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

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