January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] bugs with blocks

by ClÃ©ment Bera

Hello, I don't think this line was there by mistake. In some cases, the activePC with this code is lower than the startpc and then the debugger shows an error 'no ast node found at this pc' and cannot properly highlight the current executed code because the pc is outside the method bytecode. I remember adding this line as a hack to fix a bug report.... But I don't remember any more... Here's an extract from my blog post, at that time the method had not this line, and we added it due to a bug report: *in a debugger, the context on the top of the stack does not highlight the same way other contexts does. In fact, the top context highlights the instruction in source code that *will* be executed in the next step. On the contrary, all the other contexts highlights the instruction in source code that *has been* executed previously. That means that you need to take care about that in the mapping to highlight the correct range.* *Right now we had to keep the old mapping API so there is a method named rangeForPC:contextIsActiveContext: that has a boolean as second argument. With this boolean you know if you need to look for the range of the current pc (first argument) of the previous pc of the first argument. On the old mapping, they needed the exact pc for their pc to abstract pc mapping. So they needed a method previousPCFor: to handle the case of multiple byte code instructions. But we donât care, as the pc will be used in the scan of instructionForPC:, so we just need to do pc â 1.* *The result is : DebuggerMethodMapOpal>>#rangeForPC: aPC contextIsActiveContext:contextIsActive "return the debug highlight for aPC"| pc |pc := contextIsActive ifTrue: [aPC] ifFalse: [aPC - 1].^ (methodNode sourceNodeForPC: pc) debugHighlightRangeRBMethodNode>>#sourceNodeForPC: anInteger ^ (self ir instructionForPC: anInteger) sourceNode* *IRMethod>>#instructionForPC: aPC 0 to: -3 by: -1 do: [ : off |(self firstInstructionMatching: [:ir | ir bytecodeOffset = (aPC - off) ]) ifNotNil: [:it |^it]] * 2014/1/27 Camille Teruel <camille.teruel(a)gmail.com> > > On 27 janv. 2014, at 08:44, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 26 Jan 2014, at 10:08, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > [ [ ] ] > prints: > [ ] > instead of: > [ [ ] ] > > and > [ :arg | [ arg ] ] > prints: > DoIt > ^ [ :arg | [ arg ] ] yourself > instead of: > [ :arg | [ arg ] ] > > > Apparently it's the print that is not correct because of problem in > #sourceNode. > Any clue? Marcus? ClÃ©ment? > > > Other than âthe devil is in the detailsâ (this is all far too complex for > my taste, implementation wiseâ¦) > > Can you add an issue? My problem is that i have no time right now to even > think about itâ¦ > > > My problem is that I found a fix with try-and-fail without really > understanding the code. > I just found that problematic examples were passing through that condition > whereas non problematic examples were not. > I looked at the versions and though that you may have left this line by > error. > I removed it and so far, it *seems* to work. So the fix is there but I > have no clue if it's correct or not. > Here it the case: > https://pharo.fogbugz.com/f/cases/12732/sourceNode-broken > > > Marcus > > >

Jan. 27, 2014

Re: [Pharo-dev] bugs with blocks

by Nicolai Hess

2014-01-27 Marcus Denker <marcus.denker(a)inria.fr> > > On 26 Jan 2014, at 10:08, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > [ [ ] ] > prints: > [ ] > instead of: > [ [ ] ] > > and > [ :arg | [ arg ] ] > prints: > DoIt > ^ [ :arg | [ arg ] ] yourself > instead of: > [ :arg | [ arg ] ] > > > Apparently it's the print that is not correct because of problem in > #sourceNode. > Any clue? Marcus? ClÃ©ment? > > > Other than âthe devil is in the detailsâ (this is all far too complex for > my taste, implementation wiseâ¦) > > Can you add an issue? My problem is that i have no time right now to even > think about itâ¦ > > Marcus > Yes, please add an issue. I 'll take a look at it. One note. Blocks without inner blocks are working: [:x | x] prints [: | x] (in both versions. As there is a difference how this line activePC <= self startpc ifTrue: [ activePC := pc ]. change the sourceNode output. I would take a look at what its purpose may be). nicolai

Jan. 27, 2014

Re: [Pharo-dev] bugs with blocks

by Camille Teruel

On 27 janv. 2014, at 08:44, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 26 Jan 2014, at 10:08, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> [ [ ] ] >> prints: >> [ ] >> instead of: >> [ [ ] ] >> >> and >> [ :arg | [ arg ] ] >> prints: >> DoIt >> ^ [ :arg | [ arg ] ] yourself >> instead of: >> [ :arg | [ arg ] ] >> >> >> Apparently it's the print that is not correct because of problem in #sourceNode. >> Any clue? Marcus? ClÃ©ment? > > Other than âthe devil is in the detailsâ (this is all far too complex for my taste, implementation wiseâ¦) > > Can you add an issue? My problem is that i have no time right now to even think about itâ¦ My problem is that I found a fix with try-and-fail without really understanding the code. I just found that problematic examples were passing through that condition whereas non problematic examples were not. I looked at the versions and though that you may have left this line by error. I removed it and so far, it *seems* to work. So the fix is there but I have no clue if it's correct or not. Here it the case: https://pharo.fogbugz.com/f/cases/12732/sourceNode-broken > > Marcus

Jan. 27, 2014

Re: [Pharo-dev] bugs with blocks

by Marcus Denker

On 26 Jan 2014, at 10:08, Camille Teruel <camille.teruel(a)gmail.com> wrote: > [ [ ] ] > prints: > [ ] > instead of: > [ [ ] ] > > and > [ :arg | [ arg ] ] > prints: > DoIt > ^ [ :arg | [ arg ] ] yourself > instead of: > [ :arg | [ arg ] ] > > > Apparently it's the print that is not correct because of problem in #sourceNode. > Any clue? Marcus? ClÃ©ment? Other than âthe devil is in the detailsâ (this is all far too complex for my taste, implementation wiseâ¦) Can you add an issue? My problem is that i have no time right now to even think about itâ¦ Marcus

Jan. 27, 2014

Re: [Pharo-dev] [regression reporter]regression occurred

by Marcus Denker

On 26 Jan 2014, at 16:25, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Camillo (as you wrote this stuff), > he is nit subscribe to the list as he needs to finish writing the thesis, try send him a private mail. > The test below often fails on the CI servers, timing tests are brittle there. > > Is this test necessary the way it is written now, what do you think ? > > Sven > > Begin forwarded message: > >> From: no-reply(a)ci.inria.fr >> Subject: [regression reporter]regression occurred >> Date: 26 Jan 2014 16:17:25 GMT+1 >> To: marcus.denker(a)inria.fr, estebanlm(a)gmail.com, sven(a)stfx.eu >> >> https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2.1-Validation-A-L/labe… >> >> 1 regressions found. >> KernelTests.Methods.BlockClosureTest.testOnForkErrorTakesLessThanOneSecond > >

Jan. 27, 2014

Re: [Pharo-dev] Integration Problem

by Marcus Denker

On 27 Jan 2014, at 08:06, Marcus Denker <marcus.denker(a)inria.fr> wrote: > honestly I would prefer we control a bit what gets integrated. E.g. the Rpackage changes where not yet > integrated because we where waiting for a review from Esteban. > > And we really need to take care donât make a mess of thingsâ¦ > > On 27 Jan 2014, at 05:23, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> I followed the video directions to try and integrate a fix. Unfortunately, my >> startup script class got included in the update and broke the Jenkins build >> (which can't find the mcz). What do I do now? >> > revert (on svn remove the numbered update file and revert the updates.staged Another thing is that updating can never happen in parallel, so it needs to be coordanted by mail right now (there is no lock). Marcus

Jan. 27, 2014

Re: [Pharo-dev] Roassal Visualization for control flow graph issues

by Marcus Denker

On 26 Jan 2014, at 14:45, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > As for the visualizations, indeed I saw them before. But, my problem is that I do not know what problems they are trying to solve (besides the graph looking nice - which can be a goal in itself). Could you elaborate on this? Perhaps we can find alternative solutions. > Try to find a bug in the text representation as opposed to the graphical oneâ¦. the text one just does not work as you can not follow control flow. Marcus

Jan. 27, 2014

Re: [Pharo-dev] build validation shows wrong slice loaded

by Marcus Denker

On 26 Jan 2014, at 20:59, Max Leske <maxleske(a)gmail.com> wrote: > In 12259 I had validation warnings and so I went and looked at that page for the first time (pretty cool btw!). The problem with issue 12259 is now that there are multiple slices in there. The validation performed on the image has been done correctly with my version of the slice, but all the messages on the page say that itâs Damienâs slice (which doesnât contain the same code and would produce completely different results). > > So, my guess is, that the name is somehow being cached (?) or something. It would be nice to have the validation show the correct slice to avoid others spending the extra 20 minutes until theyâve figured it outâ¦ :) > It is always the slice loaded with the highest number. And MC gives lower numbers as it just numbers the ones with your name in order. You need to change the number yourself when committing. Marcus

Jan. 27, 2014

Re: [Pharo-dev] Integration Problem

by Marcus Denker

honestly I would prefer we control a bit what gets integrated. E.g. the Rpackage changes where not yet integrated because we where waiting for a review from Esteban. And we really need to take care donât make a mess of thingsâ¦ On 27 Jan 2014, at 05:23, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I followed the video directions to try and integrate a fix. Unfortunately, my > startup script class got included in the update and broke the Jenkins build > (which can't find the mcz). What do I do now? > revert (on svn remove the numbered update file and Marcus

Jan. 27, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Tudor Girba

I opened an issue: https://pharo.fogbugz.com/f/cases/12731/Traits-modifications-cause-a-DNU I marked it as a show stopper because right now you cannot load a package with Traits in the image. I am not sure about triggering the event for subclasses, but I can certainly understand that it can be useful for tools. However, the problem is that we are trying to figure out isPropagation after we trigger it, instead of doing it while triggering for a subclass. So, one possibility would be to distinguish between ClassModified and SuperclassModified. I tried to search in the code quickly but could not locate the exact place. I will try again later if nobody beats me to it. Cheers, Doru On Sun, Jan 26, 2014 at 11:29 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > can you propose a fix? > > On 26 Jan 2014, at 22:56, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > > On Sun, Jan 26, 2014 at 10:50 PM, Martin Dias <tinchodias(a)gmail.com>wrote: > >> >> >> >> On Sun, Jan 26, 2014 at 4:07 PM, Tudor Girba <tudor(a)tudorgirba.com>wrote: >> >>> I looked more into it, and here is a smaller example: >>> Gofer new >>> smalltalkhubUser: 'Moose' project: 'MooseAlgos'; >>> package: 'Moose-Algos-Graph'; >>> load >>> >>> This one does open the debugger, so the other emergency evaluator issue >>> comes from somewhere else. >>> >>> The problem seems to come from a Trait being defined in this package, >>> and loading this trait triggers ClassModifiedClassDefinition which stumbles >>> in >>> >>> ClassModifiedClassDefinition>>isPropagation >>> "If there is not slot changes, I can assume that there is a propagation >>> (the change is in one of the superclasses)" >>> self oldClassDefinition layout ifNil: [ ^ false ]. >>> ^ self newClassDefinition layout instanceVariables = self >>> oldClassDefinition layout instanceVariables >>> >>> >> Despite of the name of ClassModifiedClassDefinition, it is announced also >> when traits are modified. I don't know if Trait should implement #layout... >> but it is not. >> >> I reproduced using this: >> >> Trait named: #DDDD. >> Trait >> named: #DDDD >> uses: {TSortable} >> category: 'a'. >> >> I guess that ClassModifiedClassDefinition is not only being announced >> when a class changed but also it is being announced when its superclass >> changed (in the case, "propagated"). So the purpose of #isPropagation is >> the check that. But I'm not sure this announcement should be done for the >> subclasses... >> >> >> > Yes, when a class is redefined, the change is announced for subclasses > also. Maybe we shouldn't, no? > > code to reproduce: > > > aClass := Object subclass: #A. > aClass subclass: #B. > > anns := OrderedCollection new. > SystemAnnouncer uniqueInstance > when: ClassModifiedClassDefinition > send: #add: > to: anns. > > Object > subclass: #A > instanceVariableNames: 'a'. > > anns. ---> > an OrderedCollection(a ClassModifiedClassDefinition a > ClassModifiedClassDefinition) > > > > MartÃn > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 27, 2014