October 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GT-Inspector silly titles

by stepharo

doru why we do not introduce displayString as suggested long time ago and default displayString to printString? Stef On 6/10/14 13:33, Tudor Girba wrote: > Hi, > > Yes, the label does introduce redundancy in some cases, but that is > because the use of printString has to be rethought :) > > printString was used for a long time as a primary inspection tool. > Because of that it tries to do too much (like adding the class name), > and it is certainly not suitable for a label. > > gtDisplayString is meant for labeling the content of the object. It is > used also for things like a list. As soon as you will do something > with your objects, you will want to have something smaller. There is > no need to have the class part of that string. Relying on that > convention is brittle, as it is easy for people to not have the class > name in there. But, for an inspector, having the class at all times is > a prerequisite, so that will be displayed always separately (to ensure > that the right information is offered). > > gtDisplayString relies on printString by default, so people can > provide the labels at their convenience. > > Cheers, > Doru > > > On Mon, Oct 6, 2014 at 1:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>> wrote: > > I think the titles of GT-Inspector windows/panes are a bit silly: > > > Notice the 'a ZnClient(a ZnClient)' and 'a Dictionary(a > Dictionary(...))' where the class name is repeated. > > I think it is very important to honour the standard/general > Smalltalk approach and assume the #printString already contains > the class name. If not, you are basically punishing everybody who > went through the trouble of writing custom #printString > implementation (like me, I do this for most classes). > > I saw the whole #display thing, but you can't force everybody to > rewrite #printString to #gtDisplayString or whatever. > > Sven > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 7, 2014

Re: [Pharo-dev] DNUs in the styler

by stepharo

Marcus can you open a roadmap file on github so that we know and can take action. This is a nice way to share knowledge and possible actions. Stef >> I had the setting on "use AST styler" which explains the DNUs. I >> turned it off so that's solved. >> > Yes, this is not completely working yetâ¦ we need to do the move and > fix all the bugsâ¦ > >> The sequence above shows that the RBParserErrorNode thing [1] works >> in some cases and not all. >> >> Are you planning something in that area? >> > > Planning yesâ¦ but not started yetâ¦ I need to finish other things > before. So every contribution is welcome... > >> Thierry >> >> [1] encapsulating a syntax error in a RBParserErrorNode so that: >> styling can happen on a correct part of the code; and that (maybe) >> parsing can continue. >> >> >

Oct. 7, 2014

Re: [Pharo-dev] GT-Inspectors need live updating

by Tudor Girba

Hi, No. Tabs are lazy. Doru On Tue, Oct 7, 2014 at 7:00 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 07/10/2014 06:57, Tudor Girba a Ã©crit : > >> My argument was that if you redraw this several times, it will make it >> even more apparent. >> > > Obviously. > > Does the representation in a tab builds itself even if the tab isn't > visible/selected? > > Thierry > > Doru >> >> On Tue, Oct 7, 2014 at 6:54 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 06/10/2014 23:35, Sven Van Caekenberghe a Ã©crit : >> >> I understand, but even with those impressive graphical views, it >> would be really cool if updates happened automagically, right ? >> Add >> something to a collection, graphs updated.... >> >> Would it not be an idea that presentations can 'opt out' of >> updating, >> because they know things take too much time, while other, simpler >> ones can 'opt in'. Or maybe choose a slower updating cycle, >> skipping >> intermediate steps - just thinking out loud. >> >> Working with the GT presentations, I sense that some performance >> issue will come up, I just decided to ignore them for now. >> >> >> The performance issue is already there. Opening a GTinspector on >> certain types (RB AST, for example) can be felt as slow: i.e. over >> 0.5s delay. >> >> Thierry >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" >> > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 7, 2014

Re: [Pharo-dev] GT-Inspectors need live updating

by Thierry Goubier

Le 07/10/2014 06:57, Tudor Girba a Ã©crit : > My argument was that if you redraw this several times, it will make it > even more apparent. Obviously. Does the representation in a tab builds itself even if the tab isn't visible/selected? Thierry > Doru > > On Tue, Oct 7, 2014 at 6:54 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Le 06/10/2014 23:35, Sven Van Caekenberghe a Ã©crit : > > I understand, but even with those impressive graphical views, it > would be really cool if updates happened automagically, right ? Add > something to a collection, graphs updated.... > > Would it not be an idea that presentations can 'opt out' of > updating, > because they know things take too much time, while other, simpler > ones can 'opt in'. Or maybe choose a slower updating cycle, skipping > intermediate steps - just thinking out loud. > > Working with the GT presentations, I sense that some performance > issue will come up, I just decided to ignore them for now. > > > The performance issue is already there. Opening a GTinspector on > certain types (RB AST, for example) can be felt as slow: i.e. over > 0.5s delay. > > Thierry > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

Oct. 7, 2014

Re: [Pharo-dev] GT-Inspectors need live updating

by Tudor Girba

My argument was that if you redraw this several times, it will make it even more apparent. Doru On Tue, Oct 7, 2014 at 6:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 06/10/2014 23:35, Sven Van Caekenberghe a Ã©crit : > >> I understand, but even with those impressive graphical views, it >> would be really cool if updates happened automagically, right ? Add >> something to a collection, graphs updated.... >> >> Would it not be an idea that presentations can 'opt out' of updating, >> because they know things take too much time, while other, simpler >> ones can 'opt in'. Or maybe choose a slower updating cycle, skipping >> intermediate steps - just thinking out loud. >> >> Working with the GT presentations, I sense that some performance >> issue will come up, I just decided to ignore them for now. >> > > The performance issue is already there. Opening a GTinspector on certain > types (RB AST, for example) can be felt as slow: i.e. over 0.5s delay. > > Thierry > > > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 7, 2014

Re: [Pharo-dev] GT-Inspectors need live updating

by Thierry Goubier

Le 06/10/2014 23:35, Sven Van Caekenberghe a Ã©crit : > I understand, but even with those impressive graphical views, it > would be really cool if updates happened automagically, right ? Add > something to a collection, graphs updated.... > > Would it not be an idea that presentations can 'opt out' of updating, > because they know things take too much time, while other, simpler > ones can 'opt in'. Or maybe choose a slower updating cycle, skipping > intermediate steps - just thinking out loud. > > Working with the GT presentations, I sense that some performance > issue will come up, I just decided to ignore them for now. The performance issue is already there. Opening a GTinspector on certain types (RB AST, for example) can be felt as slow: i.e. over 0.5s delay. Thierry

Oct. 7, 2014

Re: [Pharo-dev] About ways to participate in community and general negativity

by Florin Mateoc

Hi Thierry, On 10/6/2014 9:37 AM, Thierry Goubier wrote: > Hi Florin, > > you're in for some interesting questions :) > > First, I did not have a methodology for finding the issue (or explaining the algorithm) when I started, and I didn't > have one afterwards; you need to look into the WhyLine stuff for that (they do a lot better, but I don't have the time > to reimplement their tool). > Thanks for pointing it out. It is indeed interesting, but not what I had in mind. I am not talking about debugging here so much. I am quite good at that, and I find it natural to build tools that help me do it (and of course, Smalltalk debuggers are very good already (restarting a method/block pretty much gives you the benefits of stepping backwards)), but debugging broken behavior is more about mapping an internalized model of the execution with what's really happening, seeing where they diverge. You are just checking that what you think you know is true. Of course, when you find out it's not, you gain insight/experience. But what to do when there is nothing to check? What if, like in the situation you mentioned, the algorithm is already working (so it's producing the correct/expected results)? But you still want to make it better.... What I want help with is what I am not as good at. I want to literally "see" what's wrong (not good enough) with the picture, since the brain has those very powerful visual pattern matching capabilities. They remain unused when you are lost in the minutiae of the debugger, where you only see text and numbers, the granularity/level of abstraction is too low. Profilers are a little better - they also succinctly capture the execution tree, and I have also used traces for hard to debug sequences. Coming back to the WhyLine example, they already had something to (visually) look at: objects colliding. Other times, the visual representation is obvious/implied (say an algorithm for driving a car on a given course - even if all you are given are coordinates, it is common sense that you would draw the course on the screen and watch the car as it makes progress when the algorithm ticks). In many algorithms you don't have that. How do you find, in such cases, what pictures/graphs/animations to look at? For an algorithm one obvious candidate would be to the dynamic behavior of the main data structures used (although, say you do this for the car example and compare and contrast visualizing the data structures used by the algorithm vs visualizing the car moving, or the objects colliding). And you still have to find the right scale and level of abstraction. > But I noticed that understanding an algorithm is easy (relatively) when: > > - You can easily move repeatedly to any point in an execution stream of that algorithm (i.e. ubiquitous debugging: > step forward, backward, jump at any point back and forth, any number of times). > > - At each point, you are given the precise point in the source code (debugger-like) > > - At each point, you get significant values: assignments, arguments, return values > > Representation is easy: an execution is a tree. A sequence in this execution is items at the same level in the tree. > Calls are subtrees, as well as iterations. Gui is simple: a tree on the left, code pane on the right. See an example > underway: I'm trying to find a bug in LayoutFrame, so I traced LayoutFrame>>transform: (without breaking Morphic). > This is for exploration at the moment, and not comparing values. And on a single method, and highlighting is broken in > Pharo 4 :( > > In the value tracking idea, what we thought then in the place I worked in at that time, is that we could study > comparing / diffing trace trees to see where the two versions of the algorithm diverges. We didn't follow up and it > wasn't published. I have new visualisations on Roassal now, but they are for static analysis of multitask C code. > > Does that give you ideas? > > Thierry The discussion is good, thank you. I don't think I have found the answers yet, but looking for them is fun too Florin

Oct. 7, 2014

Re: [Pharo-dev] [ANN] flow: a living full-stack #âframework for the web

by Sebastian Sastre

Yeah we need to make a proper logo and landing page thing is Iâve rushed it so I can be announced at CampSmalltalkVI2014 Iâd really like to see something ala meteor about download, start and use but at this point I have to pay attention to what my clients ask and flow will win features that cascade from that Itâs all open to contributions so if you have ideas on how to get that done youâre welcome to help (one show stopper Iâve found to do one thing runs all was the nginx configuration, itâs needed for the websockets connections used by flow's realtime features) Some of your questions are covered here (including question on Seaside/Aida): https://github.com/flow-stack/flow/blob/master/FAQ.md others donât, please add them and send me pull request so we at least have them scaffolded to answer later I agree with Sven and you, a written tutorial will be great, itâs here in the project kanban already Mapless is fun! useful for easy persistence but also to throw and catch JSON all over the network keep shooting! On Oct 6, 2014, at 3:25 PM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > > This development stack sounds really nice! > A really great idea. > Some thoughts (more or less en vrac, apologizes): > As it is aimed at people who want a working app/demo solution out of the box, > and if you intent is to push this stack further, perhaps it should have > a more dedicated site than github with links to: > - the setup part (more or less your github pages?) > - a zipped tarball with everything working out of the box with > up to date versions of mongo, nginx, the Pharo image , > and all parts needed : a tarball for windows, one for linux, one for mac > - a sample application and the tutorial how to build it > (Sven's is right) I have no clue about angularjs? - I know I have to learn javascript, made some trials > but don't like it much - does it replace or complete seaside (don't think so , but not sure) ? , > how does it play with jquery and others ? > - a part about mongo. > I like mongo, even if I work with relational systems every day. > I don't like orms and Mapless sounds great > (but as I discovered it this morning on your site I have to spend > some time on it). > > Really great idea indeed - I will make a try. > > Regards, > > Alain > > Le 05/10/2014 23:04, Sebastian Sastre a Ã©crit : >> Hi guys, >> >> Iâm sharing slides of my presentation at CampSmalltalkVI2014 >> http://www.slideshare.net/sebastianconcept/flow-39897704 >> >> >> From flowâs readme at github <https://github.com/flow-stack/flow>: >> >> Flow's mission is to provide /consultants/, /startups/ and /software >> houses/ with *a competitive Smalltalk full-stack framework* that allows >> them to quickly deliver a demo with all the modern html5 features the >> market expects today (2014). The idea is that they can tactically use >> this framework to keep momentum up among their prospects and clients and >> scale things to full successful projects delivered by kickass productive >> teams or individuals. >> >> sebastian <https://about.me/sebastianconcept> >> >> o/ >> >> blog: http://sebastianconcept.com <http://sebastianconcept.com/> >> LinkedIn: http://www.linkedin.com/in/sebastiansastre >> github: https://github.com/sebastianconcept >> >> >> >> >> > > >

Oct. 7, 2014

Re: [Pharo-dev] [ANN] flow: a living full-stack #âframework for the web

by Sebastian Sastre

youâre probably running on linux and I didnât implement it the start scripts there yet please take a look at the windows ones since they are bash based There is no mystery, they just start one thing in each terminal: mongo amber grunt watch and pharo if you do it manually youâll be fine you also need to work with pretty domains and I donât know how to setup them on linux but shouldnât be too different from this guide: http://zaiste.net/2013/03/serving_apps_locally_with_nginx_and_pretty_domain… once you have $ ping flow.dev responding from your localhost, you can try setting up nginx also, be sure you meet all requirements! https://github.com/sebastianconcept/flow/wiki/flow-requirements On Oct 6, 2014, at 3:00 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > ./startAll first gave an permission denied error , changed to the .hood/platform/linux folder to give permissions.. > > then it gave "Not implemented yet" > > realize the startAll has just that echo..!. > > lead me on a bit more..

Oct. 7, 2014

Re: [Pharo-dev] [ANN] flow: a living full-stack #âframework for the web

by Sebastian Sastre

please do! that will help a lot! Indeed there is a lot to catch up, the web is a universe We have parts of the audience that never touched javascript and weâre trying to make them heros on fullstack in half hour :D On Oct 6, 2014, at 2:43 AM, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > > The links has the step by step. I am running it as I type.. > > * For newbies on linux a mention of dependencies viz installing git / curl/ npm , node.js and bower and any others reqd would be great.. > > Anyways will post my attempt note in a few min.. > > > > On Mon, Oct 6, 2014 at 11:06 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Great ! > > Wasn't there a step by step tutorial somewhere ? > > On 05 Oct 2014, at 23:04, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > > > Hi guys, > > > > Iâm sharing slides of my presentation at CampSmalltalkVI2014 > > http://www.slideshare.net/sebastianconcept/flow-39897704 > > > > > > From flowâs readme at github: > > > > Flow's mission is to provide consultants, startups and software houses with a competitive Smalltalk full-stack framework that allows them to quickly deliver a demo with all the modern html5 features the market expects today (2014). The idea is that they can tactically use this framework to keep momentum up among their prospects and clients and scale things to full successful projects delivered by kickass productive teams or individuals. > > > > sebastian > > > > o/ > > > > blog: http://sebastianconcept.com > > LinkedIn: http://www.linkedin.com/in/sebastiansastre > > github: https://github.com/sebastianconcept > > > > > > > > > > > > >

Oct. 7, 2014