Xtreams port to Squeak - second wave

Hi again,
I now have ported two more packages
- Xtreams-Transforms
- Xtreams-Substreams
and their tests

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)
Plus 4 other tests failing because of my poor implementation of
#after:do: (forking processes in a SUnit TestCase can't be that
obvious).

Now, the easy part of the port (copy/paste) is almost ended.
Once we manage a compatible way to handle pragmas, PEG Parser should
port quite easily too.

Then, the harder work begins:
- File/Socket/Pipe
- Pointers (in External Heap)
- Character encoding/decoding
- Compression/Decompression

If you think you can help in any of these, please tell.

Nicolas

On Sun, 10 Oct 2010, Nicolas Cellier wrote:

I added Number >> #milliseconds to Xtreams-VWCompatible, because Squeak
has #milliSeconds for some reason and the tests use #milliseconds

I also uploaded a new version of Xtreams-CoreTests which doesn't use
#after:do:. This change may use Squeak specific stuff, revert it if you
don't like it. All tests (except for the base64 related) are passing
reliably, no more random failures.


Levente

Hi Nicolas,

You have been working quite quickly, great!

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

The readline example is using the non-existing #slicer: method, this simpler version seems to work:

|text|
text := 'line1\line2\line3\line4' withCRs reading.
text := text ender: [ :char | char = Character cr ].
text collect: [ :line | line rest ].

That is a documentation bug though.

Sven


On 10 Oct 2010, at 22:09, Nicolas Cellier wrote:

On 10-10-11 3:45 AM, "Levente Uzonyi" <[hidden email]> wrote:
> I added Number >> #milliseconds to Xtreams-VWCompatible, because Squeak
> has #milliSeconds for some reason and the tests use #milliseconds

FYI, Grease deals with this ce. It also provides Exception subclasses that
support the ANSI #signal protocols on all platforms (another portability
problem I saw mentioned in this thread).

Julian

"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.

> The readline example is using the non-existing #slicer: method, this simpler version seems to work:
>
> |text|
> text := 'line1\line2\line3\line4' withCRs reading.
> text := text ender: [ :char | char = Character cr ].
> text collect: [ :line | line rest ].
>
> That is a documentation bug though.

Hm, odd, this is fixed in the package comments, but looks like I failed to regenerate the project pages properly. I'll review the comments again and update the site. Thanks!

Martin,

On 11 Oct 2010, at 20:35, [hidden email] wrote:

> 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 committed the necessary changes in the (new) repository.

Thx,

Sven

2010/10/11 Sven Van Caekenberghe <[hidden email]>:
Thanks.
In the meantime, I used #cull: in #handleSignal: in Squeak trunk,
previous behaviour was not meaningfull anyway.
But we can keep the long version for larger compatibility.

Nicolas

PS: shall we feed vwnc list with Squeak/Pharo porting problems ? I
removed it from the CC

2010/10/11 Julian Fitzell <[hidden email]>:
Yes, thanks Julian.
By now, only a few methods were needed, so the fastest thing was to
create our own compatibility layer rather than learning Grease and
adding an external requirement.
But in the long term, that may help.

Nicolas