May 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=ma… 1 regressions found. Tests.Release.ReleaseTest.testUndeclared

May 2, 2013

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=wi… 1 regressions found. Tests.Release.ReleaseTest.testUndeclared

May 2, 2013

[Pharo-project] [regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 2 regressions found. Tests.Release.ReleaseTest.testObsoleteBehaviors Tests.Release.ReleaseTest.testUndeclared

May 2, 2013

[Pharo-project] [update 3.0] #30081

by Marcus Denker

[update 3.0] #30081 30081 ----- 10462 Add SpecModel for NewList https://pharo.fogbugz.com/f/cases/10462 10468 More Decompiler related cleanups https://pharo.fogbugz.com/f/cases/10468 Diff information: http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Tools-MarcusDenker.1096 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Widgets-MarcusDenker.132 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/Spec-Tools-MarcusDenker.99 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/KernelTests-MarcusDenker.499 http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/CompilerTests-MarcusDenker.1… http://smalltalkhub.com/#!/~Pharo/Pharo30/diff/AST-Interpreter-Extension-Ma…

May 2, 2013

[Pharo-project] How i can retrieve the global by its name?

by Igor Stasenko

Hi, all do not think that i am drunk or vent crazy, asking such silly question, which at best should be asked only by beginner :) I know the answer: Smalltalk at: #SomeName or Smalltalk globals at: #SomeName what stroke me, just now, that both answers is wrong! It should be: #SomeName asGlobal (or suggest more appropriate/precise method name for a symbol) optionally, we could also have one, with handling absent case: #SomeName asGlobalIfAbsent: [] same , but only if present: #SomeName asGlobalIfPresent: [:global | ] Currently, there is 941 references to 'Smalltalk' global in my pharo image. If we introduce this convenience method, it will shrink this number considerably, not saying that code will be more elegant and concise compare: (Smalltalk globals at: #Foo) doSomething and #Foo asGlobal doSomething P.S. What really strikes me is why we don't have such method from very beginning, and instead refer to 'Smalltalk' all over the places. Some things are so deeply indoctrinated in our minds, that we don't even think that it can be different. -- Best regards, Igor Stasenko.

May 2, 2013

Re: [Pharo-project] Issue ML doesn't thread

by Sean P. DeNigris

Camillo Bruni-3 wrote > and also upvote here! > ... >> upvote here: Done, and done. Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-ML-doesn-t-thread-tp4684851p4684888.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 2, 2013

Re: [Pharo-project] record system change

by Igor Stasenko

On 1 May 2013 10:26, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I am not really interested in conceptual ideas (with those I can come up anytime I want). > I want an actual solution as an answer to my stackoverflow question with > code that works ;) > my answer is as general as your question. you asked how you can _reliably_ capture changes in various objects in system: methods, classes, packages, i answered. what you expected? this: SystemAnnouncer uniqueInstance on: SystemAnnouncement send: #somethingChanged to: mylogger. ? > > On 2013-05-01, at 03:31, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> Ane of the idea is to use serialization, but with custom strategy. >> Since we're in living system, each object can know the answer to question >> whether it is important to capture it's changes or not. >> As well, as it can instruct serializer, what part(s) of its state >> needs to be serialized and which not.. >> This will give us the filtering rules out of the box. >> >> But still it won't give us an automagic way to represent changes in >> human-readable form, e.g: >> >> diff := someObject createTextualDiff: myPreviousSerializedVersion. >> >> well, unless you serialize textual forms of both objects .e.g: >> >> diff := someObject sufficientTextualForm createTextualDiff: >> myPreviousSerializedVersionSufficientTextualForm. >> >> (the bad part of it that it is quite difficult to represent arbitrary >> graph with possible cycles in human-readable textual form ;) >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.

May 2, 2013

Re: [Pharo-project] Issue ML doesn't thread

by Camillo Bruni

and also upvote here! http://fogbugz.stackexchange.com/questions/2961/fogbugz-should-match-in-rep… On 2013-05-02, at 01:05, Camillo Bruni <camillobruni(a)gmail.com> wrote: > upvote here: > > http://fogbugz.stackexchange.com/questions/2527/feature-request-include-in-… > > On 2013-05-01, at 22:24, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> This is kind of a small thing, but it definitely effects readability... Each >> issue update shows up as a whole different conversation, while when we used >> google, they were properly organized. Any idea how (if possible) to fix it? >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Issue-ML-doesn-t-thread-tp4684851.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >

May 1, 2013

Re: [Pharo-project] Issue ML doesn't thread

by Camillo Bruni

upvote here: http://fogbugz.stackexchange.com/questions/2527/feature-request-include-in-… On 2013-05-01, at 22:24, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > This is kind of a small thing, but it definitely effects readability... Each > issue update shows up as a whole different conversation, while when we used > google, they were properly organized. Any idea how (if possible) to fix it? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Issue-ML-doesn-t-thread-tp4684851.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 1, 2013

Re: [Pharo-project] Playing with Opal AST->BC Translator

by StÃ©phane Ducasse

Nicolas I'm convinced marcus and clement will be definitively interested! Open tickets :). Opal is not fully polished yet. It has a nice skeleton but requires more love to really shine. This is great that it was pushed in Pharo so that we can all have a look. For us this is the infrastructure for a new generation open-compiler so this is nice to hear that from you. :) Stef > Opal is fun. > I have a few simplifications to propose for the AST->BC OCASTTranslator > > 1) instead of testing isEffectTranslator or refining in subclass, most often we could just let self visit the node. Indeed, self will already be either a Translator ForEffect or ForValue. > > For example, this could apply to emitIfFalseIfTrue: emitIfNilIfNotNil: visitCascadeNode: > > This might also remove a few useless pushNil; pop BC sequences. > > > 2) I think we can simplify the #visitBlockNode: / #visitSequenceNode: pair. > > Indeed, visitSequenceNode: tests if its parent isBlock, and if so will emitValue, else emitEffect. > Inversely visitBlockNode: always ask to emitEffect, but since it contains a SequenceNode, this is a big lie. > > I suggest to always let the valueTranslator emitValue visitBlockNode: and simplify #visitSequenceNode: to just let (self visitNode: statements last). > > > 3) I suggest changing the BC generated for or: and and: > > instead of: > > valueTranslator visitNode: aMessageNode receiver. > methodBuilder > jumpAheadTo: #else if: false; > pushLiteral: true; > jumpAheadTo: #end; > jumpAheadTarget: #else. > valueTranslator visitInlinedBlockNode: aMessageNode arguments first. > methodBuilder jumpAheadTarget: #end. > > We could just use dup and thus remove a jump: > > valueTranslator visitNode: aMessageNode receiver. > methodBuilder > pushDup; > jumpAheadTo: #end if: true; > popTop. > self visitInlinedBlockNode: aMessageNode arguments first. > methodBuilder jumpAheadTarget: #end. > > ForEffect, this would just be > > self emitIfFalse: aMessageNode > > Of course, that last change might disturb the Decompiler a bit, but since we care far less now... > > I can open 1 or more issues if there is an interest. > > Nicolas

May 1, 2013