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

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

by Peter Uhnak

1. Regarding WorkingSession The WS' comment claims "On each image startup the current session is invalidated and a new session is created.", but in reality WS is reset only save&quit, and not on startup... isn't that odd? So if image crashes or I am running it headlessly without saving I am actually still on the same session. 2. Regarding NeoUUID My apologies for stating that it was made worse than the /dev/urandom one, now I know why it doesn't really matter due to the other rolling factors. However I found some things that you may or may not find interesting (especially on Windows): On Windows (10) (with latest 6 image and VM) `Time microsecondClockValue` returns microseconds, but (presumably the system) cannot give precision beyond 1 second - this will imho need a VM fix; I can also generate about 1.2M UUIDs per second (limited by single core I guess), which means that about every 600-1200 consequential UUIDs will have the same clock value. On Linux the microseconds are fine, also I generate only 0.8M UUIDs (it is older machine, so with >1M UUID/sec you will still have time clash), now there's about 1-2% probability that the immediately next UUID will have the same clock, but this is countered by the counter. :) You are also taking 8 bytes of microsecondClockValue, but the value has only 7 bytes... so 8th byte is fixed to 0. 9 & 10 bytes are counter, but 9th bit is rewritten with variant, so the counter is actually 0-255 and not 0-65536. And finally 11 & 12 are random bits (assuming the seeding isn't broken). So on Windows, the conditional probability that nth and n+256th UUIDs will be identical is imho 1/65536 (assuming they are in the same second, which is easy). On Linux my understanding is that clash can only happen if NTP adjusts my clock during UUID generation (at which point it is same as Windows). Can UUID clash be achieved on Linux if you deploy copies of the same image and let them all generate UUIDs? (It should be again 1/65536). Regarding the poor seed at startup: 1k outside runs of 'NeoUUIDGenerator new nextRandom16' (on a fresh image) gives me only 116 unique values, compared to the expected 990-1000 In the above it's already second run of the generator, for (random initial) counter, there was only 69 unique values out of 1000. 3. Chicken and egg question How would one bootstrap session's id initialized with just NeoUUID? :) (WorkingSession wants UUID new in initialize, but UUID needs WorkingSession to generate a UUID) Peter > > 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] Pharo 60 need help white-theme-color-for-button-is-not-good

by phil＠highoctane.be

I proposed that a while ago because these gradients are bad looking (especially in an age of flat design). https://pharo.fogbugz.com/f/cases/13132/Ugly-gradients-in-Pharo3Theme-Not-i… Same for those ugly flat scrollbars. https://pharo.fogbugz.com/f/cases/13136/Pharo3Theme-scrollbars-looking-like… This one has a slice. Maybe Pharo 6 is not too late for those slices. Phil On Mon, Feb 6, 2017 at 5:59 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > https://pharo.fogbugz.com/f/cases/19657/white-theme-color- > for-button-is-not-good > > If we compare the selection color for the dark theme, the blue is stronger > and much better to see. > This is particularly true for class/instance side button, > > I would be good to have a better white theme with stronger selection > colors. >

Feb. 6, 2017

Re: [Pharo-dev] Pharo 60 need help on Red-in-Dark-Theme-is-plain-bad

by phil＠highoctane.be

I'll check that. FWIW, all of this color thing + theme is annoying me and I started something to sort it out. Also have eye issues and one of the reasons I use Pharo is that I can customize it for my own ways. We need a real core palette on top of which we put logical color names for the themes. Check the GLM Themers are not fully working with themes and have hardcoded colors and some missing subclasses (I am making Sublismish from Seb work there)... AAaaah. Phil On Mon, Feb 6, 2017 at 5:56 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > https://pharo.fogbugz.com/f/cases/19658/Red-in-Dark-Theme-is-plain-bad > > The black theme is not usable on certain screen because the red color > cannot be distinguished. > So when the white theme does not work for other reasons people cannot do > much. > > They cannot read the errors. In addition since the hilighter is broken!!! > bingo you cannot see anything. > > Super cool system. >

Feb. 6, 2017

Re: [Pharo-dev] Pharo 60 need help on When-coding-in-the-debugger-I-get-an-error-sourceNodeExecuted

by Denis Kudriashov

Fixed 2017-02-06 17:55 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > https://pharo.fogbugz.com/f/cases/19661/When-coding-in- > the-debugger-I-get-an-error-sourceNodeExecuted > > 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

Pharo 60 needs help on ooltips-of-the-class-button-does-not-changed

by Stephane Ducasse

If you want to help pharo: https://pharo.fogbugz.com/f/cases/19659/Tooltips-of-the-class-button-does-n…

Feb. 6, 2017

Pharo 60 need help white-theme-color-for-button-is-not-good

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/19657/white-theme-color-for-button-is-not… If we compare the selection color for the dark theme, the blue is stronger and much better to see. This is particularly true for class/instance side button, I would be good to have a better white theme with stronger selection colors.

Feb. 6, 2017

Pharo 60 needs help on Broken-syntax-highlithing

by Stephane Ducasse

I'm giving some lectures to siemens engineers and .... we found glitches. (bad impression). https://pharo.fogbugz.com/f/cases/19656/Broken-syntax-highlithing

Feb. 6, 2017

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

by Sean P. DeNigris

Denis Kudriashov wrote > I fixed it. Thanks! Denis Kudriashov wrote > So old RemoteDebuggingTools project is also work on Pharo 5. > But remember that PharmIDE is only target Pharo 6 or later. No problem. I don't /need/ it to work in Pharo 5, but read that it was working, so I figured I'd let you know about the problem. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Seamless-Error-in-GT-Inspector-tp4933050p4933193.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Feb. 6, 2017

Pharo 60 needs help on shortcuts-are-wrongly-displayed

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/19660/shortcuts-are-wrongly-displayed The system should display Ctrl + s and not Ctrl + S Because people are pressing Shift to get S and this is not working. We should distinguish between uppercase and lowercase. The reader cannot guess that S is not the same as s + shift. There is no way that a user can know that they should NOT press shift when looking at Ctrl + S (because there is no noshiftPressed). Ctrl + S means press Shift.

Feb. 6, 2017

Pharo 60 need help on Red-in-Dark-Theme-is-plain-bad

by Stephane Ducasse

https://pharo.fogbugz.com/f/cases/19658/Red-in-Dark-Theme-is-plain-bad The black theme is not usable on certain screen because the red color cannot be distinguished. So when the white theme does not work for other reasons people cannot do much. They cannot read the errors. In addition since the hilighter is broken!!! bingo you cannot see anything. Super cool system.

Feb. 6, 2017