Squeak-dev February 2002

squeak-dev@lists.squeakfoundation.org

202 participants
665 discussions

[updates] five for 3.3a
by Scott Wallace 01 Feb '02

01 Feb '02

The following five updates have now been posted to the public servers for 3.3a. -- Scott ----------- 4731GraphicsTwkFix-tk -- Ted Kaehler -- 31 January 2002 Fix two bugs in Andreas' 4640GraphicsTweaks-ar. SyntaxUpdatingStringMorph>>drawOn: computes a font (f), and then does not use it in the loop (fails when font is nil). If Morph>>insetColor asks owner for colorForInsets, which asks *its* owner for a color. One too many layers of owner are asked. And a fix of mine. 4732HandRedrawFix -- Andreas Raab -- 1 February 2002 A fix for incremental updates in HandMorph. 4733firstModuleFixes-hg -- Henrik Gedenryd -- 31 January 2002 Some quick fixes to make module unloading work better. Moving some classes that were sent to the wrong places due to bad category strings. 4734nameForRef-sw -- Scott Wallace -- 1 February 2002 Fixes a bug recently introduced into Object.uniqueNameForReference; thanks to Bob Arning for zeroing in on this. 4735prefDirRefix-mir -- Michael Rueger -- 1 February 2002 Change set 4668ServerCode-fixes-hg reinstalled an old version which forced the creation of a prefs folder on startup. This reverts to the correct version again.

1 0

A Scheme interpreter for Squeak
by Bergel Alexandre 01 Feb '02

01 Feb '02

could be found on : http://www.iam.unibe.ch/~bergel/Scheme/scheme.html Do not hesitate to send me some feedback... Regards, Alexandre

2 4

[Modules][Vote][ShamelessPlug] Big chunks?
by goran.hultgren＠bluefish.se 01 Feb '02

01 Feb '02

Answer the poll about the Modules question below at: http://marvin.bluefish.se:8080/squeakdot :-) :-) :-) Fun and useful! regards, Göran PS. Please propose useful features for the voting mechanism. DS Henrik Gedenryd <h.gedenryd(a)open.ac.uk> wrote: > Moving this to the main list... > > Dan Ingalls wrote: > > ducasse <ducasse(a)iam.unibe.ch> wrote... > >> I think that Celeste is "well" separated from the core so this could be > >> interesting to try. > > > > Hi Stef - > > > > I've been reflecting more on this since responding to your message. I > > completely defer to you and Henrik on which way to go, but I see a choice > > here: > > > > Either we... > > Find various small things that are pretty modular and do them first > > > > Or we... > > Take various big chunks that are pretty modular and do them first.

3 2

[FIX] via source forge updates
by John M McIntosh 01 Feb '02

01 Feb '02

Tim fled to his cabin in the mountains and asked me to update source forge with some changes after I verified they worked ok on the mac. Beyond posting the changes for 3.2.2 Mac mach-o VM, excluding the FFI plugin which I'll do later today, the changes are: cross/sq.h A typedef for long long int to make acorn users happy, actually acorn users get long int (32bit) since the compiler doesn't support long long (64bits). cross/sqFilePluginBasicPrims.c Revert back to pure ansi, overrides are now done in platform specific header for 64 bit file io, and for ftruncate support (#define sqFTruncate to something). For 64bit file io: a) Your platform compiler must support long long int, pointless otherwise. b) you must typedef squeakFileOffsetType to the 64bit file offset type (possibly off_t, but you need to verify the number of bits, some u**x environments are broken) fseek to the 64bit fseeko? ftell to the 64bit ftello? unix/sqPlatformSpecific.h include <unistd.h> for ftruncate enable 64bit io per notes above However you need to comfirm the 64bit file io stuff really works even if it compiles. -- -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

3 4

Separate call stacks [DOC] Call/CC
by Anthony Hannan 01 Feb '02

01 Feb '02

Scott A Crosby <crosby(a)qwes.math.cmu.edu> wrote: > Nominally a callCC style continuation is a single unit. This would > indicate that, for example, the code is misarchitected. You might be able > to avoid it, for example, by always spawning doIts in a different (clean) > process, then have some special magic that suspends the UI process > until that one finishes (or errors). I've made this easy in the BC version. Just send #run to a block and it will run in its own process while suspending the calling process. The calling process resumes once the block returns or is terminated like when you quit its debugger. If the UI process is suspended while the debugger pops up, another UI process will be created to interact with it, but this UI process will be terminated once the previously suspended UI process is resumed (like in the current version).

1 0

Re: [FIX] via source forge updates
by Lex Spoon 01 Feb '02

01 Feb '02

> Actually _that_ change is in Cross/sqVirtualMachine.h and really, really > needs a nicer way of specifying the choice. Meta programming of the C > compiler would be nice here; can I do anything like > #if sizeof(sqeakFileOffsetType) == 4 > #define squeakInt64 long long > #else > #define squeakInt64 long int > #endif > ?? > I actually tried that with no success :-( but there really must be some > way to do it. A crucial point is that it must be ansi spec, not ISO or > 'it works ok in gcc'. Why is ansi important? Ask me once you've tried > doing ports to minimal systems with just an ansilibrary and monitor. > How about if this file includes sqPlatformSpecific.h ? Or if that's a problem (I don't really grok what the role of all these different header files is), how about we split out a sqTypes.h file with types such as this one? -Lex

2 1

RE: [DOC] Call/CC Re: [Q][Goodie] continuations (was: RE: Tail Call)
by Withers, Robert 01 Feb '02

01 Feb '02

Awesome, Scott, although I am still struggling to get my mind contraverted around/inside/between the concepts. I appreciate the scheduling examples. What about exceptions/handlers? I will have to get back to this on the weekend. Real job to do in the meantime, you know... thanks, Rob > -----Original Message----- > From: Scott A Crosby [mailto:crosby@qwes.math.cmu.edu] > Sent: Friday, February 01, 2002 12:16 PM > To: Withers, Robert > Cc: 'squeak-dev(a)lists.squeakfoundation.org' > Subject: [DOC] Call/CC Re: [Q][Goodie] continuations (was: RE: Tail > Call) > > > On Fri, 1 Feb 2002, Withers, Robert wrote: > > > Hi Bijan and all, > > > > That is a very good analogy, to me, at least at the design > level. However, > > it's application is confusing, to say the least, especially when you > > consider it's implications in the squeak environment. I > have a great need > > to understand it, however, because 'E' uses them to resolve > the promises > > that are created from an eventual send. Eventual send > semantics are my next > > little project (and I don't mean to just talk about it). > > > > Ok. In the case of a CPS style execution environment, the > continuations > are all explicit arguments.. But, since the real squeak runtime uses a > stack to represent the continuation thats implicit as the return > continuation... Normally, in most languages, you can never 'get your > hands on it'. Call/CC (which means 'call with current > continuation' is > a way that gets your hands on that continuation.. > > Conceptually, CallCC should return a block that, when > #value:, immediatly > jumps back to the continuation. That invocation will not return [*] > > foo > ^(self callCC: [:continuation | self bar: continuation]) +10 > > bar: continuation > continuation value: 15 > ^16 > > > > You invoke foo, which passes a continuation of '{}+10' into > the block, > which gets passed to bar, which, when it invokes it, > immediatly jumps back > to the {}+10, which jumps back to foo which adds 10 which is then > returned. > > How about something like: > > Processor class>>yield: > self callCC: [:cont | newCont _ self suspendedCont. > self suspendedCont: cont. > newCont value: nil] > > Which allows cooperative multithreading! Each time you invoke > it, copies > the old saved continuation thats in an instance variable, > then saves the > current one, then 'restarts' the first by invoking it with > 'nil'! Now, if > you had a queue there, or a heap.. Multipriority cooperative > multithreading. :) > > -- > > Now, in implementation terms in something like squeak, thats > quite a bit > uglier, because you can't take a stack of methodcontexts and > pretend its > an anonymous block that takes a single argument. Ergo, to get > it, you do > things like clone the entire methodcontext stack. > > In the other examples we've given, we're not trying to access > that 'system > level' implicit continuation. We're making explicit continuations > ourselves as blocks we pass them explicitly as arguments. > Thats why those > examples differ from callCC. > > > I have attached a continuation (call/cc) changeset, that > came from Vassily > > Bykov. I do hope he doesn't mind me reposting it. It is for a > > non-BlockClosure image. I have been comparing it's > implementation of > > continuations, with that of Boris' BlockClosure test case. > They are very > > different, I think, since Vassily's Continuation class has a > > #captureSenderChain method where the entire stack is copied > for later > > restore and proceed, as you discuss. Boris' continuation, > on the other > > hand, seems to be just the BlockClosure he passes as the > continuation block. > > > > It is my feeling that an 'absolute' continuation (my term), > like Vassily's > > Continuation, which captures the entire sender chain, may > not be appropriate > > in the Squeak UI environment. When I highlight the example: > > #testAccumulator and doIt, followed by activating the > Continuation, the > > Continuation stack includes those methods which processes > the event loop and > > sent the mouse event to ultimately evaluate the doIt. I > don't think these > > things should be in the continuation stack. Does it make > sense for the user > > to be able to control how much stack is closed over? > > Nominally a callCC style continuation is a single unit. This would > indicate that, for example, the code is misarchitected. You > might be able > to avoid it, for example, by always spawning doIts in a > different (clean) > process, then have some special magic that suspends the UI process > until that one finishes (or errors). > > [*] There's some funky subtletly there. Invokign the current > continuation > never returns, because, nominally, the toplevel never > returns... But, you > can implement things like [fork] as: > > fork: aBlock > self callCC: [:cont | > self suspendedCont: > [ :unused | aBlock value: true] cont. > cont value: false] > > exit: > self callCC: [:cont | > self suspendedCont value: nil] > > > Basically, take the current continuation, add it to the suspended > context's queue, then continue the continuation you were passed, > continuting it with either true or false, depending on which child you > are. :) Now for this to actually work, you'll need the > current process to > #yield as above to allow the fork. > > And exit just throws away the current continuation, and loads > and restarts > one of the saved ones. > > Continuations this way can be mind-blowing. :) I'm half > reconstructing > all of this stuff on the fly. Its great! :) I've not gotten > this deep in a > while. > > > > Finally, could somebody explain what call/cc semantics are > and how that > > differs from a continuation? > > > > If you have any other questions, Post away. > > Scott > >

2 2

[Q][Goodie] continuations (was: RE: Tail Call)
by Withers, Robert 01 Feb '02

01 Feb '02

Hi Bijan and all, That is a very good analogy, to me, at least at the design level. However, it's application is confusing, to say the least, especially when you consider it's implications in the squeak environment. I have a great need to understand it, however, because 'E' uses them to resolve the promises that are created from an eventual send. Eventual send semantics are my next little project (and I don't mean to just talk about it). I have attached a continuation (call/cc) changeset, that came from Vassily Bykov. I do hope he doesn't mind me reposting it. It is for a non-BlockClosure image. I have been comparing it's implementation of continuations, with that of Boris' BlockClosure test case. They are very different, I think, since Vassily's Continuation class has a #captureSenderChain method where the entire stack is copied for later restore and proceed, as you discuss. Boris' continuation, on the other hand, seems to be just the BlockClosure he passes as the continuation block. It is my feeling that an 'absolute' continuation (my term), like Vassily's Continuation, which captures the entire sender chain, may not be appropriate in the Squeak UI environment. When I highlight the example: #testAccumulator and doIt, followed by activating the Continuation, the Continuation stack includes those methods which processes the event loop and sent the mouse event to ultimately evaluate the doIt. I don't think these things should be in the continuation stack. Does it make sense for the user to be able to control how much stack is closed over? Finally, could somebody explain what call/cc semantics are and how that differs from a continuation? cheers, Rob > -----Original Message----- > From: Bijan Parsia [mailto:bparsia@email.unc.edu] > Sent: Friday, February 01, 2002 9:24 AM > To: squeak-dev(a)lists.squeakfoundation.org > Subject: Re: Tail Call > > > On Fri, 1 Feb 2002, Jerzy Karczmarczuk wrote: > > > Anthony Hannan: > > > > > > > Is tail recursion required for continuations? I really > don't understand > > > continuations, can you give me some pointers? > > > > Scott Crosby says: > > > > > Tail recursion is not needed for continuations. You only > need closures, > > > but without tail recursions, continuations-style > programming can overflow > > > the stack much easier. > [snip] > > > I would be more categorical and I would say YES. Otherwise > there is no point > > whatsoever in speaking about them. They are functional > models of "goto". > > I won't argue with Scott, just tell a few more words from a > different > > perspective. > [snip] > > I'd still say "no". You don't need tail call optimization (TCO) to > implement have explicit continuations. And you don't need TCO to use > explicit, full, resumable continuations to use them to > implement a variety > of control flow structures (exceptions, for example), and > even have that > be somewhat practical. You do need them for general practical use of > Continuation Passing Style (CPS), and I agree that CPS is the > best reason > to want them (in general, you're prolly better off implementing your > control flow with a less general mechanism). > > Let me add a more informal, sloganny account of > continuations: continuations are "dynamic" closures. That is, just as > closures "close over" the lexical environment, continuations "close > over" the *invoking* environment (the analogy is with dynamic > scoping of > variables). By "freezing" a copy of the calling stack, continuations > let you "continue" the compuation from that point any number of > times. (Sorta like snapshotting the image after a debugger popped > up. No matter what you do after that, you can always roll back to > that snapshotted moment and "continue" in a different (or the the > same!) way.) > > Making fully resumable, indefinite extent, multiply invokable > closures or continuations available to the host language is, > in general, > more heavyweight than alternatives (at least for the implementer). But > when you need them, you need them. > > (Note that a snapshot saves a lot more than the current > continuation :)) > > Cheers, > Bijan Parsia. > >

2 1

Re: ModuleStorageTests all error out
by Henrik Gedenryd 01 Feb '02

01 Feb '02

Ned Konz wrote: > Image version 4689. > > I tried running the ModuleStorageTests, and all of them error out: > 47 run, 0 passed, 0 failed, 47 errors > > Is there some initialization that is required but not being done? > I explicitly tried this after updating and it all went fine for me. Does anyone else see this? A Mac/Win issue perhaps? Henrik

4 3

Re: Persistence & DTSTTCPW: ZODB clone?
by John Hinsley 01 Feb '02

01 Feb '02

Cees de Groot wrote: //big snip// > Would that sound like something useful for Squeak? It has its limitations, for > sure, but it seems like the simplest way to get a solid persistence engine > into Squeak, which is a Good Thing I think. It's also a project I'd like to > tackle... Oh _please!_ Put that together with something like Comanche or Seaside and (maybe) a WYSIWYG front end (I heard that the zopistas were playing with using the Mozilla engine which is probably GLPLed, but might be loadable as a module to get rid of GPL objections) and I think we'd have a _killer_ application. I can't help with the coding (far too stupid) but I'd be happy to help on the documentation and crash test dummy side. Cheers John -- They're afraid, very afraid...... According to CRN magazine, Microsoft staff discovering Linux in use will have now access to a special 'escalation' team. Now, where did I put that stake and mallet? http://www.newsforge.com/article.pl?sid=02/01/16/0310222&mode=nocomment

3 2

Jump to page: