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

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

Re: [Pharo-project] FileDirectory <> FSFileSystem

by StÃ©phane Ducasse

for your info, I have been working on resfreshing the chapter on FS and It helped me to find some strange stuff. So I will push a list of questions soon. Stef On Aug 9, 2012, at 11:57 PM, Camillo Bruni wrote: > FileSystem compat > ----------------- > During my train trip today I "ported" (AKA copied) the whole FileSystem package > from 2.0 to 1.4 and fixed some tests: > - the 2.0 FS works almost perfectly in 1.4 > - some Tests related to DateAndTime fail! > > Furthermore I created a dumb FileDirectory interface for 2.0 > - FileDirectory is a subclass of FileReference > - FileSystem-Legacy protocols have been added to FileReference / FileDirectory > > given these two changes I think we can more safely port stuff from 1.4 to 2.0. > > > Problems > -------- > The only thing failing under 1.4 are the DateAndTime related tests since 1.4 > doesn't feature the time zone fixes. Are you (Esteban) willing to backport > the changes made to 2.0 for DateAndTime. For production code it's not that > crucial, since as long as your VM/image doesn't change time zones everything > will just work fine ;) (it's not a bug, it's a feature, yeah yeah)

Aug. 10, 2012

Re: [Pharo-project] ScaledDecimal #printOn

by StÃ©phane Ducasse

please please please update to 1.4 because we improved a lottttttttt and even more :) On Aug 10, 2012, at 12:12 AM, Guy wrote: > Cami, > Silly me 1.1.1. I should obviously be up to date. > > Thanks > > Guy > > On 10/08/2012, at 10:04 AM, Camillo Bruni wrote: > >> which version of Pharo/VM are you using? >> Cause in my latest 1.4 and latest 2.0 this seems to work... >> >> String streamContents: [ :s| -0.55s2 printOn: s ] "yields the expected '-0.55s2'" >> >> I remember Mariano once had a strange integer issue since he accidentally used once of >> is own compiled VMs which wasn't working as expected. >> >> >> best >> cami >> >> On 2012-08-09, at 23:53, Guy <guy(a)healthqualitynz.com> wrote: >> >>> Team Pharo, >>> The printOn: method in ScaledDecimal returns a positive number string where the number is >-1 and < 0. For example -0.55s2 returns a string '0.55s2'. >>> >>> I have made my own correction. >>> >>> This may help the one other person who is using ScaledDecimal as a proxy for Currency but I have no idea what to do with this astounding discovery nor whether it will help anyone nor indeed if it is very tidy code. >>> >>> Thanks >>> >>> Guy Bloomfield >>> >>> The current method starts with the string for the integer part 0 and then the absolute value of the fraction: >>> >>> printOn: aStream >>> "Append an approximated representation of the receiver on aStream. >>> Use prescribed number of digits after decimal point (the scale) using a rounding operation if not exact" >>> >>> | fractionPart | >>> scale = 0 >>> ifTrue: [self rounded printOn: aStream] >>> ifFalse: [self integerPart printOn: aStream. >>> aStream nextPut: $.. >>> fractionPart := (self abs fractionPart * (10 raisedToInteger: scale)) rounded. >>> ..... >>> >>> My correction: >>> >>> printOn: aStream >>> "Append an approximated representation of the receiver on aStream. >>> Use prescribed number of digits after decimal point (the scale) using a rounding operation if not exact" >>> >>> | fractionPart | >>> >>> self < 0 ifTrue: [ aStream nextPut: $- ]. >>> >>> scale = 0 >>> ifTrue: [self rounded printOn: aStream] >>> ifFalse: [self abs integerPart printOn: aStream. >>> aStream nextPut: $.. >>> fractionPart := (self abs fractionPart * (10 raisedToInteger: scale)) rounded. >>> ..... >>> >>> >> > >

Aug. 10, 2012

Re: [Pharo-project] Spec DropLists

by StÃ©phane Ducasse

Thanks sean Ben is on holidays for two weeks. So I imagine that he will not read the mailing-list. Stef On Aug 9, 2012, at 8:14 PM, Sean P. DeNigris wrote: > Issue 6551: [ENH Spec]: Spec-ify DropListModel > http://code.google.com/p/pharo/issues/detail?id=6551 > > Currently: > self instantiateModels: #(dropList #DropListModel). > > item1 := DropListItem named: 'Red morph' do: self redMorphBlock. > item2 := DropListItem named: 'Blue morph' do: self blueMorphBlock. > item3 := DropListItem named: 'Green morph' do: self greenMorphBlock. > > dropList items: {item1. item2. item3}. > > I'd prefer if DropLists were uniform with the rest of Spec, namely: > I'd have my domain class > MyColor>>description > ^ nameOfColor > > dropList > items: {myRedColor. myBlueColor. myGreenColor}; > displayBlock: [ :e | e description, ' morph' ]; > whenSelectionChanged: [ :e | self showMorphFor: e ]. > > I'd prefer not to even know that DropListItem exists, and have the model > take care of it for me. Something like: > DropListModel>>items: aList > "Populate the drop list with a list of objects" > > | items | > items := aList collect: [ :e | DropListItem named: e printString do: [ ] > ]. > listHolder contents: items. > > Incidentally, #whenSelectionChanged: exists for DropListModels, but is > broken. When an item is chosen from the drop list, the announcement received > by this block has both new and old contents set to nil: > Issue 6550: [BUG Spec]: DropListModel>>whenSelectionChanged: > http://code.google.com/p/pharo/issues/detail?id=6550 > > Cheers, > Sean > > > > -- > View this message in context: http://forum.world.st/Spec-DropLists-tp4643694.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Aug. 10, 2012

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

by StÃ©phane Ducasse

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). 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