- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Method expressed as symbol, used as argument

by StÃ©phane Ducasse

Hi carlo here this is something quite simple based on the fact that a symbol can understand value: and perform the method. This is simple and we can use it for what it does. Stef On Mar 19, 2011, at 9:11 PM, Carlo wrote: > I'd read up on Higher Order Messaging as to me this is an application of it. > Googling for it should give you some good results, one of the hits will most likely be a paper co-authored by Stephane which was presented at OOPSLA 2005 if I'm not mistaken. > > Cheers > Carlo > > On 19 Mar 2011, at 3:40 AM, DougEdmunds wrote: > > It was pointed out that given an instance method > MyClass >> doSomething > that > MyClass do: [:each | each doSomething]. > can be expressed as > MyClass do: #doSomething. > > Can someone suggest something to read that explains the usage of # > here (#doSomething), the relation of methods to symbols, etc. > > Trying to wrap my head around it. Thanks. > > -dae > > > > -- > View this message in context: http://forum.world.st/Method-expressed-as-symbol-used-as-argument-tp3388864… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > >

March 19, 2011

Re: [Pharo-project] SUnit and Tests inheritance or 'Data' injection

by StÃ©phane Ducasse

I was suggesting the same as lukas. and yes somebody should design a new Testing frameworks and we keep Sunit for backward compatibility Now have you tried to use traits and inject the parameters as fixture. Because this is what we did for the collection hierarchy. Stef On Mar 19, 2011, at 8:46 PM, Stefan Marr wrote: > Hi Lukas: > > On 19 Mar 2011, at 20:19, Lukas Renggli wrote: > >>> Thus, my basic test class implements some 9 tests, and my auto-sizing test-class adds two more test. >>> However, when I run the tests, only 11 tests are executed and not 2*9 + 2 = 20 tests. >>> Is there something I am missing? Is there a way that I can force SUnit to also execute the tests of the superclass? >> >> See the method TestCase class>>#shouldInheritSelectors. > Thanks, thats what I was looking for :) > >>> Or, something that would actually be nice, is there a way that I can automatically parameterize my tests with data? >> >> In your test class create a test method that takes the parameter(s) as >> argument. Create several test methods that call this method with >> different arguments. > Ehm, that approach does not scale... > > My test has currently 9 #testMethods, if I understand your proposal correctly, than I would end up with n*9 methods, no? > With #shouldInheritSelectors it still feels like a hack, but at least I avoid having to create all those methods. > > Laurent, the @DataProvider feature of TestNG is basically what I was looking for: http://testng.org/doc/documentation-main.html#parameters > > Thanks > Stefan > >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > >

March 19, 2011

Re: [Pharo-project] need your attention: Package

by StÃ©phane Ducasse

On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote: > BTW, for smooth transition, why not just replace usages of PackageInfo by RPackage keeping everything working as today? And after that, we can improve the way we use it. > > In two words, why not replace only infrastructure instead of infrastructure and behavior at the same time? Doing both together is kind of complex and easy to make mistakes... yes this is what cyrille started to do. On top of RPackage so may be cleaning that is the way to go. but the matching semantics is not good. > But maybe it's easier (or nicer) to replace everything together... :P > > Guille > > On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Stef, > > I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty. > > On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack.... > > Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ... > > For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ... > > One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2... > > Dale > > On Mar 18, 2011, at 1:56 PM, StÃ©phane Ducasse wrote: > > > Hi guys > > > > we need to think about package: > > > > right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). > > We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement > > instead. > > RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. > > > > Now one of the problem I see is that we may not have a smooth transition because: > > - Rpackage does not rely on category tagging matching. > > - It is simpler to have a mapping from current categories to packages > > - Now it means that we could load a package in the system and it would be turned into several RPackages > > so this means that configuration would have to be adapted. > > > > - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. > > and to have tags to only represent categories. > > > > Now my time is short so I will > > - probably not implement tags > > - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange > > code. > > - check the MC dependency on method category conventions, because some logic is not defined in the right place > > like overrides in the MC tools and not in the PackageInfo > > - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to > > associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames > > and change the packages accordingly). > > - we should not rely on most-specific-category kind of pattern matching. > > > > So if you have suggestion please talk now. > > > > > > Stef > > >

March 19, 2011

Re: [Pharo-project] need your attention: Package

by StÃ©phane Ducasse

On Mar 19, 2011, at 8:39 PM, Igor Stasenko wrote: > I have no idea how Rpackage done internally but i think it should be orthogonal > to MC. a list of class and a list of methods smartly organized but no more. > You can implement import/export layers between MC and RPackage > and make it follow any rules you want (current ones), but internal > organization can be completely different. Exact Now reproducing the matching of MC makes everything more complex. > > On 19 March 2011 19:17, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> BTW, for smooth transition, why not just replace usages of PackageInfo by >> RPackage keeping everything working as today? And after that, we can >> improve the way we use it. >> >> In two words, why not replace only infrastructure instead of infrastructure >> and behavior at the same time? Doing both together is kind of complex and >> easy to make mistakes... >> >> But maybe it's easier (or nicer) to replace everything together... :P >> >> Guille >> >> On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >>> >>> Stef, >>> >>> I would say that trying to diverge from category-based packaging for MC1 >>> would pretty much be a disaster. the big problem is not what happens within >>> Pharo (which is a tough enough problem to solve), but what happens to other >>> folks (Squeak or GemStone or even VW in this case) trying to use mcz files >>> created in Pharo that no longer align with the class and method categories? >>> It will not be pretty. >>> >>> On the other hand, MC2 has been designed from the beginning to allow for >>> alternate package definition schemes ... category-based packaging has always >>> been a hack.... >>> >>> Perhaps this is time to start a push towards MC2 and perhaps >>> RPackage-based packaging could become part of MC2 or at least one of the >>> packaging schemes ... >>> >>> For transition, MC1 would continue to use category-based packages and >>> those projects that wanted to preserve MC1 compatibility would simply >>> continue to name the categories to make MC1 happy and use RPackage for MC2 >>> packages with a different rule set ... >>> >>> One of the problems with MC2 has been the lack of a compelling reason to >>> make the transition to a new system ... RPackage and the associated tools >>> could be the compelling reason to move to MC2... >>> >>> Dale >>> >>> On Mar 18, 2011, at 1:56 PM, StÃ©phane Ducasse wrote: >>> >>>> Hi guys >>>> >>>> we need to think about package: >>>> >>>> right now we have a new implementation that is fast, robust and supports >>>> well a new generation of tools (glamour, nautilus...). >>>> We are capturing all system events and we would be more or less ready to >>>> remove systemNotifier and use Announcement >>>> instead. >>>> RPackage can live also on the side of PackageInfo for a while but it >>>> would be better to have the shortest possible period of co-existence. >>>> >>>> Now one of the problem I see is that we may not have a smooth transition >>>> because: >>>> - Rpackage does not rely on category tagging matching. >>>> - It is simpler to have a mapping from current categories to >>>> packages >>>> - Now it means that we could load a package in the system and it >>>> would be turned into several RPackages >>>> so this means that configuration would have to be adapted. >>>> >>>> - marcus was suggesting me to create a package with the same >>>> contents as the one of loaded by MC. >>>> and to have tags to only represent categories. >>>> >>>> Now my time is short so I will >>>> - probably not implement tags >>>> - check again the implementation of RPackage and in particular the >>>> necessary compatibility layer, because I saw some strange >>>> code. >>>> - check the MC dependency on method category conventions, because >>>> some logic is not defined in the right place >>>> like overrides in the MC tools and not in the PackageInfo >>>> - check how a package gets created when loaded: the key question >>>> is that there is a problem to rely on categories to >>>> associate classes to packages because we can end up with >>>> overlapping (normally the IDE captures the category renames >>>> and change the packages accordingly). >>>> - we should not rely on most-specific-category kind of pattern >>>> matching. >>>> >>>> So if you have suggestion please talk now. >>>> >>>> >>>> Stef >>> >>> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. >

March 19, 2011

Re: [Pharo-project] need your attention: Package

by StÃ©phane Ducasse

On Mar 19, 2011, at 5:35 PM, Dale Henrichs wrote: > Stef, > > I would say that trying to diverge from category-based packaging for MC1 would pretty much be a disaster. the big problem is not what happens within Pharo (which is a tough enough problem to solve), but what happens to other folks (Squeak or GemStone or even VW in this case) trying to use mcz files created in Pharo that no longer align with the class and method categories? It will not be pretty. No this is not a problem, because we can save the package with the * notation and category even if we do not need that. What will happen is that pharo will only save package without subcategory matching (may be now resaving another the same package in another smalltalk may lead to a problem if the category are used as tags but not to have one to one correspondance). Let me explain: In Pharo I have Package Foo class InFoo has Category Foo (not needed in pharo but to help outside) class NotInFoo has Category Foo-Zork The class NotInFoo was edited with a simple class browser and the guy put a category Either the class NotInFoo is defined in Package Foo-Zork (and there is no problem when you load it elsewhere) Now if the class NotInFoo is defined in another package then when resaving in another system we may have a problem So this is why having a category to package mapping is safer. Now what other system like gemstone could do is also to copy the pharo package implementation because these are two classes. Tell me if this is making sense. > On the other hand, MC2 has been designed from the beginning to allow for alternate package definition schemes ... category-based packaging has always been a hack.... Except that MC2 requires an implementation that is like RPackage not based on protocol matching because packages can contain the same methods. > Perhaps this is time to start a push towards MC2 and perhaps RPackage-based packaging could become part of MC2 or at least one of the packaging schemes ... > > For transition, MC1 would continue to use category-based packages and those projects that wanted to preserve MC1 compatibility would simply continue to name the categories to make MC1 happy and use RPackage for MC2 packages with a different rule set ... > > One of the problems with MC2 has been the lack of a compelling reason to make the transition to a new system ... RPackage and the associated tools could be the compelling reason to move to MC2... What I can tell you is that having fast static packages and cleaning MC name matching is good. Now I'm trying to find how we can map another semantics on top of RPackage to make the transition as smooth as possible and not only for pharo people. Stef > > Dale > > On Mar 18, 2011, at 1:56 PM, StÃ©phane Ducasse wrote: > >> Hi guys >> >> we need to think about package: >> >> right now we have a new implementation that is fast, robust and supports well a new generation of tools (glamour, nautilus...). >> We are capturing all system events and we would be more or less ready to remove systemNotifier and use Announcement >> instead. >> RPackage can live also on the side of PackageInfo for a while but it would be better to have the shortest possible period of co-existence. >> >> Now one of the problem I see is that we may not have a smooth transition because: >> - Rpackage does not rely on category tagging matching. >> - It is simpler to have a mapping from current categories to packages >> - Now it means that we could load a package in the system and it would be turned into several RPackages >> so this means that configuration would have to be adapted. >> >> - marcus was suggesting me to create a package with the same contents as the one of loaded by MC. >> and to have tags to only represent categories. >> >> Now my time is short so I will >> - probably not implement tags >> - check again the implementation of RPackage and in particular the necessary compatibility layer, because I saw some strange >> code. >> - check the MC dependency on method category conventions, because some logic is not defined in the right place >> like overrides in the MC tools and not in the PackageInfo >> - check how a package gets created when loaded: the key question is that there is a problem to rely on categories to >> associate classes to packages because we can end up with overlapping (normally the IDE captures the category renames >> and change the packages accordingly). >> - we should not rely on most-specific-category kind of pattern matching. >> >> So if you have suggestion please talk now. >> >> >> Stef > >

March 19, 2011

Re: [Pharo-project] Method expressed as symbol, used as argument

by Guillermo Polito

And you can put it as an specific application of High order programming (high order functions, high order predicates...). I can suggest you to learn Haskell too <3 :D Guille On Sat, Mar 19, 2011 at 5:11 PM, Carlo <snoobabk(a)yahoo.ie> wrote: > I'd read up on Higher Order Messaging as to me this is an application of > it. > Googling for it should give you some good results, one of the hits will > most likely be a paper co-authored by Stephane which was presented at OOPSLA > 2005 if I'm not mistaken. > > Cheers > Carlo > > On 19 Mar 2011, at 3:40 AM, DougEdmunds wrote: > > It was pointed out that given an instance method > MyClass >> doSomething > that > MyClass do: [:each | each doSomething]. > can be expressed as > MyClass do: #doSomething. > > Can someone suggest something to read that explains the usage of # > here (#doSomething), the relation of methods to symbols, etc. > > Trying to wrap my head around it. Thanks. > > -dae > > > > -- > View this message in context: > http://forum.world.st/Method-expressed-as-symbol-used-as-argument-tp3388864… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > >

March 19, 2011

Re: [Pharo-project] Method expressed as symbol, used as argument

by Carlo

I'd read up on Higher Order Messaging as to me this is an application of it. Googling for it should give you some good results, one of the hits will most likely be a paper co-authored by Stephane which was presented at OOPSLA 2005 if I'm not mistaken. Cheers Carlo On 19 Mar 2011, at 3:40 AM, DougEdmunds wrote: It was pointed out that given an instance method MyClass >> doSomething that MyClass do: [:each | each doSomething]. can be expressed as MyClass do: #doSomething. Can someone suggest something to read that explains the usage of # here (#doSomething), the relation of methods to symbols, etc. Trying to wrap my head around it. Thanks. -dae -- View this message in context: http://forum.world.st/Method-expressed-as-symbol-used-as-argument-tp3388864… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

March 19, 2011

Re: [Pharo-project] SUnit and Tests inheritance or 'Data' injection

by Stefan Marr

Hi Lukas: On 19 Mar 2011, at 20:19, Lukas Renggli wrote: >> Thus, my basic test class implements some 9 tests, and my auto-sizing test-class adds two more test. >> However, when I run the tests, only 11 tests are executed and not 2*9 + 2 = 20 tests. >> Is there something I am missing? Is there a way that I can force SUnit to also execute the tests of the superclass? > > See the method TestCase class>>#shouldInheritSelectors. Thanks, thats what I was looking for :) >> Or, something that would actually be nice, is there a way that I can automatically parameterize my tests with data? > > In your test class create a test method that takes the parameter(s) as > argument. Create several test methods that call this method with > different arguments. Ehm, that approach does not scale... My test has currently 9 #testMethods, if I understand your proposal correctly, than I would end up with n*9 methods, no? With #shouldInheritSelectors it still feels like a hack, but at least I avoid having to create all those methods. Laurent, the @DataProvider feature of TestNG is basically what I was looking for: http://testng.org/doc/documentation-main.html#parameters Thanks Stefan > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

March 19, 2011

Re: [Pharo-project] need your attention: Package

by Igor Stasenko

I have no idea how Rpackage done internally but i think it should be orthogonal to MC. You can implement import/export layers between MC and RPackage and make it follow any rules you want (current ones), but internal organization can be completely different. On 19 March 2011 19:17, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > BTW, for smooth transition, why not just replace usages of PackageInfo by > RPackage keeping everything working as today?Â And after that, we can > improve the way we use it. > > In two words, why not replace only infrastructure instead of infrastructure > and behavior at the same time?Â Doing both together is kind of complex and > easy to make mistakes... > > But maybe it's easier (or nicer) to replace everything together... :P > > Guille > > On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: >> >> Stef, >> >> I would say that trying to diverge from category-based packaging for MC1 >> would pretty much be a disaster. the big problem is not what happens within >> Pharo (which is a tough enough problem to solve), but what happens to other >> folks (Squeak or GemStone or even VW in this case) trying to use mcz files >> created in Pharo Â that no longer align with the class and method categories? >> It will not be pretty. >> >> On the other hand, MC2 has been designed from the beginning to allow for >> alternate package definition schemes ... category-based packaging has always >> been a hack.... >> >> Perhaps this is time to start a push towards MC2 and perhaps >> RPackage-based packaging could become part of MC2 or at least one of the >> packaging schemes ... >> >> For transition, MC1 would continue to use category-based packages and >> those projects that wanted to preserve MC1 compatibility would simply >> continue to name the categories to make MC1 happy and use RPackage for MC2 >> packages with a different rule set ... >> >> One of the problems with MC2 has been the lack of a compelling reason to >> make the transition to a new system ... RPackage and the associated tools >> could be the compelling reason to move to MC2... >> >> Dale >> >> On Mar 18, 2011, at 1:56 PM, StÃ©phane Ducasse wrote: >> >> > Hi guys >> > >> > we need to think about package: >> > >> > right now we have a new implementation that is fast, robust and supports >> > well a new generation of tools (glamour, nautilus...). >> > We are capturing all system events and we would be more or less ready to >> > remove systemNotifier and use Announcement >> > instead. >> > RPackage can live also on the side of PackageInfo for a while but it >> > would be better to have the shortest possible period of co-existence. >> > >> > Now one of the problem I see is that we may not have a smooth transition >> > because: >> > Â Â Â - Rpackage does not rely on category tagging matching. >> > Â Â Â - It is simpler to have a mapping from current categories to >> > packages >> > Â Â Â - Now it means that we could load a package in the system and it >> > would be turned into several RPackages >> > Â Â Â so this means that configuration would have to be adapted. >> > >> > Â Â Â - marcus was suggesting me to create a package with the same >> > contents as the one of loaded by MC. >> > Â Â Â and to have tags to only represent categories. >> > >> > Now my time is short so I will >> > Â Â Â - probably not implement tags >> > Â Â Â - check again the implementation of RPackage and in particular the >> > necessary compatibility layer, because I saw some strange >> > Â Â Â code. >> > Â Â Â - check the MC dependency on method category conventions, because >> > some logic is not defined in the right place >> > Â Â Â Â like overrides in the MC tools and not in the PackageInfo >> > Â Â Â - check how a package gets created when loaded: the key question >> > is that there is a problem to rely on categories to >> > Â Â Â associate classes to packages because we can end up with >> > overlapping (normally the IDE captures the category renames >> > Â Â Â and change the packages accordingly). >> > Â Â Â - we should not rely on most-specific-category kind of pattern >> > matching. >> > >> > So if you have suggestion please talk now. >> > >> > >> > Stef >> >> > > -- Best regards, Igor Stasenko AKA sig.

March 19, 2011

Re: [Pharo-project] Issue 3800 in pharo: StaticForm can be removed

by pharo＠googlecode.com

Updates: Status: Started Comment #3 on issue 3800 by marcus.d...(a)gmail.com: StaticForm can be removed http://code.google.com/p/pharo/issues/detail?id=3800 (No comment was entered for this change.)

March 19, 2011