Squeak-dev September 2005

squeak-dev@lists.squeakfoundation.org

157 participants
266 discussions

REMINDER: Squeak Chat Tuesday September 6th 01:00 GMT
by Ken Causey 05 Sep '05

05 Sep '05

Just a reminder that the next Squeak Chat will take place between 01:00 (1 AM) and 05:00 (5 AM) GMT Tuesday September 6th, 2005. As usual we will meet in #squeak on irc.freenode.net. More information about the #squeak IRC channel can be found at http://people.squeakfoundation.org/article/7.html This is a good time to contribute to the development of Squeak by participating in the Harvesting Process. One of the main ways to contribute is by Reviewing submitted fixes and enhancements. For information about the Harvesting Process see http://minnow.cc.gatech.edu/squeak/3152 If you have the time please attend and work toward the future of Squeak. The next seven chats are scheduled for 05:00 (05:00 AM) GMT Saturday September 10, 2005 09:00 (09:00 AM) GMT Wednesday September 14, 2005 13:00 (01:00 PM) GMT Sunday September 18, 2005 17:00 (05:00 PM) GMT Thursday September 22, 2005 21:00 (09:00 PM) GMT Monday September 26, 2005 01:00 (01:00 AM) GMT Saturday October 01, 2005 05:00 (05:00 AM) GMT Wednesday October 05, 2005

1 0

Re: Neo (was: Traits approaching mainstream Squeak)
by David T. Lewis 04 Sep '05

04 Sep '05

On Sat, Sep 03, 2005 at 10:40:10PM -0300, Jecel Assumpcao Jr wrote: > Neo Smalltalk (previously called Self/R and Merlin OS before that) is > the system level software of a low cost computer for students. Not only > should this machine be useful as a tool for learning about math, > science, history, languages and so on but it should also be an > interesting object to study in itself. A very high priority goal is that > the path from casual user to script writer (eToys level programming) to > application writer (Smalltalk-80 level programming) to system developer > to hardware hacker should be as smooth as possible. <snip> > If anyone needs better explanations or more information then please > write to me directly for this is very off topic for squeak-dev. This does not seem off topic to me, and it is very interesting. Thanks. Dave

1 0

pending mac carbon vm 3.8.8b14
by John M McIntosh 04 Sep '05

04 Sep '05

I've added logic to allow you to alter quartz flush logic and post flush logic ms times. In the info.plist within the application you will find 4 keys which alter this behavior. SqueakUIFlushPrimaryDeferNMilliseconds = 20 Attempt to accumulate draw events in a 20 ms window. If a draw occurs and the time is greater than 20 ms from the last draw we draw and flush. If the draw is in the 20ms window we draw, and do a CGSync (once) and do not do the flush. The sync should schedule an flush by the carbon event handler within 20ms or so. Setting this value towards 0 will flush on every draw. I will note setting to 16ms causes the hilbert test to draw each pixel, versus clumps of pixels. Altering this value will affect the frame rate of your squeak animation. SqueakUIFlushSecondaryCheckForPossibleNeedEveryNMilliseconds = 20 Check no faster than 20 ms for possible pending flush events. This reduces CPU overhead. The value of this key has a relationship to the other two keys, but making it smaller might not improve thing. Because of how the checking is done there is no guarantee it will achieve a rate under say 16ms, but it will always occur within N seconds. This value can effect how menus item highlighting is done. SqueakUIFlushSecondaryCleanupDelayMilliseconds = 25 When N ms occur based on SqueakUIFlushSecondaryCheckForPossibleNeedEveryNMilliseconds and we have a flush pending and the flush has not occurred within this key value of 25ms we force a flush. This value should be more than SqueakUIFlushPrimaryDeferNMilliseconds to avoid conflicts with the draw loop. If for example we have a draw and a draw then no further drawing, the first draw should be flushed, then next cached for upwards of 20-40ms based on SqueakUIFlushSecondaryCheckForPossibleNeedEveryNMilliseconds then we would see it exceeds this key value and cause the flush. SqueakUIFlushUseHighPercisionClock = true Use a more expensive ms accurate clock when set to true. If false we use the 16ms based cheap clock. This is set to true to give higher accuracy and does not seem to affect CPU usage based on statistical sampling of production VMs. Squeakers are welcome to alter these values to obtain best behaviour which might change based on versions of OS-X. Note: Altering SqueakUIFlushPrimaryDeferNMilliseconds will affect frame rate. Altering SqueakUIFlushSecondaryCheckForPossibleNeedEveryNMilliseconds & SqueakUIFlushSecondaryCleanupDelayMilliseconds will affect menu drawing. Feedback about these choices is welcome. This VM can be found at ftp.smalltalkconsulting.com Squeak 3.8.8beta14.app.zip I've also moved a copy of the sit files to my idisk http://homepage.mac.com/johnmci/FileSharing.html -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

2 4

Some thoughts about managing packages in VW
by stéphane ducasse 04 Sep '05

04 Sep '05

http://www.cincomsmalltalk.com/userblogs/travis/blogView? showComments=true&entry=3265388740 Stef

3 4

Fwd: [Squeak-fr] Why you should use Squeak to write educational application
by stéphane ducasse 04 Sep '05

04 Sep '05

Begin forwarded message: > From: Hilaire Fernandes <hilaire(a)ext.cri74.org> > Date: 4 septembre 2005 15:27:35 GMT+02:00 > To: Squeak in french / Squeak en français <squeak- > fr(a)lists.squeakfoundation.org>, OFSET members <members(a)ofset.org>, > drgeo(a)ofset.org > Subject: [Squeak-fr] Why you should use Squeak to write educational > application > Reply-To: Squeak in french / Squeak en français <squeak- > fr(a)lists.squeakfoundation.org> > > > Hello, > > I have made some initial research on Squeak to use it as development > plateform for educational applications. > As a test drive I have written the foundation of a Squeak DrGeo[1] > player, an interactive geometry software of mine on Linux. I have > written the player so that it can interact with the other Squeak > objects. > > I am still in the experimental phase of my research but I want to > share > with you this small video > http://documentation.ofset.org/drgeo/videos/drgeo-squeak.avi (need > xvid > codec) which illustrate the wonderfull aspect of object thinking > within > Squeak. > In the video, you will notice that the integration of usual Squeak > objects in a DrGeo drawable is something you get for free !! > > At this stage my conclusion is that Squeak is a perfect tool for > teachers willing to write edu oriented software, the main reasons are: > -a very advanced IDE (emacs&vi looks like prehistoric artefacts, don't > beat me I am a Emacs user) > -the simple and uniform Smalltalk language > -an important multimedia class library ready to be **easily** used and > merged in your applicaton classes > -it is multiplateform > > Hilaire > > > [1] http://www.ofset.org/drgeo > > -- > http://www.ofset.org/petition > Pétition de soutien au développement > de logiciels libres pour l'éducation. > > _______________________________________________ > Squeak-fr mailing list > Squeak-fr(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeak-fr >

1 0

Re: Traits approaching mainstream Squeak
by Dean_Swan＠Mitel.COM 04 Sep '05

04 Sep '05

While I find all this discussion fascinating, I would like to share a few thoughts on the idea of including Traits in mainstream Squeak. My first concern is performance. Since Traits carry no state, they will need to use accessor methods and message sends are clearly much slower than direct instance variable access. My second concern is regarding how Traits should/could/would be used. All of the examples that I have seen so far, including the refactoring of the Collection hierarchy, seem to me to be "toy" problems. I would be interested to read about non-trivial cases where Traits would solve a significant real world problem. It would seem to me that the kind of reuse that Traits enables is the kind that isn't apparent at design time, since individual classes of object are usually designed separately and often by completely different people. The common behavior and opportunity for code reuse might only become apparent after the initial design is implemented. It has been my experience that once something is implemented and working, unless there is a compelling reason to justify it, the code is never revisited. Management is generally focused on allocating resources to things that will yield either an opportunity for increased revenues, or reduced costs, and code "cleaning" is rarely viewed as either. If it ever gets done (code cleaning), it is usually silently piggybacked on required bug fixes by individual developers who feel it is important. Am I in the minority here, or is this how commercial software development works in general? I would even suggest that single inheritance doesn't get used that much in practice. I see an awful lot of C++ where classes are root classes and implement a singleton object. I see poly-morphism used a lot, but not much inheritance. I also see STL used a lot to get common syntax container objects, that you get with the standard Smalltalk Collection hierarchy anyway. So I guess I don't see what Traits gets us that we can't already do in Squeak with some judicious use of proxies, DNU and separate "behavior only" and "state only" classes using accessors for all instance variable access. Is the real benefit in having tools that formalize this and make it easy? Is Traits implemented by just pointing a class's method dictionary entries to the approprate seemingly class-less compiled method defined in a Trait? I guess I don't fundamentally oppose including Traits in mainstream Squeak, as long as it's still possible to ignore it and it doesn't cause a decrease in performance for commonly used objects (i.e. the Collection hierarchy). From what I've read in the whitepapers, it seems it should be safe and easy to ignore, so the only question I guess would be performance. And lastly I will just say that as others (Andreas) have pointed out, maximising code reuse is not always desirable. I can see the argument in favor of code re-use to propagate common behavior without having to find every duplicated variation, but there is also the other side of the argument where a single bug in a common, highly reused method can cause a lot of things to break that might otherwise work properly. -Dean

17 40

Re: 3.3 (was: Smalltalk and Self)
by Victor Rodriguez 04 Sep '05

04 Sep '05

Hi! 2005/9/2, Jecel Assumpcao Jr <jecel(a)merlintec.com>: > It is a pity I didn't have enough time to list names above for then it > would have given you a better idea of who has been moving things forward > the past few years. But I hope it at least gave you an overall feel of > how the community has evolved and how what "leaders" means has changed. Indeed, your message makes things make a lot more sense to me now. I do appreciate you taking the time to respond. Best Regards, Victor Rodriguez. > > On the other hand, in practice Alan Kay and Viewpoints Research are > still the leadership of Squeak as far as the outside world is concerned. > By that I mean that any reporter writing about the system will most > likely want to interview Alan about it instead of, for example, Marcus > Denker. > > -- Jecel > >

1 0

Re: first class method categories (was Re: WTF is a trait?)
by Daniel Vainsencher 04 Sep '05

04 Sep '05

Classes can do that right now, just implement the method in the class, and it overrides any versions provided by traits. This would be a small change in behavior between method categories/private traits, and shared traits - redefining a method from a category changes it. So I'm assuming that's also what we want for a traits while its private, but that would change when it becomes shared. I'm not sure that's such a big deal, but its a sort of inconsistency worth noticing. Daniel Alan Lovejoy wrote: > Classes would also need to be able to override the method implementation > defined by an imported Trait, without affecting the "global" version of the > method as defined by the Trait. > > --Alan > > > >

1 0

Neo (was: Traits approaching mainstream Squeak)
by Jecel Assumpcao Jr 04 Sep '05

04 Sep '05

Jecel Assumpcao Jr wrote on Tue, 30 Aug 2005 22:53:14 -0300 > Daniel Vainsencher wrote on Sun, 28 Aug 2005 14:01:59 -0700 > > Andreas Raab wrote: > > > I see. It would be interesting for me to see an actual design from first > > > principles that ignores the restrictions we have right now (like VM > > > dependencies) and just tries to build a comprehensive set of > > > abstractions. > > Jecel, maybe you can describe the relevant parts of NeoSmalltalk? > > I will be happy to, though it would have to be a little long to include > at least some background for the ideas. This will probably have to wait > until Friday. Another email I sent to the list several hours ago seems > to be missing - I hope this one makes it through. One characteristic of the project that might be obvious from the above is a problem with deadlines :-( Neo Smalltalk (previously called Self/R and Merlin OS before that) is the system level software of a low cost computer for students. Not only should this machine be useful as a tool for learning about math, science, history, languages and so on but it should also be an interesting object to study in itself. A very high priority goal is that the path from casual user to script writer (eToys level programming) to application writer (Smalltalk-80 level programming) to system developer to hardware hacker should be as smooth as possible. Note that I expect only a small fraction of a group at one level to want to move on to the next level. It is just fine with me if only 200 out of a million users become hardware hackers. But the system must be designed in such a way that it doesn't become an obstacle to anyone who is interested. So the same ideas should be used in all levels (no switching from Smalltalk-80 to C in order to explore further) and all learning styles should be supported. In order not to favor abstract thinking only (math types) the ideas are presented in as concrete and visual way as possible. This makes describing them just with words in this email a little more complicated. My key design criteria is "can I explain this to a bright twelve year old?" and if the answer is "no" then I look for other alternatives. One source of confusion in my explanations is that there are two versions of Neo Smalltalk - the one for the student computer (36 bit version) and another for embedded applications (16 bit version). The main difference is that the first is an open system where the image is split into pieces and only a fraction of those are loaded into the machine at any one time. You might think of it as a "world wide image". Traditional Smalltalk notions like #allInstances don't work in such an environment. In fact, there are multiple viewpoints which means that even some object that is present in the RAM might be partially loaded: looking at that EllipseMorph might let you see everything there is in the current viewpoint but there might be other parts somewhere out there that you are not aware of. This system organization will make it simple to implement several kinds of applications that I am interested in and which are hard in Squeak (for example) and hopefully will get the students used to the scientific outlook of the world (partial models). The 16 bit version only has a single viewpoint and its image is entirely stored in the local Flash memory. But the bytecodes are the same, much of the GUI and so on. Some design decisions don't make much sense for this version and only reflect the goal to make the two versions as similar as possible. I will only mention the common features below. In Neo an object includes a sequence of "facets" where each facet is simply a set of methods. Facets don't exist outside of objects and when an object is copied it shares all its facets with the new object. If the new object is edited by changing one of the facets this will affect the original and any other objects that also share that particular facet. So a very common style of development is to add a new empty facet to the object and make the changes there (which can't, by definition, affect anything else in the system). Normally the new facet will be placed at the head of the sequence so its methods can override methods with the same name in any older facets but the programmer is free to arrange and rearrange the order of the facets. State is implied by the presence of setter methods. These methods are part of some facet but the state itself belongs to the object. While I normally try to show visually a close representation of reality, in this case I felt convenience was more important and show something like "_ x <- 3" as both defining a method named "x <-" (blanks are allowed in selectors) in some facet and as showing the currently associated value in the particular object we are looking at. Viewing that same method definition inside some other object might show "_ x <- 7". Given that facets are only shown inside of objects a single one might appear several times on the screen and it would look identical except for the values shown as arguments in the setter methods. This representation is also used in the Self debugger and I think it works very well. The idea is to focus on behavior instead of state. As described so far the system doesn't have classes but the programming environment should have tools to show collections of related objects. There aren't any globals either but objects can be inserted directly into a method's source (there is no literal syntax so this is needed even for something as simple as "3 + 4") and the programming environment includes pallets of interesting objects which can be used this way. Facets don't have names but it is a good idea to add comments to them. An object's organization as facets will depend mostly on its development history. With a style where new facets are introduced only when changing any of the existing facets would break some other object, the tendency will be for facets to correspond roughly to something between classes and traits in Squeak. Often exploratory programming will result in an inconvenient division into facets for one or more objects and they will need to be refactored. Sadly this system in itself makes this very awkward but the programming environment can make up for this with some set of tools. The main idea is to present each object as a self contained entity. It does refer to other objects through its state and also all the literals in its methods but this list is just the absolute minimum it needs to know to get its job done. This is similar to the "principle of least authority" in security. Everything there is to know about the object (from a given viewpoint) should be in one place. Eliminating inheritance and globals really helps with this. Facets are manually placed in a simple sequence so they lack the sophisticated meta-information and composition of Traits. Other than that they are rather similar and so Neo gives a hint of what a Traits-only Squeak might be like. Compared with Self, Neo doesn't have a problem with incomplete trait objects (that implement methods only their children can execute but not themselves), lack of inheritance of structure (thanks to state being implied by setter methods that are "inherited"), program structure leaking into the base level (parent slots) but is missing dynamic inheritance (which hasn't been used in practice so far), shared state (data slots in parent objects) and a universal scoping story (in Self block context objects inherit from their lexical scoped context objects which inherits from the receiver which inherits from its trait which inherits from its trait which inherits from the lobby which inherits from the globals). By the way, as far as I know the word "traits" was introduced by Adele Goldberg in the boxes example when teaching Smalltalk-72 to children at Xerox PARC. Smalltalk did not yet have inheritance back then but she wanted a name to describe on paper the common set of features of a group of objects as a separate idea from the individual features of each object. So traits on paper were an informal introduction to the formal idea of classes. When Self was created a name had to be selected to describe parent objects that functioned as classes and "trait" was used to avoid confusion that "class" would have caused. Other parent objects were called "mixins" since that term was well known since the Flavors object system for Lisp. StrongTalk built its classes from smaller behavior-only pieces which they also called "mixins" as they also fit the traditional definition. For Squeak the behavior-only pieces gained a lot of new functionality so the term "mixin" would have given the wrong idea. "Trait" was selected though there was no relation with how that name was used in Self, but given how few people know that language there was far less total confusion this way. The term "facet" is used by the free Electric integrated circuit CAD software and I don't think the author will mind lending it to me ;-) If anyone needs better explanations or more information then please write to me directly for this is very off topic for squeak-dev. -- Jecel

1 0

Coercing Squeak to send HTML emails
by Nevin Pratt 03 Sep '05

03 Sep '05

What is the secret to coercing Squeak to send HTML emails instead of plain text emails? Right now I am using the AdHocComposition class for sending out emails, but I'd like to send out an HTML email instead of a plain text email. Incidentally, the HTML email I want to send will be a printable Gift Certificate that the recipient can print out and use. Since it is a gift certificate, it needs to be fancy-- something more than just plain text. Nevin

1 1

Jump to page: