- Pharo-users - lists.pharo.org

Re: [Pharo-users] How to move data between Pharo versions

by Mariano Martinez Peck

This thread may help you: http://forum.world.st/Fuel-version-td4823170.html Cheers, On Thu, May 28, 2015 at 9:19 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Fri, May 29, 2015 at 7:17 AM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > Peter Kenny wrote > >> I will have to convert all my files to the new version? As far as I can > >> see, I could not do that using > >> the device you suggest > > > > The thing is that it's only the serialization that is tied to a Fuel > > version, so the workflow is (and I've done this to port my data from > Pharo > > 3.0 to Pharo 4.0 and then to Pharo 5.0): > > > > 1. In the older image with the data, upgrade Fuel to the latest version > that > > will load in that Pharo `ConfigurationOfFuel project stableVersion load` > > This does not cater for "storing object structures long term on > disk." I guess the workaround is that the image used to store the > objects needs to archive near the fuel files. But you'd need to be > careful not to save it once you upgraded fuel versions. > > > 2. Serialize the data > > If the Fuel version in #1 is the one that comes with the newer Pharo > you're > > porting to, you're done. You can now materialize in the newer Pharo > version. > > Otherwise... > > 3. In the newer Pharo > > a. Downgrade Fuel e.g `(ConfigurationOfFuel project version: > > versionStringFromNumberOneAbove) load` > > b. Materialize the data > > c. Upgrade Fuel back to the normal version for the newer Pharo (replace > > version string from 3.a. with the original version) > > d. Serialize the data > > Some use cases may require multiple downgrades/upgrades, which could > be annoying. An interesting idea might be for a new release of Fuel to > rename the previous version of as OldFuel that is released in its own > package. Then "some OldFuel version" could exist in parallel with the > "current version." The "current version" might even be smart enough to > identify the OldFuel version needed and load it into the image and > continue materializing the data. A CI program might run through a > range of OldFuel versions to track which remain working on future > versions of Pharo. > cheers -ben > > > > > Now you can load the data into the newer Pharo. > > > > > > Peter Kenny wrote > >> could I set those to give different version numbers > > > > The problem is that the data format may not be compatible between the > > versions. Mariano would be able to give a better answer, but I would be > > afraid. What if it seems to work but corrupts your data?! > > > > > Does the workflow I detailed make sense and cover your needs? > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/How-to-move-data-between-Pharo-versions-tp4829102p482… > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > -- Mariano http://marianopeck.wordpress.com

May 29, 2015

Re: [Pharo-users] How to move data between Pharo versions

by Ben Coman

On Fri, May 29, 2015 at 7:17 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Peter Kenny wrote >> I will have to convert all my files to the new version? As far as I can >> see, I could not do that using >> the device you suggest > > The thing is that it's only the serialization that is tied to a Fuel > version, so the workflow is (and I've done this to port my data from Pharo > 3.0 to Pharo 4.0 and then to Pharo 5.0): > > 1. In the older image with the data, upgrade Fuel to the latest version that > will load in that Pharo `ConfigurationOfFuel project stableVersion load` This does not cater for "storing object structures long term on disk." I guess the workaround is that the image used to store the objects needs to archive near the fuel files. But you'd need to be careful not to save it once you upgraded fuel versions. > 2. Serialize the data > If the Fuel version in #1 is the one that comes with the newer Pharo you're > porting to, you're done. You can now materialize in the newer Pharo version. > Otherwise... > 3. In the newer Pharo > a. Downgrade Fuel e.g `(ConfigurationOfFuel project version: > versionStringFromNumberOneAbove) load` > b. Materialize the data > c. Upgrade Fuel back to the normal version for the newer Pharo (replace > version string from 3.a. with the original version) > d. Serialize the data Some use cases may require multiple downgrades/upgrades, which could be annoying. An interesting idea might be for a new release of Fuel to rename the previous version of as OldFuel that is released in its own package. Then "some OldFuel version" could exist in parallel with the "current version." The "current version" might even be smart enough to identify the OldFuel version needed and load it into the image and continue materializing the data. A CI program might run through a range of OldFuel versions to track which remain working on future versions of Pharo. cheers -ben > > Now you can load the data into the newer Pharo. > > > Peter Kenny wrote >> could I set those to give different version numbers > > The problem is that the data format may not be compatible between the > versions. Mariano would be able to give a better answer, but I would be > afraid. What if it seems to work but corrupts your data?! > > Does the workflow I detailed make sense and cover your needs? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/How-to-move-data-between-Pharo-versions-tp4829102p482… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

May 29, 2015

Re: [Pharo-users] How to move data between Pharo versions

by PBKResearch

Sean Thanks for this. At the back of my mind in asking was whether I want to use Fuel more extensively as a way of storing object structures long term on disk. If I move to Pharo 5 later on, will that have a new version of Fuel which will refuse to read my saved files, so that I will have to convert all my files to the new version? As far as I can see, I could not do that using the device you suggest; I would have to have one version of Fuel which could materialize files of version 193 and re-serialize to version 194. I see that both FLSerializer and FLMaterializer have class side methods called #currentVersion; could I set those to give different version numbers, and do the conversion that way? Alternatively, I could use Sven's suggestion of STON, provided that will not go the way of version changes without backward compatibility. I suppose a lot will depend on the efficiency of the two approaches, both in terms of storage space on disk and in conversion times. Thanks to both for the suggestions. I have food for thought and ideas for further experiment. Peter Kenny -----Original Message----- From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Sean P. DeNigris Sent: 28 May 2015 17:39 To: pharo-users(a)lists.pharo.org Subject: Re: [Pharo-users] How to move data between Pharo versions Peter Kenny wrote > My question is what should I have done? There is usually an overlap between the Fuel versions loadable in consecutive Pharo versions, so you have to either (via Metacello) upgrade the Fuel in your source image, or downgrade in the target image, so that you can save and move the data without conflict. ----- Cheers, Sean -- View this message in context: http://forum.world.st/How-to-move-data-between-Pharo-versions-tp4829102p4829 115.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 29, 2015

Re: [Pharo-users] How to move data between Pharo versions

by Sean P. DeNigris

Peter Kenny wrote > I will have to convert all my files to the new version? As far as I can > see, I could not do that using > the device you suggest The thing is that it's only the serialization that is tied to a Fuel version, so the workflow is (and I've done this to port my data from Pharo 3.0 to Pharo 4.0 and then to Pharo 5.0): 1. In the older image with the data, upgrade Fuel to the latest version that will load in that Pharo `ConfigurationOfFuel project stableVersion load` 2. Serialize the data If the Fuel version in #1 is the one that comes with the newer Pharo you're porting to, you're done. You can now materialize in the newer Pharo version. Otherwise... 3. In the newer Pharo a. Downgrade Fuel e.g `(ConfigurationOfFuel project version: versionStringFromNumberOneAbove) load` b. Materialize the data c. Upgrade Fuel back to the normal version for the newer Pharo (replace version string from 3.a. with the original version) d. Serialize the data Now you can load the data into the newer Pharo. Peter Kenny wrote > could I set those to give different version numbers The problem is that the data format may not be compatible between the versions. Mariano would be able to give a better answer, but I would be afraid. What if it seems to work but corrupts your data?! Does the workflow I detailed make sense and cover your needs? ----- Cheers, Sean -- View this message in context: http://forum.world.st/How-to-move-data-between-Pharo-versions-tp4829102p482… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 29, 2015

Re: [Pharo-users] Diffing Monticello package against image contents

by Esteban A. Maringolo

2015-05-28 19:48 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 28-05-15 22:15, Esteban A. Maringolo wrote: >> Is there a way to compare the contents of a Monticello package (mcz) >> against the contents of the image *REGARDLESS* of the packaging? > If you browse the monolithic package, you have it somewhere in > the image. You should be able to calculate a diff from there. I know I'd could (It's Smalltalk after all). But I wanted to know whether the "feature" was already available. By your answer I guess it's not a feature yet. Thank you! Esteban A. Maringolo

May 29, 2015

Re: [Pharo-users] Diffing Monticello package against image contents

by Stephan Eggermont

On 28-05-15 22:15, Esteban A. Maringolo wrote: > Is there a way to compare the contents of a Monticello package (mcz) > against the contents of the image *REGARDLESS* of the packaging? If you browse the monolithic package, you have it somewhere in the image. You should be able to calculate a diff from there. Stephna

May 29, 2015

Re: [Pharo-users] Some Pharo 4 Getting-Started tips

by Esteban A. Maringolo

2015-05-28 17:44 GMT-03:00 Sean P. DeNigris <sean(a)clipperadams.com>: > stepharo wrote >> My computer is not just Computer your phone is not just Phone :) > > Well the name iPhone is actually pretty much just Phone! Also, note that > it's not called iConchShell ;) Android Phone, Windows Phone... > Similarly, Pharo is our brand, and within the > image we can make things simple for everyone. Plus, the menu already shows "System browser" as one of the options, you click it and it opens... Nautilus :P Esteban A. Maringolo

May 28, 2015

Re: [Pharo-users] Some Pharo 4 Getting-Started tips

by Sean P. DeNigris

stepharo wrote > My computer is not just Computer your phone is not just Phone :) Well the name iPhone is actually pretty much just Phone! Also, note that it's not called iConchShell ;) And, the apps it contains are called Messages, Mail, and Phone. Similarly, Pharo is our brand, and within the image we can make things simple for everyone. Float does not have to be branded as Irrational by Calvin Klein, with mathcing unintelligible commercial advertisements :-p ----- Cheers, Sean -- View this message in context: http://forum.world.st/Some-Pharo-4-Getting-Started-tips-tp4828493p4829167.h… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 28, 2015

Diffing Monticello package against image contents

by Esteban A. Maringolo

Is there a way to compare the contents of a Monticello package (mcz) against the contents of the image *REGARDLESS* of the packaging? It is... I want to compare methods and class definitions from a mcz, that has a monolithic package (PostgresV3 in this case) against what I have loaded in the image, which has different packages (PostgresV3-Core, etc.). As it is today, if I select PostgresV3.mcz and select the "Changes" menu, it will mark everything as changed, because such package doesn't exist in the image. If PackageA contains a method ClassX>>#methodA, I want the contents of such method to be compared to what I have in the image, no matter if ClassX>>#methodA belongs to PackageB or PackageC. Does such feature exist? Something like a chunks browser, but using a Monticello package instead of a chunk file. Esteban A. Maringolo

May 28, 2015

Re: [Pharo-users] Some Pharo 4 Getting-Started tips

by stepharo

I like your point. Please keep idiosyncratic names because we can build marketing with them. My computer is not just Computer your phone is not just Phone :) Even your shoes are not Shoes So brands are important Pharo is not Programming Language! Le 27/5/15 00:59, Avdi Grimm a Ã©crit : > > > On Tue, May 26, 2015 at 1:27 PM Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> wrote: > >> or we can rename it as "System Browser (Nautilus)â in the title, >> or something like that > > > I think this is ideal. > > I remember back when I used to use Perl, and it had CPAN, which was > great. The only problem was that someone would say "use the XML > library!" and you'd look in CPAN and there'd be xml and xmllib and > libxml and fastxml or whatever, and you'd be like "uh... which one > would that be?" > > Ruby went the other way entirely, with idiosyncratic names like > "Nokogiri". The obvious down side is that if you see that in an app's > dependencies and you're a newbie, you have no fricking clue what it > is. The upside, though, is that if someone tells you "use Nokogiri!" > there is zero ambiguity about what you're supposed to use. It gives > the project a distinct, memorable personality. > > If you can keep distinctive project names, but also name menus and > title bars such that they link the distinct project to the *role* that > project plays, you've got the best of both worlds.

May 28, 2015