Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-03-24

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

All times shown according to UTC.

Time Nick Message
00:25 idiosyncrat joined #marpa
02:46 idiosyncrat Another refactoring milestone
02:46 idiosyncrat I started refactoring with 8 Marpa modules in XS -- 6 low-level, 2 high-level.
02:46 idiosyncrat The 6 low-level ones were completely eliminated some time ago.
02:46 idiosyncrat Just now I eliminated the SLIF recce object, one of the two high-level ones, so only one is left -- the SLIF grammar object.
02:48 ilbot3 joined #marpa
02: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
02:48 idiosyncrat The advantage is that this simplifies the memory model, and moves it away from my custom memory management to standard Perl and Lua mechanisms.
02:50 idiosyncrat The XS footprint of the 2 high-level objects had already been cut back severely, so that they had a life-cycle like salmon.
02:50 idiosyncrat Salmon live their entire lives in salt water, except they are born in fresh water and return to it to die.
02:50 idiosyncrat So the high-level objects were doing everything in Pure Perl and/or Lua, except for their constructor and destructor, which remained in XS, vestiges of the previous design.
02:51 idiosyncrat I have just eliminated the SLIF recognizer constructor and destructor, and I'll now do the same for the SLIF grammar object.
02:56 ronsavage JK: IOW Massive changes...
02:59 idiosyncrat ronsavage: thanks
03:00 idiosyncrat This is heading toward a situation where my XS file is 100% a Lua interface, but I don't know whether to take it that far.
03:00 idiosyncrat I don't think it would be a generally useful interface, ...
03:01 idiosyncrat because it relies a lot on the preloading of Lua code in static memory, which is blazingly fast, but an unusuall technique.
03:02 idiosyncrat Lua code is usually read from files.
03:03 idiosyncrat So it's a Lua interface which assumes the Lua code writer has access to a C compiler and is static linking his Lua, which raises the question of how the Lua interface module would find the Lua code to staticly link it.
03:04 idiosyncrat For Marpa::R3 the problem is easily solved by giving the code I use fixed names and building that knowledge into the XS code, but for my Lua interface to be generally useful, that method would have to generalized.
03:06 idiosyncrat Anyway, I've gone on a bit, but it doesn't look like my Lua interface will be something generally useful.
03:06 idiosyncrat At most someone interested in creating their own may find useful functions and ideas to borrow.
04:54 ronsavage joined #marpa
05:18 idiosyncrat OK I just eliminated the SLIF Grammar module from XS, so there are now no Marpa modules in XS.
05:19 idiosyncrat An advantage of this is that all the C code is now behind interfaces that are either
05:19 idiosyncrat 1) already documented, like Libmarpa;
05:20 idiosyncrat or 2) can easily be documented, like my Lua-calling routine.
05:21 idiosyncrat This means that one can do a lot with Marpa::R3's internals now, knowing only Lua and Perl -- you do not have to know C or Perl's XS interface.
05:23 idiosyncrat Previously, in working on the internals, the logic and data were always bouncing up and down between the Perl code and the XS/C layer.
05:23 idiosyncrat jdurand: You once asked me if I'd ever document the XS interface, and now you have your answer -- it was easier to eliminate it.
05:24 idiosyncrat This should be about the end of my refactoring the XS layer.
05:25 idiosyncrat I had consider separating "glue" code -- C code which "glued" Kollos to Perl and had to deal with all of Lua, Kollos and Perl XS --
05:26 idiosyncrat from "pure XS" code, which only dealt with Lua and Perl, and was a general Lua interface which could even be used for other Lua applications.
05:28 idiosyncrat But now that I see the result, I see that the "pure XS-to-Lua" code is so heavily oriented to the special needs of the Kollos/Marpa module, it would not that good as a general Lua interface --
05:30 idiosyncrat It's feature set is what Kollos needs, which means a lot of special features (like static loading of Lua bytecode) which are hard to generalize and not that much in demand anyway ...
05:31 idiosyncrat plus a lot of things most Lua packages would want are probably not implemented, because I only implemented things Kollos needed.
05:32 idiosyncrat Good night!
06:14 ronsavage JK: I'll bet you feel good after such big steps.
12:10 choroba joined #marpa
16:37 aredridel joined #marpa
22:03 idiosyncrat joined #marpa
22:06 idiosyncrat ronsavage: pretty good.
22:07 idiosyncrat It's especially nice because memory management had included a lot of my own non-standard stuff done via XS.  That's all gone now, either transfered to Perl and/or Lua, or done using the most basic XS techniques.
22:15 idiosyncrat I often talk about various components of Kollos/Marpa::R3.  There are 6 major ones.
22:15 idiosyncrat Here's a breakdown:
22:17 idiosyncrat lua: There's a standard 5.3.2 Lua.  A major hack is that all the external names have marpa_ or MARPA_ prefixed, for namespace reasons.  Other than that, it's pretty much as Roberto released it.
22:19 idiosyncrat Libmarpa: the core parse engine.  Written in C, it has its own small test suite and a documented interface.  The full parse engine logic, but no "sugar".  For example, symbols have integer ID's, but no names -- it's up to a higher-level to provide these if desired.
22:19 ronsavage joined #marpa
22:20 idiosyncrat Kollos: A mixed Lua/C library providing an upper layer for Libmarpa.  Written in Marpa's own literate programming language, "Miranda".
22:21 idiosyncrat Note I use the term "Kollos" in different senses -- sometimes to refer to this particular library, and sometimes as the name of what the whole Marpa project is becoming as it uses more and more Lua.
22:22 * idiosyncrat realizes it would have been easier if he'd numbered the components in his list: 1 - Lua; 2 - Libmarpa; 3 - Kollos.
22:23 idiosyncrat 4: Glue.  In Lua and eventually perhaps some C.  Code for "gluing" Kollos to Perl.
22:25 idiosyncrat 5: the XS layer: In Perl's XS sub-language, also for gluing Kollos to Perl.  I had thought that Marpa::R3 would benefit from a sharp Glue/XS distinction, where the Glue knew about all of Lua/Libmarpa/Kollos, and the XS only knew about Lua ...
22:27 idiosyncrat But no benefit emerged from that distinction so the Glue/XS boundary is very arbitrary.  Only the Glue contains Lua code, but many of the C routines now in XS could go into the Glue library.
22:27 idiosyncrat 6 and last: the Perl code.
22:28 idiosyncrat Most of the refactoring to come will be moving logic from the Perl code (6) to Kollos (3).
22:29 idiosyncrat The idea here is that Kollos will contain all the logic other implementations of Marpa/Kollos would benefit from.
22:30 idiosyncrat While the Perl code will contain the logic which makes sense only in terms of the Perl implementation.

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