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

[Pharo-project] Bug with Debug Test in OB: BlockCannotReturn

by Mariano Martinez Peck

Hi folks. I have the following issue: http://code.google.com/p/pharo/issues/detail?id=2485 Pharo image: Pharo-1.1-11367-Beta Pharo core version: 11367 Virtual machine used: Mac 2.4.2 Class browser used if applicable: OB Steps to reproduce: 1. Open a system browser 2. Select a class that has tests. Example ArrayLiteralTest. 3. Select any test method, like testByteArrayBase. 4. Right button, "debug test" 5. When the debugger raise, just click on Proceed There you will get a BlockCannotReturn: Block Cannot Return I attach PharoDebug.log in the issue tracker. Cheers Mariano <http://pharo.googlecode.com/issues/attachment?aid=4547915944036018779&name=…>

May 27, 2010

Re: [Pharo-project] difference between Sequenceable and Ordered

by Tristan Bourgois

Thanks, that's very interesting but not really help me sorry! Sorry may be the question are not very precise. My question is about the behavior so I put it in the context: I refactoring the collection in trait and I search if there are a difference between a Sequenceable and Ordered behavior. Because if there are not difference I don't create trait for the Ordered behavior. So do you think there are difference between the two behavior? -- View this message in context: http://forum.world.st/difference-between-Sequenceable-and-Ordered-tp2231718… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 27, 2010

Re: [Pharo-project] plan for 1.1

by StÃ©phane Ducasse

Torsten can you give a try to see if it fixes your problems with the latest cs? Apparently Torch is ok now. Stef On May 26, 2010, at 4:05 PM, StÃ©phane Ducasse wrote: >> Stef wrote >>> I found the traits bug :) >> >> OK, can we expect a fix in the next update (11373?). > > yes of course I was exhausted and had to sleep. > http://code.google.com/p/pharo/issues/detail?id=2477

May 27, 2010

[Pharo-project] Integrating VMMaker-dtl.175

by Igor Stasenko

Dear all, i would really like to finish an integration of new finalization. But this requires releasing a new VMs for all platforms. If you think, we're done with VM-side part, then lets proceed with releasing new VMs, so we could start using new feature. -- Best regards, Igor Stasenko AKA sig.

May 27, 2010

[Pharo-project] [ANN] Dan Ingalls at HPI (Fwd: Einladung zum HPI-Kolloquium am 03.06.10, 16:00 Uhr, HS 2)

by Torsten Bergmann

for those who are not on squeak-dev list but may be interested: see http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/151011.html -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 27, 2010

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

by Igor Stasenko

On 27 May 2010 01:57, Levente Uzonyi <leves(a)elte.hu> wrote: > 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.) > I know. But all optimizations should follow a rule: you can cheat, but not get caught. Isnt? :) In smalltalk, i can send #and: message to any object. And from this point , there is no way how #and:and: could provide similar behavior, unless my class also implements it. > > 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 >> > > _______________________________________________ > 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 27, 2010

Re: [Pharo-project] CommandShell

by laurent laffont

Hi Dave, I've managed to make it running in Pharo (remove all isMorphic ifFalse ... stuff, change menu registration, a little work is needed to adapt to Pharo new settings system). It works (I can publish a package when back at home). Now I suppose you want to keep it running on Squeak, I don't know how to handle differences on world menu and preferences. For the MVC part, is there some value in keeping it ? Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Thu, May 27, 2010 at 8:52 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 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 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