- Pharo-users - lists.pharo.org

Re: [Pharo-users] the impact of moldability

by stepharo

I like the way you react to my criticisms. In fact each time I complain you make progress. You should really thank me in fact. And you can name me if it makes you feel better. ;) Now what you should measure is the ratio over engineering - complexity of the solution vs. spread of usage. because over engineering means more code to maintain, more complex logic For example, I think that the GTinspector is a success because the pane are nice and useful. Now EyeInspector was also extensible so this is not the extensibility the point that is the difference in adoption: this is the way people can extend it the good widget support and better look Now for Spotter I'm questionning the other scenarios that are not the main ones: - find a class - implementors - refs - senders In fact on the 50 that you can find I have problems to see the others useful. You can argue and brainwash me still when I look at me coding sessions I do not need more (do not tell me that this is because I do not how to use Spotter - I should be the one that produces mooc videos showing this great tool). For the debugger I looked at the code and this is less a problem than I thought (but this is based on Glamour and I do not like Glamour with blocks with multiple arguments and dataflow). Now the question is if you would have invested the time you spent in moldable but in an advanced debugger with object based breakpoints, concurrent support, alias support (like the wormhole debugger of the phd of adrian) and back in time debugging which ones people would really choose: because so far I do not debug bytecode, nor petitparser. And what I got is basically not much more than before. This is not because you show the test setup on the side of the stack that it is useful to me. Note that my remark is not incompatible with the fact that you could have a debugger framework that you can use to support bytecode and petitparser debugging. Stef So you can claim what you feel and justify your actions still there are other ways to measure success. Stef Le 4/6/16 Ã 18:45, Tudor Girba a Ã©crit : > Hi, > > There were a couple of emails in the recent period that questioned the usefulness of moldability (the ability of developers to customize their tools deeply and inexpensively). More specifically, the question was about the moldability of the GTDebugger. > > I put together a couple of thoughts of why we think that moldability is actually a competitive advantage: > http://www.humane-assessment.com/blog/the-impact-of-moldability/ > > Please read it and provide feedback. > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > > >

June 4, 2016

Re: [Pharo-users] [Moose-dev] Re: the impact of moldability

by Tudor Girba

Hi, > On Jun 4, 2016, at 7:34 PM, Ben Coman <btc(a)openinworld.com> wrote: > > Nice read and some interesting statistics. Thanks > It makes sense when laid > out like that, but its a question of internalising the knowledge to > make use of moldability more often. Indeed. This is a challenge. In this regard, picking specific scenarios and asking questions about how to deal with them could help us build tutorials. > > One small edit... > We are the beginning > ==> We are at the beginning Fixed. Doru > > cheers -ben > > On Sun, Jun 5, 2016 at 12:45 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> There were a couple of emails in the recent period that questioned the usefulness of moldability (the ability of developers to customize their tools deeply and inexpensively). More specifically, the question was about the moldability of the GTDebugger. >> >> I put together a couple of thoughts of why we think that moldability is actually a competitive advantage: >> http://www.humane-assessment.com/blog/the-impact-of-moldability/ >> >> Please read it and provide feedback. >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Reasonable is what we are accustomed with." >> >> _______________________________________________ >> 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 -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

June 4, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Ben Coman

On Jun 4, 2016 14:11, "Ben Coman" <btc(a)openinworld.com> wrote: > >> >> >> On Sat, Jun 4, 2016 at 11:28 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> >> wrote: >> >>> Hi, >>> I undestand and really liked the idea of a moldable debugger and it's >>> true that the button actions act over the stack, however the decision on >>> what action to use is taken not looking to the stack pane (normally I've >>> decided what to do looking on the source pane). In this context, the >>> buttons are far away where the attention usually is (the code pane). IMHO >>> for the user experience point of view I think is better to have the actions >>> below the stack list and above the stack pane to let the user do not >>> diverge his attention. I'm proposing not dettaching the action buttons for >>> the stack pane, just changing the location (and also moving and inverting >>> the direction of the tab label to not waste space). >>> >> >> Interesting idea. Only the [Stack] tab is a bit lonely over there on the >> right. Perhaps the tab could still be on the left, with the buttons left >> justified against it? >> >> On Sun, Jun 5, 2016 at 1:36 AM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Well I put the buttons on the left on purpose because in the case you're > debugging source code the content tends to be on the left half of the > screen. So this keeps the actions close to the decision on what to use. > I do agree. Here is my mockup, dependent on the number of [Stack] tabs expected. cheers -ben

June 4, 2016

Re: [Pharo-users] Issue on Seaside beginning

by stepharo

Hi Cheikhou We will have a look. I will contact Luc and Damien because I do not follow the Seaside set up. May be we messed up with the setup of the seaside image we gave you. Did you save your code? So that you can reload it with the https://ci.inria.fr/pharo-contribution/job/Seaside/ Seaside3.2 You got a problem with such image https://ci.inria.fr/pharo-contribution/job/PharoWeb/PHARO=50,VERSION=stable… do you have your code published so that I try to reproduce your problem? Sorry for the inconvenience. Stef Le 4/6/16 Ã 19:00, Cheikhou Oumar KA a Ã©crit : > Hello. > > I am following #PharoMOOC and it become more and more exciting. > > I were doing TinyBlog exercise and I got an issue. I looked at the > forum but any solution and I am stuck now like many others. > > I have created my class TBApplicationRootComponent, create a server > that listen at :8080 and start it, regiser my application.... > > But at http://localhost:8080/browse I got this Image in my browser > Images intÃ©grÃ©es 1 > > Any help is welcome. > > Thanks > > -- > /*Cheikhou Oumar KA */ > å¥¥ é©¬ å° Â·è°¢ èµ« Â·å*/ > /*Doctorant Informatique > cheikhouka(a)gmail.com <mailto:cheikhouka@gmail.com> > > >

June 4, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Ben Coman

On Sun, Jun 5, 2016 at 1:17 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > >> On Jun 4, 2016, at 7:09 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On Sat, Jun 4, 2016 at 11:28 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> Hi, >> I undestand and really liked the idea of a moldable debugger and it's true that the button actions act over the stack, however the decision on what action to use is taken not looking to the stack pane (normally I've decided what to do looking on the source pane). In this context, the buttons are far away where the attention usually is (the code pane). IMHO for the user experience point of view I think is better to have the actions below the stack list and above the stack pane to let the user do not diverge his attention. I'm proposing not dettaching the action buttons for the stack pane, just changing the location (and also moving and inverting the direction of the tab label to not waste space). >> >> Interesting idea. Only the [Stack] tab is a bit lonely over there on the right. Perhaps the tab could still be on the left, with the buttons left justified against it? >> >> btw, are there any use cases for multiple stack tabs? > > Do you mean if there are cases for seeing the stack in different ways or do you mean something else? I meant, is the [Stack] tab really required? Will there ever be a second tab? Could the buttons be the sole occupant of that row - beneath the stack pane? Actually do like the idea of having a bottom hanging [Stack] tab directly opposing the [Source] tab. Could the buttons be left justified against that, and then if a second tab ever comes along, slide the buttons to the right a little? cheers -ben > > Cheers, > Doru > >> cheers -ben >> >> >> Maybe something like this (sorry no photoshop here :) ): >> >> We need to figure it out a way to improve this situation. >> >> Regards, >> Gabriel >> >> On Sat, Jun 4, 2016 at 3:45 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi Sabine (and others that asked this question), >> >> Thanks for the feedback. Sorry for the delayed reply, but I am traveling these days and I have limited online time. Also, this email took some time to write (I started it about a week ago). >> >> I will answer the buttons issue. The reason they are in a different place than where they used to be is related to new constraints that come with the new debugger. While the default interface looks like a regular debugger, the main feature of the GTDebugger is that it can be customized to match a specific domain or library. >> >> Let me provide an example of a scenario of debugging PetitParser: >> >> PPArithmeticParser parse: '1+2*3^(34-2)â >> >> The default debugger looks like this: >> >> <debug-pp-default.png> >> >> But, because we have PetitParser code on the stack, we can switch to a custom debugger: >> >> <debug-pp-dedicated-source.png> >> >> This one also features the input stream next to the code. Also, note that the stack received 3 new button actions. But, this is not all. Next to the source, there are other tabs, and we can switch to one of those: >> >> <debug-pp-dedicated-visualization.png> >> >> This one shows the source as well, but in a graphical form. >> >> So, if we step back and talk about the buttons, you will see that if we would have put the buttons on the source tabs, you have had no way to advance in this state. We could have also duplicated behavior and put the buttons on the new presentation as well, but the space is much smaller and since we now have large buttons instead of only icons we needed to deal with that as well. We encountered similar situations in other debuggers (not all, though). >> >> But, from a more point of view, the actions act on the stack. So, if we take an object-oriented approach for designing the UI, it makes sense to place those actions next to the context they act on. All these reasons made us choose to put them next to the stack and not next to the source. >> >> We certainly understand that this is a departure from the classic debugger and perhaps this is not the best way of doing things, but that was the rationale we went through. I would be happy to hear other suggestions, but please understand that we need to take into account the full spectrum of constraints when choosing solutions. >> >> In any case, the idea of this debugger is that you can change it in the way you want and customize it specifically for your needs. We still need to document how to do that, but if someone wants to start creating a custom debugger we could use the experience to drive the documentation. >> >> Does this explain the situation? >> >> Cheers, >> Doru >> >> >>> On May 25, 2016, at 9:43 PM, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: >>> >>> Hi, >>> >>> today I moved to Pharo5. It is great to get feedback and solutions for >>> problems so quickly. It is a pleasure to work with Pharo and to have the >>> community. I am grateful for having this. >>> >>> I have one comment. I don't want to complain, I can use it but I was >>> wondering about the new position and size of the debugger buttons. >>> >>> There is a longer distance now from code text pane to the buttons - I see >>> this as disadvantage to earlier versions of Pharo from the user experience. >>> The buttons are a lot of smaller - same disadvantage - both if you use the >>> mouse. >>> >>> Ok, after seeing that, I thought "Sabine, you should use keyboard shortcuts >>> here, too" (I use much of them but interesting - til now not in the >>> debugger). >>> >>> Then I saw the shortcuts for >>> Proceed cmd+r >>> Restart cmd-shift-a >>> Into cmd-e >>> over cmd-shift-o >>> through cmd-shift-t >>> >>> especially into, over and through have so different key combinations, two >>> with shift, one without shift. When I debug, I often use for example >>> into-into-over-over-over-throuhg-through--into-into etc...and with the >>> combinations cmd-e and cmd-shit-e, it is more "finger-work". It would be >>> better to have all those shortcuts with or all shortcuts without shift. And >>> the letters not so far away at the keyboard (e-o-t) >>> >>> This is only my opinion and my first impression after one day with Pharo5. I >>> am sure, after a few days, I forgot that this was uncomfortable because I >>> have the shortcuts coming automatically into my fingers. >>> >>> Regards >>> Sabine >>> >>> >>> >>> >>> >>> >>> -- >>> View this message in context: http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing should have the right to be different." >> >> >> >> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Reasonable is what we are accustomed with." > >

June 4, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Gabriel Cotelli

Well I put the buttons on the left on purpose because in the case you're debugging source code the content tends to be on the left half of the screen. So this keeps the actions close to the decision on what to use. On Jun 4, 2016 14:11, "Ben Coman" <btc(a)openinworld.com> wrote: > > > On Sat, Jun 4, 2016 at 11:28 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> > wrote: > >> Hi, >> I undestand and really liked the idea of a moldable debugger and it's >> true that the button actions act over the stack, however the decision on >> what action to use is taken not looking to the stack pane (normally I've >> decided what to do looking on the source pane). In this context, the >> buttons are far away where the attention usually is (the code pane). IMHO >> for the user experience point of view I think is better to have the actions >> below the stack list and above the stack pane to let the user do not >> diverge his attention. I'm proposing not dettaching the action buttons for >> the stack pane, just changing the location (and also moving and inverting >> the direction of the tab label to not waste space). >> > > Interesting idea. Only the [Stack] tab is a bit lonely over there on the > right. Perhaps the tab could still be on the left, with the buttons left > justified against it? > > btw, are there any use cases for multiple stack tabs? > > cheers -ben > > >> >> Maybe something like this (sorry no photoshop here :) ): >> â >> We need to figure it out a way to improve this situation. >> >> Regards, >> Gabriel >> >> On Sat, Jun 4, 2016 at 3:45 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi Sabine (and others that asked this question), >>> >>> Thanks for the feedback. Sorry for the delayed reply, but I am traveling >>> these days and I have limited online time. Also, this email took some time >>> to write (I started it about a week ago). >>> >>> I will answer the buttons issue. The reason they are in a different >>> place than where they used to be is related to new constraints that come >>> with the new debugger. While the default interface looks like a regular >>> debugger, the main feature of the GTDebugger is that it can be customized >>> to match a specific domain or library. >>> >>> Let me provide an example of a scenario of debugging PetitParser: >>> >>> PPArithmeticParser parse: '1+2*3^(34-2)â >>> >>> The default debugger looks like this: >>> >>> >>> But, because we have PetitParser code on the stack, we can switch to a >>> custom debugger: >>> >>> >>> This one also features the input stream next to the code. Also, note >>> that the stack received 3 new button actions. But, this is not all. Next to >>> the source, there are other tabs, and we can switch to one of those: >>> >>> >>> This one shows the source as well, but in a graphical form. >>> >>> So, if we step back and talk about the buttons, you will see that if we >>> would have put the buttons on the source tabs, you have had no way to >>> advance in this state. We could have also duplicated behavior and put the >>> buttons on the new presentation as well, but the space is much smaller and >>> since we now have large buttons instead of only icons we needed to deal >>> with that as well. We encountered similar situations in other debuggers >>> (not all, though). >>> >>> But, from a more point of view, the actions act on the stack. So, if we >>> take an object-oriented approach for designing the UI, it makes sense to >>> place those actions next to the context they act on. All these reasons made >>> us choose to put them next to the stack and not next to the source. >>> >>> We certainly understand that this is a departure from the classic >>> debugger and perhaps this is not the best way of doing things, but that was >>> the rationale we went through. I would be happy to hear other suggestions, >>> but please understand that we need to take into account the full spectrum >>> of constraints when choosing solutions. >>> >>> In any case, the idea of this debugger is that you can change it in the >>> way you want and customize it specifically for your needs. We still need to >>> document how to do that, but if someone wants to start creating a custom >>> debugger we could use the experience to drive the documentation. >>> >>> Does this explain the situation? >>> >>> Cheers, >>> Doru >>> >>> >>> On May 25, 2016, at 9:43 PM, Sabine Manaa <manaa.sabine(a)gmail.com> >>> wrote: >>> >>> Hi, >>> >>> today I moved to Pharo5. It is great to get feedback and solutions for >>> problems so quickly. It is a pleasure to work with Pharo and to have the >>> community. I am grateful for having this. >>> >>> I have one comment. I don't want to complain, I can use it but I was >>> wondering about the new position and size of the debugger buttons. >>> >>> There is a longer distance now from code text pane to the buttons - I see >>> this as disadvantage to earlier versions of Pharo from the user >>> experience. >>> The buttons are a lot of smaller - same disadvantage - both if you use >>> the >>> mouse. >>> >>> Ok, after seeing that, I thought "Sabine, you should use keyboard >>> shortcuts >>> here, too" (I use much of them but interesting - til now not in the >>> debugger). >>> >>> Then I saw the shortcuts for >>> Proceed cmd+r >>> Restart cmd-shift-a >>> Into cmd-e >>> over cmd-shift-o >>> through cmd-shift-t >>> >>> especially into, over and through have so different key combinations, two >>> with shift, one without shift. When I debug, I often use for example >>> into-into-over-over-over-throuhg-through--into-into etc...and with the >>> combinations cmd-e and cmd-shit-e, it is more "finger-work". It would be >>> better to have all those shortcuts with or all shortcuts without shift. >>> And >>> the letters not so far away at the keyboard (e-o-t) >>> >>> This is only my opinion and my first impression after one day with >>> Pharo5. I >>> am sure, after a few days, I forgot that this was uncomfortable because I >>> have the shortcuts coming automatically into my fingers. >>> >>> Regards >>> Sabine >>> >>> >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390.html >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com >>> <http://nabble.com>. >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "Every thing should have the right to be different." >>> >>> >>> >>> >>> >> >

June 4, 2016

Re: [Pharo-users] Issue on Seaside beginning

by Cheikhou Oumar KA

> Hi, > I think I already got this problem when I loaded Seaside 3.2 in an image > where Seaside 3.1 was present. Thanks for this. 2016-06-04 17:10 GMT+00:00 Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com>: > Le 04/06/2016 19:00, Cheikhou Oumar KA a Ã©crit : > > Hello. > > > > I am following #PharoMOOC and it become more and more exciting. > > > > I were doing TinyBlog exercise and I got an issue. I looked at the forum > > but any solution and I am stuck now like many others. > > > > I have created my class TBApplicationRootComponent, create a server that > > listen at :8080 and start it, regiser my application.... > > > > But at http://localhost:8080/browse I got this Image in my browser > > > > > > Images intÃ©grÃ©es 1 > > > > Any help is welcome. > > > > Thanks > > > > -- > > /*Cheikhou Oumar KA */ > > å¥¥ é©¬ å° Â·è°¢ èµ« Â·å*/ > > /*Doctorant Informatique > > cheikhouka(a)gmail.com <mailto:cheikhouka@gmail.com> > > > > > > > > Hi, > > I think I already got this problem when I loaded Seaside 3.2 in an image > where Seaside 3.1 was present. > > I'm not sure it's the same problem and I don't have the time to look at > it but maybe this can help others to find a solution. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > > -- *Cheikhou Oumar KA * å¥¥ é©¬ å° Â·è°¢ èµ« Â·å Doctorant Informatique cheikhouka(a)gmail.com

June 4, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Tudor Girba

Hi, > On Jun 4, 2016, at 7:09 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sat, Jun 4, 2016 at 11:28 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Hi, > I undestand and really liked the idea of a moldable debugger and it's true that the button actions act over the stack, however the decision on what action to use is taken not looking to the stack pane (normally I've decided what to do looking on the source pane). In this context, the buttons are far away where the attention usually is (the code pane). IMHO for the user experience point of view I think is better to have the actions below the stack list and above the stack pane to let the user do not diverge his attention. I'm proposing not dettaching the action buttons for the stack pane, just changing the location (and also moving and inverting the direction of the tab label to not waste space). > > Interesting idea. Only the [Stack] tab is a bit lonely over there on the right. Perhaps the tab could still be on the left, with the buttons left justified against it? > > btw, are there any use cases for multiple stack tabs? Do you mean if there are cases for seeing the stack in different ways or do you mean something else? Cheers, Doru > cheers -ben > > > Maybe something like this (sorry no photoshop here :) ): > â > We need to figure it out a way to improve this situation. > > Regards, > Gabriel > > On Sat, Jun 4, 2016 at 3:45 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Sabine (and others that asked this question), > > Thanks for the feedback. Sorry for the delayed reply, but I am traveling these days and I have limited online time. Also, this email took some time to write (I started it about a week ago). > > I will answer the buttons issue. The reason they are in a different place than where they used to be is related to new constraints that come with the new debugger. While the default interface looks like a regular debugger, the main feature of the GTDebugger is that it can be customized to match a specific domain or library. > > Let me provide an example of a scenario of debugging PetitParser: > > PPArithmeticParser parse: '1+2*3^(34-2)â > > The default debugger looks like this: > > <debug-pp-default.png> > > But, because we have PetitParser code on the stack, we can switch to a custom debugger: > > <debug-pp-dedicated-source.png> > > This one also features the input stream next to the code. Also, note that the stack received 3 new button actions. But, this is not all. Next to the source, there are other tabs, and we can switch to one of those: > > <debug-pp-dedicated-visualization.png> > > This one shows the source as well, but in a graphical form. > > So, if we step back and talk about the buttons, you will see that if we would have put the buttons on the source tabs, you have had no way to advance in this state. We could have also duplicated behavior and put the buttons on the new presentation as well, but the space is much smaller and since we now have large buttons instead of only icons we needed to deal with that as well. We encountered similar situations in other debuggers (not all, though). > > But, from a more point of view, the actions act on the stack. So, if we take an object-oriented approach for designing the UI, it makes sense to place those actions next to the context they act on. All these reasons made us choose to put them next to the stack and not next to the source. > > We certainly understand that this is a departure from the classic debugger and perhaps this is not the best way of doing things, but that was the rationale we went through. I would be happy to hear other suggestions, but please understand that we need to take into account the full spectrum of constraints when choosing solutions. > > In any case, the idea of this debugger is that you can change it in the way you want and customize it specifically for your needs. We still need to document how to do that, but if someone wants to start creating a custom debugger we could use the experience to drive the documentation. > > Does this explain the situation? > > Cheers, > Doru > > >> On May 25, 2016, at 9:43 PM, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: >> >> Hi, >> >> today I moved to Pharo5. It is great to get feedback and solutions for >> problems so quickly. It is a pleasure to work with Pharo and to have the >> community. I am grateful for having this. >> >> I have one comment. I don't want to complain, I can use it but I was >> wondering about the new position and size of the debugger buttons. >> >> There is a longer distance now from code text pane to the buttons - I see >> this as disadvantage to earlier versions of Pharo from the user experience. >> The buttons are a lot of smaller - same disadvantage - both if you use the >> mouse. >> >> Ok, after seeing that, I thought "Sabine, you should use keyboard shortcuts >> here, too" (I use much of them but interesting - til now not in the >> debugger). >> >> Then I saw the shortcuts for >> Proceed cmd+r >> Restart cmd-shift-a >> Into cmd-e >> over cmd-shift-o >> through cmd-shift-t >> >> especially into, over and through have so different key combinations, two >> with shift, one without shift. When I debug, I often use for example >> into-into-over-over-over-throuhg-through--into-into etc...and with the >> combinations cmd-e and cmd-shit-e, it is more "finger-work". It would be >> better to have all those shortcuts with or all shortcuts without shift. And >> the letters not so far away at the keyboard (e-o-t) >> >> This is only my opinion and my first impression after one day with Pharo5. I >> am sure, after a few days, I forgot that this was uncomfortable because I >> have the shortcuts coming automatically into my fingers. >> >> Regards >> Sabine >> >> >> >> >> >> >> -- >> View this message in context: http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing should have the right to be different." > > > > > > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

June 4, 2016

Re: [Pharo-users] Issue on Seaside beginning

by Cyril Ferlicot D.

Le 04/06/2016 19:00, Cheikhou Oumar KA a Ã©crit : > Hello. > > I am following #PharoMOOC and it become more and more exciting. > > I were doing TinyBlog exercise and I got an issue. I looked at the forum > but any solution and I am stuck now like many others. > > I have created my class TBApplicationRootComponent, create a server that > listen at :8080 and start it, regiser my application.... > > But at http://localhost:8080/browse I got this Image in my browser > > > Images intÃ©grÃ©es 1 > > Any help is welcome. > > Thanks > > -- > /*Cheikhou Oumar KA */ > å¥¥ é©¬ å° Â·è°¢ èµ« Â·å*/ > /*Doctorant Informatique > cheikhouka(a)gmail.com <mailto:cheikhouka@gmail.com> > > > Hi, I think I already got this problem when I loaded Seaside 3.2 in an image where Seaside 3.1 was present. I'm not sure it's the same problem and I don't have the time to look at it but maybe this can help others to find a solution. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

June 4, 2016

Re: [Pharo-users] One comment to new Pharo5 debugger

by Ben Coman

On Sat, Jun 4, 2016 at 11:28 PM, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > Hi, > I undestand and really liked the idea of a moldable debugger and it's true > that the button actions act over the stack, however the decision on what > action to use is taken not looking to the stack pane (normally I've decided > what to do looking on the source pane). In this context, the buttons are > far away where the attention usually is (the code pane). IMHO for the user > experience point of view I think is better to have the actions below the > stack list and above the stack pane to let the user do not diverge his > attention. I'm proposing not dettaching the action buttons for the stack > pane, just changing the location (and also moving and inverting the > direction of the tab label to not waste space). > Interesting idea. Only the [Stack] tab is a bit lonely over there on the right. Perhaps the tab could still be on the left, with the buttons left justified against it? btw, are there any use cases for multiple stack tabs? cheers -ben > > Maybe something like this (sorry no photoshop here :) ): > â > We need to figure it out a way to improve this situation. > > Regards, > Gabriel > > On Sat, Jun 4, 2016 at 3:45 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi Sabine (and others that asked this question), >> >> Thanks for the feedback. Sorry for the delayed reply, but I am traveling >> these days and I have limited online time. Also, this email took some time >> to write (I started it about a week ago). >> >> I will answer the buttons issue. The reason they are in a different place >> than where they used to be is related to new constraints that come with the >> new debugger. While the default interface looks like a regular debugger, >> the main feature of the GTDebugger is that it can be customized to match a >> specific domain or library. >> >> Let me provide an example of a scenario of debugging PetitParser: >> >> PPArithmeticParser parse: '1+2*3^(34-2)â >> >> The default debugger looks like this: >> >> >> But, because we have PetitParser code on the stack, we can switch to a >> custom debugger: >> >> >> This one also features the input stream next to the code. Also, note that >> the stack received 3 new button actions. But, this is not all. Next to the >> source, there are other tabs, and we can switch to one of those: >> >> >> This one shows the source as well, but in a graphical form. >> >> So, if we step back and talk about the buttons, you will see that if we >> would have put the buttons on the source tabs, you have had no way to >> advance in this state. We could have also duplicated behavior and put the >> buttons on the new presentation as well, but the space is much smaller and >> since we now have large buttons instead of only icons we needed to deal >> with that as well. We encountered similar situations in other debuggers >> (not all, though). >> >> But, from a more point of view, the actions act on the stack. So, if we >> take an object-oriented approach for designing the UI, it makes sense to >> place those actions next to the context they act on. All these reasons made >> us choose to put them next to the stack and not next to the source. >> >> We certainly understand that this is a departure from the classic >> debugger and perhaps this is not the best way of doing things, but that was >> the rationale we went through. I would be happy to hear other suggestions, >> but please understand that we need to take into account the full spectrum >> of constraints when choosing solutions. >> >> In any case, the idea of this debugger is that you can change it in the >> way you want and customize it specifically for your needs. We still need to >> document how to do that, but if someone wants to start creating a custom >> debugger we could use the experience to drive the documentation. >> >> Does this explain the situation? >> >> Cheers, >> Doru >> >> >> On May 25, 2016, at 9:43 PM, Sabine Manaa <manaa.sabine(a)gmail.com> wrote: >> >> Hi, >> >> today I moved to Pharo5. It is great to get feedback and solutions for >> problems so quickly. It is a pleasure to work with Pharo and to have the >> community. I am grateful for having this. >> >> I have one comment. I don't want to complain, I can use it but I was >> wondering about the new position and size of the debugger buttons. >> >> There is a longer distance now from code text pane to the buttons - I see >> this as disadvantage to earlier versions of Pharo from the user >> experience. >> The buttons are a lot of smaller - same disadvantage - both if you use the >> mouse. >> >> Ok, after seeing that, I thought "Sabine, you should use keyboard >> shortcuts >> here, too" (I use much of them but interesting - til now not in the >> debugger). >> >> Then I saw the shortcuts for >> Proceed cmd+r >> Restart cmd-shift-a >> Into cmd-e >> over cmd-shift-o >> through cmd-shift-t >> >> especially into, over and through have so different key combinations, two >> with shift, one without shift. When I debug, I often use for example >> into-into-over-over-over-throuhg-through--into-into etc...and with the >> combinations cmd-e and cmd-shit-e, it is more "finger-work". It would be >> better to have all those shortcuts with or all shortcuts without shift. >> And >> the letters not so far away at the keyboard (e-o-t) >> >> This is only my opinion and my first impression after one day with >> Pharo5. I >> am sure, after a few days, I forgot that this was uncomfortable because I >> have the shortcuts coming automatically into my fingers. >> >> Regards >> Sabine >> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390.html >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com >> <http://nabble.com>. >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Every thing should have the right to be different." >> >> >> >> >> >

June 4, 2016