August 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Benchmark

by ClÃ©ment Bera

However benchmark on the CI are not on a dedicated machine so it is not very reliable .... 2013/8/30 Camillo Bruni <camillobruni(a)gmail.com> > That you just need to run it from the command line which is not related to > the benchmark project. > Currently it seems like the ci has some troubles, so I cannot get to the > configuration either. > > > On 2013-08-30, at 17:25, Natalia Moskovchuk < > natalia.moskovchuk(a)unikernel.net> wrote: > > > Thanks. I already saw this video. I cann't see configuration on > > https://ci.inria.fr/rmod/job/FullTextSearch/configure . Can you share > it? > >

Aug. 30, 2013

Re: [Pharo-users] Benchmark

by Camillo Bruni

That you just need to run it from the command line which is not related to the benchmark project. Currently it seems like the ci has some troubles, so I cannot get to the configuration either. On 2013-08-30, at 17:25, Natalia Moskovchuk <natalia.moskovchuk(a)unikernel.net> wrote: > Thanks. I already saw this video. I cann't see configuration on > https://ci.inria.fr/rmod/job/FullTextSearch/configure . Can you share it?

Aug. 30, 2013

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

by Esteban Lorenzano

Hi, One idea (not sure if it will work) You can take Time primUTCMicrosecondsClock when system start, then increase it sequentially. most probably that will ensure uniqueness while providing fast ids. but of course, that depends, you need to check in your system. I'm thinking on provide different ID generators for Voyage, and let people plug what is more convenient for them. (all of this happens because, unlike other db drivers, mongo does not answer the inserted id :( ) Esteban On Aug 30, 2013, at 5:41 PM, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: > So, I will wait and till then, use the solution of Jan. > Thank you, Jan for the file in. > Sabine > > > > -- > View this message in context: http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705821.ht… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Aug. 30, 2013

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

by Sabine KnÃ¶fel

So, I will wait and till then, use the solution of Jan. Thank you, Jan for the file in. Sabine -- View this message in context: http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705821.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 30, 2013

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

by Esteban Lorenzano

yes, is a conversation geeky enough to be fun :) unix: https://github.com/pharo-project/pharovm/blob/master/platforms/unix/plugins… mac: https://github.com/pharo-project/pharovm/blob/master/platforms/iOS/plugins/… win: https://github.com/pharo-project/pharovm/blob/master/platforms/win32/plugin… as you can see... it much depends on the platform. I would like to unify that (I'm doing it slooooowly, with certain plugins... but just when I have time, which is not very frequent :), and also it is not always possible) Esteban On Aug 30, 2013, at 5:15 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 30 Aug 2013, at 16:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On Aug 30, 2013, at 4:49 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >>> >>> On 30 Aug 2013, at 16:35, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> >>>> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>>> >>>>> On 29 Aug 2013, at 16:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> >>>>>> hi >>>>>> >>>>>> well... I've never been happy on using the UUID generator for my keys, but is the fastest option I found. >>>>>> There are, of course, alternatives: >>>>>> >>>>>> 1) Using your own number generator (sequential, or whatever). Problem with that is that is image based, then you need a persistence strategy... then you are slow. >>>>>> 2) then you can use your own procedure in mongo... with same problem than (1) >>>>>> 3) you could use timestamp. but TimeStamps are slow :( >>>>>> >>>>>> anyway... I open to ideas :) >>>>>> >>>>>> in the mean time, you can check if your UUID generator is using the primitive or not. In you are not, you have more possibilities of having a collision. >>>>> >>>>> Yes, the Smalltalk code (type 4 UUID) is just a random number that is computed in a complex way. >>>>> >>>>> What does the primitive actually do ? Is it different ? >>>> >>>> the primitive uses the clock ticks to produce an UUID... you shouldn't have repeated numbers that way... but well, it depends on the platform implementation also. >>> >>> I don't like plugins because it is some much harder for everyone to look at the implementation, while everybody thinks some magic happens there, and often the truth is quite disappointing. >>> >>> Maybe the resolution of #primUTCMicrosecondsClock is not high enough ? >> >> I tried... not enough :( > > I understand: the clock is not fast enough for the request rate. But then what is there against some counter as part of a UUID ? > > Sorry for the discussion, I find it an interesting subject. I'll have to read a bit about UUIDs. Can anyone point to the plugin implementation code ? > >>>>>> Esteban >>>>>> >>>>>> On Aug 29, 2013, at 11:27 AM, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: >>>>>> >>>>>>> Hi Esteban, All, >>>>>>> >>>>>>> I was proceeding to seach for the reason of the problem I described >>>>>>> yesterday. >>>>>>> >>>>>>> I added some debugging code into VOMongoSerializer>>ensurePersisted: and the >>>>>>> problem I described, did NOT occur. >>>>>>> >>>>>>> That made the whole process slower...and I had an idea.... >>>>>>> >>>>>>> I was looking into >>UUIDGenerator default makeSeed. >>>>>>> Then I tried the following code: >>>>>>> >>>>>>> |theOld theNew| >>>>>>> >>>>>>> 100000000 timesRepeat: [ >>>>>>> theNew := UUIDGenerator default makeSeed. >>>>>>> theNew = theOld ifTrue: [self halt]. >>>>>>> theOld := theNew] >>>>>>> >>>>>>> The debugger came up! Doesn't that mean that, if the code is run very fast, >>>>>>> there are double OIDs generated?! >>>>>>> >>>>>>> In my case, the objects for country and currency are very lightweight and >>>>>>> so, they are created very fast. Also, the error occured much more often >>>>>>> within my fast production EC2 instance as at my (old and slow) development >>>>>>> pc. >>>>>>> >>>>>>> Important: I work with windows and so >>makeUnixSeed returns nil... :-) >>>>>>> >>>>>>> What is your opinion about that? >>>>>>> >>>>>>> Sabine >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> View this message in context: http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.ht… >>>>>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

Aug. 30, 2013

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

by Sabine KnÃ¶fel

"Sorry for the discussion" for me, this discussion is interesting and important because I need a solution. :-) Thank you for the discussion! I tried following ideas but they have been up to 4 times slower than the original: 1) I tried to remember the last seed in an inst var of UUIDGenerator and create it new if it was the same as the last one. 2) wait for 1 millisecond before create new seed. As third, I tried adding a (random nextInt: 100000). This did not work, there have been also doouble numbers. So, perhaps the counter is a good idea but is it fast? Again, I work on windows and so I get nil as answer to makeUnixSeed. makeSeed | seed | seed := self makeUnixSeed. seed ifNotNil: [^seed]. [seed := (Time millisecondClockValue bitAnd: 16r3FFFFFFF) bitXor: self hash. seed := seed bitXor: (Time totalSeconds bitAnd: 16r3FFFFFFF). seed = 0] whileTrue: ["Try again if ever get a seed = 0"]. ^seed On Fri, Aug 30, 2013 at 5:15 PM, Sven Van Caekenberghe-2 [via Smalltalk] < ml-node+s1294792n4705817h22(a)n4.nabble.com> wrote: > > On 30 Aug 2013, at 16:54, Esteban Lorenzano <[hidden email]<http://user/SendEmail.jtp?type=node&node=4705817&i=0>> > wrote: > > > > > On Aug 30, 2013, at 4:49 PM, Sven Van Caekenberghe <[hidden email]<http://user/SendEmail.jtp?type=node&node=4705817&i=1>> > wrote: > > > >> > >> On 30 Aug 2013, at 16:35, Esteban Lorenzano <[hidden email]<http://user/SendEmail.jtp?type=node&node=4705817&i=2>> > wrote: > >> > >>> > >>> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <[hidden email]<http://user/SendEmail.jtp?type=node&node=4705817&i=3>> > wrote: > >>> > >>>> > >>>> On 29 Aug 2013, at 16:51, Esteban Lorenzano <[hidden email]<http://user/SendEmail.jtp?type=node&node=4705817&i=4>> > wrote: > >>>> > >>>>> hi > >>>>> > >>>>> well... I've never been happy on using the UUID generator for my > keys, but is the fastest option I found. > >>>>> There are, of course, alternatives: > >>>>> > >>>>> 1) Using your own number generator (sequential, or whatever). > Problem with that is that is image based, then you need a persistence > strategy... then you are slow. > >>>>> 2) then you can use your own procedure in mongo... with same problem > than (1) > >>>>> 3) you could use timestamp. but TimeStamps are slow :( > >>>>> > >>>>> anyway... I open to ideas :) > >>>>> > >>>>> in the mean time, you can check if your UUID generator is using the > primitive or not. In you are not, you have more possibilities of having a > collision. > >>>> > >>>> Yes, the Smalltalk code (type 4 UUID) is just a random number that is > computed in a complex way. > >>>> > >>>> What does the primitive actually do ? Is it different ? > >>> > >>> the primitive uses the clock ticks to produce an UUID... you shouldn't > have repeated numbers that way... but well, it depends on the platform > implementation also. > >> > >> I don't like plugins because it is some much harder for everyone to > look at the implementation, while everybody thinks some magic happens > there, and often the truth is quite disappointing. > >> > >> Maybe the resolution of #primUTCMicrosecondsClock is not high enough ? > > > > I tried... not enough :( > > I understand: the clock is not fast enough for the request rate. But then > what is there against some counter as part of a UUID ? > > Sorry for the discussion, I find it an interesting subject. I'll have to > read a bit about UUIDs. Can anyone point to the plugin implementation code > ? > > >>>>> Esteban > >>>>> > >>>>> On Aug 29, 2013, at 11:27 AM, Sabine KnÃ¶fel <[hidden email]<http://user/SendEmail.jtp?type=node&node=4705817&i=5>> > wrote: > >>>>> > >>>>>> Hi Esteban, All, > >>>>>> > >>>>>> I was proceeding to seach for the reason of the problem I described > >>>>>> yesterday. > >>>>>> > >>>>>> I added some debugging code into > VOMongoSerializer>>ensurePersisted: and the > >>>>>> problem I described, did NOT occur. > >>>>>> > >>>>>> That made the whole process slower...and I had an idea.... > >>>>>> > >>>>>> I was looking into >>UUIDGenerator default makeSeed. > >>>>>> Then I tried the following code: > >>>>>> > >>>>>> |theOld theNew| > >>>>>> > >>>>>> 100000000 timesRepeat: [ > >>>>>> theNew := UUIDGenerator default makeSeed. > >>>>>> theNew = theOld ifTrue: [self halt]. > >>>>>> theOld := theNew] > >>>>>> > >>>>>> The debugger came up! Doesn't that mean that, if the code is run > very fast, > >>>>>> there are double OIDs generated?! > >>>>>> > >>>>>> In my case, the objects for country and currency are very > lightweight and > >>>>>> so, they are created very fast. Also, the error occured much more > often > >>>>>> within my fast production EC2 instance as at my (old and slow) > development > >>>>>> pc. > >>>>>> > >>>>>> Important: I work with windows and so >>makeUnixSeed returns nil... > :-) > >>>>>> > >>>>>> What is your opinion about that? > >>>>>> > >>>>>> Sabine > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> View this message in context: > http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.ht… > >>>>>> Sent from the Pharo Smalltalk Users mailing list archive at > Nabble.com. > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705817.ht… > To unsubscribe from voyage/mongo randomly wrong OIDs, click here<http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML<http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705819.ht… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 30, 2013

Re: [Pharo-users] Benchmark

by Natalia Moskovchuk

Thanks. I already saw this video. I cann't see configuration on https://ci.inria.fr/rmod/job/FullTextSearch/configure . Can you share it? -- View this message in context: http://forum.world.st/Benchmark-tp4705781p4705818.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 30, 2013

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

by Sven Van Caekenberghe

On 30 Aug 2013, at 16:54, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Aug 30, 2013, at 4:49 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > >> >> On 30 Aug 2013, at 16:35, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> >>> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> >>>> On 29 Aug 2013, at 16:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>>> hi >>>>> >>>>> well... I've never been happy on using the UUID generator for my keys, but is the fastest option I found. >>>>> There are, of course, alternatives: >>>>> >>>>> 1) Using your own number generator (sequential, or whatever). Problem with that is that is image based, then you need a persistence strategy... then you are slow. >>>>> 2) then you can use your own procedure in mongo... with same problem than (1) >>>>> 3) you could use timestamp. but TimeStamps are slow :( >>>>> >>>>> anyway... I open to ideas :) >>>>> >>>>> in the mean time, you can check if your UUID generator is using the primitive or not. In you are not, you have more possibilities of having a collision. >>>> >>>> Yes, the Smalltalk code (type 4 UUID) is just a random number that is computed in a complex way. >>>> >>>> What does the primitive actually do ? Is it different ? >>> >>> the primitive uses the clock ticks to produce an UUID... you shouldn't have repeated numbers that way... but well, it depends on the platform implementation also. >> >> I don't like plugins because it is some much harder for everyone to look at the implementation, while everybody thinks some magic happens there, and often the truth is quite disappointing. >> >> Maybe the resolution of #primUTCMicrosecondsClock is not high enough ? > > I tried... not enough :( I understand: the clock is not fast enough for the request rate. But then what is there against some counter as part of a UUID ? Sorry for the discussion, I find it an interesting subject. I'll have to read a bit about UUIDs. Can anyone point to the plugin implementation code ? >>>>> Esteban >>>>> >>>>> On Aug 29, 2013, at 11:27 AM, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: >>>>> >>>>>> Hi Esteban, All, >>>>>> >>>>>> I was proceeding to seach for the reason of the problem I described >>>>>> yesterday. >>>>>> >>>>>> I added some debugging code into VOMongoSerializer>>ensurePersisted: and the >>>>>> problem I described, did NOT occur. >>>>>> >>>>>> That made the whole process slower...and I had an idea.... >>>>>> >>>>>> I was looking into >>UUIDGenerator default makeSeed. >>>>>> Then I tried the following code: >>>>>> >>>>>> |theOld theNew| >>>>>> >>>>>> 100000000 timesRepeat: [ >>>>>> theNew := UUIDGenerator default makeSeed. >>>>>> theNew = theOld ifTrue: [self halt]. >>>>>> theOld := theNew] >>>>>> >>>>>> The debugger came up! Doesn't that mean that, if the code is run very fast, >>>>>> there are double OIDs generated?! >>>>>> >>>>>> In my case, the objects for country and currency are very lightweight and >>>>>> so, they are created very fast. Also, the error occured much more often >>>>>> within my fast production EC2 instance as at my (old and slow) development >>>>>> pc. >>>>>> >>>>>> Important: I work with windows and so >>makeUnixSeed returns nil... :-) >>>>>> >>>>>> What is your opinion about that? >>>>>> >>>>>> Sabine >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> View this message in context: http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.ht… >>>>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

Aug. 30, 2013

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

by Esteban Lorenzano

On Aug 30, 2013, at 4:49 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 30 Aug 2013, at 16:35, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 29 Aug 2013, at 16:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> hi >>>> >>>> well... I've never been happy on using the UUID generator for my keys, but is the fastest option I found. >>>> There are, of course, alternatives: >>>> >>>> 1) Using your own number generator (sequential, or whatever). Problem with that is that is image based, then you need a persistence strategy... then you are slow. >>>> 2) then you can use your own procedure in mongo... with same problem than (1) >>>> 3) you could use timestamp. but TimeStamps are slow :( >>>> >>>> anyway... I open to ideas :) >>>> >>>> in the mean time, you can check if your UUID generator is using the primitive or not. In you are not, you have more possibilities of having a collision. >>> >>> Yes, the Smalltalk code (type 4 UUID) is just a random number that is computed in a complex way. >>> >>> What does the primitive actually do ? Is it different ? >> >> the primitive uses the clock ticks to produce an UUID... you shouldn't have repeated numbers that way... but well, it depends on the platform implementation also. > > I don't like plugins because it is some much harder for everyone to look at the implementation, while everybody thinks some magic happens there, and often the truth is quite disappointing. > > Maybe the resolution of #primUTCMicrosecondsClock is not high enough ? I tried... not enough :( > >>>> Esteban >>>> >>>> On Aug 29, 2013, at 11:27 AM, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: >>>> >>>>> Hi Esteban, All, >>>>> >>>>> I was proceeding to seach for the reason of the problem I described >>>>> yesterday. >>>>> >>>>> I added some debugging code into VOMongoSerializer>>ensurePersisted: and the >>>>> problem I described, did NOT occur. >>>>> >>>>> That made the whole process slower...and I had an idea.... >>>>> >>>>> I was looking into >>UUIDGenerator default makeSeed. >>>>> Then I tried the following code: >>>>> >>>>> |theOld theNew| >>>>> >>>>> 100000000 timesRepeat: [ >>>>> theNew := UUIDGenerator default makeSeed. >>>>> theNew = theOld ifTrue: [self halt]. >>>>> theOld := theNew] >>>>> >>>>> The debugger came up! Doesn't that mean that, if the code is run very fast, >>>>> there are double OIDs generated?! >>>>> >>>>> In my case, the objects for country and currency are very lightweight and >>>>> so, they are created very fast. Also, the error occured much more often >>>>> within my fast production EC2 instance as at my (old and slow) development >>>>> pc. >>>>> >>>>> Important: I work with windows and so >>makeUnixSeed returns nil... :-) >>>>> >>>>> What is your opinion about that? >>>>> >>>>> Sabine >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.ht… >>>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>>>> >>>> >>>> >>> >>> >> >> > >

Aug. 30, 2013

Re: [Pharo-users] voyage/mongo randomly wrong OIDs

by Sven Van Caekenberghe

On 30 Aug 2013, at 16:35, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On Aug 29, 2013, at 5:08 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 29 Aug 2013, at 16:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> hi >>> >>> well... I've never been happy on using the UUID generator for my keys, but is the fastest option I found. >>> There are, of course, alternatives: >>> >>> 1) Using your own number generator (sequential, or whatever). Problem with that is that is image based, then you need a persistence strategy... then you are slow. >>> 2) then you can use your own procedure in mongo... with same problem than (1) >>> 3) you could use timestamp. but TimeStamps are slow :( >>> >>> anyway... I open to ideas :) >>> >>> in the mean time, you can check if your UUID generator is using the primitive or not. In you are not, you have more possibilities of having a collision. >> >> Yes, the Smalltalk code (type 4 UUID) is just a random number that is computed in a complex way. >> >> What does the primitive actually do ? Is it different ? > > the primitive uses the clock ticks to produce an UUID... you shouldn't have repeated numbers that way... but well, it depends on the platform implementation also. I don't like plugins because it is some much harder for everyone to look at the implementation, while everybody thinks some magic happens there, and often the truth is quite disappointing. Maybe the resolution of #primUTCMicrosecondsClock is not high enough ? >>> Esteban >>> >>> On Aug 29, 2013, at 11:27 AM, Sabine KnÃ¶fel <sabine.knoefel(a)gmail.com> wrote: >>> >>>> Hi Esteban, All, >>>> >>>> I was proceeding to seach for the reason of the problem I described >>>> yesterday. >>>> >>>> I added some debugging code into VOMongoSerializer>>ensurePersisted: and the >>>> problem I described, did NOT occur. >>>> >>>> That made the whole process slower...and I had an idea.... >>>> >>>> I was looking into >>UUIDGenerator default makeSeed. >>>> Then I tried the following code: >>>> >>>> |theOld theNew| >>>> >>>> 100000000 timesRepeat: [ >>>> theNew := UUIDGenerator default makeSeed. >>>> theNew = theOld ifTrue: [self halt]. >>>> theOld := theNew] >>>> >>>> The debugger came up! Doesn't that mean that, if the code is run very fast, >>>> there are double OIDs generated?! >>>> >>>> In my case, the objects for country and currency are very lightweight and >>>> so, they are created very fast. Also, the error occured much more often >>>> within my fast production EC2 instance as at my (old and slow) development >>>> pc. >>>> >>>> Important: I work with windows and so >>makeUnixSeed returns nil... :-) >>>> >>>> What is your opinion about that? >>>> >>>> Sabine >>>> >>>> >>>> >>>> -- >>>> View this message in context: http://forum.world.st/voyage-mongo-randomly-wrong-OIDs-tp4705396p4705603.ht… >>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>>> >>> >>> >> >> > >

Aug. 30, 2013