Re: [Pharo-dev] Segmentation fault while installing Scale
Hi Andrey, Thanks for providing both a way to reproduce and the log so we can have you machine details. I see that the VM was compiled from build #589 on jenkins with VMMaker.oscog-eem.1855 and you're on Linux using x86 back-end. Scale works only on Linux and when I try the wget command from Mac it does not work so I can't reproduce right now. I suggest that for now you try to use one of the newer VMs (from http://files.pharo.org/vm/pharo-spur32/linux/ , you're using stable-20160504.zip, pick another one, I suggest a more recent one than from May last year, either stable-20160623.zip or pharo-linux-i386itimer-201702061308-aa78f27.zip) and then use the "classic installation" to be able to use another VM than the one downloaded by the wget script until someone can have a look into your problem. Best, Clement On Tue, Feb 7, 2017 at 8:00 AM, Stephane Ducasse wrote: > Hi andrey > > can you tell us on which OS and version and which VM do you use (there is > a System report browser where you can find the information. > > Tx > > > On Mon, Feb 6, 2017 at 8:20 PM, Andrey Tykhonov > wrote: > >> Hi all! >> >> While executing the following command: >> >> $ wget -O- https://raw.githubusercontent.com/guillep/Scale/master/setup >> Scale.sh | sudo bash > stderr.log >> >> I got the Segmentation fault error. You can see it in the contents of >> stderr.log which is attached to the email. Here you can see the >> output of the mentioned command: >> >> ``` >> --2017-02-03 19:35:16-- https://raw.githubusercontent >> .com/guillep/Scale/master/setupScale.sh >> Resolving raw.githubusercontent.com... 151.101.128.133, 151.101.192.133, >> 151.101.64.133, ... >> Connecting to raw.githubusercontent.com|151.101.128.133|:443... >> connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 1021 [text/plain] >> Saving to: ‘STDOUT’ >> >> - 100%[= >> >]1021 --.-KB/sin 0s >> >> 2017-02-03 19:35:16 (274 MB/s) - written to stdout [1021/1021] >> >> Cloning into '/tmp/scale'... >> remote: Counting objects: 1457, done. >> remote: Total 1457 (delta 0), reused 0 (delta 0), pack-reused 1457 >> Receiving objects: 100% (1457/1457), 656.60 KiB | 714.00 KiB/s, done. >> Resolving deltas: 100% (799/799), done. >> Note: checking out 'f70fdb90cf66d443140b6fe84cad9848163bf32e'. >> >> You are in 'detached HEAD' state. You can look around, make experimental >> changes and commit them, and you can discard any commits you make in this >> state without impacting any branches by performing another checkout. >> >> If you want to create a new branch to retain commits you create, you may >> do so (now or later) by using -b with the checkout command again. Example: >> >> git checkout -b >> >> --2017-02-03 19:35:18-- http://get.pharo.org/50+vm >> Resolving get.pharo.org... 128.93.162.72 >> Connecting to get.pharo.org|128.93.162.72|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 2901 (2.8K) [text/html] >> Saving to: ‘STDOUT’ >> >> - 100%[= >> >] 2.83K --.-KB/sin 0.001s >> >> 2017-02-03 19:35:18 (3.56 MB/s) - written to stdout [2901/2901] >> >> Downloading the latest 50 Image: >> http://files.pharo.org/get-files/50/pharo.zip >> Downloading the latest pharoVM: >> http://files.pharo.org/get-files/50/pharo-linux-stable.zip >> Downloading PharoV50.sources: >> http://files.pharo.org/get-files/50/sources.zip >> Creating starter scripts pharo and pharo-ui >> >> Fetched -> BaselineOfScale-SantiagoBragagnolo.4 --- >> filetree:///tmp/scale/src [:] --- filetree:///tmp/scale/src./pharo: line >> 11: 19176 Aborted "$DIR"/"pharo-vm/pharo" --nodisplay "$@" >> Syntax Error on line 26: 'Unmatched '' in string literal. ->' >> = >> 01: | scapeParentDirectory pharoParentDirectory scaleX scaleuiX | >> 02: >> 03: system stdout << 'Uninstalling scale' << String cr. >> 04: >> 05: system saveImageAs: #/ asFileReference / #tmp / #'uninstall.image'. >> 06: " The image must be stored elsewhere for deleting all the files " >> 07: >> 08: scaleX := '/usr/local/bin/scale' asFileReference. >> 09: scaleX exists ifTrue: [ system call: ' rm ', scaleX fullName ]. >> 10: system stdout << 'Uninstalling executable scale' << String cr ; flush. >> 11: >> 12: scaleuiX:='/usr/local/bin/scale-ui' asFileReference. >> 13: scaleuiX exists ifTrue: [ system call: ' rm ', scaleuiX fullName ]. >> 14: system stdout << 'Uninstalling executable scale-ui' << String cr ; >> flush. >> 15: >> 16: scapeParentDirectory := '/usr/local/scale' asFileReference. >> 17: pharoParentDirectory := '/usr/local/pharo' asFileReference. >> 18: >> 19: scapeParentDirectory exists ifTrue: [ system call: ' rm -rf ', >> scapeParentDirectory fullName ]. >> 20: system stdout << 'Removing scale folder' <
Re: [Pharo-dev] [QA] Debugger buttons explained
> On 7 Feb 2017, at 08:05, Stephane Ducasse wrote: > > Sven I do not get > > Step over the highlighted message, i.e. do not follow the sent message, > taking debugger control after the method invoked returns or whenever > execution should return inside a block used as an argument before that. > > in particular the taking debugger control > may be > > give back debugger control? Give back might be clearer than take back, I guess, I don't know. Maybe the 'before that' should be moved too, as in Step over the highlighted message, i.e. do not follow the sent message, give back debugger control after the method invoked returns or whenever before that execution should return inside a block used as an argument. > On Mon, Feb 6, 2017 at 7:39 PM, Sven Van Caekenberghe wrote: > > > On 6 Feb 2017, at 18:55, Hilaire wrote: > > > > How will you describe these buttons in the debugger? > > Here are proposals for tooltips, please fix it, I am sure there are > > better way to write it. > > > > Proceed > > Quit the debugger and resume the execution of the method. > > > > Restart > > Reset the local variable and restart stepping at the beginning of the > > method. > > > > Into > > Step in the highlighted message, i.e. follow the sent message in its method. > > > > Over > > Execute the highlighted message, i.e. do not follow the sent message in > > its method. > > > > Through > > Execute the highlighted message, when argument is a bloc to #do:, > > #collect:, #select: #detect: step in the bloc. > > That last one is not correct. It has nothing to do with specific iteration > selectors. It means: stop when execution returns in one of the argument > blocks. It also works for #on:error: #streamContents: or any other message > that accepts blocks as argument - which is pretty cool. > > Consult DebugSession for good descriptions of the actions. > > > This is my version/take, probably not perfect either. > > > Into > > Step in the highlighted message, i.e. follow the sent message, taking > debugger control in the method invoked. > > Over > > Step over the highlighted message, i.e. do not follow the sent message, > taking debugger control after the method invoked returns. > > Through > > Step over the highlighted message, i.e. do not follow the sent message, > taking debugger control after the method invoked returns or whenever > execution should return inside a block used as an argument before that. > > Restart > > Go back the start of the current execution context, resetting all local > variables and take debugger control. > > Continue > > Relinquish debugger control and proceed execution from the current point of > debugger control. > > > > https://pharo.fogbugz.com/f/cases/19654/Tooltips-with-description-of-the-over-and-through-debugger-buttons-actions > > > > -- > > Dr. Geo > > http://drgeo.eu > > > > > > >
Re: [Pharo-dev] Pharo 60 need help white-theme-color-for-button-is-not-good
No it is important. There is no point to have a supercool system that looks so bad and turn people off. But I do not get it your 13136 was integrated. On Mon, Feb 6, 2017 at 6:28 PM, p...@highoctane.be wrote: > 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-in-line-with-the-times > > Same for those ugly flat scrollbars. > > https://pharo.fogbugz.com/f/cases/13136/Pharo3Theme- > scrollbars-looking-like-dead-without-visual-indicators > > 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 > wrote: > >> https://pharo.fogbugz.com/f/cases/19657/white-theme-color-fo >> r-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. >> > >
Re: [Pharo-dev] [QA] Debugger buttons explained
Sven I do not get Step over the highlighted message, i.e. do not follow the sent message, taking debugger control after the method invoked returns or whenever execution should return inside a block used as an argument before that. in particular the taking debugger control may be give back debugger control? On Mon, Feb 6, 2017 at 7:39 PM, Sven Van Caekenberghe wrote: > > > On 6 Feb 2017, at 18:55, Hilaire wrote: > > > > How will you describe these buttons in the debugger? > > Here are proposals for tooltips, please fix it, I am sure there are > > better way to write it. > > > > Proceed > > Quit the debugger and resume the execution of the method. > > > > Restart > > Reset the local variable and restart stepping at the beginning of the > > method. > > > > Into > > Step in the highlighted message, i.e. follow the sent message in its > method. > > > > Over > > Execute the highlighted message, i.e. do not follow the sent message in > > its method. > > > > Through > > Execute the highlighted message, when argument is a bloc to #do:, > > #collect:, #select: #detect: step in the bloc. > > That last one is not correct. It has nothing to do with specific iteration > selectors. It means: stop when execution returns in one of the argument > blocks. It also works for #on:error: #streamContents: or any other message > that accepts blocks as argument - which is pretty cool. > > Consult DebugSession for good descriptions of the actions. > > > This is my version/take, probably not perfect either. > > > Into > > Step in the highlighted message, i.e. follow the sent message, taking > debugger control in the method invoked. > > Over > > Step over the highlighted message, i.e. do not follow the sent message, > taking debugger control after the method invoked returns. > > Through > > Step over the highlighted message, i.e. do not follow the sent message, > taking debugger control after the method invoked returns or whenever > execution should return inside a block used as an argument before that. > > Restart > > Go back the start of the current execution context, resetting all local > variables and take debugger control. > > Continue > > Relinquish debugger control and proceed execution from the current point > of debugger control. > > > > https://pharo.fogbugz.com/f/cases/19654/Tooltips-with- > description-of-the-over-and-through-debugger-buttons-actions > > > > -- > > Dr. Geo > > http://drgeo.eu > > > > > > >
Re: [Pharo-dev] Debugger hang when step throught
tx for the report hilaire. Indeed I can reproduce your bug - I pasted it - I did debug it over over and through trhough and my system froze. On Mon, Feb 6, 2017 at 7:04 PM, Hilaire wrote: > Hello, > > The faulty code bellow when debugged and 'step through' cause the > debugger to hang: > > self inform: '1'. > #(2 3 4) select: [:i| i] thenDo: [:n| self inform: n printString ]. > self inform: '5'. > > It seems trapped in an infinite loop, you can more or less get control > back with Alt+[.] > > > When step in, the debugger properly report the error. > > Pharo #60362. > > > I did not see similar bug report, shall I? > > -- > Dr. Geo > http://drgeo.eu > > >
Re: [Pharo-dev] Segmentation fault while installing Scale
Hi andrey can you tell us on which OS and version and which VM do you use (there is a System report browser where you can find the information. Tx On Mon, Feb 6, 2017 at 8:20 PM, Andrey Tykhonov wrote: > Hi all! > > While executing the following command: > > $ wget -O- https://raw.githubusercontent.com/guillep/Scale/master/ > setupScale.sh | sudo bash > stderr.log > > I got the Segmentation fault error. You can see it in the contents of > stderr.log which is attached to the email. Here you can see the > output of the mentioned command: > > ``` > --2017-02-03 19:35:16-- https://raw.githubusercontent.com/guillep/ > Scale/master/setupScale.sh > Resolving raw.githubusercontent.com... 151.101.128.133, 151.101.192.133, > 151.101.64.133, ... > Connecting to raw.githubusercontent.com|151.101.128.133|:443... connected. > HTTP request sent, awaiting response... 200 OK > Length: 1021 [text/plain] > Saving to: ‘STDOUT’ > > - 100%[= > >]1021 --.-KB/sin 0s > > 2017-02-03 19:35:16 (274 MB/s) - written to stdout [1021/1021] > > Cloning into '/tmp/scale'... > remote: Counting objects: 1457, done. > remote: Total 1457 (delta 0), reused 0 (delta 0), pack-reused 1457 > Receiving objects: 100% (1457/1457), 656.60 KiB | 714.00 KiB/s, done. > Resolving deltas: 100% (799/799), done. > Note: checking out 'f70fdb90cf66d443140b6fe84cad9848163bf32e'. > > You are in 'detached HEAD' state. You can look around, make experimental > changes and commit them, and you can discard any commits you make in this > state without impacting any branches by performing another checkout. > > If you want to create a new branch to retain commits you create, you may > do so (now or later) by using -b with the checkout command again. Example: > > git checkout -b > > --2017-02-03 19:35:18-- http://get.pharo.org/50+vm > Resolving get.pharo.org... 128.93.162.72 > Connecting to get.pharo.org|128.93.162.72|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 2901 (2.8K) [text/html] > Saving to: ‘STDOUT’ > > - 100%[= > >] 2.83K --.-KB/sin 0.001s > > 2017-02-03 19:35:18 (3.56 MB/s) - written to stdout [2901/2901] > > Downloading the latest 50 Image: > http://files.pharo.org/get-files/50/pharo.zip > Downloading the latest pharoVM: > http://files.pharo.org/get-files/50/pharo-linux-stable.zip > Downloading PharoV50.sources: > http://files.pharo.org/get-files/50/sources.zip > Creating starter scripts pharo and pharo-ui > > Fetched -> BaselineOfScale-SantiagoBragagnolo.4 --- > filetree:///tmp/scale/src [:] --- filetree:///tmp/scale/src./pharo: line > 11: 19176 Aborted "$DIR"/"pharo-vm/pharo" --nodisplay "$@" > Syntax Error on line 26: 'Unmatched '' in string literal. ->' > = > 01: | scapeParentDirectory pharoParentDirectory scaleX scaleuiX | > 02: > 03: system stdout << 'Uninstalling scale' << String cr. > 04: > 05: system saveImageAs: #/ asFileReference / #tmp / #'uninstall.image'. > 06: " The image must be stored elsewhere for deleting all the files " > 07: > 08: scaleX := '/usr/local/bin/scale' asFileReference. > 09: scaleX exists ifTrue: [ system call: ' rm ', scaleX fullName ]. > 10: system stdout << 'Uninstalling executable scale' << String cr ; flush. > 11: > 12: scaleuiX:='/usr/local/bin/scale-ui' asFileReference. > 13: scaleuiX exists ifTrue: [ system call: ' rm ', scaleuiX fullName ]. > 14: system stdout << 'Uninstalling executable scale-ui' << String cr ; > flush. > 15: > 16: scapeParentDirectory := '/usr/local/scale' asFileReference. > 17: pharoParentDirectory := '/usr/local/pharo' asFileReference. > 18: > 19: scapeParentDirectory exists ifTrue: [ system call: ' rm -rf ', > scapeParentDirectory fullName ]. > 20: system stdout << 'Removing scale folder' << String cr ; flush. > 21: > 22: pharoParentDirectory exists ifTrue: [ system call: ' rm -rf ', > pharoParentDirectory fullName ]. > 23: system stdout << 'Removing pharo folder' << String cr ; flush. > 24: > 25: > 26: system stdout << 'Done > _^_ > Syntax Error on line 39: 'Unmatched '' in string literal. ->' > = > 01: | scaleParentDirectory scaleFile scaleUIFile pharoParentDirectory| > 02: > 03: " DEPLOY " > 04: system stdout << 'Deploying scale command';cr. > 05: > 06: scaleParentDirectory := '/usr/local/scale' asFileReference. > 07: > 08: scaleParentDirectory exists > 09: ifTrue: [ > 10: system stderr << 'There is already an installation. Please > uninstall before' > 11: ] ifFalse: [ > 12: scaleParentDirectory ensureCreateDirectory. > 13: scaleFile := scaleParentDirectory / 'scale'. > 14: scaleUIFile := scaleParentDirectory / 'scale-ui'. > 15: system workingDirectory /
Re: [Pharo-dev] Pharo 6 update catalog entries
Fair point, I will make the changes. Glad you find it useful, is there any new feature you want ? On Mon, 6 Feb 2017 at 18:05, Sean P. DeNigris wrote: > 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. > >
[Pharo-dev] Printing numbers in different bases
--- Begin Message --- Is there a reason why we allow printing numbers in bases greater than 36? It makes no sense to me. For instance: 1406 printStringBase: 57. "O]" - Benoît St-Jean "A standpoint is an intellectual horizon of radius zero". (A. Einstein)--- End Message ---
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
On Tue, Feb 7, 2017 at 5:59 AM, Peter Uhnak wrote: > >> > 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 find that quite hard to believe and I did not know that. Are you really >> sure ? That would be terrible. A solution might be to use another clock >> primitive. >> >> > 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. >> >> I can't follow your reasoning here: if the clock precision would be 1 >> second, you would get 1.2M consecutive UUIDs with the same clock value, >> right ? > > Whoops, I meant the precision on a millisecond, not second... thus the ~1000k > consecutive clock values. > The returned value is still in microseconds, but the last 3 digits are fixed > (they are different on startup, but same during execution). This is a limitation of the Windows VM. I opened an issue to work on VM clock, but a few other side-tasks jumped above it while I was learning more about the VM code. https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/36 cheers -ben
Re: [Pharo-dev] [QA] Debugger buttons explained
> On 6 Feb 2017, at 21:25, Sean P. DeNigris wrote: > > How about... > > Into > > Step into the highlighted message, i.e. dive the debugger into the method > which handles it > > Over > > Step over the highlighted message, i.e. execute it, but keep the debugger > focused on the current method > > Through > > Like stepping "Over", except step through block contents when executed > > Restart > > Rewind to the start of the current execution context, resetting all local > variables > > Continue > > Relinquish debugger control and proceed with normal execution Well simpler is of course better, but I think that the aspect of telling what the debugger will do, where it will stop is quite important. Unless it is clear for everybody that step implies to stop and having control return to the debugger. > - > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/QA-Debugger-buttons-explained-tp4933212p4933238.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
> On 6 Feb 2017, at 23:01, werner kassens wrote: > > On 02/06/2017 09:00 PM, Sven Van Caekenberghe wrote: >> 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. >> But that is not proper use of a random generator, you create a new instance >> every time. You basically test seeding, which is different from random >> number generator proper. >> > Hi, isnt it that, what the thread originally was about? as far as i > understand it, it started with yuriy saying: > > The idea is that each time an image is started a new session is created and > assigned a new UUID... Certainly for NeoUUIDGenerator, that will be the case, AFAIK. > werner
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
> On 6 Feb 2017, at 22:59, Peter Uhnak wrote:
>
>
>>> 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 find that quite hard to believe and I did not know that. Are you really
>> sure ? That would be terrible. A solution might be to use another clock
>> primitive.
>>
>>> 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.
>>
>> I can't follow your reasoning here: if the clock precision would be 1
>> second, you would get 1.2M consecutive UUIDs with the same clock value,
>> right ?
>
> Whoops, I meant the precision on a millisecond, not second... thus the ~1000k
> consecutive clock values.
> The returned value is still in microseconds, but the last 3 digits are fixed
> (they are different on startup, but same during execution).
>
> I faintly remember having the same issue in a different language years ago,
> because they had different APIs or some bullshit like that.
>
> So when I generate e.g. 10 random UUIDs I get:
>
>
> (1 to: 10) collect: [ :i | NeoUUIDGenerator next ]. "an Array(
> an UUID('349b2ccc-4404-0d00-a8e7-5c9c0ef2da37')
> an UUID('349b2ccc-4404-0d00-a8e8-2f3a0ef2da37')
> an UUID('349b2ccc-4404-0d00-a8e9-9e0b0ef2da37')
> an UUID('349b2ccc-4404-0d00-a8ea-15520ef2da37')
> an UUID('349b2ccc-4404-0d00-a8eb-fa5c0ef2da37')
> an UUID('349b2ccc-4404-0d00-a8ec-d25f0ef2da37')
> an UUID('349b2ccc-4404-0d00-a8ed-6a590ef2da37')
> an UUID('349b2ccc-4404-0d00-a8ee-3a8d0ef2da37')
> an UUID('349b2ccc-4404-0d00-a8ef-0ad20ef2da37')
> an UUID('349b2ccc-4404-0d00-a8f0-7bda0ef2da37'))"
I don't see any problem here, they are all different.
Of course the clock part is the same during the same millisecond.
>> In the unit tests this is verified (that the time value goes forward on
>> consecutive calls).
>>
>
> testTwo*Generator only tests if they are close, not that one is higher than
> the other,
>
> if I add
>
> self assert: time2 equals: time1.
>
> the test will still pass (but that is already obvious from the list above).
>
>
>
>>> 9 & 10 bytes are counter, but 9th bit is rewritten with variant, so the
>>> counter is actually 0-255 and not 0-65536.
>>
>> Yes, but more correctly, the top 2 bits are set to 10, making the range 1 to
>> 2^14 (16384) (instead of 2^16).
>
> Welp, I can't do bit math.
>
>>
>>> And finally 11 & 12 are random bits (assuming the seeding isn't broken).
>>
>> The seeding is one aspect (the quality of the seed), the algorithm is
>> another.
>> Note that in the current Random class, the seed is initialised using the
>> clock as well.
>
> The problem with Random is not the time-based initialization, but masking of
> the initial value (which is mentioned in the originally linked thread on
> randomness, which fixes itself upon further generations).
>
>>
>>> 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).
>>
>> I am pretty/quite sure this is not correct but it would take me much more
>> time to come up with a more correct calculation.
>
> With the actual counter I would have to generate 16384 UUID/milisecond, which
> unlike 256/ms I cannot do, so it is safe again. :) (well... until Pharo goes
> multicore)
>
>>
>> BTW, you also have to define the context of being the same: the same
>> instance of one NeoUUIDGenerator generating the same UUID, or several
>> different generator instances, in the same image, in different images, on
>> different runs, the same or different machines/networks, ...
>>
>>> 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).
>
> Yeah, across machines the last four bytes behave randomly too.
>
> Maybe I can get clash if I run two random generators in forks (to fix 14 bits
> of counter randomness :) ... but no time for that now. :)
>
> Peter
>
Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)
> On 6 Feb 2017, at 22:33, Nicolai Hess wrote: > > > > 2017-02-04 13:40 GMT+01:00 Sven Van Caekenberghe : > > > On 4 Feb 2017, at 13:01, Nicolai Hess wrote: > > > > > > > > 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe : > > Hi Nicolai, > > > > The FileSystem API is a bit inconsistent, yes. > > > > This is how you can use it: > > > > (FileLocator temp / 'foo.txt') writeStreamDo: [ :out | > > out binary. > > (ZnCharacterWriteStream on: out encoding: #utf8) << 'élève' ]. > > > > (FileLocator temp / 'foo.txt') readStreamDo: [ :in | > > in binary. > > ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > > > (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in | > > (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > > > There is no #binaryWriteStreamDo: > > > > The API around File is more correct, IMHO. > > > > Does this help ? > > > > Yes, thanks for the fast response. > > > > What exactly is your question ? > > > > I am looking at the issues with FileList, there are some parts that don't > > work anymore (see FileList>>#contents, it calls some unimplemted methods), > > and it uses TextConverter and somoe parts of the older File api. > > It looks like most other (newer) parts are using ZnCharacterReadstream for > > encoding, but I couldn't find a way to use it together with FileReferences > > (most parts of the FileList already operate with the newer FileSystem API. > > OK. > > From my standpoint and understanding, I would always use binary streams with > explicit Zn converters, this combination is much easier to understand and > better implemented with more features. > > If you encounter any problem or have any questions, I will gladly try to help > you. > > :-) > Is there a way to list all supported encodings, similar to TextConverter > class >> #allEncodingNames ? > I only found > ZnSimplifiedByteEncoder class >> #knownEncodingIdentifiers > and > ZnByteEncoder class >> #knownEncodingIdentifiers > and nothing for all supported utf-8/16 ... encodings. Ah, yes, you are right, I should add a #knownEncodingIdentifiers at the level of ZnCharacterEncoder that returns the union of all of them. I will add that tomorrow. > nicolai > > > > Sven > > > > > On 4 Feb 2017, at 12:09, Nicolai Hess wrote: > > > > > > Hi > > > How can I specify the character encoding when opening a readStream on a > > > FileRerefence. > > > > > > I found this, that works: > > > > > > | readStream fileContent | > > > readStream := (File named: aFileName) openForRead. > > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > > fileContent upToEnd asString. > > > > > > But if I try to do the same with a readStream from a FileReference > > > > > > | readStream fileContent | > > > readStream := aFileName asFileReference readStream. > > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > > fileContent upToEnd asString. > > > > > > I get an error SmallInteger DNU #asciiValue, > > > > > > this is because, in the first method, we create a binary filestream, and > > > if we > > > use readStream from a FileReference, the stream is a MultibyteFileStream. > > > > > > How can I us ZnEncoder for a readstream from a FileReference? > > > > > > (and is it on purpose that both readStream method (openForRead/readStream) > > > return different kinds of binary streams?) > > > > > > > > > nicolai
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
On 02/06/2017 09:00 PM, Sven Van Caekenberghe wrote: 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. But that is not proper use of a random generator, you create a new instance every time. You basically test seeding, which is different from random number generator proper. Hi, isnt it that, what the thread originally was about? as far as i understand it, it started with yuriy saying: The idea is that each time an image is started a new session is created and assigned a new UUID... werner
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
> > 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 find that quite hard to believe and I did not know that. Are you really
> sure ? That would be terrible. A solution might be to use another clock
> primitive.
>
> > 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.
>
> I can't follow your reasoning here: if the clock precision would be 1 second,
> you would get 1.2M consecutive UUIDs with the same clock value, right ?
Whoops, I meant the precision on a millisecond, not second... thus the ~1000k
consecutive clock values.
The returned value is still in microseconds, but the last 3 digits are fixed
(they are different on startup, but same during execution).
I faintly remember having the same issue in a different language years ago,
because they had different APIs or some bullshit like that.
So when I generate e.g. 10 random UUIDs I get:
(1 to: 10) collect: [ :i | NeoUUIDGenerator next ]. "an Array(
an UUID('349b2ccc-4404-0d00-a8e7-5c9c0ef2da37')
an UUID('349b2ccc-4404-0d00-a8e8-2f3a0ef2da37')
an UUID('349b2ccc-4404-0d00-a8e9-9e0b0ef2da37')
an UUID('349b2ccc-4404-0d00-a8ea-15520ef2da37')
an UUID('349b2ccc-4404-0d00-a8eb-fa5c0ef2da37')
an UUID('349b2ccc-4404-0d00-a8ec-d25f0ef2da37')
an UUID('349b2ccc-4404-0d00-a8ed-6a590ef2da37')
an UUID('349b2ccc-4404-0d00-a8ee-3a8d0ef2da37')
an UUID('349b2ccc-4404-0d00-a8ef-0ad20ef2da37')
an UUID('349b2ccc-4404-0d00-a8f0-7bda0ef2da37'))"
>
> In the unit tests this is verified (that the time value goes forward on
> consecutive calls).
>
testTwo*Generator only tests if they are close, not that one is higher than the
other,
if I add
self assert: time2 equals: time1.
the test will still pass (but that is already obvious from the list above).
> > 9 & 10 bytes are counter, but 9th bit is rewritten with variant, so the
> > counter is actually 0-255 and not 0-65536.
>
> Yes, but more correctly, the top 2 bits are set to 10, making the range 1 to
> 2^14 (16384) (instead of 2^16).
Welp, I can't do bit math.
>
> > And finally 11 & 12 are random bits (assuming the seeding isn't broken).
>
> The seeding is one aspect (the quality of the seed), the algorithm is another.
> Note that in the current Random class, the seed is initialised using the
> clock as well.
The problem with Random is not the time-based initialization, but masking of
the initial value (which is mentioned in the originally linked thread on
randomness, which fixes itself upon further generations).
>
> > 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).
>
> I am pretty/quite sure this is not correct but it would take me much more
> time to come up with a more correct calculation.
With the actual counter I would have to generate 16384 UUID/milisecond, which
unlike 256/ms I cannot do, so it is safe again. :) (well... until Pharo goes
multicore)
>
> BTW, you also have to define the context of being the same: the same instance
> of one NeoUUIDGenerator generating the same UUID, or several different
> generator instances, in the same image, in different images, on different
> runs, the same or different machines/networks, ...
>
> > 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).
Yeah, across machines the last four bytes behave randomly too.
Maybe I can get clash if I run two random generators in forks (to fix 14 bits
of counter randomness :) ... but no time for that now. :)
Peter
Re: [Pharo-dev] FileStreams and encoding ( opening a readStream on a FileRerefence)
2017-02-04 13:40 GMT+01:00 Sven Van Caekenberghe : > > > On 4 Feb 2017, at 13:01, Nicolai Hess wrote: > > > > > > > > 2017-02-04 12:49 GMT+01:00 Sven Van Caekenberghe : > > Hi Nicolai, > > > > The FileSystem API is a bit inconsistent, yes. > > > > This is how you can use it: > > > > (FileLocator temp / 'foo.txt') writeStreamDo: [ :out | > > out binary. > > (ZnCharacterWriteStream on: out encoding: #utf8) << 'élève' ]. > > > > (FileLocator temp / 'foo.txt') readStreamDo: [ :in | > > in binary. > > ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > > > (FileLocator temp / 'foo.txt') binaryReadStreamDo: [ :in | > > (ZnCharacterReadStream on: in encoding: #utf8) upToEnd ]. > > > > There is no #binaryWriteStreamDo: > > > > The API around File is more correct, IMHO. > > > > Does this help ? > > > > Yes, thanks for the fast response. > > > > What exactly is your question ? > > > > I am looking at the issues with FileList, there are some parts that > don't work anymore (see FileList>>#contents, it calls some unimplemted > methods), and it uses TextConverter and somoe parts of the older File api. > > It looks like most other (newer) parts are using ZnCharacterReadstream > for encoding, but I couldn't find a way to use it together with > FileReferences (most parts of the FileList already operate with the newer > FileSystem API. > > OK. > > From my standpoint and understanding, I would always use binary streams > with explicit Zn converters, this combination is much easier to understand > and better implemented with more features. > > If you encounter any problem or have any questions, I will gladly try to > help you. > :-) Is there a way to list all supported encodings, similar to TextConverter class >> #allEncodingNames ? I only found ZnSimplifiedByteEncoder class >> #knownEncodingIdentifiers and ZnByteEncoder class >> #knownEncodingIdentifiers and nothing for all supported utf-8/16 ... encodings. nicolai > > > Sven > > > > > On 4 Feb 2017, at 12:09, Nicolai Hess wrote: > > > > > > Hi > > > How can I specify the character encoding when opening a readStream on > a FileRerefence. > > > > > > I found this, that works: > > > > > > | readStream fileContent | > > > readStream := (File named: aFileName) openForRead. > > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > > fileContent upToEnd asString. > > > > > > But if I try to do the same with a readStream from a FileReference > > > > > > | readStream fileContent | > > > readStream := aFileName asFileReference readStream. > > > fileContent := ZnCharacterReadStream on: readStream encoding: encoding. > > > fileContent upToEnd asString. > > > > > > I get an error SmallInteger DNU #asciiValue, > > > > > > this is because, in the first method, we create a binary filestream, > and if we > > > use readStream from a FileReference, the stream is a > MultibyteFileStream. > > > > > > How can I us ZnEncoder for a readstream from a FileReference? > > > > > > (and is it on purpose that both readStream method > (openForRead/readStream) > > > return different kinds of binary streams?) > > > > > > > > > nicolai > > >
Re: [Pharo-dev] [QA] Debugger buttons explained
On Mon, Feb 6, 2017 at 9:14 PM, Hilaire wrote: > Thanks for the updated message. > > Le 06/02/2017 à 19:39, Sven Van Caekenberghe a écrit : > > That last one is not correct. It has nothing to do with specific > iteration selectors. It means: stop when execution returns in one of the > argument blocks. It also works for #on:error: #streamContents: or any other > message that accepts blocks as argument - which is pretty cool. > > Strangely step over does not step in the bloc with #do: but does with > #to:do: > > In the later case step over and through behave mostly the same, the > stack looks a bit different though. > > > Another question, I try to locate where the tooltips are set in the > debugger. I can't find it with traditional browser tools (send, class > use) and the finder: > > The finder tells me "Through" is used in SpecThroughDebugAction, but > browser tells me there is no use case of this class. I see some pragma > in class side method, did it... > actionType > > > > No user of actionType, but I guess user or pragma, how do you guys track > the logic from here > Seems that the logic for changing the tooltips is not that straightforward. If you ping me once you decided for a the text of the tooltip I can add them. If you want to look at it yourself here are some details: Each action in the debugger is modeled as a subclass of DebugAction. The Glamour interface of the debugger uses DebugAction>>#asGlamourAction to transform that into a Glamour action. This action is then rendered in GLMMorphicActionRenderer>>#render:. There the tooltip is set directly by concatenating the title and the shortcut of the action. Best solution would be to add a description attribute to DebugAction and GLMAction and then modify GLMMorphicActionRenderer>>#render: to use it. For the Spec interface of the debugger you need to adapt DebugAction>>#asMenuRegistrationIn: Cheers, Andrei > > > -- > Dr. Geo > http://drgeo.eu > > >
Re: [Pharo-dev] [QA] Debugger buttons explained
Ok, give a look to SpecDebugActionButton, this class has no user, only progma reference, not easy to track the logic. Never mind I test on a halt in its #update method. Nothing happen when opening the debugger. May be there is instance in memory, no idea under which name it is referenced, may be not. Inspecting the debugger window does not help, it is a kind of generic morph. Never mind, can try to look at the menu item "Debug it" in the playground window, I used to find the action there. Oops, get lost there, I see #debugSelection looks promising, see announcement. Get lost again. No idea, someone else should put these tooltips in the appropriate place. Le 06/02/2017 à 21:14, Hilaire a écrit : > No user of actionType, but I guess user or pragma, how do you guys track > the logic from here -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] [QA] Debugger buttons explained
How about... Into Step into the highlighted message, i.e. dive the debugger into the method which handles it Over Step over the highlighted message, i.e. execute it, but keep the debugger focused on the current method Through Like stepping "Over", except step through block contents when executed Restart Rewind to the start of the current execution context, resetting all local variables Continue Relinquish debugger control and proceed with normal execution - Cheers, Sean -- View this message in context: http://forum.world.st/QA-Debugger-buttons-explained-tp4933212p4933238.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] [QA] Debugger buttons explained
Thanks for the updated message. Le 06/02/2017 à 19:39, Sven Van Caekenberghe a écrit : > That last one is not correct. It has nothing to do with specific iteration > selectors. It means: stop when execution returns in one of the argument > blocks. It also works for #on:error: #streamContents: or any other message > that accepts blocks as argument - which is pretty cool. Strangely step over does not step in the bloc with #do: but does with #to:do: In the later case step over and through behave mostly the same, the stack looks a bit different though. Another question, I try to locate where the tooltips are set in the debugger. I can't find it with traditional browser tools (send, class use) and the finder: The finder tells me "Through" is used in SpecThroughDebugAction, but browser tells me there is no use case of this class. I see some pragma in class side method, did it... actionType No user of actionType, but I guess user or pragma, how do you guys track the logic from here -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
First, thanks for the discussion, I think this is good.
The idea/reason behind NeoUUIDGenerator was to get an algorithm that is fully
documented and clearly implemented with proper unit tests, all at the Smalltalk
level, so that we can get rid of the plugin.
> On 6 Feb 2017, at 18:54, Peter Uhnak wrote:
>
> 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.
That is a bug. Either the documentation has to be changed, but more likely the
implementation.
The idea behind the old, simple Session object was crystal clear: create a new,
unique (in the sense of #==) Session object on each run of an image (and not
when saving).
WorkingSession got more complicated and less clear. People seem to have
different expectations from it, and we keep on having trouble with it, which
are not a good signs.
Your point (3) also indicates and important issue in division of responsibility.
> 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 find that quite hard to believe and I did not know that. Are you really sure
? That would be terrible. A solution might be to use another clock primitive.
> 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.
I can't follow your reasoning here: if the clock precision would be 1 second,
you would get 1.2M consecutive UUIDs with the same clock value, right ?
In the unit tests this is verified (that the time value goes forward on
consecutive calls).
> 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. :)
Yes, the clock + the counter + the machine id + random (this is a described in
detail in the class comment of NeoUUIDGenerator).
> You are also taking 8 bytes of microsecondClockValue, but the value has only
> 7 bytes... so 8th byte is fixed to 0.
True.
> 9 & 10 bytes are counter, but 9th bit is rewritten with variant, so the
> counter is actually 0-255 and not 0-65536.
Yes, but more correctly, the top 2 bits are set to 10, making the range 1 to
2^14 (16384) (instead of 2^16).
> And finally 11 & 12 are random bits (assuming the seeding isn't broken).
The seeding is one aspect (the quality of the seed), the algorithm is another.
Note that in the current Random class, the seed is initialised using the clock
as well.
> 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).
I am pretty/quite sure this is not correct but it would take me much more time
to come up with a more correct calculation.
BTW, you also have to define the context of being the same: the same instance
of one NeoUUIDGenerator generating the same UUID, or several different
generator instances, in the same image, in different images, on different runs,
the same or different machines/networks, ...
> 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).
Same remark as above.
> 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.
But that is not proper use of a random generator, you create a new instance
every time. You basically test seeding, which is different from random number
generator proper.
It seems that is a chicken-egg problem too ;-)
BTW, you can currently provide your own seed too, for example:
Random seed: ('/dev/random' asFileReference binaryReadStreamDo: [ :in | in
next: 4 ]) asInteger.
> 3. Chicken and egg question
>
> How would one bootstrap session's id initialized with just NeoUUID? :)
> (Work
[Pharo-dev] Segmentation fault while installing Scale
Hi all! While executing the following command: $ wget -O- https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh | sudo bash > stderr.log I got the Segmentation fault error. You can see it in the contents of stderr.log which is attached to the email. Here you can see the output of the mentioned command: ``` --2017-02-03 19:35:16-- https://raw.githubusercontent.com/guillep/Scale/master/setupScale.sh Resolving raw.githubusercontent.com... 151.101.128.133, 151.101.192.133, 151.101.64.133, ... Connecting to raw.githubusercontent.com|151.101.128.133|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1021 [text/plain] Saving to: ‘STDOUT’ - 100%[=>] 1021 --.-KB/sin 0s 2017-02-03 19:35:16 (274 MB/s) - written to stdout [1021/1021] Cloning into '/tmp/scale'... remote: Counting objects: 1457, done. remote: Total 1457 (delta 0), reused 0 (delta 0), pack-reused 1457 Receiving objects: 100% (1457/1457), 656.60 KiB | 714.00 KiB/s, done. Resolving deltas: 100% (799/799), done. Note: checking out 'f70fdb90cf66d443140b6fe84cad9848163bf32e'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b --2017-02-03 19:35:18-- http://get.pharo.org/50+vm Resolving get.pharo.org... 128.93.162.72 Connecting to get.pharo.org|128.93.162.72|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2901 (2.8K) [text/html] Saving to: ‘STDOUT’ - 100%[=>] 2.83K --.-KB/sin 0.001s 2017-02-03 19:35:18 (3.56 MB/s) - written to stdout [2901/2901] Downloading the latest 50 Image: http://files.pharo.org/get-files/50/pharo.zip Downloading the latest pharoVM: http://files.pharo.org/get-files/50/pharo-linux-stable.zip Downloading PharoV50.sources: http://files.pharo.org/get-files/50/sources.zip Creating starter scripts pharo and pharo-ui Fetched -> BaselineOfScale-SantiagoBragagnolo.4 --- filetree:///tmp/scale/src [:] --- filetree:///tmp/scale/src./pharo: line 11: 19176 Aborted "$DIR"/"pharo-vm/pharo" --nodisplay "$@" Syntax Error on line 26: 'Unmatched '' in string literal. ->' = 01: | scapeParentDirectory pharoParentDirectory scaleX scaleuiX | 02: 03: system stdout << 'Uninstalling scale' << String cr. 04: 05: system saveImageAs: #/ asFileReference / #tmp / #'uninstall.image'. 06: " The image must be stored elsewhere for deleting all the files " 07: 08: scaleX := '/usr/local/bin/scale' asFileReference. 09: scaleX exists ifTrue: [ system call: ' rm ', scaleX fullName ]. 10: system stdout << 'Uninstalling executable scale' << String cr ; flush. 11: 12: scaleuiX:='/usr/local/bin/scale-ui' asFileReference. 13: scaleuiX exists ifTrue: [ system call: ' rm ', scaleuiX fullName ]. 14: system stdout << 'Uninstalling executable scale-ui' << String cr ; flush. 15: 16: scapeParentDirectory := '/usr/local/scale' asFileReference. 17: pharoParentDirectory := '/usr/local/pharo' asFileReference. 18: 19: scapeParentDirectory exists ifTrue: [ system call: ' rm -rf ', scapeParentDirectory fullName ]. 20: system stdout << 'Removing scale folder' << String cr ; flush. 21: 22: pharoParentDirectory exists ifTrue: [ system call: ' rm -rf ', pharoParentDirectory fullName ]. 23: system stdout << 'Removing pharo folder' << String cr ; flush. 24: 25: 26: system stdout << 'Done _^_ Syntax Error on line 39: 'Unmatched '' in string literal. ->' = 01: | scaleParentDirectory scaleFile scaleUIFile pharoParentDirectory| 02: 03: " DEPLOY " 04: system stdout << 'Deploying scale command';cr. 05: 06: scaleParentDirectory := '/usr/local/scale' asFileReference. 07: 08: scaleParentDirectory exists 09: ifTrue: [ 10: system stderr << 'There is already an installation. Please uninstall before' 11: ] ifFalse: [ 12: scaleParentDirectory ensureCreateDirectory. 13: scaleFile := scaleParentDirectory / 'scale'. 14: scaleUIFile := scaleParentDirectory / 'scale-ui'. 15: system workingDirectory / '..' / 'scale' copyTo: scaleFile. 16: system workingDirectory / '..' / 'scale-ui' copyTo: scaleUIFile. 17: system workingDirectory / '..' / #build / 'uninstall.st' copyTo: scaleParentDirectory / 'uninstall.st'. 18: system stdout << 'Deploying Pharo';cr. 19: 20: pharoParentDirectory := '/usr/local/pharo' asFileReference. 21: pharoParentDirectory ensureCreateDirectory. 22: #( 'pharo' 'pharo-vm' 'pharo-ui') 23: do: [ :file | system workingDirectory / file c
Re: [Pharo-dev] [QA] Debugger buttons explained
> On 6 Feb 2017, at 18:55, Hilaire wrote: > > How will you describe these buttons in the debugger? > Here are proposals for tooltips, please fix it, I am sure there are > better way to write it. > > Proceed > Quit the debugger and resume the execution of the method. > > Restart > Reset the local variable and restart stepping at the beginning of the > method. > > Into > Step in the highlighted message, i.e. follow the sent message in its method. > > Over > Execute the highlighted message, i.e. do not follow the sent message in > its method. > > Through > Execute the highlighted message, when argument is a bloc to #do:, > #collect:, #select: #detect: step in the bloc. That last one is not correct. It has nothing to do with specific iteration selectors. It means: stop when execution returns in one of the argument blocks. It also works for #on:error: #streamContents: or any other message that accepts blocks as argument - which is pretty cool. Consult DebugSession for good descriptions of the actions. This is my version/take, probably not perfect either. Into Step in the highlighted message, i.e. follow the sent message, taking debugger control in the method invoked. Over Step over the highlighted message, i.e. do not follow the sent message, taking debugger control after the method invoked returns. Through Step over the highlighted message, i.e. do not follow the sent message, taking debugger control after the method invoked returns or whenever execution should return inside a block used as an argument before that. Restart Go back the start of the current execution context, resetting all local variables and take debugger control. Continue Relinquish debugger control and proceed execution from the current point of debugger control. > https://pharo.fogbugz.com/f/cases/19654/Tooltips-with-description-of-the-over-and-through-debugger-buttons-actions > > -- > Dr. Geo > http://drgeo.eu > >
[Pharo-dev] Debugger hang when step throught
Hello, The faulty code bellow when debugged and 'step through' cause the debugger to hang: self inform: '1'. #(2 3 4) select: [:i| i] thenDo: [:n| self inform: n printString ]. self inform: '5'. It seems trapped in an infinite loop, you can more or less get control back with Alt+[.] When step in, the debugger properly report the error. Pharo #60362. I did not see similar bug report, shall I? -- Dr. Geo http://drgeo.eu
[Pharo-dev] [QA] Debugger buttons explained
How will you describe these buttons in the debugger? Here are proposals for tooltips, please fix it, I am sure there are better way to write it. Proceed Quit the debugger and resume the execution of the method. Restart Reset the local variable and restart stepping at the beginning of the method. Into Step in the highlighted message, i.e. follow the sent message in its method. Over Execute the highlighted message, i.e. do not follow the sent message in its method. Through Execute the highlighted message, when argument is a bloc to #do:, #collect:, #select: #detect: step in the bloc. https://pharo.fogbugz.com/f/cases/19654/Tooltips-with-description-of-the-over-and-through-debugger-buttons-actions -- Dr. Geo http://drgeo.eu
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
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 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 > >
Re: [Pharo-dev] Pharo 60 need help white-theme-color-for-button-is-not-good
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-in-line-with-the-times Same for those ugly flat scrollbars. https://pharo.fogbugz.com/f/cases/13136/Pharo3Theme-scrollbars-looking-like-dead-without-visual-indicators 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 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. >
Re: [Pharo-dev] Pharo 60 need help on Red-in-Dark-Theme-is-plain-bad
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 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. >
Re: [Pharo-dev] Pharo 60 need help on When-coding-in-the-debugger-I-get-an-error-sourceNodeExecuted
Fixed 2017-02-06 17:55 GMT+01:00 Stephane Ducasse : > 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…. >
[Pharo-dev] Pharo 60 needs help on ooltips-of-the-class-button-does-not-changed
If you want to help pharo: https://pharo.fogbugz.com/f/cases/19659/Tooltips-of-the-class-button-does-not-changed
Re: [Pharo-dev] Seamless Error in GT-Inspector
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.
[Pharo-dev] Pharo 60 need help white-theme-color-for-button-is-not-good
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.
[Pharo-dev] Pharo 60 needs help on Broken-syntax-highlithing
I'm giving some lectures to siemens engineers and we found glitches. (bad impression). https://pharo.fogbugz.com/f/cases/19656/Broken-syntax-highlithing
[Pharo-dev] Pharo 60 needs help on shortcuts-are-wrongly-displayed
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.
[Pharo-dev] Pharo 60 need help on Red-in-Dark-Theme-is-plain-bad
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.
[Pharo-dev] Pharo 60 need help on When-coding-in-the-debugger-I-get-an-error-sourceNodeExecuted
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….
Re: [Pharo-dev] Seamless Error in GT-Inspector
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 : > 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. > >
Re: [Pharo-dev] Pharo 6 update catalog entries
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.
Re: [Pharo-dev] Seamless Error in GT-Inspector
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.
Re: [Pharo-dev] [QA] quality assurance
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.
Re: [Pharo-dev] Esteban's ChangeLog week of 30 January 2017
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-tp4933097p4933165.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
> On 6 Feb 2017, at 15:21, Yuriy Tymchuk 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 wrote: >> >> >>> On 6 Feb 2017, at 14:17, Yuriy Tymchuk 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 >> >> >> >> >> > >
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
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 wrote: > > >> On 6 Feb 2017, at 14:17, Yuriy Tymchuk 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 > > > > >
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
> On 6 Feb 2017, at 14:51, Peter Uhnak 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 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 >> >> >> >> >> >
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
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 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 > > > > >
Re: [Pharo-dev] WorkingSession UUID looks "sketchy"
> On 6 Feb 2017, at 14:17, Yuriy Tymchuk 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
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/60375 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] 394af1: 60375
Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 394af1e72e16fd07e051c527b87418e41e00b848 https://github.com/pharo-project/pharo-core/commit/394af1e72e16fd07e051c527b87418e41e00b848 Author: Jenkins Build Server 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
[Pharo-dev] WorkingSession UUID looks "sketchy"
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
[Pharo-dev] [pharo-project/pharo-core] 1ef999: 60374
Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 1ef999f0f762ee205eee21501a8001ca63416aaa https://github.com/pharo-project/pharo-core/commit/1ef999f0f762ee205eee21501a8001ca63416aaa Author: Jenkins Build Server Date: 2017-02-06 (Mon, 06 Feb 2017) Changed paths: R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60373.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60374.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60373.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60374.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Tools.package/MessageBrowser.class/instance/private/methodClassNameForItem_.st A Spec-Tools.package/MessageBrowser.class/instance/private/packageNameForItem_.st A Spec-Tools.package/MessageBrowser.class/instance/private/protocolNameForItem_.st M Spec-Tools.package/MessageBrowser.class/instance/private/wrapItem_.st A Tool-FileList.package/FileList.class/instance/accessing/contents.st R Tool-FileList.package/FileList.class/instance/private/contents.st M Tool-FileList.package/FileList.class/instance/private/selectedDirectory_.st Log Message: --- 60374 18783 FileList: selected directory is changed after selecting a different folder https://pharo.fogbugz.com/f/cases/18783 18699 MessageBrowser>>#wrapItem: may send #name to nil, raising Deprecated https://pharo.fogbugz.com/f/cases/18699 http://files.pharo.org/image/60/60374.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/60374 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] Esteban's ChangeLog week of 30 January 2017
Hello! This is my weekly ChangeLog, from 30 January 2017 to 5 February 2017. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=30/1/2017&to=5/2/2017 ChangeLog = 3 February 2017: *Still on [iceberg](https://github.com/npasserini/iceberg), this time I addresed two issues: * [issue 269](https://github.com/npasserini/iceberg/issues/269), which is an improvement on the way we visualise trees (showing just those that have changes, this is very important in big repositories) * [issue 270](https://github.com/npasserini/iceberg/issues/270), which addreses a problem I left there when working on multi-remotes: it was showing incorrect data between the real outgoing commits and the ones shown in the browser. I made a couple of pull requests with them (yep, still using the plugin I developed yesterday :P) 2 February 2017: *I spent last two days working on adapt [Iceberg](https://github.com/npasserini/iceberg) infrastructure to accept plugins. Well... not totally true. What in fact I made was to *start* to program a way to add plugins, which for now are just allowed in repositories pane on repositories browser. But well, the rudiments are there. What actually took most of my time was the development of the first plugin (you know, I do not believe too much on "developments in abstract", I need concrete cases to test my ideas): an Pull Request creator. With this, you can do from iceberg the same kind of work you do in github web page :) So, now you can have a beutiful pull request dialog, along with several validations... Now, you may wonder why I needed to develop such kind of tool (after all, you can always go to the web page and do the same). And the answer is that in the new process we are starting to create for Pharo, we need to be able to do things like: . create a fix . create a branch from pharo-core sources, named for example issue-12345 (something that would usually belong to a SLICE) . sends commits to that branch while working on the issue . send a Pull Request of the issue (what now is to commit the SLICE to inbox and changing status on the bug tracker) so, to make this process easy, we need to be able to complete the full cycle from Pharo, exactly as we do it now. Pull Requests are a necessary step to fulfill this requirement. 31 January 2017: *Working on [iceberg](https://github.com/npasserini), I fixed a bug that happened when trying to clone a recently created repository (without branchs yet). cheers! Esteban
