Stefan,

I don't fully understand what you have in mind, but the thought that packaging 
is weak in Pharo is not a new one.  In the early days of Dolphin's packaging 
system, it was not terribly good about loading prerequisites (that improved 
greatly over time), so I built a tool called Migrate that had presence in both 
an outgoing image and a new one.  The outgoing portion figured out which 
packages to save and built a script for loading them into the new image.  The 
new image portion did the obvious, along with picking up some loose methods 
saved along with the packages - don't ask :)

In Pharo, I was stunned to find that I was apparently expected to individually 
save any number of packages, each requiring a multi-step process, using the MC 
browser, and immediately thought of Migrate.  The result is not as slick as 
what I was able to build in Dolphin, but it works for me.  You are welcome to 
look for the code in the Pharo In Box and try it if you think it will help you 
(if only to avoid problems in the future, which I fear is what would happen).  
Something in #suspectMethodsReport might be adaptable to your current 
situation??

There are no warranties that the code will load and work as-is.  See my Wiki 
and bug tracker entries on streams (e.g. #nextOne, #nextMany:, etc.) for things 
that you should be using anyway<g> and will likely need to get Migrate to run.  
If you want to use it, I will be happy to help you get it going.  The Migrate 
class comment appears below.

Bill



CONFIGURE
=========
Configure it using #homeGrownPackageNames and #me to tell it which packages are 
intended to hold your work, and how to identify you from the (misnomer!!!) 
#timeStamp aspects of the compiled methods you produce.


SAVE YOUR WORK
==============
Use #suspectMethodsReport to produce a listing of class>>selector names that 
might be in danger of being orphaned in your current image.

Use #homeGrownPackgesSaveWithMessage: to save all of the identified home grown 
packages in the next version and with the common text message.



BUILD A NEW IMAGE
=================
Load Migrate into a new image.  If you want a web image, evaluate #web and then 
save the image.

It wants underscore_madness.cs, and loads SIXX and other packages of interest 
to me; you can edit as needed to remove what you do not want to load.  Put your 
packages in the cache directory for the new image.  Yes, it is fussy about 
these things, but the idea is to find errors early rather than being stopped 
after a long wait.  Likewise, if you do not like what #setPreferences does, 
edit it.


________________________________________
From: [email protected] 
[[email protected]] On Behalf Of Stefan Marr 
[[email protected]]
Sent: Wednesday, October 06, 2010 4:28 AM
To: List Mailing Pharo; [email protected]
Subject: [Pharo-project] Tool for: Image2 - Image1 > FileOut?

Hello:

I got here two images without sufficient development history, source code 
management, or change sets.

One of the images is the basis point and the other contains all the relevant 
code I need to file out somehow so that it represents a diff which can be filed 
into the base point image easily.

I am only interested in classes, methods, and their meta infos, so general 
state in the image is not a problem at the moment.

If it would be only about methods, that would be easy, since I can find out 
whether it is a changed/new method by locking at the fileIndex.

However, for classes that does not work out. How can I find out whether they 
changed or were added?
That seems to be only possible if they were actually commented...

Is there any known tool which could produce me a diff/fileOut/changeSet from 
two given images?
Or might there be any other information in the image I could use to create one 
myself?

Thanks and best regards
Stefan


--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


_______________________________________________
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

Reply via email to