Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-04-12

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
09:24 LLamaRider joined #marpa
09:44 ronsavage joined #marpa
15:30 jeffreykegler joined #marpa
17:02 jeffreykegler1 joined #marpa
17:16 jeffreykegler joined #marpa
17:56 jeffreykegler joined #marpa
19:15 jdurand joined #marpa
19:18 jdurand Jeffrey, I would like to direct calls to Marpa in an XS, e.g. marpa_r_terminals_expected() for example. Since marpa.h is not bundled with CPAN installation, I am a bit in trouble, and would like to avoid to have to forward declare all marpa types.
19:20 jdurand Do you think it is wise to include my own copy of marpa.h in my distrib ? The side-effect is that, since I do not want to distribute a library containing marpa itself, I will then depend on a very specific of marpa.
19:21 jdurand Side-effect of this question is: do you think that marpa.h will evolve significantly in the feature ? Anyway, the root question is: how to access directly marpa.c routine within an XS, still using the symbols that will from R2.so shipped with Marpa:::R2, without having a potential trouble with marpa version
19:24 jdurand "the symbols that will come from"
19:39 jdurand An alternative being to use void* for all struct-like types, and others like int for e.g. Marpa_Symbol_ID, so that a call like marpa_r_terminals_expected ( Marpa_Recognizer r, Marpa_Symbol_ID* buffer) will work - thanks to C lazyness, but that's dirty -;
19:41 jdurand Another idea: bundle marpa.h and libmarpa.so with Marpa::R2 CPAN installation, tagging the so with a library version - just an idea
19:42 jdurand If nothing else, I'll may swith to a pure C solution, although I want to avoid that because Perl solves natively the problem of encoding, utf8-ness etc
20:37 jdurand Ah later: forget all what I said. libmarpa symbols are not exported by R2.so, so end of the story
20:48 jdurand I will move to Marpa::R2::Thin - forget everything writen upper - thx
22:08 jeffreykegler joined #marpa
22:10 jeffreykegler jdurand: re http://irclog.perlgeek.de/​marpa/2014-04-12#i_8577069 -- There's a libmarpa_dist/marpa.h in the CPAN distribution
22:10 * jeffreykegler apologizes in advance -- his Internet connection is flaky at this point
22:12 jeffreykegler Getting the Libmarpa files from the CPAN distribution is quite possible, and basing your C development on them is a fine way to go.  It's important to *build* the Marpa::R2 distribution first, so that it is tailored to your target system and tested.  Pulling files from the raw distribution is a bad idea.
22:13 jeffreykegler Using the Thin interface is another fine way to go.
22:14 jeffreykegler Starting with the thin interface might be preferable, as you can resolve library use and other issues in the more friendly Perl context.  Once that is done, you can go to a pure C language approach, if you wish.
22:20 jeffreykegler joined #marpa
22:29 jeffreykegler1 joined #marpa
22:30 jeffreykegler1 judrand: if we're talking about manual lexing, and the object is optimization, a significant part of the speedup may not happen until you get Perl out of the loop in the lexing -- but even so a Thin interface version may be the next best step.
22:34 jeffreykegler joined #marpa
22:34 jeffreykegler The thin interface (THIF) will deliver some speedup and, since THIF calls corresponds almost one-to-one with Libmarpa calls, a good way of prototyping the pure C solution.
22:50 jeffreykegler joined #marpa
22:56 jeffreykegler1 joined #marpa

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary