- Pharo-dev - lists.pharo.org

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

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

by StÃ©phane Ducasse

On Aug 9, 2012, at 12:24 PM, Mariano Martinez Peck wrote: > (MCWorkingCopy allManagers collect: [:p | p package name] ) includes: 'RPackage' -> true > > (RPackageOrganizer default packageNamed: 'RPackage') -> KeyNotFound probably. But again the import from the system to RPackageOrganizer has never been look at seriously. > > bug? > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 10, 2012

Re: [Pharo-project] FileDirectory <> FSFileSystem

by Dale Henrichs

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 ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Thursday, August 9, 2012 3:19:06 PM | Subject: Re: [Pharo-project] FileDirectory <> FSFileSystem | | On 2012-08-10, at 00:15, "Sean P. DeNigris" <sean(a)clipperadams.com> | wrote: | > Camillo Bruni-3 wrote | >> | >> FileSystem compat | >> | > Is the FS 2.0 API backward-compatible with the current 1.4 FS? If | > not, (and | > I /really/ want to have the latest FS in 1.4), I think it should be | > loadable | > via Metacello as not to create a mess for our users... maybe | > ConfigurationOfFilesystem20. | | most of the interface is more or less the same, with a bit less love | in 1.4 and | certainly partly broken file streams... so I think we should update | it in 1.4 | | > Camillo Bruni-3 wrote | >> | >> - some Tests related to DateAndTime fail! | >> | > How does FS effect DateAndTime, or is that a separate issue? | It's the other way round :), some FS test fail due to the timezone | bug | | | > Camillo Bruni-3 wrote | >> | >> Furthermore I created a dumb FileDirectory interface for 2.0 | >> | > Cool! As much as I dislike FileDir, that will be helpful to people | > porting. | > Will the compatibility methods raise deprecation warnings? | | I didn't add that so far, but I guess we should, or provide a simple | package to | manually load the the compat package, so it's a bit of a step :P |

Aug. 9, 2012

Re: [Pharo-project] FileDirectory <> FSFileSystem

by Camillo Bruni

On 2012-08-10, at 00:15, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > Camillo Bruni-3 wrote >> >> FileSystem compat >> > Is the FS 2.0 API backward-compatible with the current 1.4 FS? If not, (and > I /really/ want to have the latest FS in 1.4), I think it should be loadable > via Metacello as not to create a mess for our users... maybe > ConfigurationOfFilesystem20. most of the interface is more or less the same, with a bit less love in 1.4 and certainly partly broken file streams... so I think we should update it in 1.4 > Camillo Bruni-3 wrote >> >> - some Tests related to DateAndTime fail! >> > How does FS effect DateAndTime, or is that a separate issue? It's the other way round :), some FS test fail due to the timezone bug > Camillo Bruni-3 wrote >> >> Furthermore I created a dumb FileDirectory interface for 2.0 >> > Cool! As much as I dislike FileDir, that will be helpful to people porting. > Will the compatibility methods raise deprecation warnings? I didn't add that so far, but I guess we should, or provide a simple package to manually load the the compat package, so it's a bit of a step :P

Aug. 9, 2012

Re: [Pharo-project] FileDirectory <> FSFileSystem

by Sean P. DeNigris

Camillo Bruni-3 wrote > > FileSystem compat > Is the FS 2.0 API backward-compatible with the current 1.4 FS? If not, (and I /really/ want to have the latest FS in 1.4), I think it should be loadable via Metacello as not to create a mess for our users... maybe ConfigurationOfFilesystem20. Camillo Bruni-3 wrote > > - some Tests related to DateAndTime fail! > How does FS effect DateAndTime, or is that a separate issue? Camillo Bruni-3 wrote > > Furthermore I created a dumb FileDirectory interface for 2.0 > Cool! As much as I dislike FileDir, that will be helpful to people porting. Will the compatibility methods raise deprecation warnings? Sean -- View this message in context: http://forum.world.st/FileDirectory-FSFileSystem-tp4643713p4643717.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 9, 2012

Re: [Pharo-project] ScaledDecimal #printOn

by Guy

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. 9, 2012

Re: [Pharo-project] Script passing and StartupPreferences

by Camillo Bruni

On 2012-08-09, at 22:54, Francois Stephany <tulipe.moutarde(a)gmail.com> wrote: > +1, preferences should be loaded before any laod scripts. indeed, so we have to change the order in the startup list... > On 09/08/12 12:20, Sean P. DeNigris wrote: >> >> Sean P. DeNigris wrote >>> >>> It seems that (in 1.4, not sure about 2.0) if an image is launched with a >>> script (e.g. "cogvm my.image my.st"), StartupPreferences are never run. Is >>> that what's intended? >>> >> >> After experimenting a bit, it seems that preferences are loaded after script >> arguments are handled, so if the script ends in #snapshot:andQuit:, the >> prefs never get loaded. >> >> I'm thinking the prefs should be loaded before any scripts. For example, I >> want my shared cache to be set as the package cache before any load scripts >> are run. >> >> What do y'all think?

Aug. 9, 2012