- Pharo-dev - lists.pharo.org

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

BlueInk shouldn't add parentheses when not needed

by Peter UhnÃ¡k

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] [ANN] Pharo Consortium New Bronze Member: feenk

by Tudor Girba

Hi, An extra note to the announcement: Due to the 2016 campaign for extending the reach of the consortium, the Pharo Consortium receives from a generous external fund an extra amount corresponding to one year fee for any new members or the difference for any upgrading members. More details about the campaign can be found at: http://consortium.pharo.org/web/membership Cheers, Doru > On May 6, 2016, at 9:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > The Pharo Consortium is very happy to announce that feenk > has joined the Consortium as a Bronze Member. > > About > - feenk: http://www.feenk.com > - Pharo Consortium: http://consortium.pharo.org > > The goal of the Pharo Consortium is to allow companies and institutions to > support the ongoing development and future of Pharo. > > Individuals can support Pharo via the Pharo Association: > > - http://association.pharo.org > - https://salt.bountysource.com/teams/pharo > -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

May 6, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50751 Home: https://github.com/pharo-project/pharo-core

May 6, 2016