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 <[email protected]> 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 <[email protected]> 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 >>>>>> >>>> >>> >> > >
