Squeak-dev October 1998

squeak-dev@lists.squeakfoundation.org

107 participants
209 discussions

Aspect-Oriented Programming
by Les Tyrrell 29 Oct '98

29 Oct '98

For those folks interested in Aspect-Oriented programming, I just saw the following in the Smalltalk archive at UIUC: ftp://st.cs.uiuc.edu/pub/Smalltalk/st80_vw/aopst/ It appears to have been placed recently. les

2 1

Re[2]: subsumption project
by Jerome.Garcia＠wj.com 28 Oct '98

28 Oct '98

> My job these days involves working on an embedded Java project in a VxWorks environment (see http://www.audesi.com) ... has there been any work towards a headless, embedded real-time Squeak? This is another project that would be interesting to pursue. > Does your planning also include formalization of a "Smalltalkish" mechanism for communication and syncronization between various headless embedded images on distributed hardware? I am anxious to see the evolution of an easier way doing development in this area. Also, have you given any thought to the development of automatic generation of simulators for embedded software? I am wondering is whether it is possible to develop a mechanism which would enable a component to generate and return a simulator description in answer to a message like component>>simulator. It can sometimes be a bit of a pain to develop simulators and they tend to get out of date if not constantly watched. Jerome -- Jerome E. Garcia jegarcia(a)adventurousmind.com ______________________________ Reply Separator _________________________________ Subject: Re: subsumption project Author: Dave Astels <astels(a)audesi.com> at INTERNET Date: 10/28/98 8:24 PM Dwight Hughes wrote: > Are you planning on keeping Brooks' exact same Behavior Language LISPy > syntax and implementation or do you plan to create a new Smalltalk-based > Behavior Language? It will be a new Behaviour language that is Smalltalk based rather than LISP based. The tools will follow the same "style" as the standard Smalltalk development environment. > If you were to create a SVM that ran a subset of > Squeak, this could be a very exciting thing for a lot of folks (not so > much the subsumption architecture per se but the frameworks and > mechanisms for generating the embeddable VM). I'm not sure how much of a Squeak subset will be required/desired/included but I am planning on using as much of a Smalltalkish syntax as possible. My job these days involves working on an embedded Java project in a VxWorks environment (see http://www.audesi.com) ... has there been any work towards a headless, embedded real-time Squeak? This is another project that would be interesting to pursue. Dave -- Dave Astels The people who are crazy enough Software Engineer to think they can change the world, AudeSi Technologies Inc. are the ones who do. astels(a)audesi.com (work) 01490312(a)3web.net (home)

2 1

RE: Optimization for portables
by Alejandro F. Reimondo 28 Oct '98

28 Oct '98

---------- De: spacelab[SMTP:sharris@thinktankinc.com] Enviado: Martes 27 de Octubre de 1998 01:01 Para: squeak(a)cs.uiuc.edu Asunto: Optimization for portables >Also, >Has squeak been ported to be a web plugin yet? Not a plugIn (yet) But as anActiveX object that can be enbedd in a web page. You can see at http://www.sugarWeb.com/Web/Squeak/readme.htm Please feel free to visit the Smalltalk User Group of Argentina (SUGAR) at http://www.sugarWeb.com Ale.

2 1

Re: subsumption project
by Dwight Hughes 28 Oct '98

28 Oct '98

Dave Astels wrote: ---snip--- > Since these FSAs are low level and plentiful it can be difficult > describing a large, more complex system using them. Brooks > et.al. developed the Behavor Language to provide a higher level, more > programmer friendly way to describe subsumptive systems. This was > implemented in LISP, and used a subset of LISP syntax. ---snip--- > My project is to develop a subsumption VM and development environment. > Originally I was planning to do this using VWNC for the development > tools and simulated VM, resorting to handcrafted C for the target VM. > Since discovering Squeak, I've decided to do the whole thing in > Smalltalk, using the CTranslator to generate the embeddable VM. Are you planning on keeping Brooks' exact same Behavior Language LISPy syntax and implementation or do you plan to create a new Smalltalk-based Behavior Language? If you were to create a SVM that ran a subset of Squeak, this could be a very exciting thing for a lot of folks (not so much the subsumption architecture per se but the frameworks and mechanisms for generating the embeddable VM). -- Dwight

2 1

Re: CrLfFileStream as default?
by R. A. Harmon 28 Oct '98

28 Oct '98

At 05:48 PM 10/25/98 -0600, Dwight Hughes wrote: >As a quick and modestly sick example of eol formatting there is: [snip] The runs in Text instances breaks also. >These problems seem to come from code developed on several versions of >Smalltalk and/or several platforms and cut-and-pasted I think I am guilty of this, but it is something you ought to be able to do. [snip] >I haven't looked any deeper into the problem than just being aggravated >by it and whining :-) -- it is easy enough to deal with in other ways. >Thinking a bit more about it, I think the difficulties in creating a >one-size-fits-all pathological file filter (which Richard Harmon talks >about in his messages) makes putting this filtering in as a default a >bad idea - the assumptions one has to make to filter in any reasonably >effective way will also turn around and bite you sooner or later. You very well may be right about the "bite". I'm not sure it can be done but it's annoying, and in the USA at least we are guaranteed the right to life, liberty, and platform independent line termination (PILT). It's in the constitution or something. Seriously, handling line separation is not "Rocket Science". I don't think we would ask other users of our software to deal with this kind of anomaly and programming is difficult enough without tripping over this. On the other hand fixing it won't be the cure for cancer, or end world hunger. It seems to me that Smalltalk Express handles PILT transparently, but I wouldn't want to bet my life that it does. Strings seem to be mostly stored in StringModel instances as line without line termination. It has facilities for coercing a text stream to a desired line end combination, but normally uses the platform default. I think with the following proposed set of conventions that PILT could be effectively achieved and the odd "bite" handled on a case by case basis in some standard way. - Internally all lines end with a carriage return and contain no other interline spacing (carriage return, form feed, line feed, and vertical tab). - External text lines end with the platform default unless explicitly set to some other line end. - External binary lines must deal explicitly with interline spacing characters. - External text is the open default. - All objects that have lines and internal stuff that depends on them (like Text string and runs) must have conversion methods for internal to external and back if used made external. - You run into something that doesn't follow the convention, send in a fix or at least point it out. >Since the real problem I see is in filing in such files and getting >screwy formatting when I browse the code, it might be better to have >this filter applied by nextChunk during fileIn (it would be nice to base >this filter on a very general and stupid nextLine method in FileStream - >just read in anything that is not cr or lf as a line - stop and return >the line when you see either a cr or lf, if cr or lf is the first char >seen by nextLine ignore and get next char, etc. -- then put whatever >end-of-line char you want between lines read). [snip] What I think what might work is the following suggestion in the preview of the book "The Design Patterns Smalltalk Companion" by Kyle Brown, Sherman Alpert, and Bobby Woolf" -------- Missed Opportunities For every good opportunity where the Decorator pattern is used, there seems to be another where it might have been used but wasn't. The key to the Decorator pattern is that it is a flexible alternative to subclassing. Rather than adding behavior to a class by creating a subclass of it, we can add the behavior by creating a Decorator for it. Then that Decorator can be used to decorate any other class of the same type. Plus, Decorators can be nested, so rather than having to choose between a subclass or its peer, you can decorate with both. There are numerous hierarchies that seem like they could benefit from a more flexible alternative than subclassing. For example, in the VisualWorks Stream hierarchy, ExternalReadStream has a subclass called CodeReaderStream and ExternalWriteStream has a subclass called CodeWriterStream. The following diagram shows these classes. Although their protocols are counterparts of each other, such reciprocal behavior is often encapsulated into a single class. But if there were a single CodeStream class, how could it be used with both ExternalRead-Streams and ExternalWriteStreams? It should be implemented as a Stream Decorator, much like those in ET++ (DP 183). -------- It seemed to me when I looked at the Stream hierarchy that it needed an External layer, and probably needs to be generally refactered also. That's why it looked like a lot bigger project than I wanted to tackle right now. That seems like such a cheesy cop-out as much as I whine about PILT. -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy

1 0

introductions
by Dave Astels 28 Oct '98

28 Oct '98

Hello. I'm new here and so thought I would introduce myself. I've been working off & on in/with/on various implimentations and incarnations of Smalltalk since '91. I'just recently discovered Squeak.... it's fantastic. It has the clean lines of the original Smalltalk-80 that originally caught my attention. I'm especially impressed with the extension of the Smalltalk principle of reflexion taken to the full extent.. the VM itself. 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. And lastly, Squeak has the "fun" feel that Smalltalk-80 had.. that has been lost in VW, VA, etc. Dave -- Dave Astels The people who are crazy enough Software Engineer to think they can change the world, AudeSi Technologies Inc. are the ones who do. astels(a)audesi.com (work) 01490312(a)3web.net (home)

3 2

Re: Structure of objects and execution
by Michael S. Klein 28 Oct '98

28 Oct '98

> > 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, No, the parse tree is close, but not the same in all cases. All that is required is functional equivalence. Here is example from VW: plook |x y z | x := y := false. z := (x or: [y]) ifTrue: [ y ifTrue: [self yourself] ifFalse: [x]]. ^z or: [x] plook "pretty-printed" | x y z | x := y := false. z := (x or: [y]) ifTrue: [y ifTrue: [self yourself] ifFalse: [x]]. ^z or: [x] plook " ***This is decompiled code.*** " | t1 t2 t3 | (t3 := ((t1 := t2 := false) or: [t2]) ifTrue: [t2 ifTrue: [self yourself] ifFalse: [t1]] ifFalse: [nil]) ifTrue: [^true]. ^t1 The Decompiler in Squeak does better, probably because it does fewer optimizations. > > At each step, information is lost... not gained. > 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. Consider that this roots your ideas of what "source" might be. For example, this view completely precludes any posibilities of macros (Please.. no flames... I'm not saying we should add macros). > The parse tree is derived from the source, and the byte-codes are dervived > from the parse-tree. > This is merely the way things are right now, not some axiom. The parse tree can > be derived from many different > types of user-system interactions (structured editing, visual construction, > logging of manual execution*), and can > be optimized for execution in many ways besides byte codes. These "user-system interactions" , to the extent that they can be review and edited produce source. Source need not take the form of linear text... visual construction is a prim example. The parse tree does not include geometrical coordinates in a visual language.... these are part of the source. > [snip on MorphicWrappers] Yeah. These are nice. I can't wait until I can have the target of a MorphicWrapper as a literal in my code. > > At each step, information is lost... not gained. Obviously these two > > representations are more efficient in certain domains... > > Look at the RefactoringBrowser - it uses parse trees. Why? because parse tree > are a more efficient representation > for what it is trying to do - figure out and improve code. Exactly my point... parse trees are nice for code analysis tools... not humans > Well, whaddaya > know... that's precisely what I'm trying to > do most of the time! > True, parse trees aren't perfect. For example, they don't support comments > amazingly well. Which is not surprising, > because having text as the only way of writing code made it almost unavoidable > that they would be easy to use in text > (easy to layout manually using spaces and such, for example). Because comments > are the one piece of information > that the execution engine care nothing about, it is naturally lost en route. > But that's valid only if you think the only client > for things other than text is the VM, and that's not the case. Again. I would like to move away from *just* text as source. Parse trees provide some part of the answer, but a small part. They lose more than they gain, for humans. > This doesn't mean that's the only way things could be. If you think (as I do), > that comments are there to clarify specific > elements of code (at whatever level - a statement, a method, a block, a message > send), then it makes perfect sense to > make them attach to specific parse tree nodes, and not to specific text > locations. How these comments are then rendered > on screen is a flexible matter, to be solved by UI wizards. But since the > subject of each comment will be clearly defined, > their task will be clearer than the prettyPrinters' is now. My personal opionion is that comments should be attached to regions of source. For abstract meanings of 'region' and 'source'. > > Of course, no one wants to see UI gestures when reading source, but then > > I really dont want to see parse-trees either. > > You want to see the meaning of the code you're writing, at the level of objects > sending messages (not bytecodes) ? 'Meaning' cannot be seen. I can "see" the "parse-tree" structure easiest in well-written text. All of the other visual means for showing this that I've seen are worse. > > 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 answer - when it's important to you to write this way, don't use linear > text. I siad I would like to be able to *read* it this way... not *write* it this way. > But that means you need alternatives. Someday.... > [Parse trees] could easily be expanded to support comments though. > Those branches just wouldn't produce byte code. I dont want to have to extent parse trees every time I extend my notion of source. Simple example: the time & author stamp. > The other great thing about structured representations is they allow for lively > interaction. Imagine dragging and droping elements of an equation around and the > UI only allowing valid operations. Kids could learn about the dynamics of equations > by treating the thing like a physical puzzle. Likewise imagine trigometric equations > being displayed in a structured interactive geometric form. Kids could learn about > complex trigometric relationships without algebra... You don't have to imagine it. Go look at GraphingCalculator on the Mac. (It's a desk accessory) -- Mike

2 2

Re: Structure of objects and execution (with effects on v
by Daniel Vainsencher 27 Oct '98

27 Oct '98

Michael S. Klein wrote: > The parse tree is derived from the source, and the byte-codes are dervived > from the parse-tree. This is merely the way things are right now, not some axiom. The parse tree can be derived from many different types of user-system interactions (structured editing, visual construction, logging of manual execution*), and can be optimized for execution in many ways besides byte codes. But to the extent that the language remains Smalltalk, the parse trees will remain the same. * -Gerardos and Lucianos excellent MorphicWrappers allow you to have any kind of object (smallIntegers, for example) on a morphic world, not just Morphs, and to send them messages by drag and drop, in a very natural, tactile way. A friend of mine and I have written a small addition that logs every action you do with the objects to the Transcript, so after you're done, you have executable code. That's another way of creating parse trees. Unfortunately, they are currently hard enough to create directly that we chose to go through text again, which was rather unnatural, ugly, and annoying. > At each step, information is lost... not gained. Obviously these two > representations are more efficient in certain domains... Look at the RefactoringBrowser - it uses parse trees. Why? because parse tree are a more efficient representation for what it is trying to do - figure out and improve code. Well, whaddaya know... that's precisely what I'm trying to do most of the time! True, parse trees aren't perfect. For example, they don't support comments amazingly well. Which is not surprising, because having text as the only way of writing code made it almost unavoidable that they would be easy to use in text (easy to layout manually using spaces and such, for example). Because comments are the one piece of information that the execution engine care nothing about, it is naturally lost en route. But that's valid only if you think the only client for things other than text is the VM, and that's not the case. This doesn't mean that's the only way things could be. If you think (as I do), that comments are there to clarify specific elements of code (at whatever level - a statement, a method, a block, a message send), then it makes perfect sense to make them attach to specific parse tree nodes, and not to specific text locations. How these comments are then rendered on screen is a flexible matter, to be solved by UI wizards. But since the subject of each comment will be clearly defined, their task will be clearer than the prettyPrinters' is now. > Of course, no one wants to see UI gestures when reading source, but then > I really dont want to see parse-trees either. You want to see the meaning of the code you're writing, at the level of objects sending messages (not bytecodes) ? that's what determines, directly, the parse trees structure. > If a representation is > neither more readable, not more writable, leave it to the computer. Of course we still DO have to render and edit the parse tree in a useable way, but that's fine so long as we're clear as to what we're looking at. > 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 answer - when it's important to you to write this way, don't use linear text. But that means you need alternatives. > -- Mike Daniel

2 1

Re[2]: Subsumption Architectures in Squeak
by Jerome.Garcia＠wj.com 27 Oct '98

27 Oct '98

I strongly agree with the importance of this benefit. In my current work at Watkins-Johnson on semiconductor processing equipment software based on ControlWORKS, one of the major causes of thrashing has been the existence of some components which do not provide for adequate hardware simulation during development and debugging. Work on those modules that do provide support has been greatly aided by close to transparent simulation of I/O ports and hardware with the only changes necessary to switch between simulation and real world being a couple of changes to a configuration file. Actually, I would like it to go furthur and allow for switching in and out of simulation individual components on the fly to enable confidence testing prior to actual hardware action. As far as I know, ControlWORKS does not provide this capability. I really hope that such transparency is the result of your effort. Jerome -- Jerome E. Garcia jegarcia(a)adventurousmind.com ______________________________ Reply Separator _________________________________ Subject: Re: Subsumption Architectures in Squeak Author: Dave Astels <astels(a)audesi.com> at INTERNET Date: 10/27/98 10:02 PM Sam Adams wrote: > Dave Astels wrote: > << > <snip> > I've started a project to build a version of Rod Brooks Behaviour language > > I would also like to know more your subsumption interests and efforts. I've started writing up an overview. Expect it in a couple of days. > Sounds like you're more aimed at embedded control, but a software > environment to test your subsumption designs could be useful, too. The benefit of a VM is that you could work in an entirely software environment with simulated hardware. You could tie into that by subclassing the VM and providing implementation for I/O ports. The hardware simulation could be anything from numeric oriented dialogs to full 3D, realtime visualizaton. Dave -- Dave Astels The people who are crazy enough Software Engineer to think they can change the world, AudeSi Technologies Inc. are the ones who do. astels(a)audesi.com (work) 01490312(a)3web.net (home)

1 0

cassiopeia e-11
by Matthew McDonald 27 Oct '98

27 Oct '98

Is anybody using squeak on a cassiopeia e-10 or 11? If so, can they advise on whether or not it makes a practical squeak platform? I couldn't work out whether the comments about the usability of squeak on the cassiopeia from the squeak-for-cassiopeia pages apply to the A-model cassiopeias (which have a keyboard as well as a pen) or the E-models (pen-only). The E-11 looks like a neat piece of hardware, but most of the WinCE software it includes in ROM doesn't seem to be much use unless your main computer is also running some version of windows. My hope is that I could more or less use squeak as an alternative (more flexible) operating system for the thing and ignore the WinCE stuff. The most complicated stuff I'm interested in doing is reading and writing email, and some programming. Obviously, this would be easier on a machine with a keyboard and a larger screen but would it be _practical_ on the E-11? -- Matthew McDonald <mafm(a)cs.uwa.edu.au>

2 1

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

Jump to page: