- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About EndOfStream notification [was Streams - #nextLine]

by Nicolas Cellier

Bill, What I propose is to let programmer decide whether he will use Exception or not on endOfStream. And if he choose Exception, I underline that a defaultAction answering nil is not a panacea. But that defaultAction would still be an option if it solves your problem. Not sure my proposition does really solve the #next: problem you raised, indeed. The solution could be independant of endOfStream handling for this one. I support your request of creating a VW/Dolphin compatible #nextAvailable: and changing #next: to raise a NotEnoughElementAvailableError (maybe a subclass of EndOfStreamError). We would have a few package incompatibility, but, on ne fait pas d'omelette sans casser des oeufs... But I'm not convinced by the idea of duplicating the whole method protocol. Nor on duplicating the whole Stream class hierarchy, it's too big. That's were a classic delegation pattern can help (pluggable endOfStream). Of course, Trait composition is another option, and dynamic (on the fly) composition would be fun experimenting (as opposed to Static class definition). Keeping Traits as independant code units as possible is an interesting challenge (to explore the limits of such design). Nicolas 2009/6/9 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > > On Jun 8, 2009, at 9:32 PM, Nicolas Cellier wrote: > >> There are better examples where I want Exceptions, so I'd like the >> choice to be in programmers hands. >> - 1) Raising an EndOfStream Exception (and not a Notification as I >> suggested) should be optional >> - 2) The Exception should not have a default action. > > To add emphasis: it can't have a default action or it is not doing its job. > > >> The simple thing to do is to add an endOfStreamAction instanceVariable >> to Stream or ReadStream. >> If a read past end is attempted, then ^endOfStreamAction value. >> >> nil value = nil, so letting this inst var uninitialized will lead to >> backward compatibility (at minimal cost concerning efficieny!). >> filling the inst var with a block comes to mind immediately, and among >> natural choice is: >> Stream>>willSignalEndOfStream >> Â Â Â self endOfStreamAction: [EndOfStream signal] >> >> There might be more work for Stream wrappers, but that sounds a cheap >> and efficient idea to reconcile both worlds. >> >> What will protect above code example from an internal low level >> EndOfStream? >> Nothing, but the fact that programmers using explicitely >> #willSignalEndOfStream will know what they do! >> Either they will protect with a handling block, or advertise enough >> that the code might generate spurious EndOfStream on malformed >> inputs... > > I hesitate to call the exceptions spurious; in situations where they would be described as such, I generally would use #nextAvailable: and write code that won't blow up. Â Exceptions do a very important job: they carry information from the point of detection of a problem to a place (often far removed on the stack) where a corrective action can be reasonably applied. > > To (attempt) to paraphrase your idea, you are proposing to remove the default action from EndOfStream, replacing that blunting of exceptions with an uninitialized endOfStreamAction instance variable that defalts to the same behavior, and can be set to ensure raising of exceptions. Â Fair? > > This is certainly worth a try. Â For my part, the cost would be I need to ensure that I set the exception behavior on every stream I create vs. ensuring I use a different set of methods. Â It's probably no worse, and maybe easier to enforce. Â I will generally hide ReadStream on: behind a helper, #readStream, so I could just as easily use #readStreamRobust to create the stream and activate exceptions. Â Sorry to press this so hard, but I cannot afford to have things breaking w/o telling me. Â At best, that wastes time to track down mysterious failures, and worse, it can be dangerous. Â It's not unlike the practice of building electronic enclosures with lots of exposed grounded metal. Â It took me a while to gain comfort with it, but the idea is that if a wire comes loose, it hits ground, pulls a breaker, and goes into a safe mode and gets attention as a side effect. > > Bill > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009

Re: [Pharo-project] About super initialize

by Lukas Renggli

> I do not think that we will hev speed impact but yes we should run that. > Still I have the impression that for direct subclasses of Object super > initialize is unnecessary If you follow this pattern refactoring code (moving classes in hierarchies) can easily introduce bugs. Furthermore it is already complicated enough for beginners to know when to call super initialize and when not (the class side). So I would strive for the simplest and most uniform solution --- always call super initialize. In Seaside we always call super initialize, even if the initialize method is empty. This is more uniform and makes refactoring easier. The only exception for this rule is the single direct subclass of Object we have, WAObject. This class does not call super initialize solely for portability reasons, no other Smalltalk implements #initialize on Object. Of course we have various Lint rules that check the initialize patterns in the Seaside code. I guess they could be (adapted and) run on Pharo code too. If you want me to run them, let me know and I can post a list of the offending methods. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

June 9, 2009

Re: [Pharo-project] Syntax error loading Coral

by Luc Fabresse

2009/6/9 Mariano Martinez Peck <marianopeck(a)gmail.com> > pharo scripts to rename iPhoto pictures??? > Writing scripts using Pharo (instead of Bash, Ruby,...) is the objective of Coral. So, Coral could be used to rename files in the future. > > On Mon, Jun 8, 2009 at 5:48 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> > Hi all, >> > >> > I tried to load Coral in the latest dev image using ScriptLoader >> > and I got a syntax error in >> > "UnixProcess>>argsAsFlatArrayAndOffsets:". I guess it is an UTF-8 >> > problem. >> > Any ideas for a solution ? >> >> Not right on top of my head but this is cool that you tried it. I >> want to write pharo scripts >> to rename my iPhoto pictures and lot more. >> >> > >> > #Luc >> > _______________________________________________ >> > Pharo-project mailing list >> > Pharo-project(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009

Re: [Pharo-project] About EndOfStream notification [was Streams - #nextLine]

by Schwab,Wilhelm K

On Jun 8, 2009, at 9:32 PM, Nicolas Cellier wrote: > There are better examples where I want Exceptions, so I'd like the > choice to be in programmers hands. > - 1) Raising an EndOfStream Exception (and not a Notification as I > suggested) should be optional > - 2) The Exception should not have a default action. To add emphasis: it can't have a default action or it is not doing its job. > The simple thing to do is to add an endOfStreamAction instanceVariable > to Stream or ReadStream. > If a read past end is attempted, then ^endOfStreamAction value. > > nil value = nil, so letting this inst var uninitialized will lead to > backward compatibility (at minimal cost concerning efficieny!). > filling the inst var with a block comes to mind immediately, and among > natural choice is: > Stream>>willSignalEndOfStream > self endOfStreamAction: [EndOfStream signal] > > There might be more work for Stream wrappers, but that sounds a cheap > and efficient idea to reconcile both worlds. > > What will protect above code example from an internal low level > EndOfStream? > Nothing, but the fact that programmers using explicitely > #willSignalEndOfStream will know what they do! > Either they will protect with a handling block, or advertise enough > that the code might generate spurious EndOfStream on malformed > inputs... I hesitate to call the exceptions spurious; in situations where they would be described as such, I generally would use #nextAvailable: and write code that won't blow up. Exceptions do a very important job: they carry information from the point of detection of a problem to a place (often far removed on the stack) where a corrective action can be reasonably applied. To (attempt) to paraphrase your idea, you are proposing to remove the default action from EndOfStream, replacing that blunting of exceptions with an uninitialized endOfStreamAction instance variable that defalts to the same behavior, and can be set to ensure raising of exceptions. Fair? This is certainly worth a try. For my part, the cost would be I need to ensure that I set the exception behavior on every stream I create vs. ensuring I use a different set of methods. It's probably no worse, and maybe easier to enforce. I will generally hide ReadStream on: behind a helper, #readStream, so I could just as easily use #readStreamRobust to create the stream and activate exceptions. Sorry to press this so hard, but I cannot afford to have things breaking w/o telling me. At best, that wastes time to track down mysterious failures, and worse, it can be dangerous. It's not unlike the practice of building electronic enclosures with lots of exposed grounded metal. It took me a while to gain comfort with it, but the idea is that if a wire comes loose, it hits ground, pulls a breaker, and goes into a safe mode and gets attention as a side effect. Bill

June 9, 2009

[Pharo-project] Pharo Inbox Conflict

by Gabriel Cotelli

Hi, I rewrite the following Morph methods: TransformMorph >> numberOfItemsPotentiallyInViewWith: PluggableListMorph >> numSelectionsInView WorldState class >> deferredExecutionTimeLimit WorldState >> runStepMethodsIn: but when I try to upload to Pharo Inbox I get the attached warning.. (see attached file) Should I proceed with the saving? My version is also numbered 325 but with different author Thanks, Gabriel

June 9, 2009

Re: [Pharo-project] swapMouseButtons doesn't work

by Mariano Martinez Peck

Yes. I can see it in that version. Ok.This was weird. Between 10319 and 10234 seems to have changed and then returned..... On Mon, Jun 8, 2009 at 5:54 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > in 10331 core > > swapMouseButtons > ^ self > valueOfFlag: #swapMouseButtons > ifAbsent: [ > OSPlatform current platformFamily ~= #Windows ] > > > > > On Jun 8, 2009, at 8:10 PM, Mariano Martinez Peck wrote: > > > I don't get it. I see Pharo 9.06.1 which is based on 10234 and this > > is the implementation: > > > > swapMouseButtons > > ^ self > > valueOfFlag: #swapMouseButtons > > ifAbsent: [false] > > > > > > But, you said you change to > > > > > > swapMouseButtons > > ^ self > > valueOfFlag: #swapMouseButtons > > ifAbsent: [ > > OSPlatform current platformFamily ~= #Windows ] > > > > in 10319 > > > > > > So, maybe it has been overriden? > > > > Cheers, > > > > Mariano > > > > On Sun, Jun 7, 2009 at 5:16 PM, Adrian Lienhard <adi(a)netstyle.ch> > > wrote: > > In issue #838 I changed the implementation to be platform specific as > > follows: > > > > swapMouseButtons > > ^ self > > valueOfFlag: #swapMouseButtons > > ifAbsent: [ > > OSPlatform current platformFamily ~= #Windows ] > > > > which means that for Unix swapping is enabled (returns true). > > > > If I understand you correctly, however, for Unix it should be > > disabled. Is this correct? > > > > So the correct implementation would be to test for > > > > OSPlatform current platformFamily = #Mac (or similar) > > > > Adrian > > > > On Jun 7, 2009, at 19:08 , Mariano Martinez Peck wrote: > > > > > Hi folks: I had an Pharo 10318 and then updat to 10328 in Linux and > > > swapMouseButtons seems to be wrong. For the "right button" I have to > > > press > > > the mouse wheel button. I tried this things: > > > > > > Preferences setPreference: #swapMouseButtons toValue: true. > > > Preferences setPreference: #swapMouseButtons toValue: false. > > > Preferences enable: #swapMouseButtons. > > > Preferences disable: #swapMouseButtons. > > > InputSensor swapMouseButtons: false. > > > InputSensor swapMouseButtons: true. > > > > > > No one do nothing. > > > > > > I saw http://code.google.com/p/pharo/issues/detail?id=838 and seems > > > to be > > > changed in 10319 > > > > > > However, this is not working well in Linux. What I had to do to make > > > it work > > > is this: > > > > > > Rewrite Preferences>>swapMouseButtons to this: > > > > > > swapMouseButtons > > > ^ self > > > valueOfFlag: #swapMouseButtons > > > ifAbsent: [self break. > > > OSPlatform current platformFamily = #Windows > > > ifTrue: [false]. > > > OSPlatform current platformFamily = #Unix > > > ifTrue: [false] ] > > > > > > > > > And then do: > > > > > > InputEventSensor swapMouseButtons: false > > > > > > In addition 10324 dev seems to work ok for me out of the box. Can > > be a > > > problem of updating from an older version ? > > > > > > What can be the problem? > > > > > > Thanks > > > > > > Mariano > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009

Re: [Pharo-project] About super initialize

by Mariano Martinez Peck

> Still I have the impression that for direct subclasses of Object super > initialize is unnecessary > +1 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009

Re: [Pharo-project] Syntax error loading Coral

by Mariano Martinez Peck

pharo scripts to rename iPhoto pictures??? On Mon, Jun 8, 2009 at 5:48 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > > Hi all, > > > > I tried to load Coral in the latest dev image using ScriptLoader > > and I got a syntax error in > > "UnixProcess>>argsAsFlatArrayAndOffsets:". I guess it is an UTF-8 > > problem. > > Any ideas for a solution ? > > Not right on top of my head but this is cool that you tried it. I > want to write pharo scripts > to rename my iPhoto pictures and lot more. > > > > > #Luc > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 9, 2009

[Pharo-project] BookMorph removal slice

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > Now I would do the following: > remove > BookMorph > SLICE-BookMorphRemoval-alain_plantec.1 is in PharoInbox alain

June 8, 2009

Re: [Pharo-project] New Extensible Inspector for Pharo-Core

by Frederic Pluquet

I also added a new child "Submorphs" for any instance of Morph (and subclasses) to inspect directly (and more easily) them. FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet On Mon, Jun 8, 2009 at 11:15 PM, Frederic Pluquet <fpluquet(a)ulb.ac.be>wrote: > > - get the view inpesctor (flash behavior) >> > >> > I don't understand what it means. >> >> you select in your tree an object bring a menu and click flash and >> oops you see you widgets flashing. >> Check the viewExplorer... sent in the list by "steven wirts" > > > It is done in the last published version of NewInspector :) A new menu item > "Flash" appears for Morph instances (Cmd-f works also). > > FrÃ©d >

June 8, 2009