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

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

by Alexandre Bergel

Hi Frederic, It looks really good. I tried to used it instead of the Explorer. Few comments: - Unfolding a branch that contains an element with a very very long printOn: seems to freeze the system. I got an error niDescription not found. - I spend a lot of time in unfolding branches to see field content. Maybe field values could be displayed without having to unfold ? Cheers, Alexandre On 8 Jun 2009, at 16:11, 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 9, 2009

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

by Schwab,Wilhelm K

Nicolas, You have some interesting observations re senders of #next: - fixing it is sounding like a good idea. Since you are not ready to take the plunge on #next, I will be forced to deprecate it for my own use and continue to use #nextOne, unless we take the pluggable exception route?? Stef, how should we proceed? I think this ultimately has to go to the board for a decision. For my part, I am happy to help, will gladly take advantage of whatever we fix, and will deprecate/add protocol to ensure correct behavior where we do not act. To summarize, the options appear to be: (1) add pluggable exceptions covering #next, #next:, etc.; any attempt to read off the end of a stream would invoke the set behavior, either an exception with teeth (no default action), or truncate/answer nil as appropriate. (2) Fix #next: on the grounds Nicolas has identified, specifically that many senders assume non-truncating behavior; #next would likely remain as-is. (3) Adopt Dolphin's behavior - I do not see us taking this branch, but list it for completeness. Either way, add #nextAvailable: - it is harmless to backward compatibility, so can go in in either case. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Tuesday, June 09, 2009 7:38 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] About EndOfStream notification [was Streams - #nextLine] 2009/6/9 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > Adding #nextAvailable: hurts nothing, but changing #next: (and #next too) will break existing code. Â In VW, it is only #next that has the silent failure trap, and while Cincom was willing to consider a change, they ultimately declined to make it. Â I am convinced that Dolphin gets it right, but I would be surprised to see us adopt its behavior. Â I would be thrilled if we did so, but doubt it will happen. Â Failing such breaking changes, I need to create a way to have my code work, which is why I started adding my own methods. > That's the price to pay, we have to break some #next: senders... Inside the image, we can fix it easily. Bt how many should we fix? I have 18 implementors (16 stream-like, 2 linked-list like) and 100 senders in core, but when looking at them, few are prepared to get a shorter collection than requested. For example, I read: (self next: 1) at: 1 or: header := strm next: 4. self nSamples: header first nLevels: header second. self setAlpha: header third beta: header fourth. IMO, the change you request is a must in a majority of cases... It's of course better to see an immediate EndOfStreamError rather than a delayed OutOfBoundError. For external packages, either the change is backported to other Squeak branches on a collaborative basis (preferred), or we'll have to maintain Pharo specific code on a competitive basis. Other squeak branches don't need to adopt our #next: behaviour, they just have to provide a #nextAvailable: hook for compatibility, so I don't think this is a real problem, especially if it enhances portability. For #next, I can understand VW declined: 1) they would have to change a bunch of senders 2) they have to guarantee a certain degree of portability to their clients, especially on such a heavily used kernel method. In Squeak code too, there are just too many senders of #next, the transition would be painfull without some backward compatibility. > Your pluggable exception/defaultAction idea is worth a shot. Â Some simple testing should show whether it can preserve current behavior and throw exceptions, respectively. Â I think I heard Stef as much as say he would support it if it does serve both masters. Â Stef? > > Bill > > Cost is small. Think of adding a Nile compatible hook too. > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > Nicolas Cellier > Sent: Tuesday, June 09, 2009 2:34 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] About EndOfStream notification [was > Streams - #nextLine] > > 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 >> > > _______________________________________________ > 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] Syntax error loading Coral

by Alexandre Bergel

As far as I am aware of, only a small experiment was realized in Bern. Oscar said he will allocate a student on it. Alexandre On 9 Jun 2009, at 08:35, Mariano Martinez Peck wrote: > > > 2009/6/9 Luc Fabresse <luc.fabresse(a)gmail.com> > 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. > > wow! Is somewhere documentation or information I can read about ? > > Thanks! > > Mariano > > > > > 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 > > > _______________________________________________ > 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 9, 2009

[Pharo-project] vm-maker

by danil osipchuk

Hello squeak people Does anyone have a hint how to get (with reasonable effort) current vmmaker setup? May be there is a prepared image somewhere? I'm interested in building vm on windows. When I follow these instructions: http://wiki.squeak.org/squeak/6102 i stuck during loading of vmmaker from the squeak-map regards, Danil

June 9, 2009

[Pharo-project] [ANN] Morph dirty methods rewrite

by Gabriel Cotelli

Name: Morphic-GabrielOmarCotelli.326 Author: GabrielOmarCotelli Time: 9 June 2009, 10:31:46 am UUID: dc1de612-41c5-b942-ac37-d4841ac4917d Ancestors: Morphic-GabrielOmarCotelli.325 Rewrite of: TransformMorph >> numberOfItemsPotentiallyInViewWith: PluggableListMorph >> numSelectionsInView WorldState class >> deferredExecutionTimeLimit WorldState >> runStepMethodsIn: Please review... Thanks, Gabriel

June 9, 2009

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

by Oscar Nierstrasz

I think I prefer to stick with the current pharo image. I posted this workaround on the issue page: - copy, paste and accept the ugly code - View...>PrettyPrint (click Proceed when it complains) - Copy the pretty-printed code - Paste it back into the source view and accept - on On Jun 9, 2009, at 14:25, Alain Plantec wrote: > Oscar, for the moment, maybe you can use 9.04.6 pharo version. >> Pasting code from an external editor is still broken. >> > this annoying problem will certainly be fixed when someone will have > enough time to work on it. > It is already reported as an issue: > http://code.google.com/p/pharo/issues/detail?id=823

June 9, 2009

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

by Alain Plantec

> With pharo0.1-10292dev09.04.6, with pharo0.1-10324dev09.06.1 > the pretty print entry of the code pane > menu is not present. > So I guess the lost of the code pane menu pretty print entry results from > some OB refactoring from 09.05.4 to 09.04.6. > to 09.06.1 of course > and yes, as it was for 9.04.6 and for 09.05.4 versions, you can't save > you pretty printed code when you format it > by the using of the view button. So, except for the deprecation warning, > It seems that the refactoring I made is not responsible for that problem. > > I've take a look at the 9.04.6 OB code but I'm completely lost and do > not have enough time for this. > David, do you have an idea of what happen ? > > Oscar, for the moment, maybe you can use 9.04.6 pharo version. >

June 9, 2009

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

by Nicolas Cellier

2009/6/9 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Nicolas, > > Adding #nextAvailable: hurts nothing, but changing #next: (and #next too) will break existing code. Â In VW, it is only #next that has the silent failure trap, and while Cincom was willing to consider a change, they ultimately declined to make it. Â I am convinced that Dolphin gets it right, but I would be surprised to see us adopt its behavior. Â I would be thrilled if we did so, but doubt it will happen. Â Failing such breaking changes, I need to create a way to have my code work, which is why I started adding my own methods. > That's the price to pay, we have to break some #next: senders... Inside the image, we can fix it easily. Bt how many should we fix? I have 18 implementors (16 stream-like, 2 linked-list like) and 100 senders in core, but when looking at them, few are prepared to get a shorter collection than requested. For example, I read: (self next: 1) at: 1 or: header := strm next: 4. self nSamples: header first nLevels: header second. self setAlpha: header third beta: header fourth. IMO, the change you request is a must in a majority of cases... It's of course better to see an immediate EndOfStreamError rather than a delayed OutOfBoundError. For external packages, either the change is backported to other Squeak branches on a collaborative basis (preferred), or we'll have to maintain Pharo specific code on a competitive basis. Other squeak branches don't need to adopt our #next: behaviour, they just have to provide a #nextAvailable: hook for compatibility, so I don't think this is a real problem, especially if it enhances portability. For #next, I can understand VW declined: 1) they would have to change a bunch of senders 2) they have to guarantee a certain degree of portability to their clients, especially on such a heavily used kernel method. In Squeak code too, there are just too many senders of #next, the transition would be painfull without some backward compatibility. > Your pluggable exception/defaultAction idea is worth a shot. Â Some simple testing should show whether it can preserve current behavior and throw exceptions, respectively. Â I think I heard Stef as much as say he would support it if it does serve both masters. Â Stef? > > Bill > > Cost is small. Think of adding a Nile compatible hook too. > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier > Sent: Tuesday, June 09, 2009 2:34 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] About EndOfStream notification [was Streams - #nextLine] > > 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 >> > > _______________________________________________ > 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] Syntax error loading Coral

by Mariano Martinez Peck

2009/6/9 Luc Fabresse <luc.fabresse(a)gmail.com> > 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. > wow! Is somewhere documentation or information I can read about ? Thanks! Mariano > > > >> >> 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 >> > > > _______________________________________________ > 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] what happened to pretty-print?

by Alain Plantec

Oscar Nierstrasz a Ã©crit : > OK, I updated pharo0.1-10324dev09.06.1 to 10331. (Or should I update > pharo-core?) > no, it should be ok if you update from pharo0.1-10324dev09.06.1 > Pretty-print is still missing when I right-click on the method source > pane. > see my comments below > View...>Pretty Print now generates the following error: > > "Compiler>>format:in:notifying:contentsSymbol: has been deprecated. > colorWhenPrettyPrintingAsBeenRemoved > Select Proceed to continue, or close this window to cancel the > operation." > ok, you see this warning because of the deprecation. you can check off the #showDeprecationWarning preference in order to avoid that. > If I select Proceed, it does pretty-print, but I cannot save the > pretty-printed version! > I have investigated it a little bit: With pharo0.1-10292dev09.04.6, we had the pretty print entry in the code pane menu and it was functional. With this menu you was able to pretty print and to save your code (so it was ok for you). But, even with 9.04.6 version, you was not able to save your pretty printed code when you choose 'pretty print' from the 'view' button of the top pane. With pharo0.1-10318dev09.05.4, I can't check the code pane menu because when I try to open it, it falls into an 'Invalid utf8 input detected' error. The impossibility to save pretty printed code formated with the help of the view button is still present. With pharo0.1-10292dev09.04.6, the pretty print entry of the code pane menu is not present. So I guess the lost of the code pane menu pretty print entry results from some OB refactoring from 09.05.4 to 09.04.6. and yes, as it was for 9.04.6 and for 09.05.4 versions, you can't save you pretty printed code when you format it by the using of the view button. So, except for the deprecation warning, It seems that the refactoring I made is not responsible for that problem. I've take a look at the 9.04.6 OB code but I'm completely lost and do not have enough time for this. David, do you have an idea of what happen ? Oscar, for the moment, maybe you can use 9.04.6 pharo version. > Pasting code from an external editor is still broken. > this annoying problem will certainly be fixed when someone will have enough time to work on it. It is already reported as an issue: http://code.google.com/p/pharo/issues/detail?id=823 Cheers Alain

June 9, 2009