- Pharo-dev - lists.pharo.org

Re: [Pharo-project] RPackage does not update extension methods to removed classes

by Mariano Martinez Peck

grrrr and the same happens for methods that are removed....they are not removed from the RPackage :( On Sat, Aug 4, 2012 at 2:41 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > > > On Sat, Aug 4, 2012 at 2:34 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi Stef. I notice that RPackage does not update the extension methods of >> removed classes. It is easy to reproduce in Pharo 2.0 by doing: >> >> (RPackageOrganizer default packageNamed: 'FreeType') >> allDefinedExtensionMethods (this fails because FreeType used to have a >> extension method in TTCFont which was removed) >> >> Or step by step: >> >> 1) Create package PackageX. >> 2) Create package PackageY and ClassY. >> 3) Create in ClassY a extension method with category *PackageX. If you >> now browse the instVar "classExtensionSelectors" of PackageX you will see >> ClassY. >> 4) Remove ClassY >> 5) notice that 'classExtensionSelectors' from PackageX still references >> ClassY. In fact, if you ask its extension methods you will have a >> KeyNotFound #ClassY in Smalltalk globals ;) >> >> So...I guess this is a bug. If true, I open an issue. >> >> > and to fix the already existing ones we can do: > > | extensions | > RPackage allInstances do: [:aPackage | > extensions := (aPackage instVarNamed: 'classExtensionSelectors'). > extensions keysDo: [:aClassName | > (Smalltalk globals includesKey: aClassName) ifFalse: [extensions > removeKey: aClassName]. > ]. > extensions := (aPackage instVarNamed: 'metaclassExtensionSelectors'). > extensions keysDo: [:aClassName | > (Smalltalk globals includesKey: aClassName) ifFalse: [extensions > removeKey: aClassName]. > ]. > ] > > > >> Cheers, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Aug. 4, 2012

Re: [Pharo-project] 'self halt' safety net

by Mariano Martinez Peck

On Sat, Aug 4, 2012 at 3:44 PM, Fernando Olivero <fernando.olivero(a)usi.ch>wrote: > What about a Nautilus plugin, that allows browsing all the methods > that send #halt, #flag:,#log:? (the "development" messages). > > That's a great idea. In fact, I remember being sit at my desk in Douai and doing that with Guille.. Guille, do you remember? > Since finding all the halts, doesn't seem something that needs to be > performed all the time, an optional Nautilus plugin would suffice. > > > Fernando > > On Sat, Aug 4, 2012 at 3:02 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > > > > Mariano Martinez Peck wrote > >> > >>> Another thought, are there any plans for a "breakpoint" facility, so > that > >>> I don't dirty a package by only inserting 'self halt' to aid debugging. > >> it already exists. Right click on a method -> Add breakpoint > >> > > > > I, too would love to have the features you suggest. However, as it > stands, I > > would strongly advise against using breakpoints (someone definitely let > me > > know, maybe this is not still a problem in 2.0). In my experience, they > are > > incredibly buggy. Historically: > > * if you add a breakpoint in one tool, and try to disable it in another, > it > > may still be active; and who remembers what tool they enabled it in??? > > * there is very little feedback as to when a breakpoint is enabled > > - no icon in the browsers > > - the menu item was "toggle breakpoint" instead of dynamically "enable" > > vs. "disable" > > > > In all, I found it very confusing to figure out when a breakpoint was > > enabled, and how to disable. Of course, anyway, these are not > breakpoints as > > typically offered by an IDE, which can be attached to any statement, but > > only at the method level. > > > > Cheers, > > Sean > > > > > > > > -- > > View this message in context: > http://forum.world.st/self-halt-safety-net-tp4643012p4643070.html > > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 4, 2012

Re: [Pharo-project] LaTeX formula in Smalltalk

by Serge Stinckwich

I'm interested to render formulas from epidemiological models. EnvoyÃ© de mon iPad Le 4 aoÃ»t 2012 Ã 17:47, Hilaire Fernandes <hilaire.fernandes(a)edu.ge.ch> a Ã©crit : > Hello, > > Java has JLatex a self sufficient package to render latex formula. > > Is there any interest for a such think in Smalltalk? I guess most part > of it could be portable. > > Thanks > > Hilaire > >

Aug. 4, 2012

Re: [Pharo-project] 'self halt' safety net

by Fernando Olivero

What about a Nautilus plugin, that allows browsing all the methods that send #halt, #flag:,#log:? (the "development" messages). Since finding all the halts, doesn't seem something that needs to be performed all the time, an optional Nautilus plugin would suffice. Fernando On Sat, Aug 4, 2012 at 3:02 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Mariano Martinez Peck wrote >> >>> Another thought, are there any plans for a "breakpoint" facility, so that >>> I don't dirty a package by only inserting 'self halt' to aid debugging. >> it already exists. Right click on a method -> Add breakpoint >> > > I, too would love to have the features you suggest. However, as it stands, I > would strongly advise against using breakpoints (someone definitely let me > know, maybe this is not still a problem in 2.0). In my experience, they are > incredibly buggy. Historically: > * if you add a breakpoint in one tool, and try to disable it in another, it > may still be active; and who remembers what tool they enabled it in??? > * there is very little feedback as to when a breakpoint is enabled > - no icon in the browsers > - the menu item was "toggle breakpoint" instead of dynamically "enable" > vs. "disable" > > In all, I found it very confusing to figure out when a breakpoint was > enabled, and how to disable. Of course, anyway, these are not breakpoints as > typically offered by an IDE, which can be attached to any statement, but > only at the method level. > > Cheers, > Sean > > > > -- > View this message in context: http://forum.world.st/self-halt-safety-net-tp4643012p4643070.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 4, 2012

Re: [Pharo-project] 'self halt' safety net

by Sean P. DeNigris

Mariano Martinez Peck wrote > >> Another thought, are there any plans for a "breakpoint" facility, so that >> I don't dirty a package by only inserting 'self halt' to aid debugging. > it already exists. Right click on a method -> Add breakpoint > I, too would love to have the features you suggest. However, as it stands, I would strongly advise against using breakpoints (someone definitely let me know, maybe this is not still a problem in 2.0). In my experience, they are incredibly buggy. Historically: * if you add a breakpoint in one tool, and try to disable it in another, it may still be active; and who remembers what tool they enabled it in??? * there is very little feedback as to when a breakpoint is enabled - no icon in the browsers - the menu item was "toggle breakpoint" instead of dynamically "enable" vs. "disable" In all, I found it very confusing to figure out when a breakpoint was enabled, and how to disable. Of course, anyway, these are not breakpoints as typically offered by an IDE, which can be attached to any statement, but only at the method level. Cheers, Sean -- View this message in context: http://forum.world.st/self-halt-safety-net-tp4643012p4643070.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 4, 2012

Re: [Pharo-project] RPackage does not update extension methods to removed classes

by Mariano Martinez Peck

On Sat, Aug 4, 2012 at 2:34 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Hi Stef. I notice that RPackage does not update the extension methods of > removed classes. It is easy to reproduce in Pharo 2.0 by doing: > > (RPackageOrganizer default packageNamed: 'FreeType') > allDefinedExtensionMethods (this fails because FreeType used to have a > extension method in TTCFont which was removed) > > Or step by step: > > 1) Create package PackageX. > 2) Create package PackageY and ClassY. > 3) Create in ClassY a extension method with category *PackageX. If you now > browse the instVar "classExtensionSelectors" of PackageX you will see > ClassY. > 4) Remove ClassY > 5) notice that 'classExtensionSelectors' from PackageX still references > ClassY. In fact, if you ask its extension methods you will have a > KeyNotFound #ClassY in Smalltalk globals ;) > > So...I guess this is a bug. If true, I open an issue. > > and to fix the already existing ones we can do: | extensions | RPackage allInstances do: [:aPackage | extensions := (aPackage instVarNamed: 'classExtensionSelectors'). extensions keysDo: [:aClassName | (Smalltalk globals includesKey: aClassName) ifFalse: [extensions removeKey: aClassName]. ]. extensions := (aPackage instVarNamed: 'metaclassExtensionSelectors'). extensions keysDo: [:aClassName | (Smalltalk globals includesKey: aClassName) ifFalse: [extensions removeKey: aClassName]. ]. ] > Cheers, > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Aug. 4, 2012

[Pharo-project] RE : RE : Configuration Browser feedback

by GOUBIER Thierry

A naive proposition : Use a comment in the header of the mcz of the configuration (or whatever appropriate metadata about one of the file of the mcz) so that the description of the package (a configuration is a package, right?) can be retrieved without loading the zip in complete. In the same way when opening a package repository, you can get the last commit release ? Equivalent approaches could then be designed for other formats than the mcz. Thierry ________________________________________ De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm(a)gmail.com] Date d'envoi : samedi 4 aoÃ»t 2012 14:20 Ã : Pharo-project(a)lists.gforge.inria.fr Objet : Re: [Pharo-project] RE : Configuration Browser feedback Yes, that would be a good addition, but sadly is not so easy... if you have an idea of how to implement it, I would be happy to introduce it :) Cheers, Esteban On Aug 4, 2012, at 2:06 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > +100 on the configuration description ! > > Thierry > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Ben Coman [btc(a)openInWorld.com] > Date d'envoi : samedi 4 aoÃ»t 2012 13:14 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : [Pharo-project] Configuration Browser feedback > > Just thinking that the second tab of the Configuration Browser being > called "Untrusted" is a bit harsh and not really socially engaging. > "Community" has a better feel to me. > And perhaps not "Configurations" for the first tab either, since both > tabs are configurations. Perhaps "Core" or "Supported" or "Vetted" or > "Gold" or something similar. > > Also, what would be really fantastic would be some description of each > configuration being displayed in a pane on the right hand side. There > are A LOT of configurations listed there - which is great - but I don't > feel inclined to go looking up every single one to see if they interest > me. Sometimes what gets people interested in trying out new things is > that it just catches their eye in casual browsing. > > I guess a pre-requisite of that would be the ConfigurationOf file > containing such a description, as well as perhaps something on the back > end server that caches those descriptions into one file. > > cheers -ben > >

Aug. 4, 2012

[Pharo-project] RPackage does not update extension methods to removed classes

by Mariano Martinez Peck

Hi Stef. I notice that RPackage does not update the extension methods of removed classes. It is easy to reproduce in Pharo 2.0 by doing: (RPackageOrganizer default packageNamed: 'FreeType') allDefinedExtensionMethods (this fails because FreeType used to have a extension method in TTCFont which was removed) Or step by step: 1) Create package PackageX. 2) Create package PackageY and ClassY. 3) Create in ClassY a extension method with category *PackageX. If you now browse the instVar "classExtensionSelectors" of PackageX you will see ClassY. 4) Remove ClassY 5) notice that 'classExtensionSelectors' from PackageX still references ClassY. In fact, if you ask its extension methods you will have a KeyNotFound #ClassY in Smalltalk globals ;) So...I guess this is a bug. If true, I open an issue. Cheers, -- Mariano http://marianopeck.wordpress.com

Aug. 4, 2012

Re: [Pharo-project] RPackageOrganizer does not unregister when we unload MC ?

by Mariano Martinez Peck

On Thu, Aug 2, 2012 at 7:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Aug 2, 2012, at 1:54 PM, Mariano Martinez Peck wrote: > > > > > RPackageOrganizer default packages select: [:each | each name = > 'HistoryCollection'] -> an Array(a RPackage(HistoryCollection)) > > > > (MCPackage named: 'HistoryCollection') workingCopy unload. > > > > RPackageOrganizer default packages select: [:each | each name = > 'HistoryCollection'] -> an Array(a RPackage(HistoryCollection)) > > > > I would expect the last line to answer empty... is this a bug? > > yes or just something that was not yet done. > add a bug entry so that we do not forget. > Thanks mariano. > http://code.google.com/p/pharo/issues/detail?id=6512 > > I'm recovering slowly. Som days this is ok some days not. > > Stef > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 4, 2012

Re: [Pharo-project] RE : Configuration Browser feedback

by Esteban Lorenzano

Yes, that would be a good addition, but sadly is not so easy... if you have an idea of how to implement it, I would be happy to introduce it :) Cheers, Esteban On Aug 4, 2012, at 2:06 PM, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > +100 on the configuration description ! > > Thierry > ________________________________________ > De : pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] de la part de Ben Coman [btc(a)openInWorld.com] > Date d'envoi : samedi 4 aoÃ»t 2012 13:14 > Ã : Pharo-project(a)lists.gforge.inria.fr > Objet : [Pharo-project] Configuration Browser feedback > > Just thinking that the second tab of the Configuration Browser being > called "Untrusted" is a bit harsh and not really socially engaging. > "Community" has a better feel to me. > And perhaps not "Configurations" for the first tab either, since both > tabs are configurations. Perhaps "Core" or "Supported" or "Vetted" or > "Gold" or something similar. > > Also, what would be really fantastic would be some description of each > configuration being displayed in a pane on the right hand side. There > are A LOT of configurations listed there - which is great - but I don't > feel inclined to go looking up every single one to see if they interest > me. Sometimes what gets people interested in trying out new things is > that it just catches their eye in casual browsing. > > I guess a pre-requisite of that would be the ConfigurationOf file > containing such a description, as well as perhaps something on the back > end server that caches those descriptions into one file. > > cheers -ben > >

Aug. 4, 2012