[Pharo-project] assert:includes
Greetings, I've run across this in my own tests that ran fine in Squeak, but failed in Pharo. I thought it was just me being a dummy, but when I imported SandstoneDb and ran the tests, the exact same thing happens. It is a simple fix, but being fairly new at this, I'd like to know why this is, and if I should have to do this or not. So, for easy reference, I loaded the latest SandstoneDb (rjl.117) into my image (pharo1.0beta-10401web09.07.5) and ran the tests, several of which failed with a doesNotUnderstand: #assert:includes: Here is the test: testCollectionSerialization kid save. mom children: (OrderedCollection with: kid). mom save. self flushAndReload . self assert: mom refreshed children includes: kid refreshed if I simply put parens around the argument to assert: like this: assert: (mom refreshed children includes: kid refreshed) it passes. In all cases of failing tests with SandstoneDb, that is the case. Any insight here? Thanks! DZ
I can't remember this change specifically, but to me it seems like a method was removed from Pharo that just added slight syntactic sugar. I'd reckon the reasoning was that it was not in some "standard" SUnit, and thus keeping it lead to worse portability to Smalltalks other that Squeak. (For example, it does not exist in VisualWorks) A case could be made that the method should have been deprecated rather than removed, but done is done, and all that :) Cheers, Henry On 17.08.2009 18:17, Daniel P Zepeda wrote:
Greetings,
I've run across this in my own tests that ran fine in Squeak, but failed in Pharo. I thought it was just me being a dummy, but when I imported SandstoneDb and ran the tests, the exact same thing happens. It is a simple fix, but being fairly new at this, I'd like to know why this is, and if I should have to do this or not.
So, for easy reference, I loaded the latest SandstoneDb (rjl.117) into my image (pharo1.0beta-10401web09.07.5) and ran the tests, several of which failed with a doesNotUnderstand: #assert:includes:
Here is the test:
testCollectionSerialization kid save. mom children: (OrderedCollection with: kid). mom save. self flushAndReload . self assert: mom refreshed children includes: kid refreshed
if I simply put parens around the argument to assert: like this:
assert: (mom refreshed children includes: kid refreshed)
it passes. In all cases of failing tests with SandstoneDb, that is the case. Any insight here?
Thanks! DZ
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I quickly checked in Squeak 3.9 and 3.10 but they do not have that method either. So chances are high that this method never was in Pharo. Maybe it was added by some other package as an extension. Cheers, Adrian On Aug 17, 2009, at 18:32 , Henrik Sperre Johansen wrote:
I can't remember this change specifically, but to me it seems like a method was removed from Pharo that just added slight syntactic sugar. I'd reckon the reasoning was that it was not in some "standard" SUnit, and thus keeping it lead to worse portability to Smalltalks other that Squeak. (For example, it does not exist in VisualWorks) A case could be made that the method should have been deprecated rather than removed, but done is done, and all that :)
Cheers, Henry
On 17.08.2009 18:17, Daniel P Zepeda wrote:
Greetings,
I've run across this in my own tests that ran fine in Squeak, but failed in Pharo. I thought it was just me being a dummy, but when I imported SandstoneDb and ran the tests, the exact same thing happens. It is a simple fix, but being fairly new at this, I'd like to know why this is, and if I should have to do this or not.
So, for easy reference, I loaded the latest SandstoneDb (rjl.117) into my image (pharo1.0beta-10401web09.07.5) and ran the tests, several of which failed with a doesNotUnderstand: #assert:includes:
Here is the test:
testCollectionSerialization kid save. mom children: (OrderedCollection with: kid). mom save. self flushAndReload . self assert: mom refreshed children includes: kid refreshed
if I simply put parens around the argument to assert: like this:
assert: (mom refreshed children includes: kid refreshed)
it passes. In all cases of failing tests with SandstoneDb, that is the case. Any insight here?
Thanks! DZ
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Oh, so you guys are saying that this was a convenience selector that was added in the image I was using which was never in Pharo. I hadn't thought about that, I thought it had something to do with differences in argument precedence, which seems to be a more basic issue between Pharo and Squeak. Since I totally went with Pharo, I removed all of the Squeak images I had, so I don't know if that convenience selector was in the image I was using or not. If it was a convenience selector, I'm glad it was removed, I wouldn't have expected that behavior. I guess I should just make a change set and send it to Mr. Leon to do with what he wants to, as I said the workaround is trivial. DZ On Aug 17, 2009, at 11:45 AM, Adrian Lienhard wrote:
I quickly checked in Squeak 3.9 and 3.10 but they do not have that method either. So chances are high that this method never was in Pharo. Maybe it was added by some other package as an extension.
Cheers, Adrian
On Aug 17, 2009, at 18:32 , Henrik Sperre Johansen wrote:
I can't remember this change specifically, but to me it seems like a method was removed from Pharo that just added slight syntactic sugar. I'd reckon the reasoning was that it was not in some "standard" SUnit, and thus keeping it lead to worse portability to Smalltalks other that Squeak. (For example, it does not exist in VisualWorks) A case could be made that the method should have been deprecated rather than removed, but done is done, and all that :)
Cheers, Henry
On 17.08.2009 18:17, Daniel P Zepeda wrote:
Greetings,
I've run across this in my own tests that ran fine in Squeak, but failed in Pharo. I thought it was just me being a dummy, but when I imported SandstoneDb and ran the tests, the exact same thing happens. It is a simple fix, but being fairly new at this, I'd like to know why this is, and if I should have to do this or not.
So, for easy reference, I loaded the latest SandstoneDb (rjl.117) into my image (pharo1.0beta-10401web09.07.5) and ran the tests, several of which failed with a doesNotUnderstand: #assert:includes:
Here is the test:
testCollectionSerialization kid save. mom children: (OrderedCollection with: kid). mom save. self flushAndReload . self assert: mom refreshed children includes: kid refreshed
if I simply put parens around the argument to assert: like this:
assert: (mom refreshed children includes: kid refreshed)
it passes. In all cases of failing tests with SandstoneDb, that is the case. Any insight here?
Thanks! DZ
I sent this to Mr. Leon, and this was his reply: You're not running the latest sUnit. Find and load sUnit Enhanced which has a better UI and includes these methods. Bleh, DZ On Aug 17, 2009, at 3:45 PM, Daniel P Zepeda wrote:
Oh, so you guys are saying that this was a convenience selector that was added in the image I was using which was never in Pharo. I hadn't thought about that, I thought it had something to do with differences in argument precedence, which seems to be a more basic issue between Pharo and Squeak. Since I totally went with Pharo, I removed all of the Squeak images I had, so I don't know if that convenience selector was in the image I was using or not.
If it was a convenience selector, I'm glad it was removed, I wouldn't have expected that behavior. I guess I should just make a change set and send it to Mr. Leon to do with what he wants to, as I said the workaround is trivial.
DZ On Aug 17, 2009, at 11:45 AM, Adrian Lienhard wrote:
I quickly checked in Squeak 3.9 and 3.10 but they do not have that method either. So chances are high that this method never was in Pharo. Maybe it was added by some other package as an extension.
Cheers, Adrian
On Aug 17, 2009, at 18:32 , Henrik Sperre Johansen wrote:
I can't remember this change specifically, but to me it seems like a method was removed from Pharo that just added slight syntactic sugar. I'd reckon the reasoning was that it was not in some "standard" SUnit, and thus keeping it lead to worse portability to Smalltalks other that Squeak. (For example, it does not exist in VisualWorks) A case could be made that the method should have been deprecated rather than removed, but done is done, and all that :)
Cheers, Henry
On 17.08.2009 18:17, Daniel P Zepeda wrote:
Greetings,
I've run across this in my own tests that ran fine in Squeak, but failed in Pharo. I thought it was just me being a dummy, but when I imported SandstoneDb and ran the tests, the exact same thing happens. It is a simple fix, but being fairly new at this, I'd like to know why this is, and if I should have to do this or not.
So, for easy reference, I loaded the latest SandstoneDb (rjl.117) into my image (pharo1.0beta-10401web09.07.5) and ran the tests, several of which failed with a doesNotUnderstand: #assert:includes:
Here is the test:
testCollectionSerialization kid save. mom children: (OrderedCollection with: kid). mom save. self flushAndReload . self assert: mom refreshed children includes: kid refreshed
if I simply put parens around the argument to assert: like this:
assert: (mom refreshed children includes: kid refreshed)
it passes. In all cases of failing tests with SandstoneDb, that is the case. Any insight here?
Thanks! DZ
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
We do not know what is SUnit Enhanced (may be keith improvement of SUnit) Stef On Aug 17, 2009, at 11:06 PM, Daniel P Zepeda wrote:
I sent this to Mr. Leon, and this was his reply:
You're not running the latest sUnit. Find and load sUnit Enhanced which has a better UI and includes these methods.
Bleh,
DZ On Aug 17, 2009, at 3:45 PM, Daniel P Zepeda wrote:
Oh, so you guys are saying that this was a convenience selector that was added in the image I was using which was never in Pharo. I hadn't thought about that, I thought it had something to do with differences in argument precedence, which seems to be a more basic issue between Pharo and Squeak. Since I totally went with Pharo, I removed all of the Squeak images I had, so I don't know if that convenience selector was in the image I was using or not.
If it was a convenience selector, I'm glad it was removed, I wouldn't have expected that behavior. I guess I should just make a change set and send it to Mr. Leon to do with what he wants to, as I said the workaround is trivial.
DZ On Aug 17, 2009, at 11:45 AM, Adrian Lienhard wrote:
I quickly checked in Squeak 3.9 and 3.10 but they do not have that method either. So chances are high that this method never was in Pharo. Maybe it was added by some other package as an extension.
Cheers, Adrian
On Aug 17, 2009, at 18:32 , Henrik Sperre Johansen wrote:
I can't remember this change specifically, but to me it seems like a method was removed from Pharo that just added slight syntactic sugar. I'd reckon the reasoning was that it was not in some "standard" SUnit, and thus keeping it lead to worse portability to Smalltalks other that Squeak. (For example, it does not exist in VisualWorks) A case could be made that the method should have been deprecated rather than removed, but done is done, and all that :)
Cheers, Henry
On 17.08.2009 18:17, Daniel P Zepeda wrote:
Greetings,
I've run across this in my own tests that ran fine in Squeak, but failed in Pharo. I thought it was just me being a dummy, but when I imported SandstoneDb and ran the tests, the exact same thing happens. It is a simple fix, but being fairly new at this, I'd like to know why this is, and if I should have to do this or not.
So, for easy reference, I loaded the latest SandstoneDb (rjl.117) into my image (pharo1.0beta-10401web09.07.5) and ran the tests, several of which failed with a doesNotUnderstand: #assert:includes:
Here is the test:
testCollectionSerialization kid save. mom children: (OrderedCollection with: kid). mom save. self flushAndReload . self assert: mom refreshed children includes: kid refreshed
if I simply put parens around the argument to assert: like this:
assert: (mom refreshed children includes: kid refreshed)
it passes. In all cases of failing tests with SandstoneDb, that is the case. Any insight here?
Thanks! DZ
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes, I had the same problem. I asked him and he was actually talking about "sUnit Improved". I don't know what I should do at this point beyond just fixing the tests to run without this method. What are the plans for the sUnit that is in Pharo right now? Would it be helpful to add that method? I guess what I'm asking is there something I can do to be helpful in this regard? Thanks! DZ On Aug 18, 2009, at 1:16 PM, Stéphane Ducasse wrote:
We do not know what is SUnit Enhanced (may be keith improvement of SUnit)
Stef
On Aug 17, 2009, at 11:06 PM, Daniel P Zepeda wrote:
I sent this to Mr. Leon, and this was his reply:
You're not running the latest sUnit. Find and load sUnit Enhanced which has a better UI and includes these methods.
Bleh,
DZ On Aug 17, 2009, at 3:45 PM, Daniel P Zepeda wrote:
Oh, so you guys are saying that this was a convenience selector that was added in the image I was using which was never in Pharo. I hadn't thought about that, I thought it had something to do with differences in argument precedence, which seems to be a more basic issue between Pharo and Squeak. Since I totally went with Pharo, I removed all of the Squeak images I had, so I don't know if that convenience selector was in the image I was using or not.
If it was a convenience selector, I'm glad it was removed, I wouldn't have expected that behavior. I guess I should just make a change set and send it to Mr. Leon to do with what he wants to, as I said the workaround is trivial.
DZ On Aug 17, 2009, at 11:45 AM, Adrian Lienhard wrote:
I quickly checked in Squeak 3.9 and 3.10 but they do not have that method either. So chances are high that this method never was in Pharo. Maybe it was added by some other package as an extension.
Cheers, Adrian
On Aug 17, 2009, at 18:32 , Henrik Sperre Johansen wrote:
I can't remember this change specifically, but to me it seems like a method was removed from Pharo that just added slight syntactic sugar. I'd reckon the reasoning was that it was not in some "standard" SUnit, and thus keeping it lead to worse portability to Smalltalks other that Squeak. (For example, it does not exist in VisualWorks) A case could be made that the method should have been deprecated rather than removed, but done is done, and all that :)
Cheers, Henry
On 17.08.2009 18:17, Daniel P Zepeda wrote:
Greetings,
I've run across this in my own tests that ran fine in Squeak, but failed in Pharo. I thought it was just me being a dummy, but when I imported SandstoneDb and ran the tests, the exact same thing happens. It is a simple fix, but being fairly new at this, I'd like to know why this is, and if I should have to do this or not.
So, for easy reference, I loaded the latest SandstoneDb (rjl.117) into my image (pharo1.0beta-10401web09.07.5) and ran the tests, several of which failed with a doesNotUnderstand: #assert:includes:
Here is the test:
testCollectionSerialization kid save. mom children: (OrderedCollection with: kid). mom save. self flushAndReload . self assert: mom refreshed children includes: kid refreshed
if I simply put parens around the argument to assert: like this:
assert: (mom refreshed children includes: kid refreshed)
it passes. In all cases of failing tests with SandstoneDb, that is the case. Any insight here?
Thanks! DZ
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes, I had the same problem. I asked him and he was actually talking about "sUnit Improved".
I don't know what I should do at this point beyond just fixing the tests to run without this method. What are the plans for the sUnit that is in Pharo right now? Would it be helpful to add that method? I guess what I'm asking is there something I can do to be helpful in this regard?
Thanks!
I'll update Sandstone's tests to not use sUnit enhanced in the next day or two after I look at the change set you sent me so this isn't an issue. This isn't the first time it's come up. Ramon Leon http://onsmalltalk.com
It could be good to see what extra features we want or not in SUnit because this is also sad that we limit ourselves like that (even if I value cross platofrm portability). Stef On Aug 18, 2009, at 10:48 PM, Ramon Leon wrote:
Yes, I had the same problem. I asked him and he was actually talking about "sUnit Improved".
I don't know what I should do at this point beyond just fixing the tests to run without this method. What are the plans for the sUnit that is in Pharo right now? Would it be helpful to add that method? I guess what I'm asking is there something I can do to be helpful in this regard?
Thanks!
I'll update Sandstone's tests to not use sUnit enhanced in the next day or two after I look at the change set you sent me so this isn't an issue. This isn't the first time it's come up.
Ramon Leon http://onsmalltalk.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I updated this issue with a solution which is simpler and less intrusive than the one in Mantis, and don't suffer from any Concurrency-issues not present already. (You could argue they solve different problems, but the impact of not recycling nilSlots is much less important with this patch, since WeakSets won't tend to grow as large) I'd be grateful if someone would read my reasoning/test the patch, and give feedback whether there are scenarios where it's not a valid solution. Cheers, Henry
henrik please create new threads else people may miss your posts On Aug 19, 2009, at 4:41 PM, Henrik Johansen wrote:
I updated this issue with a solution which is simpler and less intrusive than the one in Mantis, and don't suffer from any Concurrency-issues not present already. (You could argue they solve different problems, but the impact of not recycling nilSlots is much less important with this patch, since WeakSets won't tend to grow as large)
I'd be grateful if someone would read my reasoning/test the patch, and give feedback whether there are scenarios where it's not a valid solution.
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Adrian Lienhard -
Daniel P Zepeda -
Henrik Johansen -
Henrik Sperre Johansen
-
Ramon Leon -
Stéphane Ducasse