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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>    

> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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
>>>

> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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!

>> 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
> [hidden email]
> 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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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,