Squeak-dev September 2002

squeak-dev@lists.squeakfoundation.org

165 participants
288 discussions

blue ideas
by Jecel Assumpcao Jr 03 Sep '02

03 Sep '02

I wrote a page with five ideas to simplify Self (slightly blue plane stuff): http://www.merlintec.com:8080/software/11 The jargon there is very Self oriented and so might not make much sense to Squeakers. Some of the ideas at least could be applied to Squeak - 1) unified block/method/context objects in Self, methods are supposed to be prototypes from which we obtain contexts by cloning. In practice it doesn't work that way and this is a call to take the idea seriously. Since Squeak is class based we are already used to the idea that an object and the template from which it is created are very different, so the idea doesn't have the same impact. 2) up arrow as binary selector Squeak has little special syntax: <- (or :=), ^, self, super, thisContext, true and false. Self has even less and I would like to take advantage of idea 1 and make ^ be just another binary selector. This doesn't apply to Squeak since it doesn't have the "implied self receiver" syntax. 3) simpler syntax: no literals This idea would work just as well in Squeak and we already have a taste of it in MathMorphs and eToys. If you can embed a graphical representation of any object in source code, you don't need syntax for literals. 4) simpler assignment This is an attempt to make assignment and message argument binding be the same thing. A side effect would be to allow more flexible keyword messages with default arguments. 5) removing inheritance from the base-level parent slots are a neat language design "pun" (a single thing is used for both "has-part" and "inherits-from" relations) but it would be better to have all program structuring stuff live exclusively in the meta-level. Squeak doesn't have parent slots, of course, but does have #class, #isKindOf: and other unmarked portals into the meta-level underworld. === As I was thinking about the pink plane / blue plane stuff, I came to the conclusion that there is a related but separate dimension. A project can seek "synergy" or it can work towards a "separation of concerns". If you add a JIT, for example, it might be an optional plug-in that makes things faster when present, like in Jitter 3. Everything can work either with it or without it. An alternative would be to make it a central aspect of the design (like Self or Jikes) and try to see what can be made simpler because of it. Can name spaces be simpler? Modules? 3D graphics? My personal taste makes me favor synergetic designs but there are problems. It is harder for more than a small group (or even a single person) to work on it. It is harder (impossible?) to understand a part of the project without learning all the rest. New requirements might come along and it might be easier to throw away the system and build a new one than to adapt it. The "separation of concerns" step-by-step development is the way to go in the pink plane. But what is the best style for Squeak on the blue plane? -- Jecel

7 23

Squeak book !
by Gustavo Pistoia 03 Sep '02

03 Sep '02

Did any body read this book? http://www.amazon.com/exec/obidos/tg/detail/-/0130280917/ref=pd_sr_ec_ir_b/0 02-8647131-2412827?v=glance&s=books

2 1

Re: The standard does *not* support - a removeAll: a - [was: Re: [BUG] Collection>>removeAll:]
by Richard A. O'Keefe 03 Sep '02

03 Sep '02

This was, of course, my point. Fixing a bug that might not be a bug to introduce at least one bug that will certainly be a bug isn't the best solution to this problem, particularly when the bug that might not be a bug might not be a bug except in an obscure case where there isn't any compelling need to fix the bug that might not be a bug. Note that the code which is alleged to introduce a bug is not in fact the code that is being proposed for inclusion in Squeak. Goran has persuasively argued that the "same object" case should call #removeAll, which would NOT introduce a bug in this case. LinkedList "category 'removing'">> removeAll firstLink := lastLink := nil The "oldElements copy do: [:each | self remove: each]" implementation was used to make a point about interpreting the ANSI specification, and that is all. It is consistent with the ANSI specification, as claimed, which means that it is possible and reasonable to interpret the ANSI specification in a certain way. No implementation could be consistent with _every_ possible non-ANSI-conformant quasi-collection. Merely whining that a fundamental change to Collection is demanded notwithstanding these problems because LinkedList isn't a "normal" collection (which it isn't) is as silly as arguing that ArraySliceCollection isn't yet a part of the core image. Missing the point of an example is also "silly". It would be very "silly" indeed to argue that ArraySliceCollection is not part of the image, because it _is_. It just happens to be called MappedCollection. However, just as programmers are expected to know not to change a collection if they are iterating over it, they are expected to know that they should not change a collection they have sliced, except in code which explicitly takes the existence and range of the slice into account. To slice array a, do b := MappedCollection collection a: map: (first to: last). It may not be _called_ a slice, but it's pretty much everything a slice should be. And it can slice an OrderedCollection or SortedCollection, not just an Array. MappedCollection has alreay been considered in this context. By the way, nobody is arguing for a fundamental change to Collection. Not for any specific fundamental change anyway. We shouldn't do it in the absence of a comprehensive overhaul (including a determination that same is needed) -- we are simply opening worms everywhere to fix a maybe-a-bug that may or may not need fixing. I am reminded of the man whose mother told him "No, you should not get married yet, you are too young." She kept on telling him that until one day she told him "No, you should not get married, you are too old." I'm also reminded of "It's always jam TOMORROW, never jam TODAY". As soon as we poke _anywhere_ in Collection we find worms. If we never dispose of the worms humanely, we'll have worms in the heart of Squeak forever. Notwithstanding that, I am sensible to Richard's suggestion that when it is practicable to catch a circumstance that misbehaves, we shouldn't do so silently. I am for adding the assert. That would be something, at least. Remember, it's addAll: too.

1 0

Re: [BUG]Collection>>removeAll:
by David Griswold 03 Sep '02

03 Sep '02

To try to move this issue forward, and keep it in the realm of constructive discussion, I'm going to try to clarify what is going on, and put forward a proposal. I suspect that some (Richard at least), are feeling like myself and other nay-sayers are simply being obstructionist about a simple issue. But there is a very good reason for the kind of critical discussion that has been going on, and it is actually a good thing. The closer a change comes to the core of a system, the more it should be challenged, to make sure it is worthy. We are not talking about JoeBlowCornerOfTheSystem, but the *Collection* class and protocol, arguably as close as you can get to the heart of Smalltalk. This class and protocol have withstood an enormous amount of use in the real world, and even a very slight change needs to be really, really thought about. I jumped into the conversation only because it seemed to me that the necessary "due diligence" wasn't being done. I've made my points, but to be constructive and try to move forward, here is how I would reason about this problem and what to do about it. I'm laying it out in painful detail to show the kind of restraint I think is needed when dealing with important code like this. - it is clear that people do try to write (x removeAll: x), and that it doesn't do what they expect. This seems to happen frequently enough that it would be desirable to at least let people know when this happens, so they can write their code a different way. The currently accepted valid ways to empty a collection are to either create a new collection (usually the fastest way) or say (x removeAll: x copy). - If we come up with a way to detect this case and generate an error, then the only remaining rationale for extending removeAll: to support the special case of the receiver as an argument would be if it was required by ANSI, or made the library or its specification simpler and cleaner, or fixed an actual bug. I believe that none of these has been demonstrated to be true. So how would we detect the error? Richard has argued for just putting the check in. I say it belongs in an assertion, even though it is a very fast check, and here is why: every time a programmer thinks of some invariant like this that they want to check, they make a little 'cost' calculation in their head, and if the check is going to have much of a performance cost, they tend to not do the check. Using assertions automatically for all of these kinds of checks eases that difficult cost decision, which encourages people to sprinkle these checks all over their code (a Good Thing). Just because this particular check happens to be very fast does not make it a special case. So I would recommend the following fixes: 1) Get the assertion mechanism working effectively and efficiently in the standard Squeak release. Make sure its cost in development is minimal, and its cost in production, zero. 2) Just add "self assert: [ otherCollection ~~ self ]." to the beginning of removeAll:. Very, very simple. (a Good Thing). It prevents this whole issue from being a problem, with no changing of the basic Collection interface or implementation required, and with no performance impact in production (Good Things). It also gives everyone notice that they can now sprinkle their code with assertions (a *really* Good Thing). Now, to the second, separate matter: is a new #removeAll method needed? I can see only one good reason for a #removeAll message. That is that a large, tenured collection might need it as a hook to implement a more efficient way of being emptied. Another argument that might be made is that people need a generally easy way of removing all of a collection's elements, but I don't buy that because most of the time, they should just create a new empty collection, which is usually faster, so we don't want to particularly encourage doing #removeAll anyway, since it is usually the slowest way to get the job done. However, the large collection argument is a good one, I think. The question then becomes, where does this method belong? One could argue that code dealing with such large collections almost always knows a lot more about the collection than just that it is a collection that supports remove:, so adding efficient removeAll methods to specific collection classes could be done without adding it to the Collection protocol itself. On the other hand, since removeAll is conceptually built using remove:, adding a default implementation to Collection doesn't break any subclass of collection, since it doesn't use any message other than do: and remove:. It would, however, break classes that implement the Collection protocol but which don't inherit from it (ah, for mixins). So basically, I think this argument comes down to weighing whether the "large collection" argument is good enough to overcome the drawback of breaking existing classes that implement Collection without inheriting from it. I'm not drawing a conclusion here, just trying to delineate the crux of the issue. I personally think removeAll would be a nice addition, but it would break some code out there, and it's not used that often (and shouldn't be), so I'm on the fence about it. If such a method was added, in Collection it needs to be something really simple. You can do this safely and generally without copying if you write removeAll [ self isEmpty ] whileFalse: [ self remove: self anElement ] where anElement can be the following private method (it can be made public, and is in Strongtalk, but that's another issue): anElement self do: [ :el | ^el ]. self error: 'Collection empty; no element to return'. Unfortunately, without an inlining compiler, anElement is not very efficient in Squeak right now, although with inlining it could be more efficient than copying. On a 1000 element Set of consecutive integers, the above implementation is a bit slower than (self removeAll: self copy), so maybe the copying version should be used for now instead, if removeAll is to be added (although anElement is a handy method to have around, in its own right). On the other hand, much more efficient implementations of anElement can easily be written for important subclasses, and then removeAll can be done efficiently without copying. So if there is any overall message here, it is: be very careful with code in classes like this, and show great restraint by making changes as minimal as possible. The code in Collection is simple, but not simple-minded. Don't underestimate the subtlety of why these simple-seeming methods are the way they are. Cheers, Dave

5 4

Re: Squeak book !
by Blaine Buxton 03 Sep '02

03 Sep '02

Yep, I read it cover to cover and LOVED IT. Lots of great material inside. Buy it now...=) It covers a lot of Squeak in small space and does a great job. Also, you'll spend hours with the CD that it comes with. I'm still going through the CD and finding all kinds of cool gems...=) I think I need to go read it again. Squeak for life! >From: "Gustavo Pistoia" <grpistoia(a)sinectis.com.ar> >Reply-To: squeak-dev(a)lists.squeakfoundation.org >To: <squeak-dev(a)lists.squeakfoundation.org> >Subject: Squeak book ! >Date: Mon, 2 Sep 2002 23:12:14 -0300 > >Did any body read this book? > >http://www.amazon.com/exec/obidos/tg/detail/-/0130280917/ref=pd_sr_ec_ir_b/0 >02-8647131-2412827?v=glance&s=books ------------------------------------------------ Blaine Buxton http://www.mp3.com/blainebuxton http://home.kc.rr.com/bbuxton [self isProgrammingInSmalltalk] whileTrue: [self wiggleAndSmile] _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com

1 0

Re: Design Patterns and Collection Classes
by David Griswold 03 Sep '02

03 Sep '02

Brian Rice and all: As Brian asked, I have attached the extracted sources for the core classes in the Strongtalk collection hierarchy. I have filtered out subclasses that are not part of the core hierarchy. It differs from standard hierarchies in two things: 1) it is type-annotated and typechecked 2) it incorporates Cook's collection hierarchy improvements. The Blue-Book classes are there and have the same names, however the hierarchy is shaped differently, because of the above two changes, and so the abstract superclasses differ significantly. The biggest consequence of the above two differences is that unlike other collection hierarchies, it is truly subtype-compatible. This means two things: 1) the classes and interfaces form a true subtype hierarchy as far as the type annotations go, and 2) in addition they are much more *semantically* substitutable. The single biggest change that most programmers will notice as a consequence is that #include: messages should be used instead of #add: messages (include is like just like add, except that it only adds the element if the element is not already in the collection). This lets you do things that you can't do in other Smalltalks, like use OrderedCollections as Sets (since OrderedCollections implement the full Set semantics, which is not true because of #add: behavior in other Smalltalks). If you want to read this, you will need to get used to reading Strongtalk file-out format, which is similar to other ones except that the reflective messages (class constructors etc.) use the Strongtalk mirror interface. Note: you will see the global Delta mentioned a lot in the constructors; that was just the code name for the project, and probably would have become Strongtalk or somesuch if it had reached production. You will also need to understand mixins, since they are used heavily in the Collection hierarchy. If you have any questions, let me know. Cheers, Dave Brian T Rice <water(a)tunes.org> wrote: > > Hi David, > > Would someone be kind enough to produce ascii-text (or at least > non-binary) versions of the Strongtalk sources, since I don't have a > readily-handy new Windows machine, and the Strongtalk system > is totally > unusable on older Windows versions? (I gave up after the > hundredth blue > screen.) > > I'm working on a new language, and want to incorporate the > best ideas that > I can into my collection hierarchy. I've already ported and augmented, > trimmed, and modified Squeak's collection types, but without > real access > to Strongtalk, there are some aspects of this that aren't apparent. >

2 1

Re: [BUG?]Upgrading 3.2 to 3.3alpha
by Anthony Hannan 03 Sep '02

03 Sep '02

Stephan Rudlof <sr(a)evolgo.de> wrote: > Anthony Hannan wrote: > > I am very close to releasing my next version of block closures which is > > now called VI4 indicating that it may include other image format > > changes, still to be determined. This is a working forked version of > > Squeak that will stay up to date with the latest stable release > > (currently 3.2). Once all image format changes are included and stable, > > and the community is ready, it will become Squeak 4.0. > > I'm eagerly awaiting Squeak 4.0! You don't have to wait, you can use VI4 when it comes out.

1 0

[FIX] InterpreterSimulator Fixes
by Anthony Hannan 03 Sep '02

03 Sep '02

The attached changeset adds fixes to InterpreterSimulator, including ignoring TestInterpreterPlugins, which were not being simulated correctly (see comment in TestInterpreterPlugin-simulatorClass). The InterpreterSimulator can now simulate full-size images (they don't have to be shrunken). However, to see the display, the image must have been saved within an MVC project. Images saved within a Morphic project work, but their display is black. Cheers, Anthony

1 0

Re: String>>hash performance
by Richard A. O'Keefe 02 Sep '02

02 Sep '02

First likely possibility is that your copy of MiscPlugin doesn't have the prim - do you have an absolutely up to date vm? Idunno. I just downloaded the latest 3.2 for MacOS about a week ago. It's 3.2.7Beta6.app. (I actually use an alias pointing to the Classic version.) Easy check - comment out the <prim.....> line, recompile and check times again. No apparent change. I guess this means that means MiscPlugin is not loaded or does not have the change. How do I check whether this plugin is loaded or not? How do I check whether it has this method or not? You could of course use VMMakerTool (see instructions on the swiki) to regenerate the MiscPrimitivePlugin and check the C code to see what is going on. Erk. I don't understand VMMaking and I'd rather not have to. OK, VMMakerTool openInWOrld. Path to platforms code: Problem with directory name with platform code: enter correct path or consult help text. Click on "Find Path" => No path found. Try searching from the root directory? (May take sometime) [sic.] Time is also spent on the fetching and saving of results to the stack and it might possibly swamp the time to do the hash work. Shouldn't, but I've seen sillier situations. I don't even know what a platform code _is_. Simplest guess: the plugin does not exist, is not loaded, or does not contain the String class>>stringHash:.... method. Is there a more recent Mac VM that works under MacOS 8.6 and _does_ have this method in the plugin? Is there a precompiled plugin I can download?

2 1

Re: [BUG?]Upgrading 3.2 to 3.3alpha
by Bruce ONeel 02 Sep '02

02 Sep '02

One could always grab the 3.3alpha vm/changes off of the ftp site as well. cheers bruce "Andrew C. Greenberg" <werdna(a)mucow.com> wrote: > > On Friday, August 30, 2002, at 10:57 PM, Dan Ingalls wrote: > > > A choice was offered, at update #4653, to advance to 3.3 and the > > maintainer of the 3.2 fork chose NO. There are no provisions for > > advancing to 3.3 after that point. > > Perhaps a #4652-level Squeak should be available, with a README > describing the situation and a HOWTO for building a v.3 from a v.2?

1 0

Jump to page: