Squeak-dev January 2001

squeak-dev@lists.squeakfoundation.org

112 participants
318 discussions

[ENH] append instvar type info to class comments
by Ned Konz 29 Jan '01

29 Jan '01

On Monday 29 January 2001 10:32, David Farber wrote: > Proposal: > what i would like to see is Whisker's type inferencing capabilites used to > autogenerate (at least part of the) class comments. Perhaps the enclosed change set will start you on this project. It allows you to add types to a class comment using the support in Whisker for type inferencing. -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 0

Re: [RFI] autogenerated type info in class comments
by Doug Way 29 Jan '01

29 Jan '01

David Farber wrote: > > [Request For Implementation] > > I was browsing Robert Hirschfeld's sUnit implementation this past weekend > and noticed that he did a nice job of commenting the classes. (this is in > the current update stream right? or did i file this in?) i especially > appreciated the way he commented the class's instance variables, eg. for > TestModel: > > Instance Variables: > summaryText <String> > detailsText <String> > failureList <OrderedCollection of: String> > errorList <OrderedCollection of: String> > patternHistory <OrderedCollection of: String> > summaryTextM <PluggableTextMorph | nil> > summaryTextV <PluggableTextView | nil> > updateColorSelector <Symbol> > > this morning i remembered that Doug Way's Whisker browser performs type > inferencing to display this kind of information when looking at a class > definition. Technically, Whisker does type collecting or "type snooping", which is slightly different from type inferencing in that it determines types by examining existing instances in the image, rather than examining source code. But the end result is similar, you get a reasonable guess of the type. (Vassili Bykov actually wrote the original type collector which I then added to Whisker, after modifying it a bit.) Type collecting is nice because it can run quickly, whereas a thorough type inferencer can be pretty slow. The downside to type collecting is that sometimes there will be no instances of a given class in the image to collect from. (Although this is often not a problem because as a general rule you're usually editing classes which you're actually running in the image.) I was thinking about adding Dan Ingalls' simple type inferencer to Whisker as a backup method for when the type collector can't find any instances. Also, I think Lex Spoon is working on a more thorough type inferencer... I'm not sure what the status of that is. Anyway, this is sort of a digression from your post. > Proposal: > what i would like to see is Whisker's type inferencing capabilites used to > autogenerate (at least part of the) class comments. i envision > autogenerating a preamble to the class comments containing the instance > variables and their types, as shown above in the example of Robert's class > comments. this preamble would not be editable, and would always be kept up > to date by the system. (i believe Whisker keeps the type info up to date, > even as you change the class definition or change a variable's implied > type.) the preamble would be followed by some sort of delimiter, say: > > ---- > > regular, editable class comments would follow the delimiter. any text > editing above the delimiter would be ignored by an accept of changes made > to the class comments. This is a good idea, actually I think Dan's original simple type inferencer put the information in the comment. Although I think an even better idea might be to put this information (inside double quotes) after the type definition which appears when you first select a class. That way the information will be more immediately available, rather than having to switch over to the comment to see it. (I got this idea from a recent thread on comp.lang.smalltalk, in which it was suggested that some sort of double-quoted warning that "THIS CLASS IS NOT YET COMMENTED" should be added at the end of the class definition pane in VisualWorks browsers, which is also an excellent idea for Squeak. When all else fails, shame people into adding comments. ;-) ) > i think this would be a great feature to add to squeak, especially for > people coming to Smalltalk from a typed languge. (and if Whisker gets > mainlined into squeak, so much the better!!) Some sort of type inferencing or collecting really should be in the base image, I agree... even if it's only 95% accurate, it's a huge help to beginners finding their way around the class library. - Doug Way dway(a)riskmetrics.com

1 0

unsubscribe
by Mathieu van Echtelt 29 Jan '01

29 Jan '01

CosmoCows Hoge der A 9-1 9712 AC Groningen the Netherlands www.cosmocows.com

1 0

Re: Comanche on Linux eating CPU?
by Bert Freudenberg 29 Jan '01

29 Jan '01

On 26 Jan 2001, Cees de Groot wrote: > I've seen Comanche eating CPU on Linux boxen twice now - the first > time I thought it was because I had lots of changesets in the image > that could be the cause, but my second installation was from a clean > image and had the same behavior. It's not much, maybe ~20%, but on an > Internet server it's a waste of cycles (especially when said server is > doing some unimportant background processing, like hosting 8,000 > domains ;-)). > > Both installations where Squeak 2.8, Linux 2.2.x on a multi-processor > box, with the VM attached to an Xvnc server. Anything that I'm doing > wrong with this setup? I saw this too - same setup as yours (2.2.x, smp, Sq2.8, VNC). It went away some time ago, now CPU usage is less than 1%. Unfortunately, I do not know what I did to cause that ... Anyway, I just upgraded to RedHat 7.0, and it's still fine. I'm seeing peaks in regular intervals (every 5 minutes or so) and I haven't figured out where these come from -- Bert

2 1

re: [enh] celestetweaks
by danielv＠netvision.net.il 29 Jan '01

29 Jan '01

"Lex Spoon" <lex(a)cc.gatech.edu> wrote: > 1. The custom menu button always presents a menu; matching filters are > listed at the top of the the menu. That sounds good, but your changeset puts them under the fixed filter management options. The tiny CS below reorders that to be as advertised, which I for one would prefer. > 2. The auto-move button is removed. Instead, the regular TOC menu will > give the option of an automove. These two features you mentioned are not equivalent - note what (still, with your changes applied) happens when you press alt-m. The automove I put in automatches the appropriate filter and then *moves all* matchers to the folder of same name. Of course, whether this is a good thing or bad is a matter of taste. I'm happy as it is, still having the keyboard shortcut. If people find that too dangerous an option to have (and it might be, to have hidden only in keyboard shortcut), I don't particularly mind having my own customization changeset. > 3. Huge message lists are not shown, but a menu item is added to > forcibly show all messages. This introduces a bit of redundancy with the existing folder list's menu item "view all messages"... I'd keep any one of them. > 4. The From Filter is switched to a Participant Filter."! Hey, cool! It's much more useful this way.

1 0

[BUG] Layout offset inconsistency
by Jesse Welton 29 Jan '01

29 Jan '01

As noted in the comment of Morph>>addMorph:fullFrame:, there is an inconsistency between the meaning of layout offsets between ordinary Morphs and SystemWindows. This is emphasized by the fact that SystemWindow>>addMorph:fullFrame: actually negates the bottomOffset (in addition to adjusting it to take the title bar into account) -- but only when the bottomFraction is not 1.0! This should really be cleaned up. I'd set to it straight away, but to make matters worse, it looks like LayoutFrame in fact wants to treat the offsets as insets, causing me significant cognitive dissonance. So: should "offsets" be offsets, should "offsets" be insets, or should the name be changed so that "insets" are insets? -Jesse

3 3

Re: Team development support in Squeak
by Stephane Ducasse 29 Jan '01

29 Jan '01

Hi Joseph Pelrine and some other guys are developing in thecontext of the squeak stable effort an application model (envy and teamv mixed) for Squeak. You may want to contact joseph Pelrine (jpelrine(a)acm.org say that this is me that gave you his email) and john Sarkela (one of the main actor in Squeak World Tour) sarkela(a)home.com Stef > Resent-date: Fri, 26 Jan 2001 19:01:49 +0000 > Date: Fri, 26 Jan 2001 15:39:08 +0100 > Resent-from: squeak(a)cs.uiuc.edu > From: rob <rob(a)cosmocows.com> > Subject: Team development support in Squeak > Resent-sender: squeak-request(a)cs.uiuc.edu > To: squeak(a)cs.uiuc.edu > Resent-cc: recipient list not shown: ; > Resent-message-id: <0kaYjD.A.wKB.dmcc6(a)jerry.cs.uiuc.edu> > MIME-version: 1.0 > X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 > Content-transfer-encoding: 7BIT > Importance: Normal > X-Priority: 3 (Normal) > X-MSMail-priority: Normal > X-Loop: squeak(a)cs.uiuc.edu > X-pair-Authenticated: 212.26.212.244 > X-Mailing-List: <squeak(a)cs.uiuc.edu> archive/latest/28189 > > Setting up the team development infrastructure in our company we are having > a discussion about several possible strategies for source code management > and project management. > As we are sure many of you face the same problem I would like to ask for > references, experiences, suggestions. > Of the possible solutions the following come to mind: > - Visual Source Safe from Microsoft, or PVCS > The advantage would be a defined way of working, a disadvantage would of > course be the > fact that it is file-based and has no awareness of objects. > - Scan, a tool from Heeg > This is a project from Hans-Martin Mosner on http://squeak.heeg.de/ > How is this tool going with the new Squeak releases? Morphic support? > - AppMan (is it ported to Squeak?) in the Smalltalk archives > - any other solutions? > > =================================== > Rob Vens > "Cosmocows don't moo, they squeak!" > http://www.cosmocows.com > =================================== > Stephane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes University of Bern, Institut fuer informatik and Mathematik IAM-SCG, 10 neubruckstrasse, CH-3012 Bern, Switzerland.

1 0

RE: [OT] Frame and Word [Was: Squeak Books!]
by Peter Crowther 29 Jan '01

29 Jan '01

> From: Andrew P. Black [mailto:black@cse.ogi.edu] > I have an explanation for this. I think of writing like programming. [...] > My administrative staff thought of writing like typing: what you see > is all you've got. [...] > One thing that I > notice is that the Word documents that I'm sent almost always use > visual formatting, and rarely use styles. As an apps trainer: Styles are very confusing to new users of a word-processing package. This is not helped by most Word courses putting them in the 'intermediate' or 'advanced' part of the course. Also, many/most admin staff typically create one- and two-page documents, where styles are rarely useful. When I teach Word, I spend 10 minutes on styles in the fundamental (1-day) course; about two-thirds of the delegates get the idea, but very few are able to use them successfully and almost all move back to the WYSIAYG mentality by the end of the course. I moved from Frame via AmiPro to Word, just as Word gained character styles (and one of my major bitches was removed). I've written 400-page manuals in Word, and [that part of] it works fine as long as you use *entirely* styles and never touch the normal formatting controls. - Peter

1 0

RE: Squeak as an NT service
by Torsten.Bergmann＠phaidros.com 29 Jan '01

29 Jan '01

Hi Andreas, I once wrote an NT Service sample which allows you to easily create a windows service in Smalltalk. It is included in the Smalltalk MT distribution. You can check out their test version (www.objectconnect.com or www.genify.com) to see how it's done or try the following: Anything you have to do is to set the appropriate startup (dwStartupType) type when you call the CreateService()-API. SERVICE_AUTO_START will specify a service who will be started automatically by the service control manager during system startup. My SmalltalkMT Service also initializes the service state like the following: WinNTService>>initialize ... status := SERVICE_STATUS new. "service state structure" status dwServiceType: SERVICE_WIN32_OWN_PROCESS; "this service only contains the code for one service" dwCurrentState: SERVICE_STOPPED; dwControlsAccepted: SERVICE_ACCEPT_STOP|SERVICE_ACCEPT_SHUTDOWN; "the service accepts start/stop" dwWin32ExitCode: 0; dwServiceSpecificExitCode: 0; dwCheckPoint: 0; dwWaitHint: 0. self status: status; "set state and update using SetServiceStatus()-API" isRunning: false. SERVICE_ACCEPT_SHUTDOWN means: The service is notified when system shutdown occurs. This flag allows the service to receive the SERVICE_CONTROL_SHUTDOWN value. Note that ControlService cannot send this control code; only the system can send SERVICE_CONTROL_SHUTDOWN. Check out the following pages in the MSDN or search for one of the flags/api functions in the library: http://msdn.microsoft.com/library/psdk/winbase/services_3p9h.htm http://msdn.microsoft.com/library/psdk/winbase/services_9s36.htm Hope this helps Torsten -----Original Message----- From: Raab, Andreas [mailto:Andreas.Raab@disney.com] Sent: Samstag, 27. Januar 2001 20:38 To: 'squeak(a)cs.uiuc.edu' Subject: RE: Squeak as an NT service Peter, It may certainly be useful, but the fact of the matter is that I have no idea of how to make it happen :-( Any Windows hackers out there who can help?! - Andreas

1 0

Re: Changes acceptance and polling issues
by Lex Spoon 29 Jan '01

29 Jan '01

> I don't really think I agree with this. These kinds of operations are by > their very nature "multi tasking". I/O *should* be processed behind the > scenes IMO. And since the focal point of IPC is very clearly definable, > complexity isn't much of an issue. There is the queue out outgoing messages > that is shared, and there is the incoming message dispatching. Protecting > access to the output queue is trivial. For incoming messages, there's a > design issue of wheather to process messages in a separate event process or > let the calling code provide the process (or something else entirely). The incoming messages are precisely the hard part. Those guys will make big changes to the model, and they'll trigger UI updates. How do you manage these changes, if the messages are being processed outside of the UI thread? You either have to put locks everywhere -- meaning you always wonder whether you have the locks set up correctly -- or you have to explicitly forward the updates over a message queue -- meaning you have to work out an object model for the updates. The single-threaded version doesn't have these concerns. > > But it's not a major block in the road IMO. For my Java IRC implementation > I opted to use an event dispatching thread to handle events in a listener > pattern fashion because I thought it was the obvious choice. It never even > occurred to me to use some kind of polling API :) In the code in question, there is just one polling loop; the rest of the code is driven via direct method calls and on event broadcasts. The vast simplification is that none of the code worries about synchronization; the message handlers can just update the model and call #changed: directly. > > Maybe I'm in the minority. But I've never really had a problem with > multithreading; as far as I can recall I've never ran into a deadlock > bug for example. IMO the advantages by far outweight the disadvantages. > Well, I don't have much personal experience with this, either. Then again, I tend to write sequential code! I can give three examples of other peoples' code with threading problems, though, in increasing order of vagueness: 1. The Windows Squeak VM and its handling of sockets. Each socket gets at least one thread, and I've been told that socket shutdown, for example, is extremely complicated. 2. The sophomore class I'm an assistant for is using Squeak, and the newsgroup has several posts from people whose images are locked up. >From the descriptions, it sounds like threading errors to me -- one busy loop at a high priority, and bye bye image. 3. The lore of both CS departments I've spent time in is that it's risky to log into department machines when students have threading assignments -- the machines tend to fill up with processes and lock up. I can also argue this from principle, too, but I won't bother unless requested. Surely most people agree that threads are error prone, and that the errors they generate tend to be hard to track down. > > Second, there are cases where polling doesn't have the ills that are > > usually ascribed to it. In particular, polling works well when failed > > polls are cheap, and where polls can happen infrequently. If a problem > > meets both of these criterea, then polling will work fine. CPU usage > > will not be abnormally high, and responsiveness will be good. IRC meets > > both criteria, while HTTP serving probably does not. > > This might be acceptable in practice. I'm a purist though; I don't like > polling as a matter of principle unless there's a *really* good reason for it > (such as implementing a progress bar when you don't want to trigger an update > after each I/O operation). > > At the moment I have Squeak running an IRC bot on a server. It constantly > hogs about 0.5-2% of the CPU - probably because I'm invoking processIO four > times per second. > So you are claiming that the CPU usage is actually significant? I disagree, and provide two arguments. First, the CPU load in Squeak is typically a couple of percentage points anyway, even *without* IRC running. Second, the following code is a direct timing of the polling overhead: c := IRCConnection new. c openView. "connect to a server and wait for initial messages to go by" [ 1000 timesRepeat: [ c processIO. ] ] timeToRun "40" 40 milliseconds for 1000 polls is not a CPU drain. And note, this code hasn't had any time devoted to optimization -- there is probably room for improvement, should it ever become a concern! Furthermore, note that when the IRC connection gets busy, the overhead goes *down*; in the extreme case where every poll finds work to do, the overhead is *less* than that of threading plus synchronization. Overall, if you argue from purity, then there is little I can say. If we talk about concrete measures, however. it seems that avoiding threads will make this system simpler, it will avoid some hard bugs, and it won't significantly affect performance. -Lex

1 0

← Newer
1
2
3
4
5
6
7
...
32
Older →

Jump to page: