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

Pharo 60 need help on When-coding-in-the-debugger-I-get-an-error-sourceNodeExecuted

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/19661/When-coding-in-the-debugger-I-get-a… Then I got a really strange problem when I was doing the counter execise using the debugger. create a Test Case TestCase subclass: #CounterTest instanceVariableNames: '' classVariableNames: '' package: 'Counter' - add testValueAtCreation self assert: (Counter new count: 10) count equals: 10 - ok to define classes - define count: in the class Counter - count: anInteger count := anInteger - Declare instance variable count NOW problem Instance of class did not understand count - ok to define it => Instance of IRMethod do not understand sourceNodeExecuted HAnging around instances ========== Then if I remove the Counter class and relaunch the tests I get Instance of anObsoleteCounter did not understandâ¦.

Feb. 6, 2017

Re: [Pharo-dev] Seamless Error in GT-Inspector

by Denis Kudriashov

I fixed it. Now Seamless is compatible with old Pharo (5 at least). Try new stable version. It was just little problem with one method. So old RemoteDebuggingTools project is also work on Pharo 5. But remember that PharmIDE is only target Pharo 6 or later. Thank's for feedback 2017-02-06 16:59 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Denis Kudriashov wrote > > Just check in latest Pharo 6. It works > > Thanks, I was in Pharo 5 > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Seamless-Error-in-GT- > Inspector-tp4933050p4933167.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Feb. 6, 2017

Re: [Pharo-dev] Pharo 6 update catalog entries

by Sean P. DeNigris

kilon.alios wrote > I see little reason to support individual pharo versions because I focus > always on the latest version. I'm not suggesting that you maintain compatibility ongoingly with various versions, but if you mark compatible versions as such in the catalog, users won't get an unnecessary warning. Either way, thanks for the tool! I happily use it daily :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-6-update-catalog-entries-tp4932354p4933169.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 6, 2017

Re: [Pharo-dev] Seamless Error in GT-Inspector

by Sean P. DeNigris

Denis Kudriashov wrote > Just check in latest Pharo 6. It works Thanks, I was in Pharo 5 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Seamless-Error-in-GT-Inspector-tp4933050p4933167.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 6, 2017

Re: [Pharo-dev] [QA] quality assurance

by Sean P. DeNigris

Ben Coman wrote > That seems appropriate. > A separate list makes it hard to draw new people in to help. +1 ----- Cheers, Sean -- View this message in context: http://forum.world.st/QA-quality-assurance-tp4933067p4933166.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 6, 2017

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