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 <[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
