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

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

by StÃ©phane Ducasse

Ok I will integrate it. Alain dont worry too much we do not do omelette without breaking eggs. and deprecate is the right pattern here. Stef On Jun 8, 2009, at 9:53 PM, Alain Plantec wrote: > Oscar Nierstrasz a Ã©crit : >> I don't know what you mean by the "what to show" button > it is the title of the dialog which is opened when you hit the right > most button of the browser button bar. >> , 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 verified and yes, it is broken and this is my fault because > I removed Compiler>>format:in:notifying:contentsSymbol: > which is called by OBCmdMultiView>>togglePrettyPrint. > I've attached a changed set which is fixing it (it reintroduces it > as a deprecated method). > sorry :( > Hope it is ok now. > > Cheers > Alain > > 'From Pharo0.1 of 16 May 2008 [Latest update: #10330] on 8 June 2009 > at 9:51:07 pm'! > > !Compiler methodsFor: 'public access' stamp: 'alain.plantec 6/8/2009 > 21:50'! > format: textOrStream in: aClass notifying: aRequestor > contentsSymbol: aSymbol > "Compile a parse tree from the argument, textOrStream. > Answer a string containing the original code, formatted nicely." > > self deprecated: #colorWhenPrettyPrintingAsBeenRemoved. > ^ self format: textOrStream in: aClass notifying: aRequestor > ! ! > > > !Compiler class methodsFor: 'evaluating' stamp: 'alain.plantec > 6/8/2009 21:50'! > format: textOrStream in: aClass notifying: aRequestor > contentsSymbol: aSymbol > ^ self new format: textOrStream in: aClass notifying: aRequestor > contentsSymbol: aSymbol > ! ! > > _______________________________________________ > 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] New Extensible Inspector for Pharo-Core

by Frederic Pluquet

Hello, I worked on a new extensible inspector for Pharo (written without OB and so usable directly in Pharo-Core). This tool is based on a tree view of objects in which children can be dynamically extended by simple message overriding. Actions per object menu can be also defined dynamically. A definition panel shows a description of the selected object in the tree. A bottom right pane permits to evaluate some code (in which self is bound to the selected object in the tree). You can load the code from SqueakSource (NewInspector project). See the class extensions (CompiledMethod, OrderedCollection, Set, Dictionary for the moment) to know how to incorporable your needs. It is a stable but very young version (I started to code yesterday evening ;)). Any feedback is welcome :) FrÃ©d ---- FrÃ©dÃ©ric Pluquet UniversitÃ© Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet

June 8, 2009

Re: [Pharo-project] About super initialize

by Alain Plantec

Damien Cassou a Ã©crit : > 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? > Hi Damien, my opinion is that such a situation reveals a design problem which should be fixed. but it is only my opinion. Cheers alain

June 8, 2009

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

by Alain Plantec

Oscar Nierstrasz a Ã©crit : > I don't know what you mean by the "what to show" button it is the title of the dialog which is opened when you hit the right most button of the browser button bar. > , 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 verified and yes, it is broken and this is my fault because I removed Compiler>>format:in:notifying:contentsSymbol: which is called by OBCmdMultiView>>togglePrettyPrint. I've attached a changed set which is fixing it (it reintroduces it as a deprecated method). sorry :( Hope it is ok now. Cheers Alain

June 8, 2009

[Pharo-project] Syntax error loading Coral

by Luc Fabresse

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 ? #Luc

June 8, 2009

Re: [Pharo-project] Graphs Javascript

by Mariano Martinez Peck

Yes. I noticed that. I didn't understand a single word haha On Mon, Jun 8, 2009 at 6:36 PM, Francois Stephany <tulipe.moutarde(a)gmail.com > wrote: > 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 > > > > > _______________________________________________ > 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 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