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

Re: [Pharo-dev] about package naming

by Yuriy Tymchuk

> On 04 Sep 2016, at 20:52, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Actually, we still have the bug that if you would change something in FileSystem-Core, FileSystem-Core-Tests would be marked as dirty. I think that this happens because we pretend to have packages, but behind the scenes it is still based on the old smalltalk categoriesâ¦ Uko

Sept. 4, 2016

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

by Sean P. DeNigris

Peter Uhnak wrote > Well you learn it like a lot of other stuff in Pharoâ¦ by looking at code > examples, which in this case means the implementation itself. Agreed. The problem here and in other tools (as opposed to scripts) is how you get from the UI to the implementation. You're still assuming that the first-time extension writer knows how to get to the implementation, which seems unlikely to me. ----- Cheers, Sean -- View this message in context: http://forum.world.st/streamlining-creation-of-gtInspector-extensions-tp491… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 4, 2016

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

by Peter Uhnak

On Sun, Sep 04, 2016 at 12:30:29PM -0700, Sean P. DeNigris wrote: > Peter Uhnak wrote > > Do you really want to... just to save two seconds? > > Of course not! > > > Peter Uhnak wrote > > that's my experience after writing 20 or 30 extensions > > And there's the source of the misunderstanding. Notice the key word in the > original request was /discoverability/ i.e. for specifically for new people > who /haven't/ written 20 or 30 extensions, or even 1! Well you learn it like a lot of other stuff in Pharoâ¦ by looking at code examples, which in this case means the implementation itself. And from that perspective it's imho very neat, that you can already very quickly find what you know, as long as you are comfortable using Pharo. In any case, Andrei was doing some experiments during ESUG on people (me included) on writing inspector extensions, so he is looking into it. Peter

Sept. 4, 2016

Re: [Pharo-dev] about package naming

by Guillermo Polito

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> 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. 4, 2016

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

by Sean P. DeNigris

Peter Uhnak wrote > Do you really want to... just to save two seconds? Of course not! Peter Uhnak wrote > that's my experience after writing 20 or 30 extensions And there's the source of the misunderstanding. Notice the key word in the original request was /discoverability/ i.e. for specifically for new people who /haven't/ written 20 or 30 extensions, or even 1! You did suggest in your answer that you don't think it's very discoverable because it's still hidden, but it seems more discoverable than the current knowledge repositories - brains of experts, blog posts, and the help system - because it's much closer to hand. Maybe we should put a link to the help system there instead... ----- Cheers, Sean -- View this message in context: http://forum.world.st/streamlining-creation-of-gtInspector-extensions-tp491… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 4, 2016

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

by Peter Uhnak

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) 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 * 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? > > * 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. 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). 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 (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) Peter

Sept. 4, 2016

Re: [Pharo-dev] about package naming

by Cyril Ferlicot D.

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… > 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." > > -- Cyril Ferlicot http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Sept. 4, 2016

Iceberg Question

by Alexandre Bergel

Hi! I have a question regarding the window: Why if I want to retrieve the new versions, I need to press the button âFetch new versionsâ. I think I should do a pull ? But instead, i can do a load or a merge. A bit crypticâ¦ Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 4, 2016

Re: [Pharo-dev] Please review: FIleSystem displayString and printOn: to support better tweaking in playground and friends

by Tudor Girba

Hi, > On Sep 4, 2016, at 7:57 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > stepharo wrote >> I did a first cut for FIleSystem displayString and printOn: to support >> better tweaking in playground and friends > > IIUC #displayString, #storeString, et al. are well-known distinctions from > other platforms, correct? Are we following the convention? Just a note: We agreed that displayString is a bit too much tool specific to have only one generic selector. So, right now for GT we have gtDisplayString. Cheers, Doru > Also, not to digress, but I've often wondered why we restrict tool > representations to string and not text. Presumably, much more meaning could > be communicated via stylingâ¦ > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Please-review-FIleSystem-displayString-and-printOn-to… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."

Sept. 4, 2016

Bug with Iceberg

by Alexandre Bergel

Hi! I bumped into the following bug, which stems from the following method: -=-=-=-=-=-=-=-=-= IceSavedPackageVersion >> isAncestorOf: anotherVersion ^ self commit isAncestorOf: anotherVersion commit -=-=-=-=-=-=-=-=-= anotherVersion is nil I attached the log Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 4, 2016