Squeak-dev June 2003

squeak-dev@lists.squeakfoundation.org

188 participants
973 discussions

RE: Progrmaming in Bytecode?
by Swan, Dean 24 Nov '06

24 Nov '06

>> It's not uncommon to find x86 code padded with a lot of NOPs >> that weren't in the original source. > >Cowardly assembler! ;-) > >> [NOPs...] Sometimes they're there to pad the execution pipeline, and >> sometimes it's just because the code generator allocates a whole large >> enough for the largest form of an instruction to simplify the branch >> target calculations. > >We must be talking about M$oft assemblers here. ;^p) Yes. This has been pretty characteristic of MS assemblers as far back as I can remember (i.e. about MASM 2.0 - I remember being quite excited when MASM 4.0 came out - '186 and '286 code!). >The real problem is that the solution in general might require N >iterations for a piece of code with N branches -- if promoting one of them >from short to long causes the next (or, much more problematically, a >preceding) one to become long too. You're such an optimist. O(n) is close to best case for this problem. >This is a weak form of what I suppose one might call an "oscillating >constraints" problem. (Hands up anyone who has ever seen [La]TeX get Hence, stochastic optimization. Even MS uses stochastic optimizers now, even in vb. (didn't want to say that too loud here. ;) ) >The usual cause for "padding" in (capable) assemblers (other than for >prefetch alignment, as you point out) is due to dynamic linking where the >size of call sites isn't known until link time. (On modern systems the Not only prefetch alignment. I have heard, although I don't know the details that sometimes it's desirable to force a dead cycle in the execution pipeline. I can only guess that this would be to influence the scheduling of the execution units for complex instructions, but I consider myself to be only a "casual observer" with respect to this kind of thing. >In Smalltalk you've also got a bigger problem: for very long methods the >range of even unconditional branches might not be enough, at which point >I know this has nothing whatsoever to do with Smalltalk...) Well, to kind of tie this back into something relevant to Squeak - I know a few people have talked about "new" VM instruction sets. It seems that it might help to think about a VM where all instructions are the same size. This could simplify code generation (i.e. compiling methods), and possibly improve performance and *reduce* code size (at least in the case of long methods). The anticipated performance improvement would come from forcing aligned fetches more often and potentially simpler instruction decoding. It's really nice to work with an architecture where all instructions take up one word of memory, take one cyle to execute, and sometimes can cause five or six different useful things to occur during that one cycle. (ok, so I write a lot of DSP code...) The single cycle thing isn't necessarily relevant for Smalltalk, but those "extended" bytecodes are really distasteful to me. -Dean

10 15

[ENH] InspectorsAndExplorersWithColor
by diegogomezdeck＠consultar.com 25 Sep '04

25 Sep '04

Change Set: InspectorsAndExplorersWithColor-dgd Date: 28 June 2003 Author: Diego Gomez Deck The inspectors and the explorers now will use the color of the inpected/explored object (using the idiom of #defaultBackgroundColor). Two methods are added. Inspector>>defaultBackgroundColor and ObjectExplorer>>defaultBackgroundColor and the implementation is a simply delegation to the inpected/explored object.

2 1

[ENH] Undeclared cleanup
by Michael Rueger 23 Aug '04

23 Aug '04

Hi all, this tiny goodie removes all entries without references from Undeclared. Maybe this should be called after every file in. Michael 'From Squeak2.8alpha of 19 January 2000 [latest update: #2052] on 5 May 2000 at 1:27:13 pm'! !Utilities class methodsFor: 'miscellaneous' stamp: 'mir 5/5/2000 13:26'! cleanupUndeclared | toBeRemoved refs | "Utilities cleanupUndeclared" toBeRemoved _ Set new. Undeclared associationsDo: [:assoc | refs _ Smalltalk allCallsOn: assoc. refs isEmpty ifTrue: [toBeRemoved add: assoc key]]. toBeRemoved do: [:each | Undeclared removeKey: each]! !

4 19

The Magic Book - a design draft
by goran.hultgren＠bluefish.se 30 Jun '04

30 Jun '04

The idea of a "Magic Book" inside Squeak acting as both an introductory documentation for Squeak and as a reference manual is quite intriguing. A few basic ideas that got this started: - Tying unit tests to documentation in order to detect stale documentation - Not bloating the image - Easily maintain the book cooperatively (like swiki) Ok, what would be the STTCPW? (For all you non XP aware: "Simplest Thing That Could Possibly Work"). By applying reuse - what do we already have? We already have: - Projects: A very good format for "active content". I am not sure how easily they are backwardscompatible though. Could anyone post some insight in that matter? - StarBrowser: A universal UI kindof thing. We could easily let StarBrowser be the main UI of the Magic Book! It lends itself easily for the task - a treeview on the left, a dynamic area to the left etc. If we somehow find a good way to integrate a little search form then it would be quite perfect. - SqueakMap: In whichever form we choose to have the Chapters of the book (Projects) we could register them on SM (a few new categories would be nice) and thus get a distributed always up to date model of chapters for free. And when SM1.1 gets completed it will track versions of the chapters for us, etc. And in SM1.1 it will have a sensible smart diskcache for the packages (read Chapters) so we get that too. - Free text engine: Scott Crosby wrote a neat little engine for maintaining keyword indices that the book obviously should use. I have also been intending to integrate that into SM. We should be able to add it to SM in such a way that the Magic Book can simple get that "for free". So... we already have a bunch of cool technology to implement the Magic Book IMHO. We just need to knit it all together in a smart way. If we split the book in the following pieces: 1. The TOC. This is essentially a list of chapters organized in a hierarchy with names and a link to the corresponding SM package that is the chapter content - a Project. 2. The chapters themselves. These are simply Projects published as packages on SM. Perhaps we need to follow a few conventions for these Projects so that we easily can "jump into" them in a proper manner, extract keywords for indices etc. 3. The search indices and the index (as books have last). If 1 and 2 above also are packages on SM (in whichever suitable form, doesn't matter) it will be even more simplified. So the book *contents* are then managed as packages on SM. We get the possibility of having different owners for different chapters, release/version tracking etc. It is obvious when you think about it - why shouldn't they be packages? The StarBrowser is the obvious choice of a UI - it already has navigation mechanisms and it can also show contents from the book along with other things in a highly dynamic fashion. Why reinvent that? And SqueakMap gives us a lot of stuff like efficiently always updated content, a smart cache etc. And there will be no image bloat whatsoever. Well, ok, what do you all think? Darn, this sounds like real fun... I need to get cranking at my SM1.1 ... :-) regards, Göran

2 1

[ENH] new String modifier: String>>asPlural
by Norton, Chris 24 May '04

24 May '04

Hi Folks. Here's the preamble from my changeset: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "OK. You could say that this is a silly crusade, but I like my Squeak messages to be in proper English (at least when the language you're using is English). I was messing around with the HangMan file-in and I got a walkback that had the following title: 'Error: HangManPhrases classs are not indexable'. I just couldn't stand the extra 's' on 'class', so I created a nifty new String method called asPlural and I modified the sender of the odd string to use the new String modifier. Take it or leave it, but I think this makes auto-generated text just a little easier to read." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I hope you find this new String modifier useful too. Cheers! ---==> Chris <<PluralStrings-ccn.cs>>

4 4

SqueakMap - analysis tools?
by Bill Schwab 14 May '04

14 May '04

Hello all, SqueakMap seems to be taking off nicely, and it is a nice way to grab goodies. However, I still come back to the problem of starting from scratch. Dolphin's commercial origins force the issue with each release, but it's also a nice sanity check on whether or not I know what is in my image. Are there any good tools for deciding what to load into a new image? I encourage and Dolphin-using Squeakers to take a look at Migrate from my Dolphin Goodies - especially the version packaged for D5. I would really like to see something like it for Squeak. The other issue, mentioned before, is that SM seems to favor downloading over locally cached copies. Ideally, it should offer to download updates, but be willing to load packages from the local drive. Has that been addressed? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bills(a)anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

3 2

Enhanced & Extended Serial Port support.
by John M McIntosh 11 May '04

11 May '04

I've push a changeset and macintosh plugins onto the server, they should appear in a few days. The SerialExtendedMacOS9Plugin.sit goes in the mac 3.5 noncarbon plugin location The SerialExtendedUnixPlugin.bundle goes in the mac 3.5 carbon plugin location {yes the name implies unix, but os-x is unix...} The EnhancedSerialPorts-JMM changeset which is the classes and plugin interface logic you need to file in. I suspect usage will be limited but it enables you to do things with serial ports (and file handles, hint any file handle) that you can't do otherwise. I would think to compile this code on your favorite Linux box that would be a snap. Only one platform specific primitive or method exists serialPortFindNamesPlusKeysstorage which on os-x invokes the IOServiceGetMatchingServices() call to get path names to devices that support the serial protocols. This primitive call a common Linux box could be replaced by smalltalk code to iterate over /dev or read some sort of control file etc to figure out the path names to the serial devices. For mac os-9 this functionality was already part of the VM. I'm hoping that no platform specific C code will be required for unix boxes. Alas windows users require someone to do the dirty work if you want windows specific serial calls? Or will unix emulation somewhere/how etc work? Couldn't speak for parallel ports, never even occurred to me to investigate till now. I should point out that Dan Ingalls <Dan(a)SqueakLand.org> was kind enough to actually fund with real USA $ some of the work required to build this plugin, then willing to release it to the public. So enjoy, and thank Dan for motivating ($) me to write the code and for releasing it. PS I won't pass up an opportunity to point out if you've an obscure macintosh specific feature you would like and like Dan have a bit of cash to pay for it, then we should talk. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

4 5

[FIX][KCP][3.6a] IfUnhandledError-nk
by ned＠bike-nomad.com 28 Apr '04

28 Apr '04

from preamble: "Change Set: IfUnhandledError-nk Date: 27 June 2003 Author: Ned Konz This changeset: - edits all callers of BlockContext>>ifError: to use something else, usually #ifUnhandledError: - adds BlockContext>>ifUnhandledError: (see below) - marks BlockContext>>ifError: as deprecated - edits all callers of Semaphore>>critical:ifError: to use something else. - marks Semaphore>>critical:ifError: as deprecated - edits most callers of on: Error do: [ ... ] to use something else, mostly #ifUnhandledError: - restores the behavior of removing step messages from the WorldState step list when the step messages have an error (the 'start stepping again' debug menu choice will restart them) I wrote #ifUnhandledError:, which allows enclosing scopes to handle exceptions. This behaves exactly the same as #ifError:, except that: - if there is an outer exception handler, that handler gets to handle the exception instead, and - there is now a one-argument form as well as the 0 and 2 argument forms that gets passed the exception itself. "!

2 1

RE: Fun article
by Ivan Tomek 21 Mar '04

21 Mar '04

Thanks, and my apologies for being so sensitive to this. Ivan > -----Original Message----- > From: Marcus Denker [mailto:marcus@ira.uka.de] > Sent: Friday, June 13, 2003 9:38 AM > To: The general-purpose Squeak developers list > Subject: Re: Fun article > > > On Fri, Jun 13, 2003 at 09:32:12AM -0300, Ivan Tomek wrote: > > Too bad they can't spell Smalltalk right. > > > Oh, horrors of all horrors. ;-) > > How could that happen? I just tried to fix it, and, in my local > PersonalWiki this is allready corrected. So I synced this > with the website. No change. Hmm. The problem seems to be MacOS: > the only Unix-Filesystem that is not case-sesitive. > I guess I fixed the typo as soon as I saved the first wrong version > (they are both dated the same), only the html-conversion scripts did > not write the new file (it was allready there...) > > http://www.ira.uka.de/~marcus/_The_Early_History_of_Smalltalk_.html > > Marcus > > > -- > Marcus Denker marcus(a)ira.uka.de -- Squeak! http://squeak.de > >

15 22

[BUG] FileContentsBrowser doesn't filein 'all' protocol
by Tim Rowledge 10 Mar '04

10 Mar '04

Just noticed this; in a filecontents browser if you pick a class youcan filein all the stuff for that class. If you pick a protocol you can filein all the methods in that protocol. However, if you pick 'all' protocol, you don't get to filein all the methods visible. Foo. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim AAAAAA - American Association Against Acronym Abuse Anonymous

2 1

Jump to page: