Further background: It seems to me that there should be no real conceptual difference between an IO channel to a file, and an IO channel to a socket, or to any other external IO channel which can be opened, closed, read, or written to. Presumably these should all look like streams, and presumably we would want socket streams, file streams, and any other streams on external IO channels to behave in similar ways. The specifics of making connections to various types of external IO channels probably merit their own classes, which would know about things like SQFile and SQSocket data structures if needed. I wrote some classes to do this for files and sockets, and it all seems to work very nicely, but I still need a machine independent way to convert the file and socket data structures into Smalltalk objects, hence the question about converting integers back and forth between ByteArrays and Integers.

Sounds a bit like Inferno, where every external object, file, printer, socket, network, scanner, other machine, etc. is a "file," manipulated using the traditional file operations of open, close, read, write, position, and each such object is named and accessed using an i-node-like hierarchical naming system.

If you know that the data is coming from that particular machine, you might simply write some pluggable primitive functions longAt:, shortAt: and the like, that do the obvious things, but by casting in the C code rather than trying to "interpret" the data.

This generates "portable" code that has the property that, when the plugin is compiled and installed on each native machine, it will load the data from the ByteArray, interpreting it with the "correct" byte gender for the machine on which it is running. And, of course, once you have those operations, you can test your machine gender simply by loading in an asymmetric bytePattern, say, 16rEAFF and checking the value of a shortAt:

The code is portable in the sense that it will compile on each machine; it will run with the machine's own native data correctly, but is inherently machine dependent, in that images retaining this information may break when copied from machine to machine.

Thus, the code should only be used for machine-dependent purposes or for interpreting highly transient machine local data that will ultimately be stored in non-byteArray (or machine-indepent byteArray) data objects. This is why, I believe, Squeak Central left only the "machine-dependent" operations in ByteArray -- the code yields the same results on every machine everywhere, even though its internals might operate differently.

I have a project that I have been working on and off for awhile trying to model native machine MemoryBlocks, to facilitate machine-dependent manipulation of data, and the coercion/marshalling of data from Squeak to OS and back. The project entailed a hierarchy of classes that would seamlessly understand a block that was stored in a byteArray, stored in system RAM, and pointed to (as pointer, handle or otherwise) from a MemoryBlock, whether internal or external. Using the decorator pattern, the project allows you to define system C records and other datatypes, and refer to them with a nice smalltalk syntax, regardless of whether the C type is stored in a byteArray, in Ram or otherwise. For various reasons, the machine-dependent byteAt:, shortAt, etc. was useful.

Lately, I've been wondering how good such a thing is in principle -- one of the reasons that Java never made the cut of write-once, run-anywhere had to do with a yicky "easy" solution of using machine dependencies to solve problems.

Thanks very much for your suggestions and advice! I'm mainly just having some fun figuring out how things work at the moment. One of the things I enjoy about Squeak is being able to see the whole system all the way from the high level abstractions down to the bits and bytes. I'll try not to let my more ill-conceived experiments loose on the world ;)

Dave

On Mon, Nov 01, 1999 at 12:07:53PM -0800, John.Maloney@disney.com wrote:

Dave:

Re:

...

I'm trying to map a data structure (struct SQFile) in the VM to its corresponding set of objects. The data structure is available as a ByteArray on the Smalltalk side, and I was looking for a quick and dirty way to convert to ByteArray into its corresponding Integers and so forth. This would allow a convenient way to look at the SQFile data structure with normal Smalltalk inspectors.

This is actually NOT a recommended, for several reasons. First, these objects are meant to just be handles to an opaque data abstraction; if you started to modify the bits you could either break the abstraction, crash the VM, or become dependent on an implementation detail that could change without warning in some future release. Second, the representation is entirely platform dependent. If you want your code to run everywhere, you'd have to have variations for each platform, and you'd need to detect which platform you were running on. That's just what the Squeak VM's abstraction of the underlying OS facilities is supposed to save you from having to do.

Re:

...

Further background: It seems to me that there should be no real conceptual difference between an IO channel to a file, and an IO channel to a socket, or to any other external IO channel which can be opened, closed, read, or written to. Presumably these should all look like streams, and presumably we would want socket streams, file streams, and any other streams on external IO channels to behave in similar ways. The specifics of making connections to various types of external IO channels probably merit their own classes, which would know about things like SQFile and SQSocket data structures if needed. I wrote some classes to do this for files and sockets, and it all seems to work very nicely, but I still need a machine independent way to convert the file and socket data structures into Smalltalk objects, hence the question about converting integers back and forth between ByteArrays and Integers.

It seems to me that you would accomplish your goals most easily simply by building wrapper object that holds either a FileStream and Socket object. That is, you could build a class "UniversalStream" that provides buffered stream I/O to either a file or a socket. Instances of UniversalStream would have a private instance variable that was a Squeak FileStream or Socket object. There would be no reason for them to directly manipulate the data structures of the underlying VM implementation of these objects (SQFile and SQSocket).

-- John

It looks like GUSI (Grand Unified Socket Interface) has finally been released. Interestingly, there's a new PThread emulation package. It might be nice to convert a fair chunk of the "external resource" code (filesystem, sockets, etc.) of the mac vm to use GUSI, for the sake of easing portability. GUSI is very freely redistributable.

Cheers, Bijan Parsia.

I got this off the MacTech (http://www.mactech.com/) site:

GUSI 2, a free[*] POSIX, sockets, and pthreads emulation library for MacOS, is now available on

ftp://sunsite.cnlab-switch.ch/software/platforms/macos/src/mw_c

The main distribution for CodeWarrior Pro 5 and MPW compilers (SC[pp] and MrC[pp]) is in GUSI_20.sit.bin, extra libraries for CodeWarrior 4 are in GUSI_20_CWPro4.sit.bin

Enjoy Matthias

-- Matthias Neeracher neeri@iis.ee.ethz.ch http://www.iis.ee.ethz.ch/~neeri

[*]

GUSI USER LICENSE

My primary objective in distributing GUSI is to have it used as widely as possible, while protecting my moral rights of authorship and limiting my exposure to liability.

Copyright (C) 1992-1999 Matthias Neeracher

Permission is granted to anyone to use this software for any purpose on any computer system, and to redistribute it freely, subject to the following restrictions:

• The author is not responsible for the consequences of use of this software,

no matter how awful, even if they arise from defects in it.

• The origin of this software must not be misrepresented, either by explicit

claim or by omission.

• Altered versions must be plainly marked as such, and must not be

misrepresented as being the original software.

While I am giving GUSI away for free, that does not mean that I don't like getting appreciation for it. If you want to do something for me beyond your obligations outlined above, you can

• Acknowledge the use of GUSI in the about box of your application and/or

your documentation.

• Send me a CD as described in

http://www.iis.ee.ethz.ch/~neeri/macintosh/donations.html

--============_-1270420839==_============ Content-Type: text/plain; charset="us-ascii"

G'day all

Working recently with a number of large morphs open at the same time, I got frustrated with the difficulty in handling them, and created this little changeset to overcome the problem.

It creates a menu (press shift-cntrl and press a mouse button) which shows the top level morphs in the world, and allows you to shuffle, delete, collapse or hide them.

(A bit like the application menu on the Mac)

This leads me to a question - windows have some very handy features, like collapse and expand and the way in which the focus is changed, which are a great help when using the system. Morphs don't have those features, or have them in a less accessible way (like through halos).

Is the aim in Squeak to eventually move most of the morphs in 'applications' like Tetris/FreeCell etc into SystemWindows, or will people be using a system where there are lots of 'naked' morphs on the desktop?

Do people prefer working in SystemWindows, or using Halo and 'naked' morphs? Or is there a third option?

Does SC have a preference?

:) Russell

--============_-1270420839==_============ Content-Type: text/plain; name="DesktopMenu.4Nove634pm.cs" ; x-mac-type="54455854" ; x-mac-creator="522A6368" Content-Disposition: attachment; filename="DesktopMenu.4Nove634pm.cs" Content-Transfer-Encoding: imap_stub

0,783,2,4301,0,

--============_-1270420839==_============ Content-Type: text/plain; charset="us-ascii"

---------------------------------------- Russell Allen russell.allen@firebirdmedia.com

"No Sane man will dance. " - Cicero (106-43 B.C.)

"Show me a sane man and I will cure him for you. " - Carl Gustav Jung (1875-1961)

---------------------------------------- --============_-1270420839==_============--

Stefan writes:

Sun says that their new way of describing objects is better than classes. Now I have always thought that a "class" is, in the first place, nothing more than a naming convention.

Can anybody explain to me what they are talking about then? &BTW: do you agree with Sun, or is this just another "dot in com" talk?

What Self does is rather interesting - you basically clone existing objects and add your own "slots" (which roughly correspond to instance variables and methods) to the copy. You then use it to make copies, and so on. The idea of classes sort of becomes irrelevant - to create a new instance of something, you instead just find an object with the correct slots and copy it. You can also choose to make a very primitive object, make its parent an existing object, and simply override and/or add slots to do what you want.

For instance, to make a 3D Point, I'd clone a prototype 2D Point and add the extra slot for the z value. Since the original and the close share the same parent object, the 3D Point inherits all of the slots (including methods) of the original. Now, to make more 3D Points, I clone the one I just made.

Morphic, which came from Self, simulates these additional slots with the "extensions" object which hangs off of Morph. Squeak uses them most frequently to store balloon help text. The "duplicate" halo would be critical in the Self world, and so would the functionality we see as "flaps".

Frankly, Self is a very elegant system, which takes Smalltalk-like languages towards being even simpler and easier to understand. You can artificially impose a more familiar class structure if you want, as evidenced by the Smalltalk implementation in Self. Being simpler, it lends itself pretty well to interesting implementations, including runtime translation to native code. I think I saw a note from one of the Squeak luminaries (Alan?) that Self could have been Smalltalk-80's natural successor.

I would encourage people to take a look at it. I got tremendous insight into Morphic's architecture and philosophy by examining Self and reading the various white papers.

=================================================== Duane Maxwell dmaxwell (at) entrypoint.com CTO http://www.entrypoint.com EntryPoint (619) 578-8500 x226

Information contained herein is my personal opinion and not necessarily that of EntryPoint. ===================================================