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