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

[pharo-project/pharo-core] 13d069: 50574

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 13d069e690c17556c53e525e866b08aa63cb8100 https://github.com/pharo-project/pharo-core/commit/13d069e690c17556c53e525e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-10 (Wed, 10 Feb 2016) Changed paths: M ConfigurationOfSessionManager.package/ConfigurationOfSessionManager.class/instance/symbolic versions/stable_.st A ConfigurationOfSessionManager.package/ConfigurationOfSessionManager.class/instance/versions/version11_.st M Kernel-Tests.package/BlockClosureTest.class/instance/tests/testTallyInstructions.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50573.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50574.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50573.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50574.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/asserting/assertHandledId_equals_.st M System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testCategoriesPriorityOrder.st M System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testPriorityOrderInTheSameCategoryIsRespected.st M System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testRegisterElementByDefault.st M System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testRegisterSystemElement.st M System-SessionManager-Tests.package/SessionManagerRegistrationOrderTest.class/instance/tests/testSubscriptionReverseOrder.st A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/README.md A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/definition.st A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/running/setUp.st A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenARegisteredClassRenamedThenItsHandlerIsUpdated.st A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenManyRegistrationsInDifferentCategoriesShoudlLastClassRegistrationBeTheOnlyOccurenceInStartupList.st A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenManyRegistrationsInSameCategoryAtDifferentPriorityShoudlAClassBePresentOnlyOnceInStartupList.st A System-SessionManager-Tests.package/SessionManagerRegistrationTest.class/instance/tests/testGivenManyRegistrationsInSameCategoryShoudlAClassBePresentOnlyOnceInStartupList.st A System-SessionManager.package/SessionCategory.class/instance/private/renamedClass_from_to_.st A System-SessionManager.package/SessionCategory.class/instance/registration/unregisterHandler_.st R System-SessionManager.package/SessionCategory.class/instance/registrqtion/unregisterClassNamed_.st M System-SessionManager.package/SessionManager.class/class/compatibility - startupList/initializedSessionManager.st M System-SessionManager.package/SessionManager.class/instance/registration/register_inCategory_atPriority_.st A System-SessionManager.package/SessionManager.class/instance/registration/renamedClass_from_to_.st M System-SessionManager.package/SessionManager.class/instance/registration/unregisterClassNamed_.st A System-SessionManager.package/SessionManager.class/instance/registration/unregisterHandler_.st M System-SessionManager.package/StartupUIManager.class/instance/ui requests/inform_.st R System-SessionManager.package/UIManagerSessionHandler.class/class/initialize-release/release.st Log Message: ----------- 50574 17281 Failing test: BlockClosureTest>>#testTallyInstructions https://pharo.fogbugz.com/f/cases/17281 17553 missing classes in startup list https://pharo.fogbugz.com/f/cases/17553 http://files.pharo.org/image/50/50574.zip

Feb. 10, 2016

Re: [Pharo-dev] newFrom: vs. withAll:

by Richard Sargent

stepharo wrote > Hi guys > > I was looking at the Collection chapter and I stumbled upon newFrom: and > I wonder what is the real > difference between newFrom: and withAll:. > I have the impression that there is not much difference. There are only > 47 senders of newFrom: in the default Pharo image. > > Dictionary class>>withAll: interprets its argument as a collection of > values, > whereas Dictionary class>>newFrom: expects a collection of associations. > > I would really deprecate newFrom: in the future. > > Stef Absent a compelling argument for deviating from the ANSI standard, it would be best to adhere to the standard. #withAll: doesn't make sense to treat the argument as supplying the values, as there is nothing to define the keys. <abstractDictionary> suggests the only protocol needed for the argument would be #keysAndValuesDo: (but it /isn't/ specified as such). ANSI specifies #withAll: as having an effect "the same as evaluating Dictionary new addAll: newElements; yourself." #addAll: is shown with "dictionary" for the argument name and typed as <abstractDictionary>. -- View this message in context: http://forum.world.st/newFrom-vs-withAll-tp4876589p4876674.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 9, 2016

Re: [Pharo-dev] Getting coherent shortcuts

by Tudor Girba

Thanks Stephan :). @Guille: Stephan just added you to the SmalltalkHub repository. Could you ping me when you commit so that I can review? Cheers, Doru > On Feb 9, 2016, at 11:25 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 09/02/16 15:50, Guille Polito wrote: >> Also, I did some changes in Glamour and GTSpotter, but I have no >> permissions to commit there. How do we do to commit in those packages? >> Should I ask for permissions or is there any other process in place? > > There's a magical process by which you complain in the mailing list and then suddenly are able to commit. > > Stephan > > > -- www.tudorgirba.com www.feenk.com "No matter how many recipes we know, we still value a chef."

Feb. 9, 2016

Re: [Pharo-dev] Getting coherent shortcuts

by Stephan Eggermont

On 09/02/16 15:50, Guille Polito wrote: > Also, I did some changes in Glamour and GTSpotter, but I have no > permissions to commit there. How do we do to commit in those packages? > Should I ask for permissions or is there any other process in place? There's a magical process by which you complain in the mailing list and then suddenly are able to commit. Stephan

Feb. 9, 2016

Re: [Pharo-dev] Getting coherent shortcuts

by Tudor Girba

This is great! Doru > On Feb 9, 2016, at 7:10 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 09 Feb 2016, at 17:31, Damien Cassou <damien.cassou(a)inria.fr> wrote: >> >> Guille Polito <guillermopolito(a)gmail.com> writes: >> >>> So, since today I was able to commit again, I decided to make a couple >>> of slices/new configurations fixing the majority of shortcuts in the >>> image. Like this, mac shortcuts will remain in cmd, but linux and >>> windows shortcuts will be with ctrl, as expected by the vast majority of >>> users :). The changes I made should fix 97.8882% of the shortcut >>> experience in linux and windows, without degrading the one in mac. Of >>> course, if you see any glitch, just tell. >> >> thank you very much! > > + 10 ! > >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." --Winston Churchill >> > > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

Feb. 9, 2016

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

by stepharo

Agreed :) But I was easy to convince :) Le 9/2/16 19:09, Sven Van Caekenberghe a Ã©crit : >> On 09 Feb 2016, at 17:35, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Tue, Feb 9, 2016 at 11:53 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Le 9/2/16 09:58, Sven Van Caekenberghe a Ã©crit : >>>> 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. >>> >>> me too. >>> Less plugin! >> This is a good general philosophy, but we should benchmark in-image >> versus plugin so we can make an informed analytical decision on how >> much performance we are willing to trade for the convenience of it >> being all in-image, and whether we want to maintain a separate CI job >> for keeping the plugin tested. Overriding that is providing a quick >> fix so other development is not blocked, which however Guille's >> solution seems sufficient for the code freeze of Pharo 5. > From a comment in > > === > Speedwise, in Pharo 5 Spur on my machine, the new implementation is just as fast as the primitive, or so it seems: > > [ UUIDGenerator next ] bench. "'1,235,356 per second'" > > [ UUID nilUUID primMakeUUID ] bench. "'1,237,213 per second'" > === > > But even if it were slower (like half or quarter speed), there is a *HUGE* benefit to in image code. > > C code will always win, performance wise, but if that is all that counts, why do we program in Pharo at all. > > Please read << Design Principles Behind Smalltalk >> > > http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html > > Principle 1: > > Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. > > Further on: > > Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one. > > Not that this document is an axiom or anything, but it articulates well some very relevant principles. > > For all these years, you nor I ever knew what took place in that silly plugin (1 method), while a confusing UUIDGenerator made some of us believe that it was used or somehow identical to the plugin (that was probably not true), now you, me and 99% of all other Pharo developers can read clean code. > > For me, Pharo is much more than the next scripting language that links to OS libraries. Pharo makes software (development) tangible, understandable in one single language/environment. > > When is the last time you looked into the open source C code of any library of your OS, let alone the kernel itself or one of its drivers ? Probably never. But in Pharo we can all look under the hood, everywhere, seamlessly. > > Sven > >> cheers -ben >> >>> >>>>> 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 Stephan Eggermont

On 09/02/16 14:12, Guille Polito wrote: > AAAANNNDDD! It looks I found the real cause of this! > > - I tested an image pre-new session manager, and an image post-new > session manager. The issue only appeared in the latter. > > - Checking, it seems that UUIDGenerator is not subscribed to the new > startup list. This means that the UUIDGenerator is not being > reinitialized on every startup. This means, moreover, that every person > that is loading the latest Pharo image is using the same UUIDGenerator > instance, with the same random seed => same generated UUIDs. > > So, adding UUIDGenerator to the list would be the simplest solution and > the integration of NeoUUIDGenerator can be moved to Pharo6 maybe. > > However, now that we found that something was missing in the startup > list, we should check for others... So, which image versions do we need to mark as broken, don't use? Stephan

Feb. 9, 2016

Re: [Pharo-dev] Getting coherent shortcuts

by Sven Van Caekenberghe

> On 09 Feb 2016, at 17:31, Damien Cassou <damien.cassou(a)inria.fr> wrote: > > Guille Polito <guillermopolito(a)gmail.com> writes: > >> So, since today I was able to commit again, I decided to make a couple >> of slices/new configurations fixing the majority of shortcuts in the >> image. Like this, mac shortcuts will remain in cmd, but linux and >> windows shortcuts will be with ctrl, as expected by the vast majority of >> users :). The changes I made should fix 97.8882% of the shortcut >> experience in linux and windows, without degrading the one in mac. Of >> course, if you see any glitch, just tell. > > thank you very much! + 10 ! > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill >

Feb. 9, 2016

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

by Sven Van Caekenberghe

> On 09 Feb 2016, at 17:35, Ben Coman <btc(a)openinworld.com> wrote: > > On Tue, Feb 9, 2016 at 11:53 PM, stepharo <stepharo(a)free.fr> wrote: >> >> >> Le 9/2/16 09:58, Sven Van Caekenberghe a Ã©crit : >>> >>> 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. >> >> >> me too. >> Less plugin! > > This is a good general philosophy, but we should benchmark in-image > versus plugin so we can make an informed analytical decision on how > much performance we are willing to trade for the convenience of it > being all in-image, and whether we want to maintain a separate CI job > for keeping the plugin tested. Overriding that is providing a quick > fix so other development is not blocked, which however Guille's > solution seems sufficient for the code freeze of Pharo 5. >From a comment in === Speedwise, in Pharo 5 Spur on my machine, the new implementation is just as fast as the primitive, or so it seems: [ UUIDGenerator next ] bench. "'1,235,356 per second'" [ UUID nilUUID primMakeUUID ] bench. "'1,237,213 per second'" === But even if it were slower (like half or quarter speed), there is a *HUGE* benefit to in image code. C code will always win, performance wise, but if that is all that counts, why do we program in Pharo at all. Please read << Design Principles Behind Smalltalk >> http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html Principle 1: Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. Further on: Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one. Not that this document is an axiom or anything, but it articulates well some very relevant principles. For all these years, you nor I ever knew what took place in that silly plugin (1 method), while a confusing UUIDGenerator made some of us believe that it was used or somehow identical to the plugin (that was probably not true), now you, me and 99% of all other Pharo developers can read clean code. For me, Pharo is much more than the next scripting language that links to OS libraries. Pharo makes software (development) tangible, understandable in one single language/environment. When is the last time you looked into the open source C code of any library of your OS, let alone the kernel itself or one of its drivers ? Probably never. But in Pharo we can all look under the hood, everywhere, seamlessly. Sven > cheers -ben > >> >> >>> >>>> 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 Ben Coman

On Tue, Feb 9, 2016 at 11:53 PM, stepharo <stepharo(a)free.fr> wrote: > > > Le 9/2/16 09:58, Sven Van Caekenberghe a Ã©crit : >> >> 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. > > > me too. > Less plugin! This is a good general philosophy, but we should benchmark in-image versus plugin so we can make an informed analytical decision on how much performance we are willing to trade for the convenience of it being all in-image, and whether we want to maintain a separate CI job for keeping the plugin tested. Overriding that is providing a quick fix so other development is not blocked, which however Guille's solution seems sufficient for the code freeze of Pharo 5. cheers -ben > > >> >>> 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