Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2016-05-25

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

All times shown according to UTC.

Time Nick Message
00:13 idiosyncrat_ joined #marpa
00:27 ronsavage joined #marpa
01:48 ilbot3 joined #marpa
01:48 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
04:58 rns joined #marpa
05:14 idiosyncrat_ Good night!
05:20 rns idiosyncrat: re {{ ... }} vs lua long brackets -- the former are ok, the latter look more Luaesque, so I’d prefer the latter, for consistency sake.
05:21 rns A related thought is that Perl actions are specified in the SLIF as a sub name for a reason and perhaps Lua actions can/should follow suit.
05:21 rns Which poses a question of loading Lua packages from files and where they should reside.
05:21 rns Another thought is that with Lua the global environment can be populated with AST/ASF and Lua actions can be called as handlers when traversing them, with Context Accessors as was planned for Kollos -- https://github.com/rns/kollos-luif-doc/blob/master/manual.md#context_accessors.
05:22 rns One overly brave idea (early morning here) could be to move Marpa::R3 internals to Lua from Perl XS step by step.
05:22 rns idiosyncrat: A couple of nits, premature as they are, but possible showstoppers for the next dev version:
05:22 rns (1) dTHX; is needed in new static functions in R3.xs and Lua.xs (push_val, bool_ref, marpa_luaL_loadbuffer, among others) on perls complied with threads.
05:22 rns (2) s/status = luaL_loadbuffer/status = marpa_luaL_loadbuffer/ in Lua.xs
05:22 rns Related: moving from dTHX; to pTHX_/aTHX_ as per http://perldoc.perl.org/5.8.8/perlguts.html#How-do-I-use-all-this-in-extensions%3f can provide a speed up for threaded perls.
05:23 rns s/complied/compiled
05:24 rns AFK, will backlog.
05:24 rns left #marpa
05:43 idiosyncrat_ joined #marpa
05:44 idiosyncrat_ rns: re http://irclog.perlgeek.de/marpa/2016-05-25#i_12541402 -- specifying Lua as code, but Perl via sub name.
05:45 idiosyncrat_ Two reasons I did not allow Perl to specified as code:
05:45 idiosyncrat_ 1.) I did not want to commit to Perl as the semantics language of the SLIF.
05:47 idiosyncrat_ 2.) Once you allow code, there'll be pressure to actually parse it for various reasons, such as substituting context variables.  Putting a Perl parser inside Marpa was not something I was sure I wanted to get into.
05:47 idiosyncrat_ Neither of these is an obstacle to specifying Lua as code.  But, what about also as a function name?  Yes, perhaps in the future.
05:48 idiosyncrat_ re http://irclog.perlgeek.de/marpa/2016-05-25#i_12541408 -- moving the Marpa::R3 internals to Lua step by step?
05:49 idiosyncrat_ Yes, something that has definitely crossed my mind.
05:50 idiosyncrat_ re http://irclog.perlgeek.de/marpa/2016-05-25#i_12541410 -- the missing thread macros
05:50 idiosyncrat_ Thanks for catching that.  Could you submit a patch?
05:51 idiosyncrat_ Also, dunno if you caught earlier, but right now Marpa::R3 uses a single Lua interpreter and I've changed the docs to state that Marpa::R3 is *not* thread-safe.
05:52 idiosyncrat_ The question is how many bridges do I want to burn.
05:53 idiosyncrat_ I'm thinking any effort on the current Perl threads might be a waste of time; see http://perldoc.perl.org/threads.html#WARNING
05:54 idiosyncrat_ My guess is that that language was not put into Perl 5.24.0 casually.
05:55 idiosyncrat_ So another approach is to simply abandon thread support totally, rip out all thread macros, and reap the efficiency gain.
05:56 idiosyncrat_ Anyone willing to research this topic, find out which way the wind is blowing, etc., I'd greatly appreciate it.  I could do it, but I'd like to spend my time coding.
05:58 idiosyncrat_ Good night!
05:58 ronsavage joined #marpa
06:08 ronsavage JK: I'd rip out the thread stuff. There are so many other modules in Perl to help:
06:08 ronsavage - Growl::GNTP
06:08 ronsavage - DBD::Pg
06:08 ronsavage - Notify
06:08 ronsavage - Job::Machine
06:08 ronsavage - Message::Passing (uses ZeroMQ)
06:08 ronsavage - ZeroMQ
06:08 ronsavage - Net::RabbitMQ
06:08 ronsavage - IPC::DirQueue
06:08 ronsavage - Qless
06:08 ronsavage - Mojo::Server::TCP
06:08 ronsavage - Parallel::PreFork
06:08 ronsavage - Parallel::Forkmanager
06:08 ronsavage - Proclet
08:59 rns joined #marpa
09:00 rns idiosyncrat: re http://irclog.perlgeek.de/marpa/2016-05-25#i_12541467 -- good, I'd be willing to help.
09:00 rns re parsing action source to do substitution --
09:00 rns instead of parsing, we can create an environment and expose it by passing it as an object in the first arg of calls to semantic functions.
09:00 rns Perl interpreter is already embedded an exposed via perlapi and, unless I’m missing something, can be used via eval_pv()/eval_sv() in the same way as Lua interpreter, embedded by hand, is (going to be) used via marpa_luaL_loadbuffer().
09:00 rns That can lead to actions as Perl sub name and/or Lua sub name and/or Perl code and/or Lua code, executed in a pre-created environment exposed via its own API, just like Marpa::R2::ASF does or Kollos planned to do (Context Accessors above). Needless to say, an ASF-based evaluator, also planned for Kollos, starts coming to mind.
09:01 rns re threads --
09:01 rns did some googling/reading, looks like native Perl threads are dead or at least doomed, but the baggage is here [3], [4]. “Thread-safe”, BTW, seems to mean capability of being used with threads and threads::shared, Options:
09:01 rns (1) don’t compile on threaded perls (where MULTILICITY is defined) [2] -- appealing, but hardly good
09:01 rns (2) remove PERL_GET_NO_CONTEXT and dTHX; -- compile can fail with cryptic error message [1] seen it under cygwin
09:01 rns (3) thread safe, but no explicit thread support -- use PERL_GET_NO_CONTEXT and dTHX;
09:01 rns (3a) reserve moving to pTHX_/aTHX_ as a possible efficiency boost on threaded perls -- this is what DB_File does [5]
09:01 rns (3b)  do (3)/(3a) and explore if multiple instances of Marpa::R3 can be used via modules providing thread facilities (per ronsavage list above -- thanks! -- possibly including threads(::shared) unless they are deprecated in future perls) possibly provide an example.
09:02 rns I’d take (3) -- this only requires adding dTHX; to new static functions, (3a) in hot places (like DB_File) and possibly (3b) -- had thoughts of doing it before anyway.
09:02 rns References:
09:02 rns [1] PERL_NO_GET_CONTEXT and Static Functions --http://blogs.perl.org/users/nick_wellnhofer/2015/03/writing-xs-like-a-pro---perl-no-get-context-and-static-functions.html
09:02 rns [2] Significance of #define PERL_GET_NO_CONTEXT in XS -- http://www.perlmonks.org/?node_id=1078178
09:02 rns [3] When a core function calls another, it must pass the context. This is normally hidden via macros. -- http://perldoc.perl.org/perlguts.html#Background-and-PERL_IMPLICIT_CONTEXT
09:02 rns [4] http://perldoc.perl.org/perlguts.html#How-do-I-use-all-this-in-extensions%3f
09:02 rns [5] https://metacpan.org/source/PMQS/DB_File-1.838/DB_File.xs
09:04 rns re patches --
09:15 rns sure, I’d take that, one nit in a meanwhile --  tabs-to-spaces in R3.xs -- many occurences -- can be fixed by s/\t/8 spaces/ -- and Lua.xs -- not many occurences -- I can file a PR or you may prefer doing it yourself.
09:26 rns I mean R3.xs complies with that change, but the patch is huge (6 hundred lines changed) so might prefer doing do it with your editor just as with Lua.xs.
09:31 rns s/complies/compiles/
09:32 rns AFK, will backlog.
09:32 rns left #marpa
09:32 kaare_ joined #marpa
10:54 idiosyncrat_ joined #marpa
10:55 idiosyncrat_ rns: Thanks a lot!  Will study once I'm awake. :-)
12:48 rns joined #marpa
12:48 rns s/embedded an exposed/embedded and exposed/
15:15 idiosyncrat_ joined #marpa
15:16 idiosyncrat_ rns: re http://irclog.perlgeek.de/marpa/2016-05-25#i_12542641 -- tabs instead of spaces
15:17 idiosyncrat_ Thanks!  Did it in commit f678a7cfa1460dcd11e6f5444c44bbe3e25808e8
15:17 idiosyncrat_ rns: Thanks for working out the choices re dealing with threading.
15:18 idiosyncrat_ I hadn't realized that without the threading macros you can't even compile in a threaded Perl.
15:20 idiosyncrat_ The best choice seems to be (3) -- http://irclog.perlgeek.de/marpa/2016-05-25#i_12542509 -- where we include the thread macros so that we do compile, but do not actually support threading.
15:22 idiosyncrat_ (Adding Lua broke threading.  Given the apparently non-use of Perl's interpreter based threads, I don't see that as a issue, but it could be fixed by switching to an approach that uses one Lua interpreter per grammar.)
15:23 idiosyncrat_ If the usual course is following, the "discouraged" status of Perl threads will change to "deprecated" and then they will be removed.
15:25 idiosyncrat_ Until then, I guess we have to include the dTHX; lines and should strive to do so in the right places, juuuuust in case.  (Apparently nobody tests, so we'll never know.)
15:26 idiosyncrat_ As for (3a) -- http://irclog.perlgeek.de/marpa/2016-05-25#i_12542511 -- I'll look at this some more.
15:27 idiosyncrat_ My current thought is that optimizing for Perls compiled with threading should not be a priority.
15:28 idiosyncrat_ rns: http://irclog.perlgeek.de/marpa/2016-05-25#i_12542497 -- using Lua environments instead of reparsing.
15:29 idiosyncrat_ Good idea.  One motive for my switch to Lua 5.3.2 was to get Roberto's new Lua environment implementation.
15:38 rns idiosyncrat: re http://irclog.perlgeek.de/marpa/2016-05-25#i_12545066 -- great, so I'll submit a patch to put the dTHX; as needed (in static functions using perlapi).
15:38 rns re http://irclog.perlgeek.de/marpa/2016-05-25#i_12545166 -- not exactly optimizing for threaded perls, just making sure that Marpa::R3 on threaded perls is not slower than on non-threaded, -- but yes, not a priority and, at least, benchmarking is in order, not the least because for me moving from dTHX; to pTHX_/aTHX_ does not look like an easy thing to do.
15:39 rns re http://irclog.perlgeek.de/marpa/2016-05-25#i_12545184 -- great, perhaps a single Lua environment can be used by *both* Lua and Perl semantic actions.
15:40 rns That can be in line with moving Marpa::R3 internals to Lua.
15:47 rns AFK, will back log.
15:47 rns left #marpa
15:50 rns joined #marpa
15:51 rns left #marpa
19:43 btyler joined #marpa
22:35 ronsavage joined #marpa

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