Squeak-dev August 2005

squeak-dev@lists.squeakfoundation.org

157 participants
234 discussions

Squeak related videos on video.google.com
by Marcus Denker 07 Sep '05

07 Sep '05

Hi, ESUG (European Smalltalk Usergroup) is proud to announce that the following videos are now available at Google Video. Thanks for Andres Valloud for collecting and encoding the videos! Google Video allows only for streaming and is usable from windows only for now. The videos will soon be available as a data DVD via ESUG. The video there will be playable on all systems, players for Mac and Win will be included on the DVD. Marcus What is Squeak? (Alan Kay) http://tinyurl.com/a53zm Squeak and Croquet Demo Etech03 (Alan Kay and David A. Smith) http://tinyurl.com/bywxe Croquet: A Collaboration Architecture (Alan Kay and David A. Smith) http://tinyurl.com/cgcms The Computer Revolution hasn't happend yet. Keynote OOPSLA 1997 (Alan Kay) http://tinyurl.com/9vgdl Beyond VI -- Talk from euroko03 (Marcus Denker) http://tinyurl.com/dczzt Alan Kay: Education in the Digital Age http://tinyurl.com/8trwq Alan Kay: Graphical User Interfaces http://tinyurl.com/daocv Bytecode-to-bytecode adaptive optimization for Smalltalk (Eliot Miranda) http://tinyurl.com/dparf Dan Ingalls: Object-Oriented Programming http://tinyurl.com/784jk Alan Kay: Doing with Images Makes Symbols http://tinyurl.com/cpgjz Self; The Video http://tinyurl.com/8q6ku Doug Engelbart: The Demo http://tinyurl.com/d9r9w

2 1

internal or external, that is the question
by Brad Fuller 06 Sep '05

06 Sep '05

I'm trying to learn VMMaker and create a total Unix VM from scratch. I see that I need to first assign plugins to be either Internal or External in the VMMakerTool. And, if a plugin is not assigned, make errors may result. (errors depends on if the class exists or not? Is that right?) I hope this is right. Where do I find each plugins "normal" configuration state? (configuration state = internal OR external) I couldn't find this on the swiki or email. Or, am I way off base here. thanks, brad -- Brad Fuller (408) 799-6124 ** Sonaural Audio Studios ** (408) 799-6123 West San Jose (408) 799-6124 Cambrian ________________________________ Hear us online: www.Sonaural.com

11 23

[ANN] Alternate PostgreSQL interface update
by Jim Menard 05 Sep '05

05 Sep '05

A few years ago, I released an alternate PostgreSQL interface for Squeak. Recently, Leonardo Cecchi (l.cecchi(a)mind-informatica.com) greatly improved upon the code by fixing some bugs, adding SmalltalkX compatability, and creating SUnit tests. http://www.io.com/~jimm/projects/squeak_postgresql/ Jim -- Jim Menard, jimm(a)io.com, http://www.io.com/~jimm "You will notice that BeOS has taken the best parts from all the major operating systems and made them its own. We've got the power of the Unix command line, the ease of use of the Macintosh interface, and Minesweeper from Windows." -- Tyler Riti

6 14

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

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

[ENH] HTTPProxyEditor with proxy user and password
by SPINIELLI Enrico 03 Sep '05

03 Sep '05

Hi all, please find attached an enhanced (I hope) HTTPProxyEditor with extra field for authentication (proxy user/password). HTTPProxy has gone thru some changes too. Hope it elps Bye <<HTTPProxyEditorEnh.1.cs>> --- Enrico Spinielli Eurocontrol/CFMU enrico.spinielli at eurocontrol.int office 21.111 tel:+32-2-7299716 Rue de la Fusée, 96 fax:+32-2-7299022 B-1130 BruxellesBelgium ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender.

4 3

[Fix] Preferences Help not working Squeak 3.8
by SPINIELLI Enrico 02 Sep '05

02 Sep '05

Hi all, while using Preferences window I found out that clicking on Help button was not working due to a missing check on emptyness of a string. here is the fix for 3.8: <<PreferencesHelpFix.1.cs>> --- Enrico Spinielli Eurocontrol/CFMU enrico.spinielli at eurocontrol.int office 21.111 tel:+32-2-7299716 Rue de la Fusée, 96 fax:+32-2-7299022 B-1130 BruxellesBelgium ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender.

4 4

[Q] Speed comparison 2.8 vs 3.8
by Günther Schmidt 02 Sep '05

02 Sep '05

Hi, I just bought myself Mark Guzdials Blue Book and am thus using Squeak 2.8, I've usually been using 3.8. Morphic in 2.8 gives me the impression to be a lot faster than in the 3.8 version, am I imagining this or can that actually be so? Günther

17 42

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

01 Sep '05

Hi Stéphane, Yes, I ***really*** do think that the Collection hierarchy is a "toy" example. Allow me to explain why: What was done with the Collection hierarchy was essentially a refactoring to use Traits. It wasn't a new design from requirements. And while the Collection hierachy is a fabulous and powerful invention, it is really just a bunch of generic components to be used in building more complex systems. My point was that I don't think that the capabilities Traits offers matches up with the way that commercial software is created in the "real" world. I work on a product that is built from over ten thousand source files and has hundreds of developers working on it. The system runs on at least 8 different target CPU's (obviously, not all of the code runs on all eight different CPU types), and includes code written in C, C++, Java, JavaScript, Pascal, various assembly languages, and includes over 300 megabytes of executable code. I am not commenting on the quality of code, only the quantity here. The quality level of the code by any objective standards varies widely, depending on the skill and experience of the people who worked on it and the other constraints placed on the development (i.e. if we can't demonstrate the new feature to an important customer by the end of the (pick some time interval - quarter, month, week, etc.) we will lose a sale worth millions to an evil competitor). I think what I am describing here is how a lot of software gets created in the real world, and in this kind of environment the code never gets past the "make it work" stage. "It works - ship it, and get on to the next thing" tends to be the approach. My point is that common behavior that COULD be reused and benefit from Traits is not usually identified until quite late in the game, after a lot of code has already been written, if it can be identified at all. The other idea that I was trying to get across is that code reuse is a double-edged sword. While it can reduce maintenance effort, and improve the overall quality of a code base, it also makes the codebase more brittle by introducing heavily loaded single points of failure. So I guess I am raising a largely philosophical issue. As I understand it, Traits facilitates code reuse in ways that would be difficult if at all possible with a single inheritance class hierarchy. This capability comes at the cost of an extra layer of complexity (or degree of freedom, if you prefer) and possibly a decrease in performance. The philosophical questions are how can I use it, and how will I benefit from having used it? The Collection hierarchy example shows that I can implement 27 classes with 48 Traits, saving about 10% in the number of methods. This says to me that there was only an average of 2 or 3 methods per class that were redundant or refactorable (Given that we end up with 567 methods, this implies 630 methods in the original implementation, so we eliminated about 63 methods). So, in this respect I don't think that the Collection hierachy is a very strong example for showing the benefits of Traits. You had my attention more with the RectangleMorph example. There you were going to save 70 methods with only 3 classes involved. Admittedly, the paper that is dedicated to the Traits based Collection class hierarchy goes into more detail and shows a greater savings in method count, but I am not sure if I agree that counting (m+h) is legitimate, so I will call it 17.7% instead of 28.2%. I did read the papers, but like many good papers they generate at least as many questions as answers. Traits is very "blue plane" stuff and therefore interesting, but we've had single inheritance for over thirty years, and most of the world still doesn't take advantage of the capability that it brings. I approach Traits with trepidation because it offers another way to do things and I do think there is such a thing as too much flexibility. That was/is one of the major problems with C++. So I guess I'm still looking for somebody to show me the "good-ness" of Traits, because so far it looks interesting, but like a lot of work for a small increase in code reuse and a (hopefully) small decrease in performance, and we've been seeing a "small" decrease in performance with each successive version of Squeak for way too long now. This is (of course), only my opinion. I could certainly be in the minority here. Traits shows clear value in refactoring, but refactoring is "code cleaning", and it doesn't happen much in the real world. In fact, it is sometimes "forbidden" because it is seen as a high risk to touch code that is "field proven". So for now I will sit back, watch, and try to learn something. -Dean stéphane ducasse <ducasse(a)iam.unibe.ch> Sent by: squeak-dev-bounces(a)lists.squeakfoundation.org 08/30/2005 09:37 AM Please respond to The general-purpose Squeak developers list To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> cc: Subject: Re: Traits approaching mainstream Squeak Hi dean do you ***really*** think that the Collection hierarchy is a toy example.... I'm not sure that we are talking about the same. On 30 août 05, at 02:28, Dean_Swan(a)Mitel.COM wrote: > > 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? Cleaning your design does not solve the problem that traits solve. Read the papers. Sometimes we are forced to duplicate code or to write a lot of delegate methods just because we cannot simply reuse method dictionary. This is what traits are about. > 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 > >

5 5

VM mix and match
by Michael Rueger 01 Sep '05

01 Sep '05

Hi all, trying to build the installers for the new squeakland release I just realized that we have an "interesting" mix of VM versions out there. Andreas asked me to use the 3.7.x version, but John built his latest VMs on the 3.8.x trunk. *ix is at 3.7.x. It seems with VMs we have the same situation as with the image (at least before 3.8) that fixes always and only go into the HEAD and older VMs are never maintained. Am I correct here? Which, with all the unfinished changes for the 3.8.x trunk might cause problems? What about for instance the changes to weak behavior (GC)? What are other people's experiences with using the 3.8.x VMs? Any hints, solutions etc welcome. Michael

3 2

Jump to page: