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

Re: [Pharo-dev] PluggableButtonMorph does not respect font size :(

by Tudor Girba

Hi, > On Jan 14, 2016, at 11:19 AM, stepharo <stepharo(a)free.fr> wrote: > > For the Pharo Mooc we need to use large font and we end up with this visual glitch :( > I tried to dive into PluggableButtonMorph and I failed to found how to make sure it computes the bound correctly. > Any help is welcome. > I really think that in Brick we should really be picky on such problems. Indeed. Actually, Alex Syrel spent 2 weeks to get this âlittleâ thing of computing the bounds of a string right (I think it works well now hopefully) :). Doru > Stef > > > <djbhggee..png> -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Jan. 15, 2016

Re: [Pharo-dev] [Pharo-users] [ANN] OSSubprocess first milestone

by Mariano Martinez Peck

> > > Quick feedback: > > - the API seems great > - thank you very much for the documentation > Thanks! > - I wonder why you pass strings for stdout and stderr instead of streams > In which part exactly? In the method like #runAndWaitOnExitDo: ? if that was the question, then I simply thought it would be easier for the user to receive strings. In fact, internally I use streams, but just when I evaluate the closure I pass #contents. I think it's more common for users wanting a string than a stream. In either case, if they received a string they can do #readStreamDo:[] or whatever, and if they receive a stream they can do #contents. > - it would be nice to be able to subclass OSSUnixProcessExitStatus for > some commands. E.g., GitProcessExitStatus could have a method > isMergeConflict > That would be nice. > - how can I implement something like tail --follow > I think it would be nice to how an example of this type of streaming API. Note that this goes very similar to what Luc proposes below. Thanks for the feedback! -- Mariano http://marianopeck.wordpress.com

Jan. 15, 2016

Re: [Pharo-dev] How can we flush the remembered expressions of Playground?

by Tudor Girba

Hi, For manipulating the active bindings, you have a menu item on the top right: Doru > On Jan 15, 2016, at 12:09 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > For remembered expressions: Delete the folders play-cache and play-stash from the directory of the image and run 'GTPlayBook cleanUp' before opening the playground. > For the bindings: in the list of displayed binding each binding has an action that removes it from the list (It has an X icon) > > > Andrei > > On Fri, Jan 15, 2016 at 12:02 PM, stepharo <stepharo(a)free.fr> wrote: > Because when I turn videos I want to control the starting state of the system.... > Then how do I reset the binding list? > I could not find a menu entry. > I found the resetBindings but it is not simple to grab the correct object. > > > Stef > > -- www.tudorgirba.com www.feenk.com "It's not how it is, it is how we see it."

Jan. 15, 2016

Re: [Pharo-dev] spotter much slower (GTools 3.6)

by Nicolai Hess

2016-01-15 14:02 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > Oh, I got it. Your test does not test inside a class, but the top search. > > I now committed GT-SpotterExtensions-Core-TudorGirba.187 to only search > for exact references. Could you check? > Yes! Much better :) > > Before, searching for Morphs took 58s: > > > > Cheers, > Doru > > > On Jan 15, 2016, at 1:33 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Nice catch! > > I looked at it, and I cannot understand where the slowness comes from > because there is essentially no change in the processors of a Behavior. Now > I am intrigued. > > Please open an issue. > > Cheers, > Doru > > > > On Jan 15, 2016, at 10:32 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > since pharo 50524 spotter is much slower. > > Most probably related to search results from classes with many subclasses > Morph / Object / Error / Announcement. > > For example, search for Announcement > and dive into the result for the Announcement class. > It takes about ~ 10 seconds to build the result page (instance methods / > super instance methods....) > > Testcase > > GTSpotterStepTest>>timeClassTest:aClassName > [ self basicSearch:aClassName ] timeToRun logCr. > > "Pharo 50523" > timeClassTest:'Announcement' > 0:00:00:00.539 > timeClassTest:'Morph' > 0:00:00:01.448 > > "Pharo 50524" > timeClassTest:'Announcement' > 0:00:00:06.936 > timeClassTest:'Morph' > 0:00:00:49.044 > > Or open SUnit Testrunner and run tests for package: > GT-Tests-Spotter-Scripting > > nicolai > > > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "What we can governs what we wish." > > > > >

Jan. 15, 2016

Re: [Pharo-dev] spotter much slower (GTools 3.6)

by Tudor Girba

Hi, Oh, I got it. Your test does not test inside a class, but the top search. I now committed GT-SpotterExtensions-Core-TudorGirba.187 to only search for exact references. Could you check? Before, searching for Morphs took 58s: Now, searching for Morphs takes 1s: Cheers, Doru > On Jan 15, 2016, at 1:33 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Nice catch! > > I looked at it, and I cannot understand where the slowness comes from because there is essentially no change in the processors of a Behavior. Now I am intrigued. > > Please open an issue. > > Cheers, > Doru > > > >> On Jan 15, 2016, at 10:32 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> since pharo 50524 spotter is much slower. >> >> Most probably related to search results from classes with many subclasses >> Morph / Object / Error / Announcement. >> >> For example, search for Announcement >> and dive into the result for the Announcement class. >> It takes about ~ 10 seconds to build the result page (instance methods / super instance methods....) >> >> Testcase >> >> GTSpotterStepTest>>timeClassTest:aClassName >> [ self basicSearch:aClassName ] timeToRun logCr. >> >> "Pharo 50523" >> timeClassTest:'Announcement' >> 0:00:00:00.539 >> timeClassTest:'Morph' >> 0:00:00:01.448 >> >> "Pharo 50524" >> timeClassTest:'Announcement' >> 0:00:00:06.936 >> timeClassTest:'Morph' >> 0:00:00:49.044 >> >> Or open SUnit Testrunner and run tests for package: >> GT-Tests-Spotter-Scripting >> >> nicolai > > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > -- www.tudorgirba.com www.feenk.com "What we can governs what we wish."

Jan. 15, 2016

Re: [Pharo-dev] GTDebugger missing block parameters?

by Nicolai Hess

2016-01-15 13:26 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > When debugging a method containing a block with a parameter, > the parameter is missing from the variable list (because it is aliased?). > Yes, this happens with block vars from optimized blocks (ifNotNil:). The tempvars arent't local to the block, but method vars. And the debugger (debuggerMap) doesn't knows about this (this happens on both debuggers AFAIK). > > Stephan >

Jan. 15, 2016

Re: [Pharo-dev] spotter much slower (GTools 3.6)

by Mariano Martinez Peck

This is not the case but related: https://pharo.fogbugz.com/f/cases/17381/GTSpotter-hangs-image-with-slow-int… On Fri, Jan 15, 2016 at 9:33 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Nice catch! > > I looked at it, and I cannot understand where the slowness comes from > because there is essentially no change in the processors of a Behavior. Now > I am intrigued. > > Please open an issue. > > Cheers, > Doru > > > > > On Jan 15, 2016, at 10:32 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > > > > since pharo 50524 spotter is much slower. > > > > Most probably related to search results from classes with many subclasses > > Morph / Object / Error / Announcement. > > > > For example, search for Announcement > > and dive into the result for the Announcement class. > > It takes about ~ 10 seconds to build the result page (instance methods / > super instance methods....) > > > > Testcase > > > > GTSpotterStepTest>>timeClassTest:aClassName > > [ self basicSearch:aClassName ] timeToRun logCr. > > > > "Pharo 50523" > > timeClassTest:'Announcement' > > 0:00:00:00.539 > > timeClassTest:'Morph' > > 0:00:00:01.448 > > > > "Pharo 50524" > > timeClassTest:'Announcement' > > 0:00:00:06.936 > > timeClassTest:'Morph' > > 0:00:00:49.044 > > > > Or open SUnit Testrunner and run tests for package: > > GT-Tests-Spotter-Scripting > > > > nicolai > > -- > www.tudorgirba.com > www.feenk.com > > "Every successful trip needs a suitable vehicle." > > > > > > > -- Mariano http://marianopeck.wordpress.com

Jan. 15, 2016

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

by Tudor Girba

Hi, Thanks indeed for the feedback. I think not quite all are bugs, but see more details inside. > On Jan 14, 2016, at 12:59 PM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi Nicolai, > > Thanks for reporting these issues. They are indeed bugs and we are working on fixing them. > > Cheers, > Andrei > > On Tue, Jan 12, 2016 at 11:24 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-01-08 11:24 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. > > First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. > > A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. > > Accept and Cancel buttons shouldn't be there > or should not act on if the codepane hasn't changed. > (every press on "accept" writes a new method version, although the contents didn't changed - tested on > Latest update: #50524 ) Good catch. This will happen even if the button would not be present. > Most (all?) other tools don't have Accept/Cancel buttons. The logic is that these are actions that do not depend on the selection, so in Glamour we map these on actions that are applicable to the entire presentation. A similar approach is present in the inspector, although probably it does not appear so prominently because there is no text. We could try to add them in a dropdown menu. Would that help? > - I really miss the "List Methods using 'varname'/List Methods storing into âvarname' Please open an issue for this. > - is "stackTop" now gone ? I thought you wanted to add it to the stack ? > - thisContext is gone as well ? These were removed due to emergency mail exchange that happened during the last weekend. > - the Bytecode/GT button is badly placed, it looks like the "downarrow" window menu icon > is a dropdown menu with label âBytecode" We could try to fix by adding more space to the left of the menu bar in the theme. Could you open an issue? > (since when do we put buttons in the title pane? Since Glamour makes it easy to have them there :). The GTPlayground and GTInspector have them, too. > - the evaluator pane is shown as "dirty", as it does not make a difference if we > accept the text in this pane, there shouldn't be a dirty indicator. This is a problem that seems to exist with basically every pharoScript in Glamour. You commented on an issue for this: https://pharo.fogbugz.com/f/cases/16757/GLMHighlighterTextRubEditingMode-al… > - you can not use the inspector pane to change inst var values This is a problem but it is not specific to the debugger. > - there is no way to refresh the inspector pane Indeed. Would it be enough if we added a refresh for the whole debugger? Cheers, Doru > I don't open bugtracker entries now, I 'll wait maybe this issues aren't bugs but > features. > > > nicolai > > > > _______________________________________________ > 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 "Not knowing how to do something is not an argument for how it cannot be done."

Jan. 15, 2016

Re: [Pharo-dev] spotter much slower (GTools 3.6)

by Tudor Girba

Hi, Nice catch! I looked at it, and I cannot understand where the slowness comes from because there is essentially no change in the processors of a Behavior. Now I am intrigued. Please open an issue. Cheers, Doru > On Jan 15, 2016, at 10:32 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > since pharo 50524 spotter is much slower. > > Most probably related to search results from classes with many subclasses > Morph / Object / Error / Announcement. > > For example, search for Announcement > and dive into the result for the Announcement class. > It takes about ~ 10 seconds to build the result page (instance methods / super instance methods....) > > Testcase > > GTSpotterStepTest>>timeClassTest:aClassName > [ self basicSearch:aClassName ] timeToRun logCr. > > "Pharo 50523" > timeClassTest:'Announcement' > 0:00:00:00.539 > timeClassTest:'Morph' > 0:00:00:01.448 > > "Pharo 50524" > timeClassTest:'Announcement' > 0:00:00:06.936 > timeClassTest:'Morph' > 0:00:00:49.044 > > Or open SUnit Testrunner and run tests for package: > GT-Tests-Spotter-Scripting > > nicolai -- www.tudorgirba.com www.feenk.com "Every successful trip needs a suitable vehicle."

Jan. 15, 2016

Re: [Pharo-dev] Color yzw

by Nicolai Hess

No, you are right. It isn't shown in red, even if it is a unknown symbol. I'll have a look. 2016-01-15 13:28 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2016-01-15 13:10 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Hi >> >> In the past in Pharo when a message was not matching an existing selector >> the selector was turned into red >> > > I think this only happened for names not known as a symbol, regardless > whether this symbol exists as a message selector or just a symbol. > > If no symbol table includes the symbol yzw > > Color yzw > > will show yzw red, > > Color yello > will print yello in italic > Color yellow > will print yellow normal > Color jaune > will print jaune red, as long it is not in a SymbolTable. > > > >> So we could see immediately that you typed an error. >> >> Right now, the behavior only exists for Class >> so >> >> Po is italiczec >> Pox is red >> >> I played with the blueStyleTable but I cannot get it working on selector. >> Does anybody know? >> >> Such kind of glitch is slowing me when shooting new pharo videos. >> >> Stef >> >> >> >

Jan. 15, 2016