August 2012 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?

by Mariano Martinez Peck

On Sat, Aug 4, 2012 at 2:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > On Aug 4, 2012, at 11:21 AM, Mariano Martinez Peck wrote: > > > Hi all. I am answering to all together: > > > > Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0 > with seaside and magritte. With 5 minutes of opening debuggers and change > things I was able to correctly make it work (at least, my app, I didn't run > all tests to see). > > > > Dale: We don't want to just help you with "hacks", that why I send this > email and several others, to see what others think so that can find better > and non-hacky solutions. So, let's try to find good solutions: > > > > 1) does it help if we put back FildeDirectory and we remove it later ? > so that you have time to update Metacello and that we can still use > Metacello :) > > 2) for the SystemChangeNotifier does it make sense to delegate to the > closures? [ xx ] valueWithoutSystemNotifications. Or we add a > #doSilently: and we add a MetacelloPharo20Platform that overrides the > behavior. > > I do not understand why metacello is concerned about > systemChangeNotification. > > Just to make certain things silent in the tests. -- Mariano http://marianopeck.wordpress.com

Aug. 4, 2012

[Pharo-project] RE : Configuration Browser feedback

by GOUBIER Thierry

+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

Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?

by StÃ©phane Ducasse

> > SystemChangeNotifier is a complete different situation than FileDirectory, and we removed it because the effort of keeping the system working having two different notification centers was eating all our time for make improvements. So, we (I myself) decided to unload it and stop waisting time on try to make the synchronization work... if you see the "before" and "after" (once we finish, that is not done yet) you will notice the clarity and simplicity gained. So... SystemChangeNotification is not going to go back, but an approach like Mariano proposed would work fine, since Metacello just uses the #doSilently stuff. > Btw... this is internal from Pharo, and 99.99% of the packages around shouldn't even notice the difference. Of course, Metacello is in the 0.01% remaining :) > >> 3) as Janko said, what about improving/using Grease/Sport for this purpose? do they provide something for this? could this be added? > > I'm strongly against this option, because I think Metacello (base) should be part of Pharo Core (in fact I was planning to introduce it next days). If I need to load grease or sport, I certainly will banish Metacello from core... and I don't want to. Again, I prefer to spend time fixing Metacello to load on Pharo (and I maintain my offer of spending it, he). Yes I'm against adding layers of layers of layers. > >> 4) Should we integrate Metacello in the image with our changes until you have time and find a good solution that works everywhere? Maybe if we do 1) i >> t is not very necessary. > > I want Metacello in core, so... this is probably a good idea. A shrink down version then. > > best, > Esteban > >> >> Thanks for considering this a friendly and positive thread. >> >> On Sat, Aug 4, 2012 at 9:16 AM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: >> Hi Dale, >> >> Dne 04. 08. 2012 07:31, piÅ¡e Dale Henrichs: >> >> > The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today. >> >> Just FYI, there is a Sport portability library and by using Sport's >> SpFilename you have an instantly portable file support over quite a >> dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 >> filesystem first .. >> >> Best regards >> Janko >> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> _______________________________________________ >> seaside mailing list >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >

Aug. 4, 2012

Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?

by StÃ©phane Ducasse

On Aug 4, 2012, at 11:21 AM, Mariano Martinez Peck wrote: > Hi all. I am answering to all together: > > Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0 with seaside and magritte. With 5 minutes of opening debuggers and change things I was able to correctly make it work (at least, my app, I didn't run all tests to see). > > Dale: We don't want to just help you with "hacks", that why I send this email and several others, to see what others think so that can find better and non-hacky solutions. So, let's try to find good solutions: > > 1) does it help if we put back FildeDirectory and we remove it later ? so that you have time to update Metacello and that we can still use Metacello :) > 2) for the SystemChangeNotifier does it make sense to delegate to the closures? [ xx ] valueWithoutSystemNotifications. Or we add a #doSilently: and we add a MetacelloPharo20Platform that overrides the behavior. I do not understand why metacello is concerned about systemChangeNotification. > 3) as Janko said, what about improving/using Grease/Sport for this purpose? do they provide something for this? could this be added? > 4) Should we integrate Metacello in the image with our changes until you have time and find a good solution that works everywhere? Maybe if we do 1) it is not very necessary. > > Thanks for considering this a friendly and positive thread. > > On Sat, Aug 4, 2012 at 9:16 AM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > Hi Dale, > > Dne 04. 08. 2012 07:31, piÅ¡e Dale Henrichs: > > > The bigger problem is that I have to have a code base that runs on multiple platforms while being maintainable, so a "port" to Pharo-2.0 is only a starting point. In the case of FileTree, which is the real bottleneck there's a lot code that is written against the FileDirectory API, so there will need to be significant work to find a way to keep a common code base .... a much tougher problem, than "just getting it working", it can be solved with time, but I didn't budget time for an emergency rewrite of FileTree ... today. > > Just FYI, there is a Sport portability library and by using Sport's > SpFilename you have an instantly portable file support over quite a > dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 > filesystem first .. > > Best regards > Janko > > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 4, 2012