Squeak-dev August 2000

squeak-dev@lists.squeakfoundation.org

130 participants
418 discussions

Re: Time Problems with Squeak 2.8 alpha for Windows
by Bob Arning 01 Aug '00

01 Aug '00

On Tue, 1 Aug 2000 12:53:25 -0400 "Jochen F. Rick" <nadja(a)cc.gatech.edu> wrote: >| date | >date _ Date today. >(date = (Date halt fromString: (date dayOfMonth asString, '/', date monthIndex >asString, '/', date year asString))) inspect. > >I had someone report that this caused problems with Squeak2.8 alpha on >Windows. Why is that? Did fromString: get changed? If so, what is the >recommended way to deal with a string of the form dd/mm/yyyy? Je77, This happened in change set 2327DateTimeRefac-bp which substituted a julian date implementation strategy. The comments of the relevant methods are a bit at odds: fromString: aString "Answer an instance of created from a string with format DD.MM.YYYY." ^self readFrom: (ReadStream on: aString). readFrom: aStream "Read a Date from the stream in any of the forms: <day> <monthName> <year> (5 April 1982; 5-APR-82) <monthName> <day> <year> (April 5, 1982) <monthNumber> <day> <year> (4/5/82)" Since getting agreement on the _right_ way to write dates could take forever, one could use a variant of the previous version of the method: fromStringDayFirst: aString "Answer an instance of created from a string with format DD.MM.YYYY." | fields | fields := aString findTokens: './'. ^self newDay: (fields at: 1) asNumber month: (fields at: 2) asNumber year: (fields at: 3) asNumber At least then we know what the sender expects. Cheers, Bob

1 0

Time Problems with Squeak 2.8 alpha for Windows
by Jochen F. Rick 01 Aug '00

01 Aug '00

| date | date _ Date today. (date = (Date fromString: (date dayOfMonth asString, '/', date monthIndex asString, '/', date year asString))) inspect. I had someone report that this caused problems with Squeak2.8 alpha on Windows. Why is that? Did fromString: get changed? If so, what is the recommended way to deal with a string of the form dd/mm/yyyy? Peace and Luck! Je77

1 0

Re: slimming the image
by Lex Spoon 01 Aug '00

01 Aug '00

A counter-example is Emacs. Emacs has *tons* of code available for it, and yet it all tends to work nicely together with any subset of the modules loaded. And Emacs doesn't even have namespaces! It's all done by hand. I don't know why it works out, but it certainly does, somehow or another. It's at least *possible*. -Lex Paul Fernhout <pdfernhout(a)kurtz-fernhout.com> wrote: > Dan Ingalls wrote: > >> [Mention of difficulties slimming image] > > People will tell you this is the problem with the unified image approach, > > but I disagree. The problem is simply that we haven't drawn appropriate > > lines between the various parts of the system, so when you cut one out, > > you're left with dangling dependences. > > The deeper issue is management of complexity. In a Smalltalk sense, it > is that a "module" providing a certain functionality typically consists > of multiple classes that need to cooperate to get things done (thus a > Smalltalk class really isn't a "module" in any meaningful sense). > > Of course this is made worse by the fact that subclassing or copying a > whole bunch of classes in Smalltalk is a lot of work, so it is easier to > patch new functionality directly into the old classes as a practical > matter, as was done with the C code generation stuff added to the parser > classes. > > One can manage complexity by hand in Smalltalk (being very careful about > how modules are created). You can do it in assembler or C by hand as > well. Modula or modern Lisps or even Delphi Pascal at least address this > issue somewhat by having modules or units providing some sort of defined > functionality and having defines interfaces. One can also do somethign > like this by using something like ENVY (with its application and the > extension concepts). > > But in practice it is very hard to do it in Smalltalk by hand when a lot > of developers are working together -- see my "SystemDictionary>>version" > post where I cite: > SystemDictionary>>version > "Answer the version of this release." > ^ EToySystem version , ' of ' , EToySystem versionDate > > The issues were put very eloquently by Les Tyrrell and others (esp. in > his > Re: Belling the cat of complexity (was: Ship it with Squeak) > Resent-Date: 30 Jun 2000 23:20:05 -0000) > As long as a monolithic big image is what people download and what is > supported as part of the mainline, testing for a shippable app is a > nightmare, because a pruned image is a new (untested) image and has to > be retested. Building up from a solid core is the only realistic path to > reliability. > > I feel strongly on this complexity management issue -- enough to start > wondering whether it would be better for my own efforts to pick another > cross-platform solution that has a stable core (MzScheme?) and add on > Squeak like functionality. I guess "SystemDictionary>>version" is making > me despair at realizing how deep the Squeak complexity problem has > grown. Squeak has lots of great ideas and great work, but it's the > "building your house on sand" concept. If you want your house to stand, > either move it onto rocks or put in deep piles underneath. Either is a > lot of work. It's easier to just add on to a house someone else already > built on a rock. > > I understand the value to SqueakC to have everyone banging on the big > image SqueakC uses its own work. But I think in the end you and many > other Squeakers would be better served by having a slim image as the > mainline system, with everything possible (including Morphic) being > loaded as needed. A convenience kitchen sink image is OK; just always > build it from the slim core for each release. > > (And ideally that core image should be built via the ANSI declarative > approach but that is another rant.) > > > I think that real value would come from declaring this as a project, > > with a goal of having maybe 20 discardX methods that really worked > > and that wouldn't get out of date in the next month. > > I just can't see this really being a good solution. It will get out of > date immediately in a new release and produce lots of difficult to > maintain code. This is because every remove method will have to be > written by an expert (or someone becoming one) on that subsystem (and > every other subsystem that uses it). > > -Paul Fernhout > Kurtz-Fernhout Software > ========================================================= > Developers of custom software and educational simulations > Creators of the Garden with Insight(TM) garden simulator > http://www.kurtz-fernhout.com

2 1

Status of Celeste attachments?
by mdr＠scn.org 01 Aug '00

01 Aug '00

What is the present status of Celeste attachements? As far as I can tell, the present Alpha release does not always encode attachments correctly (not all receivers can decode the attachements of Celeste originated messages). Daniel had made some changes to improve this, but my (incomplete) message archive is somewhat unclear if this worked. It would be nice to reach closure on this, ideally before 2.8 is more widely available! Mike

1 0

Newbie technical/cultural question
by Chris WRIGHT 01 Aug '00

01 Aug '00

I've admired Smalltalk from afar (like, from MacApp frameworks and Python) for a long while, and I've decided to take the plunge. I want to implement a BDI Agent framework (Belief/Desire/Intention) that will enable users to spit out PROMELA code (the process description language of the SPIN model checker) to verify certain properties of their agents / agent architecture. In the past, I've done this by writing a "little language" and an interpreter for the language. I'm not sure of the "right" way to do this in Smalltalk. I guess part of my question is "Is there a set of lexers/parsers that I can use (or subclass) to parse my little language - which mightn't look anything like Smalltalk?" or do I have to write my own? The second part of my question is "What's the ST way of dealing with little languages. Do you just build editors/inspectors instead?" Lastly (!) would you suggest that I start in MVC or Morphic? I don't know if I'll need all the clever Morphic stuff, and the MVC paradigm is appealing to me, but from what I read of the docs, the experts suggest that Morphic is the way to go.... Thanks for you help, and for Sqeak cheers Chris Dr. Chris Wright Deputy Director, Intensive Care Unit. Monash Medical Centre, VIC Australia

2 1

[SF][RFC] sqXWindow.c split into pieces - please comment
by David T. Lewis 01 Aug '00

01 Aug '00

Here is something I would like to take off the to-do list. I split the sqXWindow.c file (current version from SF) into three C files and a couple of new headers. If you are doing any work with sqXWindow.c, I would appreciate if you can take a quick look at this and let me know if it looks OK. If there are no objections, I will update SourceForge in a day or two. The files are: sqMain.c sqXWindow.c sqXWindow.h sqCopyImage.c sqCopyImage.h Dave p.s. Apologies to anyone who might be currently working on changes to sqXWindow.c. Having done this once, I can now redo this work if needed, although I would obviously like to avoid that if possible.

3 4

Re: [Q] Does anyone have a radix search trie Smalltalkimplementation?
by Rob Withers 01 Aug '00

01 Aug '00

Thank you Alan, I was starting to be a little concerned that no one was interested. :) Thanks for the huge pointer on where to go next. It definitly needs a speed up and better performance tests/monitors. We'll get better algorithms. What I am really interested in is the full unification in CLOS. It almost seems as if it is related to AOP. A single object may want to register for several events with different patterns. Since every object in the system can be considered a 1 arity tuple, we could get Object to understand match: and implement a doubleDispatch to locate special cases. You may want to register with an ad hoc match algorithm, however. VM and JIT support could go a long way on restricted class spaces. Since we have a oop fence with the vm event channel, we could possibly apply the idea of an 'Protocol class' which could help us find a restricted class implementation of the space structure and algorithms. Is this the path of least resistence? Could you tell us a little more about full unification in CLOS? cheers, Rob 8-) Alan Kay wrote: > > Rob -- > > Much work was done in the area of fast correlation of tuples with > event patterns for OPS5 at CMU and later, ART (automated reasoning > tool) at Inference Corp (spinoff from CMU, they used to be located in > LA). Most of this would work very well for Linda (whose pattern > matching is kind of a minimal subset of what ART could do). You > should find some great algorithms for this in the literature. ART, in > particular, was pretty fantastic at being able to have many thousands > of patterned watchers all looking at a big constantly changing tuple > space 1000s of times per second. Several really serious mainframe and > terminal systems (e.g. for American Express, a large airline, etc.) > were done in ART in the 1980s. > Much earlier (late 60s) Dave Fisher (CMU) and I independently > showed NLogN event expression catchers (like boolean expressions but > seeming to continuously and efficiently evaluate), some of whose > technology was later incorporated into the highly engineered OPS5 > (and then ART) stuff. > You could also look at how LINDA has been incorporated into CLOS > with full unification instead of just simple matching ... > I.e. a lot has been done in this area over the years. > > Cheers, > > Alan > > At 10:32 AM -0700 7/30/00, Rob Withers wrote: > >Or any abstract tree implementation. There's no sense in reinventing > >the wheel. Even better would be a Slang implementation. 8-) (drool) > > > >thanks, > >Rob > > > >-- > >-------------------------------------------------- > >Smalltalking by choice. Isn't it nice to have one! -- -------------------------------------------------- Smalltalking by choice. Isn't it nice to have one!

3 3

Re: [ENH] Alternative EventSensor
by Rob Withers 01 Aug '00

01 Aug '00

I'll combine several responses. Linda does the demuxing of events based on a pattern match. Each event from the EventSensor is an 8 arity Tuple with the first field signifying the event type. So we register: Sensor eventQueue whenMatch: (1 | Object | Object | ... | Object) "8 arity match tuple" send: #handleVMEvent: to: aMouseEventHandler We get callbacks for every event that matches that pattern. In the case of sockets, we could register for each socket by handle: (3 | 21 | ...) or we could do what Andreas pointed out: (3 | ...) and monitor all events for Sockets. Wouldn't it be nice to have an RPM gauge, or whatever skin you want. Perhaps you could show it by network interface too. I *love* watching the flashing lights! SystemMonitor startFull is cool, and I have no idea what to do with the information! ;-) I wasn't looking at the EventSensor as a UI thing, but I suppose it is. We could absolutely have several queues, perhaps with security or processing restrictions. I agree that it would be nice to register multiple queues, perhaps with a pattern to filter the right events. If you (y'all) look at the LindaEventProcessor, you will see that it uses a FixedSizeSharedPriorityQueue (just horrible isn't it?). The PriorityQueue is implemented using the Heap, so that's pretty fast. The sort block is: [:a :b | ((a respondsTo: #priority) and: [b respondsTo: #priority]) ifTrue: [a priority > b priority] ifFalse: [a hash < b hash]]. If we could ensure that all the event objects responded to priority, then we could simplify that. I was thinking that we could also adjust the priority of the Process based on this or on a registered priority for the handler. cheers, Rob John M McIntosh wrote: > > on 7/31/00 6:47 PM, Raab, Andreas at Andreas.Raab(a)disney.com wrote: > > > Ned wrote: > >> Maybe I'm missing something, but why would we want to combine > >> dissimilar events in the same queue (sockets/input/serial?)? > > > > Good question ;-) > > > >> Wouldn't that require the queue reading process to know about > >> each event type, or to pick through the queue for the next event of a > >> particular type? > > > > The big question is who is really interested in these events?! The current > > design of events is more or less exclusively for user input events which go > > to some UI element. It *could* make sense to have socket/serial events go to > > UI elements as well but in most cases the UI probably isn't interested in > > all these things. It might, on the other hand, be interesting to allow for a > > set of listeners which could give you some global information (such as the > > number of connections currently open, the number of failed connection > > attempts etc) in which case passing along these events might be the easiest > > way of getting the information. > > > >> Is there some advantage to a single queue, or is it just > >> because it's easier? > > > > It's actually harder to do it from the VM level (although I'm not quite sure > > that's really what we're talking about here). It would be much simpler to > > generate these kinds of events directly from Socket (e.g., on the ST side) > > and pass it on to the top level input queue (managed by Sensor/Hand). > > Have we thought about having different queues? And then having different > handlers run at a different priorities so we could have say high, low , > normal event dispatching. This would separate out mixing events in the a > single queue. Of course making it easy to allow a person to define a queue > and dictate how events should be dispatch might be interesting. Something > about priorities of interrupts come to mind, should for example a serial > input event wait behind the dispatching of 10 keyboard events? > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > Custom Macintosh programming & various Smalltalk dialects > PGP Key: DSS/Diff/46FC3BE6 > Fingerprint=B22F 7D67 92B7 5D52 72D7 E94A EE69 2D21 46FC 3BE6 > =========================================================================== -- -------------------------------------------------- Smalltalking by choice. Isn't it nice to have one!

1 0

Re: [UNIX][ALPHA][NET] When to tap the r/w sems?
by Lex Spoon 01 Aug '00

01 Aug '00

Rob Withers <slosher2(a)home.com> wrote: > Lex Spoon wrote: > > > > It seems reasonable to me to tap when there is a *change* in the read or > > write flag. In fact, if the image sockets code is modified to drain > > semaphores instead of just reading one signal at a time, then we could > > completely stop checking whether we think the image is watching or not, > > and just signal any events that someone in the image might be interested > > in. > > Right on. In that scenario, I think we would only have one Semaphore in > the platform socket code to serialize the interaction of the socket > commands (create, listen, accept, connect, close, shutdown, read, write) > and the async handlers. If we link into Tims's event code and buffer in > the socket code (performance), then we could wait on an image semaphore > (for that socket), perhaps with a timeout, and upon a signal from the > arrival of an event, we would check socket state or read data. There > could also be a write buffer in the platform socket code, so it should > be thread safe. I didn't follow all this, but it sounds pretty cool. Certainly socket events could go through a global event stream. Also certainly, they don't have to, and things are okay as they are. Either way seems okay. > > I am not sure I am following you on the change in flags. In fact, if we > make the sockets eventful, then we would always send an event when > anything happens (connect, read, write, exception). select() tells you whether a socket is read-able or not, but it doesn't tell you when it *becomes* readable. So you have to watch for a transition from unreadable to readable. The image will only see events, but the VM authors have to actually manufacture those events. > > > In Unix, this would suggest that dataHandler and friends be given seven > > arguments: > > > > the fd > > the current read, write, and exceptions flags > > the previous read, write, and exceptions flags > > > > The data handlers can then signal the relevant semaphore whenever read > > or write goes from 0 to 1. > > > This approach *does* require some slight trickery in order to make the > > select() wait properly: do one select to wait for stuff to happen, and > > then do another select() to update all three flags for all open sockets. > > (Note you can't ask select() to watch for a flag changing from 1 to 0). > > I am confused about this. The tapFlags in the current code are to > inform the async handlers of intent. If the intent flags get set in the > sendDone or dataAvailable primitives, then the client is going to wait > on the semaphore, so tap on it. The scenario you painted with the read, > write, and excpetion flags sound like the FD flags for select. I am not > entirely sure about the select() call but isn't it known when the select > occurs that whatever the current flags are set, is the event that > occu Keeping track of whether someone is watching for read events seems a little complicated. Furthermore, it still sends events that get ignored: for example, I've written a good bit of network code that does call sendDone but which doesn't use waitForSendDone:. This code doesn't wait on the semaphore until it closes the socket down. So I propose, just signal every event, and if no one is interested, they can just ignore them. The image code should then be updated to deal with a slew of identical events arriving in a row. -Lex

2 1

Re: 4th Estate server (roarr.com) - gone
by Roel Wuyts 01 Aug '00

01 Aug '00

Do you need a server to put them on ? Since we are already serving Smalltalk User Group related sites, we could take one more :) > Fellow Squeakers: > > As a few of you have noted offline, the 4th Estate ftp > server where we stored our Squeak contributions for > download is no longer there. That is because, quite > literally, it is no longer there, and we don't > expect it to come back. > > The projects will be reappearing shortly, although > exactly when/where is still unclear. Please feel free > to contact me offline and I will be happy to discuss > the status of each. All of them require some clean-up > before any but the most cussed and determined > Squeakers will want to try to install them (see > previous discussions on this list). That clean-up is > in progress. > > The projects are: > > - port of T-Gen to Squeak > - a project related to platform events (as yet > nameless) > - a versioning doo-dah, which you may have heard > referred to as > "Roarr" > - a platform level messaging channel (nameless? - I > forget) > > I will post updates as these projects become available > for download. Please note that while the code is open > source under the Squeak license, the name "Roarr" is a > trademark of 4th Estate, and that project when it > reappears will be known as "Tefkar". Well, why not > "Tefkar"? > > On behalf of the ex-4th Estate Squeakers, > Paul > > wnchips(a)home.com > > __________________________________________________ > Do You Yahoo!? > Kick off your party with Yahoo! Invites. > http://invites.yahoo.com/ > -- Roel Wuyts Programming Technology Lab rwuyts(a)vub.ac.be Vrije Universiteit Brussel http://prog.vub.ac.be/~rwuyts Webmaster of European Smalltalk User Group: www.esug.org

1 0

Jump to page: