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

Re: [Pharo-dev] [Vm-dev] problem with become:?

by Tudor Girba

Hi, > On Jan 9, 2016, at 12:09 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Doru, > > On Fri, Jan 8, 2016 at 12:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > If I execute the following code in the latest Pharo image: > > Object subclass: #A > instanceVariableNames: '' > classVariableNames: '' > package: 'AA'. > Object subclass: #B > instanceVariableNames: '' > classVariableNames: '' > package: 'AA'. > a := A new. > b := B new. > a become: b. > a class > > ==> âA". > > In a pre-Spur image, I used to get âBâ. Is this a bug, or is there a change I am not aware of? > > Cheers, > Doru > > Looks like a bug to me. I'll fix it asap. Thanks! Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Things happen when they happen, > not when you talk about them happening." > > > > > > -- > _,,,^..^,,,_ > best, Eliot -- www.tudorgirba.com www.feenk.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Jan. 8, 2016

Re: [Pharo-dev] [squeak-dev] Re: problem with become:?

by Nicolai Hess

2016-01-08 23:09 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Doru, > > On Fri, Jan 8, 2016 at 12:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> If I execute the following code in the latest Pharo image: >> >> Object subclass: #A >> instanceVariableNames: '' >> classVariableNames: '' >> package: 'AA'. >> Object subclass: #B >> instanceVariableNames: '' >> classVariableNames: '' >> package: 'AA'. >> a := A new. >> b := B new. >> a become: b. >> a class >> >> ==> âA". >> >> In a pre-Spur image, I used to get âBâ. Is this a bug, or is there a >> change I am not aware of? >> >> Cheers, >> Doru >> > > Looks like a bug to me. I'll fix it asap. > There is another bug report at http://bugs.squeak.org/view.php?id=7845 | obj1 obj2 | obj1 := 'string'. obj2 := 1.234. obj1 become: obj2. {obj1. obj2} "=> #('X9ÂLÃvÂ¾' 'string'). it should be #(1.234 'string') " Squeak Cog Supr Virtual Machine 4.0.3427.0 Is it related? > >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Things happen when they happen, >> not when you talk about them happening." >> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > > > >

Jan. 8, 2016

Re: [Pharo-dev] problem with become:?

by Eliot Miranda

Hi Doru, On Fri, Jan 8, 2016 at 12:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > If I execute the following code in the latest Pharo image: > > Object subclass: #A > instanceVariableNames: '' > classVariableNames: '' > package: 'AA'. > Object subclass: #B > instanceVariableNames: '' > classVariableNames: '' > package: 'AA'. > a := A new. > b := B new. > a become: b. > a class > > ==> âA". > > In a pre-Spur image, I used to get âBâ. Is this a bug, or is there a > change I am not aware of? > > Cheers, > Doru > Looks like a bug to me. I'll fix it asap. > > > -- > www.tudorgirba.com > www.feenk.com > > "Things happen when they happen, > not when you talk about them happening." > > > -- _,,,^..^,,,_ best, Eliot

Jan. 8, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Nicolai Hess

2016-01-08 21:22 GMT+01:00 stepharo <stepharo(a)free.fr>: > > I think that experts can choose the debugger they want. The newbies don't. > +1 > > Stef > > >

Jan. 8, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by Nicolai Hess

2016-01-08 22:48 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-01-08 16:43 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > >> Hi Nicolai, >> >> Thanks for the feedback. >> Some issues I'll manage to fix until we integrate. >> For those that I do not manage please open bug reports. >> >> On Thu, Jan 7, 2016 at 9:13 PM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> Some feedback on GTDebugger >>> >>> - The inspector pane is great, we can inspect, evaluate code, and easily >>> show/ inspect the code (for thisContext). >>> although the evaluator pane has a bad text mode (for the thisContext). >>> >> >> Can you give me more details? Maybe it's obvious but I'm missing what's >> wrong :) >> > > Hm, I can not reproduce it anymore. > Ok, now it happened again. See screenshot, the thisContext evaluator pane is wrong. And it does not go away (every debugger now shows this text, even if I debug a totally different method) > > > > >> >> Cheers, >> Andrei >> >> >>> - I think the buttons are too small and the icon for "stop over" is >>> misleading, it looks like a "step out" >>> - the shortcuts (neither ctrl+t nor cmd+t) aren't working >>> - I find it totally annoying and useless that the context pane inspector >>> scrolls away if you select a value in >>> the rightmost pane. The context inspector should be fixed. >>> - I really miss the "List Methods using 'varname'/List Methods storing >>> into 'varname' >>> - the stacklist entry for block closures prints the block closure code, >>> this is confusing (too much text for such a small widget). >>> >>> nicolai >>> >> >> >

Jan. 8, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by Nicolai Hess

2016-01-08 16:48 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 08 Jan 2016, at 16:43, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi Nicolai, > > Thanks for the feedback. > Some issues I'll manage to fix until we integrate. > For those that I do not manage please open bug reports. > > On Thu, Jan 7, 2016 at 9:13 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> Some feedback on GTDebugger >> >> - The inspector pane is great, we can inspect, evaluate code, and easily >> show/ inspect the code (for thisContext). >> although the evaluator pane has a bad text mode (for the thisContext). >> > > Can you give me more details? Maybe it's obvious but I'm missing what's > wrong :) > > Cheers, > Andrei > > >> - I think the buttons are too small and the icon for "stop over" is >> misleading, it looks like a "step outâ >> > > for me they are not small, but misplaced. I expect to have them close to > where Iâm looking for: the code (that happens in all debuggers I know, with > the exception of ddd who opens a different window). > For me, they should be in the code panel and not in the stack panel. > alsoâ¦ shortcuts do not work in code panel :( > Maybe a small margin between the buttons ? It often happens to me that I press the wrong button (step into instead of step over). > > Esteban > > > - the shortcuts (neither ctrl+t nor cmd+t) aren't working >> - I find it totally annoying and useless that the context pane inspector >> scrolls away if you select a value in >> the rightmost pane. The context inspector should be fixed. >> - I really miss the "List Methods using 'varname'/List Methods storing >> into 'varname' >> - the stacklist entry for block closures prints the block closure code, >> this is confusing (too much text for such a small widget). >> >> nicolai >> > > >

Jan. 8, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by Nicolai Hess

2016-01-08 16:43 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > Hi Nicolai, > > Thanks for the feedback. > Some issues I'll manage to fix until we integrate. > For those that I do not manage please open bug reports. > > On Thu, Jan 7, 2016 at 9:13 PM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> Some feedback on GTDebugger >> >> - The inspector pane is great, we can inspect, evaluate code, and easily >> show/ inspect the code (for thisContext). >> although the evaluator pane has a bad text mode (for the thisContext). >> > > Can you give me more details? Maybe it's obvious but I'm missing what's > wrong :) > Hm, I can not reproduce it anymore. > > Cheers, > Andrei > > >> - I think the buttons are too small and the icon for "stop over" is >> misleading, it looks like a "step out" >> - the shortcuts (neither ctrl+t nor cmd+t) aren't working >> - I find it totally annoying and useless that the context pane inspector >> scrolls away if you select a value in >> the rightmost pane. The context inspector should be fixed. >> - I really miss the "List Methods using 'varname'/List Methods storing >> into 'varname' >> - the stacklist entry for block closures prints the block closure code, >> this is confusing (too much text for such a small widget). >> >> nicolai >> > >

Jan. 8, 2016

Re: [Pharo-dev] [ANN] I created a web page so you can stalk me :)

by Dimitris Chloupis

Completely agree, we need to expose the effort that is going on, the more people understand the effort the more will be able and willing to help out. FFI is a huge deal for pharo, no language has a hope of survival without a good FFI, its paramount that we are aware of all the work that goes in , what the problems are, and how we can help improve it. On Fri, Jan 8, 2016 at 10:26 PM stepharo <stepharo(a)free.fr> wrote: > Ok but my gut feeling is telling me that exposing activities in open > community can only explain better. > > Le 7/1/16 21:06, Esteban A. Maringolo a Ã©crit : > > 2016-01-07 16:54 GMT-03:00 stepharo <stepharo(a)free.fr>: > >> This is not to be visible. > >> This is to educate you guys :) > >> The point is how much time does it take esteban to fix FFI > >> How much worth is that? > >> All these questions and like that you know what esteban is doing > for > >> real when you put money > >> in the consortium. > > > > Oh, I see. Well... Esteban is very proficient, any money spent on him > > will pay more than on any other developer. His commits speak by > > themselves. > > > > Regards! > > > > Esteban A. Maringolo > > > > > > >

Jan. 8, 2016

Re: [Pharo-dev] ifError: implementation is bad

by stepharo

Indeed people like to play with better API and sometimes this is not better. I prefer on:do: because like that I know that this is about Exception handling. Stef > Hi, > > 8. 1. 2016 v 17:11, Tudor Girba <tudor(a)tudorgirba.com>: > >> Hi, >> >> Denis says that right now, to use ifError: you do: >> >> [...] ifError: [:msg :rcv | â¦ ] >> >> and he would like to write this: >> >> [...] ifError: [:error | â¦ ] > But for this we have on:do: message, right? > Do we need ifError:? > > Cheers, > Juraj > >> I agree with him. The problem is that this might generate a bit of ripple effects in external code. This is when Stephan came in and said that if we would have a way to investigate all external repositories that are open we could do such refactorings more boldly. >> >> Does it make more sense now? Or did I get it wrong? >> >> Cheers, >> Doru >> >> >> >>> On Jan 8, 2016, at 10:05 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi denis >>> I do not understand the problem and I'm convinced that you are right >>> so can anybody explain to me the point made by denis? >>> >>> Stef >>> >>> Le 7/1/16 13:11, Denis Kudriashov a Ã©crit : >>>> Hi >>>> >>>> I look at implementation of BlockClosure>>ifError: . I did't know that it culls arguments to errorBlock. >>>> But what is this arguments? It is not error instance but specific properties from it. >>>> >>>> BlockClosure>>ifError: errorHandlerBlock >>>> >>>> ^ self on: Error do: [:ex | >>>> errorHandlerBlock cull: ex description cull: ex receiver] >>>> >>>> Why people doing that? >>>> Many users of it just pass given error like >>>> >>>> [...] ifError: [:msg :rcv | ... >>>> rcv error: msg]. >>>> >>>> Especially it is commonly used scenario by senders of #critical:ifError:. But it is different question. >>>> >>>> I propose change ifError: to cull error instance. >>>> >>>> What you think? Can be put it in Pharo 5? Such change can touch some packages >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> >> >

Jan. 8, 2016

Re: [Pharo-dev] Syntax Highlighting error (RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance)

by stepharo

thanks :) Le 8/1/16 14:56, Marcus Denker a Ã©crit : > Hello, > > This is now integrated. > >> On 05 Jan 2016, at 16:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> yes, >> >> this is fixed by >> >> https://pharo.fogbugz.com/f/cases/17276/Semantic-Analysis-needs-refactoring >> >> I am now back from holidays and will review/intergrate this soon. >> >> >>> On 05 Jan 2016, at 16:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> I am seeing the following very annoying error in 50511 spur. >>> >>> Open a Playground, >>> type [ (both open en close are inserted, with the cursor in-between), >>> type : (to start a block arg), >>> boom: >>> >>> RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance >>> OCASTClosureAnalyzer>>changeVariableClass: >>> OCASTClosureAnalyzer>>visitArgumentNode: >>> [ :each | self visitArgumentNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: >>> OrderedCollection>>do: >>> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: >>> OCASTClosureAnalyzer>>visitBlockNode: >>> RBBlockNode>>acceptVisitor: >>> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >>> [ :each | self visitNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: >>> OrderedCollection>>do: >>> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: >>> RBSequenceNode>>acceptVisitor: >>> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >>> OCASTClosureAnalyzer>>visitMethodNode: >>> RBMethodNode>>acceptVisitor: >>> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >>> OCASTSemanticAnalyzer>>analyze: >>> RBMethodNode>>doSemanticAnalysis >>> RBBlockNode(RBProgramNode)>>doSemanticAnalysis >>> RubSHTextStylerST80(SHRBTextStyler)>>privateStyle: >>> [ self privateStyle: text. >>> view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ backgroundProcess := [ self privateStyle: text. >>> view ifNotNil: [ view stylerStyledInBackground: text ] ] >>> forkAt: Processor userBackgroundPriority ] in RubSHTextStylerST80(SHTextStyler)>>styleInBackgroundProcess: >>> [ self value. >>> Processor terminateActive ] in BlockClosure>>newProcess >>> >>> Has this already been reported ? >>> >>> It makes the image almost unusable... >>> >>> Sven >>> >>> > >

Jan. 8, 2016