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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stefan Marr [pharo@stefan-marr.de] Sent: Wednesday, October 06, 2010 4:28 AM To: List Mailing Pharo; pharo-users@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project