Squeak-dev May 2006

squeak-dev@lists.squeakfoundation.org

185 participants
370 discussions

Re: YASoB (was Re: some news)
by SmallSqueak 30 Jun '06

30 Jun '06

Jecel , > > My comment on this is that Smalltalk-80 was indeed wonderful by relative > standards, but it shouldn't become a religion that keeps us from > inventing something better. Though this isn't nearly as sad as people > who keep insisting on creating things that are worse while the public > assumes it is automatically better than something "old" like Smalltalk > (what C. S. Lewis called "chronological snobbery"). > I have a feeling that to many Smalltakers, in general, there have been no advances in software engineering and computer language design since Smalltalk was invented. When was Smalltalk really invented? Was it in 1972 or 1976 or 1980? Did Squeak Central insist on creating things that are worse than Smalltalk-72 and the crowd assumed that it is automatically better than something "old" like Smalltalk-72? For that matter, did the commercial Smalltalk vendors insist likewise? Cheers, PhiHo ----- Original Message ----- From: "Jecel Assumpcao Jr" <jecel(a)merlintec.com> To: "The general-purpose Squeak developers list" <squeak-dev(a)lists.squeakfoundation.org> Sent: Tuesday, May 16, 2006 2:44 PM Subject: YASoB (was Re: some news) > PhiHo, > > > "Alan Kay" wrote: > > > > "... it really bothers me that so many people on this list > > are satisfied with Smalltalk-80 (Yikes!) > > But that's another soapbox." > > > > > > Dear Seasoned Squeakers, > > > > I have followed this list for a while and I have a feeling > > that Alan Kay is not particularly fond of Smalltalk-80. > > > > I've been wondering why or maybe I got it wrong. > > > > Your thought is very much appreciated. > > > > I really hope if Alan is not too busy we will be > > able to hear it straight from the Dragon's mouth. ;-) > > Rather than speaking for Alan, I will just quote two paragraphs from his > "Early History of Smalltalk" (there is a link to a PDF version in Stef's > Free Books page and there is a html version with some missing pictures > at http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html): > > ------- > I will try to show where most of the influences came from and how they > were transformed in the magnetic field formed by the new personal > computing metaphor. It was the attitudes as well as the great ideas of > the pioneers that helped Smalltalk get invented. Many of the people I > admired most at this time--such as Ivan Sutherland, Marvin Minsky, > Seymour Papert, Gordon Moore, Bob Barton, Dave Evans, Butler Lampson, > Jerome Bruner, and others--seemed to have a splendid sense that their > creations, though wonderful by relative standards, were not near to the > absolute thresholds that had to be crossed. Small minds try to form > religions, the great ones just want better routes up the mountain. Where > Newton said he saw further by standing on the shoulders of giants, > computer scientists all too often stand on each other's toes. Myopia is > still a problem where there are giants' shoulders to stand > on--"outsight" is better than insight--but it can be minimized by using > glasses whose lenses are highly sensitive to esthetics and criticism. > ------- > > and > > ------- > New ideas go through stages of acceptance, both from within and without. > >From within, the sequence moves from "barely seeing" a pattern several > times, then noting it but not perceiving its "cosmic" significance, then > using it operationally in several areas, then comes a "grand rotation" > in which the pattern becomes the center of a new way of thinking, and > finally, it turns into the same kind of inflexible religion that it > originally broke away from. From without, as Schopenhauer noted, the new > idea is first denounced as the work of the insane, in a few years it is > considered obvious and mundane, and finally the original denouncers will > claim to have invented it. > ------- > > My comment on this is that Smalltalk-80 was indeed wonderful by relative > standards, but it shouldn't become a religion that keeps us from > inventing something better. Though this isn't nearly as sad as people > who keep insisting on creating things that are worse while the public > assumes it is automatically better than something "old" like Smalltalk > (what C. S. Lewis called "chronological snobbery"). > > --Jecel >

4 5

World Cup 2006 Betting is up! (written in Squeak)
by goran＠krampe.se 20 Jun '06

20 Jun '06

Hi folks! Ok, this is turning into a tradition - it was first up in World Cup 2002, then the Euro Cup 2004, and now it is 2006 and the site was just brought live this morning on my private server: http://worldcup.krampe.se/eng I hope it works correctly, and I (together with Jonas Öhrn) will try to help out if anyone has trouble. Email me in private. ;) And yes, I will post the code somewhere in a day or two (gotta extract it from the 3.2 image it lives in) - but it will come without a manual :) regards, Göran PS. And no, no prizes to win, only the enjoyment of betting better than the rest of us... and oh, Sweden will ROCK this year. :)

5 8

Hosting a book on Seaside with svn.squeak.org
by Damien Cassou 14 Jun '06

14 Jun '06

Hi, would the community agree that svn.squeak.org hosts a book on Seaside in french ? I'm planning to write the book and am looking for a svn server. It will be based on squeak (with a short chapter on Squeak and Smalltalk) and will be written in LaTeX. I don't know about the licence yet. I would like to make it free but I would like it to be printed/published too. Is it a problem for you ? Bye -- Damien Cassou

8 15

[3.9] 7033 available
by Stéphane Ducasse 12 Jun '06

12 Jun '06

Thanks the network and IO team... please continue this is great work.... Even if we nearly lost it because of lost emails :) Stef Name: System-gk.45 Author: gk Time: 21 October 2005, 11:58:31 am UUID: f8210799-b1de-5f46-b675-8c7b83550503 Ancestors: System-gk.44 Two good refactorings based on work from Bernard Pieber for Mantis #861 in the Network package. These depend on changes in the Network package: - Project class>>fromUrl: - ProjectLoading class>>bestAccessToFileName:andDirectory: This also removes the only sender of Project class>>serverFileFromURL: and we could nuke it, but we leave that decision for the System stewards. :)" "Name: Network-sd.30 Author: sd Time: 29 May 2006, 9:29:37 pm UUID: 6da57032-4ee0-412e-830a-e6169251929e Ancestors: Network-KLC.27, Network-tb.28, Network-tb.29 merge Network-tb-29, tb-28, KLC27 with netweork-md.27 Name: Network-tb.29 Author: tb Time: 24 May 2006, 10:23:58 pm UUID: dfdd5a1c-4494-41da-afff-925a1597b1c3 Ancestors: Network-md.27 Fixes to address http://bugs.impara.de/view.php?id=2107 FileDirectory class>>retrieveMIMEDocument: class non-existent MIMEType class>forExtension: Name: Network-tb.28 Author: tb Time: 24 May 2006, 9:10:03 pm UUID: 75f7e92a-6087-4223-a373-9d6516cd35e1 Ancestors: Network-md.27 Fix for http://bugs.impara.de/view.php?id=2454 - correctly set accent- type in HttpUrl retrieveContents so fetches of .css files succeed Name: Network-KLC.27 Author: KLC Time: 3 April 2006, 11:18 am UUID: b2510551-ffee-4449-94c5-48d8c31bef77 Ancestors: Network-md.26, Network-gk.18, Network-KLC.21, Network-gk.23 This is a merge of: Network-gk.18.mcz Network-KLC.21.mcz Network-gk.23.mcz Combined notes: Network-gk.18: Changes: - Adds #fileName to FileUrl and HierarchicalUrl (with HttpUrl as subclass), ok - I think that is fair even if the last part of the path not necessarily denotes a file. - Adds Url class>>directoryUrl to FileUrl and HierarchicalUrl (with HttpUrl as subclass) which simply returns a new URL with the last element in the path removed. - Adds #absoluteFromFileNameOrUrlString: which then is used from two different places (refactoring). - A fix so that copying a URL does not share the path collection with the original. Not sure exactly if this has caused an actual bug yet, but I agree it is a good idea to not share. - Fix bug in FileUrl>>pathForDirectory which used an explicit pathname delimiter in one place. Duh. - Removed class MswUrl, sorry but this should not be in standard Network package IMHO. There is no use of it in the current image. Non behavior changes: - Refactoring adding Url class>>urlClassForScheme:. - Improved naming in ServerDirectory class>>serverForURL:, no actual code change. - Refines and adds lots of comments here and there. Differences from proposed changes from Bernard Pieber in Mantis #861: - Did not include the proposed HierarchicalPath>>pathForDirectory because it doesn t return a path (like the same method in FileUrl does), instead it returns a URL turned into a String. I changed the few senders that Bernard Pieber (Mantis #861) introduced to directoryUrl asString instead. - Did not add isSuperSwikiUrl, it does not belong there. It is a hack from the start. Network-KLC.19: This is an adaptation of the updated provided by Patrick Mauritz at Mantis ID #0411: Change Set: Enh-ConnectionQueue Date: 16 October 2004 Author: Patrick Mauritz Allow classes to subscribe to the ConnectionQueue via addDependent: to get notifications when new connections are opened. Receivers need to implement update:aSocket for this to work. Thanks to Ken Causey for guidance on IRC. I adapted Patrick s changes to ConnectionQueue>>listenLoop the result being that a check for a ConnectedTimedOut exception is added and a call to self changed on successful connection. Otherwise this should be the same as previously in the image. Network-KLC.20: As reported in Mantis ID #2106 this method included a call to the now non-existent Notification class>deprecated method. I ve replaced that call. With what I think is the appropriate mechanism. The next question is at what point do deprecated methods get removed entirely? Network-KLC.21: This removes 3 methods that had no implementation other than calls to self halt. None of the 3 methods were being used and it didn t appear that they would likely ever be used. Network-gk.23: Fix for Mantis #2119, the simplest one described. Fix for Mantis #1585, moved 3 test methods from OldSocket class to Socket and updated the code so that it works. Doing the above I also fixed an issue in Socket>>waitForDisconnectionFor:, it was wrongly waiting on semaphore instead of self readSemaphore. I also removed an unnecessary call to dataAvailable, unneeded temp var #extraBytes etc. The problem was that loopbackTest randomly hung in this method. Optimized Socket>>discardReceivedData, unneeded call to dataAvailable removed. Better class comments in ProtocolClient, Socket and SocketStream. Improved comment in Socket>>closeAndDestroy:' Name: Monticello-al.297 Author: al Time: 9 May 2006, 4:54:21 pm UUID: bc893983-a6cd-430c-bf5d-a4d60fdb04b3 Ancestors: Monticello-al.295 - fix loading traits with empty trait composition

12 24

[ANN] A 6 MB SqueakPlugin.image
by Lic. Edgar J. De Cleene 06 Jun '06

06 Jun '06

Here you could see running on Explorer on my Mac. Also run in Firefox, Safari and iCab Now I wish know if someone know how modify the following and someone could use this image remote via Browser <EMBED type="application/x-squeak-source" ALIGN="CENTER" WIDTH="800" HEIGHT="600"> </EMBED> Very thanks !!! Edgar

6 12

3.9a unprintable characters in some methods?
by Ron Teitelbaum 04 Jun '06

04 Jun '06

Hello all, Sorry about the screen clipping but I thought I'd better show you what I'm seeing. I was wondering why some methods now in 3.9a have an unprintable character down the left column. This doesn't appear in all methods just some. Do they have some significance that I'm missing? Is this a bug? Thanks, Ron Teitelbaum

3 4

Spoon progress 23 May 2006: finding dependencies via passive imprinting
by Craig Latta 03 Jun '06

03 Jun '06

Hi-- Recently I made a module for installing ClassBuilder. (Conveniently, Spoon doesn't need ClassBuilder to install new classes, only to change old ones.) My first test was to add an instance variable to a class in a minimal remote memory. The newly-installed remote ClassBuilder itself behaved fine, but there were a few methods in the remote test class that needed to be recompiled. The minimal memory has no compiler, so that had to be swapped in from the control memory (which also has the GUI and tools I use to run the tests). Installing classes and methods into a minimal remote memory, inline as they are needed, is what I call "passive imprinting". "Active imprinting" is installing behavior in a minimal remote memory as a side-effect of running it locally where it already exists. I suggested in a previous report that only active imprinting is accurate, because a memory requesting methods for itself has no was to know if a method it can already run successfully actually has an override. The situation seems to have changed with the advent of the "method placeholders" I mentioned previously[1]. There are already placeholders in the current minimal memory for each method that hasn't been run since a certain point in time (the beginning of the most recent shrink), but whose class is still referred to by something (classes which have no references are simply removed entirely). As long as placeholders are installed for each overriden method when a new class is defined, passive imprinting now works with full accuracy. Anyway, since the minimal memory also has no source code at the moment, the method recompilation involved in my ClassBuilder test also needed the decompiler. I have the control memory set to mention the classes and methods it installs on the transcript. During the automatic installation of the decompiler, I noticed that DialogStream was getting installed, and, in turn, so was TextStream, Text, Form, Bitmap... These were things that didn't seem absolutely necessary for decompilation. I simply halted the test, noted the point at which unwanted dependencies were being invoked (MethodNode>>decompileString, which had also just been installed), and changed the offending method so that it didn't invoke the first unwanted prerequisite (DialogStream). This seems like a great way to find the dependencies between subsystems in Squeak! The advantage that this technique has over one using active imprinting is speed. With active imprinting, one must probe the remote target memory after every single local message-send, whereas in the passive case the target memory just runs methods without pause until it comes to a placeholder. A workflow for finding dependencies and using them to inform module creation is beginning to appear. It seems we mostly need to come up with a bunch of desired test cases, and the time to run them and watch for undesired relationships. And this whole project is starting to feel like a PhD I should be pursuing somewhere. :) -C [1] http://lists.squeakfoundation.org/pipermail/spoon/2006-April/000107.html -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]

11 37

Re: Is it ok to use a morphic list for MathMorphs-Revival communications?
by Milan Zimmermann 02 Jun '06

02 Jun '06

A question about Morphic lists below: On 2006 May 29 11:53, Serge Stinckwich wrote: > Le 29 mai 06 à 18:02, Milan Zimmermann a écrit : > > On 2006 May 29 03:35, Serge Stinckwich wrote: <snip> > Hum, yes a bit confuse ... maybe we could ask on the squeak-dev list > why there is two lists ? Ok, let me ask: There seem to be 2 Morphic lists: One linked from the Teams site http://squeak.org/Community/Teams/ as Morphic Stewards: http://discuss.squeakfoundation.org/cgi-bin/ezmlm-browse?list=morphic-split… and another one that I cannot find on squeak.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/morphic For the MathMorphs Revival effort, I suggested creating a list, then Serge sugested we could ask the morphic list to carry the MathMorph Revival communication there - which caused my confusion as to what list (because I did not find the "morphic" list above on squeak.org). So maybe the squeak-dev is the right forum for this question (s): - Is it general knowledge there are 2 morphic lists, and is it a good idea to have 2 - Is it ok to use one of them for the MathMorphs revival communication, or better to ask to create a new list for MathMorphs revival? Regarding the second question, we could keep communicating via private email, but that makes harder for others to join, and it seems it is good to have a public record of the changes and discussions. Thanks for any suggestions, Milan

2 3

Re: A Lisper asks, "Am I supposed to like Smalltalk?"
by Colin Putney 02 Jun '06

02 Jun '06

On May 17, 2006, at 3:55 PM, Alan Lovejoy wrote: > I think our attitude is wrong, even if we're "right." We > absolutely should > enable more "traditional" approaches for doing Smalltalk > programming. If > the Mountain won't come to Mohammed, then Mohammed must go to the > Mountain. I like the attitude, but I think it's really tough in practice. I see two problems: 1) The tools for doing "traditional" programming would have to be implemented by fairly adept Smalltalkers. This means that they're working on tools based in a paradigm they don't themselves share. They'd be creating tools they have no interest in using. Who's going to want to put effort into that, and who could do it well? 2) The reasons Smalltalk is good are basically the same as the reasons it's different. If we enable newcomers to retain their old habits and coding style, are we really doing them a service? We just make it that much less likely they'll learn the Smalltalk way, and ultimately give them no reason to use Smalltalk at all. Heck, if you want a more "traditional" version of Smalltalk, just use Ruby. The syntax is a little awkward, but otherwise, it's all there. Colin

14 22

RE: Name spaces in Spoon
by Peter Crowther 02 Jun '06

02 Jun '06

> From: Ralph Johnson > people don't generate > selector names randomly. For example, Morphic adds #isMorph and > #costumes to Object. It is possible that someone else might add > #costumes to Object, but nobody would try to define #isMorph unless > they were trying to cause trouble. Consider an effort to construct a simpler Morphic (or refactor it). You might want exactly that behaviour during development of the new Morphic, where both the old and the new versions defined the same method on the same class with different implementations. You almost certainly *would* want it in a putative future image where MVC had gone, and hence the only toolset you could use to construct the new Morphic was running using features of the old Morphic. Spoon+Naiad could resolve this in either of two ways, as I undertand it. One way would be to run the "new" Morphic in its own object memory and remote-debug it into existence; this is independent of namespaces. The other would be to allow both in the same image at the same time; this is hightly dependent on namespaces. Craig will no doubt tel me I'm talking through an inappropriate orifice here... If we're planning on refactoring Squeak, we're going to come across instances like this. At present, one has to be very, very careful when changing some parts of the image, as it's very easy to break something and leave oneself without access to tools - this is the responsibility that comes with the power of being able to change anything 'live'. I'd love to see a way of reducing this danger, and I'm very interested that Craig appears to have provided us with two distinct ways - one of which we appear to be intent on removing from consideration! - Peter

3 2

Jump to page: