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

Re: [Pharo-dev] Just that you know that we are not happy

by Max Leske

> On 10 Jan 2016, at 08:37, stepharo <stepharo(a)free.fr> wrote: > > Hi > > if GTdebugger becomes the default debugger it means that our mooc will be already obsolete before getting finished. > It means that we will be forced to > have separate installers > different web pages explaining not to use Pharo 50 but a strange version > it means that people will report bugs on a different system > And we will have to spent time on that instead of the rest. > > And we will really thank the Pharo community for its great vision and care about our effort. > This is more than 6 months that we are working on it and we have problably yet another month of work. > Now just writing this makes me sick. > > So if the only respect about the work of other people is like that then I will just think a lot about my > engagement. If this happens I can tell you that you will have a hard time to ask me to put energy into > pharo in the future. > > Now if this makes you feel easy you can think that I'm tired. This poor stephane is working too much and > is overacting. Think that if this helps you to feel good. Really. > > Now what pissed me off the most is that I'm **TEACHING** to L2 L3 and M1 students > This year I was teaching to > Prague > Annecy > Lviv > Lome > Dakar > Saint louis > Yaounde > > and when I say that the student are afraid by the default debugger, they are afraid also by > a more complex one. Who among the people deciding to not put this debugger by default > can show me that he did one lecture on newbies over the last two years? For real? > > So be right and go ahead: because you know what is good for the end programmer. > I asked five times to understand who need _thisContext and _stakc top and so far I got zero answer. > It will help me to take a break from Pharo. I use both thisContext and stackTop regularly. thisContext maybe once a wee, stackTop probably multiple times a day. > > Stef > > PS: I 'm not in the Pharo board anymore because I have to do something else > > >

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Nicolai Hess

2016-01-09 23:10 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > On Jan 9, 2016, at 3:29 PM, Christophe Demarey < > christophe.demarey(a)inria.fr> wrote: > > Not yet tested but looks good. > > > Thanks. > > I just noticed it misses the "run to here" action. > > > It does not miss it. It is in the context menu of the code (this is where > it logically belongs). > Argh, trying to change a "well known user interface" (SpecDebugger) and arguing about why the new interface (GTDebugger) is " more logical" is always risky :) Even so we (smalltalkers) have the best software environment (Pharo) we are bound to our owns habits. And it is a question of "discoverability". If you only see 5 debugger action icons, you may not know that there is another one (hidden) inthe context menu. > > > > Doru > > > > > Le 9 janv. 2016 Ã 11:01, Esteban Lorenzano a Ã©crit : > > again re-send because of exceed limits with the image (thatâs new?) > > with a small tweak, texts (AND icons :P): > > > <Screen Shot 2016-01-09 at 10.59.20.png> > > would that be aceptable for you? > > cheers! > Esteban > > On 09 Jan 2016, at 09:43, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > (re-send because I exceeded limit.) > > Hi, > > letâs think positive. > the GTDebugger is a step forwardâ¦ it allow a lot of better interactions > and of course, it needs some iterations to make it appealing to everybody. > For instance, I took me 2â to tweak the debugger presentation and to get > this: > > <Screen Shot 2016-01-09 at 09.29.59.png> > > (I changed all availableâ¦ is a trivial task) > > and like IMO feels a lot betterâ¦ and I think is a good compromise between > the old and the new. > Reasons to suggest this approach: > > - it keeps old approach who(I think) was good (I can see the stack, and > the flow feels natural from top to down) > - it preserves âthe importantâ (the code) as central. > - it gives space for adding columns (like the bytecode). > > Nowâ¦ I can understand you want icons with text, and that can be hacked > tooâ¦ > > Soâ¦ can we have an agreement? > > Esteban > > ps: btwâ¦ using GT with Fast Table we can also avoid those annoying > paginated lists too > > On 09 Jan 2016, at 08:53, stepharo <stepharo(a)free.fr> wrote: > > Thanks for your testimony. > > I'm not against GTDebugger per se. I believe that we should have better > tools > but we should take time for building better tools (even if this is two > years that moosers use or not this new debugger). > I would appreciate a process where users can give real feedback and we can > simplify/shape our tools nicely. > > Now for the mooc I will not present GTDebugger. So students will not use > Pharo 50 > > Stef > > Le 08/01/2016 21:22, stepharo a Ã©crit : > > I'm sorry but this debugger should not be the default one. > MONDAY we are filming our mooc and we have to explain the debugger and > personally I do not see the gain: > - It looks a lot more complex to me and I do not want to have to > redo all the screenshots > of our lecture. > - Just that I have to learn the meaning of small icons. > - Why do we need a special pane for the evaluator > - Why there is a type column. > - Sorry but I'm not convinced about the moldable aspect behind the > story (no need to argue I know it) > > I would like to avoid to be forced to use not the latest version of > Pharo for the mooc. > > Such changes are arriving far too late in the release. We do not change > the debugger itself the day of code freeze. > > We decided that the GTDebugger can be included but to me it never meant > that it should be the default one. > I think that experts can choose the debugger they want. The newbies don't. > > Stef > > > IMO the old debugger is way more intuitive. > When I used the debugger of Eclipse for java I was lost. When I used > Spec debugger I thought "Oh, this is not so hard in fact". And I lose > the feeling with GTDebugger. And the debugger is one of the main source > of interest for newbies. > > Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Quality cannot be an afterthought." > >

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Nicolai Hess

2016-01-09 22:51 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > > On Jan 9, 2016, at 10:23 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > > > > > 2016-01-09 20:52 GMT+01:00 Francisco Ortiz PeÃ±aloza <patchinko(a)gmail.com > >: > > Hi, > > > > i would like to have the GTDebugger in the near future. Great job and > thanks! > > > > I like the Esteban built instead of the original one and i agree with > stef on removing _stack and _thisContext from top and the bytecode view. > Aim to simplicity must be a top priority and if anybody needs something > more specific can change it easily (its moldable!) > > > > I often use thisContext and stackTop for inspecting the current context > (I use this a lot when debugging compiler errors) and > > the stackTop when stepping through cascaded message send, I want to see > the intermediate return value. > > Indeed, I use them too, but not too often. That is why Andrei and I think > maybe they should be in the menu of hte stack and have them appear in the > inspector below. What do you think? > I don't know. At the moment I would say, keep it. It is a valuable information about the current state of the execution. But if you implement it as you described, I will test and give feedback. I would not change the name of thisContext to _thisContext. The name "thisContext" is a valid and evaluatable variable name. It is confusing if we show it as "_thisContext" just to tell it appart from "normal" variable names. There is a "type" column, this could be used to name this kind of variable ("pseudo Var" for example). > > Cheers, > Doru > > > > > > > Cheers > > Francisco > > > > > > > > On Sat, Jan 9, 2016 at 12:07 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> > wrote: > > http://ws.stfx.eu/3KXXDAJ4EUF6 > > > > > > -----Original Message----- > > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of > Stephan Eggermont > > Sent: Saturday, January 9, 2016 3:36 PM > > To: pharo-dev(a)lists.pharo.org > > Subject: Re: [Pharo-dev] gtdebugger in pharo 5.0 > > > > On 09-01-16 12:39, Dimitris Chloupis wrote: > > > there has been around a script to automate the screenshots, but > > > personally I never bother using it because taking a screenshot and > > > inserting in pillar is the easiest thing. > > > > AFAIK the hard part is keeping things up to date. That's where > automation helps. > > > > Stephan > > > > > > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > > > >

Jan. 10, 2016

Re: [Pharo-dev] Just that you know that we are not happy

by HernÃ¡n Morales Durand

Hi Stef, Just to tell you that I don't understand the process (if any) where it is decided a new tool to be the new default, how it is evaluated and by whom. But I would love to. HernÃ¡n 2016-01-10 6:06 GMT-03:00 stepharo <stepharo(a)free.fr>: > Since the debugger is improving we will see if we can avoid to produce an > obsolete lecture that people will > use for 5 years. I should discuss with damien and luc. > But it means that it should be stable by monday or at maximum tuesday > because we will have to redo > the slides. Now luckily we postponed redoing 15 videos we should (re)do to > show how to code in Pharo > (for the record doing such videos of 5 min takes 3 hours minimum to do, > cut and process). > > Now I would like that we consider that I gave feedback on the icons two > years ago and the net result > was that during two years nothing changed. So I'm happy to see feedback > getting listened because > I often got the impression in the past that I should learn how to use > tools instead of having tools > that work for me (remember the discussion about playground and where we > have to explain why the result of > a printString should not only be in a popup!) > Sometimes I hate that people teachs me how I should work because I often > go faster my way. > > Stef > > Le 10/1/16 08:37, stepharo a Ã©crit : > > Hi >> >> if GTdebugger becomes the default debugger it means that our mooc will be >> already obsolete before getting finished. >> It means that we will be forced to >> have separate installers >> different web pages explaining not to use Pharo 50 but a strange >> version >> it means that people will report bugs on a different system >> And we will have to spent time on that instead of the rest. >> >> And we will really thank the Pharo community for its great vision and >> care about our effort. >> This is more than 6 months that we are working on it and we have >> problably yet another month of work. >> Now just writing this makes me sick. >> >> So if the only respect about the work of other people is like that then I >> will just think a lot about my >> engagement. If this happens I can tell you that you will have a hard time >> to ask me to put energy into >> pharo in the future. >> >> Now if this makes you feel easy you can think that I'm tired. This poor >> stephane is working too much and >> is overacting. Think that if this helps you to feel good. Really. >> >> Now what pissed me off the most is that I'm **TEACHING** to L2 L3 and M1 >> students >> This year I was teaching to >> Prague >> Annecy >> Lviv >> Lome >> Dakar >> Saint louis >> Yaounde >> >> and when I say that the student are afraid by the default debugger, they >> are afraid also by >> a more complex one. Who among the people deciding to not put this >> debugger by default >> can show me that he did one lecture on newbies over the last two years? >> For real? >> >> So be right and go ahead: because you know what is good for the end >> programmer. >> I asked five times to understand who need _thisContext and _stakc top and >> so far I got zero answer. >> It will help me to take a break from Pharo. >> >> Stef >> >> PS: I 'm not in the Pharo board anymore because I have to do something >> else >> >> >> >> >> > >

Jan. 10, 2016

Re: [Pharo-dev] Just that you know that we are not happy

by stepharo

Since the debugger is improving we will see if we can avoid to produce an obsolete lecture that people will use for 5 years. I should discuss with damien and luc. But it means that it should be stable by monday or at maximum tuesday because we will have to redo the slides. Now luckily we postponed redoing 15 videos we should (re)do to show how to code in Pharo (for the record doing such videos of 5 min takes 3 hours minimum to do, cut and process). Now I would like that we consider that I gave feedback on the icons two years ago and the net result was that during two years nothing changed. So I'm happy to see feedback getting listened because I often got the impression in the past that I should learn how to use tools instead of having tools that work for me (remember the discussion about playground and where we have to explain why the result of a printString should not only be in a popup!) Sometimes I hate that people teachs me how I should work because I often go faster my way. Stef Le 10/1/16 08:37, stepharo a Ã©crit : > Hi > > if GTdebugger becomes the default debugger it means that our mooc will > be already obsolete before getting finished. > It means that we will be forced to > have separate installers > different web pages explaining not to use Pharo 50 but a strange > version > it means that people will report bugs on a different system > And we will have to spent time on that instead of the rest. > > And we will really thank the Pharo community for its great vision and > care about our effort. > This is more than 6 months that we are working on it and we have > problably yet another month of work. > Now just writing this makes me sick. > > So if the only respect about the work of other people is like that > then I will just think a lot about my > engagement. If this happens I can tell you that you will have a hard > time to ask me to put energy into > pharo in the future. > > Now if this makes you feel easy you can think that I'm tired. This > poor stephane is working too much and > is overacting. Think that if this helps you to feel good. Really. > > Now what pissed me off the most is that I'm **TEACHING** to L2 L3 and > M1 students > This year I was teaching to > Prague > Annecy > Lviv > Lome > Dakar > Saint louis > Yaounde > > and when I say that the student are afraid by the default debugger, > they are afraid also by > a more complex one. Who among the people deciding to not put this > debugger by default > can show me that he did one lecture on newbies over the last two > years? For real? > > So be right and go ahead: because you know what is good for the end > programmer. > I asked five times to understand who need _thisContext and _stakc top > and so far I got zero answer. > It will help me to take a break from Pharo. > > Stef > > PS: I 'm not in the Pharo board anymore because I have to do something > else > > > >

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

- Can we have a setting to remove all the colors from the stack because sometimes the hilighting is more confusing than helping and especially for newbies - the argument about run to here not being a button is not about logical placement is it about making things easy to use and discover. - I found the icon on the right (the right mo When do you think that the new debugger could be stable. Because we can try to see if we can change the lectures and change the screenshots but first we should finish the other ones. Stef Le 9/1/16 22:35, Tudor Girba a Ã©crit : > 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 >> <mailto: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. >> 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 <http://www.tudorgirba.com> > www.feenk.com > > "It's not how it is, it is how we see it." >

Jan. 10, 2016

Re: [Pharo-dev] Little challenge

by stepharo

Le 10/1/16 01:56, Eliot Miranda a Ã©crit : > BlockClosure and Context. Back in the day OrderedCollection was one (when become was cheap there was no need for the array inst car). Yes I remember in VW. > You want to say > > Smalltalk allClasses select: [:c| c isVariable and: [c instSize > 0]] > > _,,,^..^,,,_ (phone) > >> On Jan 9, 2016, at 1:24 PM, stepharo <stepharo(a)free.fr> wrote: >> >> We tried >> >> (Object allSubclasses select: #isVariable) >> reject: [ :each | each instVarNames isEmpty ] >> >> and we discovered that we have no class in the system with named instance variables and indexed ones. >> May be we are wrong. We are interested if you find one. >> >> >> Now we created one >> >> Object variableSubclass: #PPpoint >> instanceVariableNames: 'x y' >> classVariableNames: '' >> package: 'Web' >> >> and this is strange because inspecting PPoint new: 3 looks wrong since the variable zone arrives before >> the named one as displayed. >> >> >> <hhbahgba.> >

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

> I've never used the bytecodes view, but when I see them listed in the > inspector on a method I still often think "Wow! You can do that?!" > Its cool a hook to let novices peek under the hood and build a sense > of mastery. Though I haven't used the GTDebugger for a long time, so > I'm not sure whether my sentiment is applicable. We are not facing the same novices then. Mine are 3 years into programming at max. Stef

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

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

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

> I wanted to say that I also like more the distribution that Esteban > built instead of the original one of GT Debugger. So.. +1 for that. > > And yes, I also like the text besides the buttons since unfortunately > the buttons are not extremely intuitive. +1 for that too. For the record I gave this feedback two years ago. Fun to see that I'm so right. > Stef, as for the bydecode debugger, if I remember, you had to > explicitly switch to a bytecode debugger. In the normal debugger a > normal user will use, the bytecode pane was not there. > > > > > > On Sat, Jan 9, 2016 at 11:08 AM, Dimitris Chloupis > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > Dont do it for me , what I did with ChronosManager is only the tip > of the iceberg, I will be redesigning the whole Pharo GUI from > scratch. After I release ChronosManager 0.2 my next victim will be > Nautilus, then inspector and finally debugger. So I will be > building my own GUI for the debugger anyway, in similar style to > ChronosManager, completely custom made , static and icon based. > It wont happen tommorow but slowly and steadily I will make my own > Pharo GUI, obviously radically different to what we have now. > > I merely mentioned this to represent a voice of reason over icon > based interfaces that dominate software market anyway. > > On Sat, Jan 9, 2016 at 3:49 PM Christophe Demarey > <Christophe.Demarey(a)inria.fr <mailto:Christophe.Demarey@inria.fr>> > wrote: > > Hi, > > It is impossible to satisfy everyone. > What I would suggest is to have text + icons as default and a > preference to only have icons. > > Christophe > > Le 9 janv. 2016 Ã 14:30, Dimitris Chloupis a Ã©crit : > >> Which brings us to my question, where did tooltips go ? >> Squeak had them and then they were gone in pharo. >> >> Personally I dont see the point of having an icon to have >> text next to it. Seriously how much time it takes you to >> learn what each icon does ? >> >> and the debugger is not exactly a tool you will be using once >> per month, so the chance of forgeting gets pretty low after >> the first week. >> >> So my vote goes to get rid of text, it wastes valuable gui >> space in an environment where windows fight for space. And >> even on my 27'' monitor I rather have as compact as possible >> GUI. >> On Sat, Jan 9, 2016 at 3:05 PM stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> >> >> Le 9/1/16 11:01, Esteban Lorenzano a Ã©crit : >>> again re-send because of exceed limits with the image >>> (thatâs new?) >>> >>> with a small tweak, texts (AND icons :P): >> >> And text. I asked that during two years in GT but I was >> told it was not possible. >> Like that I do not have to learn these icons >> What is the Where is? >> >> >>> >>> >>> <PiÃ¨ce jointe Mail.png> >> >>> >>> would that be aceptable for you? >>> >>> cheers! >>> Esteban >> >>> >>>> On 09 Jan 2016, at 09:43, Esteban Lorenzano >>>> <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>> >>>> (re-send because I exceeded limit.) >>>> >>>> Hi, >>>> >>>> letâs think positive. >>>> the GTDebugger is a step forwardâ¦ it allow a lot of >>>> better interactions and of course, it needs some >>>> iterations to make it appealing to everybody. >>>> For instance, I took me 2â to tweak the debugger >>>> presentation and to get this: >>>> >>>> <Screen Shot 2016-01-09 at 09.29.59.png> >>>> >>>> (I changed all availableâ¦ is a trivial task) >>>> >>>> and like IMO feels a lot betterâ¦ and I think is a good >>>> compromise between the old and the new. >>>> Reasons to suggest this approach: >>>> >>>> - it keeps old approach who(I think) was good (I can >>>> see the stack, and the flow feels natural from top to down) >>>> - it preserves âthe importantâ (the code) as central. >>>> - it gives space for adding columns (like the bytecode). >>>> >>>> Nowâ¦ I can understand you want icons with text, and >>>> that can be hacked tooâ¦ >>>> >>>> Soâ¦ can we have an agreement? >>>> >>>> Esteban >>>> >>>> ps: btwâ¦ using GT with Fast Table we can also avoid >>>> those annoying paginated lists too >>>> >>>>> On 09 Jan 2016, at 08:53, stepharo <stepharo(a)free.fr >>>>> <mailto:stepharo@free.fr>> wrote: >>>>> >>>>> Thanks for your testimony. >>>>> >>>>> I'm not against GTDebugger per se. I believe that we >>>>> should have better tools >>>>> but we should take time for building better tools >>>>> (even if this is two years that moosers use or not >>>>> this new debugger). >>>>> I would appreciate a process where users can give real >>>>> feedback and we can simplify/shape our tools nicely. >>>>> >>>>> Now for the mooc I will not present GTDebugger. So >>>>> students will not use Pharo 50 >>>>> >>>>> Stef >>>>> >>>>>> Le 08/01/2016 21:22, stepharo a Ã©crit : >>>>>>> I'm sorry but this debugger should not be the >>>>>>> default one. >>>>>>> MONDAY we are filming our mooc and we have to >>>>>>> explain the debugger and >>>>>>> personally I do not see the gain: >>>>>>> - It looks a lot more complex to me and I do not >>>>>>> want to have to >>>>>>> redo all the screenshots >>>>>>> of our lecture. >>>>>>> - Just that I have to learn the meaning of small >>>>>>> icons. >>>>>>> - Why do we need a special pane for the evaluator >>>>>>> - Why there is a type column. >>>>>>> - Sorry but I'm not convinced about the moldable >>>>>>> aspect behind the >>>>>>> story (no need to argue I know it) >>>>>>> >>>>>>> I would like to avoid to be forced to use not the >>>>>>> latest version of >>>>>>> Pharo for the mooc. >>>>>>> >>>>>>> Such changes are arriving far too late in the >>>>>>> release. We do not change >>>>>>> the debugger itself the day of code freeze. >>>>>>> >>>>>>> We decided that the GTDebugger can be included but >>>>>>> to me it never meant >>>>>>> that it should be the default one. >>>>>>> I think that experts can choose the debugger they >>>>>>> want. The newbies don't. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>> IMO the old debugger is way more intuitive. >>>>>> When I used the debugger of Eclipse for java I was >>>>>> lost. When I used >>>>>> Spec debugger I thought "Oh, this is not so hard in >>>>>> fact". And I lose >>>>>> the feeling with GTDebugger. And the debugger is one >>>>>> of the main source >>>>>> of interest for newbies. >>>>>> >>>>>> Maybe we could have a button on the spec Debugger >>>>>> "Switch to GTDebugger"? >>>>>> >>>>> >>>>> >>>> >>> > > > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 10, 2016