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

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

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