Gerardo Richarte wrote on Fri, 29 May 2009 01:00:24 -0300:

Merik Voswinkel wrote:

...

A question from our Morphle team about the name SqueakNOS. Jecel and I are publishing papers about SiliconSqueak and the operating system we run on top of it. It has (among many other innovations) a new virtual parallel device driver system.

This is very interesting, where can I read more from this? or see it? screenshots, movies, anything!

The paper about the driver framework has not been written yet (much less the actual code), but there are several sources of information that are available. There was a thread about this on squeak-dev back in May 1998:

http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-May/015997.html

Unfortunately, my message that started that thread is missing from the archives. So I will add a copy of it to the end of this one.

A wish list for Squeak was discussed earlier this year and two items were a rewrite of the event interface between the VM and the image and the inclusion of the Announcements framework (created in VisualWorks and ported to Dolphin Smalltalk and Squeak) as part of the official image. I suggested that these two items could be merged and several people felt this is a good idea, but not work has been done on this.

http://wiki.squeak.org/squeak/5734

An interesting aspect of SqueakNOS is that interrupts get translated into semaphore signals. This allows some forked code to block in different points on this semaphore, which gets us something more like coroutines than traditional interrupts handlers (which always start in the same point and so have no saved state). This is very similar to what was developed for the Apertos operating system that I have mentioned here before.

http://www.sonycsl.co.jp/project/Apertos/techpaper.html

I am talking about papers 8, 9, 10 and 12 (I haven't actually read 10 since it is in Japanese). For your convenience, I have translated paper 12 from Postscript to PDF:

http://www.merlintec.com/download/SCSL-TM-94-005.pdf

...

Would you mind if we would call that SqueakNOS 2.0, or is that name reserved for the work that you and Luciano did?

well, truly, I think it's not a good idea, unless it's really based on SqueakNOS, and unless you are going to contribute everything back to SqueakNOS right away. We'd really have to see it to decide, but until we do, please, don't call it SqueakNOS or anything similar.

On the other hand, if you implemented a new platform where SqueakNOS can run, it's just SqueakNOS, not 2.0, we commit it to the source repository, and that's it.

The code we are developing will be just plain SqueakNOS. I am very much against forking except in extreme cases. In my discussion with Merik, I mentioned that the current state of SqueakNOS has some limitations equivalent to early Linux or even MS DOS 1.0. In those systems the hardware configuration was hardwired into the software and you had to recompile it (or wait for Microsoft to do it for you) before you could access new hardware. Eventually Linux got its kernel modules and MS DOS 2.0 got its .sys files, so I said we need to get to at least that level with SqueakNOS where some framework allows the PS/2 mouse to be replaced with a USB one, for example.

So I used the term "SqueakNOS 2.0" to refer to a version at least as modular as DOS 2.0 (not the most ambitious target for an OS developer, right?).

And then, yes, we are planning a SqueakNOS 2.0 already (and a 3.0 and a 404 too :)

Exactly - let us get our roadmaps in synch if possible.

Just to be clear: the discussion was about code to be added at the Smalltalk level to SqueakNOS and not about any details of the lower level platform. And I am also very interested in having SqueakNOS track any changes in terms of event handling that might be developed for "normal" Squeak.

-- Jecel

Here is the initial email in the i/o framework for Squeak thread: =============

From - Tue May 19 22:05:54 1998

Received: from jerry.cs.uiuc.edu (qmailr@jerry.cs.uiuc.edu [128.174.246.71]) by hermes.lsi.usp.br (8.8.8/8.8.8) with SMTP id CAA25363 for jecel@lsi.usp.br; Tue, 19 May 1998 02:19:02 -0300 (BSC) Received: (qmail 27590 invoked by uid 95); 19 May 1998 05:18:39 -0000 Resent-Date: 19 May 1998 05:18:39 -0000 Resent-Cc: recipient list not shown: ; Date: Tue, 19 May 1998 00:17:14 -0500 (CDT) From: jecel@lsi.usp.br Message-Id: 199805190517.AAA27596@c.cs.uiuc.edu Subject: KeyUp events Resent-Message-ID: <"Hw2QrC.A.goG.hYRY1"@jerry> To: squeak@cs.uiuc.edu Resent-From: squeak@cs.uiuc.edu Reply-To: squeak@cs.uiuc.edu X-Mailing-List: squeak@cs.uiuc.edu archive/latest/2072 X-Loop: squeak@cs.uiuc.edu Precedence: list Resent-Sender: squeak-request@cs.uiuc.edu Status: RO X-Mozilla-Status: 0001 Content-Length: 2357

I really haven't looked too deeply at this, but it seems to me that it is not possible to detect keyUp events in Squeak. That makes it impossible to write certain kinds of games, a simple piano application or, in my case, a chorded keyboard emulator.

To tell the truth, I haven't been very pleased with what I have seen so far of the input architecture. I thought you might find a design I came up with interesting (if not, sorry for wasting bandwidth...).

My idea is to have a set of components connected in a graph-like structure. The graph's edges can be either "push" (where the origin sends a message like #mouseDown: to the destination) or "pull" (where the destination sends a message like #curentCursorX to the origin).

A pushInput/pullOutput component is a buffer, like the well known keyboard type-ahead buffer. A pullInput/pushOutput object could be called a "pump", and can be quite handy in certain situations. A filter is normally a push/push component, but could also be a pull/pull one. They are linked in a 2D graph, so an object can pull from several sources or send to many destinations if the need arises.

Now this graph is dynamic, and can change in response to hardware changes (pluging in that new USB joystick) user preferences (invoking Alan Kay's character recognizer) or application needs (after a drag is initiated you want to keep track of the cursor).

The application should be able to "dip into" this event graph at the points which match its semantic needs the best. If it needs to insert text in a morph then it should poll the TextMux object for input. At this point it could be seeing cooked input from a multi- language keyboard system, the result of a fancy voice recognition system or even the interpretation of some touch tones over the phone line. On the other hand, the toy piano app I mentioned above would be driven by virtual keyboard scancodes. In the same way, a program that needs gestures could get them from a filter on the mouse or from a VR glove, while a paint program might prefer to see mouse events directly (not really, but you get the idea).

Extending Squeak with remote "hands", MIDI, future facial expression recognition from video and so on will become ever more difficult unless something like I suggested is implemented.

-- Jecel =============