October 2017 - Pharo-dev - lists.pharo.org

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

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

by Denis Kudriashov

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 > > >

Oct. 3, 2017

Re: [Pharo-dev] Iceberg - loading baseline

by Esteban Lorenzano

> On 3 Oct 2017, at 14:30, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > You have projects A and B on git(hub). > A has a dependency on B (in its baseline of). > > With integration enabled, installing A will also clone B and add B to iceberg. otherwise it will still download and installâ¦ but following the older process. Esteban > > Peter > > On Tue, Oct 3, 2017 at 2:06 PM, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: > Peter UhnÃ¡k wrote > > Don't forget to enable Metacello integration in settings. > > What does this setting do? I have been plugging along without it and haven't > noticed any problemsâ¦ > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> > >

Oct. 3, 2017

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

by Sean P. DeNigris

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! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 3, 2017

Re: [Pharo-dev] Iceberg - loading baseline

by Peter UhnÃ¡k

You have projects A and B on git(hub). A has a dependency on B (in its baseline of). With integration enabled, installing A will also clone B and add B to iceberg. Peter On Tue, Oct 3, 2017 at 2:06 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Peter UhnÃ¡k wrote > > Don't forget to enable Metacello integration in settings. > > What does this setting do? I have been plugging along without it and > haven't > noticed any problemsâ¦ > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Oct. 3, 2017

[Pharo 7.0-dev] Build #167: 20073 string morph add emphasis method

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #167 was: SUCCESS. The Pull Request #322 was integrated: "20073 string morph add emphasis method" Pull request url: https://github.com/pharo-project/pharo/pull/322 Issue Url: https://pharo.fogbugz.com/f/cases/20073 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 3, 2017

Re: [Pharo-dev] Sista alternate bytecodes + Java Bytecode ?

by ClÃ©ment Bera

Hi, That question should be asked on vm-dev. Just a detail, multibytecode set support is prior to the Sista implementation, it was used for example in the context of Newspeak (Squeak and Newspeak bytecodes supported together). Sista uses that feature, which makes it look like new in the Pharo community since afaik no one used it before in the context of Pharo. Then yes it is feasible to have the VM process Java bytecode, but it's humongous work. On the top my head, we would need to support typed bytecodes for Numbers and exceptions at the bytecode level (which in itself is month of work, imagine raising an exception from Java/ST and catch it from the other runtime, with multiple ensure/try finally in between) Note that supporting the Java bytecode is far from enough to be able to run Java code (We also need core Java libraries support at least, including exceptions/stack reification model that should be able to interact with each other) You can have a look at Smalltalk/X where the VM can run Java, C and Smalltalk. Regards On Tue, Oct 3, 2017 at 1:57 PM, Ben Coman <btc(a)openinworld.com> wrote: > Just wondering about an exotic idea, with Sista facilitating alternate > bytecodes (btw, is that multiple bytecode sets within one Image?), how > feasible would it be to have the VM process Java bytecode? > > cheers -ben >

Oct. 3, 2017