- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] Re: extending GTDebugger

by Peter UhnÃ¡k

Hi Andrei, well I don't know exactly what I want... my initial idea was to quickly stick something together and see what is available to me and what I can do. But the overall idea is to extend the debugger to see metalinks-related infoâ¦ such as the currently installed metalinks in a method, which one was called, stepping into and over the metalinks, etc. But I'll start small with some windows and slowly see where I can go from there. Alsoâ¦ does the debugger uses regular Glamour? Can I read the Glamour docs to help me understand it? (I remember reading about Glamour long time ago and it had things like transmissions and portsâ¦ so maybe I can learn the behavior there.) Thanks, Peter On Fri, May 6, 2016 at 4:23 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi Peter, > > Yes, extending the debugger is more work than extending the inspector. > However it depends on what you want to do. Do you need to change the UI of > the debugger or just add new actions? > > To create a new UI you need to subclass GTSUnitDebugger and > override debuggerStructureIn: and debuggerTransmissionsIn:. You can the > extend the UI using glamour presentations. On the class side of your UI you > need to implement #defaultTitle, #handlesContext:. If you need to customize > it more you can override at #helpClass, #sessionClass, > #variablesBrowserClass and #availableAutomatically. > > To create new actions you need to create subclasses of DebugAction. There > are a lot of examples in the image. To link a action with a UI widget you > need to add to the class side a method that just has an annotation. > Different widgets load actions that have various annotations. For example > the stack widget loads actions annotated with #gtStackDebuggingAction. > > Let me know if you need more information to get started. Unfortunately > there isn't a guide that you can use. > > Cheers, > Andrei > > > > On Fri, May 6, 2016 at 2:54 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> Hi, >> >> is there some guide / help how to extend the GTDebugger? >> >> I tried to take a look at SUnit/PParser but it looks quite complexâ¦ >> certainly more complex than extending Inspector. :) >> >> Thanks, >> Peter >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >

May 7, 2016

Jenkins CI error

by Esteban A. Maringolo

Who is in charge of the Jenkins installation for http://ci.inria.fr/dbxtalk. I'm trying to modify certain projects and I'm getting the following error: Error JSONObject["scm"] is not a JSONObject. I tried some hacks to make it work, but no luck. Did this happen to somebody else? How to fix it? Regards! Esteban A. Maringolo

May 6, 2016

Re: [Pharo-dev] BlueInk shouldn't add parentheses when not needed

by Alistair Grant

On 6 May 2016 at 10:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I have seen this too, and I hate it as well. > > I would definitively prefer the minimal syntax: no parenthesis when not needed, not extra $# when not needed. > >> On 06 May 2016, at 10:26, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> And second, perhaps less important... do we really need to reformat #(name owner uuid) into #(#name #owner #uuid)? Seems a bit superfluous too. I'll put in a vote the other way. As a new-to-Pharo user it is much faster for me to understand what is happening with the #'s present. Cheers, Alistair

May 6, 2016

Re: [Pharo-dev] [Moose-dev] extending GTDebugger

by Andrei Chis

Hi Peter, Yes, extending the debugger is more work than extending the inspector. However it depends on what you want to do. Do you need to change the UI of the debugger or just add new actions? To create a new UI you need to subclass GTSUnitDebugger and override debuggerStructureIn: and debuggerTransmissionsIn:. You can the extend the UI using glamour presentations. On the class side of your UI you need to implement #defaultTitle, #handlesContext:. If you need to customize it more you can override at #helpClass, #sessionClass, #variablesBrowserClass and #availableAutomatically. To create new actions you need to create subclasses of DebugAction. There are a lot of examples in the image. To link a action with a UI widget you need to add to the class side a method that just has an annotation. Different widgets load actions that have various annotations. For example the stack widget loads actions annotated with #gtStackDebuggingAction. Let me know if you need more information to get started. Unfortunately there isn't a guide that you can use. Cheers, Andrei On Fri, May 6, 2016 at 2:54 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > is there some guide / help how to extend the GTDebugger? > > I tried to take a look at SUnit/PParser but it looks quite complexâ¦ > certainly more complex than extending Inspector. :) > > Thanks, > Peter > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >

May 6, 2016

Re: [Pharo-dev] About PharoInProgress book

by Damien Pollet

Listings can be floating (like figures) or not; I'd still recommend to float the larger ones, especially if you want to refer to them from several places, because for those, you need a number/caption and an entry in the list of illustrations. Floating is more or less independent from the label and caption, but IMHO it makes more sense. I'm not sure of the details, but maybe you'll have to update how you marked them up in Pillar to work as needed with the new LaTeX class. Check the pillar chapter or its readme file on github. On 6 May 2016 at 04:27, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Damien: > > One thing I noticed with the new PDF rendering is that the code > listings does not appear in the order they are in the Pillar file, so > I can't be sure that a code block will follow a certain paragraph, > hence I can't say "in the following example code", because the example > might have appeared three paragraphs ago. > > Can that be avoided? And if not... how can I "link" or add a reference > to such code block? > > Regards! > > Esteban A. Maringolo > > > 2016-05-04 4:14 GMT-03:00 stepharo <stepharo(a)free.fr>: > > Yes this is on my todo. > > > > > > Le 3/5/16 Ã 14:01, Damien Pollet a Ã©crit : > > > > The interns updated the stable release of Pillar; there is a mention of > the > > listings package in the log, which suggests that pillar outputs TeX code > for > > the new sbabook class instead of the old one. That should be fixable by > > finding the correct version of Pillar to use, but the correct long-term > fix > > is to migrate to sbabook. > > > > On 27 April 2016 at 22:28, Esteban A. Maringolo <emaringolo(a)gmail.com> > > wrote: > >> > >> I sent an email this morning about this issue, apparently it has to do > >> with a missing font. > >> > >> Esteban A. Maringolo > >> > >> > >> 2016-04-27 16:50 GMT-03:00 stepharo <stepharo(a)free.fr>: > >> > Hi > >> > > >> > I tried to fix the build on jenkins but I failed. I do not know how to > >> > fix > >> > it. > >> > > >> > I do not know how to fix. Probably the changes in Pillar broke it. > >> > > >> > Now since Damien will quit our team, I wonder what will be the future > of > >> > pillar, may be markdown and for me LaTeX > >> > > >> > Stef > >> > > >> > > >> > > >> > ./AWS.tex:40: LaTeX Error: Environment listing undefined. > >> > > >> > See the LaTeX manual or LaTeX Companion for explanation. > >> > Type H <return> for immediate help. > >> > ... > >> > > >> > l.40 \begin{listing} > >> > [language=smalltalk] > >> > Your command was ignored. > >> > Type I <command> <return> to replace it with another command, > >> > or <return> to continue without it. > >> > > >> > > >> > ./AWS.tex:53: LaTeX Error: \begin{document} ended by \end{listing}. > >> > > >> > See the LaTeX manual or LaTeX Companion for explanation. > >> > Type H <return> for immediate help. > >> > ... > >> > > >> > l.53 \end{listing} > >> > > >> > Your command was ignored. > >> > Type I <command> <return> to replace it with another command, > >> > or <return> to continue without it. > >> > > >> > No file AWS.bbl. > >> > > >> > > >> > > > > > > > > -- > > Damien Pollet > > type less, do more [ | ] http://people.untyped.org/damien.pollet > > > > > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 6, 2016

extending GTDebugger

by Peter UhnÃ¡k

Hi, is there some guide / help how to extend the GTDebugger? I tried to take a look at SUnit/PParser but it looks quite complexâ¦ certainly more complex than extending Inspector. :) Thanks, Peter

May 6, 2016

Re: [Pharo-dev] BlueInk shouldn't add parentheses when not needed

by Peter UhnÃ¡k

> > parent isArray ifTrue: [ ^ false ]. Wow this actually seems to work, thanks! We could integrate it for Pharo 6. As for the Literal Array, this appears to solve it BlConfigurableFormatter>>visitLiteralNode: aLiteralNode aLiteralNode value isLiteral ifFalse: [ ^ self writeString: '''<an unprintable nonliteral value>''' ]. aLiteralNode parent isLiteralArray ifTrue: [ self writeString: (aLiteralNode sourceText withoutPrefix: '#') ] ifFalse: [ self writeString: aLiteralNode sourceText ]

May 6, 2016

Re: [Pharo-dev] BlueInk shouldn't add parentheses when not needed

by Sven Van Caekenberghe

I have seen this too, and I hate it as well. I would definitively prefer the minimal syntax: no parenthesis when not needed, not extra $# when not needed. > On 06 May 2016, at 10:26, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > I thought that I already asked about this but apparently not... > > Right now when I have an array like > > observations := { > MElement -> { > #change -> #(name owner uuid). > #add -> #(). > #remove -> #() > }. > > MContainer -> { > #change -> #(). > #add -> #(add:). > #remove -> #(remove:). > }. > }. > > it gets formatted into > > observations := {(MElement > -> > {(#change -> #(#name #owner #uuid)). > (#add -> #()). > (#remove -> #())}). > (MContainer > -> > {(#change -> #()). > (#add -> #(#add:)). > (#remove -> #(#remove:))})}. > > Which is really ugly with all the _uneeded_ parenthesis. > > I tried to look into BlConfigurableFormatter>>needsParenthesisFor: where it is being added, but any change I try to make I end up breaking some test as the behavior is not very obvious for me. > > Can this be changed/fixed easily? > > > And second, perhaps less important... do we really need to reformat #(name owner uuid) into #(#name #owner #uuid)? Seems a bit superfluous too. > > Thanks, > Peter > >

May 6, 2016

Re: [Pharo-dev] BlueInk shouldn't add parentheses when not needed

by Nicolai Hess

2016-05-06 10:26 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > I thought that I already asked about this but apparently not... > > Right now when I have an array like > > observations := { > MElement -> { > #change -> #(name owner uuid). > #add -> #(). > #remove -> #() > }. > > MContainer -> { > #change -> #(). > #add -> #(add:). > #remove -> #(remove:). > }. > }. > > it gets formatted into > > observations := {(MElement > -> > {(#change -> #(#name #owner #uuid)). > (#add -> #()). > (#remove -> #())}). > (MContainer > -> > {(#change -> #()). > (#add -> #(#add:)). > (#remove -> #(#remove:))})}. > > Which is really ugly with all the _uneeded_ parenthesis. > > I tried to look into BlConfigurableFormatter>>needsParenthesisFor: where > it is being added, but any change I try to make I end up breaking some test > as the behavior is not very obvious for me. > would this help (added to the very start of needsParenthesisFor: , after checking that parent isn't nil) : parent isArray ifTrue: [ ^ false ]. > > Can this be changed/fixed easily? > > > And second, perhaps less important... do we really need to reformat #(name > owner uuid) into #(#name #owner #uuid)? Seems a bit superfluous too. > > Thanks, > Peter > > >

May 6, 2016

Disable formatting per-method (via pragma?)

by Peter UhnÃ¡k

Hi, I use formatter all the time as I like to have uniform code. Because it's not perfect I sometimes purposefully replace things like {(#a -> #b). (#c -> #d)} with Array with: #a -> #b with: #c -> #d just so I have better control of the formatting... However sometimes (especially for code intended for playground) it's best to not apply the formatting at all. As I have already developed the habit of autoformatting it's a bit hard to not apply it sometimes. Would it be possible to add a pragma to the method or something... <BlueInk: #disabled> or something that wouldn't apply the formatting? Thanks, Peter

May 6, 2016