[Need help with Monkey] Removing Object>>name
Locked
123
123
[Need help with Monkey] Removing Object>>name
 
|
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/validationReport.html 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 |
Re: [Need help with Monkey] Removing Object>>name
|
|
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/validationReport.html > > > 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 |
Selection_002.png (65K) |
|
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/validationReport.html >> >> >> 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 > |
Re: [Need help with Monkey] Removing Object>>name
|
|
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/validationReport.html >>> >>> >>> 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 >> > > |
Re: [Need help with Monkey] Removing Object>>name
|
|
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-GuillermoPolito.3 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/validationReport.html >>>> >>>> >>>> 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 >>> >> >> > |
Re: [Need help with Monkey] Removing Object>>name
|
|
But StHub did not change for a long time, no ?
Saving to an HTTP MC repo is nothing more than an HTTP PUT. You should be able to do that manually with just ZnClient. > On 04 Feb 2016, at 10:52, Guille Polito <[hidden email]> 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-GuillermoPolito.3 > > 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/validationReport.html >>>>> >>>>> 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 >>>> >>> >>> >> > > |
Re: [Need help with Monkey] Removing Object>>name
|
|
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.4 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.2 , 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.2 and the one of Santiago http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-SantiagoBragagnolo.32 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 <[hidden email]> 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-GuillermoPolito.3 >> >> 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/validationReport.html >>>>>> >>>>>> 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 >>>> >> > |
Re: [Need help with Monkey] Removing Object>>name
|
|
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.4 > > > 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.2 > , 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.2 > > > and the one of Santiago > > http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-SantiagoBragagnolo.32 > > > 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 <[hidden email]> >>> 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-GuillermoPolito.3 >>> >>> 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/validationReport.html >>>>>>> >>>>>>> >>>>>>> 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 >>>>> >>> >> > |
Re: [Need help with Monkey] Removing Object>>name
|
|
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 <[hidden email]> 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.4 >> >> 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.2 , 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.2 >> >> and the one of Santiago >> >> http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-SantiagoBragagnolo.32 >> >> 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 <[hidden email]> 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-GuillermoPolito.3 >>>> >>>> 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/validationReport.html >>>>>>>> >>>>>>>> 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 >>>>>> >>>> >>> >> > > |
Re: [Need help with Monkey] Removing Object>>name
|
|
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 <[hidden email]> 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.4 >>> >>> 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.2 , 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.2 >>> >>> and the one of Santiago >>> >>> http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-SantiagoBragagnolo.32 >>> >>> 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 <[hidden email]> 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-GuillermoPolito.3 >>>>> >>>>> 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/validationReport.html >>>>>>>>> >>>>>>>>> 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 >> > |
Re: [Need help with Monkey] Removing Object>>name
|
|
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 <[hidden email]> >>> 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.4 >>>> >>>> >>>> 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.2 >>>> , 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.2 >>>> >>>> >>>> and the one of Santiago >>>> >>>> http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-SantiagoBragagnolo.32 >>>> >>>> >>>> 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 >>>>>> <[hidden email]> 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-GuillermoPolito.3 >>>>>> >>>>>> 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/validationReport.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 >>> >> > |
Re: [Need help with Monkey] Removing Object>>name
|
|
> On 04 Feb 2016, at 11:55, Guille Polito <[hidden email]> 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 <[hidden email]> 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.4 >>>>> >>>>> 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.2 , 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.2 >>>>> >>>>> and the one of Santiago >>>>> >>>>> http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-SantiagoBragagnolo.32 >>>>> >>>>> 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 <[hidden email]> 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-GuillermoPolito.3 >>>>>>> >>>>>>> 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/validationReport.html >>>>>>>>>>> >>>>>>>>>>> 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 >>>> >>> >> > > |
Re: [Need help with Monkey] Removing Object>>name
|
|
More random for certain, at least much faster than we could do in Pharo, is certainly possible with a plugin. More unique... well, depends on whether you can trust the source RNG (seeded from data with enough entropy, period much greater than 2^128, etc). A single next:into:startingAt: primitive filling random data (obtained using platform primitives and/or RDRAND/RDSEED) into a buffer would be much nicer/more flexible than the current UUID primitive though. (the linked UUID library is basically just a thin wrapper around the platform primitives, plus setting variant/version bits in the returned UUID bytes) As a stopgap, one could instead use another, more general primitive (but with a less flexible api than next:into:startingAt:) in an otherwise unrelated plugin (but that is built internal to all Cog VM's, at least): rand: aBuffer <primitive: 'primitiveGatherEntropy' module: 'CroquetPlugin'> ^self primitiveFail (which, iirc, resolves to the same platform primitives as UUID lib) Also, the meaning of different UUID versions are well defined in the RFC, marking NeoUUID's as being a version 4 UUID seems somewhat ... disingenuous. Cheers, Henry
|
Re: [Need help with Monkey] Removing Object>>name
|
|
In reply to this post by Guillermo Polito
2016-02-04 11:29 GMT+01:00 Guille Polito <[hidden email]>:
It looks like Monticello ignore UUID failure and just use value from ancestor. Could you investigate it? It can be fixed in that case. |
Re: [Need help with Monkey] Removing Object>>name
|
|
In reply to this post by Henrik Sperre Johansen
> On 04 Feb 2016, at 14:02, Henrik Johansen <[hidden email]> wrote: > >> >> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe <[hidden email]> wrote: >> >> >>> On 04 Feb 2016, at 11:55, Guille Polito <[hidden email]> 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 ? > > More random for certain, at least much faster than we could do in Pharo, is certainly possible with a plugin. > More unique... well, depends on whether you can trust the source RNG (seeded from data with enough entropy, period much greater than 2^128, etc). > > A single next:into:startingAt: primitive filling random data (obtained using platform primitives and/or RDRAND/RDSEED) into a buffer would be much nicer/more flexible than the current UUID primitive though. (the linked UUID library is basically just a thin wrapper around the platform primitives, plus setting variant/version bits in the returned UUID bytes) > > As a stopgap, one could instead use another, more general primitive (but with a less flexible api than next:into:startingAt:) in an otherwise unrelated plugin (but that is built internal to all Cog VM's, at least): > rand: aBuffer > <primitive: 'primitiveGatherEntropy' module: 'CroquetPlugin'> > ^self primitiveFail > > (which, iirc, resolves to the same platform primitives as UUID lib) > > Also, the meaning of different UUID versions are well defined in the RFC, marking NeoUUID's as being a version 4 UUID seems somewhat ... disingenuous. Yes, but to 99.99% of developers, a UUID is something special/magic where some effort was made to generate something as unique as possible. If we insist on it being just 128 random bits, then why all the fuss ? Why do we even need so called standards ? Why do we need a plugin, an implementation even ? It makes no sense. Just read 16 bytes from /dev/[u]random, or the equivalent use of a RNG and be done with it. But if you tell developers that their database IDs are just plain random numbers, they will probably feels less good about them. To me UUID is a specific concept: << The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. In this context the word unique should be taken to mean "practically unique" rather than "guaranteed unique". >> Not including any 'node' information (identifying process, image, VM, machine, network endpoint), nor 'counter' does not feel right. > Cheers, > Henry |
Re: [Need help with Monkey] Removing Object>>name
|
|
In reply to this post by Guillermo Polito
Guille Polito <[hidden email]> writes:
> And yes, linux VM's are not shipped with the UUID plugin... at least not > since 2014/2013... if you tell me what to change, I can release new VM sources in http://files.pharo.org/vm/src/vm-unix-sources/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill |
Re: [Need help with Monkey] Removing Object>>name
|
|
In reply to this post by Sven Van Caekenberghe-2
On Thu, Feb 4, 2016 at 2:59 PM, Sven Van Caekenberghe <[hidden email]> wrote: 2) Misrepresenting the way the UUID was generated (a combination of node identifier + timestamp + random value, similar to type 3, but with differently sized/ordered fields) by marking it as being of type 4, which is defined to be UUID consisting of random bytes.
In my mind, you just answered that :) The standard provides 4 well-defined ways to implement something where it's guaranteed that some effort has been made to generate something as unique as possible. Why do we need a plugin, an implementation even ? It makes no sense. Just read 16 bytes from /dev/[u]random, or the equivalent use of a RNG and be done with it.
But... that's *exactly* what you tell them by marking UUID's as being of type 4. To me UUID is a specific concept: << The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. In this context the word unique should be taken to mean "practically unique" rather than "guaranteed unique". >> And I agree Neo-UUID fits that bill nicely, the values it returns *are* practically unique. The two things I disagreed with was: 1) The statement that it is possible to implement purely in Smalltalk UUID's as random as those returned by the plugin (Which, as you say, is basically reading 16 bytes from /dev/random), at least as performant, without consulting an external trusted randomness source. IOW, I think it should be marked as type 0 instead of 4, so for the 1 person in each country who might be found to assume something about the implementation based on the type field, won't later feel he's been duped when checking the generator. Cheers, Henry |
UUIDs are not so unique [WAS] Removing Object>>name
|
|
I detach the conversation from the Object>>name issue.
So, to summarize the conversation: For some reason, the UUIDs generated by my Pharo in my new machine (Debian Jessie 64bit) are not unique at all. They keep clashing with UUIDs of existing packages in Smalltalkhub. I mean with this that it is not an isolated case or a random thing. I can reproduce it every time I commit. I opened a bug for this [1]. And I marked it as show stopper, as I believe we cannot release pharo5 with this bug that prevents people from doing a commit. Then, I tested the NeoUUIDGenerator and it works better in that sense. Or at least it gives me better guarantees. I propose to replace the existing UUID generator by NeoUUID generator. The latter is not only better, but it also includes tests. What do you think? Guille [1] https://pharo.fogbugz.com/f/cases/17544/UUIDs-are-not-so-unique -------- Forwarded Message --------
On Thu, Feb 4, 2016 at 2:59 PM, Sven
Van Caekenberghe <[hidden email]> wrote:
2) Misrepresenting the way the UUID was generated (a
combination of node identifier + timestamp + random value,
similar to type 3, but with differently sized/ordered fields)
by marking it as being of type 4, which is defined to be UUID
consisting of random bytes.
In my mind, you just answered that :)
The standard provides 4 well-defined ways to implement
something where it's guaranteed that some effort has been
made to generate something as unique as possible.
Why do we need a plugin, an implementation even ? It makes no sense. Just read 16 bytes from /dev/[u]random, or the equivalent use of a RNG and be done with it.
But... that's *exactly* what you tell them by marking
UUID's as being of type 4.
To me UUID is a specific concept: << The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. In this context the word unique should be taken to mean "practically unique" rather than "guaranteed unique". >> And I agree Neo-UUID fits that bill nicely, the values
it returns *are* practically unique.
The two things I disagreed with was:
1) The statement that it is possible to implement
purely in Smalltalk UUID's as random as those returned by
the plugin (Which, as you say, is basically reading 16
bytes from /dev/random), at least as performant, without
consulting an external trusted randomness source.
IOW, I think it should be marked as
type 0 instead of 4, so for the 1 person in each country who
might be found to assume something about the implementation
based on the type field, won't later feel he's been duped when
checking the generator.
Cheers,
Henry
|
|
|
In reply to this post by Sven Van Caekenberghe-2
Hi Sven
I think that we should use your package! Can you open a bug entry and we add it. Stef Le 4/2/16 11:36, Sven Van Caekenberghe a écrit : > 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 <[hidden email]> 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.4 >>> >>> 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.2 , 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.2 >>> >>> and the one of Santiago >>> >>> http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-SantiagoBragagnolo.32 >>> >>> 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 <[hidden email]> 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-GuillermoPolito.3 >>>>> >>>>> 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/validationReport.html >>>>>>>>> >>>>>>>>> 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 >> > > |
Re: [Need help with Monkey] Removing Object>>name
|
|
In reply to this post by Henrik Sperre Johansen
> On 05 Feb 2016, at 14:12, Henrik Sperre Johansen <[hidden email]> wrote: > > > > On Thu, Feb 4, 2016 at 2:59 PM, Sven Van Caekenberghe <[hidden email]> wrote: > > > On 04 Feb 2016, at 14:02, Henrik Johansen <[hidden email]> wrote: > > > >> > >> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe <[hidden email]> wrote: > >> > >> > >>> On 04 Feb 2016, at 11:55, Guille Polito <[hidden email]> 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 ? > > > > More random for certain, at least much faster than we could do in Pharo, is certainly possible with a plugin. > > More unique... well, depends on whether you can trust the source RNG (seeded from data with enough entropy, period much greater than 2^128, etc). > > > > A single next:into:startingAt: primitive filling random data (obtained using platform primitives and/or RDRAND/RDSEED) into a buffer would be much nicer/more flexible than the current UUID primitive though. (the linked UUID library is basically just a thin wrapper around the platform primitives, plus setting variant/version bits in the returned UUID bytes) > > > > As a stopgap, one could instead use another, more general primitive (but with a less flexible api than next:into:startingAt:) in an otherwise unrelated plugin (but that is built internal to all Cog VM's, at least): > > rand: aBuffer > > <primitive: 'primitiveGatherEntropy' module: 'CroquetPlugin'> > > ^self primitiveFail > > > > (which, iirc, resolves to the same platform primitives as UUID lib) > > > > Also, the meaning of different UUID versions are well defined in the RFC, marking NeoUUID's as being a version 4 UUID seems somewhat ... disingenuous. > > Yes, but to 99.99% of developers, a UUID is something special/magic where some effort was made to generate something as unique as possible. > > If we insist on it being just 128 random bits, then why all the fuss ? Why do we even need so called standards ? > In my mind, you just answered that :) > The standard provides 4 well-defined ways to implement something where it's guaranteed that some effort has been made to generate something as unique as possible. > > Why do we need a plugin, an implementation even ? It makes no sense. Just read 16 bytes from /dev/[u]random, or the equivalent use of a RNG and be done with it. > > > But if you tell developers that their database IDs are just plain random numbers, they will probably feels less good about them. > > > But... that's *exactly* what you tell them by marking UUID's as being of type 4. > > To me UUID is a specific concept: << The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. In this context the word unique should be taken to mean "practically unique" rather than "guaranteed unique". >> > > Not including any 'node' information (identifying process, image, VM, machine, network endpoint), nor 'counter' does not feel right. > > And I agree Neo-UUID fits that bill nicely, the values it returns *are* practically unique. > The two things I disagreed with was: > 1) The statement that it is possible to implement purely in Smalltalk UUID's as random as those returned by the plugin (Which, as you say, is basically reading 16 bytes from /dev/random), at least as performant, without consulting an external trusted randomness source. Agreed. > 2) Misrepresenting the way the UUID was generated (a combination of node identifier + timestamp + random value, similar to type 3, but with differently sized/ordered fields) by marking it as being of type 4, which is defined to be UUID consisting of random bytes. > IOW, I think it should be marked as type 0 instead of 4, so for the 1 person in each country who might be found to assume something about the implementation based on the type field, won't later feel he's been duped when checking the generator. OK, I certainly want to change the type. Thing is, I cannot find a reference to type 0 anywhere that I am looking (I mostly used https://en.wikipedia.org/wiki/Universally_unique_identifier). Where did you find a definition of type 0 ? Or would that be a way to say 'no specific type' then ? > Cheers, > Henry |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |