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

Re: [Pharo-dev] Non-deterministic ombu errors

by Gabriel Cotelli

Yes, please backport the changes to Pharo 6.1 because the travis builds are failing a lot with this kind of errors when you have a project with non-ASCII characters. Probably it makes no sense to enable Epicea in the images used by SmalltalkCI. Is there some way to disable it? On Mon, Oct 2, 2017 at 10:18 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Martin > > if you publish a fix for 6.1 we will port it back because this is > important. > > Stef > > On Fri, Sep 29, 2017 at 3:55 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > Now I do not know the best way for you to get the new fixed version. It's > > too late to include it in P6.1, I guess, so... either add epicea into > > metacello configuration or wait until P7. > > > > > > > > On Fri, Sep 29, 2017 at 5:34 AM, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> > > wrote: > >> > >> I'm glad it has known reason then, thank you for looking into it, all I > >> was > >> able to find out was that it relates to non-ascii characters and that > >> build > >> on our production server fails because of that :) > >> > >> Jan > >> > >> > >> tinchodias wrote > >> > On Sun, Sep 24, 2017 at 5:49 AM, Sven Van Caekenberghe < > >> > >> > sven@ > >> > >> > > wrote: > >> > > >> >> > >> >> > On 23 Sep 2017, at 22:42, Jan BlizniÄenko < > >> > >> > bliznjan@.cvut > >> > >> > > wrote: > >> >> > > >> >> > Hello > >> >> > > >> >> > I am having very similar errors from time to time when manually > >> >> > loading > >> >> code > >> >> > into Pharo from filetree (gitfiletree), but only in one of my > >> >> > projects > >> >> which > >> >> > contains non-ASCII characters like ÄÅ¡ÄÅÅ¾Ã½Ã¡ÃÃ©Å¯ÃºÅ¥Ä. For the very same > >> >> reason > >> >> > (not able to find why sometimes the error is there and sometimes is > >> >> not), I > >> >> > did not report it yet, but it is quite annoying. Retrying loading > the > >> >> > package helps every time. > >> >> > >> >> I think was reported before. I believe Ombu somewhere takes an > >> >> arbitrary > >> >> chunk of bytes out of an UTF-8 encoded file (like the last 100 of > >> >> something > >> >> like that) and then starts reading that. With UTF-8, a variable > length > >> >> encoding, that can be dangerous because you could end up in the > middle > >> >> of > >> >> a > >> >> character, not between encoded character boundaries. This would also > >> >> explain the randomness, as it is highly dependent on the contents. > >> >> > >> >> ZnUTF8Encoder>>#backOnStream: can be used to make sure you are really > >> >> at > >> >> the start of an encoded character. > >> >> > >> > > >> > > >> > Hello > >> > > >> > This issue was reported as: > >> > > >> > > >> > https://pharo.fogbugz.com/f/cases/20112/Epicea-can-fail- > while-reading-non-ascii-blocks > >> > > >> > My apologies for the bug... I introduced that code as an i/o > >> > optimization > >> > but wasn't properly tested. > >> > > >> > Thnks Sven, but I finally used stream's #basicNext (as Henrik > suggested > >> > in > >> > fogbugz) which skips forward. > >> > > >> > > >> > Martin > >> > >> > >> > >> > >> > >> -- > >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > >> > > > >

Oct. 3, 2017

Re: [Pharo-dev] About a discord channel for the mooc?

by Guillermo Polito

I'm in On Tue, Sep 19, 2017 at 8:50 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Tx esteban I will advertise it. > > On Tue, Sep 19, 2017 at 11:31 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > >> On 18 Sep 2017, at 15:13, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> > >> Hi guys > >> > >> The students of the lectures at Prague and the forthcoming mooc will > >> be strongly > >> suggested to use discord. > >> So now how can we organise it? > >> How do we create a channel? > > > > I just created a channel #mooc > > > > Esteban > > > >> > >> Stef > >> > > > > > > -- 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] Iceberg - loading baseline

by Sean P. DeNigris

EstebanLM wrote > otherwise it will still download and installâ¦ but following the older > process. IOW the projects will not be aded to Iceberg? If the shared repo setting is enabled, will existing local clones be found and used? Does it matter if the baseline contains e.g. github:// vs filetree://? The latter would require finding the git root i.e. stripping any code subfolderâ¦ ----- Cheers, Sean -- Sent from: 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 thought I explained it in my blog... But I know that I am a bad writer. Ah, sorry I forgot to re-read the blog and was trying to refresh my understanding just based on this thread. I wouldn't say the post was poorly written, just seemed to assume a prior familiarity with the inherent value of class annotations. >From what I understand, what you're describing sounds very Magritte-like. What I don't understand is the difference between, for example: CmdCommand class>>#activators ^ self classAnnotations select: [ :each | each isKindOf: CmdCommandActivationStrategy ] and a <commandActivationStrategy> pragma which signifies a message returning an appropriate object. ----- 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 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