Squeak-dev February 2002

squeak-dev@lists.squeakfoundation.org

202 participants
665 discussions

[UPDATES] three more for 3.3a
by Scott Wallace 03 Feb '02

03 Feb '02

A further trickle... 4736 openProjFix - Bob Arning - 2 February 2002 Some file services would rather have the directory and local file name. This change set restores that option. 4737 FailingTestCases-dew - Doug Way - 3 February 2002 Disables the two SUnit tests (#testFailureDebugUI and #testDebugUI) which simply test to make sure the SUnit UI handles failure. By default, doing a RUN ALL tests in the UI should have all tests pass, so it's silly to have these two purposely fail. These tests can be re-enabled by uncommenting out the appropriate code. Also removes two recently added tests in FileList2ModalDialogsTest which never worked. After filing this in, doing 'TestRunner runTests' should result in all tests passing, at least in 3.2. 4738classVarRefs-sw - Scott Wallace - 3 February 2002 Reverts a method that was blocking access to class-var-refs queries, as per Henrik's instructions. -- Scott

1 0

[FIX] FailingTestCases-dew
by dway＠riskmetrics.com 03 Feb '02

03 Feb '02

from preamble: "Change Set: FailingTestCases-dew Date: 3 February 2002 Author: Doug Way Disables the two SUnit tests (#testFailureDebugUI and #testDebugUI) which simply test to make sure the SUnit UI handles failure. By default, doing a RUN ALL tests in the UI should have all tests pass, so it's silly to have these two purposely fail. These tests can be re-enabled by uncommenting out the appropriate code. Also removes two recently added tests in FileList2ModalDialogsTest which never worked. After filing this in, doing 'TestRunner runTests' should result in all tests passing, at least in 3.2."!

1 0

[modules] Important: class re/definitions in change sets and updates
by Henrik Gedenryd 03 Feb '02

03 Feb '02

Dan Ingalls wrote: > Apparently some of the new updates after modules have had their classes > strangely classified. I say this because if you do a 'find...' in the left > pane of a browser, they do not seem to be findable, even though they appear at > the bottom of the leftmost pane. > Ok, the updates got out so fast I didn't have the time to say this in public: There are now multiple name spaces, one per module. So an important thing to keep in mind is that in subsequent change sets and especially updates, system categories in class definitions *have to* agree with that of the existing class, or a second class will be added in the module specified by the category. (Harvesters, in particular, keep this in mind.) Since system categories are simulated from module path names, classes will be placed in *exactly* the module specified in the category of a class definition--even if the module doesn't exist. This is for reasonable backward compatibility. So, new classes will be placed there obviously. But, for an existing class in a certain module, a *new class* will be created from the new class (re-) definition if it specifies a different module. This is not a bug, it is because every module has its own name space. One could circumvent this by ignoring the category for any class already present under #(Squeak), but I don't think this would be a good thing, all things considered. > Do you know how to > fix this so they can be found? attached. > and/or warn so it doesn't happen in the future? Umm, there is a warning for reusing class names, but they are suppressed during fileIn... suggestions? > write an update with code that will repair existing cases? attached. Finally, a warning: There are now (and have been) coming out updates that refactor the image. This should always be done on a non-modified, standard image. If there are classes in improper places (ie. badly placed modules), they are in danger during refactoring. There is code to prevent this, but there are no guarantess that this will always work (although I don't see why it should happen). Henrik

6 9

[FIX] VariableNode>>index
by Vassili Bykov 03 Feb '02

03 Feb '02

Looks like it should be as attached. --Vassili --- snip --- 'From Squeak3.3alpha of 30 January 2002 [latest update: #4730] on 2 February 2002 at 6:13:26 pm'! !VariableNode methodsFor: 'testing' stamp: 'vb 2/2/2002 18:11'! index "This code attempts to reconstruct the index from its encoding in code." code < 0 ifTrue:[^nil]. code > 256 ifTrue:[^code \\ 256]. ^code - (CodeBases at: self type)! !

1 0

[META] Please resend any mail you sent to Craig Latta in the last week...
by Craig Latta 03 Feb '02

03 Feb '02

Hi-- Well, I'm back home, but not without having had a minor brush with data loss. The only thing unrecoverable is the last week of my mail. So, if you sent anything to me (like an ack for the new Flow mailing list), please resend. thanks! -C -- Craig Latta composer and computer scientist craig.latta(a)netjam.org www.netjam.org crl(a)watson.ibm.com Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0

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

03 Feb '02

Hi Scott, It took me a little time to figure some of this out, and none of it was due to that aweful link you posted! ;-) When I search the web for this topic, most of what I get back is headache food. The trick with doing callCC in Squeak, is that we don't have callCC:, like your foo example. Instead we create a continuation around a block and not part of a #callCC: expression. Below is a fixed version of your foo/bar: example. >foo >^([:continuation | self bar: continuation] valueWithCC) +10 > >bar: continuation > continuation value: 15 > ^16 Another issue is with which Process we create or invoke a continuation. Anthony's #run method sounds perfect for this. I have attached a ContinuationFuture changeset. Here are some other things I learned in writting this. If you don't fork your call to the creation of a continuation, whatever you do afterwards will be executed when you invoke the continuation. If you do an inspect, then each time you invoke the continuation, it will be reinspected. If you happen to invoke the continuation, just after you have created it, then without invoking conditionally, you are in an infinite loop. I decided to create continuations from a forked process, that takes a second block to do work on the value of the continuation. I do this fork at timingPriority, so I know it gets created before I try to invoke it. If you don't fork your call to the invocation of the continuation, then the process you invoke it with is *gone*. If this happens to be your UI Process, then you are stuck without a UI Process. This is typically more fatal than the first case, especially if you start infitine looping. I believe the priority you fork the invocation of a continuation is the priority that the continuation runs at. I default to highIOPriority. The key to getting thi sto work was you example of error handling of objects. With this example, you bail the first time through the setup method (#errorIn:handle:), when the continuation returns nil, as it does the first time. Here was that code: >Or, a more sophisticated example that handles objects and nested exn >handlers. > >Processor>>error: errorObj > self callCC: [:cont | self exnhandler value: errorObj] > >Processor>>errorIn: aBlock :handle: aHandleBlock > oldhandle _ self exnHandler. > err _ self callCC: [:cont | self exnHandler: self > cont nil.] > err ifNil: [^nil] > self exnHandler: oldhandle. > aHandleBlock value: err. Here is a bare-bones SimpleContinuationFuture, that is inthe attached changeset. Object subclass: #SimpleContinuationFuture instanceVariableNames: 'valueContinuation' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Methods' value: value [valueContinuation value: value] forkAt: Processor highIOPriority. Processor yield. whenResolved: aBlock | valueResolution initial | [initial := true. valueResolution := [:cont | valueContinuation := cont. nil] valueWithCC. initial ifTrue: [initial := false] ifFalse: [aBlock value: valueResolution]] forkAt: Processor timingPriority. example | cont | cont := SimpleContinuationFuture new whenResolved: [:each | each inspect]. cont value: 23. Since I fork both the creation and the evaluation, there are no infinite loops or lost UIProcess. I see know that the 23 that I send to value, is set to the value of the continuation, which logically hooks into the #whenResolved method, just where the valueWithCC send is. When you invoke the continuation with #value:, that value is the return value of the #valueWithCC and so is assigned to the valueResolution variable. The use of initial is key, since it allows us to setup the continuation, without evaluating any of the code in the false block. It does set the initial variable to false, so the next time we invoke it, this value is passed to the aBlock argument. comments interspersed... At 12:15 PM 2/1/2002, you wrote: >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 [*] This block is a Continuation object in Vassili's changeset. It represents the return continuation from the call to #valueWithCC, right? <snip> -- >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. Yes, I see now. >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. Is there a better, faster way to do this ContinuationFuture? >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. Yes, me too! I am really impressed with the power of these things. They carry around little frozen stacks that you can restart, and there are certainly some interesting things that can be done with them. I am well on my way into implementing References and Promises for an Elib like mechanism. I have a FarRef and a Promise, and the Promise is created from a send to the FarRef and is waiting for the future continuation to resolve.. Further sends to the Promise, also return promises. I'll keep working on that a little. Thank you everyone, for the great explorations into these things. cheers, Rob

2 1

Re: TextMorph events
by Gary McGovern 03 Feb '02

03 Feb '02

Thanks Bijan, Using a transparent button might be a good idea in some places, but I'm generally quite happy with overriding the textmorph methods. As for the using the command key actions, I can't see how they can be used in an object model. But, in windows, alt 6 changes the colour, alt d opens the browser in "TextMorph browse", but couldn't find the equivalent to Ned's example where he changed it to "Click me". That wouldn't work. Thanks! Gary. 02/02/02 06:07:35, Bijan Parsia <bparsia(a)email.unc.edu> wrote: >On Sat, 2 Feb 2002, Gary McGovern wrote: > >> I'm not sure what you mean there. To explain a bit better what I need: >> >> I don't want to alter or edit the text. > >The standard way of creating a hyperlink is to add a certain kind of style >to the text via command-6. Check out TextAction and friends. > >If you want the TextMorph itself to be a button, er..., use a button :) > >> When I click on the text I >> want to go to another page in a bookmorph, or other text in a >> bookmorph, or open a window or other morph, " rather than the I beam >> sitting in the textmorph for editing. > >If you select *all* the text in a text morph, and do the "link" think, >you'll get pretty close to this behavior, I think. Otherwise, you could >always cover your morph with a transparent button, maybe, a la hypercard? > >[snip] >John Hinsley wrote: >> >You can make other kinds of active links this way, including links to >> >classes, methods, or URL's." >> > >> >But while this works for most text_in_morphs, I don't think it'll work >> >for a plain old text morph. > >The morph itself or the "text" in a "plain ole text morph"? > >> > I could never come up with a satisfactory >> >explanation of why! >[snip] > >Hmm. What's not working? The technique? The cmd-6 thing is a *UI* >issue. If your textmorph isn't hooked up to the right editor, you can't >use it. > >OTOH, you can certainly add styles to *any* Text, including to the >plainest of the TextMoprhs...you just have to do it programmatically. I >show how to do this in on of the SqueakTweak columns. Check out the >TextEmphasis hierarchy, and Text itself. > >Those links aren't restricted to Morphic, BTW. > >Cheers, >Bijan Parsia. > > >

3 2

[BUG] 3.2-4652 scoller sausage can obscure top scroll arrow
by Tim Rowledge 03 Feb '02

03 Feb '02

Using the 'normal' scoller look (no offense intended but the new one with rounded ends looks really awful) it is possible to get the scroller sausage to overlay the top scroll arrow, but not the bottom one. tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: WK: Write to Keyboard

3 4

Command/control key mapping
by Harry Chesley 03 Feb '02

03 Feb '02

I recall a discussion on the list a while ago about allowing Windows users to use control- rather than alt-. I don't recall whether there was any final resolution (i.e., code) posted. I looked in the Squeak Fixes archives, but didn't see it. At the time, I thought I'd wait and hope it makes it into the official image, but as my Squeak usage approaches 50% of my time on the computer, I find my muscle memory is approaching a state of maximal confusion... I'd be quite happy with something that swapped control- and alt-, or with something allowed the core commands (x, c, v, z, s, l) to be used with either control- or alt-. To avoid unnecessary traffic on the list, perhaps it would be best to reply directly to me on this. I'll post a summary answer to the list. Thanks.

4 4

Re: Iteration Speed, Collections, and speed
by Lex Spoon 03 Feb '02

03 Feb '02

> > What this means in using Squeak is that you can't opt out to the C++ dumb > ass solution of "I got a list of 10K items, I'll just grovel through them to > find the one I want." What is ignorable in C++ is a slow mover in > Smalltalk. This isn't always the case. For example, look at the code behind senders-of sometime, which grovels through more than 10k objects. #allCallsOn: "implementors-of" The speed difference in Smalltalk and C++ only matters for medium-speed programs. Really fast programs are still fast, while really slow programs need to be rewritten anyway Medium-speed programs are around, but they are a minority, and thus doing it the dumb and simple way is a great technique for Smalltalk, too. -Lex

1 0

← Newer
1
...
58
59
60
61
62
63
64
...
67
Older →

Jump to page: