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

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by StÃ©phane Ducasse

> > > Stef and I worked on an implementation a few years ago. > http://www.squeaksource.com/Namespace.html And it is a bad one :) Now we are working on making the system environment-aware so that we can browse part of the system, (remotely too with you). Stef > > Cheers, > Alexandre > > > On 11 Oct 2010, at 07:53, Nick Papoylias wrote: > >> Hallo to all, >> >> I am starting my Ph.D on 'languages and environments for autonomous robotics' -- and pharo will be a huge part of it. >> >> I am currently playing around with the system (to get the feel of it..) and testing it's programming tools in the context of >> different namespaces / environments. >> >> Specifically I am trying to find out what the implications of having a remote environment over rST for e.g (to browse, debug e.t.c). >> >> Any pointers to related work, suggestions e.t.c are welcomed. >> >> So my question: >> >> Is anybody currently working on integrating namespaces in the system level ? I may have one or two questions and suggestions to make. >> >> Thank you very much ! >> >> Nick Papoulias >> >> _______________________________________________ >> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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

[Pharo-project] [update 1.2] #12189

by StÃ©phane Ducasse

12189 ----- - Issue 2883: Anymorphic Style. Thanks Anymorphic and Nicolas Paez. - Issue 2979: Controlling UI feedback. BlockClosure>>silentlyValue

Oct. 11, 2010

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

by Lukas Renggli

>> Â Filename: Â Â Â Magritte-All-lr.185.mcz >> Â Author: Â Â Â Â Â Â Â Â Lukas Renggli >> Â Timestamp: Â Â 19 January 2007 2:25:14 pm >> Â UUID: Â Â Â Â Â e26ba5b5-15b0-4128-9839-1536359b89f0 >> Â Ancestors: Â Â Magritte-All-lr.184.mcz >> >> Â - removed #value: and #value:value: from Symbol (this is now in 3.9 >> and not really cool) >> Â - changed all (or most) references to these methods > > I'm not questioning that you added it to Magritte before 3.9 picked it up. I > just didn't understand how could the re-occuring questions disappear, > because Symbol >> #value: was still in the system. But I guess people > didn't understand the code which used this feature. I was referring to the magritte mailing-list, check the archive. Lukas > > > Levente > >> >> -- >> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by Simon Denier

On 11 oct. 2010, at 15:17, Igor Stasenko wrote: > Also, i remember someone presented the namespaces implementation > during last ESUG conference. Its fresh, and probably will run on pharo. > But i don't remember who did this. Here you go, it's a GSOC project, video included: Begin forwarded message: > From: James Foster <Smalltalk(a)JGFoster.net> > Date: 24 septembre 2010 00:09:39 HAEC > To: Pharo-project(a)lists.gforge.inria.fr, ESUG Mailing list <esug-list(a)lists.esug.org> > Subject: [Pharo-project] GSoC Project for Namespaces > Reply-To: Pharo-project(a)lists.gforge.inria.fr > > GermÃ¡n Leiva was accepted in Google Summer of Code 2010 and developed a Namespaces implementation for Pharo Smalltalk. A video at http://www.youtube.com/watch?v=n4I7fSVNX2A is based on his presentation at ESUG in Barcelona last week. You can get the code at http://www.squeaksource.com/Environments.html. > > James Foster > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by Igor Stasenko

Also, i remember someone presented the namespaces implementation during last ESUG conference. Its fresh, and probably will run on pharo. But i don't remember who did this. On 11 October 2010 16:10, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Hi Nick, > > Stef and I worked on an implementation a few years ago. > http://www.squeaksource.com/Namespace.html > > Cheers, > Alexandre > > > On 11 Oct 2010, at 07:53, Nick Papoylias wrote: > >> Hallo to all, >> >> I am starting my Ph.D on 'languages and environments for autonomous robotics' -- and pharo will be a huge part of it. >> >> I am currently playing around with the system (to get the feel of it..) and testing it's programming tools in the context of >> different namespaces / environments. >> >> Specifically I am trying to find out what the implications of having a remote environment over rST for e.g (to browse, debug e.t.c). >> >> Any pointers to related work, suggestions e.t.c are welcomed. >> >> So my question: >> >> Is anybody currently working on integrating namespaces in the system level ? I may have one or two questions and suggestions to make. >> >> Thank you very much ! >> >> Nick Papoulias >> >> _______________________________________________ >> 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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

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

by Levente Uzonyi

On Mon, 11 Oct 2010, Lukas Renggli wrote: >>> I eventually removed Symbol>>#value: for good. Re-occuring questions >>> in the mailing list disappeared. >> >> That's strange, because Symbol >> #value: was added to Squeak in 2006 during >> the developement of 3.9. > > Why? > > Filename: Magritte-All-lr.185.mcz > Author: Lukas Renggli > Timestamp: 19 January 2007 2:25:14 pm > UUID: e26ba5b5-15b0-4128-9839-1536359b89f0 > Ancestors: Magritte-All-lr.184.mcz > > - removed #value: and #value:value: from Symbol (this is now in 3.9 > and not really cool) > - changed all (or most) references to these methods I'm not questioning that you added it to Magritte before 3.9 picked it up. I just didn't understand how could the re-occuring questions disappear, because Symbol >> #value: was still in the system. But I guess people didn't understand the code which used this feature. Levente > > -- > 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 >

Oct. 11, 2010

Re: [Pharo-project] Hallo Pharoers.. namespaces in the system level ?

by Alexandre Bergel

Hi Nick, Stef and I worked on an implementation a few years ago. http://www.squeaksource.com/Namespace.html Cheers, Alexandre On 11 Oct 2010, at 07:53, Nick Papoylias wrote: > Hallo to all, > > I am starting my Ph.D on 'languages and environments for autonomous robotics' -- and pharo will be a huge part of it. > > I am currently playing around with the system (to get the feel of it..) and testing it's programming tools in the context of > different namespaces / environments. > > Specifically I am trying to find out what the implications of having a remote environment over rST for e.g (to browse, debug e.t.c). > > Any pointers to related work, suggestions e.t.c are welcomed. > > So my question: > > Is anybody currently working on integrating namespaces in the system level ? I may have one or two questions and suggestions to make. > > Thank you very much ! > > Nick Papoulias > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 11, 2010

Re: [Pharo-project] MicroSqueak [was System Tracer]

by Noury Bouraqadi

Thanks indeed to John and to you Eliot. Noury On 9 oct. 2010, at 03:48, Eliot Miranda wrote: > Hi All, > > I'm please to let you know that John Maloney has published his MicroSqueak code on his website under the MIT license. http://web.media.mit.edu/~jmaloney/microsqueak/ > Apologies for the premature posting. We can get down to business now. Again huge thanks to John for this code. > > On Thu, Oct 7, 2010 at 10:26 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > > turns out John does not want this code released, so please can you destroy any and all copies? Also, who do I have to talk to to get the archive message, with attachments, destroyed? > > Apologies to all, I've f***ed up badly here. > > Eliot > > > On Wed, Oct 6, 2010 at 4:22 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > FInd attached. You want MicroSqueak-colonequal.st and the various MSqueak-.st files. This produces a 57k image. John's also given me a 2.0 development image which will run on a 3.8 VM. Let me know if you want that. For me this is a proof of concept. What's needed is to define a headless core that contains the compiler, good error reporting to standard out, the core collection and numeric libraries and file support. Then we try and load packages into it and build up a headful image. > > On Wed, Oct 6, 2010 at 3:03 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Oct 6, 2010, at 7:18 PM, Eliot Miranda wrote: > > > > > > > On Wed, Oct 6, 2010 at 7:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > generate a new image. > > > > But that's not what it does. > > Yes I know gnerates = clone in my mail. > > > t merely clones an image, which is a long way form building an image form source. *That*'s a useful project. John Maloney's lovely MicroSqueak is a good starting point for ideas (basically have a copy of a kernel subset of the system in a namespace and generate a fresh image from that). > > Do you have a pointer on the code of john. We are looking at bootstrap code right now. > > > > > On Oct 6, 2010, at 2:23 PM, Alexandre Bergel wrote: > > > > > Hi! > > > > > > What do you want to achieve? > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 6 Oct 2010, at 05:36, Gabriel HernÃ¡n Barbuto wrote: > > > > > >> Hi > > >> > > >> Does anyone know where I can find the system tracer that is currently > > >> in use in Pharo? > > >> > > >> Bests > > >> Gabriel > > >> > > >> _______________________________________________ > > >> 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 > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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

Oct. 11, 2010

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

by Lukas Renggli

>> I eventually removed Symbol>>#value: for good. Re-occuring questions >> in the mailing list disappeared. > > That's strange, because Symbol >> #value: was added to Squeak in 2006 during > the developement of 3.9. Why? Filename: Magritte-All-lr.185.mcz Author: Lukas Renggli Timestamp: 19 January 2007 2:25:14 pm UUID: e26ba5b5-15b0-4128-9839-1536359b89f0 Ancestors: Magritte-All-lr.184.mcz - removed #value: and #value:value: from Symbol (this is now in 3.9 and not really cool) - changed all (or most) references to these methods -- Lukas Renggli www.lukas-renggli.ch

Oct. 11, 2010

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

by Levente Uzonyi

On Mon, 11 Oct 2010, Lukas Renggli 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. That's true. > 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). That "hack" is really cool IMO. The code is easily understood by anyone: #(4 1 3 5 2) sort: #<=. > 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. That's strange, because Symbol >> #value: was added to Squeak in 2006 during the developement of 3.9. Levente > > 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 > > _______________________________________________ > 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 Mariano Martinez Peck

2010/10/11 Johannes Rasche <johannesrasche(a)mac.com> > 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?) > > http://book.pharo-project.org/book/Localisation/ > 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] [squeak-dev] Re: WeakRegistry>>remove: - when you'll be in trouble

by Schwab,Wilhelm K

Dave, Since when? Even if operating systems started universally covering for such mistakes, I still would not recommend testing them on it. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of David T. Lewis [lewis(a)mail.msen.com] Sent: Sunday, October 10, 2010 9:54 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Re: WeakRegistry>>remove: - when you'll be in trouble On Sun, Oct 10, 2010 at 08:16:57PM -0400, Schwab,Wilhelm K wrote: > <snip> > The creation of the redundant executors is a recipe for for a double free and resulting crash. <snip> > Am I missing something? There is no such thing as a "double free and resulting crash". Dave _______________________________________________ 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] Compiler pedantic about ifNotNil: argument

by Igor Stasenko

On 11 October 2010 15:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> Now to me this looks like a hack and again it works because now Symbol are valuable objects. >>> Too many hacks will only make the system more hackish. >>> And especially the >>> Â Â Â Â iftrue: 'foo' ifFalse: 'zork' >>> >> >> This is not a hack, because if you refer to implementation: >> >> True>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock >> Â Â Â ^trueAlternativeBlock value >> >> False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock >> Â Â Â ^falseAlternativeBlock value >> >> so, it answers either 'foo' value , or 'zork' value. >> And #value could be sent to any object in system: >> >> 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. > > I know well that. and it sucks from a language semantics point of view. > I agree with the mail of lukas. > Okay, your obscurity barrier is higher than mine, and mine is higher than VW's, Nicolas and Levente's one :) > Stef > _______________________________________________ > 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

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

by StÃ©phane Ducasse

On Oct 11, 2010, at 1:28 PM, Lukas Renggli 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. + 200 > 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. This is exactly my point. Especially for system API like ifNotNil: When I read self bar: #zook I just know ok we are just passing a symbol as argument. I do not have to rely on the semantics of bar: so this is the only conclusion I can draw. Now I do not want to force people to have to understand the semantics of each single selector. In addition, it breaks nice rule such as use [ ] for any place where you do not know if the code will be executed. Simple nice and beautiful. [..]s delay execution and let the guy control it. Stef

Oct. 11, 2010

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

by StÃ©phane Ducasse

>> >> >> Now to me this looks like a hack and again it works because now Symbol are valuable objects. >> Too many hacks will only make the system more hackish. >> And especially the >> iftrue: 'foo' ifFalse: 'zork' >> > > This is not a hack, because if you refer to implementation: > > True>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock > ^trueAlternativeBlock value > > False>>ifTrue: trueAlternativeBlock ifFalse: falseAlternativeBlock > ^falseAlternativeBlock value > > so, it answers either 'foo' value , or 'zork' value. > And #value could be sent to any object in system: > > 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. I know well that. and it sucks from a language semantics point of view. I agree with the mail of lukas. Stef

Oct. 11, 2010

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