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

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

by Sabine Manaa

Johan, thank you, this works fine! regards Sabine 2016-05-27 2:33 GMT+02:00 jfabry [via Smalltalk] < ml-node+s1294792n4897659h24(a)n4.nabble.com>: > > I will just leave this here, so that people that prefer the buttons in > their original place can get them back ... > > I did some quick investigating, and itâs straightforward. Just change the > implementation of GTGenericStackDebugger>>codeActionsPragmas to the > following: > > codeActionsPragmas > > ^ #( codeDebuggingAction stackDebuggingAction ) > > Et voila, the stack debugging action buttons now are also available just > above the code pane! > > For extra goodness, the following two-liner is now also going into my > startup preferences, run-once code part: > > GTGenericStackDebugger compile: 'codeActionsPragmas > ^ #(stackDebuggingAction codeDebuggingAction)' classified: 'building > actions' > > Voila, I will never miss those buttons again :-) > > -- > Does this mail seem too brief? Sorry for that, I donât mean to be rude! > Please see http://emailcharter.org . > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University > of Chile > > On May 26, 2016, at 11:01, stepharo <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4897659&i=0>> wrote: > > > Yes, and there was also some discussion on the Pharo-users mailing list. > Apparently the same comments more or less ... > > I give a big +1 on moving the buttons down, so that they are between the > stack and the code pane. I still donât understand why they need to be so > far away from the code pane, it makes much more sense above the code pane + > we save on mouse movements. > > > Because doru got trapped into his own view on "UI design". > > Even apple does not respect its own design documents. > > Stef > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390p4897659.… > To start a new topic under Pharo Smalltalk Users, email > ml-node+s1294792n1310670h65(a)n4.nabble.com > To unsubscribe from Pharo Smalltalk Users, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/One-comment-to-new-Pharo5-debugger-tp4897390p4897703.… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 27, 2016

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

by Johan Fabry

I will just leave this here, so that people that prefer the buttons in their original place can get them back ... I did some quick investigating, and itâs straightforward. Just change the implementation of GTGenericStackDebugger>>codeActionsPragmas to the following: codeActionsPragmas ^ #( codeDebuggingAction stackDebuggingAction ) Et voila, the stack debugging action buttons now are also available just above the code pane! For extra goodness, the following two-liner is now also going into my startup preferences, run-once code part: GTGenericStackDebugger compile: 'codeActionsPragmas ^ #(stackDebuggingAction codeDebuggingAction)' classified: 'building actions' Voila, I will never miss those buttons again :-) -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On May 26, 2016, at 11:01, stepharo <stepharo(a)free.fr> wrote: > > >> Yes, and there was also some discussion on the Pharo-users mailing list. Apparently the same comments more or less ... >> >> I give a big +1 on moving the buttons down, so that they are between the stack and the code pane. I still donât understand why they need to be so far away from the code pane, it makes much more sense above the code pane + we save on mouse movements. > > Because doru got trapped into his own view on "UI design". > > Even apple does not respect its own design documents. > > Stef

May 27, 2016

Re: [Pharo-users] Having STON generate flatter output

by Sven Van Caekenberghe

Yes, STON uses depth-first traversal of the object graph. Since it uses numbered references, the traversal has to be fixed. This excludes other traversals, as far as I can see. > On 26 May 2016, at 22:00, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > At a first glance it seems to me that it uses DFS instead of BFS, because it doesn't distinguish what is it actually following. > So maybe the strategy could be to follow BFS and use subinstances of Collection as references. > > Peter > > On Thu, May 26, 2016 at 9:20 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi, > > I didn't find that strategy and finally created a #flatten method before serializing my grafoscopio trees, with just what I wanted. At [1] you can find the last version of the notebook show at this screenshot: > > <ffcheafc..png> > > [1] http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212 > > I know is this doesn't solve in anyway your problem... but may be it could inspire you in some way. I was asking also for a flatter STON and the idea of a method to flatten the tree wrote by myself was not evident at the beginning, but was a very good solution. > > Cheers, > > Offray > > > On 26/05/16 13:52, Peter UhnÃ¡k wrote: >> Hi, >> >> is it possible to configure STON to generate more flat output? >> >> Imagine a scenario where an element can have children and the children have reference to their parent >> >> <Mail Attachment.png> >> â >> Now the problem is that the output of STON will depend on the order of the items, >> so if I have "nice" ordering for the following, I will get a flat output >> >> <Mail Attachment.png> >> â >> If however the ordering is different, the output will be more nested >> >> <Mail Attachment.png> >> â >> As the ordering is not stable, I often end up with results like this (zoomed out) >> >> <Mail Attachment.png> >> â >> The image above has depth of about fourteen, even though it could be represented with just depth of four. >> >> In the current state I cannot actually look at the generated output because it's impossible to find anything, which is problematic when an error occurs. >> >> So the question is if it is possible to push the actual objects as far up as possible, and use references "@12" only on the deeper levels. >> >> Thanks, >> Peter >> > >

May 26, 2016

Re: [Pharo-users] Having STON generate flatter output

by Peter UhnÃ¡k

At a first glance it seems to me that it uses DFS instead of BFS, because it doesn't distinguish what is it actually following. So maybe the strategy could be to follow BFS and use subinstances of Collection as references. Peter On Thu, May 26, 2016 at 9:20 PM, Offray Vladimir Luna CÃ¡rdenas < offray.luna(a)mutabit.com> wrote: > Hi, > > I didn't find that strategy and finally created a #flatten method before > serializing my grafoscopio trees, with just what I wanted. At [1] you can > find the last version of the notebook show at this screenshot: > > > > [1] > http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212 > > I know is this doesn't solve in anyway your problem... but may be it could > inspire you in some way. I was asking also for a flatter STON and the idea > of a method to flatten the tree wrote by myself was not evident at the > beginning, but was a very good solution. > > Cheers, > > Offray > > > On 26/05/16 13:52, Peter UhnÃ¡k wrote: > > Hi, > > is it possible to configure STON to generate more flat output? > > Imagine a scenario where an element can have children and the children > have reference to their parent > > > â > Now the problem is that the output of STON will depend on the order of the > items, > so if I have "nice" ordering for the following, I will get a flat output > > > â > If however the ordering is different, the output will be more nested > > > â > As the ordering is not stable, I often end up with results like this > (zoomed out) > > > â > The image above has depth of about fourteen, even though it could be > represented with just depth of four. > > In the current state I cannot actually look at the generated output > because it's impossible to find anything, which is problematic when an > error occurs. > > So the question is if it is possible to push the actual objects as far up > as possible, and use references "@12" only on the deeper levels. > > Thanks, > Peter > > >

May 26, 2016

Re: [Pharo-users] Having STON generate flatter output

by Offray Vladimir Luna CÃ¡rdenas

Hi, I didn't find that strategy and finally created a #flatten method before serializing my grafoscopio trees, with just what I wanted. At [1] you can find the last version of the notebook show at this screenshot: [1] http://mutabit.com/repos.fossil/panama-papers/artifact/cbfe8929edf64212 I know is this doesn't solve in anyway your problem... but may be it could inspire you in some way. I was asking also for a flatter STON and the idea of a method to flatten the tree wrote by myself was not evident at the beginning, but was a very good solution. Cheers, Offray On 26/05/16 13:52, Peter UhnÃ¡k wrote: > Hi, > > is it possible to configure STON to generate more flat output? > > Imagine a scenario where an element can have children and the children > have reference to their parent > > > â > Now the problem is that the output of STON will depend on the order of > the items, > so if I have "nice" ordering for the following, I will get a flat output > > > â > If however the ordering is different, the output will be more nested > > > â > As the ordering is not stable, I often end up with results like this > (zoomed out) > > > â > The image above has depth of about fourteen, even though it could be > represented with just depth of four. > > In the current state I cannot actually look at the generated output > because it's impossible to find anything, which is problematic when an > error occurs. > > So the question is if it is possible to push the actual objects as far > up as possible, and use references "@12" only on the deeper levels. > > Thanks, > Peter >

May 26, 2016

Re: [Pharo-users] Having STON generate flatter output

by Esteban A. Maringolo

That is more a serialization strategy issue, that happens a lot with JSON serialization as well. As far as I could see there is no such feature to perform substitutions neither at read/write time in STON or NeoJSON, for that you would need to traverse the whole object graph first, or have some metadata about what is is going to be fully serialized and what it is going to be a reference, like Fuel does. Regards! Esteban A. Maringolo 2016-05-26 15:52 GMT-03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > is it possible to configure STON to generate more flat output? > > Imagine a scenario where an element can have children and the children > have reference to their parent > > > â > Now the problem is that the output of STON will depend on the order of the > items, > so if I have "nice" ordering for the following, I will get a flat output > > > â > If however the ordering is different, the output will be more nested > > > â > As the ordering is not stable, I often end up with results like this > (zoomed out) > > > â > The image above has depth of about fourteen, even though it could be > represented with just depth of four. > > In the current state I cannot actually look at the generated output > because it's impossible to find anything, which is problematic when an > error occurs. > > So the question is if it is possible to push the actual objects as far up > as possible, and use references "@12" only on the deeper levels. > > Thanks, > Peter > >

May 26, 2016

Having STON generate flatter output

by Peter UhnÃ¡k

Hi, is it possible to configure STON to generate more flat output? Imagine a scenario where an element can have children and the children have reference to their parent â Now the problem is that the output of STON will depend on the order of the items, so if I have "nice" ordering for the following, I will get a flat output â If however the ordering is different, the output will be more nested â As the ordering is not stable, I often end up with results like this (zoomed out) â The image above has depth of about fourteen, even though it could be represented with just depth of four. In the current state I cannot actually look at the generated output because it's impossible to find anything, which is problematic when an error occurs. So the question is if it is possible to push the actual objects as far up as possible, and use references "@12" only on the deeper levels. Thanks, Peter

May 26, 2016

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

by stepharo

> Yes, and there was also some discussion on the Pharo-users mailing > list. Apparently the same comments more or less ... > > I give a big +1 on moving the buttons down, so that they are between > the stack and the code pane. I still donât understand why they need to > be so far away from the code pane, it makes much more sense above the > code pane + we save on mouse movements. Because doru got trapped into his own view on "UI design". Even apple does not respect its own design documents. Stef

May 26, 2016

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

by Esteban Lorenzano

> On 26 May 2016, at 14:49, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > > Yes, and there was also some discussion on the Pharo-users mailing list. Apparently the same comments more or less ... > > I give a big +1 on moving the buttons down, so that they are between the stack and the code pane. I still donât understand why they need to be so far away from the code pane, it makes much more sense above the code pane + we save on mouse movements. is because of the âmoldableâ nature of the debugger, since the code panel could be anything (like a custom browser, etc.), it is not certain that buttons can be thereâ¦ only âconstantâ place is the top of the browserâ¦ that does not means I do not agree it would be better closer to the code itselfâ¦ but I will need to take a care look to that before proposing a possible change. Esteban > > -- > Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . > > Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/~jfabry> > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > >> On May 26, 2016, at 04:37, Christophe Demarey <Christophe.Demarey(a)inria.fr <mailto:Christophe.Demarey@inria.fr>> wrote: >> >> Hi Sabine, >> >> this point was also Â« discussed Â» (no answer) here: http://forum.world.st/gtdebugger-debug-actions-buttons-td4874316.html <http://forum.world.st/gtdebugger-debug-actions-buttons-td4874316.html> >> Yes, the new buttons are counter-productive and there is even no setting to have them usable â¦ >> You can still with to the SpecDebugger through settings >> >> >>> Le 25 mai 2016 Ã 22:49, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> a Ã©crit : >>> >>> Hi, >>> >>> yes, this question was raised before, but there are some disagreements over how it should be, so it may take some time http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html <http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html> >>> >>> You can also use a startup script to reassign them, such as this one. https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformD… <https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformD…> >>> But a startup script is a temporary solution. >>> >>> On Wed, May 25, 2016 at 9:43 PM, Sabine Manaa <manaa.sabine(a)gmail.com <mailto:manaa.sabine@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 <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/>. >>> >>> >> >

May 26, 2016

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

by Johan Fabry

Yes, and there was also some discussion on the Pharo-users mailing list. Apparently the same comments more or less ... I give a big +1 on moving the buttons down, so that they are between the stack and the code pane. I still donât understand why they need to be so far away from the code pane, it makes much more sense above the code pane + we save on mouse movements. -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org <http://emailcharter.org/> . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On May 26, 2016, at 04:37, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > > Hi Sabine, > > this point was also Â« discussed Â» (no answer) here: http://forum.world.st/gtdebugger-debug-actions-buttons-td4874316.html <http://forum.world.st/gtdebugger-debug-actions-buttons-td4874316.html> > Yes, the new buttons are counter-productive and there is even no setting to have them usable â¦ > You can still with to the SpecDebugger through settings > > >> Le 25 mai 2016 Ã 22:49, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> a Ã©crit : >> >> Hi, >> >> yes, this question was raised before, but there are some disagreements over how it should be, so it may take some time http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html <http://forum.world.st/GTDebugger-shortcuts-usability-td4890316.html> >> >> You can also use a startup script to reassign them, such as this one. https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformD… <https://github.com/peteruhnak/pharo-scripts/blob/master/config/5.0/uniformD…> >> But a startup script is a temporary solution. >> >> On Wed, May 25, 2016 at 9:43 PM, Sabine Manaa <manaa.sabine(a)gmail.com <mailto:manaa.sabine@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 <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/>. >> >> >

May 26, 2016