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

Re: [Pharo-dev] Bloc Documentation

by Aliaksei Syrel

> > formerOwner: anElementOrNil > "Set my former or remove property of argument is nil" > > anElementOrNil > ifNil: [ self removeProperty: #formerOwner ] > ifNotNil: [ self setProperty: #formerOwner toValue: > anElementOrNil ] I hate this method :) It is identical to Morph>>#formerOwner: (ctrl+c, ctrl+v) Basically it should be removed after reimplementation of drag&drop mechanism. Current one was copied from morphic to support compatibility. We will need to find better solution. Drag&drop is not so easy to do right. Help from community is appreciated :) Cheers, Alex On Tue, Feb 9, 2016 at 1:12 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > formerOwner: anElementOrNil > "Set my former or remove property of argument is nil" > > anElementOrNil > ifNil: [ self removeProperty: #formerOwner ] > ifNotNil: [ self setProperty: #formerOwner toValue: > anElementOrNil ] > > I'd prefer to see a #setProperty:toValueOrRemove: there, > as that pattern is used a lot. > > Stephan > > >

Feb. 9, 2016

Re: [Pharo-dev] Bloc Documentation

by Stephan Eggermont

On 09/02/16 11:53, Aliaksei Syrel wrote: > So I'm asking: what parts of Bloc do you find especially complicated to > understand. so we could concentrate on them? Root class > BlElement(methods) has good doc, so please use it to start your > exploration journey. A lot of confusing comes from BlMorphXX things still being around all over the place. I prefer good examples as a starting point. Making Bloc-DragPanels work again? Stephan

Feb. 9, 2016

Re: [Pharo-dev] Bloc Documentation

by Stephan Eggermont

formerOwner: anElementOrNil "Set my former or remove property of argument is nil" anElementOrNil ifNil: [ self removeProperty: #formerOwner ] ifNotNil: [ self setProperty: #formerOwner toValue: anElementOrNil ] I'd prefer to see a #setProperty:toValueOrRemove: there, as that pattern is used a lot. Stephan

Feb. 9, 2016

Re: [Pharo-dev] Some questions

by Aliaksei Syrel

> > The properties visible and locked, somehow they don't fit in the structure > a BlElement provides, I don't know why but it looks strange. > zIndex: what defines the order of elements, its zIndex or *are* they in > different Bloc-Layers and a zIndex would be superfluous? Don't worry they are deprecated :) That is why all methods related to locking/visibility/sticking packaged in *Bloc-Core-*Ugly*. >From zIndex: setter: > self flag: 'It should not be just magic number but maybe elevation > or z position in pixels or any other material value'. I was planning to replace it with something stored layout properties. Are measuredExtent requestingLayout oldExtentMeasurementSpec attributes, a > BlElement always has and needs, or are they only used during layouting? only during layout. They should be moved to layout strategy inst vars. Thanks for pointing :) children ownerReference nextElementReference previousElementReference, > would it make sense to encapsulate this in one new class, something like a > treeNode/structureNode? I agree. Don't like so many inst vars in BlElement. They should be somehow encapsulated in the end. Nice catch! BlWorldElement and BlSpaceElement sounds like this is for elements *in* > space or *in* world, not like > *the* WorldElement. The same for me... Besides SpaceElement there is BlSpace which is a model. Doru suggested to rename: BlWorldElement -> BlWorld BlSpace -> BlSpaceModel BlSpaceElement -> BlSpace Would such naming by more self-describing for you? Cheers, Alex On Tue, Feb 9, 2016 at 12:50 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > 2016-02-05 11:33 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > >> Nice questions :) I will not able to address all mentioned issues today, >> but at least will try some. Answers inlined. >> >> - What are package-tags starting with ! >> >> To force Nautilus show most used core packages first in the list. Without >> "!" they are floating somewhere in the middle of the lists and it takes few >> microseconds more to find them + eye concentration. Of course before >> release they will be renamed. >> >> - Why BlLayoutProperties is named like that? >>> I do not like the ies at the end in particular >> >> I wanted to rename to BlLayoutParams. If you like Params then I will >> rename. >> >> - Why UndefinedObject defines vertical?/horizontal? >>> to me it looks like the auto method generation encountered a nil. >> >> That is to make Bloc compatible with morphic. ( >> https://pharo.fogbugz.com/f/cases/17502) LayoutProperties of Morph can >> be nil. So I decided to add extension methods to nil instead of making >> architecture of Bloc ugly :) Don't see any better solution. >> >> - I cannot close the debugger because I get a DNU askOkToClose >> >> I too. I also can't close Implementors/Senders browser for the same >> reason. No idea why. >> >> - Why BlMargin is not polymorphic with Margin? >> >> Please, don't take next sentence as joke, but I think it is Margin that >> is not polymorphic with BlMargin... >> In Bloc we have padding and margin. They both modify bounds. I don't like >> to use existing Margin class to describe padding.. Still BlMargin has >> similar, not identical api as Margin. >> Also check Margin's api.. It has #rightBottom method - which is the only >> one to return Point. Where is leftBottom or rightTop? wat. >> >> >> >>> - what is BlPaint and what are its collaborators. >> >> is used for filling and stroking shapes. >> Milestone is Bloc-beta. >> >> - What is a coordinateHolder? Why donât we use a point? >> >> Kind of helper. It is used in events and event listeners. I still didn't >> invest time in revising events.. >> >> - Events needs some class comments: >>> - API? >>> - >> >> Milestone is Bloc-beta. >> >> - Why do we have brickValue: in BlAnimation? to me it looks like a layer >>> violation. >> >> yes. BlAnimation should be deleted. >> >> - in BlPath: I have no diea what is a sparta shapes :) >>> I got confused by >>> "I'm responsible for building shape path on passed athens path builder.â >> >> Well, yes :) >> >> Oops the vm crashed :) >> >> Oho! It took so long to crash! =^.^= >> >> p.s. To all who see this email: Bloc needs more complains >> > > :) > > Some random thoughts: > BlWorldElement and BlSpaceElement sounds like this is for elements *in* > space or *in* world, not like > *the* WorldElement. > > Looking at BlElement definition: > > Object subclass: #BlElement > uses: TBlPropertiesOwner > instanceVariableNames: 'ownerReference visible properties > layoutProperties zIndex spaceReference eventListener errorOnDraw locked > extent shape layoutStrategy children nextElementReference > previousElementReference measuredExtent requestingLayout > oldExtentMeasurementSpec transformation' > classVariableNames: '' > package: 'Bloc-Core-!Core-Basic' > > The properties visible and locked, somehow they don't fit in the structure > a BlElement provides, I don't know why but it looks strange. > zIndex: what defines the order of elements, its zIndex or *are* they in > different Bloc-Layers and a zIndex would be superfluous? > > Are measuredExtent requestingLayout oldExtentMeasurementSpec attributes, a > BlElement always has and needs, or are they only used during layouting? > > children ownerReference nextElementReference previousElementReference, > would it make sense to encapsulate this in one new class, something like a > treeNode/structureNode? > > > > >> >> Cheers, >> Alex >> > >

Feb. 9, 2016

Re: [Pharo-dev] Bloc Documentation

by Aliaksei Syrel

On Tue, Feb 9, 2016 at 11:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > mmmâ¦ thatâs a bad question because I would answer âall of themâ, but I > understand you want to do a step to make easy for us to understand so my > answer has to be âthe important onesâ, but since there is no > documentation/class comments/examples I just cannot know which them, so is > up to you (and people doing bloc) to tell us which are âthe important > onesââ¦ by adding class comments and examples! :D It depends :) There are a lot of obvious places in Bloc that do not necessarily need documentation to understand them. For example events. BlLostMouseFocusEvent does not need any "serious" documentation in first place. If you want to find out when it is being sent it is much faster to do cmd+n then read long class doc. I don't want to say that we don't need documentation.. I just want to say that with amount of available man-power we can't instantly add documentation to everything in bloc. So I'm asking: what parts of Bloc do you find especially complicated to understand. so we could concentrate on them? Root class BlElement(methods) has good doc, so please use it to start your exploration journey. Cheers, Alex

Feb. 9, 2016

Re: [Pharo-dev] Bloc Documentation

by Esteban Lorenzano

> On 09 Feb 2016, at 09:15, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Bloc does not have examples yet. > What classes/methods do you need to be commented first to understand the system? > mmmâ¦ thatâs a bad question because I would answer âall of themâ, but I understand you want to do a step to make easy for us to understand so my answer has to be âthe important onesâ, but since there is no documentation/class comments/examples I just cannot know which them, so is up to you (and people doing bloc) to tell us which are âthe important onesââ¦ by adding class comments and examples! :D Esteban > On Feb 9, 2016 4:46 AM, "Sean P. DeNigris" <sean(a)clipperadams.com <mailto:sean@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 <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] [Need help with Monkey] Removing Object>>name

by Guille Polito

Yes, go on. I think it is the easiest. Right now, to check if a slice is good or not I have to commit, browse Smalltalkhub's UI, and if it not good I have to delete the mcz manually... On 02/09/2016 10:10 AM, Sven Van Caekenberghe wrote: > You want me to do it then ? > > I don't want us to do double work ... > >> On 09 Feb 2016, at 10:09, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> Sad and true... :'( >> >> On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Beside, you can't make slices ;-) >> >>> On 09 Feb 2016, at 09:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> 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 Sven Van Caekenberghe

You want me to do it then ? I don't want us to do double work ... > On 09 Feb 2016, at 10:09, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Sad and true... :'( > > On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Beside, you can't make slices ;-) > > > On 09 Feb 2016, at 09:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > 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 Guillermo Polito

Sad and true... :'( On Tue, Feb 9, 2016 at 10:01 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Beside, you can't make slices ;-) > > > On 09 Feb 2016, at 09:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > 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 Sven Van Caekenberghe

Beside, you can't make slices ;-) > On 09 Feb 2016, at 09:58, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > 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