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

SmallLintRule RBGuardingClauseRule and RBGuardClauseRule

by Nicolai Hess

We have to similar rules RBGuardClauseRule and RBGuardingClauseRule One is a ParseTreeLintRule, the other one is a TransformationRule. I don't know why we have to at all. One rule was "disabled" (or not chown) in the CriticsBrowser because it was removed from the set of all rules before opening CriticsBrowser (see method #allGoodRules). In the past, monty fixed the class comment and #rational for class RBGuardClauseRule to correctly explain what this rule is about. This of course now differes from the similar rule RBGuardingClauseRule. 1. Why do we have both (ok, on can only select the rule violation, whereas the other on does not select it but shows the possible transformation 2. why is the second one now in the set of all rules used by CriticsBrowser 3. what to do ? Remove one, fix the comment and #rational for the second one? nicolai

Sept. 5, 2016

Re: [Pharo-dev] Bizarre Text Selection in Pharo 5.0

by Nicolai Hess

2016-09-04 19:54 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Max Leske wrote > > Please open a new issue (you can add me to the notification list). > > Done. Sorry for the delay. > https://pharo.fogbugz.com/f/cases/19036/Bizarre-Text- > Selection-in-Pharo-5-0 Can you add the platform information. I can not reproduce this on windows And does this happens only for $[ or for the other smart characters as well? > > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Bizarre- > Text-Selection-in-Pharo-5-0-tp4908498p4914071.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Sept. 5, 2016

Re: [Pharo-dev] about package naming

by stepharo

Guille do you know if iceberg has the same problem? I do not remember what nicolas mentionned about if MC entities were kept around and used. Stef

Sept. 5, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] e64121: 60202

by stepharo

Sean this is like that since years. Stef Le 4/9/16 Ã 20:06, Sean P. DeNigris a Ã©crit : > GitHub wrote >> 19001 Another pass to introduce iconNamed: and avoid Smalltalk ui icons >> https://pharo.fogbugz.com/f/cases/19001 > This one surprised me. I thought we were trying to avoid extensions to > low-level classes when possible. How is icon retrieval a responsibility of > ClassDescription?! I'm all about convenience, but not getting this change. > Was there a discussion somewhere? What benefits am I missing? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/pharo-project-pharo-core-e64121-60202-tp4914016p49140… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Sept. 5, 2016

Re: [Pharo-dev] about package naming

by stepharo

No guillermo. This is really annoying. With long package list like Collections* then you do not see well the tests. So we should check the bug like that we are free. > Je suis pas de place que no necesita activar gustamucho la ð¶ que ya > el otro lado > > > Le 4 sept. 2016 10:18, "stepharo" <stepharo(a)free.fr > <mailto:stepharo@free.fr>> a Ã©crit : > > Hi guys > > Sorry to be that dull and stupid but I do not get why (beside > following the seaside convention - and I do not understand it > either) why the test package for FileSystem-Core is named > FileSystem-Tests-Core > > and not just > > FileSystem-Core-Tests > > like that we could have > > FileSystem-Core-Help > > FileSystem-Core-Examples > > And when we are looking for FileSystem-Core we can see > automatically FileSystem-Core-Tests > > Now we cannot. > > Stef > >

Sept. 5, 2016

Re: [Pharo-dev] about package naming

by stepharo

Le 4/9/16 Ã 21:15, Cyril Ferlicot D. a Ã©crit : > Le 04/09/2016 Ã 20:52, Tudor Girba a Ã©crit : >> Hi, >> >> That naming convention is due to the fact that there was a time when Monticello committed the content of packages based on prefix matching. >> >> So, if you had: >> FileSystem-Core >> FileSystem-Core-Tests >> committing FileSyste-Core would also commit FileSystem-Core-Tests as a subcategory. >> >> Actually, we still have the bug that if you would change something in FileSystem-Core, FileSystem-Core-Tests would be marked as dirty. >> > Exactly! > > At Synectique we had to rename a lot of packages because this bug was > really annoying to know what to commit. > > We opened an issue: > https://pharo.fogbugz.com/f/cases/18712/Monticello-have-strange-behavior-if… You should mention it on the mailing list when you open a bug and this one is important. > >> Still, it would be much better to have naming of a package reflect a categorization. So, FileSystem-Core-Tests would be much more preferable. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "If you can't say why something is relevant, >> it probably isn't." >> >> >

Sept. 5, 2016

Re: [Pharo-dev] streamlining creation of gtInspector extensions

by Ben Coman

On Mon, Sep 5, 2016 at 3:24 AM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On Sun, Sep 04, 2016 at 11:10:26AM -0700, Sean P. DeNigris wrote: >> Ben Coman wrote > > Do you really want to add extra hidden > (because nobody would click on a tab, because nowhere else in the system it's like that) Its not hidden because its similar to lot of other systems that newcomers use [1][2][3]. > buttons just to save two seconds? > >> > * Show Definition - which opens a browser on the right code > > * click on the pen near top right corner, select extensions package, select method "Which extensions package, which method do I select? I've only been using Pharo a week. I'm not used to this extreme integration of IDE and my application code. You mean I can actually modify the UI code right now?" > * select the meta tab, select a class, select extensions package, select method > > Do you really need a special hidden button to maybe save two seconds on a five second action that you rarely perform? Its exactly the rare actions that benefit the most from better discoverability (see below). Its not about saving a few seconds. > >> > * Create Custom Extension - which opens a dialog to create a new >> > package "MyGTExtensions" and/or select an existing package, specify an >> > identifier and choose a template that is created and Browser opened. > > Why not just open a browser and add a method? You can protocolize the method with two clicks or a shortcut, and it's already part of the system. "How do I determine the right class to add the method? I've only been using Pharo a week and I'm not used to extending core classes. What is a protocol and what is an extension?" > > Unless you plan on writing two hundred extensions, you are really not going to save anything, because you spend most of the time actually implementing it and not bootstrapping it. (At least that's my experience after writing 20 or 30 extensions). The advantage is not for someone writing 20 or 200 extensions. Its for the person creating their very *first* extension. > > Another tip that I tend to use: > * open spotter, type #gtInsp, press ctrl + m (to select implementors), enable live preview (if you haven't already), look around for inspiration Considering a newcomer's discoverability of: * a common paradigm such as a tab context menu [1] [2] [3] + a dialog * guessing a random string like #gtInsp to search on + having the idea to create a personal MyGTExtensions package to hold the extension + knowing how to derive the name of the *MyGTExtensions protocol I feel the former will work better. > > > (just to be clear... I am not strictly against adding it, but it feels like it add another hidden feature (that's undiscoverable) for very little benefit) Maybe the <Pen> button could be a menu with * Browse definition of selected tab * Create a new tab The icon could be the three horizontal line "menu" icon rather than a "pen". [1] http://stackoverflow.com/questions/12986625/eclipse-plugin-development-addi… [2] http://www.howtogeek.com/howto/internet/firefox/quick-tip-duplicate-current… [3] http://techdows.com/2012/02/reload-all-tabs-in-chrome-from-context-menu-or-… cheers-ben

Sept. 5, 2016

Re: [Pharo-dev] Error When Accepting Changes in Debugger (Moose 6 on Pharo 5)

by Sean P. DeNigris

Andrei Chis wrote > Do you have a way to reproduce it? Not sure. I'll report back if it happens again;;; ----- Cheers, Sean -- View this message in context: http://forum.world.st/Error-When-Accepting-Changes-in-Debugger-Moose-6-on-P… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 4, 2016

Re: [Pharo-dev] Error When Accepting Changes in Debugger (Moose 6 on Pharo 5)

by Andrei Chis

Doesn't look familiar. Do you have a way to reproduce it? Cheers, Andrei On Sun, Sep 4, 2016 at 11:16 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > MessageNotUnderstood: Context>>messageName > > Is this a known bug? Should I open an issue? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Error- > When-Accepting-Changes-in-Debugger-Moose-6-on-Pharo-5-tp4914109.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Sept. 4, 2016

Error When Accepting Changes in Debugger (Moose 6 on Pharo 5)

by Sean P. DeNigris

MessageNotUnderstood: Context>>messageName Is this a known bug? Should I open an issue? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Error-When-Accepting-Changes-in-Debugger-Moose-6-on-P… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 4, 2016