Squeak-dev January 1999

squeak-dev@lists.squeakfoundation.org

143 participants
293 discussions

Re: Squeak: Events, Modularity, Exceptions
by R. A. Harmon 02 Jan '99

02 Jan '99

At 05:15 PM 1/1/99 -0500, Paul Fernhout wrote: [snip] >In my opinion the issues of events, modularity, and exceptions are the >leaky plumbing that needs to be addressed to make Squeak a great >programming system (beyond merely good). I'll even go further: these >need to be addressed (and soon) if Squeak is to grow and prosper. They >need to be addressed to make Squeak ready for prime-time limelight -- >into which it seems (ready or not) about to head. [snip] >Exception handling allows one to more easily remove GUI dependence. It >also is becoming accepted practice. [snip] I've sent my implementation of the ANSI Exception protocols to a half a dozen folks to try out but haven't received any comments on it back from them yet. I had no experience with exceptions until I implemented them so I don't know whether my implementation is a useful starting point or junk. I wanted to finish the ANSI Numeric protocol (now done) and give the folks I sent my exception stuff to a chance to try it out. I'll check back with them and if they think my exceptions stuff is usable, I'll send it on to Squeak Central in the hope they will incorporate into the base system. As I understand it a robust exception implementation requires VM support to properly handle returns (up arrow) in the protected and action blocks. I won't consider digging into Squeak internals to do this until after I have ported the remaining ANSI protocols, if at all. [snip] >Modularity allows one to deploy a Squeak system with the minimal >footprint (like with only text handling classes and a compiler). >Stripping out what you don't want is not good enough. One should have >precise control over building an image up from modules to get exactly >what you do want -- with every byte accounted for (and none accidentally >left over from ST-76). I think the declarative model, as I understand it from the description given in one of Allen Wirfs-Brock's documents at his web site, would address this issue. I planned on trying to implement it, but again only after I've finished the ANSI stuff. [snip] >Obviously, individuals have addressed these somewhat -- especially >exceptions (in different ways). I was sort of hoping we could finally get them addressed in a "standard" way. [snip] >We are all grateful for the fantastic job done by Squeak Central of >integrating contributions and creating ever greater versions of Squeak. I'll second that. >Still, in the interests of moving Squeak forward, it would be nice to >know if these core issues of events, modularity, and exceptions anywhere >on Squeak Central's priority list for the near future. > >If not, since these issues are so fundamental to the system, how could >these be addressed by others in such a way as to avoid splintering off >another development line of Squeak? I seems obvious (to me) that having >proper solutions for these in mainline Squeak would not detract one bit >from efforts at Disney to use Squeak in-house (except in the sense of >time if they implemented them or merged them). Yet, every time I think >of coding up something to address any of these (or using someone else's >solution), I realize all that work is going to get left behind in a new >release, because it entails making many fundamental changes to the >system (sprinkled throughout the code). I have those same concerns. >At OOPSLA '97 it was brought up that there are two main Squeak camps. > >The first camp is people who want to experiment. [snip] >The other camp is made up of people who wants an open and stable >Smalltalk to do real business-like work (typically grungy, non >glamorous, often text-oriented and standard widget-oriented). It's not >necessarily that we wouldn't pay for Smalltalk, or don't have several >purchased copies on the shelf. It's more like we want to ship the >compiler, or we might want to change the VM in the future, or we want >the really small footprint Squeak offers, or any of several other >reasons (often related more to open source issues than money itself). Open source is my main reason for turning to Squeak. >Some people, like myself, are in both camps at various times. Perhaps >this is common. I'm in both camps. I am unwilling to port the same core code of lots of tools to new dialects. The tools make it easier to do grungy stuff and experimental stuff. I never know if a bug in a tool in one dialect (or a terrific enhancement) is fixed (added) in other ports. Maybe the ANSI standard will not prove to be all that advantageous in writing dialect portable applications, but I' inclined by my experience in other languages to put the work into it to find out. Doing this also keeps me out of pool halls and away from questionable influences. > Obviously, being able to justify Squeak use to >management for grungy apps (like processing text files) would get it in >the door for other fancier uses. Does this make sense at all? Perfect sense to me. >Is the second camp (or sentiment) present on this list to any extent? Am I the >only one out here thinking Squeak could become an acceptable scripting >language up there with Perl, TCL, and Python/TK? I would think many >people would adore feeding program/text files to Squeak which were >written in their favorite text editor (David Pennell brings this issue >up in a recent "Re: Squeak book" post). And if it is useful, how many times should this application be sliced, diced, and re-edited to get the same functionality in different dialects? [snip] >Alternatively, if someone was going to maintain another line of Squeak >(focusing on stability, minimal footprint, shrink-wrapping, events, >modularity, exceptions, compatability like all code using := assignment, >standard GUI widgets, etc.) would that do other than wither as the >current mainline Squeak forged ahead? Or would experimental Squeak work >reorganize around the stable version? Would people want to use such a >release (beginners, servers, embedders, business types)? Would >experimental Squeakers be comfortable pointing newbies to a separate >line of development? [snip] I have been wondering what to do after I've finished adding the ANSI stuff to Squeak. Do I stay with Squeak and hope the grungy apps camp stays interested and active, and those knowledgeable (and interested) enough to work on the VM don't move on to Java? Do I commit to a branch of Squeak that like old solders and SE never die, but just fade away? Or is Dolphin a better bet in the long run? Or is VWNC? Thanks for putting it so elegantly Paul. -- Richard A. Harmon "The only good zombie is a dead zombie" harmonra(a)webname.com E. G. McCarthy

1 0

Re: Dangling SystemWindow's in 2.3Beta
by SWallace 02 Jan '99

02 Jan '99

David, The five windows that are eluding you are all related to the default "standard parts bin". Squeak maintains a prototype of the parts bin in memory so that one can be quickly produced upon request via "veryDeepCopy" of this prototype. If you need to get rid of those SystemWindow instances for some reason, you can do so by evaluating: ScriptingSystem resetStandardPartsBin This will nil out the only reference to the parts-bin-prototype, so that after the next garbage collect you should find the SystemWindow objects gone. Of course, as soon as anyone subsequently requests a new parts bin, a fresh prototype will be created. (For those that may not have noticed, if you bring up a parts bin [via the "authoring tools" menu in a morphic project] and look through its pages, you'll come upon a page that offers a browser, a workspace, a file-browser, etc. If it suits your style to keep a parts bin up, you may find this to be a convenient way to launch such tools.) -- Scott At 5:19 PM -0800 1/1/99, Pennell's wrote: >Start with a virgin 2.3Beta. > >Close all of the windows. >Open a workspace. > >Smalltalk garbageCollect. >SystemWindow allInstances inspect. > >There are 5 SystemWindow's: >- System Browser >- Workspace >- BackStreet HD:Squeak 2.3 >- scripting area >- assembly window > >I've tried a lot of things over the last few hours to get them to go away. >If anybody figures it out - please let me know. > >I'm having a similar problem with my T-gen port and hope the problems >are related. > >-david

1 0

Are there any examples of 'connectors' around?
by Tom Morgan 02 Jan '99

02 Jan '99

I am plugging away on a grapher, and it is laying things out pretty good now. I figured I might as well let the layout be editable, by dragging the nodes around. That means keeping the arcs attached to the node as it moves. Are there any examples around of 'connectors'--lines which stay attached to their connectees, done in Morphic? ...Tom M -- +---Tom Morgan ------------------------------ (tmorgan(a)acm.org) -----+

2 1

Bug in ChangeList wrt LF or CRLF files
by Pennell's 02 Jan '99

02 Jan '99

ChangeList>>#scanFile:from:to: depends on records being terminated by CR. I first noticed it with the FileContentsBrowser in 2.3Beta. It finds classes but no methods. The attached changeset provides a simple fix. -david Content-Type: application/octet-stream; name="ChangeList-djp.1Janu827pm.cs" Content-Disposition: attachment; filename="ChangeList-djp.1Janu827pm.cs" Attachment converted: Anon:ChangeList-djp.1Janu827pm.cs (????/----) (00005C4A)

1 0

Re: Squeak book
by Pennell's 01 Jan '99

01 Jan '99

>>When teaching Cobol-people, I >>noticed that they'd severe problems with that select&action pattern of >>Smalltalk. They were keyboard-centric people. I've noticed that programmers accustomed to traditional language's and development environments (including the newer IDE's) have a very "source file centric" view. You show them how to write some code and it doesn't take long before they get nervous about where "their" code is. How do I save my source. Then you get to discuss "the" source file, "the" changes file, fileOut, changeset management and management of the whole process. The traditional development environments give you a nice safety blanket. When things go bump, you always have the ascii source to fall back to and start over with. The start over process is identical (or almost so) to the normal process... [notice the tie in to the earlier "project file vs makefile" thread...] >>>>The browser needs wizards to create classes and methods. >>>Nahhh... >>Never said that you must use them, but try to explain the funny effects >>that occur if you make some errors filling out the class creation pattern. >>Strange error messages or even system crashes because somebody just >>redefined Class upto recompilations of the whole system can occur. > >:)))... yeah, it's true... but I dunno. Maybe it's better to let such >errors happen because then when someone looks for the reason there's a lot to >learn by oneself. The enviroment should allow for exploration not require it. >>>Break points I don't know... maybe not. I guess they're most probably >>Well, just because I want to stop the execution, I don't want to modify a >>method and "polute" the change set. Amen! Has this been done in any of the other Smalltalk environments? >You know, it would be nice to use > >self trace soTheDebuggerOpensAndYouStartTracing > >instead of > >self halt failAndThenOpenTheDebuggerAndThenStartTracing Is there any reason not to do this? I almost always proceed to the debug window. >>All I want in Squeak is, that $ñ isLetter or $á isLetter or $ä isLowercase >>all answer true instead of false. >>As Western European, I'm happy with Squeak default font which >>resembles ISO Latin1 (I don't know), but I can hear the complains of >>Russians (not talking about people of Far and Near East) who demand their >>letters. Perhaps the best solution would be to switch to Unicode. With run-time support for Unicode, we could start with doing simple things like allowing Celeste to read this e-mail or extending Scamper to read the SUGAR Web pages or adding localized IDE's. This seems like a good pluggable primitive project. -david

2 1

Re: Squeak book
by Ralph Johnson 01 Jan '99

01 Jan '99

Breakpoints are not that hard to implement. Bob Hinkle did a version a few years back for VisualWorks. You can find the code in http://st-www.cs.uiuc.edu/ftp/pub/Smalltalk/st80_vw/Breakpoint20.st Bob's package not only lets you put a breakpoint anywhere, it lets you do it for a single object, so you can trap the send of add: to one particular OrderedCollection and not have it affect any others. There is a commercial breakpoint package that does something similar. I assume both packages work the same. Bob's package worked by recompiling the method with a "self halt" in it, but not changing the source. He let you put a breakpoint on a single object by using lightweight classes and giving an object with its own breakpoints its own class. I am sure that the details of how to do this will be different for Squeak, but the main idea should be the same. -Ralph

1 0

Re: SqueakOS
by johnm＠wdi.disney.com 01 Jan '99

01 Jan '99

Dwight Hughes <dwighth(a)ipa.net> wrote: > Also be sure to take a close look at the Flux OSKit version 0.96 just > released: > > http://www.cs.utah.edu/projects/flux/oskit/ > > You can create very small "kernels" with just the resources required and > wrapper code from other unixy OSs. Interesting! How portable is OSKit? I know that Compaq is running a stripped down Linux on their Itsy Palmtop prototype. I believe it uses about 4 MBytes, comparable the the stripped-down FreeBSD (PicoBSD) that David Pennell mentioned. Squeak doesn't need much from an OS: a display driver, a millisecond clock, and a pointing device driver are the minimum; everything else is optional including a file system and keyboard input. (Support for some sort of interrupt key or button is quite helpful.) I know of at least two bare-hardware Squeak ports. Writing drivers for the basic display and pointing devices is not too difficult. Adding support for a file system, sound output and input, and/or serial ports is also straightforward. The one thing I would be loathe to tackle is a TCP/IP protocol stack. So, for me, networking is the most compelling feature that these micro OS's offer. Unfortunately, just having a portable OS kernel may not be sufficient. The hardware details required to port the OS to a given device may not be published, or the existing OS may use a memory protection scheme that that makes it impossible to supplant it with a new OS. Still, I'd love to see more bare-machine Squeak ports, and I'd be happy to see Squeak ported to one of these micro OS kernels. -- John

4 3

Re: Squeak unstable on Linux ?
by johnm＠wdi.disney.com 01 Jan '99

01 Jan '99

michal starke <Michal.Starke(a)lettres.unige.ch> wrote: > > Playing around for a bit with the morph interface, is also almost > > guaranteed to get the VM in a closed loop. > > Is morphic running correctly on anyone's (intel) linux box [modulo sound] > or is this a generalised problem? > (I am considering a switch to linux but need to work on morhpic a lot...) Lex Spoon (lex(a)cc.gatech.edu) used Morphic on Linux all of last summer, and is probably still using it. You might ask him what version of Linux he's using. -- John

1 0

Re: Midi Time Codes
by johnm＠wdi.disney.com 01 Jan '99

01 Jan '99

"Steve Walker" <swalker(a)link.ca> wrote: > Does Squeak (either with or without Siren) currently support the use of > midi time codes for the synchronization of multiple midi devices? For > example, can Squeak accept a time code signal from a digital tape unit and > use that signal for synchronization ? Yes and no. Squeak has a MIDI input parser that accepts the full MIDI protocol including the "real time" commands. However, it doesn't have specific support for time codes; you would have write that yourself. Let me know if you do! You don't need Siren to read MIDI input, although you *will* need it if you want to route MIDI data into Squeak from some OMS-enabled MIDI application running on the same computer. Hope this helps. -- John

1 0

Re: Window code issue
by johnm＠wdi.disney.com 01 Jan '99

01 Jan '99

"Richard L. Peskin" <rlpcon(a)vermontel.net> wrote: > Thanks Andreas-- > Where do I find this specialized code? I have looked over the > sqMacWindows.c and the only thing I see (other than window creation and > event handling) is ioShowDisplay() which appears to do a PixMap to BitMap > conversion, followed by a CopyBits(). Should I be looking elsewhere as well? I think Tim and Andreas pretty much answered this question, but just in case... You can find the latest Win32 VM sources at: ftp.cs.uni-magdeburg.de /pub/Smalltalk/free/squeak The sources are also be mirrored at squeak.cs.uiuc.edu /pub/Smalltalk/Squeak The code you want is in the file sqWin32Windows.c. For those folks interested in VM design issues, here are the arguments in favor of the current Display design, which is to have the Display object be a buffer owned by Squeak, as opposed to a direct pointer to the hardware display buffer. (But note that the latter design has also been explored in at least one Squeak port, and required only a few modifications. Tim pointed out the hook in the release VM to support it.) 1. The current design is extremely portable. 2. Keeping thes ame byte order is the on all platforms, allows folks to write very efficient platform-independent image processing code that doesn't need to take two byte orderings into account. This code can be translated into C to make it really fast. I've done some experiments with cross-fade primitives that were easy to build and really rip! 3. Morphic uses the Squeak Display as an "offscreen buffer" to get smooth, double-buffered display updates. Give that one wants double-buffered display updates, the current design doesn't cost anything extra because you'd need an offscreen buffer anyhow. 4. Copying pixels from the Squeak Display to the actual hardware display buffer takes, typically, well under ten percent of the overall display update time. Thus, having Squeak write into the hardware screen buffer directly could only speed things up a little, and that would be at the cost of portability and giving up double-buffering. 5. There is definitely a cost associated with byte-reversal on little-endian machines. Yet the Andreas's in-place byte reversal is surprisingly fast, and that's the worst case. In many cases one can arrange to swap the bytes on the fly as the data is copied to the hardware display buffer, making the byte-reversal practically free. I hope that you get to the bottom of the BeOS performance problem. Please keep us posted. -- John

1 0

Jump to page: