Squeak-dev December 2004

squeak-dev@lists.squeakfoundation.org

194 participants
491 discussions

How to file-in a VW *.st file?
by Ruben Bakker 02 Dec '04

02 Dec '04

I like to file-in an "*.st" file from VisualWorks. Unfortunaltly, squeak doens't recognize the format (it is XML). How can it be done? Thanks Ruben

2 2

SqueakSource down?
by Frank Shearar 02 Dec '04

02 Dec '04

I can ping kilana.unibe.ch but there's no SqueakSource running on port 8888. Is the server moving, or has someone forgotten to restart it, or something? frank ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ********************************************************************

2 1

RE: Perhaps naive question about the colon.
by Frank Shearar 02 Dec '04

02 Dec '04

Blake <blake(a)kingdomrpg.com> wrote: > > On Thu, 02 Dec 2004 12:59:04 +0100, Andreas Nilsson > <wahboh(a)mac.com> wrote: > > > I'd say there's a difference between: > > caveman light: fire with: flintAndTinder usingForFuel: twigsAndStraw > > > > and: > > caveman light fire with flintAndTinder usingForFuel twigsAndStraw > > > > The first example is calling a method with arguments to > tell it what to > > do while the second simply calls the methods twigsAndStraw, > > usingForFuel, flintAndTinder, with, fire and light on the > caveman object. > > You could, I suppose, write classes that has methods instead of > > arguments and rely on people calling them in the right order but I > > wouldn't recommend it. > > > > The second example could also be used like this: > > caveman flindAndTinder twigsAndStraw usingForFuel with fire light > > Well, as I said, it was a conceptual (perceptual? habitual?) > issue. I > don't think of terms in consecutive statements--a hold over > from more > procedural langugaes, so I'd "intuit" a special punctuation > for multiple > sends. In other words, in Smalltalk, you'd send three > messages with one > parm each as: > > Caveman find: flint gather: twigs light:fire. This actually sends the message #find:gather:light. If you mean to send #find: then #gather: then #light: you need disambiguate using brackets: ((Caveman find: flint) gather: twigs) light: fire (I'm ignoring semantics here - you probably don't want to send the #gather: message to the result of #find: as I do in this example!) > whereas, I would expect punctuation for the separation versus > for the > parameters: > > Caveman find flint, gather twigs, light fire. "Three > messages, one parm > each." Ah, a cascade: Caveman find: flint; gather: twigs; light: fire. which is a neater way of saying Caveman find: flint. Caveman gather: twigs. Caveman light: fire. frank ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ********************************************************************

2 1

RE: Perhaps naive question about the colon.
by Frank Shearar 02 Dec '04

02 Dec '04

Blake <blake(a)kingdomrpg.com> wrote: > > On Thu, 02 Dec 2004 19:05:01 +0800, Yar Hwee Boon > <hboon(a)motionobj.com> > wrote: > > >> caveman light fire with flintAndTinder usingForFuel twigsAndStraw. > > > > Well.. at the very least, "caveman light fire with flintAndTinder > > usingForFuel twigsAndStraw" is already valid syntax now, > its a chain of > > simple message sends, no? > > Aha! It was a naive question.<s> > > Thanks for bearing with me. I've never gotten used to that > construct. Very > often in the code it's done with line-breaks, and I think I > had attributed > significance to those. You mean something like caveman light: fire with: flintAndTinder usingForFuel: twigsAndStraw ? I don't know when it was invented, but Kent Beck's (fantastic!) "Smalltalk Best Practice Pattern" describes it in the Indented Control Flow pattern on page 175. I've always figured it as analogous to doing this in Delphi: Caveman.Light(Fire, FlintAndTinder, TwigsAndStraw); at least where indenting's concerned. frank ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ********************************************************************

2 1

Perhaps naive question about the colon.
by Blake 02 Dec '04

02 Dec '04

This may be a naive question, but it should at least have a simple answer, unlike a lot of the stuff flying around here.<s> Is the colon as a signal for a parameter expected necessary? I know it's spec'ed, and I can see where in the browser, it's what separates the parameters (buildButton:target:label:selector). But from a strict parsing standpoint, do the colons tell you anything you couldn't get from the context? Like: caveman light: fire with: flintAndTinder usingForFuel: twigsAndStraw. versus: caveman light fire with flintAndTinder usingForFuel twigsAndStraw. Forgive me if this is dense, as well as naive.

3 4

Re: FIX: Making Set/Dictionary etc. loops more robust
by Richard A. O'Keefe 02 Dec '04

02 Dec '04

"Joshua Scholar" <jscholar(a)access4less.net> wrote: Changes Set>>do: from do: aBlock tally = 0 ifTrue: [^ self]. 1 to: array size do: [:index | | each | (each _ array at: index) ifNotNil: [aBlock value: each]] to do: aBlock tally = 0 ifTrue: [^ self]. array do: [:each | each ifNotNil: [aBlock value: each]]. There's one fairly major problem with Set>>do: which this change does nothing about: the fact that iterating over a Set of n elements is not O(n). This seems rather like polishing the brass on the Titanic. The difference is that adding to a Set or Dictionary can put a new rehashed hashed hash table into "array" Yes, but it has always been strictly forbidden to make any kind of change to a Set or Dictionary while iterating over it. There are a number of ways to deal with this: - Java actually maintains a change count and Set/Dictionary iterators watch out for changes, so If You Do Bad Things You Get Told - AWK (at least the 'mawk' implementation with which I'm familiar) actually goes to the trouble of making a copy of the key set of an array when you do 'for (key in array) ...' so If You Do Bad Things It Works Like You Should Have Expected'. - Smalltalk has traditionally gone a little bit crazy; If You Do Bad Things You Get What's Coming To You And Why Didn't You Read The Sources? - Verification tools like ESC/M3, ESC/Java, SPARK, and so on verify at 'compile' time that You Didn't Do Anything Bad You Good Little Programmer You (it's just not what the customer wanted). In the original version, if any block inside of a "do:" or any of the many loops that depend on "do:" called code that added to that Set then there was a chance the set would grow and rehash - and some element would be visited more than once and some not at all. Indeed. Break the contract and you lose your rights. The way it is with this change, adding to a Set in a loop adds an element that might not be visited, and deleting an element doesn't necessarily mean the element won't be visited but the meltdown scenario can't happen. Add an element to a Set, and the following things can happen: (1) The element is already present; nothing bad happens. (2) The element is not already present and there is room in the array; (2a) the new element is inserted after the current iteration point=> it will be seen (2b) the new element is inserted before the current iteration point=> it will not be seen. We are already in Very Bad News territory. It's darned near impossible to give this a coherent abstract semantics. A "live view" should ensure that when you finish the loop you have seen _everything_ that is still in the set. The proposed change does not ensure that. A "snapshot" should ensure that when you finish the loop you have seen all and only the things that _were_ in the set at the start; the proposed change does not ensure that either. (3) The element is not already present and there is not enough room left (as defined by #fullCheck) The old code will switch over to the new array, but not scan all of it. The new code will continue scanning the old array, so will not see the addition or any other changes. This is at least as much of a "meltdown" as what the old code did, and is arguably worse, in that it will hold onto a dead data structure that ought to be GC-meat. Remove an element from a Set, and the following things can happen: (1) The element is already absent; nothing bad happens. (2) The element is present. It's replaced by nil, then #fixCollisionsFrom: is called. This can make fairly large scale rearrangements of the array. As far as I can see, this can results in elements being missed or seen twice, WHICHEVER of the #do: versions is used. In short, the only effective change is that the new Set>>do: will, in some rare circumstances, visit more elements because it is scanning the wrong array. I don't really understand why this is useful, when we STILL have the problem that additions may or may not be seen and removals can STILL scramble a #do:. And of course the new version is at least as fast as the old one. I benchmarked it, and the new code is slower. s := (1 to: 60000) asSet. [s do: [:each |]] timeToRun => 42 msec (old version) [s do2: [:each |]] timeToRun => 63 msec (new version) These times with Squeak 3.6-5429-full, MacOS 10.3.3 on a 1GHz G4 PPC.

11 26

[ANN][GOODIE]Nice Do It
by Noury Bouraqadi 02 Dec '04

02 Dec '04

Hi, I just uploaded a package that introduces "nice do it". Its just like "do it" except that the evaluation is performed in a low priority process so one can keep interacting with its Smalltalk. The process can get supervised through a window that is automatically opened. http://csl.ensm-douai.fr/noury/17 -- Noury ------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Ecole des Mines de Douai - Dept. G.I.P http://csl.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org Squeak: an Open Source Smalltalk http://www.squeak.org ------------------------------------------

2 2

Re: [Squeak 0000548]: FileContentsBrowser has garbled characters in InfoView
by Scott Wallace 02 Dec '04

02 Dec '04

Hi, Marcus, Alex, and all, For the record, the "tidbits" update I published to Squeakland 3.8 (as update 0368tidbits-sw) had *correct* fixes for the two methods whose "black-dot" characters had earlier gotten clobbered during the m17n process. Thus, Squeakland 3.8 has the correct code in it. And that's the last time I touched that code. Evidently, when someone recently cross-published my Squeakland update to Squeak3.8beta, as update 6459-0368tidbits-sw, the procedure used somehow introduced fresh encoding errors, which resulted in the publishing of a faulty file that has garbage characters in it. I think Michael or Bert is shortly going to be publishing a new update to Squeak 3.8gamma that restores the correct code for the two methods in question. Cheers, -- Scott At 9:55 AM +0100 11/26/04, bugs(a)impara.de wrote: >The following bug has been RESOLVED. >====================================================================== >http://bugs.impara.de/bug_view_page.php?bug_id=0000548 >====================================================================== >Reported By: laza >Assigned To: MarcusDenker >====================================================================== >Project: Squeak >Bug ID: 548 >====================================================================== >Summary: FileContentsBrowser has garbled characters in InfoView >Description: While looking at a method source the bottom info view >contains garbage characters (see snapshot) >====================================================================== > > MarcusDenker - 11-26-2004 09:48 CET >---------------------------------------------------------------------- >caused by update 6459 > >"Change Set: tidbits-sw >Date: 16 November 2004 >Author: Scott Wallace > >A few methods skimmed from Vancouver updates... > >From 0269blackDotFixes, fixups for two methods that still used the old >black-dot string: > FilecontentsBrowser>>infoViewContents >.... > >---------------------------------------------------------------------- > MarcusDenker - 11-26-2004 09:55 CET >---------------------------------------------------------------------- >fix attached > >Bug History >Date Modified Username Field Change >====================================================================== >11-23-04 11:25 laza New Bug >11-23-04 11:26 laza File Added: strange.png >11-24-04 01:15 tim Bugnote Added: 0000735 >11-24-04 12:34 laza Bugnote Added: 0000736 >11-24-04 12:34 laza Status new => confirmed >11-26-04 09:48 MarcusDenker Bugnote Added: 0000758 >11-26-04 09:55 MarcusDenker File Added: fixFileContentGarbled-md.1.cs >11-26-04 09:55 MarcusDenker Bugnote Added: 0000759 >11-26-04 09:55 MarcusDenker Assigned To => MarcusDenker >11-26-04 09:55 MarcusDenker Resolution open => fixed >11-26-04 09:55 MarcusDenker Status confirmed => resolved >======================================================================

1 0

Re: Adding loop primitives/optimizations (was Making Set/Dictionaryetc. loops more robust)
by Joshua Scholar 02 Dec '04

02 Dec '04

I should have included a link in my answer to Richard O'Keefe. Here is the Squeak Swiki Page I was talking about: http://minnow.cc.gatech.edu/squeak/331 It's called "Are Squeak blocks like Scheme blocks" ... "'do' is also defined in terms of rewriting to a recursive 'lambda'." Anyway I don't really understand how recursive lambdas can give you iteration while reusing the same environment - recursion creates a new environment with each call. Yes I know about tail recursion - but if you were to capture a variable in a Scheme recursive loop (that is store a closure accessing that variable), as the Swiki example does with a Smalltalk iteration loop, then each iteration WOULD have to be a separate variable. I think that if a variable is captured then the tail recursion optimization must be disallowed. Think about what recursion looks like in C. void RecureLoop(int i) { if (i<10) RecureLoop(i+1); ... If you call RecureLoop(1), then when i=10 that means there is another instance of i on the stack that holds a 9, another above that with an 8 another above that with a 7... You can see that capturing a variable in a recursive lambda iteration means that each captured variable is unique. Thus "Scheme _does_ create a new environment (in principle) for each loop _entry_ but not for each loop _iteration_." is only true when the tail recursion optimization succeeds and that can only happen if the environment isn't captured. Anyway, in Smalltalk iteration is primary, not recursion. Is there a tail-recusion optimization? But now that I think about it, the only loops that are primitive right now are while and number to: loops... Won't blocks have to create a new environment on each invocation? And primitive looping blocks are the only blocks that will know the difference between running the first first time and running again, so therefor any block sent to collect: will be nested inside of a primitive iterator, but being nested in the iteration block not being the iteration block the they won't know the difference between a first invocation and a second one and so they'll have to create a new environment each time. Am I missing something? Joshua Scholar

1 0

Accessing a particular object in GOODS causes "Space is low" warning
by Yar Hwee Boon 02 Dec '04

02 Dec '04

I'm trying to access a particular object stored in GOODS and I'm getting a "Space is low" warning. Any idea why? Thanks. -- Regards HweeBoon MotionObj

2 3

Jump to page: