Squeak-dev January 2002

squeak-dev@lists.squeakfoundation.org

176 participants
612 discussions

Annoyance: Hierarchical Browser
by Ross Boylan 02 Apr '02

02 Apr '02

Most of the time when I open a hierarchical class browser the focal class is invisible, since it is below the very tiny scroll area that is shown. This seems a bit odd, since that class is highlighted (when scrolled into view, and it is controlling what you see in the other windows anyway). I see this both on MS Windows and Linux, though I wonder if it's a font thing and it looks OK on, e.g., a Mac.

3 2

RE: XML Parser choice (was Re: [ENH] ??? MD5 in Squeak.)
by Richard A. O'Keefe 25 Mar '02

25 Mar '02

"Andreas Raab" <Andreas.Raab(a)gmx.de> wrote: Code size isn't but complexity is. Usually these two go hand in hand and therefore it's no strange argument at all. In fact I'd argue that programmer time is (in this particular case) mostly dictated by the complexity involved in the parser itself - most people will want to do pretty simple stuff. But this is precisely why a non-validating parser would be a *bad* idea. Non-validating parsers are easy to write. But if anyone were to try to process DocBook using Squeak (hey, guess what I'm trying to learn?) such a parser would be as much use as an Apple ][ simulator (maybe less, come to think of it). If you really want to avoid complexity for people trying to use XML in Squeak, then choose a parser than implements *ALL* of XML, not just the dead easy bits. Do the hard stuff *once*.

13 16

Re: VM Profiling in Linux
by Anthony Hannan 11 Mar '02

11 Mar '02

Scott A Crosby <crosby(a)qwes.math.cmu.edu> wrote: > Do a search on the mailing list for a couple of months ago, I give an > exact recipe. I believe someone added it to the swiki. I did follow the instructions from the swiki, but still no luck. Any Ideas? Thanks again, Anthony

2 1

Re: touchesA: (Does anyone think it works?)
by Bob Arning 20 Feb '02

20 Feb '02

On Tue, 29 Jan 2002 18:34:20 +0100 Karl Ramberg <karl.ramberg(a)chello.se> wrote: >Bob Arning wrote: >> >> Rik, >> >> The *feature* probably overlooked is that this only works for SketchMorphs and I'm gessing (Star) is a StarMorph. What it will do is something like >> >> paint a blue star freehand >> name it "bluestar" >> >> some script can change its object's appearance by saying "foo look like bluestar" >> >> some other script can say "bar's touchesA bluestar" and you should get a true if foo overlaps bar. >> > >Maybe the test should work on all morphs( e.g. the rendered form of each >morph = >to avoid this confusion and have it work as a general collition >detection >for the etoy scripting ? > >All those kids making all those games need it :-) Well, probably, but one of my main goals here was to make something reasonably fast for uses like the epidemic etoy. The existing colorSees was just too slow to be useful in this case and that's because it *does* render each morph to see if it contains a particular color in a particular place. Possibly more useful in the general case would be a "touches" variant that queried some attribute/property of each morph. Cheers, Bob

2 1

Impacts of the squeak garbage collector
by Scott A Crosby 19 Feb '02

19 Feb '02

Quick summary: The default paramaters for the GC are a poor choice for RAM-rich modern computers. A 3x performance gain on GC is obtainable, if you're willing to dedicate RAM to squeak. (My desktop has 768, so I think nothing of running with 100-500mb) The current squeak GC does an incremental collection every 4000 allocations. Although this can lead to sub-ms latency, it is excessive, especially for long running or many GUI applications. So, running macrobenchmarks, and counting GC time, I get: 22 seconds of GC time. (only GC when you absolutely must, 500mb RAM.) 60 seconds of GC time. (GC every 4000 allocations) +15 additional seconds of fullGC's in either case [*] A typical run of macrobenchmarks is about 360 seconds on the P2-450. I'm not sure the threshold is where GC time drops by 2/3, but the fact that it does is an indication that other people can have similar gains. I even see some gain at 50mb and 200kallocs/GC. [*] These additional GC's occur because of root table overflows, with RootTableOverflow.cs, they become about 1/4 second total. I typically run with: Smalltalk vmParameterAt: 5 put: 400000. Smalltalk vmParameterAt: 6 put: 12000. which gives me <100ms incrgc latency. But, given average object size, its about 10mb/100k objects, so you'll want to run with 40mb free space to exploit those parameters, more memmory for higher numbers. Note that SystemDictionary>>setGCParameters resets these values to the default ones on each restart. You will have to change them there. -- Anyways, a root table overflow is bad. You consume one root table entry for each 'old' object that is made to point to a some new object. After 2500 entries, you are forced to take a fullGC. An incremental GC does *not* reset this table. Only a tenure or fullGC does. You'll typically see this in any routine that holds lots of data, or adds data incrementally to a large dbase. FTI, for examples, sees them constantly. The slang-to-C translater sees them constantly. I suspect that the recent 'Challenge' is likewise experiencing many of them.. Use: Smalltalk vmParameterAt: 21 to see how many entries have been used. Use: Smalltalk vmParameterAt: 22 to see how many times you've overflowed so far. Basically, that first number is how full the table is, and hte second number is the number of overflows (fullGC's that could be avoided.) Until the patch goes in, you can manually fake it by checking if the root table is near to full (first line), and forcing a tenure. That saves you from the fullGC. ---- SystemDictionary>>tenure "Incrementally collect all objects and tenure. This is useful after allocating a large array or after making a large array point to a new object." |oldtenure| oldtenure _ self vmParameterAt: 6. self vmParameterAt: 6 put: 0. self garbageCollectMost. self vmParameterAt: 6 put: oldtenure. ---- SystemDictionary>>tenure is part of the FTI engines. Scott

8 28

Block Closures are here!
by Anthony Hannan 10 Feb '02

10 Feb '02

I finally finished implementing block closures. Please check it out on the swiki at http://minnow.cc.gatech.edu/squeak/NewBlockClosureVersion. Feel free to email me if you have any questions. I put a lot of work into this, so I hope it gets used and eventually gets into the main release. Cheers, Anthony

8 9

Self ported to Linux
by Torsten.Bergmann＠phaidros.com 06 Feb '02

06 Feb '02

It's running, see: http://www.gliebe.de/self/ :) This project uses code (mainly the i386 assembler and parts of the NIC) from an earlier Linux port started by Gordon Cichon in 1999. Bye Torsten

6 8

[modules] Top 10 ways in which the modules system sucks
by Henrik Gedenryd 06 Feb '02

06 Feb '02

Just to anticipate a certain category of comments ;-) Top 10 ways in which the modules system sucks (ordering depends on particular tastes). - Documentation. This is a feature. No really. I had to remove the documentation to make this system Squeak-compliant. But some of the rationale behind the system is to be found at <http://minnow.cc.gatech.edu/squeak/modules>. - Things are probably broken in the existing code base. Some parts most certainly are broken: Alice/Wonderlands use pool variables in a way that really isn't supposed to work, now it propbably doesn't. Project un/loading and image segments most likely don't work properly any more. Some eToy player-something also uses pool variables in a naughty way, in classes that modify their own definition. - UI support. Right now the module explorer is what you get. And that ain't much. In particular, there is little or no ui support for creating delta modules and their contents yet. - Version management. This barely exists yet. - DeltaModules. They are not complete. Changing the external modules of the base modules, or the format of a class, would be the next thing to add. - Image modularity. I have only been able to make the VMConstruction module, and Balloon3D (almost), unloadable. - Integration with existing dev. tools. I've tried to fix the most obvious things, but cmd-q doesn't seem to find all symbols. For example. - Repository classes. These could be made complete. And be made to handle errors gracefully. No good forwarding facility yet. - ModuleInstaller. A cleaner (and complete) message protocol. More solid unistallation and failure recovery (and tests for these). Possibly the uninstall information will hold on to modules to prevent them from being cleared out from the image? - Tests. The tests I've written so far cover the functionality to a reasonable amount, but they are not exhaustive. Also, the tests for module storage/retrieval from net servers do not pass yet, in large part because the ServerDirectory code doesn't work properly. This is something anyone could work on. Henrik

7 14

[ANN] Fulltext search engine.
by Scott A Crosby 04 Feb '02

04 Feb '02

As the image has just radically changed with modules, I think it makes sense to adapt my FTI for the new image before posting it to the list. As such, I don't expect to be posting it in the near-term future. So, if anyone wants a copy for private development and integration work, send me email. Besides, it'll give me a chance to work any unknown bugs out. Scott

2 1

Re: A Squeak version of "How to Think Like a Computer Scientist"
by Scott Wallace 03 Feb '02

03 Feb '02

Consider perhaps: (StringMorph contents: 'hello world') openInHand -- Scott At 10:25 AM -0800 1/29/02, Ned Konz wrote: >On Monday 28 January 2002 08:19 pm, Aaron J Reichow wrote: >> Is there another person or two who would be interested in giving me >> a hand to Squeakify this text, introducing a Squeak book that would be >> pretty comprehensive for beginners? > >And so we see yet another computer programming intro that starts with "hello >world"... > >How would one present that in Squeak? > >* get to the world menu, or to the Tools pane, or to the Objects tool >* open a Transcript (from the menu), or drag out a Transcript >* open a Workspace, or drag out a Workspace >* type in something like: > >Transcript show: 'hello world' > >* select it, or hit alt-d (or cmd-d, depending on whether you have a mac) >* now look in the transcript > >As you see, the focus is suddenly more on the environment than on the >language. This isn't surprising, of course, given that one of the most >important parts of Squeak is the envirionment. > >But the focus of the book is on the language; I wonder how well Squeak would >fit in to this book form. > >Also, it doesn't seem like this presentation would show Squeak's best side >(that is, why print text into the Transcript when one could make things move?)

4 3

Jump to page: