- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Idea: User-Installed Nautilus Package Group

by Sean P. DeNigris

EstebanLM wrote > +1 I will not open an issue because I don't have time to work on it right now and suspect it will languish and be closed (not complaining), so I will add it way down on my personal todo list and I leave opening an issue to anyone actually willing to do the work. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Idea-User-Installed-Nautilus-Package-Group-tp4913942p… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 4, 2016

Re: [Pharo-dev] about package naming

by Yuriy Tymchuk

Hi, I like the FileSystem-Core-Tests more, because then we can also have FileSystem-Core-Rules and FileSystem-Core-Rules-Tests. But I think that the other way to think about this is that if you want to (un)load all the test from filesystem you just work with FileSystem-Tests and not do it individually for each submodule. However this is just my guess. Uko > On 04 Sep 2016, at 10:17, 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 > >

Sept. 4, 2016