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

Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0

by Tudor Girba

Hi, > On Jan 8, 2016, at 7:28 PM, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: > > Hi, > > with a moldable debugger we should (in the future) be able to support > debugging also different/other programming languages/DSLs in Pharo :) Yes. This would work quite well if the language would project on the AST of Pharo, like Helvetia does. > - although usually one does necessary have such a use case. So I guess > GTInspector or other will be adopted to own needs more than GTDebugger. The debugger can be specialized for specific libraries or frameworks, not necessarily only languages. For example, we currently have extensions for PetitParser, Glamour, Announcements. I expect that every framework would benefit from a specialized debugger. This would not be an odd behavior at all. > However: > The only objection so far is that I dislike the order/size of the panes. > The placement of the panes in GTDebugger (as for instance found in Moose) > requires often to use the scrollbars of the pane showing the stack because > of the text length. > > In GTDebugger the stack is at the top left, the source at the top right with > a common splitter beneath the two panes: therefore the height (depth) of the > stack pane is always the height of the code pane. > When you have a long method to debug on the right much space is wasted for > a deep stack on the left although you might only be interested in a few top frames. > > Contrary when you have are interested in a deep/full stack and you increase the > height of the stack pane on the left you directly increase the height of the code > pane and for short methods you waste a lot of space in the source pane as well. > > This is much better solved with the positioning in the traditinal Debugger: > - Stack > - Source > - other > > So in my opinion We should preserve: > > - TOP: the stack at the top (using the full width of the window, so only vertical scrolling > has to be done to "roll" on the stack, no need for horizontal scrolling as the area > is wide enough) > - MIDDLE: the source code pane in the middle (also using the full width of the window and there > fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) > - BOTTON: one or more panel for inspection at the bottom > > It would be OK for me if others like the new layout better - but at least there should be an > option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) Thanks. We took this into account. > Also the debugger window in Moose wastes a lot of space/has unused space within the > windows client are itself. For instance the splitters are very thick which might be an issue of > the moose theme. Thanks. We reduced the splitter size in Glamour. Doru > Thanks > T. > > Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr > Von: "Tudor Girba" <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch <mailto:moose-dev@iam.unibe.ch>>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 > > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. > > First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. > > A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. > > > While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). > > > > Here is an introductory overview blog post that also includes some links for further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ <http://www.humane-assessment.com/blog/gtdebugger-in-pharo/> > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/>[http://www.tudorgirba.com <http://www.tudorgirba.com/>] > www.feenk.com <http://www.feenk.com/>[http://www.feenk.com <http://www.feenk.com/>] > > "Beauty is where we see it." -- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/> "Presenting is storytelling."

Jan. 9, 2016

Re: [Pharo-dev] Understanding Spotter?

by Tudor Girba

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

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Tudor Girba

Hello everyone, As expected, there was some feedback. Here is a summary: 1. The layout should mirror the classic debugger - The previous layout was chosen to show more of the stack and to make use of the screen real estate. - But, as that is not an essential component of GTDebugger, the current implementation of the generic stack debugger looks like this now: 2. it would be interesting if the buttons would have text - This is something we need to work on 3. Why is there bytecode shown? - There is none by default :). This only appears when the developer explicitly chooses the Bytecode debugger 4. why is there a _thisContext _stackTop? - Because this is what the SpecDebugger offers as well :). - But, we removed them for now from the list. - There would be a possibility to add them to the context menu of the stack or to add them to bottom of the list 5. why is there a Type column in the inspector - Because we want to know what kind of variable we are dealing with (parameter, instvar, temp). This is not explicit in other debuggers. - Furthermore, you can filter the variables by clicking on the type tag. This can be particularly useful when we deal with large states. Please let me know if I missed anything. Of these only point 2 requires work. Cheers, Doru > On Jan 8, 2016, at 1:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. > > First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. > > A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. > > While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). > > For example, the core configuration includes also the SUnit and the bytecode debugger. These are around 150 lines of code. Here is how the bytecode debugger looks like: > > <bytecode.png> > > You can find more information in an introductory overview blog post that also includes some links for further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

Jan. 9, 2016

Re: [Pharo-dev] Little challenge

by stepharo

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.

Jan. 9, 2016

Re: [Pharo-dev] Idea to improve GTInspector

by Tudor Girba

Thanks. Try this. Class>>gtInspectorDefinitionIn: composite <gtInspectorPresentationOrder: 15> composite pharoScript title: 'Definition'; display: [ self definition ] I committed it in the latest GTInspector. It took 2 minutes. Doru > On Jan 9, 2016, at 11:14 PM, stepharo <stepharo(a)free.fr> wrote: > > We cannot see the class definition when browsing a collection of classes. > > -- 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."

Jan. 9, 2016

Re: [Pharo-dev] Understanding Spotter?

by Dimitris Chloupis

video tutorial like this one ? https://www.youtube.com/watch?v=mNh6VtPy8m4 On Sat, Jan 9, 2016 at 11:02 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 > >

Jan. 9, 2016

Idea to improve GTInspector

by stepharo

We cannot see the class definition when browsing a collection of classes.

Jan. 9, 2016

Little challenge

by stepharo

We are trying to find examples of variableSubclass:... and with source code we could not find them. Even looking in all the code did not work. finally Object allSubclasses select: #isVariable worked but it would be good that search to the code would take into account classdefinitions. Or may be it does. Stef and Luc working on the Pharo Mooc

Jan. 9, 2016

Understanding Spotter?

by stepharo

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

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Nicolai Hess

2016-01-09 20:52 GMT+01:00 Francisco Ortiz PeÃ±aloza <patchinko(a)gmail.com>: > Hi, > > i would like to have the GTDebugger in the near future. Great job and > thanks! > > I like the Esteban built instead of the original one and i agree with stef > on removing _stack and _thisContext from top and the bytecode view. Aim to > simplicity must be a top priority and if anybody needs something more > specific can change it easily (its moldable!) > I often use thisContext and stackTop for inspecting the current context (I use this a lot when debugging compiler errors) and the stackTop when stepping through cascaded message send, I want to see the intermediate return value. > > Cheers > Francisco > > > > On Sat, Jan 9, 2016 at 12:07 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> > wrote: > >> http://ws.stfx.eu/3KXXDAJ4EUF6 >> >> >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Stephan Eggermont >> Sent: Saturday, January 9, 2016 3:36 PM >> To: pharo-dev(a)lists.pharo.org >> Subject: Re: [Pharo-dev] gtdebugger in pharo 5.0 >> >> On 09-01-16 12:39, Dimitris Chloupis wrote: >> > there has been around a script to automate the screenshots, but >> > personally I never bother using it because taking a screenshot and >> > inserting in pillar is the easiest thing. >> >> AFAIK the hard part is keeping things up to date. That's where automation >> helps. >> >> Stephan >> >> >> >> >

Jan. 9, 2016