June 2009 - Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Streams - #nextLine

by Damien Cassou

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. -- 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

Re: [Pharo-project] About super initialize

by Mariano Martinez Peck

On Mon, Jun 8, 2009 at 3:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > 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 don'' understand why. If ProtoObject>>initialize is implemented like this: initialize "Subclasses should redefine this method to perform initializations on instance creation" why should direct subclasses of Object call super initialize? uniformity as you said ? > > 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 Nicolas Cellier

If ever you want to change these messages, please run some benchmark. 2009/6/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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

[Pharo-project] About super initialize

by StÃ©phane Ducasse

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

June 8, 2009