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

Re: [Pharo-project] About super initialize

by StÃ©phane Ducasse

Mine too. I have some serious doubt about the TTCompositeGlyph subclass of TGlyph when the initialize is not called. On Jun 8, 2009, at 10:08 PM, Alain Plantec wrote: > 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 > > > _______________________________________________ > 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] New Extensible Inspector for Pharo-Core

by Frederic Pluquet

Hello, > frederick what I would love to have is a > - merge between the explorer and the inspector This is, no ? :) > > - get the view inpesctor (flash behavior) I don't understand what it means. > > - get trippy like navigation (when you select an iv of an element > that you can go over all the elements looking only > at the iv you selected) You can select an object (an instVar value, a method, ... any item of the tree) and select "Add as root" in the contextual menu (or Cmd-a). You can also delete a root item (menu "Remove from roots" or Cmd-a). It is not exactly a trippy-like navigation, but you can inspect only some sub-objects if you want. > - see the morph in the pane when this is a morph :) > Good idea but it is no simple to implement (I want to work only with Pluggeable*Spec classes and no directly with Morphs). FrÃ©d

June 8, 2009

Re: [Pharo-project] About super initialize

by StÃ©phane Ducasse

> If ever you want to change these messages, please run some benchmark ok but when you have a class 4 level deep that has subclasses and an initialize and ... it means that when we will change its superclass Model we will get some bugs. 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

June 8, 2009

Re: [Pharo-project] About super initialize

by StÃ©phane Ducasse

On Jun 8, 2009, at 6:36 PM, Damien Cassou wrote: > 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? most of them predate the new/initialize patterns. on all the changes alain did I found so far only one mistake :) stef > > > -- > 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] Syntax error loading Coral

by StÃ©phane Ducasse

> 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

June 8, 2009

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

by StÃ©phane Ducasse

On Jun 8, 2009, at 9:32 PM, Nicolas Cellier wrote: > 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! no if we can learn something in the process discussion is always worth. > > However, my opinion has evolved closer to Andreas' one. this > > > 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). Yeap it does not scale well in complexity for something that should be quite simple: there is not element anymore. :) > > 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... sounds like a good compromise. > > > Of course, I must remind: use Exception handling pattern but don't > abuse. Programming with these deserve great care! > > Cheers > > Nicolas > > _______________________________________________ > 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] New Extensible Inspector for Pharo-Core

by StÃ©phane Ducasse

frederick what I would love to have is a - merge between the explorer and the inspector - get the view inpesctor (flash behavior) - get trippy like navigation (when you select an iv of an element that you can go over all the elements looking only at the iv you selected) - see the morph in the pane when this is a morph :) Stef On Jun 8, 2009, at 10:11 PM, Frederic Pluquet wrote: > 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 > _______________________________________________ > 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] Why TTComposite is a subclass of TTGlyph

by StÃ©phane Ducasse

This is why for this kind of changes 4 eyes are better than two :) Stef On Jun 8, 2009, at 10:28 PM, Alain Plantec wrote: > >> but in the subclass >> >> TTCompositeGlyph>>contours >> ^contours ifNil:[contours := self computeContours] >> >> >> so if we change the initialize of the subclass then the countours >> will >> be never computed.... >> > damn! >:o > ok, seen well > > > _______________________________________________ > 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 StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/list?thanks=870 oscar can you check the new update and let me know if this is working :) 10331 should fix that ;) Alain can you check and next time attach a cs or push it into the inbox else I have to retype or fix the bad characters :)

June 8, 2009

Re: [Pharo-project] Why TTComposite is a subclass of TTGlyph

by Alain Plantec

> but in the subclass > > TTCompositeGlyph>>contours > ^contours ifNil:[contours := self computeContours] > > > so if we change the initialize of the subclass then the countours will > be never computed.... > damn! >:o ok, seen well

June 8, 2009