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@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@tudorgirba.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org>, "Moose-dev Moose Dev" <moose-dev@iam.unibe.ch>, "Any question about pharo is welcome" <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/

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

It looks much better to me, yes. I would need to use it some time before I could give more detailed feedback. (And I can’t really do that until the FFI is fixed, because all my development crashes the VM since I am using Roassal. So I am still on the last Pharo version before the VM switch.) One last thing is that I am not convinced on having the ‘proceed’, ‘step into’, ‘step over’ et cetera buttons on the stack pane. To me they are more related to the source code pane, as you always see the results of pressing those buttons there, but on the stack not always, e.g. the ‘step over’ actions.

On Jan 9, 2016, at 19:06, Tudor Girba <tudor@tudorgirba.com> wrote:

Thanks. What do you think of the new solution? Is it sufficient?

Doru

---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Hi,

On Jan 8, 2016, at 7:28 PM, Torsten Bergmann <astares@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@tudorgirba.com <mailto:tudor@tudorgirba.com>> An: "Pharo Development List" <pharo-dev@lists.pharo.org <mailto:pharo-dev@lists.pharo.org>>, "Moose-dev Moose Dev" <moose-dev@iam.unibe.ch <mailto:moose-dev@iam.unibe.ch>>, "Any question about pharo is welcome" <pharo-users@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."

Personally I dont mind if its the default or not and I dont judge things unless i try them for a considerably amount of time. Pharo is not and will not be begineer friendly for at least the not so distant future. Its not a matter of whether the GTDebugger becomes the default or not. There are a lot of issues Pharo has to face like most small community projects: a) Lack of substantial documentation b) Complete lack of begineer orientated documentation c) Lack of substantial begineer friendly libraries d) Lack of Libraries in general e) Small community with limited support f) Lack of support of other languages g) Completely diffirent coding paradigm from familar approaches etc etc Python is an excelent example of a programming language which is probably the most begineer friendly out there and the one that I recommend the most, for one new to coding and ones coming from another language. Unfortunately begineer friendly approaches on IDE and language level require big resources that pharo does not possess. For me pharo is an advanced coder orientated tool, with a steep learning curve, targeted at coder already familiar with OOP and the pitfalls of regular coding with considerable experience that look for a new way of coding that is radically different to what they are used to. Again I cannot really say if the old debugger is more begineer friendly than the new, I will have to try it for a week to offer an educated opinion. Also as I have already said I will be building my own workflow and guis with pharo because in many cases I dont like the design of old and new pharo tools, so for me at least I dont care if GTDebugger will become the default on this release or the other, what I do care is that is moldable, a design I have praised Spotter as well about, which means its easier for me to change take off its GUI , use my own GUI in place and maybe customize it a bit here and there. Thus I wont be pushing for anything since I will be fine with any scenario as long as the new debugger is integrated. I am coding with pharo because I am interested in making tools that fit like a glove to my needs and desires and help me automate my workflow as a 3d artists. I dont feel the need to impose my preference on other people since its easy enough to customise to great extend how Pharo looks and behaves and none else is going to build the tools I want to use since my desires are so specific and not what the average coder wants. For example ChronosManager is a tool I use on daily basis. This is why I am a coder, because I find it fun to create my own tools even if those tools are based on tools others created. So I have zero intention in getting in the way of such decisions. But I cannot deny also that I am in favor of a debugger that allows me with ease to change its GUI and it behavior. On Sun, Jan 10, 2016 at 4:10 PM Ben Coman <btc@openinworld.com> wrote:

On Fri, Jan 8, 2016 at 6:24 PM, Tudor Girba <tudor@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.

Can we do it the other way for Pharo 5 "Release"? Keeping the existing debugger as default and as desired people can enable GTDebugger. I know this limits exposure and slows uptake and feedback, but prior to this announcement there has been *zero* community discussion of making this the default. I can't find the Pharo 5 roadmap/plan, but I don't remember GTDebugger being mentioned at all. I worry how it looks to people considering Pharo for big changes like this to be dropped out of the sky without *public* forward *planning*.

A big UI change like this should happen *early* in a release cycle - because then you have a *long* time for it to become stable for documentation. Even though Dimitris is keen, I can understand why its disheartening for Stef. I'd hope the way is to introduce such big changes is as a technology preview and have the *default* match the recently developed documentation.

Note my problem is only with the default for the Pharo 5 "Release", so it could be default now to kick start its exposure and revert the default a few weeks before the Pharo 5 Release. And its not like you lose a whole year of feedback by not being default in Pharo 5 Release. The documentation using newcomers who are most likely to use Pharo 5 "Release" probably wouldn't have the confidence (or care) to provide the feedback you want anyway. Many of those in the community who would normally provide feedback will be follow Pharo 6 bleeding edge anyway, so they'll that won't be stuck with the old debugger. Making GTDebugger the default early in Pharo 6 should still get plenty of feedback from those that usually contribute.

btw, I am looking forward to using it for myself.

cheers -ben

...

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.

"I know you mean well, that you only want to encourage people to work on these areas, but it hurts me (personally) quite a bit if you say it like that - because statements like that are like a self fulfilling prophecy and very bad advertising that is hard to counter. I have written many serious libraries with lot's of documentation and I have supported them for years, I have written standalone articles for various audiences and I am active on the ML's; I did my part for your points a) to e) - I cannot do more. Should I stop if even you cannot see it ? And many others did at least as much, if not more." I am not dismiss your effort of course Pharo is 10 times more begineer friendly than it was 7 years ago, back then it was just a squeak fork , but it was mostly squeak. Of course you work hard and document your libraries, but you are not the rule , you are the exception. Most libraries dont come with documentation, most libraries dont come with enough class comments, hell most libraries dont even have a summary info in smalltalkhub. Esteban had to beg to get project descriptions. Does that look to you as begineer friendly ? "You helped with PBE and did screencasts, which is b) - is that a 'complete' lack of beginner documentation ?" See how I can even say that though like you I worked so hard on documenting things ? Am I a moron ? Maybe But the thing if there is one thing I love in my life the most is the truth. And the truth is even with my effort UPBE is not remotely close to being begineer friendly. The book itself in the Preface states that it requires knowledge of OOP and experience with other languages. My video tutorials are, but some of them are already outdated and I know even if I have the motivation to update them and thats definetly not begineer friendly. Its not about hurting your feelings, it about being realistic. We sit here and argue about the interface of the new debugger, and thats fine, of course we should keep working hard making pharo more begineer friendly but pharo wont become begineer friendly any time soon because we dont have the amount of people to get there. But our community grows because pharo improves and one of the improvement is that it becomes more begineer friendly? Should we stop ? should be discouraged about the difficulty of the whole task? Well if people are not discouraged from sending people to Mars why should I or you be discouraged from making pharo more beginner friendly. I never give up and surrender, but I dont try to advertise pharo as an easy to learn platform because when the student or beginner comes me and learns thisn and I tell them that Pharo is as easy to learn as python, ruby etc and hits those dead ends he/she will tell me "but you said it will be easy as X language" and it will not be. On Sun, Jan 10, 2016 at 5:22 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 10 Jan 2016, at 15:48, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

Personally I dont mind if its the default or not and I dont judge things unless i try them for a considerably amount of time.

Pharo is not and will not be begineer friendly for at least the not so distant future. Its not a matter of whether the GTDebugger becomes the default or not.

There are a lot of issues Pharo has to face like most small community projects:

a) Lack of substantial documentation b) Complete lack of begineer orientated documentation c) Lack of substantial begineer friendly libraries d) Lack of Libraries in general e) Small community with limited support f) Lack of support of other languages g) Completely diffirent coding paradigm from familar approaches etc etc

I know you mean well, that you only want to encourage people to work on these areas, but it hurts me (personally) quite a bit if you say it like that - because statements like that are like a self fulfilling prophecy and very bad advertising that is hard to counter.

I have written many serious libraries with lot's of documentation and I have supported them for years, I have written standalone articles for various audiences and I am active on the ML's; I did my part for your points a) to e) - I cannot do more.

Should I stop if even you cannot see it ?

And many others did at least as much, if not more.

You helped with PBE and did screencasts, which is b) - is that a 'complete' lack of beginner documentation ?

Yes, Pharo (Smalltalk) is a bit strange, needs some getting used to, but basically it is like most other OO languages (but better ;-).

Ever seen Haskel or Erlang, or C++ for that matter ?

We should positively but honestly describe ourselves, not belittle our own work.

...

Python is an excelent example of a programming language which is probably the most begineer friendly out there and the one that I recommend the most, for one new to coding and ones coming from another language.

I disagree, I once let one of my sons take some Python lessons on the Raspberry PI. We had quite a few WTF moments, not the least when things did not go as advertised (in other words, error messages and debugging is ugly as hell). But more importantly the course (one of the 'best') started explaining weird syntax from the beginning, that is not beginner friendly at all. The underlying model is not nice, you cannot hide that for long.

Python is widespread, because it is better that some alternatives and has good C integration.

...

Unfortunately begineer friendly approaches on IDE and language level require big resources that pharo does not possess. For me pharo is an advanced coder orientated tool, with a steep learning curve, targeted at coder already familiar with OOP and the pitfalls of regular coding with considerable experience that look for a new way of coding that is radically different to what they are used to.

Again I cannot really say if the old debugger is more begineer friendly than the new, I will have to try it for a week to offer an educated opinion.

Also as I have already said I will be building my own workflow and guis with pharo because in many cases I dont like the design of old and new pharo tools, so for me at least I dont care if GTDebugger will become the default on this release or the other, what I do care is that is moldable, a design I have praised Spotter as well about, which means its easier for me to change take off its GUI , use my own GUI in place and maybe customize it a bit here and there.

Thus I wont be pushing for anything since I will be fine with any scenario as long as the new debugger is integrated.

I am coding with pharo because I am interested in making tools that fit like a glove to my needs and desires and help me automate my workflow as a 3d artists. I dont feel the need to impose my preference on other people since its easy enough to customise to great extend how Pharo looks and behaves and none else is going to build the tools I want to use since my desires are so specific and not what the average coder wants.

For example ChronosManager is a tool I use on daily basis. This is why I am a coder, because I find it fun to create my own tools even if those tools are based on tools others created.

So I have zero intention in getting in the way of such decisions. But I cannot deny also that I am in favor of a debugger that allows me with ease to change its GUI and it behavior.

On Sun, Jan 10, 2016 at 4:10 PM Ben Coman <btc@openinworld.com> wrote: On Fri, Jan 8, 2016 at 6:24 PM, Tudor Girba <tudor@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.

Can we do it the other way for Pharo 5 "Release"? Keeping the existing debugger as default and as desired people can enable GTDebugger. I know this limits exposure and slows uptake and feedback, but prior to this announcement there has been *zero* community discussion of making this the default. I can't find the Pharo 5 roadmap/plan, but I don't remember GTDebugger being mentioned at all. I worry how it looks to people considering Pharo for big changes like this to be dropped out of the sky without *public* forward *planning*.

A big UI change like this should happen *early* in a release cycle - because then you have a *long* time for it to become stable for documentation. Even though Dimitris is keen, I can understand why its disheartening for Stef. I'd hope the way is to introduce such big changes is as a technology preview and have the *default* match the recently developed documentation.

Note my problem is only with the default for the Pharo 5 "Release", so it could be default now to kick start its exposure and revert the default a few weeks before the Pharo 5 Release. And its not like you lose a whole year of feedback by not being default in Pharo 5 Release. The documentation using newcomers who are most likely to use Pharo 5 "Release" probably wouldn't have the confidence (or care) to provide the feedback you want anyway. Many of those in the community who would normally provide feedback will be follow Pharo 6 bleeding edge anyway, so they'll that won't be stuck with the old debugger. Making GTDebugger the default early in Pharo 6 should still get plenty of feedback from those that usually contribute.

btw, I am looking forward to using it for myself.

cheers -ben

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.

Hi, I have taught with (I)Python and Pharo to non programmers or beginners and I would say, from that direct experience that Pharo is easier because it has an easier syntax, an uniform way of programming and a continuity between scripting, apps, code, code management and docs. So I will be talking about how I have dealt with a similar educative experience using pharo and python, where I think that is the pharo advantage and where I think, as a newbie and as a learner, are the weak spots to see how we can work on them. The problem I had with python was that it is "just" the language, so even dealing with which is gonna be your IDE for editing code becomes an issue. We started with web2py for web development, which has a minimalist web IDE and comes with batteries included and is easier to learn that Django, Rails or Seaside, but when that IDE felt limited, supporting IDE on several Gnu/Linux distros (we used arch & debian based) and Windows and Mac started to make noise in the educative experience, even installing cross-platform solutions, because of the sightly differences in the tools and their tool chains. Then there was the issue with introspection of the models we declared on web2py, which required to create a list or some kind of view. Using web2py from IPython prompt shell was the most interactive experience we had, but then we need to use two separated interfaces for web2py: CLI (for interactive instrospection) and WUI for everything else. So we went with IPython interactive notebooks, which resolved some things on the idea of introducing newbies to modeling and computing via interactive documentation, but then there is the problem of source code management. We used fossil for documentation on our hackerspace workshops, what kept things simple, but because libraries where distributed with other source code management systems (usually git) we start to deal with git related issues on how to update the code, but the bigger issue was the lack of moldability of IPython notebook without a lot of cognitive overhead: If I want something like an interactive outliner combining features of Leo and IPython (like the proposed on [1]) I would need to go to a lot of different technologies and paradigms: JSON, JQuery, Javascript, python, ZeroMQ, server programming, client programming, HTML interfaces, scripting, object oriented (as listed in [2]). [1] http://mutabit.com/offray/static/blog/output/posts/on-deepness-and-complexit... [2] http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-init... In contrast, making the workshops with Pharo has been a lot more smooth experience: learning the basics of the language, models introspection, data visualization, scripting, interactive documentation, IDE, "apps", and code management, all happens from the same environment in a continuous fashion. Deep roots on Smalltalk as an environment for children and (de)constructive learning reveal themselves in this kind of setups, making learning easier for newbies and makes a sharp contrast with the Unix/OS tradition and programming languages made from programmers by programmers. Of course, this experience has a lot of "band width" being a face to face workshop, so we can deal with any issue on real time, even without proper resources in knowledge (mostly all of us are newbies) or documentation (mostly all of it is directed towards programmers). But even with limited resources, the continuity of the environment, responsiveness of the community and moldability of tools beats almost everything else with bigger communities, more documentation, more (but inflexible) tools and a lot of "learning impedance". I have been able to prototype something in months, even with limited time, that in other environments, including python, would take orders of magnitude more time, effort and knowledge (at least in the kind of experience we had here, but YMMV) It this experience, community has been the most valuable resource and binding experience for me. It's pretty supportive and friendly most of the time (including the git vs fossil or pillar vs markdown or ecstatic vs grav/anything-else healthy rants). So there is a lot of effort and advantage in Pharo for newbies, from increasing documentation & videos, to face to face workshops to MOOCs, mailing list and chat channels and I think that together we can deal with the challenges ahead. The main concern for my is rhythm and interaction with the external world: being small means that not all the time we can be as supportive or proactive as we want. Some times I get quick, detailed and/or worked answers to my questions that I have not the time to experiment with, some times I'm working hard to learn something (like with my dynamic spec interface question[3]) and not getting feedback in days start to feel like eternity. Something similar applies to external world interaction, being small means that we don't have the time to implement stuff that bigger communities had: external libraries for supporting languages like yaml or markdown or a broader panoramic view on the state of affairs in a particular subject (i.e: flat file web generators or DVCS). [3] http://forum.world.st/Spec-Binding-widgets-how-to-td4863742.html#a4870168 How can we deal with this rhythm issues to make the learning experience more continuous? How can we enrich the bridges with the external world (i.e: libraries, formats, data)? Hope this helps. Offray On 10/01/16 11:04, Martin Bähr wrote:

Excerpts from Sven Van Caekenberghe's message of 2016-01-10 16:21:10 +0100:

...

I have written many serious libraries with lot's of documentation and I have supported them for years, I have written standalone articles for various audiences and I am active on the ML's; I did my part for your points a) to e) Should I stop if even you cannot see it ? maybe this is the part of the problem, there is a lot of stuff, but it is not always easy to find.

the graphic last month with a list of interesting tools and libraries for various aspects of pharo was very informative. more of that would be nice.

same goes for documentation, a lot of it exists, but it could maybe be structured better.

what i mean here is, to group documentation by topic:

what do you want to do?

gui programming: from introduction to morphic/bloc/etc to serious complex gui applications web development: seaside tutorial zinc tutorial (that is an excellent beginner tutorial btw) rest, etc... data visualization: introduction to roassal, from simple example to advanced. most if not all of that is in the agile visualization book. etc...

...

You helped with PBE and did screencasts, which is b) - is that a 'complete' lack of beginner documentation ? since last year i have observed several students from middle-school to university level, who all managed to learn pharo with little help, just by pointing them to a series of tutorials.

the only extra motivation i have given them is a small task to solve on top of each tutorial. very rarely i had to answer extra questions. for the most part the students were able to work on their own with only the existing documentation available to them.

while this is only anecdotal evidence, it shows that pharo is approachable by beginners. and i would claim, even complete beginners who have never programmed before, however i don't know if any of my students actually were complete beginners.

...

Yes, Pharo (Smalltalk) is a bit strange, needs some getting used to, but basically it is like most other OO languages (but better ;-). and i would say it is only strange to those who are already somewhat experienced and have only seen and used curly-brace languages.

...

I disagree, I once let one of my sons take some Python lessons on the Raspberry PI. We had quite a few WTF moments, not the least when things did not go as advertised (in other words, error messages and debugging is ugly as hell). But more importantly the course (one of the 'best') started explaining weird syntax from the beginning, that is not beginner friendly at all. The underlying model is not nice, you cannot hide that for long. what i like about python syntax for beginners is the indenting. it teaches clean code formatting. the rest is no better or worse than other similar languages.

greetings, martin.

Sent from my iPad

On Jan 10, 2016, at 06:08, Ben Coman <btc@openinworld.com> wrote:

...

On Fri, Jan 8, 2016 at 6:24 PM, Tudor Girba <tudor@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.

Can we do it the other way for Pharo 5 "Release"? Keeping the existing debugger as default and as desired people can enable GTDebugger. I know this limits exposure and slows uptake and feedback, but prior to this announcement there has been *zero* community discussion of making this the default. I can't find the Pharo 5 roadmap/plan, but I don't remember GTDebugger being mentioned at all. I worry how it looks to people considering Pharo for big changes like this to be dropped out of the sky without *public* forward *planning*.

A big UI change like this should happen *early* in a release cycle - because then you have a *long* time for it to become stable for documentation. Even though Dimitris is keen, I can understand why its disheartening for Stef. I'd hope the way is to introduce such big changes is as a technology preview and have the *default* match the recently developed documentation.

Note my problem is only with the default for the Pharo 5 "Release", so it could be default now to kick start its exposure and revert the default a few weeks before the Pharo 5 Release. And its not like you lose a whole year of feedback by not being default in Pharo 5 Release. The documentation using newcomers who are most likely to use Pharo 5 "Release" probably wouldn't have the confidence (or care) to provide the feedback you want anyway. Many of those in the community who would normally provide feedback will be follow Pharo 6 bleeding edge anyway, so they'll that won't be stuck with the old debugger. Making GTDebugger the default early in Pharo 6 should still get plenty of feedback from those that usually contribute.

btw, I am looking forward to using it for myself.

cheers -ben

+1

...

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.

Hi Nicolai, Thanks for reporting these issues. They are indeed bugs and we are working on fixing them. Cheers, Andrei On Tue, Jan 12, 2016 at 11:24 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:

2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:

...

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.

Accept and Cancel buttons shouldn't be there or should not act on if the codepane hasn't changed. (every press on "accept" writes a new method version, although the contents didn't changed - tested on Latest update: #50524 )

Most (all?) other tools don't have Accept/Cancel buttons.

- I really miss the "List Methods using 'varname'/List Methods storing into 'varname' - is "stackTop" now gone ? I thought you wanted to add it to the stack ? - thisContext is gone as well ? - the Bytecode/GT button is badly placed, it looks like the "downarrow" window menu icon is a dropdown menu with label "Bytecode" (since when do we put buttons in the title pane? - the evaluator pane is shown as "dirty", as it does not make a difference if we accept the text in this pane, there shouldn't be a dirty indicator. - you can not use the inspector pane to change inst var values - there is no way to refresh the inspector pane

I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs but features.

nicolai

2016-01-15 13:39 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:

Hi,

Thanks indeed for the feedback. I think not quite all are bugs, but see more details inside.

...

On Jan 14, 2016, at 12:59 PM, Andrei Chis <chisvasileandrei@gmail.com> wrote:

Hi Nicolai,

Thanks for reporting these issues. They are indeed bugs and we are working on fixing them.

Cheers, Andrei

On Tue, Jan 12, 2016 at 11:24 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:

2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>: 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.

Accept and Cancel buttons shouldn't be there or should not act on if the codepane hasn't changed. (every press on "accept" writes a new method version, although the contents didn't changed - tested on Latest update: #50524 )

Good catch. This will happen even if the button would not be present.

...

Most (all?) other tools don't have Accept/Cancel buttons.

The logic is that these are actions that do not depend on the selection, so in Glamour we map these on actions that are applicable to the entire presentation. A similar approach is present in the inspector, although probably it does not appear so prominently because there is no text. We could try to add them in a dropdown menu. Would that help?

...

- I really miss the "List Methods using 'varname'/List Methods storing into ‘varname'

Please open an issue for this.

This issue is one year old: 14583 <https://pharo.fogbugz.com/f/cases/14583/inspector-and-instvars-list-methods-...> inspector and instvars : list methods storing into/using

...

- is "stackTop" now gone ? I thought you wanted to add it to the stack ? - thisContext is gone as well ?

These were removed due to emergency mail exchange that happened during the last weekend.

...

- the Bytecode/GT button is badly placed, it looks like the "downarrow" window menu icon is a dropdown menu with label “Bytecode"

We could try to fix by adding more space to the left of the menu bar in the theme. Could you open an issue?

...

(since when do we put buttons in the title pane?

Since Glamour makes it easy to have them there :). The GTPlayground and GTInspector have them, too.

still I don't think this is a good idea. What is the difference between action buttons in the title pane and the other one.

...

- the evaluator pane is shown as "dirty", as it does not make a difference if we accept the text in this pane, there shouldn't be a dirty indicator.

This is a problem that seems to exist with basically every pharoScript in Glamour. You commented on an issue for this:

https://pharo.fogbugz.com/f/cases/16757/GLMHighlighterTextRubEditingMode-alw...

Yes this is working nwo in 3.8.

...

- you can not use the inspector pane to change inst var values

This is a problem but it is not specific to the debugger.

...

- there is no way to refresh the inspector pane

Indeed. Would it be enough if we added a refresh for the whole debugger?

I don't know if there is an easy solution. But it was nice in the old debugger resp. inspector pane to have auto-updates for this values.

Cheers, Doru

...

I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs but features.

nicolai

_______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

2016-01-17 22:09 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:

Hi,

...

On Jan 17, 2016, at 7:56 PM, Nicolai Hess <nicolaihess@gmail.com> wrote:

[…]

...

...

- I really miss the "List Methods using 'varname'/List Methods storing into ‘varname'

Please open an issue for this.

This issue is one year old: 14583 inspector and instvars : list methods storing into/using

Ok. Thanks. Fixed.

Thanks Doru, I commented on the bug report. Will this be included in the (left most) inspector pane in the debugger? (this is difficult to use in the "State"-pane, because as soon as you try to bring up the popup-menu, the pane "slides away"). nicolai

-- www.tudorgirba.com www.feenk.com

"To utilize feedback, you first have to acquire it."