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

Re: [Pharo-dev] Understanding Spotter?

by stepharo

Hi doru you see I make the effort to reply even if I get really frustrated with our tools. I do not get why you cannot - have a set of fixed most used queries and this will create a small vocabulary that can be extensible and it can be mapped to what we do with shortcuts = reduce cognitive load and then a full search when you do not know what you are searching. This is not exclusive and it works for the two scenario. I was discussing with Luc and he made a fun but sad remark "Since people do not understand well spotter they most of the time only use it to open a class. And this is something that he already had before." I briefly looked at the Youtube video of Chloupis and So you can have a generic super cool tool, if people do not use it it defeats its purpose. You can be really happy because you go fast with it but you only. So making sure that the most used actions are really supported is important. But more important the discoverability is important because there is not even a help. Right now as a user I can only guess and often I close spotter and use my shortcuts. As a user I see something that ask me about network (and I do not care) but nothing that brings me to the next level. Most of the time the user forgets the key combination (may be this will be solved with the cool shortcut reminder we developed and is under review) Stef

Jan. 10, 2016

Re: [Pharo-dev] Understanding Spotter?

by stepharo

Doru I will stop to argue with you because you are blind. If luc that is teaching and programming in Pharo and me do not find how to use Spotter then what can I say. Stef Le 10/1/16 06:32, Tudor Girba a Ã©crit : > Hi, > >> On Jan 10, 2016, at 12:21 AM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Doru >> >> are all the type after the name? >> menu #pr > > No. You can also do it like this: > #pragma menu > > >> I always thought it was the inverse. >> Where can we find the list of #â¦ > > That depends on the place you are searching. > > The # searches through the categories defined in the class of the > current step. By default, you start in an instance of GTSpotter so you > will find methods that are annotated with <spotterOrder:>. All > extensions of for GTSpotter are documented by inspecting the GTSpotter > class (and you can filter by the name of the class): > > > > So, # does not define a search action. It filters the search results > that happen anyway. That is why it is probably more natural to first > search what you are looking for, and then trim to only see the > category you are interested in. In any case, you can do it both ways. > >> Why we cannot have a ghost showing one example. > > What do you mean? > >> Blog posts are not part of the discoverability of an UI. > > Of course they are not. But, this is a bit of an unfair comparison :). > > Doru > > >> Stef >> >> Le 9/1/16 22:42, Tudor Girba a Ã©crit : >>> You can find documentation with examples about GTSpotter on the >>> humane-assessment.com <http://humane-assessment.com> blog: >>> https://www.google.com/search?client=safari&rls=en&q=site:humane-assessment… >>> >>> Specifically about finding Pragma usages, I just added a blog post: >>> http://www.humane-assessment.com/blog/spotting-pragmas-with-gtspotter >>> >>> Cheers, >>> Doru >>> >>>> On Jan 9, 2016, at 11:00 PM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> Hi >>>> >>>> Is there a help a student or idiot like me can read about how to >>>> find information with Spotter? >>>> For example >>>> We with luc wanted to find all the senders of variableSubclass: >>>> we tried # #senders and more... but gave up. >>>> Yesterday I wanted to find all the user of <menu> >>>> >>>> May be I missed an obvious help that will enlighten me? >>>> I hope. >>>> >>>> Now without such help how can we expect students or users to >>>> discover the way we should >>>> use the tools? >>>> >>>> We were planning to do a video to explain Spotter but I'm slowly >>>> thinking to discard this video >>>> because we do not know. >>>> >>>> Stef >>>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Value is always contextual." >>> >>> >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > www.feenk.com > > "Quality cannot be an afterthought." >

Jan. 10, 2016

Just that you know that we are not happy

by stepharo

Hi if GTdebugger becomes the default debugger it means that our mooc will be already obsolete before getting finished. It means that we will be forced to have separate installers different web pages explaining not to use Pharo 50 but a strange version it means that people will report bugs on a different system And we will have to spent time on that instead of the rest. And we will really thank the Pharo community for its great vision and care about our effort. This is more than 6 months that we are working on it and we have problably yet another month of work. Now just writing this makes me sick. So if the only respect about the work of other people is like that then I will just think a lot about my engagement. If this happens I can tell you that you will have a hard time to ask me to put energy into pharo in the future. Now if this makes you feel easy you can think that I'm tired. This poor stephane is working too much and is overacting. Think that if this helps you to feel good. Really. Now what pissed me off the most is that I'm **TEACHING** to L2 L3 and M1 students This year I was teaching to Prague Annecy Lviv Lome Dakar Saint louis Yaounde and when I say that the student are afraid by the default debugger, they are afraid also by a more complex one. Who among the people deciding to not put this debugger by default can show me that he did one lecture on newbies over the last two years? For real? So be right and go ahead: because you know what is good for the end programmer. I asked five times to understand who need _thisContext and _stakc top and so far I got zero answer. It will help me to take a break from Pharo. Stef PS: I 'm not in the Pharo board anymore because I have to do something else

Jan. 10, 2016

Re: [Pharo-dev] Understanding Spotter?

by Tudor Girba

Hi, > On Jan 10, 2016, at 12:28 AM, stepharo <stepharo(a)free.fr> wrote: > > Can we look for senders directly? Because we could not find how to do it. Not at the moment. The way it is supported now is by finding a concrete implementor and then diving in that one to find its senders. > And we read this blog post: > http://www.humane-assessment.com/blog/introducing-gtspotter/ > > Why Spotter does not offer > > #n foo senders of > #m foo implementors of > #N Point refs for class > #pr > #pa > it sounds simpler that way and coherent with the way we use senders and implementors. This is a different take on what Spotter is. In this case, you want to use # more like a search predicate, but Spotter is made to work with objects which implies that the mechanism should be generic. That is why we thought of # as being a search through the active names of categories. This is generic and it works reasonably well for any object. We envisaged introducing other operators, too. For example, in your case we could have & for denoting a shortcut for the name of the category. The problem there is that you want to limit these operators because you might want to use the symbol (like # or &) for an actual query. That is why we only introduced the searching through categories. But, letâs play a bit and maybe we find a better solution. What do you think? > Now I do not really care about commiting code from within Spotter. Do you refer about the Monticello extensions? Sometimes I use that because it is faster than clicking and opening Monticello, but those are more examples. Doru > > Stef > > Le 9/1/16 22:42, Tudor Girba a Ã©crit : >> You can find documentation with examples about GTSpotter on the humane-assessment.com blog: >> https://www.google.com/search?client=safari&rls=en&q=site:humane-assessment… >> >> Specifically about finding Pragma usages, I just added a blog post: >> http://www.humane-assessment.com/blog/spotting-pragmas-with-gtspotter >> >> Cheers, >> Doru >> >>> On Jan 9, 2016, at 11:00 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi >>> >>> Is there a help a student or idiot like me can read about how to find information with Spotter? >>> For example >>> We with luc wanted to find all the senders of variableSubclass: we tried # #senders and more... but gave up. >>> Yesterday I wanted to find all the user of <menu> >>> >>> May be I missed an obvious help that will enlighten me? >>> I hope. >>> >>> Now without such help how can we expect students or users to discover the way we should >>> use the tools? >>> >>> We were planning to do a video to explain Spotter but I'm slowly thinking to discard this video >>> because we do not know. >>> >>> Stef >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Value is always contextual." >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "Some battles are better lost than fought."

Jan. 10, 2016

Re: [Pharo-dev] Understanding Spotter?

by Tudor Girba

Hi, > On Jan 10, 2016, at 12:21 AM, stepharo <stepharo(a)free.fr> wrote: > > Doru > > are all the type after the name? > menu #pr No. You can also do it like this: #pragma menu > I always thought it was the inverse. > Where can we find the list of #â¦ That depends on the place you are searching. The # searches through the categories defined in the class of the current step. By default, you start in an instance of GTSpotter so you will find methods that are annotated with <spotterOrder:>. All extensions of for GTSpotter are documented by inspecting the GTSpotter class (and you can filter by the name of the class): So, # does not define a search action. It filters the search results that happen anyway. That is why it is probably more natural to first search what you are looking for, and then trim to only see the category you are interested in. In any case, you can do it both ways. > Why we cannot have a ghost showing one example. What do you mean? > Blog posts are not part of the discoverability of an UI. Of course they are not. But, this is a bit of an unfair comparison :). Doru > Stef > > Le 9/1/16 22:42, Tudor Girba a Ã©crit : >> You can find documentation with examples about GTSpotter on the humane-assessment.com blog: >> https://www.google.com/search?client=safari&rls=en&q=site:humane-assessment… >> >> Specifically about finding Pragma usages, I just added a blog post: >> http://www.humane-assessment.com/blog/spotting-pragmas-with-gtspotter >> >> Cheers, >> Doru >> >>> On Jan 9, 2016, at 11:00 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Hi >>> >>> Is there a help a student or idiot like me can read about how to find information with Spotter? >>> For example >>> We with luc wanted to find all the senders of variableSubclass: we tried # #senders and more... but gave up. >>> Yesterday I wanted to find all the user of <menu> >>> >>> May be I missed an obvious help that will enlighten me? >>> I hope. >>> >>> Now without such help how can we expect students or users to discover the way we should >>> use the tools? >>> >>> We were planning to do a video to explain Spotter but I'm slowly thinking to discard this video >>> because we do not know. >>> >>> Stef >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Value is always contextual." >> >> >> >> >> >> > > -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Hi, Thanks for the detailed feedback. See my comments inline. > On Jan 10, 2016, at 12:12 AM, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > Le 09/01/2016 10:32, Tudor Girba a Ã©crit : >> Hi, >> >> Could you be specific? What exactly do you find less intuitive? To be able to react, it is useful to get concrete points. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Value is always contextual." >> > > This was my impression but I will try to list these things. > > First I find the improvements of Esteban good. > > - For the icons it is true that the text help a lot. As someone mention, > just a setting to get or not the text is possible, but a least be able > to get the text is important IMO. > I use Intellij for java debugging and sometime I get a little lost when > I see the icons because for a same icon there is two different actions > between Pharo and Intellij. So I lose always some time waiting the > popup. And I think that a lot of students that do Java will have the > same problem. Interesting point, but I would not guide myself > - I like that the stack is fully loaded in the Spec debugger. In general > that doesn't add this much time to show all the stack and it's one more > line to show useful information. It is now fully loaded in a FastTable in the GTDebugger as well. > - On thing that I really don't like is to get 4 lines with the code of a > block in the stack. This is too much space I think. And because of this > we have a large horizontal scroll bar that we could avoid with a limite > in character. I miss the fact that we had the name of the class on the > line of a block in the Spec debugger. This is no longer the case in the latest implementation. Could you check? > For example I will join a screen with a block. > > I would prefer something like: > > In GLMMorphicTabulatorRenderer: [ :index :each | each hasId ifTrue:â¦ ] > And if you use FTTable you will not even get the horizontal scrollbar, > so it's useless to get 4 long lines of the block if we cannot see half > of it. Indeed. Printing is a problem of the Context printing, and will be changed, but in the meantime we have FastTable. Is this good enough for now? > - There is no way to close the inspector if we miss click Indeed, this is a problem. We did not want to have an extra tab line and that is why we do not have a way to close inspector panes, but you can still scroll back. Also, in the meantime, we made the Evaluator the default second pane, so you can use it by default just like in the classic debugger. > - I liked the separation between attributes and parameter/temp. I think > that it was more readable. Before I could had a global overview of both > easily. Now I have to scroll down to see the attributes. But for this > one maybe I prefer the old one by habits. I think this is indeed a habit issue. > - The context menu of the spec debugger have more useful options > (Suggestions, Code searchâ¦) These can be added. Could you say more concretely which of those you actually used? > These are the things that come in my mind. But maybe I missed some since > the fact that I found the old debugger more intuitive was a feeling. > It's hard to define why we have a feeling. Thanks for taking the time. I know itâs hard to dig underneath an impression like that, but it is very valuable once you do it because it can push us further. Cheers, Doru > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > <screen14.png> -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

Jan. 10, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Ben Coman

On Fri, Jan 8, 2016 at 9:40 PM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Here's an alternative implementation, which, instead of checking for the new > method name, hooks into the existing unwind machinery to execute the > waitIfCurtailed: argument. > Which removes the special case from Process >> #terminate, but at the added > cost that in-progress unwinds are executed as if the (suspended) terminating > thread they started executing on, is still the active process. (Which, > arguably, should be done anyways) It feels a bit fragile playing peeking into "Processor activeProcess suspendingList". Also it doesn't work :) It is not sufficient to test with only two processes. You need three, since it is the third process that wakes up incorrectly. lock := Semaphore forMutualExclusion. waitInFirstCritical := Semaphore new. Transcript clear; show: 'excessSignals=' , (lock instVarNamed: 'excessSignals') printString. testBlock := [ :n | Transcript crShow: n printString , ' start'. lock critical2: [ (n=1) ifTrue: [ waitInFirstCritical wait ]. Transcript crShow: n printString, ' done'. ]]. proc1 := (testBlock newProcessWith: {1}) priority: 50. proc2 := (testBlock newProcessWith: {2}) priority: 50. proc3 := (testBlock newProcessWith: {3}) priority: 50. proc1 resume. proc2 resume. proc3 resume. "proc2 terminate." waitInFirstCritical signal. Transcript cr; show: 'excessSignals=' , (lock instVarNamed: 'excessSignals') printString. "proc2 terminate" commented produces the expected result... excessSignals=1 1 start 2 start 3 start 1 done 2 done 3 done excessSignals=1 "proc2 terminate" uncommented produces incorrect ordering... excessSignals=1 1 start 2 start 3 start 3 done "<--should occur after 1" 1 done excessSignals=2 "<--should be 1" Now using "lock := CriticalSection new" provided by Eliot (and removing instVarNamed: 'excessSignals' access from the test script) produces correct result... 1 start 2 start 3 start 1 done 3 done cheers -ben

Jan. 10, 2016

Re: [Pharo-dev] Little challenge

by Eliot Miranda

BlockClosure and Context. Back in the day OrderedCollection was one (when become was cheap there was no need for the array inst car). You want to say Smalltalk allClasses select: [:c| c isVariable and: [c instSize > 0]] _,,,^..^,,,_ (phone) > On Jan 9, 2016, at 1:24 PM, stepharo <stepharo(a)free.fr> wrote: > > We tried > > (Object allSubclasses select: #isVariable) > reject: [ :each | each instVarNames isEmpty ] > > and we discovered that we have no class in the system with named instance variables and indexed ones. > May be we are wrong. We are interested if you find one. > > > Now we created one > > Object variableSubclass: #PPpoint > instanceVariableNames: 'x y' > classVariableNames: '' > package: 'Web' > > and this is strange because inspecting PPoint new: 3 looks wrong since the variable zone arrives before > the named one as displayed. > > > <hhbahgba.>

Jan. 10, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Mariano Martinez Peck

On Sat, Jan 9, 2016 at 4:15 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Mariano, > > if you followed the approach I described recently you wouldn't be > having these problems. Instead, the system would be generating the > information you need to know about sizes for you automatically. Eventually > you're going to have to grasp the nettle of how to import platform-specific > information such as structure sizes, values of $defines, layout of structs, > etc, etc. I presented a straightforward approach but you've yet to comment > on it. > > Hi Eliot, I read all that thread carefully and indeed, I would like to comment on it. Please, give me some time and I will share my thoughts. Thanks! > On Sat, Jan 9, 2016 at 4:54 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi Ben, allf >> >> Ok, I can also confirm that doing ExternalAddress allocate: 76 does work >> in Linux. And yes, since it's opaque I don't have to map it and just >> allocating the correct size is enough. >> I expect this would work in all GNU libc (glibc) based UNIXses. >> Esteban, well, I thought the init function would do both, allocate and >> init, but in glibc it seems it only init. In OSX it seems it does both. But >> from the API point of view it's not explicit that they should allocate the >> space. >> >> Anyway, I think we get this working this time. Thanks all for the help. >> >> Now the problem I am facing (in Linux) is that my none blocking pipes do >> not seem to be none blocking or either feof() call is not working as >> expected. Ok, I have to deal with this one now. >> >> Thanks!! >> >> >> On Sat, Jan 9, 2016 at 9:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> On Sat, Jan 9, 2016 at 12:15 PM, Ben Coman <btc(a)openinworld.com> wrote: >>> > On Sat, Jan 9, 2016 at 7:12 AM, Mariano Martinez Peck >>> > <marianopeck(a)gmail.com> wrote: >>> >> >>> >> On Jan 8, 2016 4:13 PM, "Ben Coman" <btc(a)openinworld.com> wrote: >>> >>> >>> >>> On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck >>> >>> <marianopeck(a)gmail.com> wrote: >>> >>> > Hi guys, >>> >>> > >>> >>> > I wonder if someone could give me a hand to find out why a FFI >>> calling I >>> >>> > am >>> >>> > doing is crashing. In OSX it works correct but I am testing in >>> CentOS >>> >>> > and it >>> >>> > fails. I wonder if it also crashes in other Linuxes too. >>> >>> >>> >>> I only had enough time to run it a few time so you know it also >>> >>> crashes in Debian Jessie 32-bit. There were no debug logs. I got >>> >>> these sorts of messages... >>> >>> >>> >> >>> >> Thanks! >>> >> >>> >>> *** Error in `/home/ben/tst/pharo-vm/pharo': free(): invalid next >>> size >>> >>> (fast): 0x08841a70 *** >>> >>> >>> >>> pharo: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) >>> >>> >= (unsigned long) (nb)' failed. >>> >>> *** Error in `/home/ben/tst/pharo-vm/pharo': malloc(): memory >>> >>> corruption: 0x0984c1e0 *** >>> >>> >>> >>> >>> >>> Searching github for "posix_spawn_file_actions_init " >>> >>> (https://git.io/vuSPL) >>> >>> I see a lot a function definitions of the form... >>> >>> int posix_spawn_file_actions_init(posix_spawn_file_actions_t *fa) >>> >>> { >>> >>> fa->__actions = 0; >>> >>> return 0; >>> >>> } >>> >>> >>> >>> ...so it seems you need to first allocate the space for the struct >>> and >>> >>> then pass the address of that. >>> >> >>> >> I thought the same. But I also read in glibc that that the init and >>> destroy >>> >> would free and alloc exactly so that you don't have to do it. >>> >> >>> >> In fact, the structure is known to be opaque. I cannot rely in what I >>> see in >>> >> internet since each os may have a different. >>> >> >>> >> And I cant get the size of it from ffi so I cannot allocate >>> accurately. I >>> >> think I am screw. I don't want to go to plugin side grrr .. >>> >> >>> >> And osx does work. >>> >> >>> >> I think I will try against glibc rather than libc. >>> >> >>> >> Another idea? >>> >> >>> >>> { >>> >>> int __allocated; >>> >>> int __used; >>> >>> struct __spawn_action *__actions; >>> >>> int __pad[16]; >>> >>> } posix_spawn_file_actions_t; >>> >>> // http://linux.die.net/include/spawn.h >>> >>> >>> >> >>> >> But that's opaque right? I cannot rely on that >>> > >>> > Your ExternalAddress use only allocates 4 bytes for the pointer. You >>> > need to also allocate the space for the structure. I guess these may >>> > need separate ExternalXXX objects, but just as hack experiment I find >>> > below that n:=68 crashes and n:=69 its fine. >>> >>> Whoops, I missed that the space for the struct seems actually >>> allocated by ExternalAddress. Doh! there it is staring at me with the >>> #allocate: message. So I guess a separate ExternalXXX object isn't >>> required. >>> >>> > >>> > | posixSpawnFileActionsT n | >>> > n := 68. "n := 69" >>> > posixSpawnFileActionsT := ExternalAddress allocate: n. >>> > OSSUnixSubprocess new primitivePosixSpawnFileActionsInit: >>> > posixSpawnFileActionsT. >>> > posixSpawnFileActionsT free. >>> > >>> > >>> > In trying to understand this I found an interesting article... >>> > http://www.catb.org/esr/structure-packing/ >>> > What I don't know is for a 32-bit OS on a 64-bit machine, is my >>> > pointer 4 or 8 bytes? >>> > Assuming 4 I derive the structure size for my 32-bit system is... >>> > 4 int __allocated; >>> > 4 int __used; >>> > 4 struct __spawn_action *__actions; >>> > 64 int __pad[16]; >>> > 76 posix_spawn_file_actions_t; >>> > >>> > 76 - 68 = 8 is an interesting round number, but I can't quite reason >>> it out. >>> >>> btw I confirmed *my* structure size by compiling and running... >>> #include <stdio.h> >>> #include <spawn.h> >>> posix_spawn_file_actions_t tst; >>> int main() >>> { >>> printf("-->sizeof=%d\n", sizeof(posix_spawn_file_actions_t)); >>> } >>> >>> -->sizeof=76 >>> >>> cheers -ben >>> >>> > With FFI how to you allocate some external memory and then get a >>> > pointer to it to pass to primitivePosixSpawnFileActionsInit ? >>> > >>> > cheers -ben >>> > >>> >>> > I am using latest Pharo 5.0 with Spur. To reproduce: >>> >>> > >>> >>> > 1) Get latest Pharo 5.0 and Spur via: >>> >>> > wget -O- get.pharo.org/alpha+vm | bash >>> >>> > >>> >>> > 2) Inside Pharo, load my prototype tool: >>> >>> > >>> >>> > Gofer it >>> >>> > package: 'OSSubprocess'; >>> >>> > url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main'; >>> >>> > load. >>> >>> > >>> >>> > 3) This is the code I am executing and it's crashing: >>> >>> > >>> >>> > | posixSpawnFileActionsT | posixSpawnFileActionsT := >>> ExternalAddress >>> >>> > allocate: 4. OSSUnixSubprocess new >>> primitivePosixSpawnFileActionsInit: >>> >>> > posixSpawnFileActionsT. posixSpawnFileActionsT free. >>> >>> > 4) The primitive is as simple as: >>> >>> > >>> >>> > primitivePosixSpawnFileActionsInit: aPosixSpawnFileActionsT >>> >>> > ^ self ffiCall: #( int posix_spawn_file_actions_init(void* >>> >>> > aPosixSpawnFileActionsT) ) module: LibC >>> >>> > >>> >>> > I have no idea what I am doing wrong. And again, this works on >>> OSX. The >>> >>> > function I am calling is: int >>> >>> > posix_spawn_file_actions_init(posix_spawn_file_actions_t >>> *file_actions); >>> >>> > as >>> >>> > you can read in [1] >>> >>> > >>> >>> > Below is the stacktrace I get the Linux terminal. >>> >>> > >>> >>> > Any hint is greatly appreciated. >>> >>> > >>> >>> > Thanks, >>> >>> > >>> >>> > >>> >>> > [1] >>> >>> > >>> >>> > >>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_… >>> >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > _,,,^..^,,,_ > best, Eliot > -- Mariano http://marianopeck.wordpress.com

Jan. 9, 2016

Re: [Pharo-dev] Understanding Spotter?

by stepharo

Can we look for senders directly? Because we could not find how to do it. And we read this blog post: http://www.humane-assessment.com/blog/introducing-gtspotter/ Why Spotter does not offer #n foo senders of #m foo implementors of #N Point refs for class #pr #pa it sounds simpler that way and coherent with the way we use senders and implementors. Now I do not really care about commiting code from within Spotter. Stef Le 9/1/16 22:42, Tudor Girba a Ã©crit : > You can find documentation with examples about GTSpotter on the humane-assessment.com blog: > https://www.google.com/search?client=safari&rls=en&q=site:humane-assessment… > > Specifically about finding Pragma usages, I just added a blog post: > http://www.humane-assessment.com/blog/spotting-pragmas-with-gtspotter > > Cheers, > Doru > >> On Jan 9, 2016, at 11:00 PM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi >> >> Is there a help a student or idiot like me can read about how to find information with Spotter? >> For example >> We with luc wanted to find all the senders of variableSubclass: we tried # #senders and more... but gave up. >> Yesterday I wanted to find all the user of <menu> >> >> May be I missed an obvious help that will enlighten me? >> I hope. >> >> Now without such help how can we expect students or users to discover the way we should >> use the tools? >> >> We were planning to do a video to explain Spotter but I'm slowly thinking to discard this video >> because we do not know. >> >> Stef >> > -- > www.tudorgirba.com > www.feenk.com > > "Value is always contextual." > > > > > >

Jan. 9, 2016