Squeak-dev June 2001

squeak-dev@lists.squeakfoundation.org

122 participants
362 discussions

Debugger desirable feature
by Ross Boylan 01 Jul '01

01 Jul '01

When in the debugger, pressing send will not get you out of a method. I think it would be good if it did. Is there any reason for the current implementation? While I'm at it, the debugger highlighting is also misleading around conditionals. if foo is false, code like this foo ifTrue: [ do something]. next command. has "do something" highlighted after evaluating the conditional, even though it will not execute that statement. At least, that's my recollection. When I try to evaluate the following method: silly |n| self halt. n_6. n _ Project allInstances size > 30 ifTrue: [n_5]. n _ n+10. ^n. I get a code simulation error at evaluating the +10. Other variants seem to work OK.

1 1

Re: newbie question - killing a process
by Bob Arning 01 Jul '01

01 Jul '01

On Sat, 30 Jun 2001 18:14:58 -0400 (EDT) Rosemary Michelle Simpson <rms(a)cs.brown.edu> wrote: >Well, that worked on getting a consistent 15 processes. I discovered that >if I terminate a process labeled "a Process in ProcessorScheduler >class>>idleProcess" I freeze not only Squeak but my machine and >terminating a process labeled "a Process in Delay class>>DoIt" freezes >Squeak but I can still quit from the top menubar File menu. The clock is >still running. Here are the fifteen process descriptions: Well, let's see... -- these look normal and should be left alone -- >1 a Process in Delay class>>DoIt >2 a Process in WeakArray class>>DoIt >13 a Process in InputSensor>>userInterruptWatcher >14 a Process in SystemDictionary>>lowSpaceWatcher >15 a Process in ProcessorScheduler class>>idleProcess -- one or both of these are normal -- >11 a Process in Delay>>wait >12 a Process in Delay>>wait -- these are terminated processes. something is keeping them around -- >3 a Process in nil >9 a Process in nil >10 a Process in nil -- these are processes for which a debugger is open. try dismissing all open debuggers -- >4 a Process in Debugger class>>openContext:label:contents: >5 a Process in Debugger class>>openContext:label:contents: >6 a Process in Debugger class>>openContext:label:contents: >7 a Process in Debugger class>>openContext:label:contents: >8 a Process in Debugger class>>openContext:label:contents: Try doing this (again, all at once): Smalltalk garbageCollect. Process allInstances do: [ :p | PointerFinder on: p]. This will open a pinkish window for each process showing what's keeping it in the image. The processes in the third and fourth groups above are the ones you are interestd in getting rid of. Cheers, Bob

2 1

Re: newbie question - killing a process
by Bob Arning 01 Jul '01

01 Jul '01

On Sat, 30 Jun 2001 16:51:16 -0400 (EDT) Rosemary Michelle Simpson <rms(a)cs.brown.edu> wrote: >> FWIW, 34 processes seems like a very high number. Have you repeated the example you gave 20 or 30 times? > >It gets even stranger. (1) the number of processes goes up and up and >then down - it went as high as 85 and as low as 20. (2) doing DoIt on >(self at: n) terminate for the processes labeled "a Process in >UndefinedObject>>DoIt" turns the comment to "a Process in nil" but even >doing that to all has not gotten rid of the clock and new processes seem >to be being spawned. I feel like the sorcerer's apprentice... Of course, >I could trash this image and bring in another from the CD, but I want to >understand how to work with the processes. Rosemary, The problem is that ProcessorScheduler>>yield creates a new, but very short-lived, process and this may happen very often. In order not to see these guys, which are really dead and soon-to-be-garbage-collected, inspect the following two lines as a single unit: Smalltalk garbageCollect. Process allInstances. A clean image will have around 8 or 9 processes. Cheers, Bob

2 1

Supporting newish input devices
by John Kozak 01 Jul '01

01 Jul '01

I've got some (PC) peripherals it would be nice to have more support for, and I've started to dig around looking at adding some. I'd appreciate any comments on the feasibility or folly of these: wacom tablet. By default, this acts as another way to move the mouse cursor, but can be used as a another, independent, pointing device. I'd like to have two separate Hands, the pen one having genie on and the mouse one not. MS Intellimouse. It's got five buttons; it'd be nice to use them all... windows keyboard. I'd like to be able to use the windows and menu keys - could someone point be at where global key bindings live? Is there a utility that dumps out the keyboard stream (or something like emacs' view-lossage)? thanks, John

3 3

Re: Out of space + other flakiness
by Bob Arning 30 Jun '01

30 Jun '01

Ross, On Sat, 30 Jun 2001 13:48:54 -0700 Ross Boylan <RossBoylan(a)stanfordalumni.org> wrote: >> >A handy thing I found was "Smalltalk pointersTo:" to trace object >> >references back. >> >>Also quite useful is >> >> PointerFinder on: <someObject> >> >>This will trace <someObject> back to Smalltalk and open a window showing >>the links in the chain. > >Beautiful! Sounds like just what I need. Can it cope with multiple paths >and loops? Loops - sure. Multiple paths - not really. It reports the first path it finds that leads back to Smalltalk. If you are trying to clear out dead wood, eliminate that reference and then retry to see if there are any more. Remember to close inspectors, etc that may be holding references. >> >Among the oddities encountered: >> >I frequently ended up with two squeak processes running when it hung. >> >I was a bit surprised to find it launching separate processes. >> >>Which OS is this? > >Debian GNU/Linux, kernel 2.4.2. Mostly "woody" level packages. I don't know Linux, but I have a vague recollection about two processes. Someone on the list surely knows. > >> >TheWorldMenu was pointing to one of the projects I hand't used much. >> >>Hmm.. doesn't sound like a good thing. I'll take a look at it. > >I thought this might be the result of some interrupted processing because >of the memory problems, rather than a bug in code. E.g., I exited that >project but ran out of memory before the project in TheWorldMenu was >updated. Although I guess I'd expect the project to be reset every time I >switched projects... An instance of TheWorldMenu may have a reference to the project it belongs to, but this would not be a problem under normal circumstances, since the project points to the world which points to the menu and it's all in the family. Something else is probably keeping the whole mess around if you have really killed the project. > >Just did it. I now see >Smalltalk bytesLeftString '4,284,616 bytes (internal) >193,700,040 bytes (physical) >523,161,800 bytes (total) ' >Before I got '5,245,932 bytes available' >However, I'm now on Win32 and the "before" is Debian. I can't tell if this >is progress. The Windows VM can tap into the OS and grab more memory for the Smalltalk heap, so it considers all of OS memory available. The other VM's use a preallocated size, so free space can mean very different things. >Based on the total space use from printSpaceAnalysis, I >gained almost 2Mg.. Well, that sounds good. >> (String allInstances collect: [ :x | x size]) asBag >> >> (String allInstances select: [ :x | x size > 1000]) > > >Most of the biggest strings apppear to be C source code. Those are parts of the VM that are carried in the image as C source. If you are interested in saving more space *and* you don't plan on generating a new VM using this image, you could delete those methods. Cheers, Bob

1 0

Re: newbie question - killing a process
by Bob Arning 30 Jun '01

30 Jun '01

On Sat, 30 Jun 2001 15:35:27 -0400 (EDT) Rosemary Michelle Simpson <rms(a)cs.brown.edu> wrote: >How do you kill a process whose objects have gone away? I created a >clock process (part of Mark's examples) and then made the mistake of >quitting without terminating the process. Now I have an orphan clock that >wont go away. I did as he suggested and did: > > Smalltalk garbageCollect. > Process allInstances inspect. > >This produced a long array of 34 processes, most of which say "a Process >in UndefinedObject>>DoIt". Mark says to 'find the one you want (probably >near the bottom of the list) and send it terminate." > >My question is: > >How do I select a receiver from this array to terminate? Rosemary, In the bottom pane of the inspector, do this: (self at: n) terminate where n is the index in the array of the Process you want to kill. FWIW, 34 processes seems like a very high number. Have you repeated the example you gave 20 or 30 times? Cheers, Bob

2 1

Re: Out of space + other flakiness
by Bob Arning 30 Jun '01

30 Jun '01

Hi Ross, On Fri, 29 Jun 2001 22:32:18 -0700 Ross Boylan <RossBoylan(a)stanfordalumni.org> wrote: >Thanks. I think things are back under control now. So the rest of >this is making conversation. > >A handy thing I found was "Smalltalk pointersTo:" to trace object >references back. Also quite useful is PointerFinder on: <someObject> This will trace <someObject> back to Smalltalk and open a window showing the links in the chain. >I thought the current VMs could grow as needed. I'm surprised to see >that it apparently can't. I *think* the Windows VM may be able to do that now, but I'm not really sure. >Among the oddities encountered: >I frequently ended up with two squeak processes running when it hung. >I was a bit surprised to find it launching separate processes. Which OS is this? >TheWorldMenu was pointing to one of the projects I hand't used much. Hmm.. doesn't sound like a good thing. I'll take a look at it. >I got into some very weird debugger states, where it apparently >switched the identifiers of variables. The code ran OK when not in >the debugger. While inspecting the results of Project allInstances >I entered the following in the bottom pane: >#(2 11 12 13 14) do: [:i | > |aProject| > Transcript show: i printString; tab. > aProject _ self at: i. > self halt. > Transcript show: aProject printString; cr. > ProjectHistory forget: aProject. > Project deletingProject: aProject.]. > >When I looked in the debugger, i contained a project, and aProject had >the number 2 in it--the reverse of what should have been. The code >also acted this way--when I went forward I got errors because objects >weren't the right types. When I removed the halt, the sensible values >came out on the transcript, and the most of the requested deletions >did occur. I thought we had this one fixed, but your example gives me the clues I need. I'll put out an update to fix it. Thanks. >Here's my top printSpaceAnalysis before: >Class code space # instances inst space percent >String 16824 69965 3482093 18.1 >ByteArray 3192 559 3276681 17.0 >CompiledMethod 7578 41735 2691360 14.0 >Array 1494 48182 2288068 11.9 >Bitmap 3277 1526 2025812 10.5 >Symbol 3610 32939 663867 3.5 > >and after > >String 16824 68212 3365324 22.5 >CompiledMethod 7578 41715 2690236 18.0 >Array 1478 42607 2139148 14.3 >Bitmap 3277 825 1784456 12.0 >Symbol 3610 32937 663822 4.4 Is this a clean image or one you have added stuff to? I ask because you have many more Strings than I do (although not that much more in terms of space). Have you tried ChangeSet allInstancesDo: [:cs | cs zapHistory] >By far the biggest win was ByteArray, which lost over 2.6Mg of memory >in 92 objects. What were those likely holding? bit maps (not the >class, but something related)? One use of ByteArrays is to hold the compressed version of Forms which have been hibernated. One technique I use in rooting out these mysteries is something like: PointerFinder on: (ByteArray allInstances asSortedCollection: [ :a :b | a size > b size]) first >I'm guessing the strings are source >code. Maybe literals in methods, but the source itself is usually only found on disk. The exceptions would be any browsers you have open, etc. Some interesting things to inspect: (String allInstances collect: [ :x | x size]) asBag (String allInstances select: [ :x | x size > 1000]) Cheers, Bob

2 1

Sorting on Oops
by Anthony Hannan 30 Jun '01

30 Jun '01

Is it true that objects in memory never change relative position? The garbage collector only slides objects and never swaps them. If this characteristic is likely to remain. I would like to surface the oops in the image so we can sort objects by them and do binary searches on them. I find this useful for creating a LargeIdentityDictionary that has a hash table of 4096 entries (exhausting the 12 bits of identity hash) with buckets in each entry that hold its elements in sorted oop order. The objects in the buckets can then be search using binary search on their oops. What do you think? -Anthony

3 2

ping... (please ignore this mail)
by Stephan Rudlof 30 Jun '01

30 Jun '01

Explanation for this mail: Squeakers, my domain was unavailable between 26.-28.6.. No it is available again, but I don't get any Squeak ML mails. Since there could be an intelligent mailing list program, which possibly waits for some action after a disconnection: this is it... Greetings, Stephan -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

1 0

Re: Newbie Questions
by Ned Konz 30 Jun '01

30 Jun '01

On Saturday 30 June 2001 10:54, Steve Wart wrote: > I am a little confused by the distinction between scripts and methods, > especially when I look at the SyntaxMorph. How hard would it be to get > the methods to show up in the Viewer? Scripts are (special) methods that live in so-called "uniclasses". If you browse the Morphic-User Objects category, you'll see the actual classes that were made on the fly. Each scripted object gets its own class. But there's some special plumbing that lets a method be usable for scripting, mostly including declaring slots and commands for the Viewer. I suspect that the reason that regular methods aren't visible in the Viewer is that the eToy user would be overwhelmed. Look at implementors of "additionsToViewerCategories" to see how a class adds commands and slots to the Viewer. -- Ned Konz currently: Stanwood, WA email: ned(a)bike-nomad.com homepage: http://bike-nomad.com

1 0

Jump to page: