Blake -

Great idea. Thanks for volunteering to write that. ;-)

But seriously, not out of the box in an easy way. Some of that could be handled through events, if the VM or I/O processing routines were set up to handle such events.

After all, one can think of Embedded Squeak as just a Smalltalk object that processes messages (events)... My thinking for now is that such events (messages) consist of Smalltalk code to be executed and return text strings. However, there is no reasons that you could not submit a piece of code that says in effect, "when this happens, send a string down the serial port or network socket".

For example, off the top of my head, in one line fragements:

"Smalltalk at: #CallbackEvents put: Dictionary new." "CallbackEvents at: #timerOne put: 'EmbeddedSystem report: ''timerOne'''." "[Semaphore new waitTimeoutSeconds: 3. Compiler evaluate: (CallbackEvents at: #timerOne)] fork."

Of course, this isn't exactly what you're looking for, but it could be pressed into service to do something like it (with appropriate code on the other end of the link to interpret 'timerOne' or a more complex message structure).

Of course, you're also asking about "recursive" callbacks, so that would be a little trickier...

-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the GPL Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com

Blake McBride wrote (regarding Embedded Squeak):

Does it allow recursive callbacks/callins?

--blake

Sven Dowideit wrote:

do I read this correctly? you _are_ working on a Newton port?

As I wrote to the list two years ago (on 12/21/96): ) ... for those of us who already use Smalltalk for other projects, ) Squeak on a Newton is a way to stretch our imaginations ) in new directions as to what Smalltalk can be about.

Having started it, the Newton port will be an albatross around my neck until such time as I (or someone else) can say version 1.0 is done...

A full port under Newton OS is just at the edge of technical feasibility for the MP2100 or expanded eMate. The single biggest issue with the Newton port is lack of good C++ debugging support in Apple's tools. There are several others, next in importance being that users will be *very* annoyed if a C/C++ program crash kills their Newton, which supposedly can happen (by crashing in such a way as to overwrite critical memory somewhere which isn't backed up), although I've never seen this personally. And, as an earlier thread shows, it is quite possible to crash the VM from within Smalltalk. Now that you've been properly warned, liabilities disclaimed, received suggestions to back up and not do this on a mission critical Newt, etc., we can proceed.

Embedded Squeak (Squeakette) is so simple to deploy, almost no debugging (relatively speaking) will be required to get the minimal implementation to work on any platform with a C compiler and some form of character I/O (serial, console, socket, etc.). So, I have hopes it might work right the first or second time on the Newton. Since Squeakette eliminates the need for loading and saving files, or doing keyboard I/O, bitmap display, and mouse tracking, those issues can be ignored at the start, and dealt with as desired over time.

For example I just got Squeakette to work under VxWorks on a client's prototype hardware (MIPS type chip). It took two days. Most of the time was spent diagnosing the "32 bit clean" issue Georg posted about previously. Besides filing in Georg Gollman's patch and regenerating 'interp.c', and aside from creating a makefile (defining 'EMBEDDED' and 'mips'), renaming main() to mainInterpret(), and calling mainInterpret() from standard VxWorks file 'userConfig.c', all I really had to do was change the serial input primitive to remove the keyboard hit test (Windows call) and switch _getch() with getchar(). Also, I had to add a line right after getchar() to convert ascii 10 to ascii 13 for a proper line end (otherwise Squeak just echoed input and never processed it, since the main loop waits for a Character cr (not a Character lf) before processing). While it all could be improved (and of course should not be used in life support equipment, nuclear power plants, flight control systems, etc.), it works.

Of course, Squeakette only chats over the console serial port. However, the Squeak VM serial I/O primitives can be enhanced to send and receive messages via named pipes or sockets (keeping the VM separate from the rest of the system), with each named pipe or socket being assigned a separate serial port number, allowing one to do unlimited I/O from those two serial primitives.

[By the way, I noticed if you open the current 'embedded.image' on a PC without COM2, it warns about a primitive failure -- just change the default serial port in EmbeddedSystem from 2 to 1, save the image and quit, and you're fine on reloading the image.]

what level HW are you going for??

MP2100 or Expanded eMate. I'd like to run under MP2000 or MP130 if we could get the image size (Compiler + core base classes) down to 100K or so, and cut warpblit etc. (sorry Dan! :-) out of the VM to bring that down to 100K or so too. A 200K C binary + NewtonScript shell might be able to run on the MP130 or MP2000.

I have a dream to pull the ROMs from a 120 (or better) and give the best HW form for me a nice life.

Sounds great, but Apple still hasn't released enough specs to use the underlying hardware by making your own ROMS. I'd love to do the same too though. There are many power management and device driver issues that would need to be overcome though.

and Squeak seems like the 'place' (grin) for me.

And the rest of us, too!

I currently have a 110, and am curious about what you are up to,

You might say my current approach is inspired by Forth.

I have a NewtonScript shell I wrote a year or so ago, which currently hosts a Forth (written in NewtonScript, but based on eForth by Bill Muench, and developed in collaboration with him). The shell is a window that floats above the notepad (or any other text edit). It has a drop down menu with among other things "do it". You select some Forth written in the Notepad, and then you choose "do it" and the results are added right after after the Forth code in the same notepad entry. (That this was doable at all, let alone easily, is a tribute to the NewtonOS). The Forth "image" is persistent as long as the shell window is up. I would like to do the same thing with Squeakette.

and if you would like a slave... (I have a bit of time, don't know much Smalltalk yet, but I've used a few different platforms, and program for a living)

I'd very much like any help I can get on improving Squeakette (as long as such improvements are put under the Squeak license).

However, although your offer is tempting, I don't believe in slavery -- it's not practical in the long term due to low morale, low productivity, sabotage, rebellion, etc. (let alone moral by today's standards).

But, if you wanted to be a great help as a collaborator :-), you could modify the Squeak VM translator (Smalltalk->C) to generate the Squeak VM as a C++ class. Shouldn't take that long, and it could be a great learning experience. My hand-translated C++ 1.21 VM is now quite out of date. Making the VM a C++ class needs to be done because C/C++ compiler for the Newton does not support globals (don't ask me why, since other ARM C compilers do allow them). The idea is that you make a VM class instance and then all its calls pass itself around. I already have NewtonScript support code to make a VM object and call its interpret routine. This work would be useful whether or not a Newton port uses it.

Alternatively, if you could investigate creating an expression in Smalltalk which would close all windows, and then remove all GUI classes, (and also map the debugger and notifier to EmbeddedSystem>>report calls), I'd be much obliged. Doing this well would require a thorough investigation of Squeak processes, and also mapping out how the base system calls the GUI. I'm hoping this would let us reduce the image size to 100 - 200K.

Or instead, figuring out what code can be dropped out of the interpreter for a headless Squeak (bitblit, sound, other optional primitives), would be a great help in reducing the footprint. What primitives are essential for basic embedded operations (i.e. compilation and text processing)?

Or, investigating why the Apple C++ tools crash (after taking forever) when trying to compile a definition of the image as a memory array would help. I had a similar problem with VC++, but found a compiler switch to fix it ( /Zm500 ). Is there a compiler option I could use with Apple's tools, or could we get someone like Tim Rowledge to compile the image for us on another ARM machine and give us a useable image.o file?

Or, if I had a version of the Squeakette Squeak VM and image which accepted a string, processed it, and returned a string as a single function call like: int sqPrintIt(char* doItString, char* resultString, int resultLength); I could then link this Newton shell to it. The current Squeakette system does process characters and return characters, but there are some issues to be resolved in terms of who calls whom when, (how exactly the VM cycles and interoperates with the caller).

I am currently toying with such issues as a Windows ActiveX control to be used with Delphi (similar to Python for Delphi http://www.robanal.demon.co.uk/demos/pyvb/index.htm ), but similar issues need to be resolved for the Newton. However, this may be complex, as Blake McBride pointed out earlier, and so probably isn't the best issue for you to start with (unless you're comfortable with VC++ and like the idea of doing an ActiveX control to get started with Squeak, with the though that the ActiveX control would work much like a Newton version of Squeakette).

-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the GPL Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com

Steve Dekorte wrote:

Paul Fernhout pdfernhout@kurtz-fernhout.com wrote:

...

A full port [of Squeak] under Newton OS is just at the edge of technical feasibility for the MP2100 or expanded eMate. The single biggest issue with the Newton port is lack of good C++ debugging support in Apple's tools.

Have you considered using the NewtonScript VM?

Steve -

This is a good idea, and was discussed briefly on the list a very long time back.

This message is in two parts, one about the concrete issue you raise (using the NewtonScript VM to implement Squeak) and one about abstraction (doing Squeak VM generation / porting in a general way, which entails adding better support for abstraction to Squeak).

There are at least two possibilities - using a Squeak VM written NewtonScript and using the NewtonScript VM directly as the Squeak VM.

A Squeak VM in NewtonScript would probably run 30 - 200X slower than in C (probably making it unusable on current hardware). However, this might be good enough or some tasks - like experimentation or learning the Smalltalk syntax, especially if the GUI used native widgets. I think had I taken this approach at the start as a first cut (modifying the VM C code translator to spit our NewtonScript) at least I might have had something working right away, even if it was very slow. I took this approach with NewtonForth and had immediate gratification -- even though it is not as fast a Forth as a native one written in ARM assembler. There is another issue that all but the MP2100 and expanded eMate have only at most 180K of space for NewtonScript objects for all running programs, which means the image size would still have to be radically trimmed for such machines (C heap is a little larger - around 350K on earlier machines).

A Squeak VM built on the NewtonScript VM with a compiler that translated to NewtonScript VM bytecodes would run faster, however then to take advantage of the NewtonScript VM, all Squeak objects would have to be NewtonScript objects (using the NewtonScript garbage collector, etc.). Also the NewtonScript VM does not support all the byte code operations the Squeak VM does (and some operations like inheritance are done differently), so these would have to be emulated primitives or native C. Also, fundamentally the prototype frames approach take by NewtonScript is slower than Squeak's class based one (in terms of method dispatch and instance variable access). Still, this could be made to work (given Apple's releasing of the VM specs about 18 months ago).

There is a tension here. The current Squeak approach is to make Squeak *portable* by porting a common abstraction (the VM). Another approach is to make Squeak *retargetable*, by having higher level representations of Squeak and tools to work with those representations. Metacompiled Forths, like eForth, are more in the class of being retargetable at the lowest level (although such Forth systems do in practice also typically port a common abstraction at a higher level on top of the retargeted base).

Up until now, it seems all this sort of initial targeting work is done by hand (in effect: "gee, I think it can be done", "let's write a custom translator", work, work, work, "here it is"). That's great for a first step, but the next step it to make tools and representations to support this targeting effort (for retargeting).

I like Alan Kay's suggestion at OOPSLA '97 of moving Squeak/Smalltalk development to a higher plain (the metaobject protocol). Having the VM specification written in Smalltalk is a step towards representing Squeak more abstractly, but perhaps not enough in terms of documenting assumed information, implementer folklore, and possible variants.

If the Squeak VM and base image were represented more abstractly and modularly (as a semantic net perhaps?), and tools existed to represent other systems (like the NewtonScript VM or JavaVM) in the same abstraction space, we could think about developing tools to help one target some subset (or superset) of Squeak functionality to a fundamentally different abstraction (such as another language than C, another VM than the bluebook, native machine code, parallel processing tuplespaces, or as a independent component in a larger system with different interoperabilty event handling needs like an ActiveX control).

I see working at a higher level of abstraction as another twist on what it would take to have a general purpose native code generation tool suite for Squeak (see an earlier thread) -- ideally one would want to be able to represent real hardware like the 80X86 (just another VM really) in some abstraction space (concretely consisting of a simulator, inspection tools, and semantic-net knowledge base) and then retarget the Squeak VM bytecodes, primitives, and Compiler to work in that abstraction space.

Work by the Squeak team done to create the first Squeak VM and image under another Smalltalk was in this area, although in it informally. Andrew Brault's Pocket Smalltalk for the Pilot is a great example of a system moving in this direction, by using one Smalltalk image (Dolphin) to generate a very different Smalltalk image (Pocket / embedded Pilot). I suspect his VM is hand coded in C though; it could move a step up in abstraction by being written in Smalltalk and using the Squeak C translator. Putting these two approaches together will increase our ability to retarget Squeak (such as for memory or I/O constrained systems, or in other fundamentally different directions).

I think Smalltalk is one of the best general purpose languages designed for representing abstractions via building complex object sets with Smalltalk code (such as is typically done by window builder code), so it is quite feasible to do all this abstraction definition in Smalltalk, with the abstractions coded as Smalltalk snippets that build the abstractions.

However, for the past two decades or so I have worked on and off toward another programming system (called "Pointrel", for POINTers and RELationships) with a current prototype implementation in Python) that lets me begin to build tuple space / semantic net like systems using a simpler syntax without as much punctuation (although admittedly more text, so perhaps Smalltalk is still better). I have earlier implementations in various states of doneness of this in Smalltalk, Forth, Lisp, Delphi, Basic, and C. This representation work is similar to the ROSE/STAR system described in William Kent's book "Data and Reality" http://home.earthlink.net/~billkent/

In brief, the Pointrel syntax supports defining relationships within semantic subspaces by code such as:

New label John New label book New label Mary New label "gave to" John gave to Mary book New label Fred New label "the trumpet" Fred gave to John the trumpet Mary gave to Fred the box New label "display on" New label "the screen" New label "last relation" the box class "!Smalltalk at: #Box." the screen "maps to object" "!Display." display on "implemented by" "!self displayOn: arg1." The box display on the screen do last relation

The idea is to avoid smashedTogether words, by always looking up the longest previously defined phrase. Explicit quoting overrides this default behavior.

The lines "New label XYZ" can be omitted as implicit, to produce:

John "gave to" Mary book Fred gave to John "the trumpet" John "gave back" Fred the trumpet Mary gave to Fred "the box" the box class "!Smalltalk at: #Box." "the screen" "maps to object" "!Display." "display on" "implemented by" "!self displayOn: arg1." The box display on the screen do "last relation"

Of course, many text strings like "display on" or "last relation" would probably have been previously defined and would not need quoting the first time used in this semantic subspace.

After definition, these relationships of text would be then processed further to create more abstract relationships. For example the concrete "New label John" is processed into a new object with a label relationship connecting it to the label "John", and later references to "John" are indirected to this new object. All these relationships (tuples, really, and implemented as such in Python) would be tagged by other relationships associating them with specific input streams, times of day, subspaces they are in, and so on, creating a rich sea of relationships for later analysis. Each iteration of processing can be seen as "binding" the resulting abstraction into yet another abstraction.

To apply this to Squeak VM generation:

"Squeak VM" "has byte code" "return true" Squeak VM has byte code "duplicate top" Squeak VM has byte code "extended store" return true "in Smalltalk" "| cntx val | cntx := self sender. val := trueObj. self returnValue: val to: cntx." duplicate top in Smalltalk "self internalPush: self internalStackTop." duplicate top "in NewtonScript" "vm.internalPush(vm.internalStackTop())" return true in NewtonScript "vm.returnValueTo(vm.trueObj, vm.sender())"

You can then have programs that use this VM knowledge base, and reason about it to generate new ports and to assist VM implementors in maintaining ports. Of course, it would be nice to use a Smalltalk like browser to browse and maintain this knowledge base.

At this point, I'm beginning to see Pointrel as a concept that lives on top of a host programming language (whatever the combination of syntaxes used). However, there are many ways to do this, and many people who have worked in this field, and Bill Kent's work (predating Gelernter's) is still for me the definitive work, just like Smalltalk (developed around the same time) was and still is the definitive programming system. ;-)

It is very hard to improve on the Smalltalk syntax as a general purpose programming language, so I think ultimately a fusion of ideas like Kent's on relationships and semantic nets with Squeak (along with an ability to support alternate syntaxes as needed, like described in my earlier post to the list of "Squeak and the Babel of programming languages 12/28/96") may prove to be a phenomenal system supporting work at many levels of abstraction. Knowledge representation techniques such as those looked into by Pointrel or ROSE/STAR or other AI KR work are essential to explore if Squeak is going to move to a higher level of abstraction, and from there, everywhere.

-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the GPL Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com/squeak