Squeak-dev December 1998

squeak-dev@lists.squeakfoundation.org

125 participants
236 discussions

SqueakOS
by Jerry Bell 26 Dec '98

26 Dec '98

I'm new to the list, but I've found some references to 'bare-metal' Squeak implementations. Is anyone working on this? What would be the ideal kind of kernel to run Squeak on top of? I know portability would be on the top of the list. How about single vs. multithreaded? Maybe even something completely different to take advantage of the unique needs of a smalltalk environment? I assume that a goal would be to eventually make Squeak classes that could generate the low-level kernel code for a given platform, much like the interpreter generator. Then, to port to another platform you would simply define the characteristics of that specific platform. All from within Squeak. That would be.... nice. I don't have much experience with Smalltalk, and even less with OS design. But it seems that one way to approach this would be to build something quickly using simple, existing tools. Then, when there is a working system we could factor parts of the original low-level code out and replace them with code generated by Squeak. At that point, we could make refinements in speed, portability, etc. from within Squeak itself. Specifically, I've started looking at FreeDOS's kernel, dos-c, as a possible starting point. There is already a DOS port of Squeak out there, and it seems as if it would not be too terribly complicated to take dos-c and the DOS port of Squeak and kinda mash them together to make a booting SqueakOS. Plus, the dos-c kernel is supposed to be pretty portable, and is written mostly in C so it shouldn't be not TOO hard to work with. It should also be simpler than a more advanced kernel. And, it's GPL'd. I've just started looking at dos-c, I'm reading the author's book now. Unfortunately, it doesn't look like the current version of dos-c will handle the DPMI stuff that the DOS port of Squeak needs, but maybe that would be easy to fix for someone who knows what they are doing? Any suggestions? Jerry Bell jdbell(a)fareselaw.com Links: http://www.iop.com/~patv/ - this is the dos-c site. http://www.freedos.org/ - freeDOS, freely available DOS clone. Dos-c is the kernel. Book: FreeDOS Kernel / Pat Villani , it's available at Amazon. I'm reading it now and starting to look at the source.

4 3

Window code issue
by Richard L. Peskin 26 Dec '98

26 Dec '98

We are trying to improve the graphical (bitmap rendering) performance for the BeOS port. One issue we face lies in our current display model: squeak renders into its own bitmap, then we translate the squeak bitmap image into a BBitmap with the same pixel configuration as the display, then invalidated screen areas are drawn out of the BBitmap backing store. What is done on other platforms? Is the Squeak UI the same on all platforms? I.e., on any of the supported platforms, does squeak use "native" windows for its windows, or do all platforms render into a window like is currently done on the BeOS? thanks, --dick peskin ================================= R. L. Peskin, Rutgers Univ. ; <peskin(a)caip.rutgers.edu>; <http://www.caip.rutgers.edu/~peskin> VT Phone (802) 824-4558 NJ Phone (732) 445-4208 "The corporate culture is concerned less with Occam's razor than his aftershave lotion."

3 4

Re: Low on space problem.
by Christopher Oliver 25 Dec '98

25 Dec '98

> But, whenever I try to do anything in it, I get "space is low" messages. > What can be the problem? And the solution too :-) Are you remembering to give a '-memory XXm' switch where XX is some number of megabytes the VM has to work with? There is a lot of stuff in this image, and the default, 5MB, is pretty tight. I usually start squeak with 16MB unless I've trimmed out many things. It's quite a change from the memory requirements des- cribed in the Byte balloon issue. ;-) -- Christopher Oliver, Traverse Internet, oliver(a)traverse.net We've secretly replaced their web server with Folgers Crystals. Let's see if they notice.

1 0

VM2.2 and 2.3beta unstable on Linux ?
by Han Holl 25 Dec '98

25 Dec '98

Hello, Id this just me, or is the VM on Linux (2.0.36, different machines, different X-servers) quite unstable. With the downloaded binary, I could send the VM in a closed loop by choosing the nextPage button in the Morphbook (one of the play-with-me's). I recompiled, and now nextPage works, but, for example, selecting '1 + abc' and doing it in the Workspace does not produce an error, but causes the VM to freeze. If I kill it via the WM button close, it gets in a closed loop. Playing around for a bit with the morph interface, is also almost guaranteed to get the VM in a closed loop. It would be nice if someone could confirm this behaviour, or maybe there is something wrong with my system(s). Linux-2.0.36, fresh, hardly updated, RedHat 5.2, with KDE desktop. (I tried different Xservers and WM's, but no difference there). Han Holl

3 5

Embedded Squeak 1.0 released for Squeak 2.2
by Paul Fernhout 24 Dec '98

24 Dec '98

Squeakers - Thanks to all those who replied to my earlier post (11/25/98) on Embedded Squeak, as well as those who wrote on this topic over the past two years. I've spent the past few weeks since then pondering the issues, on top of much earlier thinking/coding in the context of the stalled memory-constrained, GUI-constrained, debugger-constrained Squeak->Newton port, and after a weekend of coding (well, mostly de-coding and testing), here is: Embedded Squeak 1.0 for Squeak 2.2 downloadable at: http://www.kurtz-fernhout.com/squeak/ Some comments on it taken from part of the readme.txt file: The current version is built for Windows95, and features a text-only console in which you can type Smalltalk expressions. There is no image or changes file -- everything is in the EXE. Almost all the i/o primitives are stubbed out. This version of the code should compile/run on almost all platforms with minimal changes (you just need to know how to do character I/O). Main features: * subtracted: most VM i/o functionality (including file & GUI support & sound). * added: one Squeak method to write image as C memory array, and read that array at program startup. * added: EmbeddedSystem class to process serial i/o as console command lines. * added: C code to read image from memory array. Why would one want to use a stripped-down Squeak? * You might want to embed Squeak in other applications, devices like cellular phones, headless web servers, or even PDAs with native widgets (Pilot/Newton?). (Andrew Brault's Pocket Smalltalk is inspirational in this regard). * Embedded Squeak is preparation work for other things. Now one can work to create an image with just the compiler and various support classes, and build a totally new GUI / event system on top of the compiler core. One can also then come up with a package system to load packages onto this stripped down Squeak, to build up to the big Squeak. * Smalltalk novices can experiment with just the language for a day before jumping into the development/GUI system. Why would one want a Squeak with the image embedded in the EXE? * Using it is immediate gratification on ports to new hardware -- if you can get the console going (via serial), you at least have the compiler options set correctly. There is no need to mess with files or display drivers at the start. * Smalltalk novices may find it easier to get one self-contained EXE to run (even if they can't save and reload their image). * It could become an easily installed Perl/Python alternative. Things to do (and I'd be grateful for help): * create an expression to strip the GUI from the image and then save the image (maybe reducing the image to 200K?). * adding exceptions (so GUI isn't launched ever -- a top level handler reports to console). * optionally generating VM without bitblit, sound primitives, other stuff. * resolving why some ImageFileInMemory.c files don't load properly (probably related to state of image when saved). * a better command line interface, with macros, code filein format reader, and support for multi-line expressions * better backspace support * ports (especially to command-line-oriented DOS & UNIX). * Transcript redirection to the console * socket support for events to communicate with a headed Squeak to browse code and debug processes. I was originally going to do this at the VM level, but now I think it's OK (much easier) to do this in Squeak for a start. * support for pluggable I/O primitives and other dynamically loaded primitives * generating interp.c as a C++ class (for the Newton). * getting support for the "image embedding" code changes in the mainline Squeak distribution. Enjoy. This work is released under same terms as the Squeak license. If anyone can think of a catchy name for Embedded Squeak I'll consider renaming it. Right now I'm leaning to Squeak-e, for Squeak-embedded. But how about Squeakette? (ette = Elegant Technology To Embed or Embedded Technology Through Elegance) -Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of PlantStudio(TM) Botanical Illustration Software http://www.kurtz-fernhout.com

4 6

Re: primaryHand
by Leandro Caniglia 24 Dec '98

24 Dec '98

John wrote: >You're right! The "primaryHand" mechanism was a shortcut that was supposed >to have been replaced by "self world activeHand" as you describe. The fix >you propose is reasonable. John. Please note that the fix is OK in most cases but not enough in some situations. A deeper (and not very difficult) patch is to make ScrollPane|yellowButtonActiviy: receive the MorphicEvent <evt> as argument instead of the Boolean <evt shiftKeyState>. The only cases were you have not the event are tricky since ScrollPane|#shiftedYellowButtonActivity and ScrollPane|#unshiftedYellowButtonActivity are used to handle the menu item with label 'more...'. The right way to handle the 'more...' label in menus is found in PluggableTextMorph|#scrollBarMenuButtonPressed:, were the Boolean is supplied to #getMenu: and the <menu popUpAt: event cursorPoint event: event> is used. I think that #shiftedYellowButtonActivity and #unshiftedYellowButtonActivity should be removed from the system (I could try to do this if you agree). Leandro

1 0

Re: primaryHand
by Leandro Caniglia 24 Dec '98

24 Dec '98

Les wrote: >The big problem is that the consumers of the events generated by the hands >are not getting information about which hand generated the event. So, >the primaryHand appears to be a hack to get around this for awhile until >the whole thing gets patched up. This would probably only happen in >a fairly major cleanup of Morphic, which I think would be a good project >for someone. I think that the situation is not so critical right now taking into account that 18 classes use #primaryHand in 2.2. The problem may grow if we fail to solve it in time. Leandro

1 0

Re: [Q] Integrate my C-Code("Large One") with Squeak
by johnm＠wdi.disney.com 24 Dec '98

24 Dec '98

"Chun, Sungjin" <ninja(a)aerohel.snu.ac.kr> wrote: > I want to use my optimization code in Sqeak but the problem > is that it is written in C Language. It is big code almost > 20000 lines and I cannot convert them into Smalltalk. > Is there any way or resource on this kind of integration ? > I really want to do this in Sqeak. There is no "C-to-Smalltalk" translator that I know of. However, the 2.3 release will allow you to more easily link to external C code that is prepared as a shared library. If you really want to translate your code into Squeak, I think you'll have to either re-code it by hand or write a program to do that for you. If you write a program to do it, please let us know. I think many people would be interested. -- John

2 1

re: yet still more about that problem with sockets
by Craig Latta 24 Dec '98

24 Dec '98

Hi John-- (I hope you don't mind if I also send this message to the Squeak list. It seems like something of interest to some others.) > Do you recall where you read [that Mac OS X will not support MacTCP]? Yes; at http://developer.apple.com/macos/opentransport. About a third of the way down, on the right, it says "Mac OS X will support Open Transport APIs (but not 'classic' AppleTalk or MacTCP)." > When is OS X due to come out, anyway? According to http://developer.apple.com/macosx, "Apple's new advanced version of the Mac OS will be available to developers in early 1999 and ship in the Fall of 1999." > One question: Is your socket package a complete replacement for the one in > Squeak (i.e., all new primitives based on Berkeley sockets)? Yes. Actually, I wrote it before you mentioned you were doing one. Unfortunately, I wasn't at liberty to mention mine at the time. > If so, it might make sense to make it available as a Squeak "plugin" that we could try > out for a while before deciding if it should replace Squeak's current socket interface. > ... > At the moment, I'm basically planning to just fix the accept() semantics so > we can handle back-to-back connection requests and leave everything else > alone. That sounds reasonable, especially since the current interface has people using it (and we can do plugins now :). > Except for the problem with accept() (ha!), I don't have any problems with > Squeak's current socket interface. I can see why someone familiar with > the Berkeley sockets API would prefer it, of course. I have no particular attachment to the Berkeley interface (despite graduating from the institution from which it takes its name :). Indeed, I'm often tempted to dispense with using a C library for sockets altogether, and write the whole thing in Smalltalk (this was actually on my to-do list at one point in my previous project, when we had no sockets library for our weird hardware). I think the main benefit is that host libraries for it are widespread, so using it enhances portability in the meantime. However, as I mentioned before, I do prefer the way I factored the Smalltalk part. I prefer to keep external resources like sockets separate from the protocols which are conducted over them. My framework has "net correspondents" which use streams, and "net streams" which get their elements from external resources (not just sockets, but serial lines, files, MIDI instruments, etc.). I think it makes writing all clients and servers easier, but particularly those which make use of the added flexibility (eg., a network file system). Someone using the framework usually thinks about protocols, occasionally about streams, and almost never about sockets. I also prefer they way I handled a few other things like process synchronization. Ripping it out of our system (which forked from Squeak 1.13) is an interesting archaeological exercise. :) Back to it... -C -- Craig Latta composer and computer scientist craig.latta(a)netjam.org www.netjam.org latta(a)interval.com Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

Re: VM2.2 and 2.3beta unstable on Linux ?
by johnm＠wdi.disney.com 23 Dec '98

23 Dec '98

Han Holl <han.holl(a)pobox.com> wrote: > With the downloaded binary, I could send the VM in a closed loop > by choosing the nextPage button in the Morphbook (one of the > play-with-me's). This is almost certainly a problem with sound on your machine. You can turn off sound by setting the "disableSound" preference to true. The other problems sound like Linux-specific bugs. -- John

2 1

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

Jump to page: