Squeak-dev October 1998

squeak-dev@lists.squeakfoundation.org

107 participants
209 discussions

Re: Subsumption Architectures in Squeak
by Sam Adams 27 Oct '98

27 Oct '98

Dave Astels wrote: << <snip> I've started a project to build a version of Rod Brooks Behaviour language (tentatively called "Behave Yourself" :-) and a subsumption architecture VM in Squeak (I had recently begun in VWNC). I've switched to Squeak due to a) it's openness, and b) the VM building support that is built in. A Smalltalk implementation of the Virtual Subsumpton Machine (VSM) was going to be a central feature of the system, with a handcrafted C version developed for use on embedded hardware. Now, with the Squeak tools, the C version can be generated. >> Welcome! I would also like to know more your subsumption interests and efforts. I have been following Brooks' work for years. Recently I have been investigating the possibility of doing an Animats-like environment in Morphic for experimenting with various kinds of critters. Something like Michael Travers Animal Construction Kit (Alife VI, p.421) with subsumption for higher level functions. Sounds like you're more aimed at embedded control, but a software environment to test your subsumption designs could be useful, too. [Duh, I just remembered that Travers' work was part of the Vivarium project.....any thoughts Alan?] <<And lastly, Squeak has the "fun" feel that Smalltalk-80 had.. that has been lost in VW, VA, etc.>> Couldn't agree more! Regards, Sam Sam S. Adams, Distinguished Engineer, IBM Network Computing Software Division tie line 444-0736, outside 919-254-0736, email: ssadams(a)us.ibm.com <<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>>

1 0

Re[4]: Structure of objects and execution (with effects
by Jerome.Garcia＠wj.com 27 Oct '98

27 Oct '98

> It sure would be nice to be able to read ((a+b)/(c+(d raisedTo: n))) as a + b ------ n c + d (Well, layed out nicer than posible with ASCII art) But it is dificult to write that way, using linear text, and difficult to parse that way, using linear text. The above illustrates one of my problems with the use of linear text as source and the thought that parse trees have to be derived from the such source. I think that in the above case it is more user friendly to provide a GUI editor which manipulates the "parse tree" directly. The individual plus, raiseTo, and divide nodes encapsulate the knowledge and behavior necessary for their individual requirements including bug catching and prevention along with the pointers linking the nodes to each other. The GUI provides the support and spatial information that is necessary for building and maipulation of the tree itself. The GUI can have multiple faces including the ((a+b)/(c+(d raisedTo: n))) type of face and the parse tree form for those that prefer. The difference is that of editing structure rather than linear text. My point is that I do not see the advantage of having a form that needs to be parsed. Jerome -- Jerome E. Garcia jegarcia(a)adventurousmind.com ______________________________ Reply Separator _________________________________ Subject: Re: Re[2]: Structure of objects and execution (with effects Author: "Michael S. Klein" <mklein(a)alumni.caltech.edu> at INTERNET Date: 10/27/98 10:48 AM > - The ability of the system and the user to copy, paste, and merge The following is an obvious statement, but it bears saying: The parse tree is derived from the source, and the byte-codes are dervived from the parse-tree. At each step, information is lost... not gained. Obviously these two representations are more efficient in certain domains... byte codes are easier to execute, more compact, parse trees are easier to analyze. But these are all optimizations, derived from the source. Alternate source representations should move in the direction of the user, not the computer. For instance, in principle, with enough contextual information availiable, the "source" text is derivable from a series of UI gestures. The text can then be viewed as a compilation of these gestures. If someone cut & pasted code from one method to another, this info might indicate area ripe for factoring. Of course, no one wants to see UI gestures when reading source, but then I really dont want to see parse-trees either. If a representation is neither more readable, not more writable, leave it to the computer. It sure would be nice to be able to read ((a+b)/(c+(d raisedTo: n))) as a + b ------ n c + d (Well, layed out nicer than posible with ASCII art) But it is dificult to write that way, using linear text, and difficult to parse that way, using linear text. -- Mike

1 0

Re: Re[2]: Structure of objects and execution (with effects on v
by Les Tyrrell 27 Oct '98

27 Oct '98

> The following is an obvious statement, but it bears saying: > > The parse tree is derived from the source, and the byte-codes are dervived > from the parse-tree. This can also be reversed... the Decompiler takes byte-codes and generates first the parse tree, and then a printed form based on the auto-formatting code in the parse nodes. I will be rebuilding that last step, so that auto-formatting is done by a visitor rather than the nodes. As a side effect, a visitor framework will be built that would also allow analysis tools to be easily built. > At each step, information is lost... not gained. Obviously these two > representations are more efficient in certain domains... byte codes are > easier to execute, more compact, parse trees are easier to analyze. But > these are all optimizations, derived from the source. Alternate source > representations should move in the direction of the user, not the computer. I believe that any current information loss due to these transformations can be solved. The bytecodes used for the Smalltalk VM map rather well into the model of execution that actually is presented to the user, and I don't think there really is all that much opportunity for information loss even in the existing system. les

1 0

Optimization for portables
by spacelab 27 Oct '98

27 Oct '98

I am pretty new to the VM stuff so this may be crazy but... what the heck Since most VM's represent special objects ( i.e. nil true false smallints ) in a much smaller space than real objects would it be possible to have a class with a few booleans optimize and pack them in a way to use just 1 bit each ( Granted we can do this ourselfs) Could other packing schemes also be built in? Do smalltalks with optimizing compiler directives exist? It would seem we could make smaller images if this stuff exsited. It could especially be useful if a mainstream web-plugin for smalltalk becomes popular. Also, Has squeak been ported to be a web plugin yet? Also, I remember reading or hearing about the concept of micro vm's ( VM's that sort of ship with the code ) and lately this seems like it could become closer and closer to possible in production. Are their any papers on this topic? When I saw pocket smalltalk and the 20k VM it struck me that you make that a 20k DST VM and we are on the verge of micro VM's. I see we have a mini squeak, how about a micro squeak? Cheers, Steve

1 0

Re: Re[10]: Does Squeak include a generic node class?
by Les Tyrrell 27 Oct '98

27 Oct '98

> You refered to running your analysis tools on various classes. Were you > also thinking about such patterns which emerge during execution? No- I was only interested in the patterns that appeared in the static analysis of the source code... the patterns would be a way to reduce the complexity of the huge amount of results generated. les

1 0

Re: Squeak-perfect portable
by Steve Dekorte 26 Oct '98

26 Oct '98

johnm(a)wdi.disney.com wrote: > Thanks for the hot tip! This is an interesting form-factor and might make > a lovely machine on which to prototype pen-based Squeak applications. Ditto. It's good to see that someone has reinvented the 1980's GRID laptop design. There have been rumours of a similar Apple machine. See the image at the bottom of: http://www.macnn.com/reality/hardware.shtml Steve

1 0

Re[2]: Structure of objects and execution (with effects on v
by Jerome.Garcia＠wj.com 26 Oct '98

26 Oct '98

I think compactness of the parse tree matters but not as much as the following: - The ability of the GUI to ask at each node what is possible and present that information to the code developer as either restrictions on actions or choices of actions. - The ability of the system and the user to copy, paste, and merge branches as they desire and obtain assistance from the system in resolving problems. - The ability of the system to analyze, compact, and optimize the parse tree automatically. Such changes should be reflected to the developer via the GUI. As necessary, the system should be capable of requesting confirmation from the developer prior to proceeding with changes. Basically what I would like as a long term goal is a development system which learns how to improve itself by analyzing and manipulating the parse tree or any more appropriate representation. But, I also want it to be able to reflect all changes to the developer in a human understandable form so that the developer can also learn from the process and therefore provide better feedback into the system the next time he or she interacts with the system. Jerome -- Jerome E. Garcia jegarcia(a)adventurousmind.com ______________________________ Reply Separator _________________________________ Subject: Re: Structure of objects and execution (with effects on visu Author: Daniel Vainsencher <danielv(a)netvision.net.il> at INTERNET Date: 10/25/98 11:03 PM To be be truthful, I honestly don't think it matters, how compact ParseTrees are, so long as they're convenient, and can easily and cheaply change formats... I trust the power of generic compression algorithms, and good code generators. In fact, I don't care if the system usually holds all the ParseTrees compressed, making them even less readable (directly) than CompiledMethods are now - so long as they open up automatically when the user turns his gaze on them. Actually, it seems like a very good starting point for the usual compressed format for code to remain CompiledMethods, or something similar - again, so long as the user and system tools get to work with a parseTree, transparently. Compactness isn't the (or even a) key feature here - a direct, usable representation of that which matters to people and programs, is. And I'm not especially attracted by a particular use for them, but by all of them together. Type inference is interesting, Alternative implementation schemes are interesting, Flexible binding for code is interesting, Automatic code layout is interesting (anything to keep the programmer on the real issues...), Better code editors are interesting (the mistakes structured editors made are assets, not proof this can't be done right, right? 8-), Visual representations for code are interesting, Code transformation is interesting, Real time code complexity metrics are interesting, etc... And it seems to me they're all fairly begging to be rid of the tyranny of the string and the CompiledMethod. CompiledMethods (bytecodes) were an inspired combination of compact representation and executability by a VM - but, IMHO, we can now afford to separate those two concerns from one another, and from everything else we do with code. Dan Ingalls wrote: > Dwight Hughes <dwighth(a)ipa.net> wrote ... > >He is wanting to improve the prettyPrinting > >to the point that it would be the preferred option (and be customizeable > >of course) -- allowing most of the source to be drastically reduced in > >size, down to basically parse trees. > > Just to be clear about a couple of things... > > The prettyPrinting with comments would save space because METHODS are extremely compact; not because Parse Trees are; they are not. In fact I believe parse trees are the worst of the three (text, parse trees, methods) in compactness. What's nice is that the decompiler can build parse trees from methods, and those, in turn can (re)generate source code. > > ...and that's not to say I'm opposed to working with parse trees either. The original Fabrik (and ThingLab before it) built parse trees from its graphical structure and then generated code from the result. > > - Dan > > P.S. There are other nice things about parse trees, such as being able to execute them for type. A simple type inference mechanism can be built this way. One should be able to execute the methods themselves for type, but the compilation of ifTrue: and the other optimized control constructs prevents it.

1 0

Re: Squeak-perfect portable
by Asymptotically Approaching Harmony 26 Oct '98

26 Oct '98

Joshua Johnson Marker <lux(a)umich.edu> writes: > At www.ogrady.com, the top link is information about the new Clio, > a sub-1000 portable. The flipback screen (that lets it turn into a > sketchpad), stylus, 11 x 8.5 x 3/4" made me think squeakish thoughts. . . > . > > Wow. I just inherited a 486 DX2/50 laptop with a whopping 4M RAM. It's currently running Linux but I'm thinking of running DOS and the DOS version of Squeak (And possibly Kaffe). New life for old hardware :) -Chris ______________________________________________________________________________ |Chris Patti|ICQ#16333120|feoh(a)cosmic.com|Home #:(617)625-3194| Geek At Large| | "The best way to predict the future is to invent it" - Alan Kay |

1 0

Re: Structure of objects and execution (with effects on visual programming, and reversible debugging, )
by Dwight Hughes 26 Oct '98

26 Oct '98

Hi Dan, That'll teach me not to throw comments about randomly ;-). What I actually have in mind is something between an abstract syntax tree (with symbol table) and a compiled method. Create the tree (no transformations or optimizations done in the parsing to create the AST - not even for #ifTrue: and kin) and "flatten" it into a RPN representation encoding the node type and and corresponding identifier string symbol into bytecodes. Actually I guess it _is_ a simple compression scheme -- because you would have a array of identifier strings, each string with a corresponding bytecode for its index. The pseudo-compiled code would simply be a bytearray of node-type/array-index "pairs" (ignoring arrays larger than 256 for the moment). The nice thing would be that this representation is independent of implementation and it is completely shareable -- all info is included for both compilation and for source reconstruction and could be transmitted reasonably efficiently. It wouldn't matter if you were compiling to another bytecode set, native code, threaded code,.... This representation could also be used in the image for a type of "lazy compilation", where the core methods and classes of Squeak are fully compiled, but the rest could be represented in this form, to be fully compiled only when finally sent a message. On comments: if comments were considered as a peculiar type of language construct rather than just another form of whitespace, then it could be inserted into the tree along with the rest of the nodes; the CommentNodes could act as placeholders and be placed at the proper position in the tree for source reconstruction. Since there are fewer that 16 node types, an encoding of NNNNIIII IIIIIIII could be used for up to 4K identifiers in a single method (yuck!). Just some vague notions I've been rolling around a bit. I'm sure there are a number of gotchas to doing it this way that I haven't thought of. -- DWight Dan Ingalls wrote: > > Dwight Hughes <dwighth(a)ipa.net> wrote ... > >He is wanting to improve the prettyPrinting > >to the point that it would be the preferred option (and be customizeable > >of course) -- allowing most of the source to be drastically reduced in > >size, down to basically parse trees. > > Just to be clear about a couple of things... > > The prettyPrinting with comments would save space because METHODS are extremely compact; not because Parse Trees are; they are not. In fact I believe parse trees are the worst of the three (text, parse trees, methods) in compactness. What's nice is that the decompiler can build parse trees from methods, and those, in turn can (re)generate source code. > > ...and that's not to say I'm opposed to working with parse trees either. The original Fabrik (and ThingLab before it) built parse trees from its graphical structure and then generated code from the result. > > - Dan > > P.S. There are other nice things about parse trees, such as being able to execute them for type. A simple type inference mechanism can be built this way. One should be able to execute the methods themselves for type, but the compilation of ifTrue: and the other optimized control constructs prevents it.

3 3

Re: Updating old 2.1 images to 2.2 (limited interest)
by Dan Ingalls 26 Oct '98

26 Oct '98

Folks - The beta release should be on its way this evening. For those of you who are updating old versions of Squeak, I have just put out another 40 or so updates on the update servers. These are tied to the new version name, so in order to see them, you will have to reset the version number of your image. Here's the full procedure, if you want to move a 2.1 image forward with continuity, * get all updates (the last of 2.1) ...the last should be number 227 * execute... EToySystem eToyVersion: 'Squeak2.2beta' date: '10 September 1998'. * get all updates again (the current set for 2.2) ...this should get you up to around 268 Good luck, and please let me know offline if you have any problems /or/ if it works for you (I am curious if anyone is trying to maintain independent forks). Thanks - Dan

4 5

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

Jump to page: