Squeak-dev April 2001

squeak-dev@lists.squeakfoundation.org

165 participants
614 discussions

Re: Squeak3.0 on x86linux doesn't start - problem solved! thanx!
by Bernd Kulawik 29 Apr '01

29 Apr '01

Tim Olson wrote: >> But when I try to start it the usual way typing >> squeak Squeak3.0final.image >> at the terminal emulation, I get the response >> >> bash: squeak: command not found > > > 1) make sure that the squeak file is executable: > > chmod ugo+x squeak this is ok. > > 2) your shell command search path may not contain the current working > directory; try typing: > > ./squeak Squeak3.0final.image > > to use the explicit path to the squeak executable. > > instead of the suggested ../squeak Squeak3.0final.image this one with only one dot worked. Thank you very much, Tim! > Good luck, and happy squeaking! > > -- Tim Olson ... and a thousand thanx to all the others too! Happy squeaking! Bernd ;-)

1 0

Re: Squeak3.0 on x86linux doesn't start
by Delbert Murphy 29 Apr '01

29 Apr '01

Hi Bernd, Is the directory /Squeak3 in your $PATH? If not, just type: ./squeak Squeak3.0final.image when you are in your /Squeak3 directory. That should get you going... Delbert On Sun, 29 April 2001, Bernd Kulawik wrote: > > Hello Squeakers, > > I have to admit, that I am an absolute beginner, so please don't bash > me, if my "error" is just stupid ;-): > I downloaded Squeak3.0pre2-x86linux-full.tar.gz and installed it on my > Laptop (x86-Toshiba with SuSE Linux 7.0). After installing 2.8 on > WindowsNT and LinuxPPC (SuSE 6.4), where everything works finde, I > wonder, why it doesn't start on my Laptop. > I created on my laptop a directory > /Squeak3 > containing the files: > Squeak3.0final.changes > Squeak3.0final.image > SqueakV3.sources > System.so > squeak > But when I try to start it the usual way typing > squeak Squeak3.0final.image > at the terminal emulation, I get the response > > bash: squeak: command not found > > Surely I made a simple mistake, and therefore apologize to take your > time - but unfortunately there's nobody around here I could ask ;-( > > Bernd

1 0

RE: Space usage (where is it all going?)
by Raab, Andreas 29 Apr '01

29 Apr '01

> >[...] (Squeak draws offscreen to Display and then transfers > >that quickly to the crt or whatever). > > Thats why code like "self visible:false. (Delay forMilliseconds:1000) wait" > takes visible affect not until after 1000ms have ellapsed, right? No. Assuming that 'self' is a morph the code will set the invisibility flag, but nothing more. Then it blocks and only after the one second is over, it'll continue redrawing. Thus, to make the above code work, you'd have to write self visible: false. self refreshWorld. "make sure world has been redrawn" (Delay forMilliseconds: 1000) wait. The double buffering in Morphic is really much smarter than that ;-) What really happens is that we usually "simulate" single buffering (done by a VM call after BitBlt has completed to copy the affected region to the screen) *but* during a Morphic redraw cycle we're simply turning off the simulated single buffering (e.g., prevent the VM call) and do an explicit update operation afterwards. Pretty nifty ;-) Cheers, - Andreas

1 0

Space usage (where is it all going?)
by Scott A Crosby 29 Apr '01

29 Apr '01

Hello.... I've got a few patch (which I tried to send from within squeak,but it diedn't appear on the mailing list.) If I can get that to work, I'll send them off... Anyways, space usage: I'm doing a dump of only large objects, IE: object count and memory usage on large (>8kb) objects: SoundBuffer 2031 1 9492 WeakArray 710 1 231880 Array 1427 7 495360 ByteArray 3192 30 624681 String 16714 45 1312768 Bitmap 3277 8 3087160 -- Total 4643584 92 5761341 Roughly 3mb in the image results from 8 large bitmaps, and another 1.3mb results from 45 large strings. I'm unfamilar enough with smalltalk to be unsure how to derive exactly what bitmaps and what strings they are, but if we can remove or compress them, we can save amost 30% of image size. 53 object to save 30%. I've also got an implementation of immutable strings that I want to offer to the list. (Though ideally, Symbol should be refactored to use them?) So, any ideas why the 'send to mailing list' didn't work? Scott -- No DVD movie will ever enter the public domain, nor will any CD. The last CD and the last DVD will have moldered away decades before they leave copyright. This is not encouraging the creation of knowledge in the public domain.

2 1

Re: How to enable profiling in Mac VM?
by Fleeberz＠aol.com 28 Apr '01

28 Apr '01

<snip questions about how to turn on profiling in Mac VM code> On 2001-04-28 at 1:30:31 PM, johnmci(a)smalltalkconsulting.com replied: >I'm not sure anyone has really explain this since it's tied to Code >Warrior. If you build a Code Warrior project you must build it with >CW profiling turned on in order to get the profile: to work. (using CodeWarrior 6) Uh, yeah. I guess I forgot to mention I'd done just that; OTOH I can't for the life of me understand why the VM would slow down so drastically if profiling _hadn't_ been turned on. I disassembled the code produced and sure enough, there's stuff at function entry/exit points to read the real time clock (cycle clock? whatever) in the PPC chip itself. And speaking of _profile:_ itself, I guess if I'm stupid enough to try to compile my own copy of the VM, it won't hurt to ask this of the group: Could I please see working example code using _profile:_ (no underscores of course) to profile, say, tinyBenchmarks? Laugh at this at your leisure, but is it SystemDictionary profile: [0 tinyBenchmarks]. "hit doIt (cmd-d) on this line" or what? Told you this would be a hairy problem! ;-) >Also you should build the VM with no inlining. This makes it much >easier to read the C code and to get proper profiling information. If it's just a case of easier, I guess I'm okay... also, I generated the C source at one other point when I specifically requested inlining where I ended up with at least one source file in the 500 kilobyte range, FWIW, but that's not what I'm currently working with. I can't seem to locate the simple list of commands to issue to generate the sources anyway - saw them here I think, but searching through the Squeak image previously showed enough to compile a working VM - looking for an "official" list anyway, maybe someday? >Apple also makes product that captures branch locations via hardware. >With a .SYM file you can also get a good picture of where code usage >is happening. Sounds interesting. If I ever have any money I would consider looking into that one. Thanks in advance for any assistance, Jean P.S. If I ever write my own experimental version of the PPC jitter, may I call it "Oil?"

2 1

Re: Space usage (where is it all going?)
by Bob Arning 28 Apr '01

28 Apr '01

On Sat, 28 Apr 2001 16:33:46 -0400 (EDT) Scott A Crosby <crosby(a)qwes.math.cmu.edu> wrote: >Roughly 3mb in the image results from 8 large bitmaps, and another 1.3mb >results from 45 large strings. I'm unfamilar enough with smalltalk to be >unsure how to derive exactly what bitmaps and what strings they are, but >if we can remove or compress them, we can save amost 30% of image size. 53 >object to save 30%. Scott, String allInstances select: [ :each | each size > 8000] will show you the large strings. The Bitmap usage is probably almost all the Bitmap in Display (Squeak draws offscreen to Display and then transfers that quickly to the crt or whatever). Cheers, Bob

1 0

Re: GeeMail Authoring
by Bijan Parsia 28 Apr '01

28 Apr '01

Alan -- > Just do cmd-click (alt-click on PCs) several times to get the text > morph, then all works as usual. Ah! I didn't even think of using the text editing halo thingies. > Note that Bob has combined both a > text morph and a playfield to get a scrollable galley that can hold > all morphs. This allows quite elaborate docs to be created with > active content and examples. Yes! That's why I want to play with it :) Thanks for the tip. Cheers, Bijan Parsia.

1 0

Re: GeeMail Authoring
by Bob Arning 28 Apr '01

28 Apr '01

Bijan, Or shift-cmd-click on the test. The shift makes it start from the innermost morph under the cursor rather than the outermost. You will also probably want to change the width of the text fairly early on. Cheers, Bob On Sat, 28 Apr 2001 11:22:49 -0800 Alan Kay <Alan.Kay(a)disney.com> wrote: >Just do cmd-click (alt-click on PCs) several times to get the text >morph, then all works as usual. Note that Bob has combined both a >text morph and a playfield to get a scrollable galley that can hold >all morphs. This allows quite elaborate docs to be created with >active content and examples. > >Cheers, > >Alan > >------- > >At 1:50 PM -0400 4/28/01, Bijan Parsia wrote: >>Is there some trick to GeeMail authoring? Or sets of tricks? >> >>I don't see that I can, as things stand, get a normal yellow-button menu >>for styling text, etc. Is standard practice to use a workspace and cut 'n' >>paste? >> >>(Recognizing that it's a hack-in-progress, of course, I still ask :))

1 0

Re: Comments on Smalltalk block closure designs, part 1
by Stephan Rudlof 28 Apr '01

28 Apr '01

Ian Piumarta wrote: > > I just *know* I'm about to say something stupid. (I haven't been > following this thread, so I'm completely lost for context.) But > thanks for `CC'ing me anyway: I was wondering what to do with a spare > 15 minutes while the washer finishes washing... I think the machine likes me ;-) > > But in spite of your criticism of an evolution of the classical ST80 design > > towards block closure semantics, I'm continuing to resist to give up my design > > at the moment. For this case you have given a neat cookbook for implementing > > block closure semantics, which I could follow then... ;-) > > AFAICMO, Allen's "cookbook" corresponds pretty closely to the way > closures are (and have been) done in the vast majority of functional > languages (including various Smalltalk implementations). Apart from > anything else, you're arguing against an awful lot of exerience gained > by an awful lot of people over an awfully long time spent implementing > (and fine-tuning) an awfully large number of dynamic languages. (By > "dynamic language" I guess I mean any language that implements > closures as fully-reentrant first-class fully-upward anonymous > functions with static [lexical] scoping and free variables.) I don't want to argument against > an awful lot of exerience gained > by an awful lot of people over an awfully long time spent implementing > (and fine-tuning) an awfully large number of dynamic languages. > > On the other hand, I do believe that many great breakthroughs have > been made simply because nobody bothered to tell the people involved > that what they were trying to do was "impossible". > > So my position, generally speaking, would be: don't listen to any of > us bumble-headed know-nothings -- just go right ahead and try it. If > it works, great! If if doesn't (or if it's abysmally slow) throw it > away and move on to something entirely different (and hopefully more > promising, in the light of experience gained). A negative result can > yield information that is every bit as useful as a positive result. I've learned a lot already now by - making the design; - starting to implement while improving it; - posting the design with - provocating this thread, and - getting other reactions. > (And the time and effort spent trying to convince us that it's The > Right Way is probably comparable to the time and effort required to > implement it, measure it, and know quantitatively whether or not it's > right.) My intent wasn't to convince you by my design, but to get insights, where are the possible problems with my design. And now I've gotten much more, namely a raw draft of a more consequent design by a very experienced man (thanks to Allen). > > Agreed. But the special logic isn't very complicated here and we > > save some other logic needed by another design. > > Most of the logic needed to efficiently implement closures in the > "traditional manner" (split allocation between captured and > non-captured variables, etc...) happens in the compiler, not in the > runtime. One needs to look very closely at what gets figured out > where, and by whom. Complex logic in the compiler is preferable, if > it can eliminate even a little "trivial" logic in the runtime. > > > > You can probably get by with static links that chain together activation > > > records (MethodContexts) but this has the reification problem that > > > ultimately is a performance killer. > > > > This is a key point: Is this really a performance killer? > > In VisualWorks: I know that big savings were made by redesigning the > way closures (and free variables in particular) work, along lines > similar to those that Allen is suggesting. J4? > In J3: not at the moment, but only because other parts of the system > are sooooo hopelessly inefficient. (Some of the inefficiency is > caused by the runtime logic required to cope with blocks that aren't > real closures, and to deal with block bodies that are inline in their > defining methods -- when truth and beauty are both crying out for them > to be compiled as separate "anonymous methods". But that's another > story, for another bedtime.) Named CompiledBlocks in VW, I think. > > I don't know Jitter technology, so I'm very interested in a rationale for > > this. > > Converting between different representations of the same thing > (machine-friendly frames on the stack, closure-friendly contexts in > the heap) is just wasted cycles. Not to mention additional memory > traffic, which is to be avoided as often as possible (in any context). Without putting contexts onto the stack at all, we don't have this reifying conversions, but only heap accesses (hopefully cached well, see below) instead. > Just having the possibility for reification is costly too, since > potentially each and every return has to check whether the exiting > frame needs to be reified in the heap. (Activation might even be more > complex too, if it has to plan ahead for possible reification.) > > Plus every time you reify something, you create an object. Even > though it's probably quite a small contribution to the big picture, > the GC has more work to do. Same as previous point. > Apart from that, the closer you can get to the execution model that > the architects of your processor had in mind while they were designing > your processor, the faster your programs will run. Since most > processors are designed to run C (or maybe Fortran), activation > records were meant to be managed (in the vast majority of > architectures) by specific hardware features implementing strict LIFO > behaviour. Anything (such as non-LIFO behaviour) that causes traffic > between the stack (where the processor's designers decreed that all > activations should live) and the heap (where reified contexts have to > live) is pure overhead (and in some cases completely invalidates lots > of information, that the processor has carefully cached on your behalf > yet will throw away mercilessly the instant it suspects that you've > violated any of its implicit LIFO laws). That seems to be the critical performance issue (also see below). > > Let's take the simple example, which should occur - as I guess - mostly often > > in running an ST application in this or a similar form: > > > [:x :y | x >= y] > > > > Lets assume a collection consisting of SmallIntegers (immediate objects): > > Is for a Jitter creating and using an activation record onto the stack faster > > than reusing an activation record at the heap for every evaluation in this > > case? > > No, there's probably only a few instructions of difference between > them. (Assuming the way that contexts are handled inside the VM is > changed a little -- see "Managing Stack Frames in Smalltalk-80" [Moss > et al] for one possibility [but watch out for the typo in the example > code, if you decide to benchmark their algorithm].) (But the required > number of memory references is another matter entirely!!) > Memory or just *heap* memory references? <snipped> > > Principal question: How intelligent are the caching mechanisms of typical > > processors (for me its an Intel) > > For Intel (and clones), depends on the manufacturer. (For the most > part, fairly dumb.) > > > regarding non localized memory addresses? Is this a problem or not? > > For most caches, dynamic locality is what matters, not static > locality. Your program can generate access patterns that span > gigabytes without any adverse effects, provided that only a reasonably > small number of addresses are in the "working set" at any time (where > "reasonably small" is relative to some function of the number of > distinct cache lines that you have). As a consequence only using activation records residing in *heap* located contexts shouldn't be a performance problem, if there aren't too many used at once ('reasonable small number of addresses'). Is this interpretation correct? <snipped> 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

GeeMail Authoring
by Bijan Parsia 28 Apr '01

28 Apr '01

Is there some trick to GeeMail authoring? Or sets of tricks? I don't see that I can, as things stand, get a normal yellow-button menu for styling text, etc. Is standard practice to use a workspace and cut 'n' paste? (Recognizing that it's a hack-in-progress, of course, I still ask :)) Cheers, Bijan Parsia.

1 0

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

Jump to page: