December 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]
by GitHub Dec. 12, 2016

Dec. 12, 2016

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

1 0

[pharo-project/pharo-core] 2da393: 50765
by GitHub Dec. 12, 2016

Dec. 12, 2016

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 2da393a0b6aa8f06137bbfb92b7d35b0c02a8c30 https://github.com/pharo-project/pharo-core/commit/2da393a0b6aa8f06137bbfb9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-12-12 (Mon, 12 Dec 2016) Changed paths: M Kernel.package/Delay.class/class/settings/delaySchedulerClass_.st A Kernel.package/ManifestKernel.class/class/code-critics/ruleRBBadMessageRuleV1FalsePositive.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50764.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50765.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50764.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50765.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50765 19435 Silently ignore loading DelayScheduler setting when its the same as existing (Pharo 5 backport) https://pharo.fogbugz.com/f/cases/19435 http://files.pharo.org/image/50/50765.zip

1 0

Set internal array size
by Christophe Demarey Dec. 12, 2016

Dec. 12, 2016

Hi, I just discovered a funny thing. If you create a Set with Set new, you will get a Set with an internal array of 5 elements (hardcoded in Set class>>#new). If you ask explicitly a Set for one or no element: Set new: 0 (or a number between 0 and 5), you will get an internal array of 7 elements. This behavior is a bit strange. Either we always need at least 7 elements and we need to update Set class>>#new, either the method Set class>>#sizeFor: should be updated. WDYT? Christophe

4 9

[pharo-project/pharo-core]
by GitHub Dec. 12, 2016

Dec. 12, 2016

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

1 0

[pharo-project/pharo-core] ed3ccb: 60324
by GitHub Dec. 12, 2016

Dec. 12, 2016

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: ed3ccb853824ab06940808cd93e649394b2bbec8 https://github.com/pharo-project/pharo-core/commit/ed3ccb853824ab06940808cd… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-12-12 (Mon, 12 Dec 2016) Changed paths: M AST-Core.package/RBArrayNode.class/instance/matching/match_inContext_.st M AST-Core.package/RBPatternVariableNode.class/instance/accessing/parent_.st A AST-Tests-Core.package/RBParseTreeSearcherTest.class/instance/tests - to de refined/testDynamicArrayWithStatementListPattern.st A Reflectivity-Tests.package/ReflectivityExamples.class/instance/examples/exampleSendNoReturn.st A Reflectivity-Tests.package/ReflectivityReificationTest.class/instance/tests - sends/testReifyReceiverOnSendWithArguments.st M Rubric.package/RubTextSegmentIconDisplayer.class/instance/event handling/invokeIconMenuOfSegments_event_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60323.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60324.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60323.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60324.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60324 19445 Pattern code ArrayNode matching failure https://pharo.fogbugz.com/f/cases/19445 18935 Rubric warning are not DarkTheme friendly https://pharo.fogbugz.com/f/cases/18935 19455 Testcase for reify receiver for before links https://pharo.fogbugz.com/f/cases/19455 http://files.pharo.org/image/60/60324.zip

1 0

Crash.dmp not created on windows
by Blondeau Vincent Dec. 12, 2016

Dec. 12, 2016

Hello, Since the release of the spur vm, the crash dump file (crash.dmp) is not generated when the image crashes under Windows (7 especially). Now, I have an image I cannot use because its crashed at startup and I cannot report a bug to VM developers in the purpose to resolve the crash. An issue on this has been opened almost for one year: https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-f… Does the creation of this crash.dmp is planned? Thanks in advance, Cheers, Vincent !!!************************************************************************************* "Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

1 0

REMEMBER: Tomorrow 13/12 16h UTC TechTalk featuring Iceberg by Nico Passerini
by Esteban Lorenzano Dec. 12, 2016

Dec. 12, 2016

Hi, Everything is in the subject :) Tomorrow we will handle a new TechTalk, this time to talk about Iceberg, the new SCM tool for Pharo. Since Nico will to also a âtourâ about what is implemented and how we expect the tool will be used, this time we will try to stream a public stream so people can watchâ¦ and participation, questions, etc. will be handled through discord, as usual. I will send links to both video and discord as soon as we have it :) cheers, Esteban

1 0

About traits
by Stephane Ducasse Dec. 12, 2016

Dec. 12, 2016

Dale I missed your remark about traits. I think that traits are nice because they act as a kind of static macro expansion and really help to get multiple inheritance into single one. Now ideally I would like to have

5 8

protocol pane "no messages" Re: [Pharo-users] setter method
by Ben Coman Dec. 11, 2016

Dec. 11, 2016

[Forwarded to pharo-dev for side discussion...] On Sat, Dec 10, 2016 at 2:15 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Sat, Dec 10, 2016 at 1:39 AM, Kateryna Aloshkina > <aloshkina(a)ucu.edu.ua> wrote: >> Hi everybody! >> >> I've just joined the community:) and have a question >> How to write the method count: such that, when invoked on an instance of >> Counter, instance variable is set to the argument given to the message? >> so that >> Counter new count: 7 >> would set the value of a new Counter instance to 7 >> (It is a little exercise from >> http://rmod-pharo-mooc.lille.inria.fr/MOOC/Exercises/Exo-Counter.pdf) >> >> >> Best wishes, >> Kateryna > > Welcome Kateryna, > I hope you are having fun and Pharo changes the way you think about programming. > > Referring to Figure 1.2, assuming you've already created the class, > first make sure you are on the instance-side rather than the class-side > of the class such that the class definition in the bottom (code) pane > looks just like Figure 1.2. Click the <Class> button to toggle which > side you look at. > > Now in the third (protocols) pane on "no messages" > and you will get a method template in the code pane > > Change... messageSelectorAndArgumentNames > to... count: > > then change.... statements > to an assignment to the instance variable. > and <Accept> the the code to save & compile the method. To be pedantic, shouldn't "no messages" actually be "no methods" But maybe even better would be... "click for method template" ? cheers -ben

4 5

NeoUUIDGenerator>>testTwoSameGenerator - intermittent CI failure
by Ben Coman Dec. 11, 2016

Dec. 11, 2016

For Case [1] I got an unrelated CI failure [2] for NeoUUIDGeneratorTests>>#testTwoSameGenerator Checking this locally by running this a dozen times... 1 to: 1000 do: [:n| last:=n. NeoUUIDGeneratorTests new setUp testTwoSameGenerator ] Two distinct failures are apparent... 1. Takes longer than expected. self assert: (time2 - time1) abs < 100 last=1 ==> a time difference of 109 last=1 ==> a time difference of 102 last=1 ==> a time difference of 155 last=1 ==> a time difference of 105 Interesting that whenever this happens its on the first iteration. 2. Invalid consecutive ids. self assert: (uuid1 at: 10) + 1 equals: (uuid2 at: 10). last=127 ==> TestFailure: Got 256 instead of 0. last=828 ==> TestFailure: Got 256 instead of 0. last=128 ==> TestFailure: Got 256 instead of 0. last=316 ==> TestFailure: Got 256 instead of 0. Maybe a problem with rollover? So instrumenting a bit: testTwoSameGenerator: n | uuid1 uuid2 consecutiveOk time1 time2 timeOk | .... "same generator, consequetive counters" consecutiveOk := ((uuid1 at: 10) + 1) = (uuid2 at: 10). "same generators, similar clock, within 100 milliseconds" time1 := self timeFromUUID: uuid1. time2 := self timeFromUUID: uuid2. timeOk := (time2 - time1) abs < 100. ( timeOk and: [ consecutiveOk ]) ifFalse: [ Transcript cr; show: 'fail n=', (n printPaddedWith: $0 to: 3) ; tab; show: ' time ', ((time2 - time1) printString) , '<100'; tab; show: ' uuid ', (((uuid1 at: 10) + 1) printString, '=', (uuid2 at: 10) printString). ]. self assert: consecutiveOk. self assert: timeOk. >From playground running... 1 to: 1000 do: [:n| NeoUUIDGeneratorTests new setUp testTwoSameGenerator: n]. Transcript crShow: 'x'. Note the 'x' was not output due to one of the consecutiveOk or timeOk asserts triggered each run. fail n=001 time 104<100 uuid 160=160 fail n=269 time 2<100 uuid 256=0 fail n=001 time 152<100 uuid 166=166 fail n=117 time 3<100 uuid 256=0 fail n=001 time 123<100 uuid 128=128 fail n=278 time 3<100 uuid 256=0 fail n=001 time 145<100 uuid 230=230 fail n=673 time 1340<100 uuid 141=141 fail n=707 time 3<100 uuid 256=0 fail n=001 time 132<100 uuid 73=73 fail n=001 time 117<100 uuid 206=206 fail n=063 time 2<100 uuid 256=0 fail n=345 time 3<100 uuid 256=0 Now a strange thing is that after commenting out those two asserts for consecutiveOk and timeOk, the fails at n=001 stop happening. fail n=001 time 141<100 uuid 232=232 x x fail n=201 time 3<100 uuid 256=0 fail n=268 time 3<100 uuid 256=0 fail n=359 time 3<100 uuid 256=0 fail n=408 time 2<100 uuid 256=0 fail n=559 time 3<100 uuid 256=0 x fail n=139 time 3<100 uuid 256=0 fail n=854 time 7<100 uuid 256=0 x fail n=389 time 3<100 uuid 256=0 fail n=669 time 3<100 uuid 256=0 fail n=876 time 3<100 uuid 256=0 fail n=916 time 3<100 uuid 256=0 fail n=953 time 2<100 uuid 256=0 fail n=954 time 3<100 uuid 256=0 x fail n=148 time 3<100 uuid 256=0 fail n=741 time 3<100 uuid 256=0 x fail n=116 time 2<100 uuid 256=0 fail n=480 time 3<100 uuid 256=0 x After treating the rollover like this... consecutiveOk := ((uuid1 at: 10) + 1) \\ 256 = (uuid2 at: 10). running the last playground script gives... (Note the n=001 fail reoccurs after waiting a while between running the playground script again.) fail n=001 time 123<100 uuid 110=110 x fail n=345 time 1287<100 uuid 24=24 fail n=404 time 1313<100 uuid 125=125 x x x x x fail n=449 time 1290<100 uuid 24=24 x x x x x Thats looking better, so upping to 10000 iterations... fail n=0001 time 151<100 uuid 160=160 fail n=2977 time 1437<100 uuid 221=221 fail n=5498 time 1454<100 uuid 224=224 fail n=9007 time 1351<100 uuid 239=239 x fail n=3389 time 1381<100 uuid 223=223 fail n=7768 time 1365<100 uuid 82=82 fail n=9773 time 1395<100 uuid 164=164 x fail n=3325 time 1448<100 uuid 67=67 fail n=9930 time 1456<100 uuid 103=103 x fail n=0060 time 2914<100 uuid 159=159 fail n=1829 time 1438<100 uuid 32=32 fail n=7918 time 1436<100 uuid 182=182 x So the rollover looks cured. Now adding some more instrumentation to view GC Time and Time To Run and (see attached ST file) 0:00:00:00 TTR 0:00:00:00.001 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 TTR 0:00:00:00 x fail n=0001 time 115<100 uuid 157=157 GCTime 0 TTR 0:00:00:00 fail n=0001 time 2<100 uuid 255=0 GCTime 0 TTR 0:00:00:00 x fail n=0001 time 111<100 uuid 104=104 GCTime 0 TTR 0 x fail n=0001 time 120<100 uuid 204=204 GCTime 0 TTR 0 fail n=0001 time 1182<100 uuid 103=103 GCTime 1 TTR 1 x x x x x fail n=0001 time 3<100 uuid 255=0 GCTime 0 TTR 0 x x fail n=0001 time 1251<100 uuid 253=253 GCTime 2 TTR 1 x Now I wonder at the class comment saying... "the first 8 bytes are the *millisecond* clock value" but #clockOn: is using *microsecond* clock. Perhaps "self assert: (time2 - time1) abs < 100" is meant to be 100ms not 100us ?? cheers -ben [1] https://pharo.fogbugz.com/f/cases/19438 [2] https://ci.inria.fr/pharo/job/Pharo-6.0-Issue-Validator/19471//artifact/val…

3 5