Re: Exception handling and cull: [ Xtreams port to Squeak - second wave ]

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

Re: Exception handling and cull: [ Xtreams port to Squeak - second wave ]

Nicolas Cellier
2010/10/11  <[hidden email]>:

> "Sven Van Caekenberghe"<[hidden email]> wrote:
>> I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report.
>>
>> I have been trying some of the examples from the doc pages (google code project), this simple one still fails:
>>
>> ((1 to: 10) reading collecting: [:x | x * x]) rest
>
> Ah, that's because of the use of #cull: like semantics with exception handlers in some places, mostly
>
>        ... on: Incomplete do: #count.
>
> We can certainly replace all those with regular block style.
>

I see, #handleSignal: just calls valueWithPossibleArgument: instead of #cull...
I don't well see the interest of adding arguments to #on:do: handler,
since they would all be filled with nils...
IMO, this is because we didn't have #cull: previously, so we used an
existsing more powerfull version.

To me, it should be self to just send #cull:

Nicolas

_______________________________________________
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: Exception handling and cull: [ Xtreams port to Squeak - second wave ]

Levente Uzonyi-2
On Mon, 11 Oct 2010, Nicolas Cellier wrote:

> 2010/10/11  <[hidden email]>:
>> "Sven Van Caekenberghe"<[hidden email]> wrote:
>>> I tried to follow your different releases in Pharo 1.1.1, right now I have 433 tests, 3 failures (#testReadWriteLargeAmount), 11 errors (#..base64 and #..multipleBufferSize). If will send you the report.
>>>
>>> I have been trying some of the examples from the doc pages (google code project), this simple one still fails:
>>>
>>> ((1 to: 10) reading collecting: [:x | x * x]) rest
>>
>> Ah, that's because of the use of #cull: like semantics with exception handlers in some places, mostly
>>
>>        ... on: Incomplete do: #count.
>>
>> We can certainly replace all those with regular block style.
>>
>
> I see, #handleSignal: just calls valueWithPossibleArgument: instead of #cull...
> I don't well see the interest of adding arguments to #on:do: handler,
> since they would all be filled with nils...
> IMO, this is because we didn't have #cull: previously, so we used an
> existsing more powerfull version.
Originally the method sent #valueWithPossibleArgs:. I changed it to
#valueWithPossibleArgument:, because it's 100% backwards compatible. But I
agree that #cull: is suitable here too.


Levente

>
> To me, it should be self to just send #cull:
>
> Nicolas
>
> _______________________________________________
> 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