- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Contributing to Pharo

by Ben Coman

On Thu, Feb 4, 2016 at 5:26 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > In the meantime, Cuis has completely given up managing packages in > Smalltalk: all is done in git externally. Thats very interesting to hear - since 2012 even... http://www.jvuletich.org/Cuis/CuisAndGitHub.html and interesting to compare different approaches... * https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentat… * https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Documentat… cheers -ben

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Stephan Eggermont

On 04-02-16 13:09, Henrik Johansen wrote: > Also, the ancestry of all packages in Pharo Core was truncated a few years back, which also screwed up merging*. > I don't think anyone looked into why it happened. My experiment in creating one file for a whole project would be a suitable starting point for fixing that. Stephan

Feb. 4, 2016

Re: [Pharo-dev] Contributing to Pharo

by Henrik Johansen

> On 04 Feb 2016, at 10:26 , Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 04/02/2016 10:04, Nicolas Cellier a Ã©crit : >> I don't understand broken history either. >> Yes there can be .mcz name clashes but UUID history is stored together >> in metadata no? > > Yes. > >> If some tool only trust .mcz name without checking UUID, consider it's a >> bug, and let's correct it (there is some in Monticello Configuration Map) > > Gofer. In fact, most of Monticello never checks the UUID, only dependencies do, but this looks like a deprecated feature given how often it is used. > >> Or is it the fact that some .mcz could be missing? >> Consider this is a feature, MC tools are robust to missing .mcz (it's >> just that you'll have to redo the merge if you lost a common ancestor). > > What? You really consider that a feature? > >> Or is it the fact that some repository might contain only a slice of >> history? >> This is another feature... You can view all the versions in a collection >> of repositories without needing to replicate. > > Understandable in theory. Unworkable over time and change (repositories disappear and die, and this stops working) > >> You can replicate if you want but it's not mandatory and completely >> orthogonal. >> So yes, this information - the list or repositories you want to consider >> - has to be stored separetely and this can sound quite unconventional. >> But IMO, it's an important feature: it gives much resilience for a very >> low investment. >> And that also mean that you can hardly break things (have unconsistent >> history). > >> Maybe when you say broken, you mean not 100% git compatible? > > No, what I say is true mcz inconsistent history (missing versions making merges very unreliable, basically). > > I describe a while ago a case where, thanks to mcz features, I couldn't merge a small change done to Roassal without generating a ton of conflicts. I moved the three needed mcz(s) to git (the change ancestor, the change, and the current head), did git merge and had no conflicts. > > If you consider those features, then I disagree. Also, the ancestry of all packages in Pharo Core was truncated a few years back, which also screwed up merging*. I don't think anyone looked into why it happened. Cheers, Henry *http://forum.world.st/FogBugz-Case-Issue-12776-Tools-Cancelling-quot-Previous-Contents-quot-in-a-Workspace-clears-the-currs-td4753381.html

Feb. 4, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Sven Van Caekenberghe

> On 04 Feb 2016, at 11:55, Guille Polito <guillermopolito(a)gmail.com> wrote: > > Good news, so far, installing NeoUUID and replacing UUID class >> new by: > > UUID class >> new > ^NeoUUIDGenerator new next > > seems to work. At it looks that I can trust again my commits. > > Thanks Sven :) OK. Now, the idea is that one instance of the generator is kept around, this is way more efficient, but also more correct, as the random generator should not be created anew each time. > Now I do not know how this should be solved, nor if this is reproducible in a machine other than mine... I seriously doubt the plugin is better (more random, more unique) then anything that we can do in Pharo itself. I like Pharo code way better, because we all see what it does. Anyone else with an opinion ? > On 02/04/2016 11:41 AM, Guille Polito wrote: >> Well, maybe we do not need a plugin, but then the fallback code is not generating unique enough UUIDs :/ >> >> Maybe it is a side effect of Spur? >> >> I'll try to patch the UUID generator in the image with the Neo one and test if it solves my problem... >> >> I just want to commit :'( >> >> On 02/04/2016 11:36 AM, Sven Van Caekenberghe wrote: >>> It beats the hell out of me why we need a plugin (apart from speed) and why the fallback should not work (i.e. generate duplicates). It is not rocket science or magic, right ? >>> >>> I once made my own generator: Neo-UUID (http://mc.stfx.eu/Neo or Neo on StHub). It is pretty simple and fast. >>> >>>> On 04 Feb 2016, at 11:29, Guille Polito <guillermopolito(a)gmail.com> wrote: >>>> >>>> And yes, linux VM's are not shipped with the UUID plugin... at least not since 2014/2013... >>>> >>>> Also, I believe the plugin is not compiled as internal since it is not listed in >>>> >>>> Smalltalk vm listBuiltinModules. >>>> Smalltalk vm listLoadedModules. >>>> >>>> On 02/04/2016 11:12 AM, Guille Polito wrote: >>>>> On 02/04/2016 10:58 AM, Sven Van Caekenberghe wrote: >>>>>> But StHub did not change for a long time, no ? >>>>> I know... >>>>>> Saving to an HTTP MC repo is nothing more than an HTTP PUT. >>>>>> >>>>>> You should be able to do that manually with just ZnClient. >>>>> Well, yes. But I'm just clicking the save button on the monticello browser... >>>>> >>>>> Now, I tested with squeaksource3: >>>>> >>>>> - I commit in squeaksource 3 using the monticello browser: the file in package-cache is OK, the file in squeaksource3 is OK >>>>> http://ss3.gemtalksystems.com/ss?_s=WvI7T3UuBKEaYUrR&_k=ukyWjav7hA-MhHIz >>>>> >>>>> - I make a copy of the file from the monticello UI to a smalltalkhub repository. The file in smalltalkhub is not the one I want. >>>>> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >>>>> >>>>> In both Squeaksource3 and Smalltalkhub I have the same UUID, project name, version number, commit message, but the MCZ file that I download from them is different. Even, making a diff from SmalltalkHub's UI shows me a diff against a completely different package (RoboticTable) that is from Santiago Bragagnolo, and that I guess it is a private project because it is not listed and cannot browsed. >>>>> >>>>> Making a diff on other versions, such as http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… , makes a diff against a version of the Makros package, which is also from Santiago Bragagnolo, but this is not a private project. >>>>> >>>>> Aaaand, now I see a problem! >>>>> >>>>> both my test package: >>>>> >>>>> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >>>>> >>>>> and the one of Santiago >>>>> >>>>> http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-Santiago… >>>>> >>>>> have the same UUID!!!!!! >>>>> >>>>> Maybe this is because of my debian 64bits? Hmm maybe the UUID plugin is not loading? I'll check that for now, because I cannot work if I cannot commit :). If somebody has an idea, It is VERY welcome! >>>>> >>>>> Thanks for reading my loud ranting/reasoning, >>>>> Guille >>>>>>> On 04 Feb 2016, at 10:52, Guille Polito <guillermopolito(a)gmail.com> wrote: >>>>>>> >>>>>>> So far, I'm blaming Smalltalkhub: >>>>>>> >>>>>>> - I create a new empty package. >>>>>>> - I commit it to a local directory, it works ok. >>>>>>> - I commit it to a smalltalkhub repository: the file in my package cache is ok, but the file in smalltalkhub is corrupted >>>>>>> e.g., http://www.smalltalkhub.com/#!/~Guille/playground/versions/test-GuillermoPo… >>>>>>> >>>>>>> The strange thing is that it is a recurrent bug. I cannot commit to smalltalkhub, not even do a push of a version in my package cache. Smalltalkhub always shows a buggy version. >>>>>>> >>>>>>> I'll now try with squeaksource 3 to narrow my conclusions. >>>>>>> >>>>>>> On 02/04/2016 10:33 AM, Guille Polito wrote: >>>>>>>> I tried for one hour yesterday to understand the problem :). This morning my priority was to not lose my code because I noticed the bug a couple of hours after my commits... Thanks I remembered to save my image and that the good old fileout in .st is working! >>>>>>>> >>>>>>>> I'll keep trying to reproduce and keep you posted >>>>>>>> >>>>>>>> On 02/04/2016 10:21 AM, stepharo wrote: >>>>>>>>> Hi guille >>>>>>>>> >>>>>>>>> Esteban got some problems with MC recently >>>>>>>>> so it would be good to have a reproducible case. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>> >>>>>>>>> Le 4/2/16 10:07, Guille Polito a Ã©crit : >>>>>>>>>> Ok, I am puzzled. I downloaded a new fresh image, in a fresh directory, worked on something else, committed, and my commit is completely broken. >>>>>>>>>> Attached screenshot of what monticello shows me. >>>>>>>>>> >>>>>>>>>> I'm on debian jessie 64bits. Maybe it has something to do? >>>>>>>>>> >>>>>>>>>> On 02/03/2016 03:41 PM, Guille Polito wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I'm finally back, rechecking this issue: >>>>>>>>>>> >>>>>>>>>>> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >>>>>>>>>>> >>>>>>>>>>> I remade the Slice to load in latest Pharo5 with the new Spur changes, plus some fixes proposed by Nicolai. I can load the slice in a new image and everything looks ok. So far so good. >>>>>>>>>>> >>>>>>>>>>> Now, the monkey starts checking the Slice and somehow it cannot load the Slice due to "dependencies to some classes". Of course, the slice I submitted does not depend on the packages on the complaint, and locally it loads well. Moreover, I never had/worked with those classes, nor they were installed in my system. Even, I have a new machine which is clean so I cannot believe I have some interference due to some package cache... >>>>>>>>>>> >>>>>>>>>>> The message of the monkey is here: >>>>>>>>>>> >>>>>>>>>>> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/26128//artifact/val… >>>>>>>>>>> >>>>>>>>>>> Did somebody find some similar problem or it is just me? I believe the problem is on the monkey side, but I have no clue... Maybe somebody has a better idea. >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> Guille >>>> >>> >> > >

Feb. 4, 2016

[ANN] We are in "code freeze" for Pharo 5

by Esteban Lorenzano

Hi, We are on âjust bugfixesâ since some time nowâ¦ I delayed the announcement because Epicea still needs to enter and we didnât manage to include it yet. But wellâ¦ with the exception of Epicea, no new features will be included un Pharo 5â¦ just bugfixes (and we have a lot of bugfixes incomingâ¦ this release will be hard :( ) cheers, Esteban

Feb. 4, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Guille Polito

Good news, so far, installing NeoUUID and replacing UUID class >> new by: UUID class >> new ^NeoUUIDGenerator new next seems to work. At it looks that I can trust again my commits. Thanks Sven :) Now I do not know how this should be solved, nor if this is reproducible in a machine other than mine... On 02/04/2016 11:41 AM, Guille Polito wrote: > Well, maybe we do not need a plugin, but then the fallback code is not > generating unique enough UUIDs :/ > > Maybe it is a side effect of Spur? > > I'll try to patch the UUID generator in the image with the Neo one and > test if it solves my problem... > > I just want to commit :'( > > On 02/04/2016 11:36 AM, Sven Van Caekenberghe wrote: >> It beats the hell out of me why we need a plugin (apart from speed) >> and why the fallback should not work (i.e. generate duplicates). It >> is not rocket science or magic, right ? >> >> I once made my own generator: Neo-UUID (http://mc.stfx.eu/Neo or Neo >> on StHub). It is pretty simple and fast. >> >>> On 04 Feb 2016, at 11:29, Guille Polito <guillermopolito(a)gmail.com> >>> wrote: >>> >>> And yes, linux VM's are not shipped with the UUID plugin... at least >>> not since 2014/2013... >>> >>> Also, I believe the plugin is not compiled as internal since it is >>> not listed in >>> >>> Smalltalk vm listBuiltinModules. >>> Smalltalk vm listLoadedModules. >>> >>> On 02/04/2016 11:12 AM, Guille Polito wrote: >>>> On 02/04/2016 10:58 AM, Sven Van Caekenberghe wrote: >>>>> But StHub did not change for a long time, no ? >>>> I know... >>>>> Saving to an HTTP MC repo is nothing more than an HTTP PUT. >>>>> >>>>> You should be able to do that manually with just ZnClient. >>>> Well, yes. But I'm just clicking the save button on the monticello >>>> browser... >>>> >>>> Now, I tested with squeaksource3: >>>> >>>> - I commit in squeaksource 3 using the monticello browser: the file >>>> in package-cache is OK, the file in squeaksource3 is OK >>>> http://ss3.gemtalksystems.com/ss?_s=WvI7T3UuBKEaYUrR&_k=ukyWjav7hA-MhHIz >>>> >>>> >>>> - I make a copy of the file from the monticello UI to a >>>> smalltalkhub repository. The file in smalltalkhub is not the one I >>>> want. >>>> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >>>> >>>> >>>> In both Squeaksource3 and Smalltalkhub I have the same UUID, >>>> project name, version number, commit message, but the MCZ file that >>>> I download from them is different. Even, making a diff from >>>> SmalltalkHub's UI shows me a diff against a completely different >>>> package (RoboticTable) that is from Santiago Bragagnolo, and that I >>>> guess it is a private project because it is not listed and cannot >>>> browsed. >>>> >>>> Making a diff on other versions, such as >>>> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >>>> , makes a diff against a version of the Makros package, which is >>>> also from Santiago Bragagnolo, but this is not a private project. >>>> >>>> Aaaand, now I see a problem! >>>> >>>> both my test package: >>>> >>>> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >>>> >>>> >>>> and the one of Santiago >>>> >>>> http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-Santiago… >>>> >>>> >>>> have the same UUID!!!!!! >>>> >>>> Maybe this is because of my debian 64bits? Hmm maybe the UUID >>>> plugin is not loading? I'll check that for now, because I cannot >>>> work if I cannot commit :). If somebody has an idea, It is VERY >>>> welcome! >>>> >>>> Thanks for reading my loud ranting/reasoning, >>>> Guille >>>>>> On 04 Feb 2016, at 10:52, Guille Polito >>>>>> <guillermopolito(a)gmail.com> wrote: >>>>>> >>>>>> So far, I'm blaming Smalltalkhub: >>>>>> >>>>>> - I create a new empty package. >>>>>> - I commit it to a local directory, it works ok. >>>>>> - I commit it to a smalltalkhub repository: the file in my >>>>>> package cache is ok, but the file in smalltalkhub is corrupted >>>>>> e.g., >>>>>> http://www.smalltalkhub.com/#!/~Guille/playground/versions/test-GuillermoPo… >>>>>> >>>>>> The strange thing is that it is a recurrent bug. I cannot commit >>>>>> to smalltalkhub, not even do a push of a version in my package >>>>>> cache. Smalltalkhub always shows a buggy version. >>>>>> >>>>>> I'll now try with squeaksource 3 to narrow my conclusions. >>>>>> >>>>>> On 02/04/2016 10:33 AM, Guille Polito wrote: >>>>>>> I tried for one hour yesterday to understand the problem :). >>>>>>> This morning my priority was to not lose my code because I >>>>>>> noticed the bug a couple of hours after my commits... Thanks I >>>>>>> remembered to save my image and that the good old fileout in .st >>>>>>> is working! >>>>>>> >>>>>>> I'll keep trying to reproduce and keep you posted >>>>>>> >>>>>>> On 02/04/2016 10:21 AM, stepharo wrote: >>>>>>>> Hi guille >>>>>>>> >>>>>>>> Esteban got some problems with MC recently >>>>>>>> so it would be good to have a reproducible case. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> >>>>>>>> Le 4/2/16 10:07, Guille Polito a Ã©crit : >>>>>>>>> Ok, I am puzzled. I downloaded a new fresh image, in a fresh >>>>>>>>> directory, worked on something else, committed, and my commit >>>>>>>>> is completely broken. >>>>>>>>> Attached screenshot of what monticello shows me. >>>>>>>>> >>>>>>>>> I'm on debian jessie 64bits. Maybe it has something to do? >>>>>>>>> >>>>>>>>> On 02/03/2016 03:41 PM, Guille Polito wrote: >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> I'm finally back, rechecking this issue: >>>>>>>>>> >>>>>>>>>> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I remade the Slice to load in latest Pharo5 with the new Spur >>>>>>>>>> changes, plus some fixes proposed by Nicolai. I can load the >>>>>>>>>> slice in a new image and everything looks ok. So far so good. >>>>>>>>>> >>>>>>>>>> Now, the monkey starts checking the Slice and somehow it >>>>>>>>>> cannot load the Slice due to "dependencies to some classes". >>>>>>>>>> Of course, the slice I submitted does not depend on the >>>>>>>>>> packages on the complaint, and locally it loads well. >>>>>>>>>> Moreover, I never had/worked with those classes, nor they >>>>>>>>>> were installed in my system. Even, I have a new machine which >>>>>>>>>> is clean so I cannot believe I have some interference due to >>>>>>>>>> some package cache... >>>>>>>>>> >>>>>>>>>> The message of the monkey is here: >>>>>>>>>> >>>>>>>>>> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/26128//artifact/val… >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Did somebody find some similar problem or it is just me? I >>>>>>>>>> believe the problem is on the monkey side, but I have no >>>>>>>>>> clue... Maybe somebody has a better idea. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> Guille >>> >> >

Feb. 4, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Guille Polito

Well, maybe we do not need a plugin, but then the fallback code is not generating unique enough UUIDs :/ Maybe it is a side effect of Spur? I'll try to patch the UUID generator in the image with the Neo one and test if it solves my problem... I just want to commit :'( On 02/04/2016 11:36 AM, Sven Van Caekenberghe wrote: > It beats the hell out of me why we need a plugin (apart from speed) and why the fallback should not work (i.e. generate duplicates). It is not rocket science or magic, right ? > > I once made my own generator: Neo-UUID (http://mc.stfx.eu/Neo or Neo on StHub). It is pretty simple and fast. > >> On 04 Feb 2016, at 11:29, Guille Polito <guillermopolito(a)gmail.com> wrote: >> >> And yes, linux VM's are not shipped with the UUID plugin... at least not since 2014/2013... >> >> Also, I believe the plugin is not compiled as internal since it is not listed in >> >> Smalltalk vm listBuiltinModules. >> Smalltalk vm listLoadedModules. >> >> On 02/04/2016 11:12 AM, Guille Polito wrote: >>> On 02/04/2016 10:58 AM, Sven Van Caekenberghe wrote: >>>> But StHub did not change for a long time, no ? >>> I know... >>>> Saving to an HTTP MC repo is nothing more than an HTTP PUT. >>>> >>>> You should be able to do that manually with just ZnClient. >>> Well, yes. But I'm just clicking the save button on the monticello browser... >>> >>> Now, I tested with squeaksource3: >>> >>> - I commit in squeaksource 3 using the monticello browser: the file in package-cache is OK, the file in squeaksource3 is OK >>> http://ss3.gemtalksystems.com/ss?_s=WvI7T3UuBKEaYUrR&_k=ukyWjav7hA-MhHIz >>> >>> - I make a copy of the file from the monticello UI to a smalltalkhub repository. The file in smalltalkhub is not the one I want. >>> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >>> >>> In both Squeaksource3 and Smalltalkhub I have the same UUID, project name, version number, commit message, but the MCZ file that I download from them is different. Even, making a diff from SmalltalkHub's UI shows me a diff against a completely different package (RoboticTable) that is from Santiago Bragagnolo, and that I guess it is a private project because it is not listed and cannot browsed. >>> >>> Making a diff on other versions, such as http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… , makes a diff against a version of the Makros package, which is also from Santiago Bragagnolo, but this is not a private project. >>> >>> Aaaand, now I see a problem! >>> >>> both my test package: >>> >>> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >>> >>> and the one of Santiago >>> >>> http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-Santiago… >>> >>> have the same UUID!!!!!! >>> >>> Maybe this is because of my debian 64bits? Hmm maybe the UUID plugin is not loading? I'll check that for now, because I cannot work if I cannot commit :). If somebody has an idea, It is VERY welcome! >>> >>> Thanks for reading my loud ranting/reasoning, >>> Guille >>>>> On 04 Feb 2016, at 10:52, Guille Polito <guillermopolito(a)gmail.com> wrote: >>>>> >>>>> So far, I'm blaming Smalltalkhub: >>>>> >>>>> - I create a new empty package. >>>>> - I commit it to a local directory, it works ok. >>>>> - I commit it to a smalltalkhub repository: the file in my package cache is ok, but the file in smalltalkhub is corrupted >>>>> e.g., http://www.smalltalkhub.com/#!/~Guille/playground/versions/test-GuillermoPo… >>>>> >>>>> The strange thing is that it is a recurrent bug. I cannot commit to smalltalkhub, not even do a push of a version in my package cache. Smalltalkhub always shows a buggy version. >>>>> >>>>> I'll now try with squeaksource 3 to narrow my conclusions. >>>>> >>>>> On 02/04/2016 10:33 AM, Guille Polito wrote: >>>>>> I tried for one hour yesterday to understand the problem :). This morning my priority was to not lose my code because I noticed the bug a couple of hours after my commits... Thanks I remembered to save my image and that the good old fileout in .st is working! >>>>>> >>>>>> I'll keep trying to reproduce and keep you posted >>>>>> >>>>>> On 02/04/2016 10:21 AM, stepharo wrote: >>>>>>> Hi guille >>>>>>> >>>>>>> Esteban got some problems with MC recently >>>>>>> so it would be good to have a reproducible case. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> Le 4/2/16 10:07, Guille Polito a Ã©crit : >>>>>>>> Ok, I am puzzled. I downloaded a new fresh image, in a fresh directory, worked on something else, committed, and my commit is completely broken. >>>>>>>> Attached screenshot of what monticello shows me. >>>>>>>> >>>>>>>> I'm on debian jessie 64bits. Maybe it has something to do? >>>>>>>> >>>>>>>> On 02/03/2016 03:41 PM, Guille Polito wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I'm finally back, rechecking this issue: >>>>>>>>> >>>>>>>>> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >>>>>>>>> >>>>>>>>> I remade the Slice to load in latest Pharo5 with the new Spur changes, plus some fixes proposed by Nicolai. I can load the slice in a new image and everything looks ok. So far so good. >>>>>>>>> >>>>>>>>> Now, the monkey starts checking the Slice and somehow it cannot load the Slice due to "dependencies to some classes". Of course, the slice I submitted does not depend on the packages on the complaint, and locally it loads well. Moreover, I never had/worked with those classes, nor they were installed in my system. Even, I have a new machine which is clean so I cannot believe I have some interference due to some package cache... >>>>>>>>> >>>>>>>>> The message of the monkey is here: >>>>>>>>> >>>>>>>>> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/26128//artifact/val… >>>>>>>>> >>>>>>>>> Did somebody find some similar problem or it is just me? I believe the problem is on the monkey side, but I have no clue... Maybe somebody has a better idea. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Guille >> >

Feb. 4, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Sven Van Caekenberghe

It beats the hell out of me why we need a plugin (apart from speed) and why the fallback should not work (i.e. generate duplicates). It is not rocket science or magic, right ? I once made my own generator: Neo-UUID (http://mc.stfx.eu/Neo or Neo on StHub). It is pretty simple and fast. > On 04 Feb 2016, at 11:29, Guille Polito <guillermopolito(a)gmail.com> wrote: > > And yes, linux VM's are not shipped with the UUID plugin... at least not since 2014/2013... > > Also, I believe the plugin is not compiled as internal since it is not listed in > > Smalltalk vm listBuiltinModules. > Smalltalk vm listLoadedModules. > > On 02/04/2016 11:12 AM, Guille Polito wrote: >> >> On 02/04/2016 10:58 AM, Sven Van Caekenberghe wrote: >>> But StHub did not change for a long time, no ? >> I know... >>> >>> Saving to an HTTP MC repo is nothing more than an HTTP PUT. >>> >>> You should be able to do that manually with just ZnClient. >> Well, yes. But I'm just clicking the save button on the monticello browser... >> >> Now, I tested with squeaksource3: >> >> - I commit in squeaksource 3 using the monticello browser: the file in package-cache is OK, the file in squeaksource3 is OK >> http://ss3.gemtalksystems.com/ss?_s=WvI7T3UuBKEaYUrR&_k=ukyWjav7hA-MhHIz >> >> - I make a copy of the file from the monticello UI to a smalltalkhub repository. The file in smalltalkhub is not the one I want. >> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >> >> In both Squeaksource3 and Smalltalkhub I have the same UUID, project name, version number, commit message, but the MCZ file that I download from them is different. Even, making a diff from SmalltalkHub's UI shows me a diff against a completely different package (RoboticTable) that is from Santiago Bragagnolo, and that I guess it is a private project because it is not listed and cannot browsed. >> >> Making a diff on other versions, such as http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… , makes a diff against a version of the Makros package, which is also from Santiago Bragagnolo, but this is not a private project. >> >> Aaaand, now I see a problem! >> >> both my test package: >> >> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >> >> and the one of Santiago >> >> http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-Santiago… >> >> have the same UUID!!!!!! >> >> Maybe this is because of my debian 64bits? Hmm maybe the UUID plugin is not loading? I'll check that for now, because I cannot work if I cannot commit :). If somebody has an idea, It is VERY welcome! >> >> Thanks for reading my loud ranting/reasoning, >> Guille >>> >>>> On 04 Feb 2016, at 10:52, Guille Polito <guillermopolito(a)gmail.com> wrote: >>>> >>>> So far, I'm blaming Smalltalkhub: >>>> >>>> - I create a new empty package. >>>> - I commit it to a local directory, it works ok. >>>> - I commit it to a smalltalkhub repository: the file in my package cache is ok, but the file in smalltalkhub is corrupted >>>> e.g., http://www.smalltalkhub.com/#!/~Guille/playground/versions/test-GuillermoPo… >>>> >>>> The strange thing is that it is a recurrent bug. I cannot commit to smalltalkhub, not even do a push of a version in my package cache. Smalltalkhub always shows a buggy version. >>>> >>>> I'll now try with squeaksource 3 to narrow my conclusions. >>>> >>>> On 02/04/2016 10:33 AM, Guille Polito wrote: >>>>> I tried for one hour yesterday to understand the problem :). This morning my priority was to not lose my code because I noticed the bug a couple of hours after my commits... Thanks I remembered to save my image and that the good old fileout in .st is working! >>>>> >>>>> I'll keep trying to reproduce and keep you posted >>>>> >>>>> On 02/04/2016 10:21 AM, stepharo wrote: >>>>>> Hi guille >>>>>> >>>>>> Esteban got some problems with MC recently >>>>>> so it would be good to have a reproducible case. >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> Le 4/2/16 10:07, Guille Polito a Ã©crit : >>>>>>> Ok, I am puzzled. I downloaded a new fresh image, in a fresh directory, worked on something else, committed, and my commit is completely broken. >>>>>>> Attached screenshot of what monticello shows me. >>>>>>> >>>>>>> I'm on debian jessie 64bits. Maybe it has something to do? >>>>>>> >>>>>>> On 02/03/2016 03:41 PM, Guille Polito wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I'm finally back, rechecking this issue: >>>>>>>> >>>>>>>> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >>>>>>>> >>>>>>>> I remade the Slice to load in latest Pharo5 with the new Spur changes, plus some fixes proposed by Nicolai. I can load the slice in a new image and everything looks ok. So far so good. >>>>>>>> >>>>>>>> Now, the monkey starts checking the Slice and somehow it cannot load the Slice due to "dependencies to some classes". Of course, the slice I submitted does not depend on the packages on the complaint, and locally it loads well. Moreover, I never had/worked with those classes, nor they were installed in my system. Even, I have a new machine which is clean so I cannot believe I have some interference due to some package cache... >>>>>>>> >>>>>>>> The message of the monkey is here: >>>>>>>> >>>>>>>> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/26128//artifact/val… >>>>>>>> >>>>>>>> Did somebody find some similar problem or it is just me? I believe the problem is on the monkey side, but I have no clue... Maybe somebody has a better idea. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> Guille >>>>>> >>>> >>> >> > >

Feb. 4, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Guille Polito

And yes, linux VM's are not shipped with the UUID plugin... at least not since 2014/2013... Also, I believe the plugin is not compiled as internal since it is not listed in Smalltalk vm listBuiltinModules. Smalltalk vm listLoadedModules. On 02/04/2016 11:12 AM, Guille Polito wrote: > > On 02/04/2016 10:58 AM, Sven Van Caekenberghe wrote: >> But StHub did not change for a long time, no ? > I know... >> >> Saving to an HTTP MC repo is nothing more than an HTTP PUT. >> >> You should be able to do that manually with just ZnClient. > Well, yes. But I'm just clicking the save button on the monticello > browser... > > Now, I tested with squeaksource3: > > - I commit in squeaksource 3 using the monticello browser: the file in > package-cache is OK, the file in squeaksource3 is OK > http://ss3.gemtalksystems.com/ss?_s=WvI7T3UuBKEaYUrR&_k=ukyWjav7hA-MhHIz > > - I make a copy of the file from the monticello UI to a smalltalkhub > repository. The file in smalltalkhub is not the one I want. > http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… > > > In both Squeaksource3 and Smalltalkhub I have the same UUID, project > name, version number, commit message, but the MCZ file that I download > from them is different. Even, making a diff from SmalltalkHub's UI > shows me a diff against a completely different package (RoboticTable) > that is from Santiago Bragagnolo, and that I guess it is a private > project because it is not listed and cannot browsed. > > Making a diff on other versions, such as > http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… > , makes a diff against a version of the Makros package, which is also > from Santiago Bragagnolo, but this is not a private project. > > Aaaand, now I see a problem! > > both my test package: > > http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… > > > and the one of Santiago > > http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-Santiago… > > > have the same UUID!!!!!! > > Maybe this is because of my debian 64bits? Hmm maybe the UUID plugin > is not loading? I'll check that for now, because I cannot work if I > cannot commit :). If somebody has an idea, It is VERY welcome! > > Thanks for reading my loud ranting/reasoning, > Guille >> >>> On 04 Feb 2016, at 10:52, Guille Polito <guillermopolito(a)gmail.com> >>> wrote: >>> >>> So far, I'm blaming Smalltalkhub: >>> >>> - I create a new empty package. >>> - I commit it to a local directory, it works ok. >>> - I commit it to a smalltalkhub repository: the file in my package >>> cache is ok, but the file in smalltalkhub is corrupted >>> e.g., >>> http://www.smalltalkhub.com/#!/~Guille/playground/versions/test-GuillermoPo… >>> >>> The strange thing is that it is a recurrent bug. I cannot commit to >>> smalltalkhub, not even do a push of a version in my package cache. >>> Smalltalkhub always shows a buggy version. >>> >>> I'll now try with squeaksource 3 to narrow my conclusions. >>> >>> On 02/04/2016 10:33 AM, Guille Polito wrote: >>>> I tried for one hour yesterday to understand the problem :). This >>>> morning my priority was to not lose my code because I noticed the >>>> bug a couple of hours after my commits... Thanks I remembered to >>>> save my image and that the good old fileout in .st is working! >>>> >>>> I'll keep trying to reproduce and keep you posted >>>> >>>> On 02/04/2016 10:21 AM, stepharo wrote: >>>>> Hi guille >>>>> >>>>> Esteban got some problems with MC recently >>>>> so it would be good to have a reproducible case. >>>>> >>>>> Stef >>>>> >>>>> >>>>> Le 4/2/16 10:07, Guille Polito a Ã©crit : >>>>>> Ok, I am puzzled. I downloaded a new fresh image, in a fresh >>>>>> directory, worked on something else, committed, and my commit is >>>>>> completely broken. >>>>>> Attached screenshot of what monticello shows me. >>>>>> >>>>>> I'm on debian jessie 64bits. Maybe it has something to do? >>>>>> >>>>>> On 02/03/2016 03:41 PM, Guille Polito wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> I'm finally back, rechecking this issue: >>>>>>> >>>>>>> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >>>>>>> >>>>>>> >>>>>>> I remade the Slice to load in latest Pharo5 with the new Spur >>>>>>> changes, plus some fixes proposed by Nicolai. I can load the >>>>>>> slice in a new image and everything looks ok. So far so good. >>>>>>> >>>>>>> Now, the monkey starts checking the Slice and somehow it cannot >>>>>>> load the Slice due to "dependencies to some classes". Of course, >>>>>>> the slice I submitted does not depend on the packages on the >>>>>>> complaint, and locally it loads well. Moreover, I never >>>>>>> had/worked with those classes, nor they were installed in my >>>>>>> system. Even, I have a new machine which is clean so I cannot >>>>>>> believe I have some interference due to some package cache... >>>>>>> >>>>>>> The message of the monkey is here: >>>>>>> >>>>>>> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/26128//artifact/val… >>>>>>> >>>>>>> >>>>>>> Did somebody find some similar problem or it is just me? I >>>>>>> believe the problem is on the monkey side, but I have no clue... >>>>>>> Maybe somebody has a better idea. >>>>>>> >>>>>>> Thanks! >>>>>>> Guille >>>>> >>> >> >

Feb. 4, 2016

Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name

by Guille Polito

On 02/04/2016 10:58 AM, Sven Van Caekenberghe wrote: > But StHub did not change for a long time, no ? I know... > > Saving to an HTTP MC repo is nothing more than an HTTP PUT. > > You should be able to do that manually with just ZnClient. Well, yes. But I'm just clicking the save button on the monticello browser... Now, I tested with squeaksource3: - I commit in squeaksource 3 using the monticello browser: the file in package-cache is OK, the file in squeaksource3 is OK http://ss3.gemtalksystems.com/ss?_s=WvI7T3UuBKEaYUrR&_k=ukyWjav7hA-MhHIz - I make a copy of the file from the monticello UI to a smalltalkhub repository. The file in smalltalkhub is not the one I want. http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… In both Squeaksource3 and Smalltalkhub I have the same UUID, project name, version number, commit message, but the MCZ file that I download from them is different. Even, making a diff from SmalltalkHub's UI shows me a diff against a completely different package (RoboticTable) that is from Santiago Bragagnolo, and that I guess it is a private project because it is not listed and cannot browsed. Making a diff on other versions, such as http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… , makes a diff against a version of the Makros package, which is also from Santiago Bragagnolo, but this is not a private project. Aaaand, now I see a problem! both my test package: http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… and the one of Santiago http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-Santiago… have the same UUID!!!!!! Maybe this is because of my debian 64bits? Hmm maybe the UUID plugin is not loading? I'll check that for now, because I cannot work if I cannot commit :). If somebody has an idea, It is VERY welcome! Thanks for reading my loud ranting/reasoning, Guille > >> On 04 Feb 2016, at 10:52, Guille Polito <guillermopolito(a)gmail.com> wrote: >> >> So far, I'm blaming Smalltalkhub: >> >> - I create a new empty package. >> - I commit it to a local directory, it works ok. >> - I commit it to a smalltalkhub repository: the file in my package cache is ok, but the file in smalltalkhub is corrupted >> e.g., http://www.smalltalkhub.com/#!/~Guille/playground/versions/test-GuillermoPo… >> >> The strange thing is that it is a recurrent bug. I cannot commit to smalltalkhub, not even do a push of a version in my package cache. Smalltalkhub always shows a buggy version. >> >> I'll now try with squeaksource 3 to narrow my conclusions. >> >> On 02/04/2016 10:33 AM, Guille Polito wrote: >>> I tried for one hour yesterday to understand the problem :). This morning my priority was to not lose my code because I noticed the bug a couple of hours after my commits... Thanks I remembered to save my image and that the good old fileout in .st is working! >>> >>> I'll keep trying to reproduce and keep you posted >>> >>> On 02/04/2016 10:21 AM, stepharo wrote: >>>> Hi guille >>>> >>>> Esteban got some problems with MC recently >>>> so it would be good to have a reproducible case. >>>> >>>> Stef >>>> >>>> >>>> Le 4/2/16 10:07, Guille Polito a Ã©crit : >>>>> Ok, I am puzzled. I downloaded a new fresh image, in a fresh directory, worked on something else, committed, and my commit is completely broken. >>>>> Attached screenshot of what monticello shows me. >>>>> >>>>> I'm on debian jessie 64bits. Maybe it has something to do? >>>>> >>>>> On 02/03/2016 03:41 PM, Guille Polito wrote: >>>>>> Hi all, >>>>>> >>>>>> I'm finally back, rechecking this issue: >>>>>> >>>>>> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >>>>>> >>>>>> I remade the Slice to load in latest Pharo5 with the new Spur changes, plus some fixes proposed by Nicolai. I can load the slice in a new image and everything looks ok. So far so good. >>>>>> >>>>>> Now, the monkey starts checking the Slice and somehow it cannot load the Slice due to "dependencies to some classes". Of course, the slice I submitted does not depend on the packages on the complaint, and locally it loads well. Moreover, I never had/worked with those classes, nor they were installed in my system. Even, I have a new machine which is clean so I cannot believe I have some interference due to some package cache... >>>>>> >>>>>> The message of the monkey is here: >>>>>> >>>>>> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/26128//artifact/val… >>>>>> >>>>>> Did somebody find some similar problem or it is just me? I believe the problem is on the monkey side, but I have no clue... Maybe somebody has a better idea. >>>>>> >>>>>> Thanks! >>>>>> Guille >>>> >> >

Feb. 4, 2016