Re: Porting (old) code to something else

[LanX]

Sorry I can't contribute to your questions, but I find your strategy interesting.

( and its a meditation, after all :)

> So, I have 50000+ tests that I want to PASS (ideally)

Not sure if I understood correctly but are you saying you started with porting the test code first?

Wouldn't it be wiser to try to test your P6 code (in case of same functionality and semantic) with your P5 test suite (using a kind of bridge maybe)? Like this keeping both test-suites in sync?

I understand that type checking doesn't make sense and that you could drop this part of the tests, but the risk of bugs in the test-suite would be reduced and you could immediately start porting.

OTOH are test-suites easier to translate because they mostly consist of "simpler" code, which could help you having a smoother transition phase. (maybe?)

[Tux]

No I/we started of by making 4 different extremely simple versions of CSV parsing core code, just to see how ell approaches would work.

1. Chucks of interest
2. State machine
3. Grammar based
4. Brute force

The first three are still alive, and I personally only develop in the chunks version, which is - for me - the easiest to develop.

I did not want to put people off in the initial post, but speed is about the most serious drawback at the moment. Not having CPAN can be worked around using use Inline::Perl5;. Examples of how to do that are available on the git repo, that includes working with XS modules (including DBI)! (passing IO arguments is work-in-progress)

When I started in October 2014, my initial version was 6700 times slower than the XS version. Meanwhile is is "just" 1010 time slower. Some of that is because I learn to code more efficient in perl6, but most of that is because the perl6 core gets faster. We're not there yet. Here is a compare:

Perl5
Text::CSV::Easy_XS  0.016   These two have no options and only parse v
+alid CSV
Text::CSV::Easy_PP  0.016
Text::CSV_XS        0.039   Highly optimized XS with many options
Text::CSV_PP        0.514   Pure perl version
Pegex::CSV          1.356   Ingy's Pegex parser
Perl6
csv.pl              8.133   John's state machine
csv-ip5xs           8.950   Text::CSV_XS with Inline::Perl5
csv-ip5pp           9.812   Text::CSV_PP with Inline::Perl5
csv_gram.pl        13.426   Using a grammar-based parser
test.pl            38.733   My first attempt, no options
test-t.pl          39.502   Almost compatible with Text::CSV_XS

The numbers shown are the time needed in seconds to parse a valid 10000 line CSV file with 5 columns.

Back to your question. Of course one cannot start with the test suite, but one can start with the test suite as a guide. So after building the initial core parser, feed it the tests and look what works and what does not. Then use the failing tests as a plan to alter the code to make the tests pass: implement error-handling, make all the attributes work, catch all exceptions etc etc

Building a bridge would imho be a waste of time: that will not make you learn perl6 any faster, not will you hit problem areas that one needs to fix in the code eventually. As perl6 is type-checked and passes arguments by reference (all are objects), supporting array-refs to speed things up is counter-productive, so one needs to match the test suite to what is feasible and sane in perl6: don't slow don to match perl5 behavior. Things are changing anyway. I'm not trying to mimic the old CSV syntax, I'm trying to port its versatility and flexibility keeping the complete and safe parsing rules.

[LanX]

> Building a bridge would imho be a waste of time: that will not make you learn perl6 any faster,

Hm I think this shows our different approaches to "porting old code to something else".

I would be rather interested to create a "cross compile" code, which can be easily maintained in both languages (possibly isolating differing parts to sub-modules)

I understand that there is already a bridge to use the old CPAN modules, so you are rather concentrating on exploring Perl 6.

> but speed is about the most serious drawback at the moment.

So your goal is to write P6 code which can compete with XS code?

Wow...

Personally I'd be inclined to do it evolutionary step by step, having a full scale 1 to 1 port from P5 maybe slow, then using XS, then replacing XS with P6 "magic".

But I can easily believe that this might be too boring! ;)

Good luck and thumbs up! =)