- Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-dev] [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-users] 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-users] Crash or locked VM

by Hilaire

With the fix I explored a bit further the construction tree with the Athletic tree https://www.facebook.com/DrGeoLibre/videos/895237543929818/ ;) Le 09/01/2016 10:30, Hilaire a Ã©crit : > Le 09/01/2016 00:30, Nicolai Hess a Ã©crit : >> Hi Hilaire, >> >> I think this is the same bug as >> https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-li… >> >> this is fixed in pharo4.0 and pharo5.0 but not in pharo3.0 >> I modified the changeset for pharo4.0 to make it loadable in pharo3.0 >> But I did not looked further on the code changes, maybe it won't fully >> work. >> Find attached the changeset. You have to switch compiler class before >> and after loading this. >> >> SmalltalkImage compilerClass: Compiler. >> 'opal_drgeo.cs' asFileReference fileIn. >> SmalltalkImage compilerClass: OpalCompiler. >> >> > It works! > Ouf! Reading at the issue , that's quite an important one. Thanks for > the retro-fix for Pharo3. It is important for people still in mark3 not > yet migrated to subsequent release > > Hilaire > > -- Dr. Geo http://drgeo.eu

Jan. 9, 2016

Re: [Pharo-users] Crash or locked VM

by Hilaire

Le 09/01/2016 00:30, Nicolai Hess a Ã©crit : > Hi Hilaire, > > I think this is the same bug as > https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-li… > > this is fixed in pharo4.0 and pharo5.0 but not in pharo3.0 > I modified the changeset for pharo4.0 to make it loadable in pharo3.0 > But I did not looked further on the code changes, maybe it won't fully > work. > Find attached the changeset. You have to switch compiler class before > and after loading this. > > SmalltalkImage compilerClass: Compiler. > 'opal_drgeo.cs' asFileReference fileIn. > SmalltalkImage compilerClass: OpalCompiler. > > It works! Ouf! Reading at the issue , that's quite an important one. Thanks for the retro-fix for Pharo3. It is important for people still in mark3 not yet migrated to subsequent release Hilaire -- Dr. Geo http://drgeo.eu

Jan. 9, 2016

Re: [Pharo-users] Interogation about recursivity or sequential

by stepharo

I propose this as an exercise. Now I was not aware that we have doubleLinkedList in the system. I do not get why DoubleLinkedList is packaged in System-Caching and not Collections-DoubleLinkedList? https://pharo.fogbugz.com/f/cases/17360/DoubleLinkedList-should-be-packaged… Stef Le 5/1/16 02:50, Peter UhnÃ¡k a Ã©crit : > Wouldn't it be better to improve the current (Double)LinkedList > instead of creating new ones? DLL had some improvements recently and I > am not aware that it's missing something. > > On Mon, Jan 4, 2016 at 10:34 PM, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > Hi Yann, > > > On 04 Jan 2016, at 22:11, Yann Dubois <yann59.dubois(a)gmail.com > <mailto:yann59.dubois@gmail.com>> wrote: > > > > Hello World, Happy new year 2016 ! > > And to you too. > > > I actually work on an integration of a double linked list on > Pharo and I have a little interogation. > > It's better to use recursivity or senquential algorithm ? > > Recursive is often cleaner, sequential is often faster. > > > Yann > > There is already a (minimal) DoubleLinkedList in the image ... > > Sven > >

Jan. 9, 2016

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

by Offray Vladimir Luna CÃ¡rdenas

Hi, Lets try something simpler. Consider this code: ============================= | data m1 m2 | data := { 'first' -> 'I\"m just text' . 'second' -> 'ProfStef openPharoZenWorkspace'} asOrderedDictionary. m1 := DynamicComposableModel new. m1 instantiateModels: #(list ListModel). m1 list items: (data keys). m1 layout: (SpecLayout composed add: #list; yourself). m2 := DynamicComposableModel new. m2 instantiateModels: #(right TextModel). m2 assign: m1 to: #left. m1 list whenSelectedItemChanged: [:item | item ifNil: [ m2 instantiateModels: #(right TextModel). m2 right text: '' ] ifNotNil: [ item = 'first' ifTrue: [ m2 instantiateModels: #(right TextModel). Transcript show: m2 right asString, String cr ]. item = 'second' ifTrue: [ m2 instantiateModels: #(right GlamourPresentationModel). Transcript show: m2 right asString, String cr]. ] ]. m2 layout: (SpecLayout composed newRow: [:r | r add: #left; add: #right]; yourself). m2 openWithSpec ============================= Shouldn't be #right dynamically defined according to the values of 'item' and be replaced on the m2 layout? The transcript show that anytime I change the selection in this small spec interface, m2 right is changed. Is it not what I'm putting in the right side of the interface with the line which says: "newRow: [:r | r add: #left; add: #right];" How can I made spec in this small example show the respective value in the dictionary when the key value is "first" inside a TextModel and the respective value in the dictionary when the key value is "second" inside a GlamourPresentationModel? Cheers, Offray On 08/01/16 19:06, Offray Vladimir Luna CÃ¡rdenas wrote: > Hi Johan, > > I have not found more errors on the booklet, but I think that I'm not > getting the explanation of dynamic spec. Consider this code: > > > ============================== > GrafoscopioGUI Class>>exampleBootstrapDynamicUI > "Starting from an example UI from the Spec-Glamour, to customize > towards the grafoscopio > UI and get some ideas" > > |notebook leftUpperPanel leftPanel treeBrowser | > > "Creating a notebook-tree with dummy data" > notebook := GrafoscopioNode new becomeDefaultTestTree. > > "Defining the tree roots part" > leftUpperPanel := DynamicComposableModel new. > leftUpperPanel instantiateModels: #(tree TreeModel). > leftUpperPanel tree > roots: notebook children; > childrenBlock: [:node | node children ]; > displayBlock: [:node | node title ]. > leftUpperPanel layout: (SpecLayout composed > add: #tree; > yourself). > "to debug upto here uncomment the next line, and comment all other > 'openWithSpec' ones" > "leftUpperPanel openWithSpec." > > "Integrating the previous tree with the node header and creating > the body according to > the tags on the node" > leftPanel := DynamicComposableModel new. > leftPanel assign: leftUpperPanel to: #roots. > leftPanel instantiateModels: #(header TextInputFieldModel). > treeBrowser := DynamicComposableModel new. > leftUpperPanel tree > whenSelectedItemChanged: [:node | > node > ifNil:[ > leftPanel header text: ''. > treeBrowser instantiateModels: #(body TextModel). > Transcript show: 'Nada que mostrar', String cr] > ifNotNil: [ > leftPanel header text: (leftUpperPanel tree > selectedItem content header). > leftUpperPanel tree selectedItem content tags = > 'cÃ³digo' > ifTrue: [ > treeBrowser instantiateModels: #(body > GlamourPresentationModel). > Transcript show: 'I am code', String cr. > Transcript show: treeBrowser body > asString, String cr. > ] > ifFalse: [ > treeBrowser instantiateModels: #(body > TextModel). > treeBrowser body text: (leftUpperPanel > tree selectedItem content body). > Transcript show: 'I am NOT code', String cr. > Transcript show: treeBrowser body > asString, String cr. > ] > ] > ]. > leftPanel layout: > (SpecLayout composed > newColumn: [:column | > column > add: #roots; > add: #header height: 35]; > yourself). > > "Integrating the previous tree with node body content" > treeBrowser assign: leftPanel to: #leftTree. > treeBrowser layout: > (SpecLayout composed > newRow: [:r | r add: #leftTree; add: #body ]; > yourself > ). > treeBrowser openWithSpec. > ============================== > > I can get the interface shown here: > > > > and when I move between nodes in the upper left tree the correspondent > name in the lower left input box changes accordingly, but nothing else > happens on the right side panel. I have put the definition of the type > and contents of such panel inside a whenSelectionChanged block, as you > can see in the previous code, because I think that right panel should > change according to the type of node that is selected, but this > doesn't work. The debug info that I send to a transcript show that > #body becomes a GlamourPresentationModel or a TextModel depending on > which node I'm selecting. I don't know what I'm doing wrong or how > this dynamic spec is supposed to behave... well, dynamically, and > accordingly making layout components to change on the fly. > > How can I make the right panel change to become a > GlamourPresentationModel or a TextModel in Spec-Glamour? > > Thanks, > > Offray > > > On 08/01/16 12:10, Johan Fabry wrote: >> >> Consider the error as reported! I should work on this text soon so I >> will fix it. If you find any more errors feel free to send me a mail. >> >>> On Jan 8, 2016, at 12:43, Offray Vladimir Luna CÃ¡rdenas >>> <offray(a)riseup.net <mailto:offray@riseup.net>> wrote: >>> >>> Thanks Johan, >>> >>> This seems what I'm looking for. >>> >>> I running now the examples at the dynamic spec section and I have >>> found an error in Script 1.41: Setting up the sub widgets (pg 24 of >>> current version) in the first line, where it says " view label text: >>> 'Packages:'." it should be " view label label: 'Packages:'." There >>> is any place where I can report and/or correct such errors? >>> >>> Cheers, >>> >>> Offray >>> >>> On 08/01/16 06:21, Johan Fabry wrote: >>>> Hola, >>>> >>>> it looks like what you want here is covered by dynamic spec. Have a >>>> look at the dynamic spec section in the Spec booklet (work in >>>> progress) >>>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… >>>> I think that it will answer your question. >>>> >>>>> On Jan 7, 2016, at 22:36, Offray Vladimir Luna CÃ¡rdenas >>>>> <offray(a)riseup.net> wrote: >>>>> >>>>> How can I initializeWidgets with some kind of conditions depending >>>>> on the kind of selection I have done on the tree? >>>> >>>> >>>> ---> Save our in-boxes! http://emailcharter.org >>>> <http://emailcharter.org/> <--- >>>> >>>> Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> >>>> PLEIAD and RyCh labs - Computer Science Department (DCC) - >>>> University of Chile >>>> >>> >> >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> >> PLEIAD and RyCh labs - Computer Science Department (DCC) - >> University of Chile >> >

Jan. 9, 2016

Re: [Pharo-users] Spec: Populating a playground with a particular content (was Re: Spec: Binding widgets how to)

by Offray Vladimir Luna CÃ¡rdenas

Hi Johan, I have not found more errors on the booklet, but I think that I'm not getting the explanation of dynamic spec. Consider this code: ============================== GrafoscopioGUI Class>>exampleBootstrapDynamicUI "Starting from an example UI from the Spec-Glamour, to customize towards the grafoscopio UI and get some ideas" |notebook leftUpperPanel leftPanel treeBrowser | "Creating a notebook-tree with dummy data" notebook := GrafoscopioNode new becomeDefaultTestTree. "Defining the tree roots part" leftUpperPanel := DynamicComposableModel new. leftUpperPanel instantiateModels: #(tree TreeModel). leftUpperPanel tree roots: notebook children; childrenBlock: [:node | node children ]; displayBlock: [:node | node title ]. leftUpperPanel layout: (SpecLayout composed add: #tree; yourself). "to debug upto here uncomment the next line, and comment all other 'openWithSpec' ones" "leftUpperPanel openWithSpec." "Integrating the previous tree with the node header and creating the body according to the tags on the node" leftPanel := DynamicComposableModel new. leftPanel assign: leftUpperPanel to: #roots. leftPanel instantiateModels: #(header TextInputFieldModel). treeBrowser := DynamicComposableModel new. leftUpperPanel tree whenSelectedItemChanged: [:node | node ifNil:[ leftPanel header text: ''. treeBrowser instantiateModels: #(body TextModel). Transcript show: 'Nada que mostrar', String cr] ifNotNil: [ leftPanel header text: (leftUpperPanel tree selectedItem content header). leftUpperPanel tree selectedItem content tags = 'cÃ³digo' ifTrue: [ treeBrowser instantiateModels: #(body GlamourPresentationModel). Transcript show: 'I am code', String cr. Transcript show: treeBrowser body asString, String cr. ] ifFalse: [ treeBrowser instantiateModels: #(body TextModel). treeBrowser body text: (leftUpperPanel tree selectedItem content body). Transcript show: 'I am NOT code', String cr. Transcript show: treeBrowser body asString, String cr. ] ] ]. leftPanel layout: (SpecLayout composed newColumn: [:column | column add: #roots; add: #header height: 35]; yourself). "Integrating the previous tree with node body content" treeBrowser assign: leftPanel to: #leftTree. treeBrowser layout: (SpecLayout composed newRow: [:r | r add: #leftTree; add: #body ]; yourself ). treeBrowser openWithSpec. ============================== I can get the interface shown here: and when I move between nodes in the upper left tree the correspondent name in the lower left input box changes accordingly, but nothing else happens on the right side panel. I have put the definition of the type and contents of such panel inside a whenSelectionChanged block, as you can see in the previous code, because I think that right panel should change according to the type of node that is selected, but this doesn't work. The debug info that I send to a transcript show that #body becomes a GlamourPresentationModel or a TextModel depending on which node I'm selecting. I don't know what I'm doing wrong or how this dynamic spec is supposed to behave... well, dynamically, and accordingly making layout components to change on the fly. How can I make the right panel change to become a GlamourPresentationModel or a TextModel in Spec-Glamour? Thanks, Offray On 08/01/16 12:10, Johan Fabry wrote: > > Consider the error as reported! I should work on this text soon so I > will fix it. If you find any more errors feel free to send me a mail. > >> On Jan 8, 2016, at 12:43, Offray Vladimir Luna CÃ¡rdenas >> <offray(a)riseup.net <mailto:offray@riseup.net>> wrote: >> >> Thanks Johan, >> >> This seems what I'm looking for. >> >> I running now the examples at the dynamic spec section and I have >> found an error in Script 1.41: Setting up the sub widgets (pg 24 of >> current version) in the first line, where it says " view label text: >> 'Packages:'." it should be " view label label: 'Packages:'." There is >> any place where I can report and/or correct such errors? >> >> Cheers, >> >> Offray >> >> On 08/01/16 06:21, Johan Fabry wrote: >>> Hola, >>> >>> it looks like what you want here is covered by dynamic spec. Have a >>> look at the dynamic spec section in the Spec booklet (work in >>> progress) >>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… >>> I think that it will answer your question. >>> >>>> On Jan 7, 2016, at 22:36, Offray Vladimir Luna CÃ¡rdenas >>>> <offray(a)riseup.net <mailto:offray@riseup.net>> wrote: >>>> >>>> How can I initializeWidgets with some kind of conditions depending >>>> on the kind of selection I have done on the tree? >>> >>> >>> ---> Save our in-boxes! http://emailcharter.org >>> <http://emailcharter.org/> <--- >>> >>> Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> >>> PLEIAD and RyCh labs - Computer Science Department (DCC) - >>> University of Chile >>> >> > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - > University of Chile >

Jan. 9, 2016

Re: [Pharo-users] Crash or locked VM

by Nicolai Hess

2016-01-08 23:20 GMT+01:00 Hilaire <hilaire(a)drgeo.eu>: > Le 08/01/2016 21:31, Nicolai Hess a Ã©crit : > > > > > > The crashing image itself can be found there in case of > usefulness > > https://www.dropbox.com/s/rur8ayt8eon6mab/drgeo.image.zip?dl=0 > > > > > > Do you have the changes file, too? > > Here: https://www.dropbox.com/s/dwg99xmvtgak10o/DrGeoCrashVM.zip?dl=0 > > Thanks > > Hi Hilaire, I think this is the same bug as https://pharo.fogbugz.com/f/cases/13854/frameSize-calculated-wrongly-for-li… this is fixed in pharo4.0 and pharo5.0 but not in pharo3.0 I modified the changeset for pharo4.0 to make it loadable in pharo3.0 But I did not looked further on the code changes, maybe it won't fully work. Find attached the changeset. You have to switch compiler class before and after loading this. SmalltalkImage compilerClass: Compiler. 'opal_drgeo.cs' asFileReference fileIn. SmalltalkImage compilerClass: OpalCompiler. > -- > Dr. Geo > http://drgeo.eu > > > >

Jan. 8, 2016

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

by Tudor Girba

Hi, Thanks a lot for the detailed feedback. > 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 only languages. For example, we currently have extensions for PetitParser, Glamour, Announcements and they are meaningful. > However: > The only objection so far is that I dislike the order/size of the panes. That is actually encouraging :). > 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. The horizontal bar could also be prevented by making the items in the list wrapped (so, they might occupy multiple lines). > 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. The reason for this choice was to expose the developer to more of the stack, but it is not an essential design choice. > 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 We will play with this a bit. Or does anyone else would like to give it a try? > 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) Movement would be certainly interesting and I would be happy if someone would implement this in Morphic. > 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. Itâs actually an issue in Glamour, but it can be adapted. Cheers, 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. 8, 2016

Re: [Pharo-users] Crash or locked VM

by Hilaire

Le 08/01/2016 21:31, Nicolai Hess a Ã©crit : > > > The crashing image itself can be found there in case of usefulness > https://www.dropbox.com/s/rur8ayt8eon6mab/drgeo.image.zip?dl=0 > > > Do you have the changes file, too? Here: https://www.dropbox.com/s/dwg99xmvtgak10o/DrGeoCrashVM.zip?dl=0 Thanks -- Dr. Geo http://drgeo.eu

Jan. 8, 2016