Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-04-20

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

All times shown according to UTC.

Time Nick Message
05:08 jeffreykegler joined #marpa
07:42 ronsavage joined #marpa
13:48 LLamaRider joined #marpa
15:58 jeffreykegler joined #marpa
16:54 jeffreykegler I assume most of you follow the Google group, but just in case, Jean-Damien has posted an instructive example: https://groups.google.com/forum/​#!topic/marpa-parser/wJobY7Ev5hI
16:55 jeffreykegler It is a pure C marpa parser, using libmarpa directly.  It's a very nice compact example.
17:01 jdurand with one bug that I just discovered right now - not in libmarpa btw - I'll put that on github and let everybody know
17:19 jeffreykegler joined #marpa
17:32 jeffreykegler1 joined #marpa
17:45 jeffreykegler joined #marpa
17:48 jeffreykegler1 joined #marpa
17:54 jeffreykegler joined #marpa
18:04 LLamaRider joined #marpa
18:05 LLamaRider Hi. Just came to express my respect for jeffreykegler's R2.xs code. That's one impressive wrapper! I'm using it as one of the resources to learn XS.
18:07 jeffreykegler1 joined #marpa
18:11 jdurand Jeffrey, qbout marpa_v_rule_is_valued_set
18:11 jdurand "about"
18:12 jdurand it is not clear to me if the return value < 0 is an indication of failure, or if it is only return value == -2
18:19 jeffreykegler joined #marpa
18:22 jeffreykegler1 joined #marpa
18:39 jeffreykegler joined #marpa
18:41 jdurand I also have difficulties to understand how the application makes the decision on which symbol to call marpa_v_rule_is_valued_set(). Should'nt the value position it to all reachable rules in the grammar ?
18:41 jdurand "on which rules" I mean - sorry
18:42 jdurand Pleasee note that first I made a typo and used: marpa_v_symbol_is_valued_set() on a rule Id... and it worked (!?)
18:44 jeffreykegler1 joined #marpa
18:48 jeffreykegler1 LLamaRider: re http://irclog.perlgeek.de/​marpa/2014-04-20#i_8614734 -- thanks.  It grew organically, so I wonder about its overall structural elegance.  But I am a careful coder, and the individual section are based on a lot of research.
18:52 jeffreykegler1 judrand: I strongly recommend you use marpa_v_valued_force() and avoid the whole issue of "valued" vs. "unvalued" tokens.
18:53 jeffreykegler1 The "is valued" flag is an efficiency hack, allowing libmarpa at evaluation time to skip operations for "don't care" values.
18:54 jeffreykegler joined #marpa
18:54 jeffreykegler If I ever do a Libmarpa version which breaks backward compatibility, the "is valued" feature is one I'd probably eliminate.
18:55 jeffreykegler As you can see, I'm having connection issues, otherwise I'd explain more.
18:56 jeffreykegler The SLIF calls marpa_v_valued_force(), and so avoids dealing with the "is valued" feature.
18:58 jdurand Ok, is_valued_set() is in t/thin_eq.t that's why - will try with v_values_force
19:05 jeffreykegler The original motive for the "is valued" vs. "don't care" status of values was that all stacks operations required a callback, and at that time a Perl callback, which is really expensive ...
19:11 jeffreykegler joined #marpa
19:11 jeffreykegler jdurand: My current belief is that there are better ways to optimize, such as for example what you are doing at the moment.
19:12 jdurand marpa_v_valued_force() is documented as experimental - I just tried with it and it worked - everything is clear in the example IMHO, except this section about value
19:12 jeffreykegler I need to change the doc.
19:13 jeffreykegler Repeated some stuff my connection ate: The original motive for the "is valued" vs. "don't care" status of values was that all stacks operations required a callback, and at that time a Perl callback, which is really expensive ...
19:13 jeffreykegler so eliminating stack operations could be a big win.  In normal evaluations, you very often don't even look at the value returned, meaning the callback is a total waste.  So I created an "is valued" flag to flag those value which are really meaningful, as opposed to those which are just some more or less random value left on the stack.
19:13 jeffreykegler Saying marpa_v_valued_force() at the beginning says that all values should be treated as meaningful, and callbacks performed for them.
19:14 jeffreykegler I may also move the other "is valued" stuff into a "deprecated" section.
19:15 jdurand Ok
19:15 jeffreykegler * other == "is valued" related calls other than marpa_v_valued_force()
19:47 jdurand No pb - the C version of thin.t works perfectly otherwise - and that was the opportunity for me to finalize the end-user comprehension needed for a basic grammar usage with the C API
19:48 jdurand Remains the notion of events that I have not covered, otherwise your API is well done and I appreciated that
19:48 jdurand Now I believe that doing a pure C big application that one would compare with others is a way to promote it as it deserves
19:49 jdurand The only thing needed is a layer in between with no logic except error management - which is more or less what is doing your general_pattern.xsh from the distrib
19:51 jdurand And when I see that valgrind says "All heap blocks were freed -- no leaks are possible" with my ambiguous_grammar.c I am truely happy -; !
19:52 jeffreykegler Actually, if you're doing a between layer ...
19:53 jeffreykegler my experience indicates you'll also want to put symbol names in there.
19:53 jeffreykegler They are very useful for debugging, tracing, etc.
19:54 jeffreykegler Libmarpa itself has no such layer, because it avoids commitment to string encodings -- ASCII-7 versus the various Unicode varieties, Latin-1, etc.
19:54 jdurand True. Acked.
19:55 jeffreykegler So Libmarpa itself has no strings at all, except perhaps one "out of memory" message which I have not gotten around to making overridable.
19:56 jdurand Hmm... why not calling strerror(errno) for any system call that fails (!?)
20:02 jeffreykegler Marpa does not make a lot of system calls -- it does no I/O, no forking, etc., etc.  malloc() and family are the only things it calls.  I'm not sure why I avoided strerror(), but many system calls import complications, and here the benefit would be very small compared to any of the potential complications.
20:05 jdurand No pb - an out of memory error is anyway a near-veyr-fatal error and the app is going to die -; that's fine!
20:05 jdurand "near-very-near-fatal"
20:09 jeffreykegler Right Libmarpa treats out-of-memory as a fatal error.  In fact, the out of memory handler is a pointer to a function, so that it would be easy to allow the user to specify their own out-of-memory handler.  But right now I think everybody is happy with Libmarpa's current behavior.

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