- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] List Method selection could be improved

by phil＠highoctane.be

Pharo3: keep your finger on shift at all times to move multiple things. Christophe Demarey showed it to me as I was complaining. Still, completely unintuitive. Phil On Wed, Oct 8, 2014 at 8:52 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-10-08 15:35 GMT-03:00 stepharo <stepharo(a)free.fr>: > > > > Hi > > > > It seems that we got some regressions in the method pane. > > - Sometimes I have the impression that I cannot look for a method just > typing the starting letter > > - When deleting a method it would be good that the next item is > selected. > > > What do you think? > > That it should be modified to behave as you expect, which is a common > pattern of list selection. > > > Plus (in Pharo 3): > - You can't individually select separate elements (methods) by holding > down Ctrl and clicking on them. > - You can select continuous elements using Shift, but once you start > dragging them the one that has the cursor when the drag operation > starts is unselected. (so if you we're going to recategorize 5 > methods, you end up doing it for only 4). > > > I don't know if those are regressions, but they certainly doesn't > follow the most used patterns of element selection. > > > Regards, > > > Esteban A. Maringolo > >

Oct. 8, 2014

Re: [Pharo-dev] List Method selection could be improved

by Esteban A. Maringolo

2014-10-08 15:35 GMT-03:00 stepharo <stepharo(a)free.fr>: > > Hi > > It seems that we got some regressions in the method pane. > - Sometimes I have the impression that I cannot look for a method just typing the starting letter > - When deleting a method it would be good that the next item is selected. > What do you think? That it should be modified to behave as you expect, which is a common pattern of list selection. Plus (in Pharo 3): - You can't individually select separate elements (methods) by holding down Ctrl and clicking on them. - You can select continuous elements using Shift, but once you start dragging them the one that has the cursor when the drag operation starts is unselected. (so if you we're going to recategorize 5 methods, you end up doing it for only 4). I don't know if those are regressions, but they certainly doesn't follow the most used patterns of element selection. Regards, Esteban A. Maringolo

Oct. 8, 2014

List Method selection could be improved

by stepharo

Hi It seems that we got some regressions in the method pane. - Sometimes I have the impression that I cannot look for a method just typing the starting letter - When deleting a method it would be good that the next item is selected. What do you think? Stef

Oct. 8, 2014

Re: [Pharo-dev] BlockClosure source code

by Marcus Denker

> On 08 Oct 2014, at 18:28, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > > On 8 oct. 2014, at 17:49, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > >>> >>> On 08 Oct 2014, at 16:46, Jan KurÅ¡ <kurs(a)iam.unibe.ch <mailto:kurs@iam.unibe.ch>> wrote: >>> >>> Hi, >>> >>> I need to extract a source code from a block closure and I found something strange: >>> >>> [ :ctx | [ ctx atEnd ] ifTrue: [ ] ] . >>> [ :ctx | [ ctx atEnd ] whileTrue:[ ] ]. >>> >>> Print of the first line returns: >>> '[ :ctx | [ ctx atEnd ] ifTrue: [ ] ]' >>> >>> Print of the second line returns: >>> '[ ctx atEnd ]' >>> >>> And honestly, I have no idea why. This behaviour was observed in Pharo3 and Pharo4. >>> >>> Is there a way how to get a consistent result, i.e. '[ :ctx | [ ctx atEnd ] whileTrue:[ ] ]' for a second line? >> >> >> I think this is an example that exposes a bug that we still have in the source mappingâ¦ on Context, see >> >> sourceNode >> "Return the source node of the method or the block corresponding to the receiver" >> ^ (method sourceNodeForPC: self neighborPCWithCorrectMapping) enclosingMethodOrBlockNode >> "Uncomment the following once the pc->AST mapping is fixed" >> "^ (method sourceNodeForPC: (pc ifNil: [ self startpc ])) enclosingMethodOrBlockNode" >> >> #neighborPCWithCorrectMapping returns the inner send, which is wrongâ¦ this method needs to be rethought. > > Yes it should. But that's not easy with optimized loop messages like whileTrue: & co. > Ideally, the source mapping needs to be fixed because that's the reason this method exists in the first place. The first step is to record a range for the byte code that an IRNode createsâ¦ > Or else we accepts that "1 to: 1 do: [ :i | ^ thisContext sourceNode ]" returns a method node instead of a block node and use a different implementation. > >> >> Marcus

Oct. 8, 2014

Re: [Pharo-dev] ShoreLine Reporter - A tool to collect stack traces

by Martin Dias

Tommaso: I also started to load it On Wed, Oct 8, 2014 at 6:09 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Do you have a link to ESUG's slides/presentation? > > Regards! > Esteban A. Maringolo > > > 2014-10-07 13:23 GMT-03:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com>: > > Hello everybody, > > > > for those of you who were not at ESUG, I present ShoreLine Reporter. > > > > ShoreLine Reporter is a Pharo plugin to collect stack traces from > exceptions > > and send them to a central repository. > > You can give feedback to the community by breaking things: how cool is > that? > > > > > > * Why? > > > > We are collecting stack traces for research purposes and to identify the > > Pharo components that can be improved or optimized. > > We are also working on a web platform where users can access the > submitted > > data and use them during the debugging process. More on that soon! > > > > > > * How? > > > > You can install ShoreLine Reporter by visiting the project page on > > SmalltalkHub: > > http://www.smalltalkhub.com/#!/~dalsat/ShoreLine-Reporter/ > > > > Installing ShoreLine Reporter requires only a couple of seconds, and you > can > > configure it with the level of feedback that you prefer. On the > SmalltalkHub > > page you can find a script to automatically install ShoreLine Reporter > with > > every new Pharo image. Just drop it in your Pharo preferences directory > and > > forget about it. > > > > Once ShoreLine Report is installed, you can decide to configure if you > want > > to be prompted to submit a stack trace, or to automatically submit each > > exception without any bother. > > > > > > * What? > > > > We try to collect as few data as possible: the execution stacktrace, the > > name of the author and the Pharo build. We do *not* any collect personal > > data, such as passwords or repositories. The data is currently stored on > our > > server, at the University of Lugano. > > > > > > * Compatibility > > > > ShoreLine Reporter is developed for the Pharo debugger. We are improving > > ShoreLine Reporter to work with GTInspector, we will push an update in > the > > following days. > > > > > > For any problem, contact me! > > > > Thanks, hope to see a lot of your exceptions ;-) > > Tommaso Dal Sasso @ REVEAL > > > >

Oct. 8, 2014

Re: [Pharo-dev] BlockClosure source code

by Camille Teruel

On 8 oct. 2014, at 17:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On 08 Oct 2014, at 16:46, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: >> >> Hi, >> >> I need to extract a source code from a block closure and I found something strange: >> >> [ :ctx | [ ctx atEnd ] ifTrue: [ ] ] . >> [ :ctx | [ ctx atEnd ] whileTrue:[ ] ]. >> >> Print of the first line returns: >> '[ :ctx | [ ctx atEnd ] ifTrue: [ ] ]' >> >> Print of the second line returns: >> '[ ctx atEnd ]' >> >> And honestly, I have no idea why. This behaviour was observed in Pharo3 and Pharo4. >> >> Is there a way how to get a consistent result, i.e. '[ :ctx | [ ctx atEnd ] whileTrue:[ ] ]' for a second line? > > > I think this is an example that exposes a bug that we still have in the source mappingâ¦ on Context, see > > sourceNode > "Return the source node of the method or the block corresponding to the receiver" > ^ (method sourceNodeForPC: self neighborPCWithCorrectMapping) enclosingMethodOrBlockNode > "Uncomment the following once the pc->AST mapping is fixed" > "^ (method sourceNodeForPC: (pc ifNil: [ self startpc ])) enclosingMethodOrBlockNode" > > #neighborPCWithCorrectMapping returns the inner send, which is wrongâ¦ this method needs to be rethought. Yes it should. But that's not easy with optimized loop messages like whileTrue: & co. Ideally, the source mapping needs to be fixed because that's the reason this method exists in the first place. Or else we accepts that "1 to: 1 do: [ :i | ^ thisContext sourceNode ]" returns a method node instead of a block node and use a different implementation. > > Marcus

Oct. 8, 2014

Re: [Pharo-dev] ShoreLine Reporter - A tool to collect stack traces

by Esteban A. Maringolo

Do you have a link to ESUG's slides/presentation? Regards! Esteban A. Maringolo 2014-10-07 13:23 GMT-03:00 Tommaso Dal Sasso <tommaso.dalsasso(a)gmail.com>: > Hello everybody, > > for those of you who were not at ESUG, I present ShoreLine Reporter. > > ShoreLine Reporter is a Pharo plugin to collect stack traces from exceptions > and send them to a central repository. > You can give feedback to the community by breaking things: how cool is that? > > > * Why? > > We are collecting stack traces for research purposes and to identify the > Pharo components that can be improved or optimized. > We are also working on a web platform where users can access the submitted > data and use them during the debugging process. More on that soon! > > > * How? > > You can install ShoreLine Reporter by visiting the project page on > SmalltalkHub: > http://www.smalltalkhub.com/#!/~dalsat/ShoreLine-Reporter/ > > Installing ShoreLine Reporter requires only a couple of seconds, and you can > configure it with the level of feedback that you prefer. On the SmalltalkHub > page you can find a script to automatically install ShoreLine Reporter with > every new Pharo image. Just drop it in your Pharo preferences directory and > forget about it. > > Once ShoreLine Report is installed, you can decide to configure if you want > to be prompted to submit a stack trace, or to automatically submit each > exception without any bother. > > > * What? > > We try to collect as few data as possible: the execution stacktrace, the > name of the author and the Pharo build. We do *not* any collect personal > data, such as passwords or repositories. The data is currently stored on our > server, at the University of Lugano. > > > * Compatibility > > ShoreLine Reporter is developed for the Pharo debugger. We are improving > ShoreLine Reporter to work with GTInspector, we will push an update in the > following days. > > > For any problem, contact me! > > Thanks, hope to see a lot of your exceptions ;-) > Tommaso Dal Sasso @ REVEAL >

Oct. 8, 2014

Re: [Pharo-dev] BlockClosure source code

by Marcus Denker

> On 08 Oct 2014, at 16:46, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: > > Hi, > > I need to extract a source code from a block closure and I found something strange: > > [ :ctx | [ ctx atEnd ] ifTrue: [ ] ] . > [ :ctx | [ ctx atEnd ] whileTrue:[ ] ]. > > Print of the first line returns: > '[ :ctx | [ ctx atEnd ] ifTrue: [ ] ]' > > Print of the second line returns: > '[ ctx atEnd ]' > > And honestly, I have no idea why. This behaviour was observed in Pharo3 and Pharo4. > > Is there a way how to get a consistent result, i.e. '[ :ctx | [ ctx atEnd ] whileTrue:[ ] ]' for a second line? I think this is an example that exposes a bug that we still have in the source mappingâ¦ on Context, see sourceNode "Return the source node of the method or the block corresponding to the receiver" ^ (method sourceNodeForPC: self neighborPCWithCorrectMapping) enclosingMethodOrBlockNode "Uncomment the following once the pc->AST mapping is fixed" "^ (method sourceNodeForPC: (pc ifNil: [ self startpc ])) enclosingMethodOrBlockNode" #neighborPCWithCorrectMapping returns the inner send, which is wrongâ¦ this method needs to be rethought. Marcus

Oct. 8, 2014

Re: [Pharo-dev] BlockClosure source code

by Marcus Denker

> On 08 Oct 2014, at 17:35, Max Leske <maxleske(a)gmail.com> wrote: > > Can you provide a simple test to execute? [ :ctx | [ ctx atEnd ] whileTrue:[1+2 ] ] sourceNode > >> On 08.10.2014, at 16:46, Jan KurÅ¡ <kurs(a)iam.unibe.ch> wrote: >> >> Hi, >> >> I need to extract a source code from a block closure and I found something strange: >> >> [ :ctx | [ ctx atEnd ] ifTrue: [ ] ] . >> [ :ctx | [ ctx atEnd ] whileTrue:[ ] ]. >> >> Print of the first line returns: >> '[ :ctx | [ ctx atEnd ] ifTrue: [ ] ]' >> >> Print of the second line returns: >> '[ ctx atEnd ]' >> >> And honestly, I have no idea why. This behaviour was observed in Pharo3 and Pharo4. >> >> Is there a way how to get a consistent result, i.e. '[ :ctx | [ ctx atEnd ] whileTrue:[ ] ]' for a second line? >> >> Thank you in advance! >> Jan > >

Oct. 8, 2014

Re: [Pharo-dev] Missing hierarchy picture

by Max Leske

And ProtoObject and nilâ¦ :) > On 08.10.2014, at 16:57, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > You know what is missing on this picture? > > <TranslucentMetaclassClassClass.png> > > Traits :) > > Cheers! > Uko

Oct. 8, 2014