February 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Metacello] Metacello tests failing in 1.2

by Dale Henrichs

Unless I find a real bug (I haven't run into one yet) the only changes I'm making specifically for Pharo 1.2 with the new Gofer is to change the tests so that they pass. There are no behavior changes needed, just change the tests to use the "correct" branching scheme. Dale On Feb 24, 2011, at 6:28 AM, laurent laffont wrote: On Thu, Feb 24, 2011 at 3:15 PM, Dale Henrichs <dhenrich(a)vmware.com<mailto:dhenrich@vmware.com>> wrote: I haven't released my changes yet ... once I'm satisfied with the the behavior on PharoCore1.2 (that's where I'm doing development) I now have to get the new version of Gofer ported to Squeak and GemStone before I can make the full release ... otherwise the tests will be failing on Squeak/GemStone ... If the goal is to make the tests green on Pharo1.2, you might just add #expectedFailures as non-metacello extension methods to the troublesome tests ... I think that this is the exact use case that #expectedFailures is aimed at ... the tests will be green for Pharo1.2 and I'll be able to take the necessary time to propogate the necessary changes... Well, I prefer to not have tests green in this case because Pharo 1.2 cannot be released without the fixed version of Metacello, is it ? Laurent. Dale On Feb 24, 2011, at 5:50 AM, laurent laffont wrote: On Thu, Feb 24, 2011 at 2:31 PM, Dale Henrichs <dhenrich(a)vmware.com<mailto:dhenrich@vmware.com><mailto:dhenrich@vmware.com<mailto:dhenrich@vmware.com>>> wrote: Laurent, I've actually made a pass and cleaned up the tests ... you can compare with my work:)... I need to write some more tests to make sure that Metacello is still behaving correctly, I think I've added enough coverage, but I need to look a little closer ... My guess is that you didn't reset the resource ... the resource structure is cached, so when you make changes to the code that is used to create the resource, you need to reset it as well... Yes that was that ! Still 9 errors but as you've already done it ..... your changes has been integrated in PharoCore 1.2 ? Laurent. Dale On Feb 24, 2011, at 12:10 AM, laurent laffont wrote: On Thu, Feb 17, 2011 at 12:33 AM, Dale Henrichs <dhenrich(a)vmware.com<mailto:dhenrich@vmware.com><mailto:dhenrich@vmware.com<mailto:dhenrich@vmware.com>><mailto:dhenrich@vmware.com<mailto:dhenrich@vmware.com><mailto:dhenrich@vmware.com<mailto:dhenrich@vmware.com>>>> wrote: On 02/15/2011 05:46 PM, Guillermo Polito wrote: Hi Dale! There are 13 failing tests on the 1.2 dev build since a week ago ( https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/141/testReport/ ). Do we have the right version? Do you have any clue so I don't dive in the code blindly? :) Cheers, Guille Ahhhh, It looks the Gofer changes for Issue 3660 have been integrated, which means that the sorting order for mcz files has been changed, which means that the Metacello tests that are sensitive (or validating) the sort order have broken ... It will be at least a couple of days before I can get these issues fixed I have to propogate the gofer fixes to GemStone and Squeak... the normal operation of Metacello shouldn't be affected by these failing tests ... the test cases involved include examples of mcz files with "incorrect" branch naming scheme... I've created Metacello Issue 108: "Need to update Metacello (tests and Gofer config) to integrate changes from Pharo Issue 3660"[1] to track progress. [1] http://code.google.com/p/metacello/issues/detail?id=108 I've tried to resolve this past two days (yep, not so easy for a first dive into Metacello :). If I understand: 'GoferBar-lr.branch.1' should be 'GoferBar.branch-lr.1' so I've changed this for all packages/branches everywhere (in MetacelloMonticelloResource, MetacelloConfigurationResource, GoferResource and tests). Now a lot of tests are red because in MetacelloFetchingMCSpecLoader>>retryingResolvePackageSpecReferences: it cannot find GoferBar-lr.branch.2 Indeed in MetacelloTestConfigurationOfFoo generated by the tests there's package: 'GoferBar' with: 'GoferBar-lr.branch.2'; This driving me mad: I cannot find how MetacelloTestConfigurationOfFoo is generated and when a spec with 'GoferBar-lr.branch.2' is created instead of 'GoferBar.branch-lr.2'. Any hint ? Cheers, Laurent Dale

Feb. 24, 2011

Re: [Pharo-project] serializing a class

by Schwab,Wilhelm K

You might do some searches on Dolphin's binary packages; I tried them once and that was about it, but there might be some useful reading on them?? For your problem, my thoughts would be either a fileout or .mcz followed by SIXX for the data. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Thursday, February 24, 2011 5:25 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] serializing a class On Thu, Apr 1, 2010 at 11:05 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Stef, Dolphin's solution is to use proxies. Rather than serializing the class itself, one might prefer to serialize a proxy that knows enough to find the appropriate object once it "wakes up" in the new image. In the case of a class, it should be enough to know the name, so the proxy would have that one aspect and it would resolve itself by looking for it in the system dictionary. There is a little more to it, but that is the basic idea. ReferenceStream does the same, and te proxy is called DiskProxy. This may work sometimes, but others, it doesn't. For example, in my case, I need to REALLY serialize a class, becase I need to load it in another image where such class is not even present. cheers Mariano Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of StÃ©phane Ducasse Sent: Thursday, April 01, 2010 3:03 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Development Subject: [Pharo-project] serializing a class Hi I would like to do a little experiment. I need to save a class (not the instances) in a binary format and I was wondering if somebody got experience with that. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 24, 2011

Re: [Pharo-project] [Metacello] Metacello tests failing in 1.2

by laurent laffont

On Thu, Feb 24, 2011 at 3:15 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > I haven't released my changes yet ... once I'm satisfied with the the > behavior on PharoCore1.2 (that's where I'm doing development) I now have to > get the new version of Gofer ported to Squeak and GemStone before I can make > the full release ... otherwise the tests will be failing on Squeak/GemStone > ... > > If the goal is to make the tests green on Pharo1.2, you might just add > #expectedFailures as non-metacello extension methods to the troublesome > tests ... I think that this is the exact use case that #expectedFailures is > aimed at ... the tests will be green for Pharo1.2 and I'll be able to take > the necessary time to propogate the necessary changes... > Well, I prefer to not have tests green in this case because Pharo 1.2 cannot be released without the fixed version of Metacello, is it ? Laurent. > > Dale > On Feb 24, 2011, at 5:50 AM, laurent laffont wrote: > > On Thu, Feb 24, 2011 at 2:31 PM, Dale Henrichs <dhenrich(a)vmware.com > <mailto:dhenrich@vmware.com>> wrote: > Laurent, > > I've actually made a pass and cleaned up the tests ... you can compare with > my work:)... I need to write some more tests to make sure that Metacello is > still behaving correctly, I think I've added enough coverage, but I need to > look a little closer ... > > My guess is that you didn't reset the resource ... the resource structure > is cached, so when you make changes to the code that is used to create the > resource, you need to reset it as well... > > Yes that was that ! Still 9 errors but as you've already done it ..... > your changes has been integrated in PharoCore 1.2 ? > > Laurent. > > > > > Dale > > On Feb 24, 2011, at 12:10 AM, laurent laffont wrote: > > On Thu, Feb 17, 2011 at 12:33 AM, Dale Henrichs <dhenrich(a)vmware.com > <mailto:dhenrich@vmware.com><mailto:dhenrich@vmware.com<mailto: > dhenrich(a)vmware.com>>> wrote: > On 02/15/2011 05:46 PM, Guillermo Polito wrote: > Hi Dale! > > There are 13 failing tests on the 1.2 dev build since a week ago ( > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/141/testReport/ > ). Do we have the right version? Do you have any clue so I don't dive > in the code blindly? :) > > Cheers, > Guille > > Ahhhh, It looks the Gofer changes for Issue 3660 have been integrated, > which means that the sorting order for mcz files has been changed, which > means that the Metacello tests that are sensitive (or validating) the sort > order have broken ... > > It will be at least a couple of days before I can get these issues fixed I > have to propogate the gofer fixes to GemStone and Squeak... the normal > operation of Metacello shouldn't be affected by these failing tests ... the > test cases involved include examples of mcz files with "incorrect" branch > naming scheme... > > I've created Metacello Issue 108: "Need to update Metacello (tests and > Gofer config) to integrate changes from Pharo Issue 3660"[1] to track > progress. > > [1] http://code.google.com/p/metacello/issues/detail?id=108 > > > > I've tried to resolve this past two days (yep, not so easy for a first dive > into Metacello :). If I understand: > 'GoferBar-lr.branch.1' should be 'GoferBar.branch-lr.1' > > so I've changed this for all packages/branches everywhere (in > MetacelloMonticelloResource, MetacelloConfigurationResource, GoferResource > and tests). > > Now a lot of tests are red because in > MetacelloFetchingMCSpecLoader>>retryingResolvePackageSpecReferences: it > cannot find GoferBar-lr.branch.2 > Indeed in MetacelloTestConfigurationOfFoo generated by the tests there's > package: 'GoferBar' with: 'GoferBar-lr.branch.2'; > > This driving me mad: I cannot find how MetacelloTestConfigurationOfFoo is > generated and when a spec with 'GoferBar-lr.branch.2' is created instead of > 'GoferBar.branch-lr.2'. > > > Any hint ? > > Cheers, > > Laurent > > > Dale > > > > > > > >

Feb. 24, 2011

Re: [Pharo-project] [Metacello] Metacello tests failing in 1.2

by Dale Henrichs

I haven't released my changes yet ... once I'm satisfied with the the behavior on PharoCore1.2 (that's where I'm doing development) I now have to get the new version of Gofer ported to Squeak and GemStone before I can make the full release ... otherwise the tests will be failing on Squeak/GemStone ... If the goal is to make the tests green on Pharo1.2, you might just add #expectedFailures as non-metacello extension methods to the troublesome tests ... I think that this is the exact use case that #expectedFailures is aimed at ... the tests will be green for Pharo1.2 and I'll be able to take the necessary time to propogate the necessary changes... Dale On Feb 24, 2011, at 5:50 AM, laurent laffont wrote: On Thu, Feb 24, 2011 at 2:31 PM, Dale Henrichs <dhenrich(a)vmware.com<mailto:dhenrich@vmware.com>> wrote: Laurent, I've actually made a pass and cleaned up the tests ... you can compare with my work:)... I need to write some more tests to make sure that Metacello is still behaving correctly, I think I've added enough coverage, but I need to look a little closer ... My guess is that you didn't reset the resource ... the resource structure is cached, so when you make changes to the code that is used to create the resource, you need to reset it as well... Yes that was that ! Still 9 errors but as you've already done it ..... your changes has been integrated in PharoCore 1.2 ? Laurent. Dale On Feb 24, 2011, at 12:10 AM, laurent laffont wrote: On Thu, Feb 17, 2011 at 12:33 AM, Dale Henrichs <dhenrich(a)vmware.com<mailto:dhenrich@vmware.com><mailto:dhenrich@vmware.com<mailto:dhenrich@vmware.com>>> wrote: On 02/15/2011 05:46 PM, Guillermo Polito wrote: Hi Dale! There are 13 failing tests on the 1.2 dev build since a week ago ( https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/141/testReport/ ). Do we have the right version? Do you have any clue so I don't dive in the code blindly? :) Cheers, Guille Ahhhh, It looks the Gofer changes for Issue 3660 have been integrated, which means that the sorting order for mcz files has been changed, which means that the Metacello tests that are sensitive (or validating) the sort order have broken ... It will be at least a couple of days before I can get these issues fixed I have to propogate the gofer fixes to GemStone and Squeak... the normal operation of Metacello shouldn't be affected by these failing tests ... the test cases involved include examples of mcz files with "incorrect" branch naming scheme... I've created Metacello Issue 108: "Need to update Metacello (tests and Gofer config) to integrate changes from Pharo Issue 3660"[1] to track progress. [1] http://code.google.com/p/metacello/issues/detail?id=108 I've tried to resolve this past two days (yep, not so easy for a first dive into Metacello :). If I understand: 'GoferBar-lr.branch.1' should be 'GoferBar.branch-lr.1' so I've changed this for all packages/branches everywhere (in MetacelloMonticelloResource, MetacelloConfigurationResource, GoferResource and tests). Now a lot of tests are red because in MetacelloFetchingMCSpecLoader>>retryingResolvePackageSpecReferences: it cannot find GoferBar-lr.branch.2 Indeed in MetacelloTestConfigurationOfFoo generated by the tests there's package: 'GoferBar' with: 'GoferBar-lr.branch.2'; This driving me mad: I cannot find how MetacelloTestConfigurationOfFoo is generated and when a spec with 'GoferBar-lr.branch.2' is created instead of 'GoferBar.branch-lr.2'. Any hint ? Cheers, Laurent Dale

Feb. 24, 2011

Re: [Pharo-project] MetacelloBrowser

by Geert Claes

Alexandre Bergel-7 wrote: > > I agree. But using the configuration basename instead of the complete name > has some magic feeling to me. > For example, the ConfigurationMetacelloBrowser loads the package > MetacelloBrowser, itself contained in the squeaksource MetacelloBrowser > repository. I feel it get easy to be confused. > I will experiment with your suggestion. Thanks > I can see your point, but having all items start with "ConfigurationOf" adds too much noise. So, we "can" now have a configuration MetacelloBrowser using ConfigurationOfMetacelloBrowser to load from the MetacelloBrowser repository on Squeaksource, the package MetacelloBrowser which has classes that are in the MetacelloBrowser category where the Configuration = Repository = Package = Category :) -- View this message in context: http://forum.world.st/MetacelloBrowser-tp3321023p3322673.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 24, 2011

Re: [Pharo-project] I am I am I am ...

by merlyn＠stonehenge.com

>>>>> "Craig" == Craig Latta <craig(a)netjam.org> writes: Craig> Hi Mariano-- >> I know the reasons and the history... Craig> Hm, I don't think I know the history. As far as I can tell, Craig> Smalltalk-80 used "the receiver" instead of "I". When did the Craig> anthropomorphic style arise? As I recall, browsing the original ST80rel2 image at Tektronix in 1982 on a magnolia box (68k bitmapped 1024x768 display), I was amused by the class comments that generally all started with "I am ...", or "Instances of me hold ...". I think down in some of the technical parts, "the receiver" was used because it wasn't "self" somehow. But generally, the original image is very "I am"-ish. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Feb. 24, 2011

Re: [Pharo-project] [Metacello] Metacello tests failing in 1.2

by laurent laffont

On Thu, Feb 24, 2011 at 2:31 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > Laurent, > > I've actually made a pass and cleaned up the tests ... you can compare with > my work:)... I need to write some more tests to make sure that Metacello is > still behaving correctly, I think I've added enough coverage, but I need to > look a little closer ... > > My guess is that you didn't reset the resource ... the resource structure > is cached, so when you make changes to the code that is used to create the > resource, you need to reset it as well... > Yes that was that ! Still 9 errors but as you've already done it ..... your changes has been integrated in PharoCore 1.2 ? Laurent. > > Dale > > On Feb 24, 2011, at 12:10 AM, laurent laffont wrote: > > On Thu, Feb 17, 2011 at 12:33 AM, Dale Henrichs <dhenrich(a)vmware.com > <mailto:dhenrich@vmware.com>> wrote: > On 02/15/2011 05:46 PM, Guillermo Polito wrote: > Hi Dale! > > There are 13 failing tests on the 1.2 dev build since a week ago ( > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/141/testReport/ > ). Do we have the right version? Do you have any clue so I don't dive > in the code blindly? :) > > Cheers, > Guille > > Ahhhh, It looks the Gofer changes for Issue 3660 have been integrated, > which means that the sorting order for mcz files has been changed, which > means that the Metacello tests that are sensitive (or validating) the sort > order have broken ... > > It will be at least a couple of days before I can get these issues fixed I > have to propogate the gofer fixes to GemStone and Squeak... the normal > operation of Metacello shouldn't be affected by these failing tests ... the > test cases involved include examples of mcz files with "incorrect" branch > naming scheme... > > I've created Metacello Issue 108: "Need to update Metacello (tests and > Gofer config) to integrate changes from Pharo Issue 3660"[1] to track > progress. > > [1] http://code.google.com/p/metacello/issues/detail?id=108 > > > > I've tried to resolve this past two days (yep, not so easy for a first dive > into Metacello :). If I understand: > 'GoferBar-lr.branch.1' should be 'GoferBar.branch-lr.1' > > so I've changed this for all packages/branches everywhere (in > MetacelloMonticelloResource, MetacelloConfigurationResource, GoferResource > and tests). > > Now a lot of tests are red because in > MetacelloFetchingMCSpecLoader>>retryingResolvePackageSpecReferences: it > cannot find GoferBar-lr.branch.2 > Indeed in MetacelloTestConfigurationOfFoo generated by the tests there's > package: 'GoferBar' with: 'GoferBar-lr.branch.2'; > > This driving me mad: I cannot find how MetacelloTestConfigurationOfFoo is > generated and when a spec with 'GoferBar-lr.branch.2' is created instead of > 'GoferBar.branch-lr.2'. > > > Any hint ? > > Cheers, > > Laurent > > > Dale > > > > > >

Feb. 24, 2011

Re: [Pharo-project] MetacelloBrowser

by Alexandre Bergel

> I only just looked at the screenshot on http://metacellobrowser.dcc.uchile.cl > and my initial reaction is; if all items in the left pane start with > "ConfigurationOf" why not just drop the "ConfigurationOf" because that would > make it much easier to scan/read through the configurations I agree. But using the configuration basename instead of the complete name has some magic feeling to me. For example, the ConfigurationMetacelloBrowser loads the package MetacelloBrowser, itself contained in the squeaksource MetacelloBrowser repository. I feel it get easy to be confused. I will experiment with your suggestion. Thanks Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 24, 2011

Re: [Pharo-project] [Metacello] Metacello tests failing in 1.2

by Dale Henrichs

Laurent, I've actually made a pass and cleaned up the tests ... you can compare with my work:)... I need to write some more tests to make sure that Metacello is still behaving correctly, I think I've added enough coverage, but I need to look a little closer ... My guess is that you didn't reset the resource ... the resource structure is cached, so when you make changes to the code that is used to create the resource, you need to reset it as well... Dale On Feb 24, 2011, at 12:10 AM, laurent laffont wrote: On Thu, Feb 17, 2011 at 12:33 AM, Dale Henrichs <dhenrich(a)vmware.com<mailto:dhenrich@vmware.com>> wrote: On 02/15/2011 05:46 PM, Guillermo Polito wrote: Hi Dale! There are 13 failing tests on the 1.2 dev build since a week ago ( https://pharo-ic.lille.inria.fr/hudson/job/Pharo%201.2/141/testReport/ ). Do we have the right version? Do you have any clue so I don't dive in the code blindly? :) Cheers, Guille Ahhhh, It looks the Gofer changes for Issue 3660 have been integrated, which means that the sorting order for mcz files has been changed, which means that the Metacello tests that are sensitive (or validating) the sort order have broken ... It will be at least a couple of days before I can get these issues fixed I have to propogate the gofer fixes to GemStone and Squeak... the normal operation of Metacello shouldn't be affected by these failing tests ... the test cases involved include examples of mcz files with "incorrect" branch naming scheme... I've created Metacello Issue 108: "Need to update Metacello (tests and Gofer config) to integrate changes from Pharo Issue 3660"[1] to track progress. [1] http://code.google.com/p/metacello/issues/detail?id=108 I've tried to resolve this past two days (yep, not so easy for a first dive into Metacello :). If I understand: 'GoferBar-lr.branch.1' should be 'GoferBar.branch-lr.1' so I've changed this for all packages/branches everywhere (in MetacelloMonticelloResource, MetacelloConfigurationResource, GoferResource and tests). Now a lot of tests are red because in MetacelloFetchingMCSpecLoader>>retryingResolvePackageSpecReferences: it cannot find GoferBar-lr.branch.2 Indeed in MetacelloTestConfigurationOfFoo generated by the tests there's package: 'GoferBar' with: 'GoferBar-lr.branch.2'; This driving me mad: I cannot find how MetacelloTestConfigurationOfFoo is generated and when a spec with 'GoferBar-lr.branch.2' is created instead of 'GoferBar.branch-lr.2'. Any hint ? Cheers, Laurent Dale

Feb. 24, 2011

Re: [Pharo-project] MetacelloBrowser

by Geert Claes

I only just looked at the screenshot on http://metacellobrowser.dcc.uchile.cl and my initial reaction is; if all items in the left pane start with "ConfigurationOf" why not just drop the "ConfigurationOf" because that would make it much easier to scan/read through the configurations -- View this message in context: http://forum.world.st/MetacelloBrowser-tp3321023p3322597.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 24, 2011