- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Who is using Pharo Launcher and for what

by Nicolai Hess

2016-02-20 11:49 GMT+01:00 Damien Cassou <damien.cassou(a)inria.fr>: > For my CV, I need to know who is using the stuff I'm doing. If you use > the Pharo Launcher, could you please tell me in which context (e.g., > which company, open-source project) and what you use it for (e.g., > download from CI, standard Pharo)? > > I don't need long paragraphs, just give me the keywords please. > > Thanks > bug hunting > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > >

Feb. 20, 2016

Re: [Pharo-dev] GTSpotter, the 95% case

by Tudor Girba

Hi, There is no processor for that. Now, if the order would work the current processor would be enough. But, if you want just that message, you can write your own processor. Would you like to try? It would be a useful exercise and I can guide you and we can use your questions to guide the documentation. Cheers, Doru > On Feb 20, 2016, at 9:19 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Sat, Feb 20, 2016 at 5:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > > > On Feb 20, 2016, at 7:45 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > > > > > On Sat, Feb 20, 2016 at 6:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > > > There are recurring questions about GTSpotter, along the lines of: > > > > why Spotter does not work well for 95% of the cases > > - implement > > - send > > - class > > - class refs? > > > > This is in the latest #50591, BTW. > > > > Starting with the 3rd one, searching for classes, that has been working well since day one and has benefited from general improvements. > > > > 'zncl' gives me ZnClient immediately. > > > > Yes, you have to learn how to dive into a result to expand it, but that is not often needed in this case. > > > > 'readstream', then first arrow (or cmd-shit-right), then 'co' gives me ZnCodePointReadStream and ZnEncodeReadStream. > > > > In both cases, just typing enter browses the class, which is what I want. > > > > Both implementers and senders do work well today, you just have to figure out how (learnability is an issue, but not everything can be obvious in this world). > > > > 'get: #i' but also, 'get:' + cmd-m gives you all implementors of #get: and spotter automatically expands from a limited set of 5 matches to 100 > > > > > > It does not here. Here, using 50594, doing 'get: +i' does not give me all implementors of #get: as you said, but all the implementors MATCHING #get:. > > In fact, those with #get: (exactly) are not even sorted on top. See attached screenshot. > > This is caused because of ordering. This is an issue that is open since a long time, and we have a hard time finding the right solution. But, we are still trying. We now made it explicit on the issue tracker: > https://pharo.fogbugz.com/f/cases/17656/Spotter-should-sort-search-results > > > Thanks Doru. And how can I get to the list of implementors of #get: in this example? Not to the list of methods matching #get: but to the exact implementors of #get: > > Sorry if it has been asked in all the other threads/ > > Cheers, > Doru > > > > > > > > Enable preview (click outer arrow, or cmd-p) and you see the implementors right there > > > > Now, dive in (first arrow or cmd-shit-right), and type 'zn' and I can see ZnClient>>#get: > > > > Type enter to open the method in a browser > > > > Similar approach for senders, using #s and cmd-n > > > > 'join: #s'but also, 'join:' + cmd-n gives you all senders of #join: and spotter automatically expands > > > > Enable preview (click outer arrow, or cmd-p) and you see the implementors right there > > > > Now, dive in (first arrow or cmd-shit-right), and type 'zn' and I can see ZnDefaultServerDelegate>>#welcomePageCss > > > > Type enter to open the method in a browser > > > > Class references, I don't know how to do that, but I can't see why it would not fit and it would be a good addition. > > > > Spotter adds to the other ways of doing these 4 actions, the old one still work, as does command-click (one of my favourites). > > > > Sven > > > > PS: I don't wan to narrow down the discussion to just these 4 cases, Spotter and GT are about way more than just this, you can search for many, many things (for example, type 'json' and you can install 3 packages from the catalog), and you can extend these tools yourself. I also know that things must improve further. > > > > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > <Screen Shot 2016-02-20 at 3.41.45 PM.png> > > -- > www.tudorgirba.com > www.feenk.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > > > > > -- > Mariano > http://marianopeck.wordpress.com -- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."

Feb. 20, 2016

Re: [Pharo-dev] GTSpotter, the 95% case

by Mariano Martinez Peck

On Sat, Feb 20, 2016 at 5:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > > > On Feb 20, 2016, at 7:45 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > > > > > > > > On Sat, Feb 20, 2016 at 6:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > Hi, > > > > There are recurring questions about GTSpotter, along the lines of: > > > > why Spotter does not work well for 95% of the cases > > - implement > > - send > > - class > > - class refs? > > > > This is in the latest #50591, BTW. > > > > Starting with the 3rd one, searching for classes, that has been working > well since day one and has benefited from general improvements. > > > > 'zncl' gives me ZnClient immediately. > > > > Yes, you have to learn how to dive into a result to expand it, but that > is not often needed in this case. > > > > 'readstream', then first arrow (or cmd-shit-right), then 'co' gives me > ZnCodePointReadStream and ZnEncodeReadStream. > > > > In both cases, just typing enter browses the class, which is what I want. > > > > Both implementers and senders do work well today, you just have to > figure out how (learnability is an issue, but not everything can be obvious > in this world). > > > > 'get: #i' but also, 'get:' + cmd-m gives you all implementors of #get: > and spotter automatically expands from a limited set of 5 matches to 100 > > > > > > It does not here. Here, using 50594, doing 'get: +i' does not give me > all implementors of #get: as you said, but all the implementors MATCHING > #get:. > > In fact, those with #get: (exactly) are not even sorted on top. See > attached screenshot. > > This is caused because of ordering. This is an issue that is open since a > long time, and we have a hard time finding the right solution. But, we are > still trying. We now made it explicit on the issue tracker: > https://pharo.fogbugz.com/f/cases/17656/Spotter-should-sort-search-results > > Thanks Doru. And how can I get to the list of implementors of #get: in this example? Not to the list of methods matching #get: but to the exact implementors of #get: Sorry if it has been asked in all the other threads/ > Cheers, > Doru > > > > > > > > Enable preview (click outer arrow, or cmd-p) and you see the > implementors right there > > > > Now, dive in (first arrow or cmd-shit-right), and type 'zn' and I can > see ZnClient>>#get: > > > > Type enter to open the method in a browser > > > > Similar approach for senders, using #s and cmd-n > > > > 'join: #s'but also, 'join:' + cmd-n gives you all senders of #join: and > spotter automatically expands > > > > Enable preview (click outer arrow, or cmd-p) and you see the > implementors right there > > > > Now, dive in (first arrow or cmd-shit-right), and type 'zn' and I can > see ZnDefaultServerDelegate>>#welcomePageCss > > > > Type enter to open the method in a browser > > > > Class references, I don't know how to do that, but I can't see why it > would not fit and it would be a good addition. > > > > Spotter adds to the other ways of doing these 4 actions, the old one > still work, as does command-click (one of my favourites). > > > > Sven > > > > PS: I don't wan to narrow down the discussion to just these 4 cases, > Spotter and GT are about way more than just this, you can search for many, > many things (for example, type 'json' and you can install 3 packages from > the catalog), and you can extend these tools yourself. I also know that > things must improve further. > > > > > > > > > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > <Screen Shot 2016-02-20 at 3.41.45 PM.png> > > -- > www.tudorgirba.com > www.feenk.com > > "If you interrupt the barber while he is cutting your hair, > you will end up with a messy haircut." > > > -- Mariano http://marianopeck.wordpress.com

Feb. 20, 2016

Re: [Pharo-dev] GTSpotter, the 95% case

by Tudor Girba

Hi, > On Feb 20, 2016, at 7:45 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Sat, Feb 20, 2016 at 6:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > There are recurring questions about GTSpotter, along the lines of: > > why Spotter does not work well for 95% of the cases > - implement > - send > - class > - class refs? > > This is in the latest #50591, BTW. > > Starting with the 3rd one, searching for classes, that has been working well since day one and has benefited from general improvements. > > 'zncl' gives me ZnClient immediately. > > Yes, you have to learn how to dive into a result to expand it, but that is not often needed in this case. > > 'readstream', then first arrow (or cmd-shit-right), then 'co' gives me ZnCodePointReadStream and ZnEncodeReadStream. > > In both cases, just typing enter browses the class, which is what I want. > > Both implementers and senders do work well today, you just have to figure out how (learnability is an issue, but not everything can be obvious in this world). > > 'get: #i' but also, 'get:' + cmd-m gives you all implementors of #get: and spotter automatically expands from a limited set of 5 matches to 100 > > > It does not here. Here, using 50594, doing 'get: +i' does not give me all implementors of #get: as you said, but all the implementors MATCHING #get:. > In fact, those with #get: (exactly) are not even sorted on top. See attached screenshot. This is caused because of ordering. This is an issue that is open since a long time, and we have a hard time finding the right solution. But, we are still trying. We now made it explicit on the issue tracker: https://pharo.fogbugz.com/f/cases/17656/Spotter-should-sort-search-results Cheers, Doru > > > Enable preview (click outer arrow, or cmd-p) and you see the implementors right there > > Now, dive in (first arrow or cmd-shit-right), and type 'zn' and I can see ZnClient>>#get: > > Type enter to open the method in a browser > > Similar approach for senders, using #s and cmd-n > > 'join: #s'but also, 'join:' + cmd-n gives you all senders of #join: and spotter automatically expands > > Enable preview (click outer arrow, or cmd-p) and you see the implementors right there > > Now, dive in (first arrow or cmd-shit-right), and type 'zn' and I can see ZnDefaultServerDelegate>>#welcomePageCss > > Type enter to open the method in a browser > > Class references, I don't know how to do that, but I can't see why it would not fit and it would be a good addition. > > Spotter adds to the other ways of doing these 4 actions, the old one still work, as does command-click (one of my favourites). > > Sven > > PS: I don't wan to narrow down the discussion to just these 4 cases, Spotter and GT are about way more than just this, you can search for many, many things (for example, type 'json' and you can install 3 packages from the catalog), and you can extend these tools yourself. I also know that things must improve further. > > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > <Screen Shot 2016-02-20 at 3.41.45 PM.png> -- www.tudorgirba.com www.feenk.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

Feb. 20, 2016

Re: [Pharo-dev] [Pharo-users] Who is using Pharo Launcher and for what

by Damien Cassou

On February 20, 2016 1:33:10 PM GMT+01:00, Tudor Girba <tudor(a)tudorgirba.com> wrote: >I use it for writing documentation and blog posts. > >Doru > >-- >www.tudorgirba.com > >"Every thing has its own flow" > >> On 20 Feb 2016, at 11:49, Damien Cassou <damien.cassou(a)inria.fr> >wrote: >> >> For my CV, I need to know who is using the stuff I'm doing. If you >use >> the Pharo Launcher, could you please tell me in which context (e.g., >> which company, open-source project) and what you use it for (e.g., >> download from CI, standard Pharo)? >> >> I don't need long paragraphs, just give me the keywords please. >> >> Thanks >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Success is the ability to go from one failure to another without >> losing enthusiasm." --Winston Churchill >> Please all also tell me the company in which you work -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Feb. 20, 2016

Re: [Pharo-dev] Yet again, wrong tempvars in debuggers context variables list

by Nicolai Hess

2016-02-20 19:11 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > This is not an issue with GTDebugger, but the way opal generates the > tempvar > index or the way, debuggerMap tries to access the context vars > > 17660 > <https://pharo.fogbugz.com/f/cases/17660/wrong-tempvar-values-in-debugger> > wrong tempvar values in debugger > > > This is a really special case, I wasn't able yet to create an easier > example for reproducing this bug: > - put a self haltOnce in > RAbstractClass>>#directlyDefinesLocalMethod: > - enable halt once > - select any other method in Nautilus and choose > "Rename method (all)" from method panes context menu > - enter a new name and push "OK" > -> the debugger pops up in method > directlyDefinesLocalMethod: > - select the first "allClassesDo:" context from top of the stack > -> the debugger shows that we are in the evalBlock context > The "seen" variable is a Set, but if you look at the "Variables"-pane, it > is shown > as a block (this is actually the parameter aBlock) > again, this is caused by a change for spur migration This worked up to pharo 50496 starting with pharo 50497, the order of variables has changed. see http://forum.world.st/pharo-project-pharo-core-dfd4f3-50497-td4867046.html <https://pharo.fogbugz.com/f/cases/17241/ffi-nb-is-not-cleaning-compiled-met…>

Feb. 20, 2016

Re: [Pharo-dev] GTSpotter, the 95% case

by Mariano Martinez Peck

On Sat, Feb 20, 2016 at 6:41 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > There are recurring questions about GTSpotter, along the lines of: > > why Spotter does not work well for 95% of the cases > - implement > - send > - class > - class refs? > > This is in the latest #50591, BTW. > > Starting with the 3rd one, searching for classes, that has been working > well since day one and has benefited from general improvements. > > 'zncl' gives me ZnClient immediately. > > Yes, you have to learn how to dive into a result to expand it, but that is > not often needed in this case. > > 'readstream', then first arrow (or cmd-shit-right), then 'co' gives me > ZnCodePointReadStream and ZnEncodeReadStream. > > In both cases, just typing enter browses the class, which is what I want. > > Both implementers and senders do work well today, you just have to figure > out how (learnability is an issue, but not everything can be obvious in > this world). > > 'get: #i' but also, 'get:' + cmd-m gives you all implementors of #get: and > spotter automatically expands from a limited set of 5 matches to 100 > > It does not here. Here, using 50594, doing 'get: +i' does not give me all implementors of #get: as you said, but all the implementors MATCHING #get:. In fact, those with #get: (exactly) are not even sorted on top. See attached screenshot. > Enable preview (click outer arrow, or cmd-p) and you see the implementors > right there > > Now, dive in (first arrow or cmd-shit-right), and type 'zn' and I can see > ZnClient>>#get: > > Type enter to open the method in a browser > > Similar approach for senders, using #s and cmd-n > > 'join: #s'but also, 'join:' + cmd-n gives you all senders of #join: and > spotter automatically expands > > Enable preview (click outer arrow, or cmd-p) and you see the implementors > right there > > Now, dive in (first arrow or cmd-shit-right), and type 'zn' and I can see > ZnDefaultServerDelegate>>#welcomePageCss > > Type enter to open the method in a browser > > Class references, I don't know how to do that, but I can't see why it > would not fit and it would be a good addition. > > Spotter adds to the other ways of doing these 4 actions, the old one still > work, as does command-click (one of my favourites). > > Sven > > PS: I don't wan to narrow down the discussion to just these 4 cases, > Spotter and GT are about way more than just this, you can search for many, > many things (for example, type 'json' and you can install 3 packages from > the catalog), and you can extend these tools yourself. I also know that > things must improve further. > > > > > > -- Mariano http://marianopeck.wordpress.com

Feb. 20, 2016

Yet again, wrong tempvars in debuggers context variables list

by Nicolai Hess

This is not an issue with GTDebugger, but the way opal generates the tempvar index or the way, debuggerMap tries to access the context vars 17660 <https://pharo.fogbugz.com/f/cases/17660/wrong-tempvar-values-in-debugger> wrong tempvar values in debugger This is a really special case, I wasn't able yet to create an easier example for reproducing this bug: - put a self haltOnce in RAbstractClass>>#directlyDefinesLocalMethod: - enable halt once - select any other method in Nautilus and choose "Rename method (all)" from method panes context menu - enter a new name and push "OK" -> the debugger pops up in method directlyDefinesLocalMethod: - select the first "allClassesDo:" context from top of the stack -> the debugger shows that we are in the evalBlock context The "seen" variable is a Set, but if you look at the "Variables"-pane, it is shown as a block (this is actually the parameter aBlock)

Feb. 20, 2016

Re: [Pharo-dev] Who is using Pharo Launcher and for what

by Stephan Eggermont

On 20-02-16 11:49, Damien Cassou wrote: > For my CV, I need to know who is using the stuff I'm doing. If you use > the Pharo Launcher, could you please tell me in which context (e.g., > which company, open-source project) and what you use it for (e.g., > download from CI, standard Pharo)? I use PharoLauncher all the time, on Mac and Linux. When fixing an issue, it provides an easy way to get the latest image, make a change or review a slice, or test a metacello configuration I use company project images, pharo-contribution (seaside, qcmagritte) and moose (petitdelphi) CI images Stephan

Feb. 20, 2016

Re: [Pharo-dev] Who is using Pharo Launcher and for what

by Cyril Ferlicot D.

Le 20/02/2016 11:49, Damien Cassou a Ã©crit : > For my CV, I need to know who is using the stuff I'm doing. If you use > the Pharo Launcher, could you please tell me in which context (e.g., > which company, open-source project) and what you use it for (e.g., > download from CI, standard Pharo)? > > I don't need long paragraphs, just give me the keywords please. > > Thanks > Hi, Myself and some people from Synectique use it to download and manage images from Pharo, Moose and Synectique's CI. -- Cyril

Feb. 20, 2016