- Pharo-users - lists.pharo.org

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

Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

by Sabine Manaa

Hi Peter, thanks. But I will wait for next integration level. I would like to try it but I have to organize my time strictly, so I have no time to play around so much ;-( Regards Sabine 2016-05-26 11:33 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi, > > > To manage on github there are some blog around > > I wrote a guide for moving from SmalltalkHub to Github > http://peteruhnak.com/blog/2016/03/02/moving-project-from-smalltalkhub-to-g… > And Uko wrote about versioning > http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.h… > > now I am writing a bit more practical guide on how to use Git from Pharoâ¦ > hopefully it will be done during weekend, I'm busy with other stuff atm. > > Peter >

May 26, 2016

Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

by Peter UhnÃ¡k

Hi, > To manage on github there are some blog around I wrote a guide for moving from SmalltalkHub to Github http://peteruhnak.com/blog/2016/03/02/moving-project-from-smalltalkhub-to-g… And Uko wrote about versioning http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.h… now I am writing a bit more practical guide on how to use Git from Pharoâ¦ hopefully it will be done during weekend, I'm busy with other stuff atm. Peter

May 26, 2016

Re: [Pharo-users] Having a more robust PharoLauncher in low-bandwidth conditions

by Serge Stinckwich

On Wed, May 25, 2016 at 9:27 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> something like wget or curl > > there's also zeroconf as the alternative, or directly downloading the zip > http://files.pharo.org/image/ I'm not sure I can use images build on the CI with zeroconf. > Also Stef made a flash stick with Pharo, videos, etc. exactly for places > like this (with bad or no internet). Yes, sure. But you want to dl recent images, this does not work :-) > But of course PharoLauncher shouldn't crash. Alternatively PharoLauncher as > far as I know has a local cache, so maybe if you need just a fresh image and > not the latest one you could reuse that? I will look at PharoLauncher code if I have some time. At the moment, I'm using wget to dl to my PharoLauncher directory. Thank you. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

May 26, 2016

Re: [Pharo-users] Problem with Mongo on Pharo5 ("collection already exists")

by stepharo

Le 25/5/16 Ã 21:57, Sabine Manaa a Ã©crit : > Hi Esteban, > > do you know a documentation/entry point about moving to github? To manage on github there are some blog around. Now what we want to offer is something else: We want to have one solution where you can publish using git (but that people can also use fossil or mercurial if they provide the right commands) from within Pharo. > Is it in experimental state experimental for the integrated pharo version > or recommended for all Pharo users? we want to offer a solution for everybody with minimum pain. > How/where to start? > > Regards > Sabine > > 2016-05-25 21:54 GMT+02:00 EstebanLM [via Smalltalk] <[hidden email] > </user/SendEmail.jtp?type=node&node=4897395&i=0>>: > > Hi, > > yes, I recommend you to use the github version, we are moving there. > But anyway we are keeping the sthub as mirrorâ¦ it just got > de-sync. And the only reason why I needed the merge, and not a > simple copy is because metadataless format got activated and I > lost the history, so I rather merge to recover history in some wayâ¦ :) > > cheers! > Esteban > >> On 25 May 2016, at 21:23, Sabine Manaa <[hidden email] >> <http:///user/SendEmail.jtp?type=node&node=4897394&i=0>> wrote: >> >> Hi Esteban, >> >> great, now it works. Thank you! >> >> In the comments, I see "merged with github". I am curious about >> using github in future, too. >> >> Regards >> Sabine >> >> 2016-05-25 21:01 GMT+02:00 EstebanLM [via Smalltalk]<<a >> href="x-msg://138/user/SendEmail.jtp?type=node&node=4897384&i=0" >> target="_top" rel="nofollow" link="external" class="">[hidden >> email]>: >> >> hi Sabine, >> >> please update to latest packages of Voyageâ¦ there was a >> de-sync problem with the API change in MongoTalk, that >> *should* fix your issue. >> >> cheers, >> Esteban >> >> >>> On 25 May 2016, at 16:29, Sabine Manaa <[hidden email] >>> <http://user/SendEmail.jtp?type=node&node=4897378&i=0>> wrote: >>> >>> note that it only occurs (hanging image) if you do >>> "VORepository current reset" >>> before. Or have a new Image. >>> >>> >>> 2016-05-25 15:38 GMT+02:00 Sabine Manaa<[hidden email] >>> <http://user/SendEmail.jtp?type=node&node=4897378&i=1>>: >>> >>> I have a non-responding image with the original code >>> (with the signal) >>> >>> 2016-05-25 15:14 GMT+02:00 Holger Freyther [via >>> Smalltalk]<[hidden email] >>> <http://user/SendEmail.jtp?type=node&node=4897348&i=0>>: >>> >>> >>> > On 25 May 2016, at 15:42, Esteban Lorenzano >>> <[hidden email] >>> <http://user/SendEmail.jtp?type=node&node=4897346&i=0>> >>> wrote: >>> > >>> > >>> >>> Hi, >>> >>> >>> > No I donâtâ¦ in part because is not me who make >>> that code, but also because it is expected: after, >>> you have: >>> > >>> > getCollection: aString >>> > ^ [ self addCollection: aString capped: false >>> size: nil max: nil ] >>> > on: MongoCollectionAlreadyExists >>> > do: [ :err | >>> > MongoCollection database: self name: aString ] >>> > >>> > so the idea is to refine the error to separate >>> MongoCollectionAlreadyExists so it can later be >>> catch and handled properly. >>> >>> when adding capped collection support it seemed like >>> a good idea to fail if a collection already exists >>> that might not be capped, but given the follow up >>> issues I wonder if I/we should restore the original >>> behavior that just ignored all errors? >>> >>> holger >>> >>> >>> ------------------------------------------------------------------------ >>> If you reply to this email, your message will be >>> added to the discussion below: >>> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exist… >>> To start a new topic under Pharo Smalltalk Users, >>> email[hidden email] >>> <http://user/SendEmail.jtp?type=node&node=4897348&i=1> >>> To unsubscribe from Pharo Smalltalk Users,click here. >>> NAML >>> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> View this message in context:Re: Problem with Mongo on >>> Pharo5 ("collection already exists") >>> <http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exist…> >>> >>> >>> Sent from thePharo Smalltalk Users mailing list archive >>> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>atNabble.com >>> <http://nabble.com/>. >>> >>> >> >> >> >> ------------------------------------------------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exist… >> To start a new topic under Pharo Smalltalk Users, email<a >> href="x-msg://138/user/SendEmail.jtp?type=node&node=4897384&i=1" >> target="_top" rel="nofollow" link="external" class="">[hidden >> email] >> To unsubscribe from Pharo Smalltalk Users,click here. >> NAML >> <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> >> >> >> >> ------------------------------------------------------------------------ >> View this message in context:Re: Problem with Mongo on Pharo5 >> ("collection already exists") >> <http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exist…> >> Sent from thePharo Smalltalk Users mailing list archive >> <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html>atNabble.com >> <http://nabble.com/>. > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the > discussion below: > http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exist… > > To start a new topic under Pharo Smalltalk Users, email [hidden > email] </user/SendEmail.jtp?type=node&node=4897395&i=1> > To unsubscribe from Pharo Smalltalk Users, click here. > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > > > > > ------------------------------------------------------------------------ > View this message in context: Re: Problem with Mongo on Pharo5 > ("collection already exists") > <http://forum.world.st/Problem-with-Mongo-on-Pharo5-collection-already-exist…> > Sent from the Pharo Smalltalk Users mailing list archive > <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> at Nabble.com.

May 26, 2016