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

Re: [Pharo-users] Crash or locked VM

by stepharo

thanks hilaire. Stef Le 5/1/16 22:11, Hilaire a Ã©crit : > Hi, > > I have a situation with a recursive Dr. Geo script where the image crash > or get locked (Can't hold on the image). > I tried with latest VM as detailed in the joined crash dump. > > I did not get similar problem with other recursive script. So I may have > very special interaction between the objects, but I did not find out. > > It may also be related to Morph because when instantiating first the > canvas and its window (2nd line of the script), then the rest of the > script, it does not crash. > > The crashing image itself can be found there in case of usefulness > https://www.dropbox.com/s/rur8ayt8eon6mab/drgeo.image.zip?dl=0 > > When not crashing it outputs this cherry tree. > > Thanks > > Hilaire >

Jan. 8, 2016

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

by Johan Fabry

I second Torstenâs comment with regard to the use of space, I also think the original positioning of stack and code panes is more efficient. > On Jan 8, 2016, at 14:28, Torsten Bergmann <astares(a)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 :) > - 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. > > 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) > > 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 > T. > > Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr > Von: "Tudor Girba" <tudor(a)tudorgirba.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is welcome" <pharo-users(a)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/ > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com[http://www.tudorgirba.com] > www.feenk.com[http://www.feenk.com] > > "Beauty is where we see it." ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Jan. 8, 2016

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

by Torsten Bergmann

Hi, with a moldable debugger we should (in the future) be able to support debugging also different/other programming languages/DSLs in Pharo :) - 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. 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) 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 T.Â Gesendet:Â Freitag, 08. Januar 2016 um 11:24 Uhr Von:Â "Tudor Girba" <tudor(a)tudorgirba.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is welcome" <pharo-users(a)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/ Â Please let us know what you think. Â Cheers, Doru Â Â -- www.tudorgirba.com[http://www.tudorgirba.com] www.feenk.com[http://www.feenk.com] "Beauty is where we see it." Â

Jan. 8, 2016

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

by Johan Fabry

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> 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… <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 PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Jan. 8, 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

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 <--- > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/%7Ejfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - > University of Chile >

Jan. 8, 2016

Re: [Pharo-users] gtdebugger in pharo 5.0

by Alexandre Bergel

This is an excellent news! I have been waiting for that for long! go go go! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 8, 2016, at 8:07 AM, 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/ <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/> > www.feenk.com > > "What is more important: To be happy, or to make happy?" >

Jan. 8, 2016

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

by Andrei Chis

On Fri, Jan 8, 2016 at 2:23 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > is there any documentation about this ? or i just look at the relevant > classes ? > Not really. Now you'll need to look in UITheme>>styleContext:from:, but I'll refactor that method shortly. > On Fri, Jan 8, 2016 at 3:20 PM Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >>> does the GTDebugger respect the pharo themes support or is it like >>> GTSpotter ? >>> >> >> It behaves just as GTInspector regrading the theme. Just if you are >> using a custom theme and want to have the coloring of the stack enabled you >> need to provide the appropriate colors in your theme (styleContext:from:) >> >> Cheers, >> Andrei >> >> >> >>> >>> On Fri, Jan 8, 2016 at 1:08 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: >>>> >>>> >>>> >>>> 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?" >>>> >>>> _______________________________________________ >>>> 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 >>> >>> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >

Jan. 8, 2016

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

by Dimitris Chloupis

is there any documentation about this ? or i just look at the relevant classes ? On Fri, Jan 8, 2016 at 3:20 PM Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> does the GTDebugger respect the pharo themes support or is it like >> GTSpotter ? >> > > It behaves just as GTInspector regrading the theme. Just if you are using > a custom theme and want to have the coloring of the stack enabled you need > to provide the appropriate colors in your theme (styleContext:from:) > > Cheers, > Andrei > > > >> >> On Fri, Jan 8, 2016 at 1:08 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: >>> >>> >>> >>> 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?" >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Jan. 8, 2016

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

by Andrei Chis

On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > does the GTDebugger respect the pharo themes support or is it like > GTSpotter ? > It behaves just as GTInspector regrading the theme. Just if you are using a custom theme and want to have the coloring of the stack enabled you need to provide the appropriate colors in your theme (styleContext:from:) Cheers, Andrei > > On Fri, Jan 8, 2016 at 1:08 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: >> >> >> >> 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?" >> >> _______________________________________________ >> 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 > >

Jan. 8, 2016

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

by Dimitris Chloupis

does the GTDebugger respect the pharo themes support or is it like GTSpotter ? On Fri, Jan 8, 2016 at 1:08 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: > > > > 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?" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Jan. 8, 2016