[Pharo-project] Xtreams port to Squeak - second wave

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Oct 11 15:24:31 EDT 2010


2010/10/11 Levente Uzonyi <leves at elte.hu>:
> On Sun, 10 Oct 2010, mkobetic at gmail.com wrote:
>
>> Hi Nicolas,
>>
>> "Nicolas Cellier"<nicolas.cellier.aka.nice at gmail.com> wrote:
>>>
>>> Hi again,
>>> I now have ported two more packages
>>> - Xtreams-Transforms
>>> - Xtreams-Substreams
>>> and their tests
>>
>> This is great! I loaded your code into Pharo 1.1 and things seem to be
>> working quite well. There was a complaint about missing SharedQueue2, I just
>> created a dummy subclass of SharedQueue with that name and things seemed to
>> load fine.
>> XTRecyclingCenter seems to be subclass of XTWriteStream, it should be
>> Object subclass, maybe a typo ?
>>
>>> I did not have any portability problem with those...
>>> But that's because I did not handle the Character encoder/decoder.
>>> Consequently, I have 8 tests failing (the Base64 related tests)
>>
>> I was thinking, we could implement just 'encoding: #ascii' quite easily,
>> to make this reasonably usable at least for applications that are fine with
>> that. We're actually contemplating about implementing our own encoders for
>> Xtreams too. The VW ones are tied to the classic streams more than we like.
>> You might have noticed some rather hairy parts in the encoding streams
>> yourself, where we're trying to work around some of the issues it creates.
>> The advantage of reusing the existing encoders was that there are quite a
>> few of those available, so reimplementing all that would be a drag. But we
>> can come up with a scheme where we can reimplement at least the common ones
>> and in VW we can still preserve hooking into the old ones for the rest. I
>> can give that a try on VW side in the meantime so you could get those for
>> free.
>>
>>> Plus 4 other tests failing because of my poor implementation of
>>> #after:do: (forking processes in a SUnit TestCase can't be that
>>> obvious).
>>
>> I looked at this, and I think this is how #after:do: should look like:
>>
>> after: aDelay do: aBlock
>>        "Evaluate the argument block delayed after the specified duration."
>>
>>        | watchdog |
>>        watchdog := [
>>                aDelay wait.
>>                aBlock value.
>>        ] newProcess.
>>        watchdog priority: Processor userInterruptPriority.
>>        watchdog resume.
>>
>> This would assume that the 2 tests calling #timeout:server:client: would
>> use a Delay instance instead of a Duration, which I'd be fine with. However
>> making that change doesn't quite get the tests running. It's blowing up with
>> a DNU on the 'output close' bit in #terminate:server:client: with output
>> being nil, which I'm having trouble figuring out. I can't find who could
>> possibly be nilling it out. I'm somewhat struggling finding my way around
>> the Pharo tools. The test seems to otherwise pass but the DNUs from the
>> background process isn't nice. Also when I just click on the test in the
>> TestRunner, I actually get four DNUs, not just one as I would expect. So I'm
>> kinda stuck, not sure how to move forward without help from someone who
>> knows his way around Pharo.
>> I also get odd failure from #testWriteCollectingMultipleBufferSize, which
>> seems to run fine (against collection) when I run the equivalent in a
>> workspace, but strangely fails when running via the #timeout:server:client:
>> construct, i.e. when client and server run in separate processes. Hm, now
>> that I think of it, they sure could fail if something preempts the client,
>> server processes at the right moment. I'll have to rethink that again.
>
> These problems should be solved with the latest version of CoreTests.
>
> Levente

Thanks!




More information about the Pharo-dev mailing list