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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |