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

Re: [Pharo-dev] [Pharo-users] [ann] gtdebugger in pharo 5.0

by Johan Fabry

It looks much better to me, yes. I would need to use it some time before I could give more detailed feedback. (And I canât really do that until the FFI is fixed, because all my development crashes the VM since I am using Roassal. So I am still on the last Pharo version before the VM switch.) One last thing is that I am not convinced on having the âproceedâ, âstep intoâ, âstep overâ et cetera buttons on the stack pane. To me they are more related to the source code pane, as you always see the results of pressing those buttons there, but on the stack not always, e.g. the âstep overâ actions. > On Jan 9, 2016, at 19:06, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Thanks. What do you think of the new solution? Is it sufficient? > > Doru > ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Jan. 10, 2016

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

by Max Leske

> On 10 Jan 2016, at 19:01, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Stack top is really usefull because it contains the result of last expression evaluation. > Since we took the habit of composing message sends without decomposing into temporary variables, it avoid selecting sub-expression and re-evaluating subparts, or entering into each message to gain finer understanding... > > For thisContext, I don't really see the interest, but maybe someone will find a use caseâ¦ thisContext is useful if you want to inspect the sender chain yourself e.g. when developing tools like the debugger *with* the debugger. Cheers, Max > > 2016-01-10 18:55 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > > I use both thisContext and stackTop regularly. thisContext maybe once a wee, stackTop probably multiple times a day. > > So explain to me how? > > Stef > >

Jan. 10, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50520 Home: https://github.com/pharo-project/pharo-core

Jan. 10, 2016

[pharo-project/pharo-core] 974630: 50520

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 974630dc178b6b59156dac23623fe2dc9f98446c https://github.com/pharo-project/pharo-core/commit/974630dc178b6b59156dac23… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-10 (Sun, 10 Jan 2016) Changed paths: A Morphic-Base.package/LayoutFrame.class/class/costly instance creation/fractions_.st A Morphic-Base.package/LayoutFrame.class/class/costly instance creation/fractions_offsets_.st A Morphic-Base.package/LayoutFrame.class/class/costly instance creation/offsets_.st R Morphic-Base.package/LayoutFrame.class/class/instance creation/fractions_.st R Morphic-Base.package/LayoutFrame.class/class/instance creation/fractions_offsets_.st R Morphic-Base.package/LayoutFrame.class/class/instance creation/offsets_.st M Morphic-Base.package/LayoutFrame.class/instance/accessing/bottomFraction.st A Morphic-Base.package/LayoutFrame.class/instance/comparing/=.st A Morphic-Base.package/LayoutFrame.class/instance/comparing/hash.st A Morphic-Tests.package/LayoutFrameTest.class/instance/tests - conversion/testIdentity.st M Morphic-Tests.package/PaginatedMorphTreeMorphTests.class/instance/tests/testPager.st M Morphic-Widgets-Tree.package/PaginatedMorphTreeModel.class/class/examples/example.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50519.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50520.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50519.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50520.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50520 17361 Better LayoutFrame class comments and class method comments are needed https://pharo.fogbugz.com/f/cases/17361 17363 (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) = LayoutFrame identity should be true and it is not. https://pharo.fogbugz.com/f/cases/17363 17364 PaginateMorph uses Wrong LayoutFrame API https://pharo.fogbugz.com/f/cases/17364 http://files.pharo.org/image/50/50520.zip

Jan. 10, 2016

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

by Nicolas Cellier

Stack top is really usefull because it contains the result of last expression evaluation. Since we took the habit of composing message sends without decomposing into temporary variables, it avoid selecting sub-expression and re-evaluating subparts, or entering into each message to gain finer understanding... For thisContext, I don't really see the interest, but maybe someone will find a use case... 2016-01-10 18:55 GMT+01:00 stepharo <stepharo(a)free.fr>: > > I use both thisContext and stackTop regularly. thisContext maybe once a >> wee, stackTop probably multiple times a day. >> >> So explain to me how? > > Stef > >

Jan. 10, 2016

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

by stepharo

> I use both thisContext and stackTop regularly. thisContext maybe once a wee, stackTop probably multiple times a day. > So explain to me how? Stef

Jan. 10, 2016

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

by stepharo

Le 10/1/16 10:26, HernÃ¡n Morales Durand a Ã©crit : > Hi Stef, > > Just to tell you that I don't understand the process (if any) where it > is decided a new tool to be the new default, how it is evaluated and > by whom. But I would love to. The pharo board decided that it was ok. But I never thought it would be the default one. Now I find this process obscure and I'm not part of the board so I do not care. Stef

Jan. 10, 2016

Re: [Pharo-dev] Understanding Spotter?

by Tudor Girba

Hi Stef, > On Jan 10, 2016, at 10:21 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi doru > > you see I make the effort to reply even if I get really frustrated with our tools. Thank you. First, let me say that I was not arguing at all. I was looking for solutions. The way I know to do it is to make explicit the reasonings that we already went through so that others can poke holes at it. I also wanted to say that the choice was not random, but maybe we can find a better choice. > I do not get why you cannot > - have a set of fixed most used queries and this will create a small vocabulary that can be extensible > and it can be mapped to what we do with shortcuts = reduce cognitive load > and then a full search when you do not know what you are searching. > This is not exclusive and it works for the two scenario. I understand the intention, but I do not understand how these fixed queries are any different than we have now. When you are on the top of Spotter, when you query, you get always the same processors being executed. At first you will not know their names, and you will scroll. And if you see them, you might remember them and reproduce afterwards. Itâs a discoverable learning process that you do not have to remember. The only part that is not discoverable is that # introduces a category search. Thinking loud, I just thought that we can make the label start with # like this (I committed this change): We also thought of having completion as soon as someone type #. So, you have a kind of a dropdown for the available categories, but we did not get to implement that one. This should solve the discoverability problem even more. What do you think about that? Regarding the shortcuts, we could associated such shortcuts with a processor, but I would first want to see if we cannot manage to produce a solution with the current set of options. > I was discussing with Luc and he made a fun but sad remark > "Since people do not understand well spotter they most of the time only use it to open a class. > And this is something that he already had before." > I briefly looked at the Youtube video of Chloupis and > So you can have a generic super cool tool, if people do not use it it defeats its purpose. Certainly. > You can be really happy because you go fast with it but you only. That is not really true :). > So making sure that the most used actions are really supported is important. Of course it is. For Senders we did not find a good solution yet that is reasonably fast and useful. Stefan and I are still literally working on this. I think we should be able to have a solution, but we have to see if it is reasonable enough. We will announce it once we have it working. But, really, this tool more than anything allows one to play with possibilities in a couple of lines of code. We want people to play (some did) and to get concrete feedback and possible solutions. I think we should not just say that we need something else before we actually play with it a bit more. > But more important the discoverability is important because there is not even a help. > Right now as a user I can only guess and often I close spotter and use my shortcuts. > As a user I see something that ask me about network (and I do not care) but nothing > that brings me to the next level. This is something we need to work on, but you know, time is limited for us, too. > Most of the time the user forgets the key combination (may be this will be solved with > the cool shortcut reminder we developed and is under review) All actions in spotter have a visible icon. All. And if you hover over it you get the command. And there are literally 5 such actions. What is missing in this regard from your point of view? Doru > Stef > > > > -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

Jan. 10, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by stepharo

Yes this is my point > >> On Jan 9, 2016, at 3:29 PM, Christophe Demarey >> <christophe.demarey(a)inria.fr >> <mailto:christophe.demarey@inria.fr>> wrote: >> >> Not yet tested but looks good. > > Thanks. > >> I just noticed it misses the "run to here" action. > > It does not miss it. It is in the context menu of the code (this > is where it logically belongs). > > > Argh, trying to change a "well known user interface" (SpecDebugger) > and arguing about > why the new interface (GTDebugger) is " more logical" is always risky :) > > Even so we (smalltalkers) have the best software environment (Pharo) > we are bound to our owns > habits. > And it is a question of "discoverability". If you only see 5 debugger > action icons, you > may not know that there is another one (hidden) inthe context menu. >

Jan. 10, 2016

How to get launcher launching Spur images?

by stepharo

Hi I changed the setting to be the following but I cannot get a spur image started on mac. Does anybody succeed? Stef

Jan. 10, 2016