- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Graphs Javascript

by Francois Stephany

Oops sorry, that email was not for the list Glad you find it interesting though :p Alexandre Bergel wrote: > Thanks, it looks interesting, indeed. > > Alexandre > > > On 6 Jun 2009, at 09:49, Francois Stephany wrote: > >> Ce truc pourrait t'intÃ©resser pour tracer tes arbres de gÃ©nÃ©alogie: >> >> http://thejit.org/ >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 8, 2009

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

by Nicolas Cellier

About this subject, here is a little reflexion explaining why Notification are not my preferred solution anymore (though I defended it at http://bugs.squeak.org/view.php?id=6755 ). If you remember animated discussions about EndOfStream, then you might say Oh no, not again! However, my opinion has evolved closer to Andreas' one. It still don't find == nil a good solution for generic Stream (though acceptable for character streams). Neither do I reject the idea of catching an EndOfStream : it can be efficient if the event is rare (in other words, if the stream is long, or if there are many wrappers, each testing == nil or atEnd). What I find a big mistake now is to generalize use of an Exception with a default action. I know, this default action is for backward compatibility (answer nil). But let's take an example showing how it can be bad: First load ConnectEndOfStream-M6755-nice.1.cs and RepeatUntil-M6755-nice.1.cs from http://bugs.squeak.org/view.php?id=6755 Then try this: | str sum buffer char | str := '123 456 798' readStream. sum := 0. buffer := WriteStream on: (String new: 16). [char := str next. char isSeparator ifTrue: [buffer isEmpty ifFalse: [sum := sum + buffer contents asNumber. buffer reset]] ifFalse: [buffer nextPut: char]] repeatUntil: EndOfStream. buffer isEmpty ifFalse: [sum := sum + buffer contents.]. ^sum Yes, it just split a string on separators, convert every packet into a number and sum the numbers. The example is silly, don't comment on that. There are plenty other ways to split a String. The problem is that the loop will stop after first number... What's going on? Well, asNumber uses a readStream to perform the conversion, reads past end, and signals an EndOfStream... That is bad... I should have protected the Exception handling with: | str sum buffer char | str := '123 456 798' readStream. sum := 0. buffer := WriteStream on: (String new: 16). [[char := str next. char isSeparator ifTrue: [buffer isEmpty ifFalse: [sum := sum + buffer contents asNumber. buffer reset]] ifFalse: [buffer nextPut: char]] repeat] on: EndOfStream do: [:exc | exc receiver == str ifTrue: [exc return] ifFalse: [exc pass]]. buffer isEmpty ifFalse: [sum := sum + buffer contents.]. ^sum Oh yes, easy. But imagine now that str is a wrapper on a FileStream... (for example an InflateStream). Exception handling soon becomes hard to write, because you might have to walk up the Context stack... 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. 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... Of course, I must remind: use Exception handling pattern but don't abuse. Programming with these deserve great care! Cheers Nicolas

June 8, 2009

Re: [Pharo-project] Streams - #nextLine

by Nicolas Cellier

2009/6/8 Damien Cassou <damien.cassou(a)gmail.com>: > On Mon, Jun 8, 2009 at 6:00 PM, Nicolas > Cellier<nicolas.cellier.aka.nice(a)gmail.com> wrote: >> 2009/6/8 Damien Cassou <damien.cassou(a)gmail.com>: >>> On Sun, Jun 7, 2009 at 2:15 AM, Nicolas >>> Cellier<nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>> Before adding a new set of messages, why not make the endOfStream pluggable? >>> >>> I'm not sure it will work because different methods will expect >>> different behavior. Thus these methods won't be able to communicate >>> with the same stream. >>> >> >> I see what you mean, Stream internally use endOfStream handling for >> implementing some of its protocol and must therefore know whether an >> endOfStream event will return nil or raise an Exception, is that it? > > Yes > > >> Messages that use construct like: >> [self atEnd] whileFalse: [...] >> should always work. > > Yes > >> Messages that use constructs like: >> [(char := stream next) ~~ nil] whileTrue: [...] >> could eventually be written: >> | oldEndOfStream | >> oldEndOfStream := endOfStream. >> [[(char := stream next) ~~ nil] whileTrue: [...]] >> ensure: [endOfStream := oldEndOfStream]. > > better: > > stream do: [:char | ...] > > which is a good refactoring in all cases, even without the proposed > changed I guess. > :) When I stay at the surface of existing code, you exercise your brain a bit deeper, and that's good. However, you also have to benchmark the different approaches on some critical kernel methods. I had animated discussions with Andreas on the subject! (see http://bugs.squeak.org/view.php?id=6755 ) Nicolas > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 8, 2009

Re: [Pharo-project] About super initialize

by Nicolas Cellier

2009/6/8 Christian Haider <Christian.Haider(a)smalltalked-visuals.com>: > I would get rid of these #initialize methods and use lazy initialization instead. > Simple redefinitions in subclasses, no worries. > > Cheers, > Christian > Using this pattern here and there is at an affordable cost. But generalizing it, you take the risk to multiply cost of every access to an inst var by a huge amount. That would deserve some bench too. Nicolas PS: I'd like to have time to spend thinking about a system that would dynamically change methodDictionary per instance based on previous execution results for such typical cases. >> -----UrsprÃ¼ngliche Nachricht----- >> Von: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] Im >> Auftrag von StÃ©phane Ducasse >> Gesendet: Montag, 8. Juni 2009 18:15 >> An: Pharo Development >> Betreff: [Pharo-project] About super initialize >> >> Hi >> >> in http://code.google.com/p/pharo/issues/detail?id=135 may be >> stupidly >> I was thinking that it would be nice to >> check all the initialize methods that are not doing a super >> call, and >> fix them. >> Alain did this crazy and boring tasks and I was reviewing his code. >> Now I was wondering if it makes sense to add super initialize to the >> direct subclasses of Object. >> I have the impression that it is good for uniformity but we are >> calling an empty so we could >> do the following only fix the caller that are not subclasses >> of Object. >> >> What is your point of view, >> >> stef >> >> >> _______________________________________________ >> 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 8, 2009

Re: [Pharo-project] About super initialize

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > Hi > > in http://code.google.com/p/pharo/issues/detail?id=135 may be stupidly > I was thinking that it would be nice to > check all the initialize methods that are not doing a super call, and > fix them. > Alain did this crazy yes! > and boring yes! :-D > tasks and I was reviewing his code. > Now I was wondering if it makes sense to add super initialize to the > direct subclasses of Object. > I have the impression that it is good for uniformity but we are > calling an empty so we could > do the following only fix the caller that are not subclasses of Object. > > What is your point of view, > mainly, good for uniformity alain > stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

June 8, 2009

Re: [Pharo-project] what happened to pretty-print?

by Oscar Nierstrasz

Hi Alain, I have the latest Pharo-dev image. pharo0.1-10324dev09.06.1 Pretty-print does not work. Normally I expect to action-click on a method and get the option "pretty print (r)". This is gone now. Enabling "browseWithPrettyPrint" does not change anything. Pasting copied code is always broken. I don't know what you mean by the "what to show" button, but if I select "view...>PrettyPrint", I get a "MessageNotUnderstood: Compiler class>>format:in:notifying:contentsSymbol:" error which seems to come from OBCmdMultiView>>togglePrettyPrint. Bleh. :-( Can anyone else verify this? I am using the Squeak 4.0.1beta1U.app VM under Mac OSX 10.5.7. - on On Jun 8, 2009, at 16:20, Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> If I remember we removed the coloring which was broken. >> >> Alain did we remove the pretty printing too? >> > no, it works well on my core image: > In a browser, choosing 'pretty print' in the "what to show" button > makes > the code pretty printed. > Code is always pretty printed if you check 'BrowseWithPrettyPrinting' > preference. > With pharo, shout-coloring is working. > Is it ok Oscar ? > > alain > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 8, 2009

Re: [Pharo-project] Graphs Javascript

by Alexandre Bergel

Thanks, it looks interesting, indeed. Alexandre On 6 Jun 2009, at 09:49, Francois Stephany wrote: > Ce truc pourrait t'intÃ©resser pour tracer tes arbres de gÃ©nÃ©alogie: > > http://thejit.org/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 8, 2009

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

by Mariano Martinez Peck

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 >

June 8, 2009

Re: [Pharo-project] About super initialize

by Christian Haider

I would get rid of these #initialize methods and use lazy initialization instead. Simple redefinitions in subclasses, no worries. Cheers, Christian > -----UrsprÃ¼ngliche Nachricht----- > Von: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] Im > Auftrag von StÃ©phane Ducasse > Gesendet: Montag, 8. Juni 2009 18:15 > An: Pharo Development > Betreff: [Pharo-project] About super initialize > > Hi > > in http://code.google.com/p/pharo/issues/detail?id=135 may be > stupidly > I was thinking that it would be nice to > check all the initialize methods that are not doing a super > call, and > fix them. > Alain did this crazy and boring tasks and I was reviewing his code. > Now I was wondering if it makes sense to add super initialize to the > direct subclasses of Object. > I have the impression that it is good for uniformity but we are > calling an empty so we could > do the following only fix the caller that are not subclasses > of Object. > > What is your point of view, > > stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

June 8, 2009

Re: [Pharo-project] About super initialize

by Damien Cassou

On Mon, Jun 8, 2009 at 6:13 PM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: > I was thinking that it would be nice to > check all the initialize methods that are not doing a super call, and > fix them. Are we sure that no #initialize method avoid calling super initialize on purpose? -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

June 8, 2009