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

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

by Sven Van Caekenberghe

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

Feb. 6, 2017

[pharo-project/pharo-core]

by GitHub

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

Feb. 6, 2017

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

by GitHub

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

Feb. 6, 2017

WorkingSession UUID looks "sketchy"

by Yuriy Tymchuk

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

Feb. 6, 2017

[pharo-project/pharo-core]

by GitHub

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

Feb. 6, 2017

[pharo-project/pharo-core] 1ef999: 60374

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 1ef999f0f762ee205eee21501a8001ca63416aaa https://github.com/pharo-project/pharo-core/commit/1ef999f0f762ee205eee2150… Author: Jenkins Build Server <board(a)pharo-project.org> 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

Feb. 6, 2017

Esteban's ChangeLog week of 30 January 2017

by estebanlm＠gmail.com

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

Feb. 6, 2017

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

by serge.stinckwich＠gmail.com

Great ! Thank you Hilaire. I will help when I'm free. EnvoyÃ© de mon iPhone > Le 6 fÃ©vr. 2017 Ã 00:38, Ben Coman <btc(a)openinworld.com> a Ã©crit : > >> On Mon, Feb 6, 2017 at 4:51 AM, Hilaire <hilaire(a)drgeo.eu> wrote: >> Hi, >> >> I discussed briefly with Steph about QA team and dedicated mailing list. >> He proposed to just use the @devel list with an appropriate [QA] tag, so >> every one can participate or just discard the topic without too much noise. > > That seems appropriate. > A separate list makes it hard to draw new people in to help. > And part of the discussion can occur on the Fogbugz. > > cheers -ben >

Feb. 6, 2017

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

by Ben Coman

On Mon, Feb 6, 2017 at 4:51 AM, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > I discussed briefly with Steph about QA team and dedicated mailing list. > He proposed to just use the @devel list with an appropriate [QA] tag, so > every one can participate or just discard the topic without too much noise. That seems appropriate. A separate list makes it hard to draw new people in to help. And part of the discussion can occur on the Fogbugz. cheers -ben

Feb. 5, 2017

Re: [Pharo-dev] PharoLauncher Hanging

by Ben Coman

On Mon, Feb 6, 2017 at 1:52 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Sean P. DeNigris wrote >> I just had Launcher hang (Mac's spinning beach ball of death) twice in a >> row after launching a 5.0 image with "quit on launch" disabled. > > Still happening fairly regularly. Pretty disruptive. I can't discern a > particular pattern. No Debug log or crash dump. I leave "quit on launch" > disabled because it seems that it's the only way to open multiple images > simultaneously because Luncher will not start on Mac if there is another > Pharo image running. Anyone else? This triggers a vague memory from a while ago (I haven't been on osx for a year). Try making sure that PharoLauncher is the first VM to open. If an other Images are open, close them all before opening PharoLauncher. And check your process list. cheers -ben

Feb. 5, 2017