- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Should we always put application file paths into FileLocator?

by Denis Kudriashov

2017-10-03 15:52 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Sure, but then why FileLocator? > Because I do not want to browse all code of Epicea (for example) to find where the files are placed. Maybe we can build tool for this. But with FileLocator I will find it immediately. > You could have in your app a normal class for that... I see you're > creating a dependency for no real value, or even just polluting FileLocator > for polluting it... I mean, to me the real value of FileLocator is to give > you the cross-platform feature. > > > On Tue, Oct 3, 2017 at 3:41 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> >> 2017-10-03 15:22 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> >>> >>> On Tue, Oct 3, 2017 at 3:18 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> >>>> >>>> 2017-10-03 13:54 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com> >>>> : >>>> >>>>> Could you write a blog post? :D >>>>> >>>>> - What is the good practice >>>>> - extending FileLocator >>>>> - managing paths in a platform independent way (what to extend for >>>>> unix, mac, windows, default values for unknown platforms...) >>>>> >>>> >>>> I am not sure about last point. I thought it is solved by FileSystem >>>> itself. >>>> >>> >>> Nope, check FileLocator. FileLocator was actually designed for that, not >>> to be a "place holder" for paths. >>> >> >> I know. But I am talking only about "place holder" parts. >> If my app wants myApp.config in image directory I would put it in >> FileLocator like this: >> >> FileLocator class>>myAppConfig >> >> "method in my app package" >> >> ^self imageDirectory / 'myApp.config' >> >> >> Nothing complex and intelligent here. >> >> >>> >>>> >>>> >>>>> >>>>> On Tue, Oct 3, 2017 at 12:52 PM, Denis Kudriashov < >>>>> dionisiydk(a)gmail.com> wrote: >>>>> >>>>>> Ok. No objections yet. >>>>>> I will prepare pull requests >>>>>> >>>>>> 2017-10-03 12:04 GMT+02:00 Guillermo Polito < >>>>>> guillermopolito(a)gmail.com>: >>>>>> >>>>>>> Yes yes yes >>>>>>> >>>>>>> On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse < >>>>>>> stepharo.self(a)gmail.com> wrote: >>>>>>> >>>>>>>> Hi denis >>>>>>>> >>>>>>>> I like it!. >>>>>>>> >>>>>>>> Stef >>>>>>>> >>>>>>>> On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov < >>>>>>>> dionisiydk(a)gmail.com> wrote: >>>>>>>> > Hi. >>>>>>>> > >>>>>>>> > Many times I was trying to find "global" files of some packages >>>>>>>> in system. >>>>>>>> > >>>>>>>> > For example do you know how to find epicea session logs? >>>>>>>> > There is class side method for this at EpMonitor: >>>>>>>> > >>>>>>>> > EpMonitor logsDirectory >>>>>>>> > >>>>>>>> > Is it easy to find when you never look at it? No. >>>>>>>> > >>>>>>>> > Do you know how to find sources file? There is message in >>>>>>>> Smalltalk global: >>>>>>>> > >>>>>>>> > Smalltalk sourcesFile >>>>>>>> > >>>>>>>> > Is it easy to find? No. >>>>>>>> > >>>>>>>> > And there are many other examples. >>>>>>>> > >>>>>>>> > But if you read about FileSystem library. You know the common >>>>>>>> place where to >>>>>>>> > find well known files. It is FileLocator. >>>>>>>> > For example changes file is here: >>>>>>>> > >>>>>>>> > FileLocator changes. >>>>>>>> > >>>>>>>> > So my idea is to introduce kind of pattern, the good style, how >>>>>>>> to access >>>>>>>> > global application files: they should be in FileLocator as >>>>>>>> extensions. >>>>>>>> > Then it would be super easy to find files of any applications. >>>>>>>> > >>>>>>>> > What do you think? >>>>>>>> > >>>>>>>> > If it is good idea then we should fix current places in system to >>>>>>>> follow >>>>>>>> > this pattern. >>>>>>>> > >>>>>>>> > Best regards, >>>>>>>> > Denis >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> >>>>>>> Guille Polito >>>>>>> >>>>>>> Research Engineer >>>>>>> >>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>>> >>>>>>> CRIStAL - UMR 9189 >>>>>>> >>>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>>> <http://www.cnrs.fr>* >>>>>>> >>>>>>> >>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>>> >>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> Guille Polito >>>>> >>>>> Research Engineer >>>>> >>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>> >>>>> CRIStAL - UMR 9189 >>>>> >>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>> <http://www.cnrs.fr>* >>>>> >>>>> >>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>> >>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>> >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Oct. 3, 2017

Re: [Pharo-dev] Should we always put application file paths into FileLocator?

by Henrik Sperre Johansen

Guillermo Polito wrote > But the packaging is not an issue. I think Denis proposed to put such > methods as extension methods. So they will belong to the correct package. > Isn't it? The obvious counter example can be had by browsing Object. Are the methods properly packaged? Yes. (As were Settings) Is it likely to cause problems due to missing dependencies? No. Is it a good OO pattern that should be should encouraged widespread use of? IMHO, no, not if there are other options. (Separations of concern, and all that) (AFAICT, the role of FileLocator, is to resolve symbolic path elements at runtime, not be a dictionary of all paths used by the base system/packages. For that, I'd inspect Path allSubinstances + some source string searches if I needed to find where they were defined.). Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 3, 2017

Re: [Pharo-dev] Should we always put application file paths into FileLocator?

by Guillermo Polito

Sure, but then why FileLocator? You could have in your app a normal class for that... I see you're creating a dependency for no real value, or even just polluting FileLocator for polluting it... I mean, to me the real value of FileLocator is to give you the cross-platform feature. On Tue, Oct 3, 2017 at 3:41 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2017-10-03 15:22 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> >> >> On Tue, Oct 3, 2017 at 3:18 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> >>> 2017-10-03 13:54 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>>> Could you write a blog post? :D >>>> >>>> - What is the good practice >>>> - extending FileLocator >>>> - managing paths in a platform independent way (what to extend for >>>> unix, mac, windows, default values for unknown platforms...) >>>> >>> >>> I am not sure about last point. I thought it is solved by FileSystem >>> itself. >>> >> >> Nope, check FileLocator. FileLocator was actually designed for that, not >> to be a "place holder" for paths. >> > > I know. But I am talking only about "place holder" parts. > If my app wants myApp.config in image directory I would put it in > FileLocator like this: > > FileLocator class>>myAppConfig > > "method in my app package" > > ^self imageDirectory / 'myApp.config' > > > Nothing complex and intelligent here. > > >> >>> >>> >>>> >>>> On Tue, Oct 3, 2017 at 12:52 PM, Denis Kudriashov <dionisiydk(a)gmail.com >>>> > wrote: >>>> >>>>> Ok. No objections yet. >>>>> I will prepare pull requests >>>>> >>>>> 2017-10-03 12:04 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com >>>>> >: >>>>> >>>>>> Yes yes yes >>>>>> >>>>>> On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse < >>>>>> stepharo.self(a)gmail.com> wrote: >>>>>> >>>>>>> Hi denis >>>>>>> >>>>>>> I like it!. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov < >>>>>>> dionisiydk(a)gmail.com> wrote: >>>>>>> > Hi. >>>>>>> > >>>>>>> > Many times I was trying to find "global" files of some packages in >>>>>>> system. >>>>>>> > >>>>>>> > For example do you know how to find epicea session logs? >>>>>>> > There is class side method for this at EpMonitor: >>>>>>> > >>>>>>> > EpMonitor logsDirectory >>>>>>> > >>>>>>> > Is it easy to find when you never look at it? No. >>>>>>> > >>>>>>> > Do you know how to find sources file? There is message in >>>>>>> Smalltalk global: >>>>>>> > >>>>>>> > Smalltalk sourcesFile >>>>>>> > >>>>>>> > Is it easy to find? No. >>>>>>> > >>>>>>> > And there are many other examples. >>>>>>> > >>>>>>> > But if you read about FileSystem library. You know the common >>>>>>> place where to >>>>>>> > find well known files. It is FileLocator. >>>>>>> > For example changes file is here: >>>>>>> > >>>>>>> > FileLocator changes. >>>>>>> > >>>>>>> > So my idea is to introduce kind of pattern, the good style, how to >>>>>>> access >>>>>>> > global application files: they should be in FileLocator as >>>>>>> extensions. >>>>>>> > Then it would be super easy to find files of any applications. >>>>>>> > >>>>>>> > What do you think? >>>>>>> > >>>>>>> > If it is good idea then we should fix current places in system to >>>>>>> follow >>>>>>> > this pattern. >>>>>>> > >>>>>>> > Best regards, >>>>>>> > Denis >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>>> Guille Polito >>>>>> >>>>>> Research Engineer >>>>>> >>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>>> >>>>>> CRIStAL - UMR 9189 >>>>>> >>>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>>> <http://www.cnrs.fr>* >>>>>> >>>>>> >>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>>> >>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> >>>> CRIStAL - UMR 9189 >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>> <http://www.cnrs.fr>* >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 3, 2017

Re: [Pharo-dev] Should we always put application file paths into FileLocator?

by Denis Kudriashov

2017-10-03 15:22 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Tue, Oct 3, 2017 at 3:18 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> 2017-10-03 13:54 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> Could you write a blog post? :D >>> >>> - What is the good practice >>> - extending FileLocator >>> - managing paths in a platform independent way (what to extend for unix, >>> mac, windows, default values for unknown platforms...) >>> >> >> I am not sure about last point. I thought it is solved by FileSystem >> itself. >> > > Nope, check FileLocator. FileLocator was actually designed for that, not > to be a "place holder" for paths. > I know. But I am talking only about "place holder" parts. If my app wants myApp.config in image directory I would put it in FileLocator like this: FileLocator class>>myAppConfig "method in my app package" ^self imageDirectory / 'myApp.config' Nothing complex and intelligent here. > >> >> >>> >>> On Tue, Oct 3, 2017 at 12:52 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> >>>> Ok. No objections yet. >>>> I will prepare pull requests >>>> >>>> 2017-10-03 12:04 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com> >>>> : >>>> >>>>> Yes yes yes >>>>> >>>>> On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse < >>>>> stepharo.self(a)gmail.com> wrote: >>>>> >>>>>> Hi denis >>>>>> >>>>>> I like it!. >>>>>> >>>>>> Stef >>>>>> >>>>>> On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov < >>>>>> dionisiydk(a)gmail.com> wrote: >>>>>> > Hi. >>>>>> > >>>>>> > Many times I was trying to find "global" files of some packages in >>>>>> system. >>>>>> > >>>>>> > For example do you know how to find epicea session logs? >>>>>> > There is class side method for this at EpMonitor: >>>>>> > >>>>>> > EpMonitor logsDirectory >>>>>> > >>>>>> > Is it easy to find when you never look at it? No. >>>>>> > >>>>>> > Do you know how to find sources file? There is message in Smalltalk >>>>>> global: >>>>>> > >>>>>> > Smalltalk sourcesFile >>>>>> > >>>>>> > Is it easy to find? No. >>>>>> > >>>>>> > And there are many other examples. >>>>>> > >>>>>> > But if you read about FileSystem library. You know the common place >>>>>> where to >>>>>> > find well known files. It is FileLocator. >>>>>> > For example changes file is here: >>>>>> > >>>>>> > FileLocator changes. >>>>>> > >>>>>> > So my idea is to introduce kind of pattern, the good style, how to >>>>>> access >>>>>> > global application files: they should be in FileLocator as >>>>>> extensions. >>>>>> > Then it would be super easy to find files of any applications. >>>>>> > >>>>>> > What do you think? >>>>>> > >>>>>> > If it is good idea then we should fix current places in system to >>>>>> follow >>>>>> > this pattern. >>>>>> > >>>>>> > Best regards, >>>>>> > Denis >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> Guille Polito >>>>> >>>>> Research Engineer >>>>> >>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>> >>>>> CRIStAL - UMR 9189 >>>>> >>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>> <http://www.cnrs.fr>* >>>>> >>>>> >>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>> >>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>> >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Oct. 3, 2017

Iceberg - viewing uncommitted changes

by Ben Coman

When the Iceberg [Packages] tab shows "Uncommitted changes", how do you view what those changes are? For example... $ curl get.pharo.org/70+vm | bash $ ./pharo-ui * Open System > Settings > Include system repositories by default = enabled * Open Tools > Iceberg > "pharo" * Click <Clone> button > enter "git@github.com:pharo-project/pharo.git" * Close and reopen Iceberg so the four tabs show * Select [Packages] tab and sort by "Name" so dirty packages are at top (btw, GT-Spotter and Reflectivity packages are dirty, but ignore that for now) * Open System Browser, randomly select AST-Core > NumberParser > allowPlusSign * Change the comment, save, enter author details. * Not sure how to refresh [Packages] tab, so close and reopen Iceberg and select [Packages] tab, sorted by "Name" ==> "AST_Core" shows "Uncomitted changes" So from here, how can I view what the uncommitted changes of that package are? I partly expect it in the context menu of AST_Core package. cheers -ben P.S. Currently, when I open Iceberg I'm habitually first selecting the [Packages] and [Branches] tabs. If I first select [Remotes] & "origin" followed by... * [Packages] ==> Instance of IceScpRemote did not understand #entity * [Branches] ==> Instance of IceScpRemote did not understand #isBranchModel

Oct. 3, 2017

Re: [Pharo-dev] [Ann] Class meta annotations

by Denis Kudriashov

2017-10-03 14:38 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Denis Kudriashov wrote > > I also realized that this library automatically adds annotations to > > packages because we are now able annotate manifest classes > > This all sounds very cool, but would you mind explaining the motivation a > bit? For example, isn't a manifest class itself meta-information about a > package? What does this new feature enable us to do for/with classes and > packages that we couldn't do before? Thanks! > I thought I explained it in my blog <http://dionisiydk.blogspot.fr/2017/09/class-meta-annotations.html>. But I know that I am a bad writer. For Commander examples look at github https://github.com/dionisiydk/Commander/tree/dev. It's still draft and not full. About packages It was just an idea. Yes, Manifest is a meta information itself. But you are not able to extend it from different packages like class extensions. I don't know where it can be needed. But with class annotation approach you can do it. Actually it is the main feature required for Commander: UI packages extend commands from domain packages with information how to access and execute them from UI. It makes commands reusable. > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Oct. 3, 2017

Re: [Pharo-dev] Should we always put application file paths into FileLocator?

by Guillermo Polito

On Tue, Oct 3, 2017 at 3:18 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2017-10-03 13:54 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Could you write a blog post? :D >> >> - What is the good practice >> - extending FileLocator >> - managing paths in a platform independent way (what to extend for unix, >> mac, windows, default values for unknown platforms...) >> > > I am not sure about last point. I thought it is solved by FileSystem > itself. > Nope, check FileLocator. FileLocator was actually designed for that, not to be a "place holder" for paths. > > >> >> On Tue, Oct 3, 2017 at 12:52 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> Ok. No objections yet. >>> I will prepare pull requests >>> >>> 2017-10-03 12:04 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>>> Yes yes yes >>>> >>>> On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse < >>>> stepharo.self(a)gmail.com> wrote: >>>> >>>>> Hi denis >>>>> >>>>> I like it!. >>>>> >>>>> Stef >>>>> >>>>> On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov < >>>>> dionisiydk(a)gmail.com> wrote: >>>>> > Hi. >>>>> > >>>>> > Many times I was trying to find "global" files of some packages in >>>>> system. >>>>> > >>>>> > For example do you know how to find epicea session logs? >>>>> > There is class side method for this at EpMonitor: >>>>> > >>>>> > EpMonitor logsDirectory >>>>> > >>>>> > Is it easy to find when you never look at it? No. >>>>> > >>>>> > Do you know how to find sources file? There is message in Smalltalk >>>>> global: >>>>> > >>>>> > Smalltalk sourcesFile >>>>> > >>>>> > Is it easy to find? No. >>>>> > >>>>> > And there are many other examples. >>>>> > >>>>> > But if you read about FileSystem library. You know the common place >>>>> where to >>>>> > find well known files. It is FileLocator. >>>>> > For example changes file is here: >>>>> > >>>>> > FileLocator changes. >>>>> > >>>>> > So my idea is to introduce kind of pattern, the good style, how to >>>>> access >>>>> > global application files: they should be in FileLocator as >>>>> extensions. >>>>> > Then it would be super easy to find files of any applications. >>>>> > >>>>> > What do you think? >>>>> > >>>>> > If it is good idea then we should fix current places in system to >>>>> follow >>>>> > this pattern. >>>>> > >>>>> > Best regards, >>>>> > Denis >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> >>>> CRIStAL - UMR 9189 >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>> <http://www.cnrs.fr>* >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 3, 2017

Re: [Pharo-dev] Should we always put application file paths into FileLocator?

by Denis Kudriashov

2017-10-03 13:54 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Could you write a blog post? :D > > - What is the good practice > - extending FileLocator > - managing paths in a platform independent way (what to extend for unix, > mac, windows, default values for unknown platforms...) > I am not sure about last point. I thought it is solved by FileSystem itself. > > On Tue, Oct 3, 2017 at 12:52 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Ok. No objections yet. >> I will prepare pull requests >> >> 2017-10-03 12:04 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> Yes yes yes >>> >>> On Fri, Sep 29, 2017 at 3:58 PM, Stephane Ducasse < >>> stepharo.self(a)gmail.com> wrote: >>> >>>> Hi denis >>>> >>>> I like it!. >>>> >>>> Stef >>>> >>>> On Fri, Sep 29, 2017 at 10:31 AM, Denis Kudriashov < >>>> dionisiydk(a)gmail.com> wrote: >>>> > Hi. >>>> > >>>> > Many times I was trying to find "global" files of some packages in >>>> system. >>>> > >>>> > For example do you know how to find epicea session logs? >>>> > There is class side method for this at EpMonitor: >>>> > >>>> > EpMonitor logsDirectory >>>> > >>>> > Is it easy to find when you never look at it? No. >>>> > >>>> > Do you know how to find sources file? There is message in Smalltalk >>>> global: >>>> > >>>> > Smalltalk sourcesFile >>>> > >>>> > Is it easy to find? No. >>>> > >>>> > And there are many other examples. >>>> > >>>> > But if you read about FileSystem library. You know the common place >>>> where to >>>> > find well known files. It is FileLocator. >>>> > For example changes file is here: >>>> > >>>> > FileLocator changes. >>>> > >>>> > So my idea is to introduce kind of pattern, the good style, how to >>>> access >>>> > global application files: they should be in FileLocator as extensions. >>>> > Then it would be super easy to find files of any applications. >>>> > >>>> > What do you think? >>>> > >>>> > If it is good idea then we should fix current places in system to >>>> follow >>>> > this pattern. >>>> > >>>> > Best regards, >>>> > Denis >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>> >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Oct. 3, 2017

Re: [Pharo-dev] Should we always put application file paths into FileLocator?

by Denis Kudriashov

2017-10-03 15:13 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > But the packaging is not an issue. I think Denis proposed to put such > methods as extension methods. So they will belong to the correct package. > Isn't it? > Yes > > On Tue, Oct 3, 2017 at 3:08 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> Hi Henrik. >> >> 2017-10-03 14:04 GMT+02:00 Henrik Sperre Johansen < >> henrik.s.johansen(a)veloxit.no>: >> >>> -1 from me, for the same reasons we moved away from Framework Settings as >>> extension methods on a central "Settings" class. >>> >> >> I think the reason was not only this. >> In most cases settings affect class variables which provide default >> values for instances. So it is just suitable to define settings in same >> place where state is defined. >> Also it not breaks encapsulation. >> >> And in case of FileLocator it will not access anybody state. It is about >> constant file paths. >> >> >>> Keep "globals" related to a package local to the package where they are >>> used. >>> >> >> I just want practical solution. Now there are no tools to browse what >> files are used by applications. And simple convention could be good enough. >> >> >>> Cheers, >>> Henry >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.ht >>> ml >>> >>> >>> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Oct. 3, 2017

Re: [Pharo-dev] Should we always put application file paths into FileLocator?

by Guillermo Polito

But the packaging is not an issue. I think Denis proposed to put such methods as extension methods. So they will belong to the correct package. Isn't it? On Tue, Oct 3, 2017 at 3:08 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Henrik. > > 2017-10-03 14:04 GMT+02:00 Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no>: > >> -1 from me, for the same reasons we moved away from Framework Settings as >> extension methods on a central "Settings" class. >> > > I think the reason was not only this. > In most cases settings affect class variables which provide default values > for instances. So it is just suitable to define settings in same place > where state is defined. > Also it not breaks encapsulation. > > And in case of FileLocator it will not access anybody state. It is about > constant file paths. > > >> Keep "globals" related to a package local to the package where they are >> used. >> > > I just want practical solution. Now there are no tools to browse what > files are used by applications. And simple convention could be good enough. > > >> Cheers, >> Henry >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >> >> -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 3, 2017