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

Re: [Pharo-project] About the migration from PackageInfo to RPackage

by Mariano Martinez Peck

On Sun, Aug 5, 2012 at 1:28 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > Hi guys > > PackageInfo has a large APi that is often not used. > So I would suggest that we reduce the PackageInfo API first because it > will lower the stress on RPackage to be offer a > compatible interface. > All the methods in the compatibility should somehow disappear or only > serve as purpose to help temporary > backwards compat. > > I agree. But if you want to remove in the future PackageInfo, then RPackage HAS to provide a way to get the classes/extension methods of a MCPackage. That's why I need #allDefinedClasses and #allDefinedExtensionMethods > What do you think? > > Stef > -- Mariano http://marianopeck.wordpress.com

Aug. 5, 2012

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

by Mariano Martinez Peck

On Sun, Aug 5, 2012 at 1:07 PM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > > > 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]. >> ]. >> ] >> >> > Easier: > > 1) integrate http://code.google.com/p/pharo/issues/detail?id=6521 > 2) RPackageOrganizer initialize. > > Indeed, I saw that later. That only helps to fix the existing ones but it does not solve the problem. > >> >>> Cheers, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > -- Mariano http://marianopeck.wordpress.com

Aug. 5, 2012

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

by Guillermo Polito

Ok, I found the bug, I'm killing it. On Sun, Aug 5, 2012 at 1:07 PM, Guillermo Polito <guillermopolito(a)gmail.com>wrote: > > > 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]. >> ]. >> ] >> >> > Easier: > > 1) integrate http://code.google.com/p/pharo/issues/detail?id=6521 > 2) RPackageOrganizer initialize. > > >> >> >>> Cheers, >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >

Aug. 5, 2012

[Pharo-project] About the migration from PackageInfo to RPackage

by StÃ©phane Ducasse

Hi guys PackageInfo has a large APi that is often not used. So I would suggest that we reduce the PackageInfo API first because it will lower the stress on RPackage to be offer a compatible interface. All the methods in the compatibility should somehow disappear or only serve as purpose to help temporary backwards compat. What do you think? Stef

Aug. 5, 2012

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

by Guillermo Polito

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]. > ]. > ] > > Easier: 1) integrate http://code.google.com/p/pharo/issues/detail?id=6521 2) RPackageOrganizer initialize. > > >> Cheers, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

Aug. 5, 2012

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

by Guillermo Polito

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. > It is, and those steps can be translated to a test! :D > > Cheers, > > -- > Mariano > http://marianopeck.wordpress.com > >

Aug. 5, 2012

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

by stephane ducasse

Hi Philippe sounds quite good to me >> Thanks for considering this a friendly and positive thread. > > So instead of lamenting the state of the world I went ahead and wrote > some code. To find out what breaks in Seaside I created new packages > for every Pharo package that didn't work. So I ended up with: > > - Grease-Pharo20-Core > - Grease-Tests-Pharo20-Core > - Seaside-Pharo20-Core > - Seaside-Tests-Pharo20-Core > - Javascript-Pharo20-Core > > You can find them in the Seaside 3.1 repository [1]. I'm not really > sure this was a clever idea but it sounded better than writing a long > mail. > > Things I ran into: > - file system (obviously) > - SystemAnnouncer > - BlockContext is gone BlockContext has been abandoned some earth cycles ago already :) > - extension methods are now present on String > - different Float number printing this is strange > File system and SystemAnnouncer are only used by file library. > > Right now two tests fail because the GRPackage dependencies are > inconsistent due to a mix of Pharo and Pharo20 packages. The rest > seems to work, also functionally. So this is a good news. > > Things I didn't test or even load: > - OB tooling > - Slime/SLint tooling > > [1] http://www.squeaksource.com/Seaside31 > > Cheers > Philippe > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

Aug. 4, 2012

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

by StÃ©phane Ducasse

ok we will discuss with the crew here to see what is the best strategy. Stef On Aug 4, 2012, at 6:08 PM, Dale Henrichs wrote: > SystemChangeNotification is used in the tests...The tests (obviously) do a whole lot of loading and unloading of packages and suppressing change notifications during some tests has a significant impact on how long it takes to run the tests ... > > The solution for me is to add some code to the platform packages to hide SystemChangeNotification and use my own variant of silentlyDo: ... > > The real sticky problem is with FileDirectory... > > Dale > > ----- Original Message ----- > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Cc: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org>, metacello(a)googlegroups.com > | Sent: Saturday, August 4, 2012 5:01:48 AM > | Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes? > | > | > | 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

[Pharo-project] [ENH]: FileReference subclasses

by Sean P. DeNigris

Thoughts? Comments? Opinions? Issue 6525: [ENH]: FileReference subclasses http://code.google.com/p/pharo/issues/detail?id=6525 Different types of files have different behaviors. Currently, we need to add all those behaviors (e.g. #fileIn) to FileReference, even though they only make sense with a fraction of instances. I propose that we match the filename against FileReference subclasses. The following is a conversation starter. It works with strings... Usage: '/Users/sean/start.st' asFileReference. "anStFileReference" '/Users/sean/start.unknown' asFileReference. "aFileReference" 'file:///Users/me.st' asUrl asFileReference "not handled by current implementation, will default to aFileReference" For example, I can create a custom .st file subclass, with: StFileReference>>isClassFor: aResolvable (aResolvable isKindOf: String) ifFalse: [ ^ false ]. "just a hack to avoid DNU" ^ aResolvable endsWith: '.st'. Enhancing the following method will catch aString asFileReference, but not e.g. aFileUrl asFileReference: FileSystem>>referenceTo: aResolvable "Answer a reference to the argument from the context of the receiver filesystem. Example: FSFilesystem disk referenceTo: 'plonk.taz'" | referenceClass | referenceClass := FileReference allSubclasses detect: [ :e | e isClassFor: aResolvable ] ifNone: [ FileReference ]. ^ referenceClass fileSystem: self path: (self pathFromObject: aResolvable). -- View this message in context: http://forum.world.st/ENH-FileReference-subclasses-tp4643116.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 4, 2012

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

by Dale Henrichs

Philippe, Cami provided a port of FileTree to Pharo-2.0 within an hour... Getting FileTree to run is not the issue ... for me ... FileTree was written to be very _dependent_ on FileDirectory and needs to be rewritten... I think the Pharo folks are correct that most applications will not be hit nearly as hard by the removal of FileDirectory. Dale ----- Original Message ----- | From: "Philippe Marschall" <philippe.marschall(a)gmail.com> | To: "Seaside - general discussion" <seaside(a)lists.squeakfoundation.org> | Cc: Pharo-project(a)lists.gforge.inria.fr | Sent: Saturday, August 4, 2012 10:27:42 AM | Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | On Sat, Aug 4, 2012 at 11:21 AM, Mariano Martinez Peck | <marianopeck(a)gmail.com> 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. | > 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. | | So instead of lamenting the state of the world I went ahead and wrote | some code. To find out what breaks in Seaside I created new packages | for every Pharo package that didn't work. So I ended up with: | | - Grease-Pharo20-Core | - Grease-Tests-Pharo20-Core | - Seaside-Pharo20-Core | - Seaside-Tests-Pharo20-Core | - Javascript-Pharo20-Core | | You can find them in the Seaside 3.1 repository [1]. I'm not really | sure this was a clever idea but it sounded better than writing a long | mail. | | Things I ran into: | - file system (obviously) | - SystemAnnouncer | - BlockContext is gone | - extension methods are now present on String | - different Float number printing | | File system and SystemAnnouncer are only used by file library. | | Right now two tests fail because the GRPackage dependencies are | inconsistent due to a mix of Pharo and Pharo20 packages. The rest | seems to work, also functionally. | | Things I didn't test or even load: | - OB tooling | - Slime/SLint tooling | | [1] http://www.squeaksource.com/Seaside31 | | Cheers | Philippe | _______________________________________________ | seaside mailing list | seaside(a)lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |

Aug. 4, 2012