- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Storing metadata along with .mcz packages

by Camillo Bruni

On 2013-05-29, at 10:45, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 29/05/13 06:53, stephane ducasse wrote: >> >> On May 29, 2013, at 2:01 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: >> >>> Hi there, >>> >>> I need to store a sort of a metadata along with the code >>> in the .mcz. The goal is that if such a package is loaded >>> by standard Pharo 2.0 (or 3.0) image, modified and then saved >>> back as a new version, these metadata will be somehow preserved. >>> >>> Is that at all possible? If so, how? >> >> Yes :) >> Now packages have manifest created lazily by the smalllint browser. >> We are starting to store smallint rule false positive there and soon per package license. > > Good, Where should I look to see it how to do it? It "just" stores classes with data in strings in methods...

May 29, 2013

Re: [Pharo-dev] SmalltalkHub browser ?

by Damien Cassou

On Wed, May 29, 2013 at 10:17 AM, laurent laffont <laurent.laffont(a)gmail.com> wrote: > Is there's an ongoing project for that ? If not, is there an API for > SmalltalkHub to get needed data ? the SmalltalkHub server-side is "just" a REST API. I'm not sure there is a documentation of this API, but looking at the source code is *very* easy: - download a SmalltalkHub image: https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/ - open the image - look at ShHandler, ShVersionsHandler, and all Sh*Handler - all the methods with a <get>, <delete>... pragma is a REST entry point. You can also, open the web console of your favorite web browser and look at the network messages. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 29, 2013

Re: [Pharo-dev] Storing metadata along with .mcz packages

by Jan Vrany

On 29/05/13 06:53, stephane ducasse wrote: > > On May 29, 2013, at 2:01 AM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> Hi there, >> >> I need to store a sort of a metadata along with the code >> in the .mcz. The goal is that if such a package is loaded >> by standard Pharo 2.0 (or 3.0) image, modified and then saved >> back as a new version, these metadata will be somehow preserved. >> >> Is that at all possible? If so, how? > > Yes :) > Now packages have manifest created lazily by the smalllint browser. > We are starting to store smallint rule false positive there and soon per package license. Good, Where should I look to see it how to do it? Jan > > >> >> Best, Jan >> > > >

May 29, 2013

Re: [Pharo-dev] Storing metadata along with .mcz packages

by Jan Vrany

On 29/05/13 06:50, Camillo Bruni wrote: > Hi Jan, > > I would say that you have to plug in to the MCVersionInfo and add > another field (most probably with a dict) keeping all the additional metadata. > > That means you would also have to adapt the MCMczReader and MCMczWriter to > take the additional data into account. > - MCMczReader >> #loadVersionInfo > - MczWriter >> #writeVersionInfo: > > I would suggest to store the metadata as fueled objects, that way you do not > have to write in the monticello serialized "lisp" format ;) > > Even with the additional "files" present in the zip/mcz these versions will > load without a problem in non-changed images. Yes, additional files are not of a problem while loading. Problem is that they are not preserved, so when I open the package in unmodified pharo and save it again, all extra files are gone. That's no-go for me :-) Jan > > On 2013-05-29, at 02:01, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > >> Hi there, >> >> I need to store a sort of a metadata along with the code >> in the .mcz. The goal is that if such a package is loaded >> by standard Pharo 2.0 (or 3.0) image, modified and then saved >> back as a new version, these metadata will be somehow preserved. >> >> Is that at all possible? If so, how? >> >> Best, Jan >> > > >

May 29, 2013

[update 3.0] #30173

by Marcus Denker

30173 ----- 10781 Proper initialization/cleanup of RecentMessageList https://pharo.fogbugz.com/f/cases/10781 10783 EyeInspector raise errors on misprinted objects https://pharo.fogbugz.com/f/cases/10783 7377 Where DateModel should open the calendar https://pharo.fogbugz.com/f/cases/7377 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.188… http://smalltalkhub.com/mc/Pharo/Pharo30/main/RecentSubmissions-MarcusDenke… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Inspector-MarcusDenker.3…

May 29, 2013

Re: [Pharo-dev] RPackage and overrides

by Marcus Denker

On May 29, 2013, at 9:17 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 29/05/2013 09:07, Marcus Denker a Ã©crit : >> >> On May 29, 2013, at 9:04 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> Le 28/05/2013 22:23, stephane ducasse a Ã©crit : >>>> >>>> >>>>> I have a question about RPackage and overrides. >>>>> >>>>> RPackage consider that an override method is an extension, right? >>>> >>>> for RPackage a package is a list of method definitions and class definition. >>>> There is no specific tagging for overriding methods that would magically reappear when >>>> their overriding method would be unloaded. >>> >>> Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. RPackage does not (and list -overrides as extensions, as for example in Keymapping). >>> >>>> I do not know if this answer your question. >>> >>> Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same. >>> >>> What do you think? Is it important to classify overrides as such, or just let them be extensions ? >> >> The thing is that overrides don't work. As soon as 2 packages override the same method ==> which one is it? > > Oh, yes :( > >> Therefore, overrides as a *concept* make no sense. And thus modeling them makes no sense. >> Nobody ever should do overrides, because it will just not work as soon as it is used a lot. > > So, what do we do ? > > - Don't model and don't track overrides, even if some packages are effectively using them. > The thing is that there are much more important things to fix in RPackageâ¦ I don't even have the mental capacity to think about it. So prefer this for now. Marcus > - Model overrides so that we can: > - Detect when a package is creating an override (a Lint rule?) > - Signal an error for an override of an override (upon loading, for example). > - Signal an error when updating a package changes an extension to an override.

May 29, 2013

SmalltalkHub browser ?

by laurent laffont

Hi, I would like a sort of dedicated metacello browser for SmalltalkHub that only shows my projects & watch projects on SmalltalkHub. So the scenario is: - open SmalltalkHub browser - first time enter login & password - voilÃ , all my projects can be downloaded & saved (no more add repository, add to package, .... bla bla bla). - select a project / package in the browser -> open in nautilus I ask that because I had to evaluate many projects of my students in different repositories & packages, tiring :) Is there's an ongoing project for that ? If not, is there an API for SmalltalkHub to get needed data ? Cheers, Laurent

May 29, 2013

Re: [Pharo-dev] RPackage and overrides

by Goubier Thierry

Le 29/05/2013 09:07, Marcus Denker a Ã©crit : > > On May 29, 2013, at 9:04 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> Le 28/05/2013 22:23, stephane ducasse a Ã©crit : >>> >>> >>>> I have a question about RPackage and overrides. >>>> >>>> RPackage consider that an override method is an extension, right? >>> >>> for RPackage a package is a list of method definitions and class definition. >>> There is no specific tagging for overriding methods that would magically reappear when >>> their overriding method would be unloaded. >> >> Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. RPackage does not (and list -overrides as extensions, as for example in Keymapping). >> >>> I do not know if this answer your question. >> >> Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same. >> >> What do you think? Is it important to classify overrides as such, or just let them be extensions ? > > The thing is that overrides don't work. As soon as 2 packages override the same method ==> which one is it? Oh, yes :( > Therefore, overrides as a *concept* make no sense. And thus modeling them makes no sense. > Nobody ever should do overrides, because it will just not work as soon as it is used a lot. So, what do we do ? - Don't model and don't track overrides, even if some packages are effectively using them. - Model overrides so that we can: - Detect when a package is creating an override (a Lint rule?) - Signal an error for an override of an override (upon loading, for example). - Signal an error when updating a package changes an extension to an override. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 29, 2013

Re: [Pharo-dev] RPackage and overrides

by Goubier Thierry

Le 28/05/2013 22:23, stephane ducasse a Ã©crit : > > >> I have a question about RPackage and overrides. >> >> RPackage consider that an override method is an extension, right? > > for RPackage a package is a list of method definitions and class definition. > There is no specific tagging for overriding methods that would magically reappear when > their overriding method would be unloaded. Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. RPackage does not (and list -overrides as extensions, as for example in Keymapping). > I do not know if this answer your question. Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same. What do you think? Is it important to classify overrides as such, or just let them be extensions ? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 29, 2013

Re: [Pharo-dev] RPackage and overrides

by Marcus Denker

On May 29, 2013, at 9:04 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 28/05/2013 22:23, stephane ducasse a Ã©crit : >> >> >>> I have a question about RPackage and overrides. >>> >>> RPackage consider that an override method is an extension, right? >> >> for RPackage a package is a list of method definitions and class definition. >> There is no specific tagging for overriding methods that would magically reappear when >> their overriding method would be unloaded. > > Ok. But in MC, a MethodDefinition has a way of telling if it is an override or not. RPackage does not (and list -overrides as extensions, as for example in Keymapping). > >> I do not know if this answer your question. > > Not sure :) I wondered if I should bother with overrides or let them as extensions, as RPackage seems to be considering them the same. > > What do you think? Is it important to classify overrides as such, or just let them be extensions ? The thing is that overrides don't work. As soon as 2 packages override the same method ==> which one is it? Therefore, overrides as a *concept* make no sense. And thus modeling them makes no sense. Nobody ever should do overrides, because it will just not work as soon as it is used a lot. Marcus

May 29, 2013