Xtreams port to Squeak - second wave

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

Xtreams port to Squeak - second wave

Nicolas Cellier
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
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Levente Uzonyi-2
On Sun, 10 Oct 2010, Nicolas Cellier wrote:

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

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

>
> 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
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Sven Van Caekenberghe
In reply to this post by Nicolas Cellier
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:

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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Julian Fitzell-4
In reply to this post by Levente Uzonyi-2
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

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

mkobetic
In reply to this post by Nicolas Cellier
"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!

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

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

Sven Van Caekenberghe
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


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc