- Pharo-dev - lists.pharo.org

Re: [Pharo-project] CommandShell

by StÃ©phane Ducasse

I'm sure people can help if you need. On May 27, 2010, at 6:07 AM, David T. Lewis wrote: > On Sat, May 22, 2010 at 09:30:51AM +0200, laurent laffont wrote: >> Hi, >> >> I'm trying to load CommandShell into Pharo. >> >> I have the error: >> >> This package depends on the following classes: >> PluggableTextController >> PluggableTextView >> You must resolve these dependencies before you will be able to load these >> definitions: >> ShellWindowView >> ...... >> >> >> Do you know where I can find PluggableTextController and PluggableTextView >> ? Or maybe we can use other classes to make it compatible with Pharo > > Hi Laurent, > > Sorry for my late response, but the errors that you are encountering are > just missing MVC classes. CommandShell has both a Morphic and an MVC user > interface, but MVC has been removed from Pharo. I think that you can just > ignore the the errors, and the Morphic UI should still work properly. > > Yes I should split CommandShell into separate packages in Montecello > so you can just load what you want. But I have not done this yet for > CommandShell or OSProcess. > > Dave > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 27, 2010

Re: [Pharo-project] CommandShell

by David T. Lewis

On Sat, May 22, 2010 at 09:30:51AM +0200, laurent laffont wrote: > Hi, > > I'm trying to load CommandShell into Pharo. > > I have the error: > > This package depends on the following classes: > PluggableTextController > PluggableTextView > You must resolve these dependencies before you will be able to load these > definitions: > ShellWindowView > ...... > > > Do you know where I can find PluggableTextController and PluggableTextView > ? Or maybe we can use other classes to make it compatible with Pharo Hi Laurent, Sorry for my late response, but the errors that you are encountering are just missing MVC classes. CommandShell has both a Morphic and an MVC user interface, but MVC has been removed from Pharo. I think that you can just ignore the the errors, and the Morphic UI should still work properly. Yes I should split CommandShell into separate packages in Montecello so you can just load what you want. But I have not done this yet for CommandShell or OSProcess. Dave

May 27, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Levente Uzonyi

On Wed, 26 May 2010, Igor Stasenko wrote: > On 26 May 2010 22:18, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Wed, 26 May 2010, Igor Stasenko wrote: >> >>> On 26 May 2010 20:47, Levente Uzonyi <leves(a)elte.hu> wrote: >>>> >>>> On Wed, 26 May 2010, Lukas Renggli wrote: >>>> >>>>>>> - The exact semantics of #and:and:and: is not clear without knowing >>>>>>> how it is implemented. >>>>>>> >>>>>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>>>> conditions have side-effects. >>>>>> >>>>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>>>> short-circuit, so they'll cause exactly the same side effects. >>>>> >>>>> I know that and this is *not* what I am talking about. What you point >>>>> out is already discussed above, it is absolutely unclear what >>>>> #and:and:and: does without looking at the implementation. >>>>> >>>>> The point is that blocks that are lexically nested "a and: [ b and: [ >>>>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>>>> c ]" do not have the same expressive power (temps, state) and do not >>>>> necessarily behave the same. >>>> >>>> Maybe i'm just narrow-minded, but I can't see the difference except for >>>> the >>>> scope of temporaries defined inside blocks. >>>> >>> >>> For pushing a closure on stack, an interpreter makes a copy of closure >>> literal, from method's literal frame. >>> For expressions like: >>> a and: [ b ] and: [ c ] >>> >>> it should prepare and push 2 closures. >>> >>> and for expression like: >>> >>> a and: [ b and: [ c ] ] >>> >>> just one. >>> So it is faster, for cases when outer block is not activated, because >>> a is false. >> >> I understand this. And I know that the current compiler will inline the >> blocks in the second case which gives the real difference in speed. >> >> What I don't understand is: how can these two expressions behave >> differently. Can you provide a, b and c which will behave differently if >> evaluated as: >> 1) a and: [ b ] and: [ c ] >> and >> 2) a and: [ b and: [ c ] ] >> ? >> > Trivial. I could implement own #and: method in my class. > And there's no way how #and:and: could provide similar behavior. Nice idea, but there's no a, b or c in it (which evaluate to a Boolean). Anyway if you implement a method named #and:, you won't be able to use it, since #and: is inlined. (Which means that it's like a keyword, you can't reuse it without changing the compiler. This is another reason why inlining more methods is a bad idea.) Levente > > >> >> Levente >> >>> >>>> >>>> Levente >>>> >>>>> >>>>> 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 >>>>> >>>> >>>> _______________________________________________ >>>> 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. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by csrabak＠bol.com.br

Em 26/05/2010 07:07, Henrik Johansen < henrik.s.johansen(a)veloxit.no > escreveu: > On May 26, 2010, at 11:58 51AM, StÃ©phane Ducasse wrote: > > > hi richard > > > >> WTF?! > > If you have a real argument we are really open to discussion. > > > >> These are the only reasons? I think that they are sufficient > +1 > > Because we could have and:or: or:and: and:and:or: and a couple of > others in that case. > No we could not :) Because of ambiguity: a and: (b or: c) is not > the same as (a and: b) or: c Henry, I disagree. Since to implement this in Smalltalk you'll need a specific method the ambiguity can be removed by specifying the API and using the appropriate implementation: Boolean>> and: x or: y ^(self and: x) or: y

May 26, 2010

Re: [Pharo-project] Gettext package in PharoNonCorePackages

by Mariano Martinez Peck

Thanks Hilaire. Do you think this should be added to PharoDev? Because most of PharoNonCorePackages do. Cheers Mariano On Wed, May 26, 2010 at 9:11 PM, Hilaire Fernandes < hilaire.fernandes(a)gmail.com> wrote: > I move the gettext package there, as it is the right place for long term > support for this package. > > Please, from now, commit any change there. > > http://www.squeaksource.com/PharoNonCorePackages > > Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 26, 2010

Re: [Pharo-project] About CodeMorph and Styler dependency

by StÃ©phane Ducasse

which one I could not find it? On May 25, 2010, at 2:22 PM, Fernando olivero wrote: > Oh! my mistake, sorry. > i will add the bug entry now. > > Fernando > > > On May 25, 2010, at 2:11 PM, StÃ©phane Ducasse wrote: > >> ok I forgot it. :( Please add a bug entry else we forgot. >> >> Stef >> >> On May 25, 2010, at 9:01 AM, Fernando olivero wrote: >> >>> Hi Stef, regarding some recent mails about CodeMorph and Shout dependency i don't know if you got this email. >>> But i've removed the dependency from Shout and Styler. >>> >>> I'm still thinking about using Lukas petit parser to do the styling, or separating the Shout package in two different packages. >>> One that deals with TextMorph and the other just for Styling text. >>> >>> Fernando >>> >>> >>> Begin forwarded message: >>> >>>> From: Fernando olivero <oliverof(a)lu.unisi.ch> >>>> Date: May 17, 2010 5:51:30 PM GMT+02:00 >>>> To: "Pharo-project(a)lists.gforge.inria.fr" <Pharo-project(a)lists.gforge.inria.fr> >>>> Subject: Re: [Pharo-project] TextEditor and NewTextMorph merges and fixes >>>> >>>> De nada ! >>>> >>>> Actually i just published another version of the CodeMorph. >>>> I found no need for subclassing CodeMorph, since the accepting behavior is on the announcements now, having specific ClassDescriptionMorph and MethodMorph wouldn't be beneficial. >>>> Also removed the dependency with the Shout ( and the styler). >>>> >>>> >>>> Name: Morphic-FernandoOlivero.589 >>>> Rethought the CodeMorph class hierarchy, removed the subclasses and added CodeMorph class methods for creating >>>> "MethodMorph" and "ClassDefinitionMorph" >>>> >>>> >>>> Fernando >>>> >>>> On May 17, 2010, at 3:35 PM, StÃ©phane Ducasse wrote: >>>> >>>>> Tx!!!! >>>>> Gaucho man >>>>> >>>>> On May 17, 2010, at 3:32 PM, Fernando olivero wrote: >>>>> >>>>>> Issue: 2375 >>>>>> >>>>>> Name: System-Text-FernandoOlivero.8 >>>>>> Author: FernandoOlivero >>>>>> Time: 17 May 2010, 3:22:14 pm >>>>>> >>>>>> >>>>>> >>>>>> ###################################### >>>>>> Issue: -- >>>>>> >>>>>> Name: Morphic-FernandoOlivero.588 >>>>>> Author: FernandoOlivero >>>>>> Time: 17 May 2010, 1:42:04 pm >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Mariano Abel Coca

They do not behave different. The problem is that you cannot assume that by just looking at the message send. They could behave different, they do not, but you don't know that until you look at the method implementation. You cannot assume that #and:and:and: will or wont evaluate the second block and then compare the results. In fact, it's almost suggested in the declaration that it will by hierarchically organizing the blocks in the same logical level. And that is a lack of expressiveness. For that, is preferred the second option. Besides, #and:and:and: implementation is horrible :) Cheers, Mariano. On Wed, May 26, 2010 at 4:18 PM, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 26 May 2010, Igor Stasenko wrote: > > On 26 May 2010 20:47, Levente Uzonyi <leves(a)elte.hu> wrote: >> >>> On Wed, 26 May 2010, Lukas Renggli wrote: >>> >>> - The exact semantics of #and:and:and: is not clear without knowing >>>>>> how it is implemented. >>>>>> >>>>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>>> conditions have side-effects. >>>>>> >>>>> >>>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>>> short-circuit, so they'll cause exactly the same side effects. >>>>> >>>> >>>> I know that and this is *not* what I am talking about. What you point >>>> out is already discussed above, it is absolutely unclear what >>>> #and:and:and: does without looking at the implementation. >>>> >>>> The point is that blocks that are lexically nested "a and: [ b and: [ >>>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>>> c ]" do not have the same expressive power (temps, state) and do not >>>> necessarily behave the same. >>>> >>> >>> Maybe i'm just narrow-minded, but I can't see the difference except for >>> the >>> scope of temporaries defined inside blocks. >>> >>> >> For pushing a closure on stack, an interpreter makes a copy of closure >> literal, from method's literal frame. >> For expressions like: >> a and: [ b ] and: [ c ] >> >> it should prepare and push 2 closures. >> >> and for expression like: >> >> a and: [ b and: [ c ] ] >> >> just one. >> So it is faster, for cases when outer block is not activated, because >> a is false. >> > > I understand this. And I know that the current compiler will inline the > blocks in the second case which gives the real difference in speed. > > What I don't understand is: how can these two expressions behave > differently. Can you provide a, b and c which will behave differently if > evaluated as: > 1) a and: [ b ] and: [ c ] > and > 2) a and: [ b and: [ c ] ] > ? > > > Levente > > > >> >>> Levente >>> >>> >>>> 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 >>>> >>>> >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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 >

May 26, 2010

[Pharo-project] [update 1.1] #11373

by stephane ducasse

11373 ----- - Issue2317: FasterGrayPNGs. Thanks Squeak/Henrik - Issue 2468: Better method trailer method creation. Part two. Thanks Igor - Issue2242: FormConversionGeneralization. Henrik - Better ScriptLoader comment to explain our process. - Issue 1377: Senders of and implementers of does not work when symbol selected. Thanks Guile. - Issue 2074: Creating classes with Strings as the key in Smalltalk. Thanks marcus. - Issue 2480: prepare deprecation of and:and: + deprecated and:and:and:and: Stef

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Igor Stasenko

On 26 May 2010 22:18, Levente Uzonyi <leves(a)elte.hu> wrote: > On Wed, 26 May 2010, Igor Stasenko wrote: > >> On 26 May 2010 20:47, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>> On Wed, 26 May 2010, Lukas Renggli wrote: >>> >>>>>> - The exact semantics of #and:and:and: is not clear without knowing >>>>>> how it is implemented. >>>>>> >>>>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>>> conditions have side-effects. >>>>> >>>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>>> short-circuit, so they'll cause exactly the same side effects. >>>> >>>> I know that and this is *not* what I am talking about. What you point >>>> out is already discussed above, it is absolutely unclear what >>>> #and:and:and: does without looking at the implementation. >>>> >>>> The point is that blocks that are lexically nested "a and: [ b and: [ >>>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>>> c ]" do not have the same expressive power (temps, state) and do not >>>> necessarily behave the same. >>> >>> Maybe i'm just narrow-minded, but I can't see the difference except for >>> the >>> scope of temporaries defined inside blocks. >>> >> >> For pushing a closure on stack, an interpreter makes a copy of closure >> literal, from method's literal frame. >> For expressions like: >> a and: [ b ] and: [ c ] >> >> it should prepare and push 2 closures. >> >> and for expression like: >> >> a and: [ b and: [ c ] ] >> >> just one. >> So it is faster, for cases when outer block is not activated, because >> a is false. > > I understand this. And I know that the current compiler will inline the > blocks in the second case which gives the real difference in speed. > > What I don't understand is: how can these two expressions behave > differently. Can you provide a, b and c which will behave differently if > evaluated as: > 1) a and: [ b ] and: [ c ] > and > 2) a and: [ b and: [ c ] ] > ? > Trivial. I could implement own #and: method in my class. And there's no way how #and:and: could provide similar behavior. > > Levente > >> >>> >>> Levente >>> >>>> >>>> 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 >>>> >>> >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 26, 2010

Re: [Pharo-project] #and:and:and: deprecated on 1.1, why?

by Levente Uzonyi

On Wed, 26 May 2010, Igor Stasenko wrote: > On 26 May 2010 20:47, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Wed, 26 May 2010, Lukas Renggli wrote: >> >>>>> - The exact semantics of #and:and:and: is not clear without knowing >>>>> how it is implemented. >>>>> >>>>> - There are subtle semantic differences between "a and: [ b ] and: [ c >>>>> ] and: [ d ]" and "a and: [ b and: [ c and: [ d ] ] ]" if the >>>>> conditions have side-effects. >>>> >>>> That's not true. Both #and: and #and:and:and: (and friends) are >>>> short-circuit, so they'll cause exactly the same side effects. >>> >>> I know that and this is *not* what I am talking about. What you point >>> out is already discussed above, it is absolutely unclear what >>> #and:and:and: does without looking at the implementation. >>> >>> The point is that blocks that are lexically nested "a and: [ b and: [ >>> c ] ]" and blocks that are in a lexical sequence "a and: [ b ] and: [ >>> c ]" do not have the same expressive power (temps, state) and do not >>> necessarily behave the same. >> >> Maybe i'm just narrow-minded, but I can't see the difference except for the >> scope of temporaries defined inside blocks. >> > > For pushing a closure on stack, an interpreter makes a copy of closure > literal, from method's literal frame. > For expressions like: > a and: [ b ] and: [ c ] > > it should prepare and push 2 closures. > > and for expression like: > > a and: [ b and: [ c ] ] > > just one. > So it is faster, for cases when outer block is not activated, because > a is false. I understand this. And I know that the current compiler will inline the blocks in the second case which gives the real difference in speed. What I don't understand is: how can these two expressions behave differently. Can you provide a, b and c which will behave differently if evaluated as: 1) a and: [ b ] and: [ c ] and 2) a and: [ b and: [ c ] ] ? Levente > >> >> Levente >> >>> >>> 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 >>> >> >> _______________________________________________ >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 26, 2010