October 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

by StÃ©phane Ducasse

Hi we should improve from that side, but unfortunately we do not have enough man power to build tool that could support it. Stef On Oct 11, 2010, at 1:28 PM, Johannes Rasche wrote: > Hi Folks, > > I just wanted to install my work on version 1.1 and was surprised > to discover changes which leave me alone to find out for myself how to change my code : > > WorldMenu (I wrote a subclass of PasteUpMorph) > NaturalLanguageTranslator (what is the "gettext package" mentioned in the class comment? - cannot find a menu to edit translations - hidden sowhere?) > > possibly more surprises to come .... > > some backwardcompatibilty support would have been nice > and > some examples > > But I like to point out as well, that Pharo is improving from release to release - thanks for that !!!! > > Thanks in advance > > > > > Johannes Rasche > Hagelberger Str. 56 > 10965 Berlin > > mail: johannesrasche(a)me.com > skype: johannesrasche > www: http://myNeat.de > fon: +49-30-7469 4425 (skypeIn) > fax: +49-30-315 66 821 > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Migration Manual for Pharo 1.1 ?

by Alain Plantec

Le 11/10/2010 13:27, Johannes Rasche a Ã©crit : > Hi Folks, > > I just wanted to install my work on version 1.1 and was surprised > to discover changes which leave me alone to find out for myself how to > change my code : > > WorldMenu (I wrote a subclass of PasteUpMorph) > NaturalLanguageTranslator (what is the "gettext package" mentioned in > the class comment? - cannot find a menu to edit translations - hidden > sowhere?) /Hi Johannes, arrrh, lack of man power... concerning the world menu, have a look at http://book.pharo-project.org/book/TipsAndTricks/WorldMenuRegistration then just ask more questions if you need, it will give us the opportunity to improve the documentation. Cheers Alain / > > possibly more surprises to come .... > > some backwardcompatibilty support would have been nice > and > some examples > > But I like to point out as well, that Pharo is improving from release > to release - thanks for that !!!! > > Thanks in advance > > > > > /Johannes Rasche/ > /Hagelberger Str. 56/ > /10965 Berlin/ > / > / > /mail: johannesrasche(a)me.com <mailto:johannesrasche@me.com>/ > /skype: johannesrasche/ > /www: http://myNeat.de/ > /fon: +49-30-7469 4425 (skypeIn)/ > /fax: +49-30-315 66 821/ > > > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 11, 2010

Re: [Pharo-project] Another finalization concern: error handling

by Igor Stasenko

On 11 October 2010 14:40, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hello, > > here a situation, with which we can deal in more safer manner: > > Suppose you have a weak registry, populated by different objects and > their executors. > > Now, when some of them died, a weak registry performs finalization. > > The potential danger is , that if there's an error triggered by some > executor(s), > then rest of executors will have no chance to run and will be > forgotten, causing memory leakage. > > What you think, should we handle this more graciously? > > (Consider a following meta-code) > > WeakRegistry>>finalizeValues > | executors | > Â executors := self gatherExecutorsToRun. > > Â executors do: [:ex | > Â Â [ ex finalize ] fork. > Â ]. > oh, and this gets even more complicated, if we keep supporting multiple finalizers per single object. :) executors do: [:ex | ex hasMultipleExecutors ifTrue: [ ex do: [ :eex | [ eex finalize ] fork ] ] ifFalse: [ [ ex finalize ] fork ]. > in this way, if any executor's #finalize causing error, it won't > interfere with other executors, and they will accomplish their task > normally. > Of course, i'm not saying that we should use #fork for this, because > it is costly. Similar could be done w/o forking. > I just wanted to show a simplest code with which we could achieve a > more gracious error handling. > > P.S. of course, in a first place it would be good to make sure that we > writing executors, which can't cause an error during finalization. > But bad things happen, and we should make sure that rest of system > won't be put on its knees because of some stupid bug in a single > #finalize. > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 11 October 2010 14:28, Lukas Renggli <renggli(a)gmail.com> wrote: >> Object>>value >> Â Â Â Â ^self >> >> What actually shown here is a use of duck typing, because any object, >> which implemets #value, could be safely passed >> as argument to #ifTrue:ifFalse: message. >> It is well consistent with language design. > > Magritte implemented Symbol>>#value: for a while before any Smalltalk > had this is their standard library. I must admit that I liked it in > the beginning, but in the long run I realized that ... > > 1. It is not easily understandable for newbies. > 2. It quickly leads to very unreadable, hard to understand and hard to > refactor code. > 3. It is very limiting in itself and quickly leads to other hacks > (like to replace sort blocks). > 4. #value and friends should be only understood by objects that can be > evaluated (certainly not by Object). A symbol (name) by itself cannot > be evaluated. > > I eventually removed Symbol>>#value: for good. Re-occuring questions > in the mailing list disappeared. > > Therefor I strongly suggest to remove #value, #value:, and friends > from all objects that are not self-evaluable. BlockClosure and > MessageSend are self-evaluable. Only there it makes sense. > > If people are too lazy to create a block where something > self-evaluable is needed they should use a programming language > designed for cryptic code. Creating a block closure in Smalltalk is > concise and makes clear what happens easily. A symbol does not, you > need to exactly understand how this dispatches with various objects. > In short: i'm not sharing your concerns about #value, but sharing about #value: because to understand what happens in following: result := foo bar ifTrue: x ifFalse: y. is much easier than in following: self perform: (object ifNil: #foo ifNotNil: #bar) :) > Lukas > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

[Pharo-project] Another finalization concern: error handling

by Igor Stasenko

Hello, here a situation, with which we can deal in more safer manner: Suppose you have a weak registry, populated by different objects and their executors. Now, when some of them died, a weak registry performs finalization. The potential danger is , that if there's an error triggered by some executor(s), then rest of executors will have no chance to run and will be forgotten, causing memory leakage. What you think, should we handle this more graciously? (Consider a following meta-code) WeakRegistry>>finalizeValues | executors | executors := self gatherExecutorsToRun. executors do: [:ex | [ ex finalize ] fork. ]. in this way, if any executor's #finalize causing error, it won't interfere with other executors, and they will accomplish their task normally. Of course, i'm not saying that we should use #fork for this, because it is costly. Similar could be done w/o forking. I just wanted to show a simplest code with which we could achieve a more gracious error handling. P.S. of course, in a first place it would be good to make sure that we writing executors, which can't cause an error during finalization. But bad things happen, and we should make sure that rest of system won't be put on its knees because of some stupid bug in a single #finalize. -- Best regards, Igor Stasenko AKA sig.

Oct. 11, 2010

Re: [Pharo-project] another little OB "bug"

by Lukas Renggli

>> Â Name: OB-Morphic-lr.149 >> Â Author: lr >> Â Time: 11 October 2010, 10:17:53 am >> Â UUID: 285339d9-f9da-4c6d-98b9-e09ea154c91e >> Â Ancestors: OB-Morphic-lr.148 >> >> Â - more efficient fix for list updating >> >> I try to remember the current scroll position before updating any OB >> list, so I guess this works around the problem (indeed the UI feels >> better after the change). > > Indeed, it works perfect :) Thanks lukas Well, I noticed a first problem: Going to a different category/class/protocol leaves the selector list scrolled to the bottom (if there is no default selection). Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

Re: [Pharo-project] Compiler pedantic about ifNotNil: argument

by Lukas Renggli

> Object>>value > Â Â Â Â ^self > > What actually shown here is a use of duck typing, because any object, > which implemets #value, could be safely passed > as argument to #ifTrue:ifFalse: message. > It is well consistent with language design. Magritte implemented Symbol>>#value: for a while before any Smalltalk had this is their standard library. I must admit that I liked it in the beginning, but in the long run I realized that ... 1. It is not easily understandable for newbies. 2. It quickly leads to very unreadable, hard to understand and hard to refactor code. 3. It is very limiting in itself and quickly leads to other hacks (like to replace sort blocks). 4. #value and friends should be only understood by objects that can be evaluated (certainly not by Object). A symbol (name) by itself cannot be evaluated. I eventually removed Symbol>>#value: for good. Re-occuring questions in the mailing list disappeared. Therefor I strongly suggest to remove #value, #value:, and friends from all objects that are not self-evaluable. BlockClosure and MessageSend are self-evaluable. Only there it makes sense. If people are too lazy to create a block where something self-evaluable is needed they should use a programming language designed for cryptic code. Creating a block closure in Smalltalk is concise and makes clear what happens easily. A symbol does not, you need to exactly understand how this dispatches with various objects. Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

[Pharo-project] Migration Manual for Pharo 1.1 ?

by Johannes Rasche

Hi Folks, I just wanted to install my work on version 1.1 and was surprised to discover changes which leave me alone to find out for myself how to change my code : WorldMenu (I wrote a subclass of PasteUpMorph) NaturalLanguageTranslator (what is the "gettext package" mentioned in the class comment? - cannot find a menu to edit translations - hidden sowhere?) possibly more surprises to come .... some backwardcompatibilty support would have been nice and some examples But I like to point out as well, that Pharo is improving from release to release - thanks for that !!!! Thanks in advance Johannes Rasche Hagelberger Str. 56 10965 Berlin mail: johannesrasche(a)me.com skype: johannesrasche www: http://myNeat.de fon: +49-30-7469 4425 (skypeIn) fax: +49-30-315 66 821

Oct. 11, 2010

Re: [Pharo-project] [squeak-dev] Xtreams : first embryonary port on Squeak

by Julian Fitzell

This still seems confusing. Could we just have a new SqueakSource project called "Xtreams" (small T + an S)? It's not like projects are expensive to create... Julian On Sat, Oct 9, 2010 at 11:33 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > So, I started a quick port of VW Xtreams to Squeak this evening. > Only the Xtreams-Core and the trivial Xtreams-Terminals (no > file/pipe/socket/pointer). > You'll find code at http://www.squeaksource.com/XTream. > My previous experimental Xtream project has been renamed SqueaXTream > to reduce confusion, but still sits in the same project. > Please find my report below.

Oct. 11, 2010

Re: [Pharo-project] Adding a new font in System like DejaVu fonts

by Henrik Johansen

On Oct 10, 2010, at 12:49 40PM, nullPointer wrote: > > Now I know is possible add a new font, for use cross platform like DejaVu. I > know Juan Vuletich did that but I donÂ´t know found the place of that is > explained. Is heard do that? Whuups, might've sent you in a wild goose chase, sorry :/ Was thinking of http://forum.world.st/DemoMode-should-not-change-Fonts-only-sizes-td2538706… , which I interpreted as linking to a description of how he builds the font source. Clearly that only includes the end result ready for import. Anyways, as can be seen from the AAFonts.zip, you basically need a bmp with the font glyphs, as well as a text file containing offsets for each character. You could achieve that through printscreen and manual creation of offsets txt, or using a more automated tool similar to f.ex. http://www.angelcode.com/products/bmfont/ . CC'ing Juan in case he has time to comment on what his process is specifically. > takes very space of image when the font is > added? About as much space as the bmp's, ie depends on what sizes you want to include. Cheers, Henry

Oct. 11, 2010