assert:includes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

assert:includes

Daniel P Zepeda
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
Reply | Threaded
Open this post in threaded view
|

Re: assert:includes

Henrik Sperre Johansen
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
Reply | Threaded
Open this post in threaded view
|

Re: assert:includes

Adrian Lienhard
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
Reply | Threaded
Open this post in threaded view
|

Re: assert:includes

Daniel P Zepeda
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
Reply | Threaded
Open this post in threaded view
|

Re: assert:includes

Daniel P Zepeda
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
Reply | Threaded
Open this post in threaded view
|

Re: assert:includes

Stéphane Ducasse
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
Reply | Threaded
Open this post in threaded view
|

Re: assert:includes

Daniel P Zepeda
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
>>> [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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: assert:includes

Ramon Leon-5
> 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
Reply | Threaded
Open this post in threaded view
|

Re: assert:includes

Stéphane Ducasse
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
> [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
Reply | Threaded
Open this post in threaded view
|

WeakSet growth (issue 1047)

Henrik Sperre Johansen
In reply to this post by Adrian Lienhard
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
Reply | Threaded
Open this post in threaded view
|

Re: WeakSet growth (issue 1047)

Stéphane Ducasse
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
> [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
Reply | Threaded
Open this post in threaded view
|

Re: WeakSet growth (issue 1047)

Henrik Sperre Johansen
In reply to this post by Henrik Sperre Johansen
Ah yes, I have a bad habit of just replying to an old post, and  
erasing the subject, I'll try and improve my behaviour from now on.

I posted a short update to the issue, as I borked up the test results  
(as usual...) the my first one. :

However, the main improvement I expected (constant instead of growing  
runtime per iteration) still occurs when I run the test properly.

Cheers,
Henry

On Aug 19, 2009, at 4:46 50PM, Stéphane Ducasse wrote:

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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project