July 2008 - Pharo-dev - lists.pharo.org

RE: [Pharo-project] Re: Pharo Smalltalk

by Ramon Leon

> - 1 we need freedom. We do not want to maintain: etoy, > nebraska, alice > and the like. It's about time that stuff got dumped. > in 3.9 we harvested 625 bugs fixed but apparently this was not > valuable. We think that 3.9 was a positive experience > even if marcus got sick and burnt out. 3.9 was the best release I've used yet. I'm glad someone is thinking about a *serious* open source Smalltalk instead of arguing about how they miss that stupid mouse or whining about eToys. > - 7 The squeak model is flawed. We do not want a model were > consumers can put exigences on producers. > Even if good customers are important and this is why we want to have > Aida/Seaside and a lot of cool projects > to run on pharo. The image is looking very nice so far, I loved it when I opened a menu and all the crap I never use was finally gone. I excited to see where you take Pharo, but it's off to a good start. > Because we do not want to have complain all the times. We want to be > able to invent the future, rethink design > decision, apply good practices but not maintain the cool but old > features and experiments of others. Sorry but we > did that and now this is over. > We are also sorry but we do not believe in big bang changes and we > waited too much after spoon. So may be we are > wrong, probably but again we had to do something for ourselves. You're not wrong. Make Pharo into a serious clean open source Smalltalk kernel that can run Seaside and when the masses come for Seaside they'll choose Pharo over Squeak and Pharo could easily become the larger community. All that legacy stuff in Squeak is holding it back and stopping the mainstream from giving it a chance. Squeak is ugly, cluttered, unfocused, full of garbage that most developers will never need or use, and apparently stagnant because part of the community resists any and all change. Maybe Squeak 4.0 will fix that, maybe it won't, but so far Pharo is starting to look like the best distro for the future. > We tried to really make a better Squeak and got sick, burnt > and more. So now if I do not want to destroy the > little flame we have for Smalltalk we **must** do pharo, > because this is like new dry wood that you put on the fire place. > It brings exciting future. > > Stef You did make a better Squeak, and I look forward to seeing Pharo burn the diskpacks a bit and throw out all the crap bogging Squeak down. Keep up the good work, some of us do appreciate it. Ramon Leon http://onsmalltalk.com

July 4, 2008

Re: [Pharo-project] Streams head start

by Adrian Lienhard

Hi Bill, On Jul 4, 2008, at 16:11 , Bill Schwab wrote: > I found a good starting Seaside project. It requires only minimal > security to start, and while a little clumsy, it will actually be > useful > to me, and will be a good demo piece for "selling" future Seaside > projects that will have to be very secure. Long story. Can you elaborate on the kind of security? Is this Seaside security in general or are you talking about applications that allow users to execute code in a sandbox? Or something else? I'd be interested to hear more... Adrian

July 4, 2008

[Pharo-project] Streams head start

by Bill Schwab

Damien, I found a good starting Seaside project. It requires only minimal security to start, and while a little clumsy, it will actually be useful to me, and will be a good demo piece for "selling" future Seaside projects that will have to be very secure. Long story. The good news is that it has me chipping away at the daunting task of porting lots of infrastructure code, and as a confessed streams junkie, I ran directly into the problems we have discussed. Since I "can't wait" for, nor do I expect a robust solution[*] to the silent errors problems of #next and friends, I will simply deprecate them for my own use. Toward that end, #nextOne, #nextMany:, and #nextAvailable: exist in a change set. I will no doubt discover the need to provide additional overrides. Some of my implementations are little more than checked versions of what lurks in the image; hopefully we can do better with Nile, or any and all are welcome to do better tomorrow (today for that matter<g>). It is probably a little premature, but you are welcome to review what I have, and I would very much like to discuss file stream semantics. I will add some Dolphin-influenced entry points, but some changes/additions are going to be necessary. If nothing else, file name manipulation will change for the benefit of Linux. I understand that streams are set for milestone 3, so feel free to stick to that. At the risk of appearing to want to rewrite the schedule, I'm stuck until I have at least a temporary solution, and hopefully one that provides semantics that I can map onto whatever we ultimately create. Your input would be welcome. Let me know whether and how you would like to proceed. Bill [*] if we had Cincom's backing, I would be more optimistic, but with them clinging to backward compatibility, adding selectors seems the best approach to get moving. Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

July 4, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

On Jul 4, 2008, at 1:04 AM, Matthew Fulmer wrote: > On Thu, Jul 03, 2008 at 08:32:33PM +0200, St?phane Ducasse wrote: >> I was wondering what is the amount of work to add traits support. >> The problem is that I do not have a big picture about all the palyer: >> classDecorator, classEditor.... >> It does not look complex but I'm ill so comment and a class diagram >> would help. > > SystemEditor is an experiment done by Colin to try out a model > he had to make loading truly atomic. He did the first 90% of the > work; he made the model and got it passing the test suite. > He then abandoned it and went back to working on Monticello2. > Now, I am doing the other 90% of the work: fixing bugs, and > cleaning up the code. :) I know that. I did game dev long time ago and this was like that :) > ClassDecorator is something I made just 2 weeks ago to bring > some extensibility to SystemEditor. Classes don't have the same > properties on every system. On 3.9 systems, they have a > traitDescription. In Tweak, they have fields. On Squeak 3.x, > they have an organization. In Spoon, they have tags. So, there > would be things like: > - TraitDecorator > - TweakFieldDecorator > - ClassOrganizationDecorator > - NaiadTagDecorator > > depending on the system, and which extra packages are loaded. > These decorators would insert behavior and state at various > points in the life of a class editor (definition time, build > time, migration time, etc.). They were inspired roughly by > PRDocument decorators in Pier. Ok add that to the class comment. >> Why there is no common superclass? > > MetaclassEditor needs to be a subclass of Behavior, since it > creates instances (in order to support the class protocol: the > class of a ClassEditor is a MetaclassEditor). The others, > however could be subclasses of an AbstractEditor. I have created > an AbstractEditor in my latest code (not yet uploaded), so that > doing "AbstractEditor on: anObject" will create an instance of > the correct editor class. Also, MethodDictionaryEditor and > SystemEditor could both be subclasses of a DictionaryEditor; > they share a lot of behavior like that. good. >> <snip lots of great code comments> > > Thanks for the comments in the code. I will definitely apply > them. > > Also, thanks for your comments. They are helping a lot. I have a > lot of the makings of a design document now. Excellent. I asked david to improve the OB browser to display forms in the text pan when it browses Manifesto classes and methods with PNG I will ask him if this is possible to make a try for real. Thanks matthew. > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/

July 4, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

On Jul 4, 2008, at 12:41 AM, Matthew Fulmer wrote: > On Thu, Jul 03, 2008 at 08:09:10PM +0200, St?phane Ducasse wrote: >> hi Matthew >> >> I loaded HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' >> And I will load MC1.6. Now could you do me a favor. >> >> I ***hate*** badly formatted code >> >> <snipped a bunch of code from Launcher> > > I went through all the methods in package Installer-Launcher and > formatted them propperly. Excellent! Thanks. >> I went over all the methods of the installer and cleaned them. > > Where did you put them? Please upload your fixes to > http://www.squeaksource.com/Installer > > The repository is world-writable This is already in. I asked keith if I could publish there. >> Of course method comments would help too. > > Installer is documented at http://installer.pbwiki.com/Installer > It is the package Installer-Core > > Launcher, a command-line parser, is documented at > http://installer.pbwiki.com/Launcher > It is the package Installer-Launcher Documentation outside the system does not work. When you are in the train or when the server crash. I really want that documentation are in the image in pharo. Colin lost his documentation of Monticello (luckily I copied it for a lecture) a while back. > I don't know much about Launcher. I've never used it, so I can't > really comment on it. Thanks. > > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 4, 2008

Re: [Pharo-project] WideStringTest>>testSubstrings

by StÃ©phane Ducasse

Sorry I was ill and I should not have done it. I read your comment but they slipped through my mind. Stef On Jul 3, 2008, at 11:06 PM, Norbert Hartl wrote: > Stef, > > you propably missed my comment on the last SLICE. You > need to do a > > String initialize > > to cope the changes. After that the test will succeed. > > Norbert > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 4, 2008

Re: [Pharo-project] Re: Monticello 1.5

by Matthew Fulmer

On Thu, Jul 03, 2008 at 08:32:33PM +0200, St?phane Ducasse wrote: > I was wondering what is the amount of work to add traits support. > The problem is that I do not have a big picture about all the palyer: > classDecorator, classEditor.... > It does not look complex but I'm ill so comment and a class diagram > would help. SystemEditor is an experiment done by Colin to try out a model he had to make loading truly atomic. He did the first 90% of the work; he made the model and got it passing the test suite. He then abandoned it and went back to working on Monticello2. Now, I am doing the other 90% of the work: fixing bugs, and cleaning up the code. ClassDecorator is something I made just 2 weeks ago to bring some extensibility to SystemEditor. Classes don't have the same properties on every system. On 3.9 systems, they have a traitDescription. In Tweak, they have fields. On Squeak 3.x, they have an organization. In Spoon, they have tags. So, there would be things like: - TraitDecorator - TweakFieldDecorator - ClassOrganizationDecorator - NaiadTagDecorator depending on the system, and which extra packages are loaded. These decorators would insert behavior and state at various points in the life of a class editor (definition time, build time, migration time, etc.). They were inspired roughly by PRDocument decorators in Pier. > Why there is no common superclass? MetaclassEditor needs to be a subclass of Behavior, since it creates instances (in order to support the class protocol: the class of a ClassEditor is a MetaclassEditor). The others, however could be subclasses of an AbstractEditor. I have created an AbstractEditor in my latest code (not yet uploaded), so that doing "AbstractEditor on: anObject" will create an instance of the correct editor class. Also, MethodDictionaryEditor and SystemEditor could both be subclasses of a DictionaryEditor; they share a lot of behavior like that. > <snip lots of great code comments> Thanks for the comments in the code. I will definitely apply them. Also, thanks for your comments. They are helping a lot. I have a lot of the makings of a design document now. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

July 3, 2008

Re: [Pharo-project] Re: Monticello 1.5

by Matthew Fulmer

On Thu, Jul 03, 2008 at 08:09:10PM +0200, St?phane Ducasse wrote: > hi Matthew > > I loaded HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' > And I will load MC1.6. Now could you do me a favor. > > I ***hate*** badly formatted code > > <snipped a bunch of code from Launcher> I went through all the methods in package Installer-Launcher and formatted them propperly. > I went over all the methods of the installer and cleaned them. Where did you put them? Please upload your fixes to http://www.squeaksource.com/Installer The repository is world-writable > Could you pay attention to that? > I think that uniformity is important. Ok. I shall. Thanks for noticing. > Of course method comments would help too. Installer is documented at http://installer.pbwiki.com/Installer It is the package Installer-Core Launcher, a command-line parser, is documented at http://installer.pbwiki.com/Launcher It is the package Installer-Launcher I don't know much about Launcher. I've never used it, so I can't really comment on it. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

July 3, 2008

[Pharo-project] WideStringTest>>testSubstrings

by Norbert Hartl

Stef, you propably missed my comment on the last SLICE. You need to do a String initialize to cope the changes. After that the test will succeed. Norbert

July 3, 2008

[Pharo-project] Fwd: I'm interesting in knowing more on your atomic loading

by StÃ©phane Ducasse

Begin forwarded message: > From: Matthew Fulmer <tapplek(a)gmail.com> > Date: July 3, 2008 8:38:24 PM CEDT > To: stephane ducasse <stephane.ducasse(a)free.fr> > Cc: Matthew Fulmer <tapplek(a)gmail.com>, Keith Hodges <keith_hodges(a)yahoo.co.uk > > > Subject: Re: I'm interesting in knowing more on your atomic loading > > On Thu, Jul 03, 2008 at 07:21:21PM +0200, stephane ducasse wrote: >> Hi matthew >> >> how can i learn about your atomic loading? >> >> Stef > > ===== History ===== > > Atomic loading is a feature Colin Putney implemented for MC2, > then released as a separate, quite unstable library: > SystemEditor > > http://www.squeaksource.com/SystemEditor/ > > Goran and I picked up this library as a core component of > DeltaStreams, and we fixed many bugs it had with loading > different combinations of things, due to not being tested in > production. In the meantime, Keith Hodges wrote a new package > loader for Monticello 1.5 that hooked into SystemEditor to take > advantage of it's atomic loading property. It hardly worked at > all, but the principle was there. See the class MCPackageLoader2 > in Monticello 1.5: > > http://www.squeaksource.com/mc/ > > I have since stopped working on DeltaStreams and started working > heavily with Keith in improving the basic tools in the image and > making new ones. Since I was already familiar with SystemEditor > due to my work on DeltaStreams, I volunteered to work on package > loader 2. I fixed a dozen or so bugs in both package loader 2 > and SystemEditor, and now it is able to load quite a few > packages. It is still beta phase though. It is not yet able to > cope with the following: > > Byte/Word/Weak classes > Traits > Tweak classes > > I'm fixing those inadequacies in the order listed. Once they are > fixed, we will release PackageLoader2 as the default in > Monticello, and increment the version number of Monticello to > 1.6. > > ===== How it works ==== > > SystemEditor has a set of classes (editor classes) that respond > to the same protocol as Class, Metaclass, MethodDictionary, > ClassOrganizer, SystemDictionary, and other related core > classes. Each one acts as an "editor" on an existing object in > the system. These editors respond to the same protocol as the > object they edit, but maintain changes internally, usually as a > list of additions/removals. When the time comes to commit the > changes (See SystemEditor>>commit), all these editors are passed > a MigrationTransaction object, and are asked to submit the old > and new copy of the object they are editing, which will be > swapped at commit time. When all objects have done this, > MigrationTransaction builds two arrays: one of old objects, and > one of new, and invokes the primitive > Array>>exchangeElementIdentityWith: , which does a bulk identity > swap (see MigrationTransaction>>commit). Everything that needs > to change is swapped: Recompiled classes, instances of those > classes, new methodDictionaries for classes that don't need > recompiling, Smalltalk, the SystemDictionary instance, > ClassOrganization instances, and so on, all during one > primitive. > > ===== Status ===== > > I'm fairly confident in Monticello1.6-beta, as it currently > exists. I use it as my default loader in all of my images, > except when I am dealing with Tweak in my croquet images. > > To try it out, do the following: > HTTPSocket httpFileIn: 'installer.pbwiki.com/f/LPF.st'. > Installer install: 'Monticello16-Beta' > > This loads LevelPlayingField (= Installer and MC1.5) and then > runs my script to load SystemEditor and activate PackageLoader2. > > Pages you may want to read: > > LevelPlayingField: a script to load Installer and MC1.5 into > most any image in use: > http://installer.pbwiki.org/LevelPlayingField > > The script that loads MC1.5: > http://installer.pbwiki.org/LevelPlayingField-Monticello15 > > The script that activates MCPackageLoader2 (it is under > "Contributed Scripts" in the sidebar) > http://installer.pbwiki.org/Monticello16-Beta > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ >

July 3, 2008