Squeak-dev April 1998

squeak-dev@lists.squeakfoundation.org

107 participants
279 discussions

Virtual Computer (was Re: Interpreter plug-ins)
by Reinier van Loon 10 Apr '98

10 Apr '98

Taking into account all the remarks about the VM I think we're actually designing a virtual computer. The standard way a hardware computer starts is like this: After power-up the processor starts reading instructions from a well-known address (either hardwired into the processor or by shortwiring a few outside lines). The code which is then executed is called bootcode. The bootcode knows what to do to start another program (i.e. jump into ROM (C64) or load code from a disk (BIOS), etc). To get back to the thread about plug-ins: The power-up of a VM is nothing more than starting a program in the current platform. This program is the bootcode. The only function of the bootcode is to boot the operating system, in our case SqueakOS. SqueakOS is a program which is only capable of loading, unloading and starting executing of other programs/libraries (maybe even thread support). SqueakOS is configurable via for example a configuration file (SqueakOS.cfg) which states which plug-ins to load and which plug-in to start. The very first plug-in is probably the Interpreter. Once the Interpreter is started we're in the Squeak world of Smalltalk. It would be nice if we designed a standard startup for a common Interpreter, e.g. evaluate Session class>>start. From this method we could check if the following plug-ins are available: SqueakNetwork (sqnet), SqueakGUI (sqgui), SqueakFile (sqfile), SqueakConsole (sqcon), SqueakDevelopment (sqdev) etc.). Or we could use a file (Squeak.cfg) to state what to do. When running under another operating system we don't need the bootcode (only on a bare chip). To get things working we might: 1) write a program in ANSI C called SqueakOS which - supports primitives support; - supports 3 primitives: load, unload, start; - reads a file called <executable name>.cfg (default) or the file named in the first command-line parameter; - loads the files named in the configuration file; - transfers control to a loaded file. Sample configuration file: --------------------------- SqueakVM load. "load the interpreter" SqueakVM start. "start the interpreter" SqueakVM load. "load the interpreter" SqueakVM start: Session start. "start the interpreter with sending the message Session start" --------------------------- 2) put the interpreter in a file called SqueakVM which - has a main function called start(); - supports all primitives needed for running bytecodes; - loads the base image; - performs the message in the command-line (e.g. Session start) or continues at the program counter (default) Now we're in the position to let Squeak start up inside Squeak. Cheers, Reinier. --- Want to express your thoughts? Use Smalltalk. --- Reinier van Loon (rvloon(a)inter.nl.net or reinier(a)2share.com) Squeak Download Area at http://web.inter.nl.net/users/R.L.J.M.W.van.Loon/Squeak/download.html

1 0

Re: Squeak needs printing capabilities
by staypufd 10 Apr '98

10 Apr '98

In your msg you said, >TedK wrote: ><< >We have already begun to let Squeak generate .html files. Almost every >platform has a web browser that can print. If you choose "PrintOut" in the >Browser, it generates a html file. One problem with html is that you have no >control over horizontal spacing. Tabs are not supported. Putting in more >than one space character does not influence horizontal spacing. > >Other than that, html is a 'universal' printing format. I've noticed some >gif >support in the system. I would like to see us expand this capability to >allow >any window to dump an image of itself on the disk as a legal html file. An >added benefit is that one can make web pages by 'printing' and moving the >files >to your web server. >>> > >I don't know if everyone knows this dirty little web trick or not, but you >can >use transparent gifs of various size (or widths) to simulate tabs (but not >tab >stops). Not the perfect solution, but it would at least be useful for >rendering code and other simple linear forms of text formating. > >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>> > You might want to generate html that uses the latest cascading style sheets stuff. It lets you choose fonts, absolute and relative placement, etc. Sam Griffith Jr. Objective Methods Software staypufed(a)aol.com staypufd(a)gte.net

2 1

Re: Interpreter Plugins
by Boris G. Chr. Shingarov 10 Apr '98

10 Apr '98

Andreas, On March 22, I responded to Alejandro: ----------------------- citation ------------------------------ > If we "modularize" the VM to have the opportunity to load > its parts when the "upper (image) objects" need it, > the complete building of the VM can be done dynamically. > In commercial versions of Smalltalk like PPD, the user > have the possibility to write some primitives in an external > module (e.g. DLL) and bind/unbind a service to a primitive > number to expand or patch VM behavior. I was already looking into that. Neat idea. But why make Squeak do all the work where we can put it on the OS? Just put different sets of primitives in different DLLs. My own vision for VM modularity came from the UPs. I had Ian's sqUserPrimitives.c with his sample primitives, and my own one with DLL callout (like your SqApi, but for OS/2). 'Ok', - I said, - 'now I want both, should I produce a merged sqUserPrimitives.c by hand???' Didn't look like an option... now it searches for all DLL in the cwd to see if there are some user primitives to load. --------------------------------------------------------------- Boris

1 0

Re: Interpreter Plugins
by wirth＠almaden.ibm.com 10 Apr '98

10 Apr '98

John M. said: -------------------------- I disagree with part of this; it is actually *quite* easy to remove the VM support for optional features such as sound I/O and networking. The way to do it is to make stubs for the C functions that do the real work, and to have these stubs call "sucess(false)". This will make the primitives simply fail if they are called. Yes, some glue code still remains in the interpreter, but it consumes a trivial amount of space. The real argument for Interpreter Plugins is that they would allow folks to add primitives without recompiling or even re-linking the interpreter. This would greatly facilitate experimentation, I think. The only downside is that we'd need a cross-platform way of handling DLL's. This probably isn't too difficult, although its not an area that I know much about. -------------------------- While not disagreeing with what John said (how could I do that? :-) I'd like to suggest that there's a stronger reason for providing a plug-in mechanism: It forces the people with detailed internal knowledge to define interfaces, and reduces the cognitive load for us neophytes who want to add new functionality. With a plug-in interface to the VM, there's a better chance that I can get my head wrapped around the required knowledge in a reasonable time. Without it, it seems like I have to learn everything before I can do anything. Mike Wirth IBM Almaden Research Center

1 0

Bug in scanChars?
by Tim Rowledge 10 Apr '98

10 Apr '98

According to Holy Writ (ie Aug.81 Byte) the old scanWord prim would blt a character _before_ returning the CrossedX condition. The scanChars prim currently in Squeak (and, as it happens, similarly in ancient BrouHaHa sources) does _not_ b lt that last char. Since the source code for DisplayScaner>crossedX claims that the char will have been displayed but clipped as needed, I think this counts as a bug. I only noticed it because I was trying to speed up various text displaying stuff and reali sed that setting the right edge value to the same as the clipping rect right ought to work. Unfortunately, that results in odd looking right edges to lists and so on. I believe it would be A Good Thing to return the prim to its previous definition that matches the image's expectations. All that needs doing is to move the line "scanDisplayingFlag ifTrue:[self copyBits]. " up above the previous clause. tim -- Useful random insult:- An example of how the dinosaurs survived for millions of years with walnut sized brains. Tim Rowledge: rowledge(a)interval.com (w) +1 (650) 856-7230 (w) tim(a)sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>

1 0

Re: Interpreter Plugins
by Sam Adams 10 Apr '98

10 Apr '98

kend wrote: << I tried a couple of years ago to get the Java(Soft) folks interested in pluggable VMs to be able to run Smalltalk, etc. on the Java VM. I guess it was not really in their interest. But we could certainly do the reverse trick! The basic idea is to register VMs then have special 'switch' bytecodes to dynamically swap between bytecode dispatchers (e.g. for page layout, mathematics, Java, etc., etc.). The VMs--you could think of them as custom microcode machines--could even be dynamically loaded, at least on systems which support dynamic loading. It is very modular and if you can keep a VM small enough to stay in cash, probably as fast as native code. >> This is very much akin to an idea I've been kicking around using "content and rendering engine" metaphor. Think of a behavioral description (like bytecodes, source codes, rules, etc) and a behavioral rendering engine (interpreter, compiler, rule engine). As on the web, different rendering engines may invoked by a browser to handle the content of a particular page. So, instead of a one-size-fits-all language, you have languages fit or purpose. Of course, this is from the VM perspective. I want my Squeak objects to "know" how to render themselves in various interesting ways. Anyone out there remember "Well Defined Objects" (KSC circa 1992)? This is not really a violation of the MVC separation of concerns idea as much as it is a stronger emphasis on object self knowledge, like the self defining data tape in Alan's OOPSLA talk. But that's another thread that should be discussed another time. 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: Squeak on a Chip
by Maloney 10 Apr '98

10 Apr '98

At 11:25 AM -0500 4/9/98, Tim Olson wrote: >>And if you saw the demo of Squeak running on the "bare-chip" Mitsubishi >>computer at OOPSLA, you know that we mean this! > >This sounds interesting -- for those of us that weren't there, can you >describe it a bit? Sure! The background is the Mitsubishi has a nifty single-chip RISC computer that integrates RAM on the same chip as the CPU. But they didn't have any software for it. So they got a bright summer intern named Curtis Wickman to port Squeak to it. Curtis had to write all the device drivers from scratch, including a display driver, the mouse and keyboard handlers, a Flash RAM file system, a loader, and sound output. This took four to six weeks, I think. However, we were then able to put a generic Squeak image onto it and it looked and behaved exactly as it does on a PC or Macintosh. Even though we knew intellectually that this would be the case, it was somewhat mind-bending when Alan grabbed the mouse during our demo began doing an unrehearsed demo and everything worked perfectly! The amount of code required for this "bare machine" implementation was quite modest; 2000 lines of C and a hundred or so of assembly code, as I recall. -- John

2 2

Re: Squeak needs printing capabilities (A proposed solution)
by wirth＠almaden.ibm.com 10 Apr '98

10 Apr '98

<The following is somewhat dated because I started writing it yesterday (before being interrupted). It's amazing how many interesting comments come across the Squeak list in a short period of time:-) BTW, add Ted's suggestion of HTML to mine below.> Patrick Logan said: >Maybe there should be two efforts: > >(1) Sending text to a line printer. > >(2) Rendering postscript. Others have talked about GhostScript (as an embedded PostScript rendering engine, perhaps). I think we need to be very careful about adding too much bulk to the Squeak environment. I want to be able to use it for handheld devices, for example, and my priorities are: 1. Keep the minimum runtime size as small as possible. 2. Keep the amount of C code necessary to implement and/or port the system as small as possible. 3. If we must add something bulky, make it as modular and removable as possible. 4. Enhance our leverage to take advantage of existing solutions. A. Considering these priorities, how about the following solution (in analogy with QuickDraw and PS on the Mac): 1. Add methods to the Morphic objects to render themselves on a PostScript port (instead of the display). 2. Add the minimum necessary to the platform-specific code to package up this PostScript stream and direct it to: a. a file, or b. a printer, or c. a separate rendering application (e.g., GhostScript runnning as a separate process). I can't imagine why you would really want A.2.c. except if there were differences in rendering fidelity or features between Morphic=>screen or PostScript=>screen (all the old arguments about QuickDraw to PostScript conversion and the merits of Display PostScript come to mind). And since we control the Morphic code, we should be able to keep rendering to the screen and rendering to a print stream reasonably close together. B. If what you want is the ability to generate high visual quality, navigable, on-line documents from Squeak, then I have an even better suggestion for you: In the above proposal, substitute PDF for PS: 1. Add methods to the Morphic objects to render themselves on a PDF port (instead of the display). 2. Add the minimum necessary to the platform-specific code to package up this PDF stream and direct it to: a. a PDF file (which, in fact, is a navigable, object-oriented, read-only database -- See the PDF book, updated edition), or b. a printer, or c. an embedded rendering engine, consisting of the existing and available PDF plugin for Netscape Navigator, plus the necessary portions of the Navigator plugin interface (taken from the now-available Navigator source code :-). This approach has all kinds of interesting characteristics: 1. Online viewers and the ability to print PDF files is readily available. 2. PDF files are resolution independent, and font support is excellent. 3. Treating PDF files as OODBs, in which we can add arbitrary properties to objects, e.g., Smalltalk code, means that we can generate "active documents" with hyperlinks, active computations, etc. Reminds me some of the "notebooks" in Mathematica. Mike Wirth IBM Almaden Research Center

2 1

Re: Interpreter Plugins
by Ken Dickey 10 Apr '98

10 Apr '98

>Even more, we could build customized VMs for certain application domains >which might not include networking, sound, or even file support (if its >running a bare chip system). Also, adding new stuff would be probably much >easier - you would not have to modify the Interpreter but could just >create a new plugin which can be translated into C code. Finally, a lot of >duplicate work could be removed by the plugins because if each new >Interpreter implementation implements the plugin interface it should run >immediately. BTW, I think that the sqUserPrims.h file already gives a good >impression about what is needed to access the Interpreter from such a >plugin. > >Comments? Andreas, I tried a couple of years ago to get the Java(Soft) folks interested in pluggable VMs to be able to run Smalltalk, etc. on the Java VM. I guess it was not really in their interest. But we could certainly do the reverse trick! The basic idea is to register VMs then have special 'switch' bytecodes to dynamically swap between bytecode dispatchers (e.g. for page layout, mathematics, Java, etc., etc.). The VMs--you could think of them as custom microcode machines--could even be dynamically loaded, at least on systems which support dynamic loading. It is very modular and if you can keep a VM small enough to stay in cash, probably as fast as native code. Hey, I like the idea. So it must be good! 8^) Cheers, -Ken

1 0

Re: Interpreter Plugins
by Reinier van Loon 10 Apr '98

10 Apr '98

> Jim Benson wrote: > > This of course brings up another question -- how do we handle image > startup / configuration ? VSE has a nice way of doing that. It starts up and reads a file called <name of executable>.bnd (the bind file) and binds any libraries named in that file to the image at startup. A library may have a bind action which is evaluated after the library has been bound. In such a way each library (plug-in) can initialize itself and even start the application or development environment. The actual executable remains very small (24 KB) because all it does is binding some standard libraries and then the libraries in the bind file. Reinier.

1 0

← Newer
1
...
19
20
21
22
23
24
25
...
28
Older →

Jump to page: