February 2016 - Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

I can do the integration too, but I need some people to say go ahead. I vote for replacing everything, there is no need for a plugin. > On 09 Feb 2016, at 09:25, Guille Polito <guillermopolito(a)gmail.com> wrote: > > Sven, just to answer your last question. The UUID generation right now generates the UUID fields like this: > > UUIDGenerator>>generateFieldsVersion4 > > timeLow := self generateRandomBitsOfLength: 32. > timeMid := self generateRandomBitsOfLength: 16. > timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength: 12). > clockSeqHiAndReserved := 16r80 bitOr: (self generateRandomBitsOfLength: 6). > clockSeqLow := self generateRandomBitsOfLength: 8. > node := self generateRandomBitsOfLength: 48. > > So... It's basically completely random. There is no part of the UUID that is actually based on the node, the clock or the time. It is actually a random string of bits that are generated using a number from /dev/urandom as seed (in linux). > > Does the mac VM include the plugin? (I do not have a mac any more to test fast ^^) > > I'll work on the integration of NeoUUID now, I hope this is the kind of issues that got integrated in code-freeze :) > > Guille > > On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote: >> Here is a new version, in preparation of possible integration in the main image: >> >> === >> Name: Neo-UUID-SvenVanCaekenberghe.2 >> Author: SvenVanCaekenberghe >> Time: 8 February 2016, 8:33:04.141334 pm >> UUID: a909453e-35dd-4c25-8273-62a9b2bd982e >> Ancestors: Neo-UUID-SvenVanCaekenberghe.1 >> >> Streamline UUID generation >> >> Add a current, shared instance >> >> Added better class and method comments >> >> Add more tests >> >> As suggested by Henrik Johansen, change to a version 0 UUID to indicate that we follow a custom approach >> === >> >> The class comments now reads as follows: >> >> === >> I am NeoUUIDGenerator, I generate UUIDs. >> >> An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number that can be used for identification purposes. Concretely, a UUID is a 16 element byte array. >> >> 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". >> I generate UUIDs similar, in spirit, to those defined in RFC4122, though I use version 0 to indicate that I follow none of the defined versions. This does not matter much, if at all, in practice. >> >> I try to conform to the following aspects: >> - each 'node' (machine, image, instance) should generate unique UUIDs >> - even when generating UUIDs at a very fast rate, they should remain unique >> - be fast and efficient >> >> To achieve this goal, I >> - take several aspects into account to generate a unique node ID >> - combine a clock, a counter and some random bits >> - hold a state, protected for multi user access >> >> I can generate about 500K UUIDs per second. >> >> Implementation: >> >> Although a UUID should be seen as totally opaque, here is the concrete way I generate one: >> - the first 8 bytes are the millisecond clock value with the smallest quantity first; this means that the later of these 8 bytes will be identical when generated with small(er) timespans; within the same millisecond, the full first 8 bytes will be identical >> - the next 2 bytes represent a counter with safe overflow, held as protected state inside me; after 2*16 this value will repeat; the counter initalizes with a random value >> - the next 2 bytes are simply random, based on the system PRNG, Random >> - the final 4 bytes represent the node ID; the node ID is unique per instance of me, across OS environments where the image might run; the node ID is the MD5 hash of a string that is the concatenation of several elements (see #computeNodeIdentifier) >> Some bits are set to some predefined value, to indicate the variant and version (see #setVariantAndVersion:) >> >> Usage: >> >> NeoUUIDGenerator next. >> NeoUUIDGenerator current next. >> NeoUUIDGenerator new next. >> >> Sharing an instance is more efficient and correct. >> Instances should be reset whenever the image comes up. >> >> See also: >> >> http://en.wikipedia.org/wiki/UUID >> https://tools.ietf.org/html/rfc4122 >> === >> >> If we integrate this, I think we should replace the old generator and the use of the primitive/plugin. But that requires at least some support apart from me. >> >> And although I think that we should integrate this generator and get rid of the plugin, I think there is probably an underlying problem here (why did the generator fail ?) that could be important to find. >> >> Sven >> >>> On 08 Feb 2016, at 10:38, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >>> >>>> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <sven(a)stfx.eu> 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. >>>>> 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 ? >>> My rationale was that it is currently unassigned, and the least likely number to be chosen as identifier by new versions of the standard. >>> IOW, for those who care, it might raise a "hmm, this is strange, better check the source", upon which they will discover it is generated in a non-standard fashion (but can verify for themselves it is generated in a way still pretty much guaranteed to be unique), and the rest... well, they can (most probably) keep on living happily without ever seeing a collision. >>> >>> Cheers, >>> Henry >> >

Feb. 9, 2016

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

by Guille Polito

Sven, just to answer your last question. The UUID generation right now generates the UUID fields like this: UUIDGenerator>>generateFieldsVersion4 timeLow := self generateRandomBitsOfLength: 32. timeMid := self generateRandomBitsOfLength: 16. timeHiAndVersion := 16r4000 bitOr: (self generateRandomBitsOfLength: 12). clockSeqHiAndReserved := 16r80 bitOr: (self generateRandomBitsOfLength: 6). clockSeqLow := self generateRandomBitsOfLength: 8. node := self generateRandomBitsOfLength: 48. So... It's basically completely random. There is no part of the UUID that is actually based on the node, the clock or the time. It is actually a random string of bits that are generated using a number from /dev/urandom as seed (in linux). Does the mac VM include the plugin? (I do not have a mac any more to test fast ^^) I'll work on the integration of NeoUUID now, I hope this is the kind of issues that got integrated in code-freeze :) Guille On 02/08/2016 08:39 PM, Sven Van Caekenberghe wrote: > Here is a new version, in preparation of possible integration in the main image: > > === > Name: Neo-UUID-SvenVanCaekenberghe.2 > Author: SvenVanCaekenberghe > Time: 8 February 2016, 8:33:04.141334 pm > UUID: a909453e-35dd-4c25-8273-62a9b2bd982e > Ancestors: Neo-UUID-SvenVanCaekenberghe.1 > > Streamline UUID generation > > Add a current, shared instance > > Added better class and method comments > > Add more tests > > As suggested by Henrik Johansen, change to a version 0 UUID to indicate that we follow a custom approach > === > > The class comments now reads as follows: > > === > I am NeoUUIDGenerator, I generate UUIDs. > > An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number that can be used for identification purposes. Concretely, a UUID is a 16 element byte array. > > 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". > > I generate UUIDs similar, in spirit, to those defined in RFC4122, though I use version 0 to indicate that I follow none of the defined versions. This does not matter much, if at all, in practice. > > I try to conform to the following aspects: > - each 'node' (machine, image, instance) should generate unique UUIDs > - even when generating UUIDs at a very fast rate, they should remain unique > - be fast and efficient > > To achieve this goal, I > - take several aspects into account to generate a unique node ID > - combine a clock, a counter and some random bits > - hold a state, protected for multi user access > > I can generate about 500K UUIDs per second. > > Implementation: > > Although a UUID should be seen as totally opaque, here is the concrete way I generate one: > - the first 8 bytes are the millisecond clock value with the smallest quantity first; this means that the later of these 8 bytes will be identical when generated with small(er) timespans; within the same millisecond, the full first 8 bytes will be identical > - the next 2 bytes represent a counter with safe overflow, held as protected state inside me; after 2*16 this value will repeat; the counter initalizes with a random value > - the next 2 bytes are simply random, based on the system PRNG, Random > - the final 4 bytes represent the node ID; the node ID is unique per instance of me, across OS environments where the image might run; the node ID is the MD5 hash of a string that is the concatenation of several elements (see #computeNodeIdentifier) > > Some bits are set to some predefined value, to indicate the variant and version (see #setVariantAndVersion:) > > Usage: > > NeoUUIDGenerator next. > NeoUUIDGenerator current next. > NeoUUIDGenerator new next. > > Sharing an instance is more efficient and correct. > Instances should be reset whenever the image comes up. > > See also: > > http://en.wikipedia.org/wiki/UUID > https://tools.ietf.org/html/rfc4122 > === > > If we integrate this, I think we should replace the old generator and the use of the primitive/plugin. But that requires at least some support apart from me. > > And although I think that we should integrate this generator and get rid of the plugin, I think there is probably an underlying problem here (why did the generator fail ?) that could be important to find. > > Sven > >> On 08 Feb 2016, at 10:38, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >>> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <sven(a)stfx.eu> 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. >>>> 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 ? >> My rationale was that it is currently unassigned, and the least likely number to be chosen as identifier by new versions of the standard. >> IOW, for those who care, it might raise a "hmm, this is strange, better check the source", upon which they will discover it is generated in a non-standard fashion (but can verify for themselves it is generated in a way still pretty much guaranteed to be unique), and the rest... well, they can (most probably) keep on living happily without ever seeing a collision. >> >> Cheers, >> Henry >

Feb. 9, 2016

Re: [Pharo-dev] Bloc Documentation

by Aliaksei Syrel

Bloc does not have examples yet. What classes/methods do you need to be commented first to understand the system? On Feb 9, 2016 4:46 AM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > I realize it's a fast-moving work in progress, but what's the best way to > try > to understand the system? > > For example, I saw class comments, some of which seem to be out of date, > and > I no longer see many of the examples I remember from last year - maybe I > have to load them separately? > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Bloc-Documentation-tp4876448.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Feb. 9, 2016

Re: [Pharo-dev] GTDebugger missing block parameters?

by Nicolai Hess

2016-01-31 10:50 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-01-28 1:37 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Nicolai >> >> On Jan 15, 2016, at 4:57 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> 2016-01-15 13:26 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: >> >>> When debugging a method containing a block with a parameter, >>> the parameter is missing from the variable list (because it is aliased?). >>> >> >> Yes, this happens with block vars from optimized blocks (ifNotNil:). >> The tempvars arent't local to the block, but method vars. >> And the debugger (debuggerMap) doesn't knows about this (this happens on >> both debuggers AFAIK). >> >> >> It works in the Squeak debugger. Try e.g. debugging >> Character space printOn: Transcript >> > > Yes, thanks Eliot. > I try to find out what happens here (opals based debugger map works quite > different from squeak compiler infrastructure (parser / handling of > optimized block contexts). > > I opened a bug report 17434 <https://pharo.fogbugz.com/f/cases/17434/debugger-missing-block-local-var-fo…> debugger missing block local var for optimized blocks with a test case and a solution. But I am not satisfied with this. need more time to think about this. > > >> >> >> >>> >>> Stephan >>> >> >> >

Feb. 9, 2016

Bloc Documentation

by Sean P. DeNigris

I realize it's a fast-moving work in progress, but what's the best way to try to understand the system? For example, I saw class comments, some of which seem to be out of date, and I no longer see many of the examples I remember from last year - maybe I have to load them separately? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Documentation-tp4876448.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 9, 2016

[Survey] Users and issue tracking systems

by Tommaso Dal Sasso

Hello everybody, at the REVEAL group in Lugano, we are conducting a study on how users interact with issue tracking systems. It would really help if you could complete the survey at: http://shoreline.inf.usi.ch/survey It is a self-hosted seaside application, so the data is not shared with third parties and it will be used for research tasks in an aggregated fashion. The estimated completion time is under 5 minutes, so it is really quick. The survey will close at the end of this week. Thanks for you cooperation, have a nice week! Tommaso Dal Sasso

Feb. 8, 2016

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

by Sven Van Caekenberghe

Here is a new version, in preparation of possible integration in the main image: === Name: Neo-UUID-SvenVanCaekenberghe.2 Author: SvenVanCaekenberghe Time: 8 February 2016, 8:33:04.141334 pm UUID: a909453e-35dd-4c25-8273-62a9b2bd982e Ancestors: Neo-UUID-SvenVanCaekenberghe.1 Streamline UUID generation Add a current, shared instance Added better class and method comments Add more tests As suggested by Henrik Johansen, change to a version 0 UUID to indicate that we follow a custom approach === The class comments now reads as follows: === I am NeoUUIDGenerator, I generate UUIDs. An RFC4122 Universally Unique Identifier (UUID) is an opaque 128-bit number that can be used for identification purposes. Concretely, a UUID is a 16 element byte array. 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". I generate UUIDs similar, in spirit, to those defined in RFC4122, though I use version 0 to indicate that I follow none of the defined versions. This does not matter much, if at all, in practice. I try to conform to the following aspects: - each 'node' (machine, image, instance) should generate unique UUIDs - even when generating UUIDs at a very fast rate, they should remain unique - be fast and efficient To achieve this goal, I - take several aspects into account to generate a unique node ID - combine a clock, a counter and some random bits - hold a state, protected for multi user access I can generate about 500K UUIDs per second. Implementation: Although a UUID should be seen as totally opaque, here is the concrete way I generate one: - the first 8 bytes are the millisecond clock value with the smallest quantity first; this means that the later of these 8 bytes will be identical when generated with small(er) timespans; within the same millisecond, the full first 8 bytes will be identical - the next 2 bytes represent a counter with safe overflow, held as protected state inside me; after 2*16 this value will repeat; the counter initalizes with a random value - the next 2 bytes are simply random, based on the system PRNG, Random - the final 4 bytes represent the node ID; the node ID is unique per instance of me, across OS environments where the image might run; the node ID is the MD5 hash of a string that is the concatenation of several elements (see #computeNodeIdentifier) Some bits are set to some predefined value, to indicate the variant and version (see #setVariantAndVersion:) Usage: NeoUUIDGenerator next. NeoUUIDGenerator current next. NeoUUIDGenerator new next. Sharing an instance is more efficient and correct. Instances should be reset whenever the image comes up. See also: http://en.wikipedia.org/wiki/UUID https://tools.ietf.org/html/rfc4122 === If we integrate this, I think we should replace the old generator and the use of the primitive/plugin. But that requires at least some support apart from me. And although I think that we should integrate this generator and get rid of the plugin, I think there is probably an underlying problem here (why did the generator fail ?) that could be important to find. Sven > On 08 Feb 2016, at 10:38, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > >> >> On 08 Feb 2016, at 10:29 , Sven Van Caekenberghe <sven(a)stfx.eu> 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. >>> 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 ? > > My rationale was that it is currently unassigned, and the least likely number to be chosen as identifier by new versions of the standard. > IOW, for those who care, it might raise a "hmm, this is strange, better check the source", upon which they will discover it is generated in a non-standard fashion (but can verify for themselves it is generated in a way still pretty much guaranteed to be unique), and the rest... well, they can (most probably) keep on living happily without ever seeing a collision. > > Cheers, > Henry

Feb. 8, 2016

[Vm-dev] New spur crash detected

by Denis Kudriashov

Hi. I found reproducible problem with forwardBecome. It exists on Pharo and Squeak. For Pharo we get issue 17536 <https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s…> . Try to execute following script: obj1 := 20@10. obj2 := 50@30. weak := WeakValueAssociation new. weak key: obj1.. obj1 becomeForward: obj2. Smalltalk garbageCollect. weak key class. "-> SmallInteger. If you try to print 'weak key' image will crash" Lines with become and garbage collection should be executed together. Instead anything is working correctly. So it is somehow related to stack state. Interesting that WeakArray is working correctly. Try script with weak := WeakArray new: 1. weak at: 1 put: obj1. Best regards, Denis

Feb. 8, 2016

Re: [Pharo-dev] Help with bugfix process

by Julien Delplanque

For future reader, it was a problem with UUID generation (there is right now an issue about it [1]), I used NeoUUID and it works see [2][3]. Julien Links: [1]: https://pharo.fogbugz.com/f/cases/17544/UUIDs-are-not-so-unique [2]: http://forum.world.st/Need-help-with-Monkey-Removing-Object-gt-gt-name-td48… [3]: http://mc.stfx.eu/Neo/ On 07/02/16 14:04, Julien Delplanque wrote: > I just tried using Lubuntu 32 bits on Virtualbox and I still have the > same problem... > Is it possible that the problem is something else? > > Julien > > On 07/02/16 13:41, Julien Delplanque wrote: >> Ok I will try this :-). >> >> Julien >> >> On 07/02/16 13:36, Nicolai Hess wrote: >>> Yes, that should work. >>> Am 07.02.2016 1:33 nachm. schrieb "Julien Delplanque" >>> <julien(a)tamere.eu>: >>> >>>> I do not have a real 32bit machine available, would it be ok to use a >>>> virtual 32bit machine? >>>> >>>> Julien >>>> >>>> On 07/02/16 13:26, Nicolai Hess wrote: >>>> >>>>> No, you did it right, and it should work that way. >>>>> At the Moment, we have a problem with uuid genetation on Linux >>>>> 64bit. Can >>>>> you try to recreate and resubmit the change on a 32bit Machine? >>>>> Am 07.02.2016 1:05 nachm. schrieb "Julien Delplanque" >>>>> <julien(a)tamere.eu>: >>>>> >>>>> Hello, >>>>>> I am trying to submit a simple enhancement to WindowModel (spec) by >>>>>> adding >>>>>> #activate message [1]. >>>>>> >>>>>> I follow the process described here [2]. The problem is that when I >>>>>> commit >>>>>> my Slice in Pharo50Inbox, it uploads my changes but when I try to >>>>>> load my >>>>>> slice (in a fresh image) I have some strange things happening: >>>>>> >>>>>> I try to load my slice by: >>>>>> 1. Opening Monticello browser. >>>>>> 2. Selecting Pharo50Inbox in the right lists. >>>>>> 3. I click on 'Open' button. >>>>>> 4. I search for my slice in the right list of the window opened. >>>>>> >>>>>> Then, there are two strange things: >>>>>> 1. I can see my slice (with the right name) but when I try to >>>>>> load it >>>>>> using the button 'Load', it does nothing and if I click on >>>>>> changes it >>>>>> shows >>>>>> nothing. >>>>>> 2. The data displayed in the text field on the bottom of the >>>>>> window is >>>>>> wrong, the author is not my username, the package name is not the >>>>>> same as >>>>>> displayed in the right list and the commit message is not my commit >>>>>> message >>>>>> (see attached image). >>>>>> >>>>>> Am I doing something wrong? I think I follow the process >>>>>> correctly so I >>>>>> do >>>>>> not understand what is going on... >>>>>> >>>>>> I already submitted the fix twice and I am sorry if it creates >>>>>> unwanted >>>>>> work for someone. :-( >>>>>> >>>>>> Thanks in advance for the help, >>>>>> >>>>>> Julien >>>>>> >>>>>> [1]: https://pharo.fogbugz.com/f/cases/17528 >>>>>> [2]: http://pharo.org/contribute-propose-fix >>>>>> >>>>>> >>>> >> >

Feb. 8, 2016

Re: [Pharo-dev] UUIDs are not so unique [WAS] Removing Object>>name

by Julien Delplanque

Hello, Looks like I have the same problem as I was saying in another thread [1]. I tried to use NeoUUID and I was able to commit my change. I use Archlinux on a 64bit machine: $ uname -a Linux msi 4.4.1-2-ARCH #1 SMP PREEMPT Wed Feb 3 13:12:33 UTC 2016 x86_64 GNU/Linux Regards, Julien Link: [1]: http://forum.world.st/Help-with-bugfix-process-td4876210.html On 08/02/16 16:20, Guille Polito wrote: > Yes, creepy. > > However, I do not know if this is reproducible from some other > machine/environment or just in mine, as nobody told so... > > On 02/08/2016 02:22 PM, Stephan Eggermont wrote: >> On 08-02-16 14:13, Guille Polito wrote: >>> The thing is that it is not a monkey problem. The monkey asks >>> Smalltalkhub for the right file, but SmalltalkHub retrieves the wrong >>> mcz. And that's because Smalltalkhub associates a commit to an mcz file >>> by the UUID of the commit. >> >> So we lost source code? A slice in the inbox that has a duplicate UUID? >> >> >> Stephan >> >> >> > >

Feb. 8, 2016