- Pharo-dev - lists.pharo.org

Re: [Pharo-project] FileDirectory <> FSFileSystem

by Dale Henrichs

Cami, Well, I've been able to use the existing FS implementation to get to the point where I am passing all of my unit tests in Pharo-2.0 without FileDirectory ... I had to hack in a couple of places to get around the deficiencies of FS on Pharo-1.4 and I've yet to port the changes to the other platforms, so I'm not quite out of the woods, but I am at the point where I will start doing development in Pharo-2.0 using the FileTree repositories. It will be nice to be able to use FS in Pharo-1.4, moving forward... Thanks for your help, Dale ----- Original Message ----- | From: "Camillo Bruni" <camillobruni(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, August 10, 2012 4:50:13 PM | Subject: Re: [Pharo-project] FileDirectory <> FSFileSystem | | hi dale, | | digesting your word flow right now :P... | I don't think I will touch a computer this weekend so I probably take | a look at | it on monday to make the two things work... | | just to clarify what I intend to do: | - update FS in 1.4 so we have all the "modern" features | - provide an optionally loadable FileDirectory stub in 2.0 | | I hope like that migration should become easier, since you can simply | load code in 2.0 | and slowly start calling FileReference methods on the FileDirectory | entries. | My FileDirectory wrapper in 2.0 is simply a subclass of | FileReference, being polymorphic | here, I think, should really ease the migration task. | | best | cami | | On 2012-08-10, at 19:15, Dale Henrichs <dhenrich(a)vmware.com> wrote: | | > Cami, | > | > turns out that #readStreamDo: was added for FileTree in Pharo1.x so | > adding it doesn't need to be part of the base ... | > | > #name would then be the only compatibility method ... I can add | > that one as an extension, too. | > | > Dale | > | > ----- Original Message ----- | > | From: "Dale Henrichs" <dhenrich(a)vmware.com> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Friday, August 10, 2012 8:39:18 AM | > | Subject: Re: [Pharo-project] FileDirectory <> FSFileSystem | > | | > | Cami, | > | | > | Despite not being able to load your working version in Pharo-1.4 | > | I am | > | making progress:). I've created a Grease-like layer for FileTree | > | that papers over the differences between FileDirectory and | > | FileSystem (there is no common protocol between the two at | > | all:)... | > | | > | I am now porting the FileSystemDirectoryEntry/DirectoryEntry code | > | and | > | it would be _extremely convenient_ if FileSystemDirectoryEntry | > | were | > | more compatible with DirectoryEntry. In my case the two methods: | > | #name and #readStreamDo: would save me a ton of work. | > | | > | I can add them as extension methods for FileTree (and will for | > | the | > | time being). #readStreamDo: is just plain missing and #name is an | > | obvious concession to portability... | > | | > | Let me know whether you think these two method will be included | > | in | > | Pharo-2.0 or not. | > | | > | 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. 11, 2012

Re: [Pharo-project] FileDirectory <> FSFileSystem

by Camillo Bruni

hi dale, digesting your word flow right now :P... I don't think I will touch a computer this weekend so I probably take a look at it on monday to make the two things work... just to clarify what I intend to do: - update FS in 1.4 so we have all the "modern" features - provide an optionally loadable FileDirectory stub in 2.0 I hope like that migration should become easier, since you can simply load code in 2.0 and slowly start calling FileReference methods on the FileDirectory entries. My FileDirectory wrapper in 2.0 is simply a subclass of FileReference, being polymorphic here, I think, should really ease the migration task. best cami On 2012-08-10, at 19:15, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Cami, > > turns out that #readStreamDo: was added for FileTree in Pharo1.x so adding it doesn't need to be part of the base ... > > #name would then be the only compatibility method ... I can add that one as an extension, too. > > Dale > > ----- Original Message ----- > | From: "Dale Henrichs" <dhenrich(a)vmware.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, August 10, 2012 8:39:18 AM > | Subject: Re: [Pharo-project] FileDirectory <> FSFileSystem > | > | Cami, > | > | Despite not being able to load your working version in Pharo-1.4 I am > | making progress:). I've created a Grease-like layer for FileTree > | that papers over the differences between FileDirectory and > | FileSystem (there is no common protocol between the two at all:)... > | > | I am now porting the FileSystemDirectoryEntry/DirectoryEntry code and > | it would be _extremely convenient_ if FileSystemDirectoryEntry were > | more compatible with DirectoryEntry. In my case the two methods: > | #name and #readStreamDo: would save me a ton of work. > | > | I can add them as extension methods for FileTree (and will for the > | time being). #readStreamDo: is just plain missing and #name is an > | obvious concession to portability... > | > | Let me know whether you think these two method will be included in > | Pharo-2.0 or not. > | > | 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] FileDirectory <> FSFileSystem

by Dale Henrichs

Cami, turns out that #readStreamDo: was added for FileTree in Pharo1.x so adding it doesn't need to be part of the base ... #name would then be the only compatibility method ... I can add that one as an extension, too. Dale ----- Original Message ----- | From: "Dale Henrichs" <dhenrich(a)vmware.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, August 10, 2012 8:39:18 AM | Subject: Re: [Pharo-project] FileDirectory <> FSFileSystem | | Cami, | | Despite not being able to load your working version in Pharo-1.4 I am | making progress:). I've created a Grease-like layer for FileTree | that papers over the differences between FileDirectory and | FileSystem (there is no common protocol between the two at all:)... | | I am now porting the FileSystemDirectoryEntry/DirectoryEntry code and | it would be _extremely convenient_ if FileSystemDirectoryEntry were | more compatible with DirectoryEntry. In my case the two methods: | #name and #readStreamDo: would save me a ton of work. | | I can add them as extension methods for FileTree (and will for the | time being). #readStreamDo: is just plain missing and #name is an | obvious concession to portability... | | Let me know whether you think these two method will be included in | Pharo-2.0 or not. | | 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

[Pharo-project] [update 2.0] #20250

by Esteban Lorenzano

20250 ----- Issue 6503: ScriptLoader deletePackage: does not say what it says http://code.google.com/p/pharo/issues/detail?id=6503 Issue 6542: unload package Polymorph http://code.google.com/p/pharo/issues/detail?id=6542 Issue 6544: [ENH]: SystemPreferences - Notify Errors http://code.google.com/p/pharo/issues/detail?id=6544 Issue 6545: There are no accesses to commandLine in CommandLineHandlerTest http://code.google.com/p/pharo/issues/detail?id=6545

Aug. 10, 2012

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

by Esteban Lorenzano

he, don't worry... that will not change soon :) On Aug 10, 2012, at 6:01 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Oh no! Now I'm going to have to port all of the `self halts` in my code, too:) > > Dale > > ----- Original Message ----- > | From: "Sean P. DeNigris" <sean(a)clipperadams.com> > | To: pharo-project(a)lists.gforge.inria.fr > | Sent: Friday, August 10, 2012 8:51:10 AM > | Subject: Re: [Pharo-project] 'self halt' safety net > | > | > | Igor Stasenko wrote > | > > | > but i so get used to type 'self halt' .. its hard to get rid of bad > | > habits. :) > | > > | > | Ha ha, I wanted to remove it but Steph wouldn't let me ;) > | > | > | > | -- > | View this message in context: > | http://forum.world.st/self-halt-safety-net-tp4643012p4643771.html > | Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > | > | >

Aug. 10, 2012

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

by Dale Henrichs

Aug. 10, 2012

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

by Sean P. DeNigris

Igor Stasenko wrote > > but i so get used to type 'self halt' .. its hard to get rid of bad > habits. :) > Ha ha, I wanted to remove it but Steph wouldn't let me ;) -- View this message in context: http://forum.world.st/self-halt-safety-net-tp4643012p4643771.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Aug. 10, 2012

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

by Igor Stasenko

On 10 August 2012 14:41, Craig Latta <craig(a)netjam.org> wrote: > > I also find using "self" is a bit of a roulette wheel... When I use > this tactic, I always say "3 halt" instead. > in pharo you can use Halt now. which is imo the right way to do it.. but i so get used to type 'self halt' .. its hard to get rid of bad habits. :) > > -C > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 (no SMS) > > -- Best regards, Igor Stasenko.

Aug. 10, 2012

Re: [Pharo-project] FileDirectory <> FSFileSystem

by Dale Henrichs

Cami, Despite not being able to load your working version in Pharo-1.4 I am making progress:). I've created a Grease-like layer for FileTree that papers over the differences between FileDirectory and FileSystem (there is no common protocol between the two at all:)... I am now porting the FileSystemDirectoryEntry/DirectoryEntry code and it would be _extremely convenient_ if FileSystemDirectoryEntry were more compatible with DirectoryEntry. In my case the two methods: #name and #readStreamDo: would save me a ton of work. I can add them as extension methods for FileTree (and will for the time being). #readStreamDo: is just plain missing and #name is an obvious concession to portability... Let me know whether you think these two method will be included in Pharo-2.0 or not. 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] Spec DropLists

by Christophe Demarey

+1 for me I had exactly the same experience with DropLists Le 9 aoÃ»t 2012 Ã 20:14, Sean P. DeNigris a Ã©crit : > 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