- Pharo-dev - lists.pharo.org

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

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

by stepharo

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] gtdebugger in pharo 5.0

by stepharo

I'm sorry but this debugger should not be the default one. MONDAY we are filming our mooc and we have to explain the debugger and personally I do not see the gain: - It looks a lot more complex to me and I do not want to have to redo all the screenshots of our lecture. - Just that I have to learn the meaning of small icons. - Why do we need a special pane for the evaluator - Why there is a type column. - Sorry but I'm not convinced about the moldable aspect behind the story (no need to argue I know it) I would like to avoid to be forced to use not the latest version of Pharo for the mooc. Such changes are arriving far too late in the release. We do not change the debugger itself the day of code freeze. We decided that the GTDebugger can be included but to me it never meant that it should be the default one. I think that experts can choose the debugger they want. The newbies don't. Stef

Jan. 8, 2016

Re: [Pharo-dev] Semaphore and Mutex changes summary

by stepharo

thanks for the summary. I think that this is important to update the class comments with the comment of ben. I read several blogs of mutex vs semaphore and this is nice to get this cleared out. Stef Le 7/1/16 14:05, Denis Kudriashov a Ã©crit : > Hi. > > We got interesting discussion about semaphore and mutex. Here I put > summary of proposed changes. > > First we will deprecate Semaphore>>forMutualExclusion and rename it to > Semaphore>>newSignalled. Explanation from Ben Coman: > > Semaphore>>forMutualExclusion *encourages* people to believe > semaphores can be used *on*their*own* for mutual exclusion, when they > *shouldn't*. You *must* add ownership. If the mutual exclusion > object doesnât have ownership then, irrelevant of what it is called, > it is not a mutex!!! [1]. > > And more: > > With an implementation like.. > Semaphore>>forMutualExclusion > ^self new signal > we don't gain a lot, and its a misleading convenience method since its > doesn't provide the proper facility for mutual exclusion (and I do > conflate mutual exclusion == mutex). Indeed, "Semaphore > forMutualExclusion + roll your ownership management + problems since > you weren't aware you needed to roll your own ownership management" is > not more convenient than "Mutex new" > If you want to keep a convenience method for a pre signalled > Semaphore, then we could provide something like "Semaphore > newSignalled" > > It is also explain why we should deprecate Semaphore>>critical: and > use Mutex>>critical: instead. That's second change. > > So we want to move 4 Semaphore methods to Mutex: > > * critical: mutuallyExcludedBlock > > It will relies on new Semaphore method waitIfInterrupted: which block > is executed when waiting process terminated at point where lock was > not acquired. Slice for this already in inbox. > > * critical: mutuallyExcludedBlock ifCurtailed: terminationBlock > * critical: mutuallyExcludedBlock ifError: errorBlock > > Semantic of this method is like BlockCosure>>ifError:. It culls error > properties to handler block. It will be changed to cull only error > instance. > It will touch WeakArray and WeakRegistry. Now they doing this: > > ifError:[:msg :rcvr| rcvr error: msg]. > > > No special logic inside handler. So we will just use #critical: message. > > * critical: mutuallyExcludedBlock ifLocked: alternativeBlock > > It purpose looks like "enter critical section without waiting > otherwise alternativeBlock". But implementation not shows that waiting > can not be happens: > > critical: mutuallyExcludedBlock ifLocked: alternativeBlock > excessSignals == 0 > ifTrue: > [ ^alternativeBlock value ]. > ^self critical: mutuallyExcludedBlock > > When critical message is sent but it method not started interrupt can > happen and other process can lock this semaphore. And when process > will be resumed it will be blocked. > So implementation is not correct to me. It should be changed somehow. > > Welcome for suggestions > >

Jan. 8, 2016

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

by Juraj Kubelka

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] #sum:, #detectSum:, #sumNumbers:

by stepharo

Sven may be should do the following: - introduce the best solution (not using your and henrik decomposition) - continue to think about it. I would like to see if Xtreams does not go in the same direction too. But I do not have the code at hand to think about it. Stef

Jan. 8, 2016