November 2017 - Pharo-users

Re: [Pharo-users] I love the launcher!!!!

by Christophe Demarey

Hi Phil, > Le 26 nov. 2017 Ã 22:25, phil(a)highoctane.be a Ã©crit : > > So, I try it on my CentOS 7 64 bit and... as there is no 64 bit version of the launcherâ¦ Right. Canât you use the 32 bit version? Anyway, I think it would be good to have a 64 bit version. Could you open an issue for that please? > > pharo6-64-ui PharoLauncher.image > This interpreter (vers. 68021) cannot read image file (vers. 6521). > Press CR to quit... > > How is one using the launcher for 64 bit stuff? > > Phil > > On Sun, Nov 26, 2017 at 9:45 PM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > If you don't try you will not understand what you miss. > > On Sun, Nov 26, 2017 at 2:10 PM, Herby VojÄÃk <herby(a)mailbox.sk <mailto:herby@mailbox.sk>> wrote: > > Stephane Ducasse wrote: > >> > >> Then do not try :) like that you will never get a chance to know :) > > > > > > Could you please explain? I understood your sentence has high dose of homour > > which I cannot decipher since I lack certain abilities for that. > > > > Thanks, Herby > > > >> Stef > >> > >> > >> On Sun, Nov 26, 2017 at 1:48 PM, Herby VojÄÃk<herby(a)mailbox.sk <mailto:herby@mailbox.sk>> wrote: > >>> > >>> Stephane Ducasse wrote: > >>>> > >>>> Why don't you try? It does not bite. > >>>> > >>>> For me it works in all scenario. I have projects that i manage over > >>>> several weeks and others I drop day to day. > >>>> And I have also startup script per versions. > >>> > >>> > >>> Maybe I will. The main problem was I didn't what it's good about at all - > >>> load image for a version, runs it - what's the "wow it's great" about? > >>> Missed part was it loads correct vm; plus makes sense when you have > >>> hundreds > >>> (I don't). Now it must be combined with the startup script magic to work > >>> with long-time projects, but those are also new to me - did not know of > >>> them > >>> until your booklet, not using them at all yet. > >>> > >>> Herby > >>> > >>> > >>>> Stef > >>>> > >>>> On Fri, Nov 24, 2017 at 3:10 PM, Herby VojÄÃk<herby(a)mailbox.sk <mailto:herby@mailbox.sk>> wrote: > >>>>> > >>>>> Thank you all, now I understand it better. Good for lots of "branches". > >>>>> > >>>>> However, I wonder how does it work with the rule I read somewhere: > >>>>> "start > >>>>> each day [of work on a project] with a new image", which means I should > >>>>> not > >>>>> reuse clean new image (as it needs populating from VCSes etc.) nor > >>>>> reuse > >>>>> existing image (I should start with the new one). Or does it combine > >>>>> with > >>>>> some startup-magic described in one of the recent Steph's booklets, the > >>>>> "one > >>>>> start per [new] image" case (but again, one should discriminate > >>>>> projects > >>>>> from each other)? > >>>>> > >>>>> Thanks, Herby > >>>>> > >>>>> Peter UhnÃ¡k wrote: > >>>>>> > >>>>>> Hi Herby, > >>>>>> > >>>>>> normally people use different images for their different projects, > >>>>>> different versions, trying things, etc. Which means we end up with > >>>>>> many > >>>>>> locations on disk, and it can be hard to track. > >>>>>> So PharoLauncher is a nice tool where you can download fresh image > >>>>>> just > >>>>>> by clicking, and you see the list of your local images and can launch > >>>>>> them, etc. > >>>>>> > >>>>>> Peter > >>>>>> > >>>>>> On Thu, Nov 23, 2017 at 12:56 PM, Herby VojÄÃk<herby(a)mailbox.sk <mailto:herby@mailbox.sk> > >>>>>> <mailto:herby@mailbox.sk <mailto:herby@mailbox.sk>>> wrote: > >>>>>> > >>>>>> Stephane Ducasse wrote: > >>>>>> > >>>>>> Hi > >>>>>> > >>>>>> I love the PharoLauncher. > >>>>>> > >>>>>> > >>>>>> Pardon my question, I have downloaded it and looked at it, but I > >>>>>> don't get it. What does it do / what are the use cases (honest > >>>>>> question)? > >>>>>> > >>>>>> Thanks, Herby > >>>>>> > >>>>>> > >>>>>> It helps me to manage my parallel development and projects. > >>>>>> > >>>>>> We should put a link on the Pharo web site because > >>>>>> > >>>>>> http://files.pharo.org/platform/launcher/ <http://files.pharo.org/platform/launcher/> > >>>>>> <http://files.pharo.org/platform/launcher/ <http://files.pharo.org/platform/launcher/>> > >>>>>> > >>>>>> is arcane. > >>>>>> > >>>>>> Stef > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>> > >> > > > > > > >

Nov. 28, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Mariano Martinez Peck

On Tue, Nov 28, 2017 at 10:20 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 28 Nov 2017, at 13:52, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > > > > > On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck <dassi(a)mindclue.ch> > wrote: > > Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck: > > > Hi Andreas, > > > > > > Do you know why method contexts are trying to be serialized? Of course, > > > probably because of closures. Do you think / know / are aware of > closures > > > as part of your graph? Maybe Sorted Collection? > > > I am asking because if the only thing is SortedCollection then we can > use > > > some hook... > > > > I have closures in several places in the object graph. These are objects > > with some pluggable functionality, which I rely on. > > > > > > OK. The question is then if those closures are "clean" or not. In other > words, what's their scope? Do they refer to variables defined outside the > closure (in which case you would need the methods contexts / stack) or are > they clean in the sense that you could be able to replace them via a string > and then compile them again ? > > Some time ago we added a #isClean to BlockClosure. You can test a few of > your closures to see if this is the case or not. > > > > Btw, I have an application for a client in which we also have closures > to define some pluggable behavior. But what I do is: > > > > 1) guarantee they are 100% clean (does not go outside of scope) > > 2) aside from the "block" instVar I also add another instVar which is > the "string" version of it. Then I always implement # > fuelIgnoredInstanceVariableNames to ignore all those "block" instVars, > yet DO NOT ignore the "string" like of those closures. Then, of course, the > getter of the block instvar does a lazy compilation if the block instVar is > nil... > > Ah, that's cheating ;-) > I didn't say it wasn't hahahahahaha > > But totally acceptable with clean blocks. > > So, > > [ :x :y | x < y ] isClean. > > => true > > [ :x :y | x < y ] sourceNode formattedCode. > > => '[ :x :y | x < y ]' > > But > > Compiler evaluate: '[ :x :y | x < y ]'. > > => [ :arg1 :arg2 | arg1 < arg2 ] > > So the argument names get lost, which seems like a pity. How are you doing > it ? Can it be done differently ? > > I really don't care at all how closures look like. The idea is: always keep the string version instVars and sixx/fuel ignore the block version. block version getter compiles from string if nil. I think you might have understood I use the same instVar and that sometimes I set a string and sometimes I set a closure. If that's the case, then yes, I ended up with 2 different instVars... Example: FaAction class >> fuelIgnoredInstanceVariableNames ^ #('actionBlock') FaPersistentObject subclass: #FaAction instanceVariableNames: 'action actionBlock' classVariableNames: '' package: 'FA-Core' FaAction >> actionBlock ^ actionBlock ifNil: [ action isEmptyOrNil ifTrue: [ nil ] ifFalse: [actionBlock := self compile: action ] ] That's is obviously a simplified example and it might have some syntax error but I guess you get the idea, right? So this has worked very well for me with Fuel on Pharo and Sixx on GemStone. There are obvious drawbacks like: it only works for clean closures, having to have 2 instVar per "concept" , have to compile when I only have the string, etc etc. > > I know you already have your application written, but I am trying to > explain how I was able to use Fuel for this case... > > > > > > Just for my better understanding, I like to ask: The FLMethodChanged > > errors will show up for *EVERY* method of a materialized object (Since > > the bytecodesHash changed for every method) or just those methods which > > involve fuel-persisted MethodContexts? (Sorry, if the question is > > stupid, but I am rather new to Fuel internals) > > > > > > As far as I can remember, the latter. > > > > > > > > > > Cheers, > > Andreas > > > > -- > > Andreas Brodbeck > > www.mindclue.ch > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Nov. 28, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Sven Van Caekenberghe

> On 28 Nov 2017, at 13:52, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck <dassi(a)mindclue.ch> wrote: > Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck: > > Hi Andreas, > > > > Do you know why method contexts are trying to be serialized? Of course, > > probably because of closures. Do you think / know / are aware of closures > > as part of your graph? Maybe Sorted Collection? > > I am asking because if the only thing is SortedCollection then we can use > > some hook... > > I have closures in several places in the object graph. These are objects > with some pluggable functionality, which I rely on. > > > OK. The question is then if those closures are "clean" or not. In other words, what's their scope? Do they refer to variables defined outside the closure (in which case you would need the methods contexts / stack) or are they clean in the sense that you could be able to replace them via a string and then compile them again ? > Some time ago we added a #isClean to BlockClosure. You can test a few of your closures to see if this is the case or not. > > Btw, I have an application for a client in which we also have closures to define some pluggable behavior. But what I do is: > > 1) guarantee they are 100% clean (does not go outside of scope) > 2) aside from the "block" instVar I also add another instVar which is the "string" version of it. Then I always implement #fuelIgnoredInstanceVariableNames to ignore all those "block" instVars, yet DO NOT ignore the "string" like of those closures. Then, of course, the getter of the block instvar does a lazy compilation if the block instVar is nil... Ah, that's cheating ;-) But totally acceptable with clean blocks. So, [ :x :y | x < y ] isClean. => true [ :x :y | x < y ] sourceNode formattedCode. => '[ :x :y | x < y ]' But Compiler evaluate: '[ :x :y | x < y ]'. => [ :arg1 :arg2 | arg1 < arg2 ] So the argument names get lost, which seems like a pity. How are you doing it ? Can it be done differently ? > I know you already have your application written, but I am trying to explain how I was able to use Fuel for this case... > > > Just for my better understanding, I like to ask: The FLMethodChanged > errors will show up for *EVERY* method of a materialized object (Since > the bytecodesHash changed for every method) or just those methods which > involve fuel-persisted MethodContexts? (Sorry, if the question is > stupid, but I am rather new to Fuel internals) > > > As far as I can remember, the latter. > > > > > Cheers, > Andreas > > -- > Andreas Brodbeck > www.mindclue.ch > > > > > > -- > Mariano > http://marianopeck.wordpress.com

Nov. 28, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Mariano Martinez Peck

On Tue, Nov 28, 2017 at 9:20 AM, Andreas Brodbeck <dassi(a)mindclue.ch> wrote: > Am 28.11.17 um 11:13 schrieb H. Hirzel: > > Hello Andreas > > > > Unfortunately Fuel is not meant for this kind of use case of migrating > > an object model. > > That's sad to hear. From 1.4 to 6.1 is a big step, I agree, but I really > thought that Fuel can be considered as a good "transport vehicle" at > least for small steps like from Pharo 5 to 6. > > Yes, watching it from now, I think this was our biggest drawback of fuel. > > > > So other options have to be considered. > > That probably would be a custom mechanism storing objects in a database > or fileformat and re-import, I think. Lots of work and very error prone. > But maybe the only way unfortunately ... > > SIXX would be an option you think? > > No. SIXX doesn't know how to deal with closures. > > > > Does your object model have cycles? > > Yes. > > > Regards, > Andreas > > -- > Andreas Brodbeck > www.mindclue.ch > > > -- Mariano http://marianopeck.wordpress.com

Nov. 28, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Mariano Martinez Peck

On Tue, Nov 28, 2017 at 9:31 AM, Andreas Brodbeck <dassi(a)mindclue.ch> wrote: > Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck: > > Hi Andreas, > > > > Do you know why method contexts are trying to be serialized? Of course, > > probably because of closures. Do you think / know / are aware of > closures > > as part of your graph? Maybe Sorted Collection? > > I am asking because if the only thing is SortedCollection then we can use > > some hook... > > I have closures in several places in the object graph. These are objects > with some pluggable functionality, which I rely on. > *OK. The question is then if those closures are "clean" or not.* In other words, what's their scope? Do they refer to variables defined outside the closure (in which case you would need the methods contexts / stack) or are they clean in the sense that you could be able to replace them via a string and then compile them again ? Some time ago we added a #isClean to BlockClosure. You can test a few of your closures to see if this is the case or not. Btw, I have an application for a client in which we also have closures to define some pluggable behavior. But what I do is: 1) guarantee they are 100% clean (does not go outside of scope) 2) aside from the "block" instVar I also add another instVar which is the "string" version of it. Then I always implement #fuelIgnoredInstanceVariableNames to ignore all those "block" instVars, yet DO NOT ignore the "string" like of those closures. Then, of course, the getter of the block instvar does a lazy compilation if the block instVar is nil... I know you already have your application written, but I am trying to explain how I was able to use Fuel for this case... > > Just for my better understanding, I like to ask: The FLMethodChanged > errors will show up for *EVERY* method of a materialized object (Since > the bytecodesHash changed for every method) or just those methods which > involve fuel-persisted MethodContexts? (Sorry, if the question is > stupid, but I am rather new to Fuel internals) > > As far as I can remember, the latter. > > Cheers, > Andreas > > -- > Andreas Brodbeck > www.mindclue.ch > > > -- Mariano http://marianopeck.wordpress.com

Nov. 28, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Andreas Brodbeck

Am 28.11.17 um 12:46 schrieb Mariano Martinez Peck: > Hi Andreas, > > Do you know why method contexts are trying to be serialized? Of course, > probably because of closures. Do you think / know / are aware of closures > as part of your graph? Maybe Sorted Collection? > I am asking because if the only thing is SortedCollection then we can use > some hook... I have closures in several places in the object graph. These are objects with some pluggable functionality, which I rely on. Just for my better understanding, I like to ask: The FLMethodChanged errors will show up for *EVERY* method of a materialized object (Since the bytecodesHash changed for every method) or just those methods which involve fuel-persisted MethodContexts? (Sorry, if the question is stupid, but I am rather new to Fuel internals) Cheers, Andreas -- Andreas Brodbeck www.mindclue.ch

Nov. 28, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Sean P. DeNigris

Andreas Brodbeck-3 wrote >> So other options have to be considered. > > That probably would be a custom mechanism storing objects in a database > or fileformat and re-import,â¦ My two primary workarounds in this scenario are: 1. Try STON 2. Try Fuel in smaller hops (e.g. 1.4 -> 2 -> 4, etc), although I'm not sure that would work in your case. This seemed more useful when I didn't seem able to load the same version of Fuel in the source and target. Here is a little working document that might help get you started: https://github.com/seandenigris/pharo/wiki/Data-Migration ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Nov. 28, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Andreas Brodbeck

Am 28.11.17 um 11:13 schrieb H. Hirzel: > Hello Andreas > > Unfortunately Fuel is not meant for this kind of use case of migrating > an object model. That's sad to hear. From 1.4 to 6.1 is a big step, I agree, but I really thought that Fuel can be considered as a good "transport vehicle" at least for small steps like from Pharo 5 to 6. > > So other options have to be considered. That probably would be a custom mechanism storing objects in a database or fileformat and re-import, I think. Lots of work and very error prone. But maybe the only way unfortunately ... SIXX would be an option you think? > > Does your object model have cycles? Yes. Regards, Andreas -- Andreas Brodbeck www.mindclue.ch

Nov. 28, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by Mariano Martinez Peck

Hi Andreas, Do you know why method contexts are trying to be serialized? Of course, probably because of closures. Do you think / know / are aware of closures as part of your graph? Maybe Sorted Collection? I am asking because if the only thing is SortedCollection then we can use some hook... Let me know, On Tue, Nov 28, 2017 at 7:01 AM, Andreas Brodbeck <dassi(a)mindclue.ch> wrote: > Hi all, > > I have a long running Seaside/Pharo application which still runs perfect > on Pharo 1.4. I want to step into the future and migrate to the newest > Pharo 6.1. > > The application's persistence is just in the image, so my plan is to use > Fuel to transfer the objects from Pharo 1.4 to Pharo 6.1. > > My first attempt: > > --- Using Fuel version 1.9.4 on both VMs. > --- Class TimeStamp was missing, so I created it. > --- I use a Fuel-migration for the renaming of "MethodContext" into the > new "Context" class. > > > But now I am stuck with FLMethodChanged errors. My investigation shows > that there are unequal values for the method Context>>bytecodesHash when > comparing Pharo 1.4 with 6.1. (BTW: Pharo 5 gives same values like 6.1). > > So, basically Fuel can not materialize the instances because the > bytecode hash of all methods have changed, comparing 1.4 to 6.1. My > feeling says that this could be a major problem for my plans to migrate > from Pharo 1.4 to 6.1. > > Is there a chance to still load those instances with Fuel into the new > 6.1 Pharo? > > Thanks! > Andreas > > -- > Andreas Brodbeck > www.mindclue.ch > > > -- Mariano http://marianopeck.wordpress.com

Nov. 28, 2017

Re: [Pharo-users] Fuel transfer from Pharo 1.4 to Pharo 6.1

by stephan

On 28-11-17 11:01, Andreas Brodbeck wrote: > So, basically Fuel can not materialize the instances because the > bytecode hash of all methods have changed, comparing 1.4 to 6.1. My > feeling says that this could be a major problem for my plans to migrate > from Pharo 1.4 to 6.1. If you export the bytecode hash of the 1.4 methods, you might be able to use those to materialize again in 6.1. Or at least get a step further, as there will be more things new & renamed & missing. Stephan

Nov. 28, 2017