June 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Debugger Button Positioning

by Eliot Miranda

Hi Doru, On Sat, Jun 16, 2018 at 2:25 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > This is indeed an issue we should have solved. The concatenation of pragma > selectors is unnecessary in this case, but we did not clean it up and it > remained like this. > If the issue is that one wants generosity at the reference (in the actions methods that provide what should be pragma names) and specificity at the referent (the methods containing the pragmas) then one can add a second pragma and use and "and" function to insist on the pragma plus another qualifier. For example, StepOverDebugAction class>>gtStackDebuggingActionFor: aDebugger <gtStackDebuggingAction> ^ (self forDebugger: aDebugger) icon: GLMUIThemeExtraIcons glamorousOver could become StepOverDebugAction class>>gtStackDebuggingActionFor: aDebugger <stackDebuggingAction> <GlamorousDebugger> ^ (self forDebugger: aDebugger) icon: GLMUIThemeExtraIcons glamorousOver but I suspect that's not necessary here because all these methods exist in a class hierarchy that can provide the context and specificity required. But in this case it seems to me that there's a deeper weakness/opportunity. The meat of each class is the executeAction method, for example StepOverDebugAction >>executeAction self session stepOver: self currentContext why not add the pragma there and dispense with the gtStackDebuggingActionFor: methods altogether. For example, you could include a pragma identifying the method as an action, and a pragma to be used by a builder to add the action, or at least specify the parameters: StepOverDebugAction >>executeAction <stackDebuggingAction> <uiThemeIcon: #glamorousOver hotKey: $H> "This could be performed by a builder class specific to building glamorous debuggers, or glamorous tools, or..." self session stepOver: self currentContext This second pragma could have as many keywords and arguments as one wants, and serves to reduce the additional machinery one needs to "plug" something in. In general the pattern is to annotate some action or entry point method with pragmas that specify how the method fits in to some larger context, so for example, - an action method on a menu, where a single pragma can specify the label, icon, hot key, and menu name, using a message understood by a menu decorator that would perform the pragma to add it to the menu (and then if there is a hook on the class side that is looking for method additions and removals, menus in live tools can update as soon as a method containing such a pragma is added or removed) - an entry point for some exported interface, such as a COM interface, where the pragma specifies the types of the incoming parameters, and hence as the method is installed into some built interface, the relevant marshaling machinery is built, rather than being specified off to the side Used in this way, information about how a component fits in can be localized in the key method(s) providing the component, instead of being spread over several methods, reducing load on the programmer in comprehending and adding similar actions. > Cheers, > Doru > > > > > On Jun 16, 2018, at 8:58 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > Hi Tim, > > > > On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon <tim(a)testit.works> wrote: > >> The whole point about pragmas is that they're supposed to be messages, > and hence senders (and if possible, implementors) work. But with the > mangling that occurs here, a simple senders of stackDebuggingActions brings > nothing, and one is left manually searching the system before one finds > references to gtStackDebuggingAction. Obscure and hence horrible. > > > > Hi Eliot - Iâve been caught out by that belief too - but if you select a > pragma and do cmd-b, cmd-n (or menu code-search, senders of it) - it works > How I think you are expecting and shows you all the senders of that pragma. > I use this all of the time for remember how to implement GT-Inspector tabs > , as I was always impressed with the one in Date and use it as a way to > find lots of good examples. > > > > It could be, that you tried âimplementers ofâ - and that one always > confuses me - partly because they arenât a real thing (and I guess I agree > with you on a distaste for them - it feels like we could have done better > somehow?). > > > > These aren't the issues here. The issue here is the classic one of name > mangling, a.k.a. constructing selectors from fragments, so that the > reference (the elements of the arrays in codeDebuggingPragmas and > stackDebuggingActionPragmas, which are #codeDebuggingAction > #stackDebuggingAction) don't match the pragmas in the methods, which are > <gtCodeDebuggingAction> & <gtStackDebuggingAction>. Why the mismatch? I > would expect the references to use #gtCodeDebuggingAction & > #gtStackDebuggingAction, and finding the implementations would be trivial. > Instead one has to hunt. This is bad. > > > > > > Tim > > > > > >> On 15 Jun 2018, at 00:23, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> > >> Hi Henrik, > >> > >> On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <draagren(a)outlook.com> > wrote: > >> Hi, > >> > >> Moving the icons down to the middle row is as simple as changing: > >> > >> *** > >> codeActionsPragmas > >> ^ #( stackDebuggingActions codeDebuggingActions ) > >> *** > >> *** > >> stackDebuggingActionsPragmas > >> ^ #() > >> *** > >> > >> in GTGenericStackDebugger. > >> > >> Best regards, > >> Henrik > >> > >> Thanks. I have to say that the renaming from #stackDebuggingActions to > gtStackDebuggingAction, as in > >> > >> StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger > >> <gtStackDebuggingAction> > >> > >> is a cruel joke. The whole point about pragmas is that they're > supposed to be messages, and hence senders (and if possible, implementors) > work. But with the mangling that occurs here, a simple senders of > stackDebuggingActions brings nothing, and one is left manually searching > the system before one finds references to gtStackDebuggingAction. Obscure > and hence horrible. > >> > >> _,,,^..^,,,_ > >> best, Eliot "I designed pragmas to be useful and natural, not painful > and obscure" Miranda > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > -- > www.tudorgirba.com > www.feenk.com > > "There are no old things, there are only old ways of looking at them." > > > > > > -- _,,,^..^,,,_ best, Eliot

June 16, 2018

Re: [Pharo-dev] ZnUrl and mailto

by Sean P. DeNigris

Sean P. DeNigris wrote > Re-reading the rfc I'm still not entirely clear Apparently, multiple mailto addresses are inherently problematic [2], and the only real/safe/valid solution is using a web form! 2. https://stackoverflow.com/questions/9278363/emailing-to-multiple-recipients… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 16, 2018

Re: [Pharo-dev] ZnUrl and mailto

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > other variants feel out of scope I guess. That makes sense. Re-reading the rfc I'm still not entirely clear (numbered bullets added): Also note that it is syntactically valid to specify both <to> and an <hfname> whose value is "to". That is, #1 <mailto:addr1@an.example,addr2@an.example> is equivalent to #2 <mailto:?to=addr1@an.example,addr2@an.example> is equivalent to #3 <mailto:addr1@an.example?to=addr2@an.example> However, the latter form is NOT RECOMMENDED because different user agents handle this case differently. In particular, some existing clients ignore "to" <hfvalue>s. Is anyone clear whether "latter" and the warning that "to" <hfvalue>s may be ignored refers to just #3 or #2 as well? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 16, 2018

Re: [Pharo-dev] ZnUrl and mailto

by Sven Van Caekenberghe

I didn't even know that multiple addresses were possible. As you know, URL's can basically be anything, it does not seem possible to handle them all. ZnUrl covers the most common cases, that is already something. Indeed, as you can see from #testMailTo there is basic support for the mailto: scheme which seems to match the existing instance variables, other variants feel out of scope I guess. > On 16 Jun 2018, at 15:17, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I have a ZnUrl subclass MailtoUrl. It was working for simple cases, but then > I realized that ZnUrl assumes a single username. At first, I figured maybe > mailto was such a specialized case that it wouldn't be worth reexamining, > but then I noticed that ZnUrl implemented #mailToAddress so I figured it was > at least worth asking about. > > The reason it seems important to specify the users this way is that, > although the rfc [1] allows users to be specified in the query, it also says > that "[that] form is NOT RECOMMENDED becauseâ¦ some existing clients ignore > "to" <hfvalue>s." > > 1. https://tools.ietf.org/html/rfc6068 > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

June 16, 2018

ZnUrl and mailto

by Sean P. DeNigris

I have a ZnUrl subclass MailtoUrl. It was working for simple cases, but then I realized that ZnUrl assumes a single username. At first, I figured maybe mailto was such a specialized case that it wouldn't be worth reexamining, but then I noticed that ZnUrl implemented #mailToAddress so I figured it was at least worth asking about. The reason it seems important to specify the users this way is that, although the rfc [1] allows users to be specified in the query, it also says that "[that] form is NOT RECOMMENDED becauseâ¦ some existing clients ignore "to" <hfvalue>s." 1. https://tools.ietf.org/html/rfc6068 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 16, 2018

Re: [Pharo-dev] Debugger Button Positioning

by Tudor Girba

Hi, This is indeed an issue we should have solved. The concatenation of pragma selectors is unnecessary in this case, but we did not clean it up and it remained like this. Cheers, Doru > On Jun 16, 2018, at 8:58 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Tim, > > On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon <tim(a)testit.works> wrote: >> The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible. > > Hi Eliot - Iâve been caught out by that belief too - but if you select a pragma and do cmd-b, cmd-n (or menu code-search, senders of it) - it works How I think you are expecting and shows you all the senders of that pragma. I use this all of the time for remember how to implement GT-Inspector tabs , as I was always impressed with the one in Date and use it as a way to find lots of good examples. > > It could be, that you tried âimplementers ofâ - and that one always confuses me - partly because they arenât a real thing (and I guess I agree with you on a distaste for them - it feels like we could have done better somehow?). > > These aren't the issues here. The issue here is the classic one of name mangling, a.k.a. constructing selectors from fragments, so that the reference (the elements of the arrays in codeDebuggingPragmas and stackDebuggingActionPragmas, which are #codeDebuggingAction #stackDebuggingAction) don't match the pragmas in the methods, which are <gtCodeDebuggingAction> & <gtStackDebuggingAction>. Why the mismatch? I would expect the references to use #gtCodeDebuggingAction & #gtStackDebuggingAction, and finding the implementations would be trivial. Instead one has to hunt. This is bad. > > > Tim > > >> On 15 Jun 2018, at 00:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Henrik, >> >> On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <draagren(a)outlook.com> wrote: >> Hi, >> >> Moving the icons down to the middle row is as simple as changing: >> >> *** >> codeActionsPragmas >> ^ #( stackDebuggingActions codeDebuggingActions ) >> *** >> *** >> stackDebuggingActionsPragmas >> ^ #() >> *** >> >> in GTGenericStackDebugger. >> >> Best regards, >> Henrik >> >> Thanks. I have to say that the renaming from #stackDebuggingActions to gtStackDebuggingAction, as in >> >> StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger >> <gtStackDebuggingAction> >> >> is a cruel joke. The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible. >> >> _,,,^..^,,,_ >> best, Eliot "I designed pragmas to be useful and natural, not painful and obscure" Miranda > > > > > -- > _,,,^..^,,,_ > best, Eliot -- www.tudorgirba.com www.feenk.com "There are no old things, there are only old ways of looking at them."

June 16, 2018

Re: [Pharo-dev] @pharoproject: > 2000 followers

by Tudor Girba

Great news! Doru > On Jun 15, 2018, at 11:11 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > @pharoproject on twitter now has >2000 followers: https://twitter.com/pharoproject -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

June 16, 2018

Re: [Pharo-dev] Debugger Button Positioning

by Eliot Miranda

Hi Tim, On Fri, Jun 15, 2018 at 2:21 PM, Tim Mackinnon <tim(a)testit.works> wrote: > The whole point about pragmas is that they're supposed to be messages, and > hence senders (and if possible, implementors) work. But with the mangling > that occurs here, a simple senders of stackDebuggingActions brings nothing, > and one is left manually searching the system before one finds references > to gtStackDebuggingAction. Obscure and hence horrible. > > > Hi Eliot - Iâve been caught out by that belief too - but if you select a > pragma and do cmd-b, cmd-n (or menu code-search, senders of it) - it works > How I think you are expecting and shows you all the senders of that pragma. > I use this all of the time for remember how to implement GT-Inspector tabs > , as I was always impressed with the one in Date and use it as a way to > find lots of good examples. > > It could be, that you tried âimplementers ofâ - and that one always > confuses me - partly because they arenât a real thing (and I guess I agree > with you on a distaste for them - it feels like we could have done better > somehow?). > These aren't the issues here. The issue here is the classic one of name mangling, a.k.a. constructing selectors from fragments, so that the reference (the elements of the arrays in codeDebuggingPragmas and stackDebuggingActionPragmas, which are #codeDebuggingAction #stackDebuggingAction) don't match the pragmas in the methods, which are <gtCodeDebuggingAction> & <gtStackDebuggingAction>. Why the mismatch? I would expect the references to use #gtCodeDebuggingAction & #gtStackDebuggingAction, and finding the implementations would be trivial. Instead one has to hunt. This is bad. > Tim > > > On 15 Jun 2018, at 00:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Henrik, > > On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <draagren(a)outlook.com> > wrote: > >> Hi, >> >> Moving the icons down to the middle row is as simple as changing: >> >> *** >> codeActionsPragmas >> ^ #( stackDebuggingActions codeDebuggingActions ) >> *** >> *** >> stackDebuggingActionsPragmas >> ^ #() >> *** >> >> in GTGenericStackDebugger. >> >> Best regards, >> Henrik >> > > Thanks. I have to say that the renaming from #stackDebuggingActions to > gtStackDebuggingAction, as in > > StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger > <gtStackDebuggingAction> > > is a cruel joke. The whole point about pragmas is that they're supposed > to be messages, and hence senders (and if possible, implementors) work. > But with the mangling that occurs here, a simple senders of > stackDebuggingActions brings nothing, and one is left manually searching > the system before one finds references to gtStackDebuggingAction. Obscure > and hence horrible. > > _,,,^..^,,,_ > best, Eliot "I designed pragmas to be useful and natural, not painful and > obscure" Miranda > > > -- _,,,^..^,,,_ best, Eliot

June 16, 2018

Re: [Pharo-dev] Debugger Button Positioning

by Tim Mackinnon

> The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible. Hi Eliot - Iâve been caught out by that belief too - but if you select a pragma and do cmd-b, cmd-n (or menu code-search, senders of it) - it works How I think you are expecting and shows you all the senders of that pragma. I use this all of the time for remember how to implement GT-Inspector tabs , as I was always impressed with the one in Date and use it as a way to find lots of good examples. It could be, that you tried âimplementers ofâ - and that one always confuses me - partly because they arenât a real thing (and I guess I agree with you on a distaste for them - it feels like we could have done better somehow?). Tim > On 15 Jun 2018, at 00:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Henrik, > > On Thu, Jun 14, 2018 at 12:47 PM, Henrik-Nergaard <draagren(a)outlook.com <mailto:draagren@outlook.com>> wrote: > Hi, > > Moving the icons down to the middle row is as simple as changing: > > *** > codeActionsPragmas > ^ #( stackDebuggingActions codeDebuggingActions ) > *** > *** > stackDebuggingActionsPragmas > ^ #() > *** > > in GTGenericStackDebugger. > > Best regards, > Henrik > > Thanks. I have to say that the renaming from #stackDebuggingActions to gtStackDebuggingAction, as in > > StepIntoDebugAction class>>gtStackDebuggingActionFor: aDebugger > <gtStackDebuggingAction> > > is a cruel joke. The whole point about pragmas is that they're supposed to be messages, and hence senders (and if possible, implementors) work. But with the mangling that occurs here, a simple senders of stackDebuggingActions brings nothing, and one is left manually searching the system before one finds references to gtStackDebuggingAction. Obscure and hence horrible. > > _,,,^..^,,,_ > best, Eliot "I designed pragmas to be useful and natural, not painful and obscure" Miranda

June 15, 2018

Re: [Pharo-dev] memory leak

by Marcus Denker

> On 2 Jun 2018, at 17:53, John Brant <brant(a)refactoryworkers.com> wrote: > > On 05/26/2018 05:21 AM, Tudor Girba wrote: >> Yes, Glamour is stable since years. Yes, we did have some leak issues that appeared along the way. Last year, we discovered that a memory leak came from Rubric (specifically there was a global variable in it). People saw inspectors laying around, so naturally, the issue was seen as being due to GT. And now there is another one, which is still under investigation. For me, the main issue is not the memory leak, but the fact that we have no tool to reason about them. > > I found a memory leak in GLMHintableActionButtonBrick. It has an > asyncTask class instance variable that holds a GLMAsyncTask. After > running for a while -- opening and closing inspectors and other tools, I > closed several windows, did a GC and expected to not have any AST nodes > hanging around. However, I found several, so I used my ReferenceFinder > tool to find a reference path. That path went through the > GLMHintableActionButtonBrick to a GLMAsyncTask to a block that holds a > reference to a GLMHintableActionButtonBrick instance. Following > references out of the GLMHintableActionButtonBrick instance eventually > leads to a NodeMorph which has a NodeModel that contained my AST node. > Thanks, I have added it to the issue tracker to not lose it: https://pharo.fogbugz.com/f/cases/22163/Memory-Leak-GLMHintableActionButton…

June 15, 2018