- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Esteban's ChangeLog week of 30 January 2017

by Sean P. DeNigris

EstebanLM wrote > This is my weekly ChangeLog, from 30 January 2017 to 5 February 2017. Go, go, go, Esteban!!! EstebanLM wrote > the new process we are starting to create for Pharo, we need to be able to > do things like... Sounds great :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Esteban-s-ChangeLog-week-of-30-January-2017-tp4933097… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 6, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by Sven Van Caekenberghe

> On 6 Feb 2017, at 15:21, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Of course UUID is not guaranteed to be absolutely random. But it is suspicious these similarities happen is a small timeframe, so I think that the image got restarted a few times, but generated the same ID. If you say a timestamp is more reliable in your use case, note that NeoUUID contains a ms clock value, so it should not be possible that you get 2 similar values for 2 distinct runs. If you are limited to macOS/Linux one can always do '/dev/random' asFileReference binaryReadStreamDo: [ :in | in next: 8 ]. to get random bytes. > Uko > > >> On 6 Feb 2017, at 14:35, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >>> On 6 Feb 2017, at 14:17, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> Hi everyone, >>> >>> Iâm using the session id (Smalltalk session id) for my data recording, so I can distinguish if the recorded events came from the same session. The idea is that each time an image is started a new session is created and assigned a new UUID. Now when I started to look on the data I noticed that I have some cases where I have same session IDs with different session creation times (yes a new session is initialized with a current timestamp). The time difference for the sessions with the same UUID and a different timestamp is within 2 hours. Then another thing that I did is to group the data by the timestamp and there are no cases where I have a different ID for the same timestamp, which shows that the timestamp is a more reliable ID. Now I will deal with my data just fine, but maybe we need to look in the implementation why do we get sessions with the same IDs? >>> >>> Cheers. >>> Uko >> >> I would be very surprised it would happen with NeoUUIDGenerator (NeoUUIDGenerator next). The idea was to replace UUIDGenerator and the VM plugin by it. That got stalled when there was unforeseen interaction with WorkingSession. I believe that should be solved by now. >> >> Still, UUIDs are not 100% guaranteed to be unique, they are a (very good) best effort. >> >> But I agree that if they repeat in such a short time frame, that should be considered a bug. >> >> Sven >> >> >> >> >> > >

Feb. 6, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by Yuriy Tymchuk

Of course UUID is not guaranteed to be absolutely random. But it is suspicious these similarities happen is a small timeframe, so I think that the image got restarted a few times, but generated the same ID. Uko > On 6 Feb 2017, at 14:35, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> On 6 Feb 2017, at 14:17, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Hi everyone, >> >> Iâm using the session id (Smalltalk session id) for my data recording, so I can distinguish if the recorded events came from the same session. The idea is that each time an image is started a new session is created and assigned a new UUID. Now when I started to look on the data I noticed that I have some cases where I have same session IDs with different session creation times (yes a new session is initialized with a current timestamp). The time difference for the sessions with the same UUID and a different timestamp is within 2 hours. Then another thing that I did is to group the data by the timestamp and there are no cases where I have a different ID for the same timestamp, which shows that the timestamp is a more reliable ID. Now I will deal with my data just fine, but maybe we need to look in the implementation why do we get sessions with the same IDs? >> >> Cheers. >> Uko > > I would be very surprised it would happen with NeoUUIDGenerator (NeoUUIDGenerator next). The idea was to replace UUIDGenerator and the VM plugin by it. That got stalled when there was unforeseen interaction with WorkingSession. I believe that should be solved by now. > > Still, UUIDs are not 100% guaranteed to be unique, they are a (very good) best effort. > > But I agree that if they repeat in such a short time frame, that should be considered a bug. > > Sven > > > > >

Feb. 6, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by Sven Van Caekenberghe

> On 6 Feb 2017, at 14:51, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > I had issues with Pharo not being random during the first startup: http://forum.world.st/Random-is-not-random-at-startup-td4895905.html > > Even though the seed is different during startup, the mask trims the randomness away. The Random generator is what it is, it can certainly be improved, but that is tricky too. In 64 bits we could probably do with less masking/trimming. > Looking at NeoUUID, it actually makes it worse on Linux (and presumably Unix/Mac too), because it uses Pharo's broken seeding and not pooling /dev/urandom. > > (I can test it on linux machine later today just to be sure.) Why would it be worse ? Of course it is not. Reading from /dev/random is not portable to Windows and tricky too (because it sometimes hangs until there is enough entropy). >> Still, UUIDs are not 100% guaranteed to be unique, they are a (very good) best effort. > > For all intents and purposes they are considered 100% to be unique. > If you generate two identical V4 UUIDs then either PRNG or seeding is broken (seeding in Pharo's case). > > Peter According to https://en.wikipedia.org/wiki/Universally_unique_identifier << When generated according to the standard methods, UUIDs are for practical purposes unique, without depending for their uniqueness on a central registration authority or coordination between the parties generating them, unlike most other numbering schemes. While the probability that a UUID will be duplicated is not zero, it is so close to zero as to be negligible. >> Read the last sentence. So IMO it is certainly not 'broken'. Note also that NeoUUID uses different elements, the random part is only one of them. > On Mon, Feb 06, 2017 at 02:35:37PM +0100, Sven Van Caekenberghe wrote: >> >>> On 6 Feb 2017, at 14:17, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >>> >>> Hi everyone, >>> >>> Iâm using the session id (Smalltalk session id) for my data recording, so I can distinguish if the recorded events came from the same session. The idea is that each time an image is started a new session is created and assigned a new UUID. Now when I started to look on the data I noticed that I have some cases where I have same session IDs with different session creation times (yes a new session is initialized with a current timestamp). The time difference for the sessions with the same UUID and a different timestamp is within 2 hours. Then another thing that I did is to group the data by the timestamp and there are no cases where I have a different ID for the same timestamp, which shows that the timestamp is a more reliable ID. Now I will deal with my data just fine, but maybe we need to look in the implementation why do we get sessions with the same IDs? >>> >>> Cheers. >>> Uko >> >> I would be very surprised it would happen with NeoUUIDGenerator (NeoUUIDGenerator next). The idea was to replace UUIDGenerator and the VM plugin by it. That got stalled when there was unforeseen interaction with WorkingSession. I believe that should be solved by now. >> >> Still, UUIDs are not 100% guaranteed to be unique, they are a (very good) best effort. >> >> But I agree that if they repeat in such a short time frame, that should be considered a bug. >> >> Sven >> >> >> >> >> >

Feb. 6, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by Peter Uhnak

I had issues with Pharo not being random during the first startup: http://forum.world.st/Random-is-not-random-at-startup-td4895905.html Even though the seed is different during startup, the mask trims the randomness away. Looking at NeoUUID, it actually makes it worse on Linux (and presumably Unix/Mac too), because it uses Pharo's broken seeding and not pooling /dev/urandom. (I can test it on linux machine later today just to be sure.) > Still, UUIDs are not 100% guaranteed to be unique, they are a (very good) best effort. For all intents and purposes they are considered 100% to be unique. If you generate two identical V4 UUIDs then either PRNG or seeding is broken (seeding in Pharo's case). Peter On Mon, Feb 06, 2017 at 02:35:37PM +0100, Sven Van Caekenberghe wrote: > > > On 6 Feb 2017, at 14:17, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > > Hi everyone, > > > > Iâm using the session id (Smalltalk session id) for my data recording, so I can distinguish if the recorded events came from the same session. The idea is that each time an image is started a new session is created and assigned a new UUID. Now when I started to look on the data I noticed that I have some cases where I have same session IDs with different session creation times (yes a new session is initialized with a current timestamp). The time difference for the sessions with the same UUID and a different timestamp is within 2 hours. Then another thing that I did is to group the data by the timestamp and there are no cases where I have a different ID for the same timestamp, which shows that the timestamp is a more reliable ID. Now I will deal with my data just fine, but maybe we need to look in the implementation why do we get sessions with the same IDs? > > > > Cheers. > > Uko > > I would be very surprised it would happen with NeoUUIDGenerator (NeoUUIDGenerator next). The idea was to replace UUIDGenerator and the VM plugin by it. That got stalled when there was unforeseen interaction with WorkingSession. I believe that should be solved by now. > > Still, UUIDs are not 100% guaranteed to be unique, they are a (very good) best effort. > > But I agree that if they repeat in such a short time frame, that should be considered a bug. > > Sven > > > > >

Feb. 6, 2017

Re: [Pharo-dev] WorkingSession UUID looks "sketchy"

by Sven Van Caekenberghe

> On 6 Feb 2017, at 14:17, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi everyone, > > Iâm using the session id (Smalltalk session id) for my data recording, so I can distinguish if the recorded events came from the same session. The idea is that each time an image is started a new session is created and assigned a new UUID. Now when I started to look on the data I noticed that I have some cases where I have same session IDs with different session creation times (yes a new session is initialized with a current timestamp). The time difference for the sessions with the same UUID and a different timestamp is within 2 hours. Then another thing that I did is to group the data by the timestamp and there are no cases where I have a different ID for the same timestamp, which shows that the timestamp is a more reliable ID. Now I will deal with my data just fine, but maybe we need to look in the implementation why do we get sessions with the same IDs? > > Cheers. > Uko I would be very surprised it would happen with NeoUUIDGenerator (NeoUUIDGenerator next). The idea was to replace UUIDGenerator and the VM plugin by it. That got stalled when there was unforeseen interaction with WorkingSession. I believe that should be solved by now. Still, UUIDs are not 100% guaranteed to be unique, they are a (very good) best effort. But I agree that if they repeat in such a short time frame, that should be considered a bug. Sven

Feb. 6, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60375 Home: https://github.com/pharo-project/pharo-core

Feb. 6, 2017

[pharo-project/pharo-core] 394af1: 60375

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 394af1e72e16fd07e051c527b87418e41e00b848 https://github.com/pharo-project/pharo-core/commit/394af1e72e16fd07e051c527… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-02-06 (Mon, 06 Feb 2017) Changed paths: A AST-Core.package/RBParseErrorNode.class/instance/accessing/body_.st A AST-Core.package/RBParseErrorNode.class/instance/accessing/source_.st M AST-Core.package/RBParser.class/instance/private-parsing/parseMethod.st A AST-Tests-Core.package/RBParserTest.class/instance/tests parsing/testParseFaultyMethodMessagePattern.st R BaselineOfFileTree.package/BaselineOfFileTree.class/README.md R BaselineOfFileTree.package/BaselineOfFileTree.class/definition.st R BaselineOfFileTree.package/BaselineOfFileTree.class/instance/baseline/baseline_.st M Morphic-Base.package/SystemProgressItemMorph.class/instance/private/refresh.st M Morphic-Base.package/SystemProgressMorph.class/instance/updating/refresh.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60374.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60375.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60374.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60375.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60375 18271 BaselineOfFileTree is in the old version https://pharo.fogbugz.com/f/cases/18271 18837 RBParser should not crash when parsing a faulty method node https://pharo.fogbugz.com/f/cases/18837 19655 Handle events during progressBar usage https://pharo.fogbugz.com/f/cases/19655 http://files.pharo.org/image/60/60375.zip

Feb. 6, 2017

WorkingSession UUID looks "sketchy"

by Yuriy Tymchuk

Hi everyone, Iâm using the session id (Smalltalk session id) for my data recording, so I can distinguish if the recorded events came from the same session. The idea is that each time an image is started a new session is created and assigned a new UUID. Now when I started to look on the data I noticed that I have some cases where I have same session IDs with different session creation times (yes a new session is initialized with a current timestamp). The time difference for the sessions with the same UUID and a different timestamp is within 2 hours. Then another thing that I did is to group the data by the timestamp and there are no cases where I have a different ID for the same timestamp, which shows that the timestamp is a more reliable ID. Now I will deal with my data just fine, but maybe we need to look in the implementation why do we get sessions with the same IDs? Cheers. Uko

Feb. 6, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60374 Home: https://github.com/pharo-project/pharo-core

Feb. 6, 2017