- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] about package naming

by Tudor Girba

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. 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 > On Sep 4, 2016, at 10:17 AM, stepharo <stepharo(a)free.fr> wrote: > > 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 > > -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

Sept. 4, 2016

OCCompilerASTPlugin

by Serge Stinckwich

I have one question about Opal Compiler. I would like do an AST transformation before using the compiler. If I understand correctly, I have to built a subclass of OCCompilerASTPlugin ? Is it correct ? Any documentation more update about Opal than this : https://github.com/SquareBracketAssociates/PharoLimbo/tree/master/Opal Thank you. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Sept. 4, 2016

Re: [Pharo-dev] GTInspector Inspecting a string should provide default interaction shortcut

by Tudor Girba

Hi, We already agreed several times that this is a bug :). I now created an issue to make sure we do not forget it: https://pharo.fogbugz.com/f/cases/19037/String-presentation-in-GTInspector-… Doru > On Sep 4, 2016, at 8:00 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > stepharo wrote >> when I inspect a string, the default shortcuts should be present. > > Yes! No modes!!! It is confusing and does not seem to fit the spirit of our > system. Who can predict where a user will want/need to evaluate? I often > perform doIts in the MC Browser windows, commit log dialogs, etc. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/GTInspector-Inspecting-a-string-should-provide-defaul… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > -- www.tudorgirba.com www.feenk.com "Value is always contextual."

Sept. 4, 2016

Can Sound depend on Jobs?

by Sean P. DeNigris

I wanted to add as an extension method to the Sound package: Job>>#beepAtEnd "Sound must first be enabled via `SoundSystem soundEnabled: true.`" self announcer when: JobEnd do: [ SoundSystem current beep ] I figured I'd get some feedback first since I know we're trying to reduce dependencies... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Can-Sound-depend-on-Jobs-tp4914083.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 4, 2016