- Pharo-dev - lists.pharo.org

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

by Henrik Johansen

> 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

Spec Experience in Need for Feedback :)

by stepharo

Hi guys I should say that I'm sick (gift from my little boy) so may be this is obvious. I'm looking at the code of Spec and I hate this code :) widgetDo: aBlock ^ self widget ifNotNil: aBlock I do not see why widgetDo: has to test for nil So I transformed widgetDo: aBlock ^ self widget ifNotNil: aBlock into widgetDo: aBlock ^ aBlock cull: self widget BTW I hate all the cull: call. They are connected with sloppiness). It is far too easy to use cull: I do not know how many arguments, I do not care I use cull: cull: is slow slow and help producing messing API. And it broke. The methodBrowser example did not work anymore and many others. Debugger felt down.... I feel sad. Now my brain is dead so I cannot concentrate more. Stef

Feb. 8, 2016

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

by Sven Van Caekenberghe

> On 05 Feb 2016, at 14:12, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > > On Thu, Feb 4, 2016 at 2:59 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 04 Feb 2016, at 14:02, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > >> > >> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> > >>> On 04 Feb 2016, at 11:55, Guille Polito <guillermopolito(a)gmail.com> wrote: > >>> > >>> Good news, so far, installing NeoUUID and replacing UUID class >> new by: > >>> > >>> UUID class >> new > >>> ^NeoUUIDGenerator new next > >>> > >>> seems to work. At it looks that I can trust again my commits. > >>> > >>> Thanks Sven :) > >> > >> OK. > >> > >> Now, the idea is that one instance of the generator is kept around, this is way more efficient, but also more correct, as the random generator should not be created anew each time. > >> > >>> Now I do not know how this should be solved, nor if this is reproducible in a machine other than mine... > >> > >> I seriously doubt the plugin is better (more random, more unique) then anything that we can do in Pharo itself. I like Pharo code way better, because we all see what it does. > >> > >> Anyone else with an opinion ? > > > > More random for certain, at least much faster than we could do in Pharo, is certainly possible with a plugin. > > More unique... well, depends on whether you can trust the source RNG (seeded from data with enough entropy, period much greater than 2^128, etc). > > > > A single next:into:startingAt: primitive filling random data (obtained using platform primitives and/or RDRAND/RDSEED) into a buffer would be much nicer/more flexible than the current UUID primitive though. (the linked UUID library is basically just a thin wrapper around the platform primitives, plus setting variant/version bits in the returned UUID bytes) > > > > As a stopgap, one could instead use another, more general primitive (but with a less flexible api than next:into:startingAt:) in an otherwise unrelated plugin (but that is built internal to all Cog VM's, at least): > > rand: aBuffer > > <primitive: 'primitiveGatherEntropy' module: 'CroquetPlugin'> > > ^self primitiveFail > > > > (which, iirc, resolves to the same platform primitives as UUID lib) > > > > Also, the meaning of different UUID versions are well defined in the RFC, marking NeoUUID's as being a version 4 UUID seems somewhat ... disingenuous. > > Yes, but to 99.99% of developers, a UUID is something special/magic where some effort was made to generate something as unique as possible. > > If we insist on it being just 128 random bits, then why all the fuss ? Why do we even need so called standards ? > In my mind, you just answered that :) > The standard provides 4 well-defined ways to implement something where it's guaranteed that some effort has been made to generate something as unique as possible. > > Why do we need a plugin, an implementation even ? It makes no sense. Just read 16 bytes from /dev/[u]random, or the equivalent use of a RNG and be done with it. > > > But if you tell developers that their database IDs are just plain random numbers, they will probably feels less good about them. > > > But... that's *exactly* what you tell them by marking UUID's as being of type 4. > > To me UUID is a specific concept: << 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". >> > > Not including any 'node' information (identifying process, image, VM, machine, network endpoint), nor 'counter' does not feel right. > > And I agree Neo-UUID fits that bill nicely, the values it returns *are* practically unique. > The two things I disagreed with was: > 1) The statement that it is possible to implement purely in Smalltalk UUID's as random as those returned by the plugin (Which, as you say, is basically reading 16 bytes from /dev/random), at least as performant, without consulting an external trusted randomness source. Agreed. > 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 ? > Cheers, > Henry

Feb. 8, 2016

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

by stepharo

Hi Sven I think that we should use your package! Can you open a bug entry and we add it. Stef Le 4/2/16 11:36, Sven Van Caekenberghe a Ã©crit : > It beats the hell out of me why we need a plugin (apart from speed) and why the fallback should not work (i.e. generate duplicates). It is not rocket science or magic, right ? > > I once made my own generator: Neo-UUID (http://mc.stfx.eu/Neo or Neo on StHub). It is pretty simple and fast. > >> On 04 Feb 2016, at 11:29, Guille Polito <guillermopolito(a)gmail.com> wrote: >> >> And yes, linux VM's are not shipped with the UUID plugin... at least not since 2014/2013... >> >> Also, I believe the plugin is not compiled as internal since it is not listed in >> >> Smalltalk vm listBuiltinModules. >> Smalltalk vm listLoadedModules. >> >> On 02/04/2016 11:12 AM, Guille Polito wrote: >>> On 02/04/2016 10:58 AM, Sven Van Caekenberghe wrote: >>>> But StHub did not change for a long time, no ? >>> I know... >>>> Saving to an HTTP MC repo is nothing more than an HTTP PUT. >>>> >>>> You should be able to do that manually with just ZnClient. >>> Well, yes. But I'm just clicking the save button on the monticello browser... >>> >>> Now, I tested with squeaksource3: >>> >>> - I commit in squeaksource 3 using the monticello browser: the file in package-cache is OK, the file in squeaksource3 is OK >>> http://ss3.gemtalksystems.com/ss?_s=WvI7T3UuBKEaYUrR&_k=ukyWjav7hA-MhHIz >>> >>> - I make a copy of the file from the monticello UI to a smalltalkhub repository. The file in smalltalkhub is not the one I want. >>> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >>> >>> In both Squeaksource3 and Smalltalkhub I have the same UUID, project name, version number, commit message, but the MCZ file that I download from them is different. Even, making a diff from SmalltalkHub's UI shows me a diff against a completely different package (RoboticTable) that is from Santiago Bragagnolo, and that I guess it is a private project because it is not listed and cannot browsed. >>> >>> Making a diff on other versions, such as http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… , makes a diff against a version of the Makros package, which is also from Santiago Bragagnolo, but this is not a private project. >>> >>> Aaaand, now I see a problem! >>> >>> both my test package: >>> >>> http://www.smalltalkhub.com/#!/~Guille/playground/diff/test-GuillermoPolito… >>> >>> and the one of Santiago >>> >>> http://www.smalltalkhub.com/#!/~sbragagnolo/Makros/versions/Makros-Santiago… >>> >>> have the same UUID!!!!!! >>> >>> Maybe this is because of my debian 64bits? Hmm maybe the UUID plugin is not loading? I'll check that for now, because I cannot work if I cannot commit :). If somebody has an idea, It is VERY welcome! >>> >>> Thanks for reading my loud ranting/reasoning, >>> Guille >>>>> On 04 Feb 2016, at 10:52, Guille Polito <guillermopolito(a)gmail.com> wrote: >>>>> >>>>> So far, I'm blaming Smalltalkhub: >>>>> >>>>> - I create a new empty package. >>>>> - I commit it to a local directory, it works ok. >>>>> - I commit it to a smalltalkhub repository: the file in my package cache is ok, but the file in smalltalkhub is corrupted >>>>> e.g., http://www.smalltalkhub.com/#!/~Guille/playground/versions/test-GuillermoPo… >>>>> >>>>> The strange thing is that it is a recurrent bug. I cannot commit to smalltalkhub, not even do a push of a version in my package cache. Smalltalkhub always shows a buggy version. >>>>> >>>>> I'll now try with squeaksource 3 to narrow my conclusions. >>>>> >>>>> On 02/04/2016 10:33 AM, Guille Polito wrote: >>>>>> I tried for one hour yesterday to understand the problem :). This morning my priority was to not lose my code because I noticed the bug a couple of hours after my commits... Thanks I remembered to save my image and that the good old fileout in .st is working! >>>>>> >>>>>> I'll keep trying to reproduce and keep you posted >>>>>> >>>>>> On 02/04/2016 10:21 AM, stepharo wrote: >>>>>>> Hi guille >>>>>>> >>>>>>> Esteban got some problems with MC recently >>>>>>> so it would be good to have a reproducible case. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> Le 4/2/16 10:07, Guille Polito a Ã©crit : >>>>>>>> Ok, I am puzzled. I downloaded a new fresh image, in a fresh directory, worked on something else, committed, and my commit is completely broken. >>>>>>>> Attached screenshot of what monticello shows me. >>>>>>>> >>>>>>>> I'm on debian jessie 64bits. Maybe it has something to do? >>>>>>>> >>>>>>>> On 02/03/2016 03:41 PM, Guille Polito wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> I'm finally back, rechecking this issue: >>>>>>>>> >>>>>>>>> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >>>>>>>>> >>>>>>>>> I remade the Slice to load in latest Pharo5 with the new Spur changes, plus some fixes proposed by Nicolai. I can load the slice in a new image and everything looks ok. So far so good. >>>>>>>>> >>>>>>>>> Now, the monkey starts checking the Slice and somehow it cannot load the Slice due to "dependencies to some classes". Of course, the slice I submitted does not depend on the packages on the complaint, and locally it loads well. Moreover, I never had/worked with those classes, nor they were installed in my system. Even, I have a new machine which is clean so I cannot believe I have some interference due to some package cache... >>>>>>>>> >>>>>>>>> The message of the monkey is here: >>>>>>>>> >>>>>>>>> https://ci.inria.fr/pharo/job/Pharo-5.0-Issue-Validator/26128//artifact/val… >>>>>>>>> >>>>>>>>> Did somebody find some similar problem or it is just me? I believe the problem is on the monkey side, but I have no clue... Maybe somebody has a better idea. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Guille >> > >

Feb. 8, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by Nicolai Hess

I traced this back to Object>>withArgs:executeMethod: (primitive 188) in OpalCompiler>>#evaluate It does not happen on squeaks spur vm as far as I know (but I don't know what is the latests squeak spur vm). 2016-02-08 5:17 GMT+01:00 Martin Dias <tinchodias(a)gmail.com>: > Very interesting... > > I created case 17543 > <https://pharo.fogbugz.com/f/cases/17543/VM-crash-in-Windows-when-compiling-…>, > with Vincent's script and other quotes from this thread. I did it because > this Windows issue is independent from Epicea (whose integration only > exposed the Windows issue). > > Martin > > On Sat, Feb 6, 2016 at 6:41 AM, Max Leske <maxleske(a)gmail.com> wrote: > >> Changing the scheduler didnât have any effect. However, it seems to me >> that the size of the input matters. I can make it work in two ways: >> 1. delete a line. If the lineâs too short it wonât work though >> 2. delete a couple of characters from some symbols >> >> That would suggest that not the number of symbols / items in the array is >> significant but the number of bytes. So maybe thereâs a problem with memory >> allocation in the VM. I havenât been able to come up with an exact number, >> but the VM starts crashing at around 7096 characters. Sometimes I can go >> over 7100, other times not. Smaller numbers always work. >> >> HTH, >> Max >> >> On 06 Feb 2016, at 07:25, Ben Coman <btc(a)openInWorld.com >> <btc(a)openinworld.com>> wrote: >> >> On Sat, Feb 6, 2016 at 12:59 PM, Martin Dias <tinchodias(a)gmail.com> >> wrote: >> >> In fact, this integration step >> (https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z) >> was >> already passed by Epicea in December. That was before spur, it might be >> related to spur. >> >> That time, the integration of Epicea revealed a bug in delay's >> scheduling... >> >> >> Was that these issues integrated in build 50466... >> https://pharo.fogbugz.com/default.asp?17066 >> https://pharo.fogbugz.com/default.asp?13756 >> >> which should have left the current scheduler as >> DelayExperimentalSpinScheduler >> but in current build 50564 "Delay delaySchedulerClass" --> >> DelayMicrosecondScheduler >> >> Maybe Delay class >> initialize has been executed since >> Scheduler ifNotNil: [ Scheduler stopTimerEventLoop ]. >> Scheduler := DelayMicrosecondScheduler new. >> Scheduler startTimerEventLoop. >> Smalltalk addToStartUpList: self. >> >> but I don't see any updates that might have invoked it. >> Anyway, maybe changing that will help. >> >> cheers -ben >> >> >> >> maybe now it's revealing some bug in Windows+spur...? >> >> Martin >> >> >> On Fri, Feb 5, 2016 at 10:09 AM, Blondeau Vincent >> <vincent.blondeau(a)worldline.com> wrote: >> >> >> If you remove any line, it stops crashingâ¦ >> >> I really donât know what is going onâ¦ >> >> >> >> Vincent >> >> >> >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org >> <pharo-dev-bounces(a)lists.pharo.org>] De la part de >> Henrik Nergaard >> EnvoyÃ© : vendredi 5 fÃ©vrier 2016 14:03 >> >> >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] >> We are in "code freeze" for Pharo 5) >> >> >> >> Removing >> >> #(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp: >> visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral: >> visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable: >> visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray: >> visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp: >> visitTempVector: visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar: >> visitSend: )) >> >> And it stops crashing. >> >> >> >> - BTW, there is not crash.dmp, does it works with spur? >> >> >> >> https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-f… >> >> >> >> Best regards, >> >> Henrik >> >> >> >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Blondeau Vincent >> Sent: Friday, February 5, 2016 1:54 PM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: >> [ANN] We are in "code freeze" for Pharo 5) >> >> >> >> Very strange bug indeed that happens on windows machines that crashes the >> VM. I succeeded to reduce the problem to an evaluation of a collectionâ¦ >> >> Can someone have the same issue under Windows or Mac? >> >> >> >> To reproduce : Copy paste the contents of the attached file in the >> playground and print it or do it >> >> It works on pre-spur vm. >> >> >> >> BTW, there is not crash.dmp, does it works with spur? >> >> Vincent >> >> >> >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Marcus Denker >> EnvoyÃ© : vendredi 5 fÃ©vrier 2016 13:01 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] >> We are in "code freeze" for Pharo 5) >> >> >> >> >> >> On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >> I will try do integrate it nowâ¦ >> >> >> >> >> >> >> >> No, it still fails. >> >> >> >> >> >> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… >> >> >> >> The last test it executed seems to be this: >> >> running suite: Refactoring-Tests-Environment >> >> starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ... >> >> Very strange... >> >> Marcus >> >> >> >> >> >> ________________________________ >> >> >> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le >> secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne >> pourra >> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As >> its >> integrity cannot be secured on the Internet, the Worldline liability >> cannot >> be triggered for the message content. Although the sender endeavours to >> maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> >> >> ________________________________ >> >> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le >> secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne >> pourra >> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As >> its >> integrity cannot be secured on the Internet, the Worldline liability >> cannot >> be triggered for the message content. Although the sender endeavours to >> maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> >> >> >

Feb. 8, 2016

UUIDs are not so unique [WAS] Removing Object>>name

by Guille Polito

I detach the conversation from the Object>>name issue. So, to summarize the conversation: For some reason, the UUIDs generated by my Pharo in my new machine (Debian Jessie 64bit) are not unique at all. They keep clashing with UUIDs of existing packages in Smalltalkhub. I mean with this that it is not an isolated case or a random thing. I can reproduce it every time I commit. I opened a bug for this [1]. And I marked it as show stopper, as I believe we cannot release pharo5 with this bug that prevents people from doing a commit. Then, I tested the NeoUUIDGenerator and it works better in that sense. Or at least it gives me better guarantees. I propose to replace the existing UUID generator by NeoUUID generator. The latter is not only better, but it also includes tests. What do you think? Guille [1] https://pharo.fogbugz.com/f/cases/17544/UUIDs-are-not-so-unique -------- Forwarded Message -------- Subject: Re: [Pharo-dev] [Need help with Monkey] Removing Object>>name Date: Fri, 5 Feb 2016 14:12:10 +0100 From: Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> Reply-To: Pharo Development List <pharo-dev(a)lists.pharo.org> To: Pharo Development List <pharo-dev(a)lists.pharo.org> On Thu, Feb 4, 2016 at 2:59 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > On 04 Feb 2016, at 14:02, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: > >> >> On 04 Feb 2016, at 12:52 , Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> >> >>> On 04 Feb 2016, at 11:55, Guille Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>> >>> Good news, so far, installing NeoUUID and replacing UUID class >> new by: >>> >>> UUID class >> new >>> ^NeoUUIDGenerator new next >>> >>> seems to work. At it looks that I can trust again my commits. >>> >>> Thanks Sven :) >> >> OK. >> >> Now, the idea is that one instance of the generator is kept around, this is way more efficient, but also more correct, as the random generator should not be created anew each time. >> >>> Now I do not know how this should be solved, nor if this is reproducible in a machine other than mine... >> >> I seriously doubt the plugin is better (more random, more unique) then anything that we can do in Pharo itself. I like Pharo code way better, because we all see what it does. >> >> Anyone else with an opinion ? > > More random for certain, at least much faster than we could do in Pharo, is certainly possible with a plugin. > More unique... well, depends on whether you can trust the source RNG (seeded from data with enough entropy, period much greater than 2^128, etc). > > A single next:into:startingAt: primitive filling random data (obtained using platform primitives and/or RDRAND/RDSEED) into a buffer would be much nicer/more flexible than the current UUID primitive though. (the linked UUID library is basically just a thin wrapper around the platform primitives, plus setting variant/version bits in the returned UUID bytes) > > As a stopgap, one could instead use another, more general primitive (but with a less flexible api than next:into:startingAt:) in an otherwise unrelated plugin (but that is built internal to all Cog VM's, at least): > rand: aBuffer > <primitive: 'primitiveGatherEntropy' module: 'CroquetPlugin'> > ^self primitiveFail > > (which, iirc, resolves to the same platform primitives as UUID lib) > > Also, the meaning of different UUID versions are well defined in the RFC, marking NeoUUID's as being a version 4 UUID seems somewhat ... disingenuous. Yes, but to 99.99% of developers, a UUID is something special/magic where some effort was made to generate something as unique as possible. If we insist on it being just 128 random bits, then why all the fuss ? Why do we even need so called standards ? In my mind, you just answered that :) The standard provides 4 well-defined ways to implement something where it's guaranteed that some effort has been made to generate something as unique as possible. Why do we need a plugin, an implementation even ? It makes no sense. Just read 16 bytes from /dev/[u]random, or the equivalent use of a RNG and be done with it. But if you tell developers that their database IDs are just plain random numbers, they will probably feels less good about them. But... that's *exactly* what you tell them by marking UUID's as being of type 4. To me UUID is a specific concept: << 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". >> Not including any 'node' information (identifying process, image, VM, machine, network endpoint), nor 'counter' does not feel right. And I agree Neo-UUID fits that bill nicely, the values it returns *are* practically unique. The two things I disagreed with was: 1) The statement that it is possible to implement purely in Smalltalk UUID's as random as those returned by the plugin (Which, as you say, is basically reading 16 bytes from /dev/random), at least as performant, without consulting an external trusted randomness source. 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. Cheers, Henry

Feb. 8, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by Martin Dias

Very interesting... I created case 17543 <https://pharo.fogbugz.com/f/cases/17543/VM-crash-in-Windows-when-compiling-…>, with Vincent's script and other quotes from this thread. I did it because this Windows issue is independent from Epicea (whose integration only exposed the Windows issue). Martin On Sat, Feb 6, 2016 at 6:41 AM, Max Leske <maxleske(a)gmail.com> wrote: > Changing the scheduler didnât have any effect. However, it seems to me > that the size of the input matters. I can make it work in two ways: > 1. delete a line. If the lineâs too short it wonât work though > 2. delete a couple of characters from some symbols > > That would suggest that not the number of symbols / items in the array is > significant but the number of bytes. So maybe thereâs a problem with memory > allocation in the VM. I havenât been able to come up with an exact number, > but the VM starts crashing at around 7096 characters. Sometimes I can go > over 7100, other times not. Smaller numbers always work. > > HTH, > Max > > On 06 Feb 2016, at 07:25, Ben Coman <btc(a)openInWorld.com > <btc(a)openinworld.com>> wrote: > > On Sat, Feb 6, 2016 at 12:59 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > In fact, this integration step > (https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z) > was > already passed by Epicea in December. That was before spur, it might be > related to spur. > > That time, the integration of Epicea revealed a bug in delay's > scheduling... > > > Was that these issues integrated in build 50466... > https://pharo.fogbugz.com/default.asp?17066 > https://pharo.fogbugz.com/default.asp?13756 > > which should have left the current scheduler as > DelayExperimentalSpinScheduler > but in current build 50564 "Delay delaySchedulerClass" --> > DelayMicrosecondScheduler > > Maybe Delay class >> initialize has been executed since > Scheduler ifNotNil: [ Scheduler stopTimerEventLoop ]. > Scheduler := DelayMicrosecondScheduler new. > Scheduler startTimerEventLoop. > Smalltalk addToStartUpList: self. > > but I don't see any updates that might have invoked it. > Anyway, maybe changing that will help. > > cheers -ben > > > > maybe now it's revealing some bug in Windows+spur...? > > Martin > > > On Fri, Feb 5, 2016 at 10:09 AM, Blondeau Vincent > <vincent.blondeau(a)worldline.com> wrote: > > > If you remove any line, it stops crashingâ¦ > > I really donât know what is going onâ¦ > > > > Vincent > > > > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] De la part de > Henrik Nergaard > EnvoyÃ© : vendredi 5 fÃ©vrier 2016 14:03 > > > Ã : Pharo Development List > Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] > We are in "code freeze" for Pharo 5) > > > > Removing > > #(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp: > visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral: > visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable: > visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray: > visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp: > visitTempVector: visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar: > visitSend: )) > > And it stops crashing. > > > > - BTW, there is not crash.dmp, does it works with spur? > > > > https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-f… > > > > Best regards, > > Henrik > > > > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of > Blondeau Vincent > Sent: Friday, February 5, 2016 1:54 PM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: > [ANN] We are in "code freeze" for Pharo 5) > > > > Very strange bug indeed that happens on windows machines that crashes the > VM. I succeeded to reduce the problem to an evaluation of a collectionâ¦ > > Can someone have the same issue under Windows or Mac? > > > > To reproduce : Copy paste the contents of the attached file in the > playground and print it or do it > > It works on pre-spur vm. > > > > BTW, there is not crash.dmp, does it works with spur? > > Vincent > > > > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de > Marcus Denker > EnvoyÃ© : vendredi 5 fÃ©vrier 2016 13:01 > Ã : Pharo Development List > Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] > We are in "code freeze" for Pharo 5) > > > > > > On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > I will try do integrate it nowâ¦ > > > > > > > > No, it still fails. > > > > > > https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… > > > > The last test it executed seems to be this: > > running suite: Refactoring-Tests-Environment > > starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ... > > Very strange... > > Marcus > > > > > > ________________________________ > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its > integrity cannot be secured on the Internet, the Worldline liability cannot > be triggered for the message content. Although the sender endeavours to > maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > > > ________________________________ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its > integrity cannot be secured on the Internet, the Worldline liability cannot > be triggered for the message content. Although the sender endeavours to > maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > > >

Feb. 8, 2016

Re: [Pharo-dev] Best way to access icons?

by stepharo

Le 5/2/16 09:21, Esteban Lorenzano a Ã©crit : > of course, but since we have not implemented such mechanism, we need > to go one step at a timeâ¦ yes but this is good to think about a good solution. :) At least this is good to know that you do not consider that as the final answer (because it sucks ;) > > first step is *not to have* everything as static as it was before. > > then we need to think on skins, injection, etc. > > Esteban > >> On 04 Feb 2016, at 22:21, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Hi guys >> >> I do not have the answer but I hate such patterns >> >> Smalltalk ui icons iconNamed: #protocolExtension. >> >> To me a tools using an icon should declare the icons as a ***local*** >> ressources. >> We could imagine that there is a IconContainer and that as a tool I >> declare that I want an >> icons and I install it on myself. >> >> | t | >> t := Tool new. >> ic := IconContainer for: #darkTheme. >> t askAninnstallIcon: ic iconFor: #button. >> >> Then if the IconContainer changes, then it can notify its users to >> ask for a new version of the icon. >> >> ic broadcastNewIcon: #button >> >> This way >> >> t does not have to use a plain bad global variable and does not >> care about the global namespace. >> t should only use local resources held in classVar for example. >> >> >> Such Smalltalk ui icons is a dynamic global variable! >> >> Stef >> >> >> >> >> >> Le 4/2/16 17:00, Esteban Lorenzano a Ã©crit : >>> Smalltalk ui icons iconNamed: #protocolExtension. >>> >>> Still ugly, but Iâm not happy with the idea of a selector-per-iconâ¦ >>> they will never be enough and wellâ¦ is like a monolithic vision. >>> Not that what we have is much better, but you can consider it an >>> iteration :) >>> >>> Esteban >>> >>>> On 04 Feb 2016, at 16:19, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >>>> >>>> Hi >>>> >>>> For ages to access an icon we used: >>>> >>>> Smalltalk ui icons protocolPrivateIcon >>>> >>>> >>>> Smalltalk ui icons returns an instance of ThemeIcons. >>>> After refactoring >>>> (case<https://pharo.fogbugz.com/f/cases/16651>https://pharo.fogbugz.com/f/cases/16651) >>>> all methods to access icon (for example protocolPrivateIcon) were >>>> removed. >>>> >>>> ThemeIcons>>#doesNotUnderstand: aMessage converts message sent to >>>> iconNamed: aMessage selector which works. >>>> >>>> BUT we have this all over the image: >>>> <Screen Shot 2016-02-04 at 16.13.03.png> >>>> >>>> So, what is the best practice to access icons to use in application? >>>> >>>> Cheers, >>>> Alex >>>> >>> >> >

Feb. 7, 2016

Re: [Pharo-dev] [ANN] We are in "code freeze" for Pharo 5

by stepharo

> > We are on âjust bugfixesâ since some time nowâ¦ I delayed the > announcement because Epicea still needs to enter and we didnât > manage to include it yet. > But wellâ¦ with the exception of Epicea, no new features will be > included un Pharo 5â¦ just bugfixes (and we have a lot of bugfixes > incomingâ¦ this release will be hard :( ) > > > I would like to finish my work on shortcuts / keymapping cleanup > (remove Smalltalk/RubSmalltalk editor maps in favor of KMDispatcher). > But I am waiting for changes on the windows vm (it was included in the > pre-spur vm but it isn't in spur). > And there is a lot to be done for menus in our tools that now using > rubric instead of PluggableText, Are these considered a bug fixes ? Yes they are bugs. Menus should work. > Or should I stop and continue later in pharo 6? > > > cheers, > Esteban > >

Feb. 7, 2016

Re: [Pharo-dev] Recent changes in Bloc, no more BlMorph

by Stephan Eggermont

On 06/02/16 20:37, Tudor Girba wrote: > One of the ideas that drove the design is that Bloc should provide a > simple yet flexible low level design, and allow higher level > abstractions on top. For example, we would like to have an engine > like Roassal be directly implemented using bloc elements, without > relying on its own world built in a canvas. Are they expected to be good enough to also build text (not just line-based code) editing and layout (TeX-like quality) abstractions on top? Stephan

Feb. 7, 2016