- Pharo-dev - lists.pharo.org

Re: [Pharo-project] FileDirectory <> FSFileSystem

by Dale Henrichs

Cami, When I load your package into Pharo-1.4 the load eventually chokes because DirectoryClass has been deleted from the image ... For Pharo-1.4 we probably don't want the FileDirectory compatibility class... Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, August 10, 2012 1:56:37 AM | Subject: Re: [Pharo-project] FileDirectory <> FSFileSystem | | | On 2012-08-10, at 01:10, Dale Henrichs <dhenrich(a)vmware.com> wrote: | | > Cami, | > | > If you can let me know where to find your new FS code, I can take | > it for a spin ... | > | > I've already spent time inventing a Grease-like layer that I can | > use with FileDirectory and FileSystem, but if your FileDirectory | > will be available and will fulfill my needs I can toss out the | > work I've done so far ... | > | > I just ask that if you make up your minds once and for all here ... | > I don't want to port FileTree to Pharo-2.0 more than twice (as I | > will tossing the work that I've put into porting over the last two | > days...) | > | > Dale | | my preliminary version is here: | | http://smalltalkhub.com/mc/dh83/fisleg/main | | I didn't have time to test it though ;) |

Aug. 10, 2012

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

by Craig Latta

I also find using "self" is a bit of a roulette wheel... When I use this tactic, I always say "3 halt" instead. -C -- Craig Latta www.netjam.org/resume +31 6 2757 7177 + 1 415 287 3547 (no SMS)

Aug. 10, 2012

Re: [Pharo-project] smalltalkhub project names

by Nicolas Petton

I have to check. I fixed it in this commit http://smalltalkhub.com/#!/~NicolasPetton/SmalltalkHub/versions/Hub-Nicolas… Nico Camillo Bruni <camillobruni(a)gmail.com> writes: > is it still possible that we cannot enter $- in project names?? > > > > best > cami -- Nicolas Petton http://nicolas-petton.fr

Aug. 10, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Frank Shearar

DynamicVariables aren't really dynamic, in the sense that they're not connected to the executing environment. In particular, their #value:during: behaviour is * store old value * run block * restore old value which means that if you do something tricky during the block - perhaps like serialising the current context - when you deserialise the block you _don't_ have the value of the dynamic variable as it was during serialising. That might or might not affect what you're seeing though. I hadn't spoken up earlier because I'm not sure what exactly goes on during exporting/importing Zinc. frank On 10 August 2012 11:16, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > anyone? > > > On Wed, Aug 8, 2012 at 2:45 PM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> Guys...we are having a strange problem when exporting/importing Zinc. We >> have a problem when executing: >> >> executeRequestResponse >> self logRequest. >> ZnSignalProgress enabled >> ...... >> >> The first time, #enable answers something wrong. The second time it is >> called, it seems to answer the correct value. >> ZnSignalProgress is a subclass of DynamicVariable.... so I guess there is >> a black magic around this. >> There is a hook in Fuel where I can substitute an object being serialized >> for something else. Should I substitute DynamicVariables with something when >> serialized? send #value before serialize it? nil something? >> >> Thanks in advance, >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 10, 2012

Re: [Pharo-project] serializing DynamicVariables (Zinc so far)

by Mariano Martinez Peck

anyone? On Wed, Aug 8, 2012 at 2:45 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Guys...we are having a strange problem when exporting/importing Zinc. We > have a problem when executing: > > executeRequestResponse > self logRequest. > ZnSignalProgress enabled > ...... > > The first time, #enable answers something wrong. The second time it is > called, it seems to answer the correct value. > ZnSignalProgress is a subclass of DynamicVariable.... so I guess there is > a black magic around this. > There is a hook in Fuel where I can substitute an object being serialized > for something else. Should I substitute DynamicVariables with something > when serialized? send #value before serialize it? nil something? > > Thanks in advance, > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

Aug. 10, 2012

Re: [Pharo-project] smalltalkhub project names

by Frank Shearar

On 10 August 2012 09:53, Camillo Bruni <camillobruni(a)gmail.com> wrote: > > is it still possible that we cannot enter $- in project names?? Isn't this a limitation in Monticello package names? Given "Foo-Bar-fbs.1" is that the Bar branch of Foo, or a package Foo-Bar? (Solvable by munging the project name, but then the package name of course doesn't match the project name... which might be a price worth paying.) frank > best > cami

Aug. 10, 2012

Re: [Pharo-project] FileDirectory <> FSFileSystem

by Camillo Bruni

On 2012-08-10, at 01:10, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Cami, > > If you can let me know where to find your new FS code, I can take it for a spin ... > > I've already spent time inventing a Grease-like layer that I can use with FileDirectory and FileSystem, but if your FileDirectory will be available and will fulfill my needs I can toss out the work I've done so far ... > > I just ask that if you make up your minds once and for all here ... I don't want to port FileTree to Pharo-2.0 more than twice (as I will tossing the work that I've put into porting over the last two days...) > > Dale my preliminary version is here: http://smalltalkhub.com/mc/dh83/fisleg/main I didn't have time to test it though ;)

Aug. 10, 2012

[Pharo-project] smalltalkhub project names

by Camillo Bruni

is it still possible that we cannot enter $- in project names?? best cami

Aug. 10, 2012

Re: [Pharo-project] Question about RPackage (bug?)

by Esteban Lorenzano

not if it is prepared :) On Aug 10, 2012, at 9:57 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Fri, Aug 10, 2012 at 9:18 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Aug 9, 2012, at 4:50 PM, Fernando Olivero wrote: > > > You're right! But notice that the RPackage logic of one to one mapping > > with categories, only > > breaks when it only provides extension methods as in the case of > > 'AST-Core' and 'RPackage'. > > > > | p | > > p := RPackageOrganizer default packageNamed: 'AST-Core'. > > ( p extensionMethods size = 2 ) & ( p definedClasses size = 0 ) > > > > Only then, maybe this is a bug? > > Yes > Now just that you know. > RPackage ****import**** (system -> rpackageOrganizer) was done with the idea that we would map a category to > a package. > > Now we changed our mind, we will map a MCWorkingCopy to a RPAckage and categories will simply be class tags. > > So if you want to get rpackage working as the default MCWorkingCopy, you have to change the import phase > or wait that we do it. > > Now we should sync with ben because nautilus may be confused (and do not show class tags). > > But the worse will be that Nautilus will show less packages, with more stuff :). > > > Stef > > > > > > > > On Thu, Aug 9, 2012 at 1:52 PM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> > >> On Thu, Aug 9, 2012 at 1:25 PM, Fernando Olivero <fernando.olivero(a)usi.ch<mailto:fernando.olivero@usi.ch>> wrote: > >> Hi Mariano, > >> > >> I've been using RPackage so i stumbled on the same "problem". > >> RPackage maps System Categories (one to one), thus your problem > >> happens because there's no category named 'RPackage'. > >> > >> > >> But for the rest it works. For example: > >> > >> (RPackageOrganizer default packageNamed: 'AST-Core') > >> > >> And there is no category 'AST-Core'. > >> > >> Moreover, I have just discovered that if I evaluate: RPackageOrganizer initialize. > >> Then it appears :) > >> > >> > >> For example evaluate (RPackageOrganizer default packageNamed: 'RPackage-Core') > >> > >> Saludos, > >> Fernando > >> > >> On Thu, Aug 9, 2012 at 12:24 PM, Mariano Martinez Peck > >> <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote: > >>> (MCWorkingCopy allManagers collect: [:p | p package name] ) includes: 'RPackage' -> true > >>> > >>> (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound > >>> > >>> bug? > >>> > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > >

Aug. 10, 2012

Re: [Pharo-project] Question about RPackage (bug?)

by Guillermo Polito

On Fri, Aug 10, 2012 at 9:18 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Aug 9, 2012, at 4:50 PM, Fernando Olivero wrote: > > > You're right! But notice that the RPackage logic of one to one mapping > > with categories, only > > breaks when it only provides extension methods as in the case of > > 'AST-Core' and 'RPackage'. > > > > | p | > > p := RPackageOrganizer default packageNamed: 'AST-Core'. > > ( p extensionMethods size = 2 ) & ( p definedClasses size = 0 ) > > > > Only then, maybe this is a bug? > > Yes > Now just that you know. > RPackage ****import**** (system -> rpackageOrganizer) was done with the > idea that we would map a category to > a package. > > Now we changed our mind, we will map a MCWorkingCopy to a RPAckage and > categories will simply be class tags. > > So if you want to get rpackage working as the default MCWorkingCopy, you > have to change the import phase > or wait that we do it. > > Now we should sync with ben because nautilus may be confused (and do not > show class tags). > But the worse will be that Nautilus will show less packages, with more stuff :). > > Stef > > > > > > > > On Thu, Aug 9, 2012 at 1:52 PM, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> > >> On Thu, Aug 9, 2012 at 1:25 PM, Fernando Olivero < > fernando.olivero(a)usi.ch<mailto:fernando.olivero@usi.ch>> wrote: > >> Hi Mariano, > >> > >> I've been using RPackage so i stumbled on the same "problem". > >> RPackage maps System Categories (one to one), thus your problem > >> happens because there's no category named 'RPackage'. > >> > >> > >> But for the rest it works. For example: > >> > >> (RPackageOrganizer default packageNamed: 'AST-Core') > >> > >> And there is no category 'AST-Core'. > >> > >> Moreover, I have just discovered that if I evaluate: RPackageOrganizer > initialize. > >> Then it appears :) > >> > >> > >> For example evaluate (RPackageOrganizer default packageNamed: > 'RPackage-Core') > >> > >> Saludos, > >> Fernando > >> > >> On Thu, Aug 9, 2012 at 12:24 PM, Mariano Martinez Peck > >> <marianopeck(a)gmail.com<mailto:marianopeck@gmail.com>> wrote: > >>> (MCWorkingCopy allManagers collect: [:p | p package name] ) includes: > 'RPackage' -> true > >>> > >>> (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound > >>> > >>> bug? > >>> > >>> > >>> -- > >>> Mariano > >>> http://marianopeck.wordpress.com > >>> > >> > >> > >> > >> > >> -- > >> Mariano > >> http://marianopeck.wordpress.com > >> > > > > >

Aug. 10, 2012