Squeak-dev September 2005

squeak-dev@lists.squeakfoundation.org

157 participants
266 discussions

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

02 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: Wiki Vandalism again
by oxe 02 Sep '05

02 Sep '05

yes but they still help. spammers can get around anything. there may be newer better methods, but the type-in-the-letter hacks i know of are somewhat labour- and resource-intensive on the spammers, so i think it might be worth a shot. i was getting several comment-spams per week on my blogspot blogs, but since enabling the 'type in the letters' thing it's dropped to zero. - altho i only made that change a week or two ago, so the sample size is pretty small. orion Sean Glazier sglazier-at-comcast.net |squeak devlists| wrote: > The spammers have tools to get around those. > > -----Original Message----- > From: squeak-dev-bounces(a)lists.squeakfoundation.org > [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On Behalf Of oxe > Sent: Wednesday, August 31, 2005 4:24 PM > To: squeak-dev(a)lists.squeakfoundation.org > Subject: Re: Wiki Vandalism again > > how about adding one of those "type in the letters you see here" jobbies ? > > that must be getting to be a fairly standard package by now.. > > orion > > > Jochen F. Rick nadja-at-cc.gatech.edu |squeak devlists| wrote: > >>Are there any keywords they are using? like viagra? hot asian women? etc? >>that you want me to ban? >> >>Peace and Luck! >> >>Je77 >> >>PS reply to me and not the list. >> >>On Wed, Aug 31, 2005 at 08:41:29PM +0200, Hans-Martin Mosner wrote: >> >> >>>Hi, >>>recently I've been fixing vandalized Swiki pages almost every day - >>>looks like somebody has implemented some auto-vandalizer script or so. >>>Could the nice folks who run the Swiki (hi Mark!) maybe add some code >>>which checks whether the e-mail alert addresses contains HTML tags and >>>reject (or silently ignore) submissions in that case? That would at leas >>>stop this one vandal. >>> >>>Cheers, >>>Hans-Martin >> >> > >

4 4

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

Re: Smalltalk and Self
by Marcus Denker 01 Sep '05

01 Sep '05

Am 01.09.2005 um 00:12 schrieb Jecel Assumpcao Jr: > > In short: the Self world lacked its Andreas and Ian which was the main > factor why Self and Squeak followed different paths. > But if you then look at the development of Tweak/Croquet and the latest discussions on the vm-list, it seems they learned their lesson and now are using a much more closed (hostile?) form of development... So something clearly did not went the right way with Squeak from their perspective. One thing that the Traits discussion again has shown that it is very hard to innovate in Squeak. There is a huge hostility against doing new things, even if the alternative is complete standstill. Marcus

8 9

RE: Traits approaching mainstream Squeak
by Trygve Reenskaug 01 Sep '05

01 Sep '05

I started as a fan of inheritance; frameworks was the answer to the SW crisis. I later came to believe inheritance to be evil. The turning point was when I discovered that I just couldn't deal with new versions of the VW class library from ParcPlaceSystems. There was an enormous tangle of dependencies between the library and our 300k lines of application code and we had to resort to testing to find what was broken with a new library version. "Program testing can be used to show the presence of bugs, but never to show their absence!" (Dijkstra) I find that readable code combined with peer review goes a long way to show the absence of bugs. My conclusion: ¤ Inheritance is wonderful in the small when I can grasp all its aspects. ¤ Inheritance is evil in the large if I cannot rely on the superclasses remaining stable. Cheers --Trygve At 07:36 01.09.2005, you wrote: >Blake> I'm intrigued by the question of "is inheritance necessary" > >Perhaps a better question would be "Is inheritance optimal?" Or even >better: "When is inheritance optimal, and when is it not? And when it isn't, >what alternatives are better?" > >--Alan -- Trygve Reenskaug mailto: trygver(a)ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway

4 3

Re: Smalltalk and Self
by Chris Muller 01 Sep '05

01 Sep '05

> One thing that the Traits discussion again has shown that it is very hard > to innovate in Squeak. There is a huge hostility against doing new > things, even if the alternative is complete standstill. I didn't sense hostility, just questioning natures. The people who questioned just want to learn, not stand still. From my view, you and Stephen and others did the right thing by helping them understand and, now, they will receive Traits (more) warmly.

1 0

AW: Newbie remark concerning Smalltalk programming in (german) Sq ueak (Squeakland 3.8.5976)
by "Hübner, Uwe" 01 Sep '05

01 Sep '05

Thanks for the explanation (to both of you)! To Rene: Great! Oder besser: Goil aeh! To Herbert: No, I don't know how to program smalltalk in other environments. Darmstadt is not so far from here. I'm near Karlsruhe! May be some day, we could meet... Regards, Uwe -----Ursprüngliche Nachricht----- Von: Herbert König [mailto:herbertkoenig@gmx.net] Gesendet: Donnerstag, 1. September 2005 14:51 An: The general-purpose Squeak developers list Betreff: Re: Newbie remark concerning Smalltalk programming in (german) Squeak (Squeakland 3.8.5976) Wichtigkeit: Hoch Hello Uwe, H> until today I wandered how to program Smalltalk in Squeak. you know how to program smalltalk in other environments? H> How frustrating it is, if the first program (Hello world) doesn't work! Try the squeak.org and the swiki, there are lots of working tutorials. H> With 'ALT-D' (on an Windows-PC) i tried to execute. Something happened but H> nothing was displayed H> in the Transcript window. H> Meanwhile I found out that first I have to 'select' the code that has to be H> executed! H> Then everything works as expected. H> Could someone explain it? Actually it's helpful. You have a workspace with many snippets of code, select one or many and 'ALT-D' does it. Well each expression must be terminated by a '.' to work on many expressions. As long as it is a single smalltalk expression it may be multiline and just putting the cursor into it 'ALT-D' will do it. Where are you situated in Germany? I'm near Darmstadt, relatively new to squeak and doing something together might help both of us. Cheers, Herbert mailto:herbertkoenig@gmx.net

1 0

Current Harvesting Status/Organization
by Ken Causey 01 Sep '05

01 Sep '05

I'm wondering what the current status is of the harvesting process from the standpoint of the harvesters. I'm a little bit bothered by the most recent addition to 3.9alpha. Judging from the HTTP info 6667TallySupport-ab.cs went into the update stream on the 22nd or 23rd. For some reason this update has no preamble although the versions both in BFAV (closed by the Janitors) and with the issue (ID 1014) on Mantis have preambles. Also the issue on Mantis is still marked as new and there is no evidence that harvesting (beyond the review step) is occurring regarding this issue. I realize we are in a highly transitional time here and that as a result there may be some confusion, but even if we don't have solid stated procedures I would hope that anyone modifying the update stream will make some effort to maintain a minimum level of documentation regarding the handling of each issue. Admittedly I'm complaining here a little bit. But more than anything I would really like to have a bit better understanding of how updates will be entering the update stream in near future and what sort of changes, if any, those doing that work would like to see in the process. Very shortly I want to state publicly that in my opinion the future of Squeak progress is in the form of individuals and teams taking direct responsibility for packages and parts of the image. I think that anyone who has an interest in doing this should not wait and should speak up ASAP. Ken

7 8

LineMorph class
by Mariano Wahlmann 01 Sep '05

01 Sep '05

Hi, my name is Mariano Wahlmann, i'm using Squeak3.8 and I have a questions about LineMorph class: Why exists the new method as class method instead of having an initialize method?. I ask this because if you want to extend this class, you have to re-write new and initialize methods. Is this maybe a bug?. Thanks

4 4

Jump to page: