Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-01-13

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

All times shown according to UTC.

Time Nick Message
02:33 jdurand joined #marpa
02:40 jdurand Hello - back to the issue of shared information between grammar and recognizer, if I have recognizers instancianted from a common precomputed grammar, and make sure they never call marpa_g_event(), is it thread-safe ?
02:49 ilbot3 joined #marpa
02:49 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Pastebin: http://scsys.co.uk:8002/marpa - Jeffrey's Marpa site: http://jeffreykegler.github.io/Marpa-web-site/ - IRC log: http://irclog.perlgeek.de/marpa/today
03:55 idiosyncrat_ jdurand: re  https://irclog.perlgeek.de/marpa/2017-01-13#i_13911497
03:55 idiosyncrat_ No
03:56 idiosyncrat_ Every object created from a single grammar must be used in the same thread -- anything else is thread-unsafe
03:58 jdurand Ok - thx
03:59 idiosyncrat_ It's not a close thing, or something you can avoid if you do not certain functions, etc.
03:59 idiosyncrat_ Every object derived from a Marpa grammar is continually referring to variables in its base grammar.
04:00 idiosyncrat_ In Kollos/Marpa::R3, it gets worse -- they all depend on a single Lua interpreter, and every Lua interpreter must be run in a single thread.
04:11 jdurand I tried and I see a performance degradation unfortunately - expected though, even if it is C
04:13 jdurand In fact, I think I am missing a sort of "marpa_g_clone()" native function - instead we have to recreate the grammar from scratch in any thread isn't it
04:14 jdurand but I have caching implementation that will probably help -;
05:11 idiosyncrat_ Kollos will probably have very fast serialization of grammars, thanks to Lua.
05:12 idiosyncrat_ Good night!
07:36 hobbs joined #marpa
07:36 hobbs joined #marpa
22:39 idiosyncrat_ joined #marpa
23:34 idiosyncrat_ Another change I'm seriously considering in Marpa::R3/Kollos
23:35 idiosyncrat_ The ability to do multiple read()'s of input.
23:35 idiosyncrat_ Currently you can only read input once -- after that the input string is fixed ...
23:36 idiosyncrat_ but you can jump around in it arbitrarily using the resume() call, which in most cases allows you to simulate the effect of on-line input.
23:37 idiosyncrat_ But not always, some on-line inputs cannot be conveniently simulated in this way, and in any case this system is eccentric, and steppens the learning curve for Marpa.
23:37 idiosyncrat_ s/steppens/steepens/
23:38 idiosyncrat_ Marpa::R3 will have a more conventional input interface, and one that allows on-line input.

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