- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] About Morph cleaning and new infrastructure

by StÃ©phane Ducasse

We can't be all that wrong :) Stef >> Now we should learn from squeak and make sure that we have an >> infrastructure >> that allows one to plug difference UI frameworks (no "Smalltalk >> isMorphic" >> in the future). >> In addition we want to make sure: >> - that we can plug different UIFrameworks (Miro, Morphic30, >> YSqueak >> or something else) > > It seems to me this is part of what Newspeak is doing already.

July 3, 2008

Re: [Pharo-project] About Morph cleaning and new infrastructure

by Damien Cassou

On Thu, Jul 3, 2008 at 7:51 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Now we should learn from squeak and make sure that we have an infrastructure > that allows one to plug difference UI frameworks (no "Smalltalk isMorphic" > in the future). > In addition we want to make sure: > - that we can plug different UIFrameworks (Miro, Morphic30, YSqueak > or something else) It seems to me this is part of what Newspeak is doing already. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

July 3, 2008

[Pharo-project] Re: Pharo Smalltalk

by StÃ©phane Ducasse

>>> Couldn't you do this on Squeak? >> > > So, couldn't you continue on Squeak? Because - 1 we need freedom. We do not want to maintain: etoy, nebraska, alice and the like. We do not want to have other people putting stress and their dreams on us. We did that for 3.9 and people pissed on us (random refactorers...) complained that we pushed traits in Squeak..... read the archives of the mailing-list everything is there. - 2 people said that we did not have a process, that social engineering was the solution (which is true when you apply it). - 3 we proposed a 3.10 roadmap and people complained. - 4 we proposed our help to 3.10 but it was declined. - 6 after the sad adventure of 3.10 and the lack of reaction of people we decided that we did our best. 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. - 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. - 8 I'm sick of opening squeak and having to turn my eyes from problems. After a certain point we should learn and take decision even if they are not easy. > I can't understand why you forked the project instead of improving it. 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. >> I do not know. >> FunSqueak ;D > > So you quit Squeak... Not really. We will work on a new Volume Two and we did not renamed yet our book Pharo by Example :) May be pharo will be a cool squeak distribution or something else. For now our focus is getting things done. > I still can't see a valid reason for this fork. There are plenty of them but may be you are not in the right places to understand them. Here is an extra one. I have no choice this is pharo or ruby and I'm not joking. I was terribly sad when I see people willing to go back to 3.8! We spent a lot of energy to make sure that the forks could reunite but now this is over. 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

July 3, 2008

Re: [Pharo-project] About Morph cleaning and new infrastructure

by StÃ©phane Ducasse

Hi adrian > Hi Stef, > > This is exciting news. > > I think the VM sleeping feature is important because this is > something we do but by suspending/resuming the VM process from the > outside (else with hundreds of images the idle CPU usage kills > ressources). So this is something that also Seaside servers will > profit from. We know :) This is also why ESUG is supporting this work :) > Those changes will require work on the VM and in the image, I > suspect. Will this be shared with Squeak? Yes. This is the idea! We do not want to hear that ESUG is only taking care of Pharo. So some idiots say that in the future smashed them. I start to be fed up by idiots :). Then we will merge the fixes in Pharo. And people may want to do the same for they own fork. Stef

July 3, 2008

Re: [Pharo-project] About a file abstraction layer

by StÃ©phane Ducasse

I do not know. I have the impression this is at another level. What URI provides is a common abstraction for ftp, local files,.... But mike will comment on that (I'm ill at hilaire's place right now and they have a social event dinner :)). On Jul 3, 2008, at 8:37 PM, Damien Cassou wrote: > What about Rio? > > On Thu, Jul 3, 2008 at 8:00 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Hi guys >> >> With mike we also discussed about URI and the way sophie people >> used to >> abstract away >> from the file system. >> The idea (may be I'm summarizing a bit wrong), is to use URI >> consistently >> even to access local file. >> >> He told me that with this practice they got away from platform >> dependent >> code in Sophie. >> >> Mike also rewrote and clean a large part of the network-package. >> We got some trouble to load it in pharo since this was not made to >> be loaded >> in pharo. >> >> Mike will work on a loadable version. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 3, 2008

[Pharo-project] Re: Pharo Smalltalk

by StÃ©phane Ducasse

> Couldn't you do this on Squeak? but we are doing that starting with squeak 3.9 :) > How much Pharo will differ from Squeak? We do not know but it will. > Do you intend to rebase with a new VM or do you intend to just > improve Smalltalk code? For the moment we do not have the expertise to change the VM and we will reuse the one of Squeak. There will be also a MIT VM with a JIT so :) And also Squeak VM running on ipod :) > What about license issues? I've seen Pharo is MIT. Yes all the code of pharo will be MIT. We will only include MIT code and all the commiters have to sign the agreement. > I've seen many developers and a busy mailing list, I expect more improvements to come when the people interested by software development will join. For the moment we are in warm up mode. > what will be the future of Squeak? I do not know. FunSqueak ;D >> Well what I will have in mind depends on what you reply to the >> above questions :P > > Thanks for your reply.

July 3, 2008

Re: [Pharo-project] About Morph cleaning and new infrastructure

by Adrian Lienhard

Hi Stef, This is exciting news. I think the VM sleeping feature is important because this is something we do but by suspending/resuming the VM process from the outside (else with hundreds of images the idle CPU usage kills ressources). So this is something that also Seaside servers will profit from. Those changes will require work on the VM and in the image, I suspect. Will this be shared with Squeak? Cheers, Adrian On Jul 3, 2008, at 19:51 , StÃ©phane Ducasse wrote: > Hi guys > > Here is the summary of the discussion we got with mike today. > > In the context of the ESUG sponsored effort mike and john will work > on making the > - VM sleeping correctly, > - using a semaphore do avoid event polling and all the rest related > to that. > - fixing the event handling. > > Now the point is that mike will not change Morph, just clean what is > needed so that > the event system and the polling gets cleaned. The idea is that > Morph cannot be cleaned. > > In parallel mike has been working on ySqueak and in this context he > worked on > a new morphic model. > > Now we should learn from squeak and make sure that we have an > infrastructure > that allows one to plug difference UI frameworks (no "Smalltalk > isMorphic" in the future). > In addition we want to make sure: > - that we can plug different UIFrameworks (Miro, Morphic30, YSqueak > or something else) > - kernel class do not depend on UI. > > So mike based on his sophie experience designed a new event model > based on Announcement > which support well multiple input devices, different platform key, > different windowing bindings for > future native support. > > So the idea is the following: > - let make Morphic smaller and cleaner but acknowledge that Morphic > is not the long term future. > - mike will produce a new event model, that the other UI frameworks > could use and extend. He will ask fro feedback. > - Agree that we use announcement as an infrastructural foundation. > - make sure (with your help and feedback) that we can plug another > UI framework (in particular in the event loop handler > should support a registration mechanism. > - It would be nice to see how miro can use the new event model and > be plug in pharo > as well as the ySqueak new model. > > I would like to lower the frustration of people. The point is not to > chose a framework against another one > but to make sure that we can load and plug different frameworks. > > So please comment. > > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 3, 2008

Re: [Pharo-project] About a file abstraction layer

by Damien Cassou

What about Rio? On Thu, Jul 3, 2008 at 8:00 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > With mike we also discussed about URI and the way sophie people used to > abstract away > from the file system. > The idea (may be I'm summarizing a bit wrong), is to use URI consistently > even to access local file. > > He told me that with this practice they got away from platform dependent > code in Sophie. > > Mike also rewrote and clean a large part of the network-package. > We got some trouble to load it in pharo since this was not made to be loaded > in pharo. > > Mike will work on a loadable version. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

July 3, 2008

[Pharo-project] Re: Pharo Smalltalk

by StÃ©phane Ducasse

Hi bruno > I've head about your new project Pharo. Good :) > I'm the author of Smalltalk YX (Syx) http://syx.googlecode.com. I had a look a while back. > Another developer recently developed a VM inspired to Syx and now > we're going to merge the projects, since we have the same vision. Excellent! Join forces :) > This is the post in the mailing list: http://groups.google.com/group/syx-discuss/browse_thread/thread/55507afadab… > > I'd like to know the main purposes of your new implementation, Produce a good Smalltalk with nice, well documented and libraries so that people can develop cool projects and others can learn from the system. We want to remove cruft from the system. > are you interested in a possible collaboration? yes! Tell us what you have in mind. > I haven't seen any source code yet. I think our two projects have > many things in common. The code is available on the ugly pharo web page http://pharo.gforge.inria.fr/ Stef > > > Let me know please. > Best regards, > > - -- > http://syx.googlecode.com - Smalltalk YX > http://lethalman.blogspot.com - Thoughts about computer technologies > http://www.ammazzatecitutti.org - Ammazzateci tutti > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFIbXq1w9Qj+8Kak3ERAmZBAJ4ng2GLUD+rVuuhu2kAFjeKozyW5QCeO+WG > /tnA/LYuTonX9bzJDZBu5bs= > =og7s > -----END PGP SIGNATURE-----

July 3, 2008