I tried yesterday LPF on Pharo, infortunately when loading Magma beta MC blows on my face again. I will give a fresh start again. Hilaire 2008/6/27 Matthew Fulmer <tapplek@gmail.com>:

On Fri, Jun 27, 2008 at 09:32:35AM +0200, Hilaire Fernandes wrote:

...

Oh, Chris I am just a dumb developer and I don't know much about the tools, I just know it is a pain to get MC 1.5 working.

Indeed. Monticello is hard to load, precisely because the loader is being modified while loading. Thus, we have a script that is able to reliably load Monticello 1.5 onto any image:

http://installer.pbwiki.org/LevelPlayingField

To run it, do this: (I just tested it and got it working in Pharo)

HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st'

The actual job of loading Monticello is done here:

http://installer.pbwiki.org/LevelPlayingField-Monticello15

Notice the technique: first a plain file-out of PackageInfo and Monticello is loaded, next, nearly the exact same packages is loaded via Monticello. This ensures that the changes made to Monticello while Monticello is running are minimal. I keep that script up-to-date as I make changes to Monticello 1.5.

Monticello and PackageInfo have a number of improvements:

- Packages can be loaded out-of-order, as orphaned methods and classes are stored in an Orphanage, which is revisited when loading later packages - Tests can be separately packages from the main code, without extensive repackaging: Name a package Monticello.impl to get classes in Monticello-*, except for those that end in *-Tests, or name a package Monticello.tests to get all packages in categories Monticello-*-Tests - A new dual version sorter, able to view changes between arbitrary versions in a repository; in the right pane of the MC browser, use the menu item "open dual changes browser" - Working MonticelloConfigurations - I am fixing bugs in a new loader for Monticello that does code loading in a truly atomic fashion: code is swapped into the system, and pointers are revised in exactly ONE primitive. I have it working well enough that I made it my default loader. It is able to load problematic packages that are sensitive to inconsistencies during loading, like Monticello and Morphic. As an Acid test, I am able to load Monticello using the new package loader, which has, until now, been impossible in any version of Monticello. The biggest remaining issue is Traits support; Packages with traits are not supported. To try it out, run this after running the LPF script above:

Installer install: 'Monticello16-Beta'

In the past, people have had various problems with Monticello 1.5, such as loading FFI and strange issues with Instance variables. Keith and I were somewhat unaware of these until they were brought to our attention on IRC, and have since been fixed. This product is under active development, and our goal is to get the same very useful version of Monticello running on every active Squeak platform, and we have done so, to the best of our knowledge. So if you find a problem, please let us know and we will fix it, most likely within the hour. IRC is the best way; mailing lists are next.

I realize LevelPlayingField is not the preferred mechanism to load stuff into Pharo, and it brings along two other things beside Monticello 1.5 (namely, Installer and Launcher). I will try to prepare something suitable for loading Monticello 1.5 into Pharo, but it cannot be a plain SLICE package, due to the Monticello loading problems I explained above. I'll read up at http://code.google.com/p/pharo/wiki/HowToContribute

I'll also see what changes Stef and Lukas made to Monticello as part of Pharo and attempt to merge them.

-- Matthew Fulmer -- http://mtfulmer.wordpress.com/

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- http://blog.ofset.org/hilaire

Hi matthew Thanks for your explanation. We were afraid by MC1.5 because - the atomic loading features as hacked by ralph looked dubious to us. we did not want to break the dependency mechanism - the problem with PLF is that it looks like a black box that loads a lot of stuff and we do not know why - since we do **everything** with MC is should work 100% or we are dead. Now we would be happy to ask our MC expert (yes I looked at adrian and lukas) :) to check your changes and slowly incorporate them. Alex did a small but cool improvement: dirty packages are always at the top of the mc browser. We found that cool and integrate it.

...

Indeed. Monticello is hard to load, precisely because the loader is being modified while loading. Thus, we have a script that is able to reliably load Monticello 1.5 onto any image:

http://installer.pbwiki.org/LevelPlayingField

To run it, do this: (I just tested it and got it working in Pharo)

HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st'

The actual job of loading Monticello is done here:

http://installer.pbwiki.org/LevelPlayingField-Monticello15

Notice the technique: first a plain file-out of PackageInfo and Monticello is loaded, next, nearly the exact same packages is loaded via Monticello. This ensures that the changes made to Monticello while Monticello is running are minimal. I keep that script up-to-date as I make changes to Monticello 1.5.

Monticello and PackageInfo have a number of improvements:

- Packages can be loaded out-of-order,

what does it mean exactly?

as orphaned methods and classes are stored in an Orphanage, which is revisited when loading later packages

- Tests can be separately packages from the main code, without extensive repackaging: Name a package Monticello.impl to get classes in Monticello-*, except for those that end in *-Tests, or name a package Monticello.tests to get all packages in categories Monticello-*-Tests

We would go for real packages = without relying only on naming conventions so I do not know if this one is really useful.

- A new dual version sorter, able to view changes between arbitrary versions in a repository; in the right pane of the MC browser, use the menu item "open dual changes browser"

Cool

- Working MonticelloConfigurations That I would really want and per package source so that we can load magritte in luask repos and moose in squeaksource and ob in wiresong

- I am fixing bugs in a new loader for Monticello that does code loading in a truly atomic fashion: code is swapped into the system, and pointers are revised in exactly ONE primitive. I have it working well enough that I made it my default loader.

This is really important.

It is able to load problematic packages that are sensitive to inconsistencies during loading, like Monticello and Morphic. As an Acid test, I am able to load Monticello using the new package loader, which has, until now, been impossible in any version of Monticello.

Good

The biggest remaining issue is Traits support;

Argh this is on my pipeline to check andreas proposal to have traits as subclass of classdescription but I did not find the time to check that.

Packages with traits are not supported. To try it out, run this after running the LPF script above:

Installer install: 'Monticello16-Beta'

In the past, people have had various problems with Monticello 1.5, such as loading FFI and strange issues with Instance variables. Keith and I were somewhat unaware of these until they were brought to our attention on IRC, and have since been fixed. This product is under active development, and our goal is to get the same very useful version of Monticello running on every active Squeak platform, and we have done so, to the best of our knowledge. So if you find a problem, please let us know and we will fix it, most likely within the hour. IRC is the best way; mailing lists are next.

Excellent.

I realize LevelPlayingField is not the preferred mechanism to load stuff into Pharo,

exact. I will be against loading stuff nobody look at.

and it brings along two other things beside Monticello 1.5 (namely, Installer and Launcher).

I like the installer even if one day we will refactor it :)

I will try to prepare something suitable for loading Monticello 1.5 into Pharo, but it cannot be a plain SLICE package, due to the Monticello loading problems I explained above. I'll read up at http://code.google.com/p/pharo/wiki/HowToContribute

Sure this is the rule for simple stuff. after we can use Installer or Cs.

I'll also see what changes Stef and Lukas made to Monticello as part of Pharo and attempt to merge them.

We wanted to have a rock solid version because it is and will be our backbone.

-- Matthew Fulmer -- http://mtfulmer.wordpress.com/

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Fri, Jun 27, 2008 at 01:09:36PM +0200, St?phane Ducasse wrote:

Hi matthew

Thanks for your explanation. We were afraid by MC1.5 because - the atomic loading features as hacked by ralph looked dubious to us.

Ralph's pseudo-atomic loader is not in MC1.5, according to Keith; however, a different pseudo-atomic loader written by keith is the default loader. It also includes the old loader (disabled by default), and an experimental true atomic loader (also disabled by default).

we did not want to break the dependency mechanism

As far as I am able to tell, MC1.5 has not touched the dependency mechanism, and it works fine on what I have tried it with (which is only Nile, so far)

- the problem with PLF is that it looks like a black box that loads a lot of stuff and we do not know why

LPF loads Installer, then Monticello 1.5, then Loader. That is all. It does this by using Installer, which is able to fetch scripts off the web, dispatching optionally based on the image version (Squeak3.9, Pharo0.1), and by author initials. Look at the bottom of http://installer.pbwiki.com/LevelPlayingField First it runs the script LevelPlayingField-Preamble, then it runs one of the LevelPlayingField-<image version> scripts, and finally it runs the LevelPlayingField-Postscript script That is all it does. The scripts are linked and viewable on the web, so you can check what they do, and edit them by logging into the wiki (password is squeak)

- since we do **everything** with MC is should work 100% or we are dead.

So do we. We keep it working

Now we would be happy to ask our MC expert (yes I looked at adrian and lukas) :) to check your changes and slowly incorporate them.

Ok. Do what suits your fancy. Seems like a strange approach, though, since that is exactly what MC1.5 is: a merge of all the features from all the older forks of Monticello: impara, 3.9, with a much more careful eye on backward compatability. Unlike Monticello in 3.9, MC1.5 can save packages that Monticello in 3.8 is able to read and load.

Alex did a small but cool improvement: dirty packages are always at the top of the mc browser. We found that cool and integrate it.

I'll integrate it too. Thanks for the notification. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

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 writeTo: fileName in: directory fileout := fileName. dir := FileDirectory on: (FileDirectory default fullNameFor: directory). dir assureExistence. stdout ^stdout printWith: aBlock fileout ifNil: [ ^aBlock value: stdout ]. FileStream detectFile: [ dir forceNewFileNamed: fileout ] do: aBlock it should be writeTo: fileName in: directory fileout := fileName. dir := FileDirectory on: (FileDirectory default fullNameFor: directory). dir assureExistence. stdout ^stdout printWith: aBlock fileout ifNil: [ ^aBlock value: stdout ]. FileStream detectFile: [ dir forceNewFileNamed: fileout ] do: aBlock I went over all the methods of the installer and cleaned them. Could you pay attention to that? I think that uniformity is important. Of course method comments would help too. Stef On Jun 27, 2008, at 11:41 AM, Matthew Fulmer wrote:

On Fri, Jun 27, 2008 at 09:32:35AM +0200, Hilaire Fernandes wrote:

...

Oh, Chris I am just a dumb developer and I don't know much about the tools, I just know it is a pain to get MC 1.5 working.

Indeed. Monticello is hard to load, precisely because the loader is being modified while loading. Thus, we have a script that is able to reliably load Monticello 1.5 onto any image:

http://installer.pbwiki.org/LevelPlayingField

To run it, do this: (I just tested it and got it working in Pharo)

HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st'

The actual job of loading Monticello is done here:

http://installer.pbwiki.org/LevelPlayingField-Monticello15

Notice the technique: first a plain file-out of PackageInfo and Monticello is loaded, next, nearly the exact same packages is loaded via Monticello. This ensures that the changes made to Monticello while Monticello is running are minimal. I keep that script up-to-date as I make changes to Monticello 1.5.

Monticello and PackageInfo have a number of improvements:

- Packages can be loaded out-of-order, as orphaned methods and classes are stored in an Orphanage, which is revisited when loading later packages - Tests can be separately packages from the main code, without extensive repackaging: Name a package Monticello.impl to get classes in Monticello-*, except for those that end in *-Tests, or name a package Monticello.tests to get all packages in categories Monticello-*-Tests - A new dual version sorter, able to view changes between arbitrary versions in a repository; in the right pane of the MC browser, use the menu item "open dual changes browser" - Working MonticelloConfigurations - I am fixing bugs in a new loader for Monticello that does code loading in a truly atomic fashion: code is swapped into the system, and pointers are revised in exactly ONE primitive. I have it working well enough that I made it my default loader. It is able to load problematic packages that are sensitive to inconsistencies during loading, like Monticello and Morphic. As an Acid test, I am able to load Monticello using the new package loader, which has, until now, been impossible in any version of Monticello. The biggest remaining issue is Traits support; Packages with traits are not supported. To try it out, run this after running the LPF script above:

Installer install: 'Monticello16-Beta'

In the past, people have had various problems with Monticello 1.5, such as loading FFI and strange issues with Instance variables. Keith and I were somewhat unaware of these until they were brought to our attention on IRC, and have since been fixed. This product is under active development, and our goal is to get the same very useful version of Monticello running on every active Squeak platform, and we have done so, to the best of our knowledge. So if you find a problem, please let us know and we will fix it, most likely within the hour. IRC is the best way; mailing lists are next.

I realize LevelPlayingField is not the preferred mechanism to load stuff into Pharo, and it brings along two other things beside Monticello 1.5 (namely, Installer and Launcher). I will try to prepare something suitable for loading Monticello 1.5 into Pharo, but it cannot be a plain SLICE package, due to the Monticello loading problems I explained above. I'll read up at http://code.google.com/p/pharo/wiki/HowToContribute

I'll also see what changes Stef and Lukas made to Monticello as part of Pharo and attempt to merge them.

-- Matthew Fulmer -- http://mtfulmer.wordpress.com/

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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. Stef Why there is no common superclass? Behavior subclass: #MetaclassEditor instanceVariableNames: 'editor superEditor instVarNames methods organization traitComposition' classVariableNames: '' poolDictionaries: '' category: 'SystemEditor-Editors' Object subclass: #ClassEditor instanceVariableNames: 'subject product system superEditor name type instVarNames classVarNames sharedPools methods category organization properties decorators' classVariableNames: 'ReservedNames' poolDictionaries: '' category: 'SystemEditor-Editors' initialize migrators := OrderedCollection new. super initialize would not hurt edPrepareMigration: txn for: aClassEditor txn addMigrator: (ObjectMigrator origin: self subject destination: (self buildFor: aClassEditor)). (additions isEmpty and: [removals isEmpty]) ifFalse: [aClassEditor organization]. tnx? and a comment? at: aSymbol ifAbsent: absentBlock (removals includes: aSymbol) ifTrue: [^ absentBlock value]. additions at: aSymbol ifPresent: [:editor | ^ editor]. self subject at: aSymbol ifPresent: [:aCompiledMethod | ^ self add: (MethodEditor source: (classEditor subject sourceCodeAt: aSymbol) classified: (classEditor organization subject categoryOfElement: aSymbol) stamp: aCompiledMethod timeStamp notifying: nil logging: true )]. ^ absentBlock value may be a better formatting would help setSubject: aClass system: aSystemEditor subject := aClass. system := aSystemEditor. subject ifNil: [superEditor := aSystemEditor at: #Object. name := #Annonymous. type := #normal. instVarNames := Array new. classVarNames := Array new. sharedPools := Array new. methods := MethodDictionaryEditor for: self. self class edInitializeForNewClass]. decorators := ClassDecorator decoratorsFor: self. I was wondering when a class would be nil. So the logic should be mentioned somewhere. subclass: aSymbol instanceVariableNames: instString classVariableNames: classString poolDictionaries: poolString category: categoryString ^ ((system at: aSymbol ifAbsent: [ ClassEditor on: nil for: system]) edName: aSymbol superclassEditor: self type: #normal instVarString: instString classVarString: classString poolImports: poolString category: categoryString) edRegisterEditor

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/

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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi, Please find enclosed a proposal for the pharo website and a new version of the logo. The website proposal can seems strange at first but i think it can be cool to have something a little bit different and colored like this. I have took for this example the text from IOlanguage because i find this site very good for the organisation and the clarity. There are things to change but would like to have your opinion Hope you will like it regards, Samuel

pharo-project.org is available and we have the design so now .... we should get cmsbox :) Stef On Jul 8, 2008, at 10:54 AM, Damien Cassou wrote:

Love it

On Sun, Jul 6, 2008 at 12:51 PM, Samuel MORELLO <samuel.morello@ouvanous.com> wrote:

...

Hi,

Please find enclosed a proposal for the pharo website and a new version of the logo. The website proposal can seems strange at first but i think it can be cool to have something a little bit different and colored like this.

I have took for this example the text from IOlanguage because i find this site very good for the organisation and the clarity. There are things to change but would like to have your opinion

Hope you will like it

regards,

Samuel

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Tue, 2008-07-08 at 11:09 +0200, Stéphane Ducasse wrote:

pharo-project.org is available and we have the design so now .... we should get cmsbox :)

Ah, you chose Hetzner as hosting provider. Very good. Most of our servers are there, too :) Is this a dedicated machine or a web hosting thing? Norbert

Stef

On Jul 8, 2008, at 10:54 AM, Damien Cassou wrote:

...

Love it

On Sun, Jul 6, 2008 at 12:51 PM, Samuel MORELLO <samuel.morello@ouvanous.com> wrote:

...

Hi,

Please find enclosed a proposal for the pharo website and a new version of the logo. The website proposal can seems strange at first but i think it can be cool to have something a little bit different and colored like this.

I have took for this example the text from IOlanguage because i find this site very good for the organisation and the clarity. There are things to change but would like to have your opinion

Hope you will like it

regards,

Samuel

_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi matthew we wanted to see if MC1.6 (the one with actomic loader) could load the compiler fixes Compiler-md.67 available in pharoInbox We tried

HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st'

and it broke on us. so two requests: - could you give a try and tell us if you can load the package? - do you have a version of MC1.6 that does not really on LPF (whatever)? Stef

Matthew Fulmer wrote:

On Fri, Sep 12, 2008 at 05:41:17PM +0200, St?phane Ducasse wrote:

...

Hi matthew

we wanted to see if MC1.6 (the one with actomic loader) could load the compiler fixes Compiler-md.67 available in pharoInbox

We tried

...

HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st'

The LPF script only loads MC1.5 you need to load SystemEditor and enable the atomic loading preference. This will do it. Installer install: 'Monticello16-Beta'.

...

and it broke on us.

so two requests: - could you give a try and tell us if you can load the package?

No; it is broken for everybody. I've heard this report a couple of times. It seems we need to change the hosting of LPF

No we dont, we just have to slow requests down a bit. I put a couple of delays in it should work now

...

- do you have a version of MC1.6 that does not really on LPF (whatever)?

No; LPF is the script to load MC1.5. However, I think I'll try moving LPF off of pbwiki and into something that builds a .sar file, hosted on svn or squeaksource or something.

The first half of the script is the bootstrap of Installer in http://installer.pbwiki.com/f/LPF.st The second half of the script is available via Installer view: 'LevelPlayingField'. Keith p.s. Alexander, please don't edit Installer and break it for everyone else. Installer is for all squeak images, not just for Pharo. p.p.s. Please keep sufficient compatibility in Pharo so at least Installer can get past the initial bootstrap.

...

...

...

HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st'

The LPF script only loads MC1.5 you need to load SystemEditor and enable the atomic loading preference. This will do it.

OK

Installer install: 'Monticello16-Beta'.

...

...

- do you have a version of MC1.6 that does not really on LPF (whatever)?

No; LPF is the script to load MC1.5. However, I think I'll try moving LPF off of pbwiki and into something that builds a .sar file, hosted on svn or squeaksource or something.

The first half of the script is the bootstrap of Installer in http://installer.pbwiki.com/f/LPF.st

The second half of the script is available via

Installer view: 'LevelPlayingField'.

Keith

p.s. Alexander, please don't edit Installer and break it for everyone else. Installer is for all squeak images, not just for Pharo.

Can you tell us what were the changes?

p.p.s. Please keep sufficient compatibility in Pharo so at least Installer can get past the initial bootstrap. Sure.