Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-10-13

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

All times shown according to UTC.

Time Nick Message
00:16 flaviu joined #marpa
01:55 ronsavage joined #marpa
02:16 flaviu joined #marpa
03:17 CQ_ joined #marpa
03:18 jeffreykegler joined #marpa
04:19 ronsavage joined #marpa
05:03 lwa joined #marpa
05:26 rns jeffreykegler: re http://irclog.perlgeek.de/marpa/2014-10-12#i_9497269 — looks like just the tool for the job — extensible Lua parser fully compatible with Lua 5.1.
05:27 rns left #marpa
05:27 rns joined #marpa
05:28 rns jeffreykegler: re http://irclog.perlgeek.de/marpa/2014-10-12#i_9497269 — looks like just the tool for the job — extensible Lua parser fully compatible with Lua 5.1.
05:28 rns Sorry for duplicate answer.
06:11 rns У нас уже с 9 октября показывают Солнечный удар ,так что после выходных пойдем смотреть.
06:12 rns http://irclog.perlgeek.de/marpa/2014-10-13#i_9498205 — sorry, paste in a wrong window.
08:57 rns Lua::Ast will always be here for fallback, of course.
11:47 flaviu joined #marpa
12:40 rns joined #marpa
15:03 lwa joined #marpa
15:08 jeffreykegler joined #marpa
15:18 jeffreykegler rns: I think both the Libmarpa wrapper and Lua::AST will see a lot of use.
15:20 jeffreykegler Soon we'll need to bring the SLIF logic into Kollos/LUIF.  That's something I will have to at least start, because right now the logic is a little to convoluted for someone else to find their way around.
15:21 jeffreykegler It's not actually that complex in itself, but unfortunately the way it evolved, with all the backward compatibilities requiired, it's implementation *is* complex.  It'll be refreshing to rewrite it cleanly.
15:22 jeffreykegler There are two parts: grammar rewrites (to turn the various SLIF rules into Libmarpa calls); and lexing.
15:22 jeffreykegler I propose to do the grammar rewrites first -- lexing can be done by hand.
15:24 jeffreykegler That is, lexing can be done by hand *at first*.  A big lesson I learned from Marpa::R2 is that folks these days want a lexing solution packaged in with their interface.
15:25 jeffreykegler I am doing a lot of thinking about lexing in the LUIF, and it will offer a choice of lexers, so that a user can either go with fast (low overhead) or powerful but high overhead, like the lexer currently in the SLIF.
15:27 rns jeffreykegler: re http://irclog.perlgeek.de/marpa/2014-10-13#i_9501047 — can't see why not, really; for one, lua::ast now optionally supports some round trip parsing — comments can be included in the parse tree. So, there'll be highlights.
15:29 jeffreykegler rns: Is Lua::AST in good enough shape to be announced to the Lua community as a tool?
15:30 jeffreykegler The Lua community seems like a powerhouse of innovation and I am eager to make contact.
15:30 rns Actually, not ready for prime time yet — only basic formatting is supported.
15:31 rns Still, as I'm progressing with formatting, we possibly can contact them on IRC to ask "smart" questions?
15:31 jeffreykegler They are #lua on freenode.
15:32 rns Yep.
15:32 jeffreykegler Yes, and do let them know about Kollos and the LUIF.
15:32 rns Lua is so pleasantly simple that style guide seems to be a non-issue - they just say 2-space indents and see style guides for Perl, Python ...
15:33 rns In the best Lua minimalist style, I have to say.
15:33 rns BTW, re lexers: I converted lua::ast grammar to external lexing to avoid wrestling with nested strings/comments, can share my experience.
15:33 jeffreykegler I'm actually learning a lot by studying their materials.
15:35 jeffreykegler Marpa is minimalist too. It's the smallest practical general parser possible. ;-)
15:36 jeffreykegler Unfortunately, "smallest practical" and "huge" mean the same thing when it comes to general parsers. :-)
15:37 rns :)) yes, generality seemы to go hand in hand with size.
15:38 rns re questions to #lua, I'm going to test them here first. :)
15:38 jeffreykegler Anyway, the Lua community does have repositories, and directories of useful tools, etc.
15:38 jeffreykegler test them?
15:40 rns So far, only 've been reading in search for a "right" formatter/ast emitter. Got one formatter installed though, but it was very basic.
15:40 rns That said, http://lua-users.org/wiki/LuaInspect provoked interest.
15:42 jeffreykegler I don't think it's necessary to have a lot of features to mention Lua::AST to them.  Just producing AST's would be enough in fact.
15:45 jeffreykegler Over in Lua-land they seem to have a toolkit mentality, so they might connect the dots as needed.
15:46 jeffreykegler And if not, the downside is that they'll just ignore the announcement, and we can come back when we have more.
15:47 rns Lua AST's can now be serialized, e.g. http://goo.gl/5hYPYX or saved as a ''-separated token stream. Perpahs they'd be interested in optional comment support.
15:49 rns Well, my minimal plan is to parse/beautify lua test suite well enough, — don't wont to set strict deadlines "produce bad code" as you once said.
15:50 rns Can be done pretty soon if $work permits. :)
15:51 jeffreykegler Did I say that?  Actually, just about every set of circumstances seems quite capable of producing bad code. :-)
15:54 rns Yes you did :) #109 — http://goo.gl/Y8rgAR. I some remembered that very well.
15:55 rns re bad code — big yes, looks like every code is bad unless/untill sees a few rewrites. :)
15:56 jeffreykegler Looks like I did say it. :-)
15:57 jeffreykegler But the SLIF's Perl layer is, I think, clear proof that sometimes it pays to release bad code.
15:57 jeffreykegler :-)
15:59 rns Yes and in a good way.
16:10 jeffreykegler Actually, with announcing to the Lua folks, their mailing list might be better -- their IRC seems not be important to them in the way that ours is to us, or #perl6 is to them.
16:10 jeffreykegler And I'm not sure they backlog.
16:14 rns Looks like it, adn their IRC has not been very active recently. Mailing list is a good idea, thanks.
16:21 rns What is your take on Lua parser/lexer extensible at a grammer level (by adding/removing BNF rules) as a feature of Lua::Ast, if I can ask?
16:21 rns metalua IIRC seems to be pattern/action, so BNF-level extensibilty looks like something they don't yet have.
16:22 jeffreykegler Not sure I understand the question.
16:23 jeffreykegler You mean Lua::AST as an alternative to MetaLua?
16:30 jeffreykegler Anyway, I think my answer is, that as we takes the steps toward Kollos/LUIF, we'll see lots of different ways in which we could branch out.
16:31 jeffreykegler Certainly a Marpa-powered approach allows the kind of Lua extensions that their current parsing technology cannot.
16:31 rns I meant BNF-level extensible parser as a feature Lua folks can be interested in, like they hopefully are in metalua.
16:33 jeffreykegler One reason to contact the Lua community is to see which ideas resonate with them.
16:33 jeffreykegler A lesson I've learned with Marpa is that some ideas, ideas which seem spectacular to me, simply don't resonate with people at this point ...
16:34 jeffreykegler and to focus on those ideas who do resonate.
16:34 rns Makes sense — never really know till you try anyway.
16:36 rns Well, have to go back to $work, thanks for a nice and useful talk.
16:36 jeffreykegler So I think it makes sense in general to put the time in where we get a response, and avoid putting time in when we don't.
16:37 jeffreykegler rns: Bye!
18:18 jdurand_ joined #marpa
18:45 jdurand_ Jeffrey - what would you prefer first - finalize the proof of concept using a concrete exmaple, or moving my marpa wrappe into a separate repo
18:46 jeffreykegler Separate repo.  Definitely the separate repo.
18:47 jeffreykegler That makes it easy for others to check out what you're doing.
18:47 jeffreykegler By the way, with the business of having one's code in public ...
18:47 jeffreykegler When I started Marpa, I was not comfortable with the idea of having my early drafts of code readable by the world.  Not at all.
18:48 jeffreykegler I did it only because the Open Source culture seemed to demand it.
18:49 jeffreykegler And as I was just telling rns, at this point I have some code out there of which I am not particularly proud, and don't even have the "early draft" excuse.
18:50 jeffreykegler But "the culture" was right, it's the right way to do things and, while I've gotten snarked at a lot, it's never been for my code.
18:50 jeffreykegler Snarky people are lazy and don't read code.
18:51 jdurand_ Fine with me - will keep you informed
18:51 jeffreykegler People reading code in your repository are self-selected as being the helpful kind.
18:52 jeffreykegler Anway, back to the topic, I'm really looking forward to playing with the wrapper.
18:52 jeffreykegler jdurand: Thanks!
18:55 jdurand_ -;
18:59 jdurand_ Do you prefer the wrapper to be bundle with a specific version of Marpa, or to use a configurable; though discoverable, version of libmarpa - right now I was using *my* tarball of marpa
19:02 jeffreykegler Your choice.  Prefer as a start, whatever is easiest.
19:02 jeffreykegler Bear in mind that the wrapper is likely to cause me to make changes in Libmarpa ...
19:03 jeffreykegler changes which I may not want to port into Marpa::R2 immediately.
19:03 jeffreykegler (If only because I don't want to hassle with bumping versions.)
19:05 jeffreykegler One example of a change I may make, is a "safe" variant of the marpa_version() call.
19:06 jdurand_ ok - if I choose the unbundle libmarpa, can you please remind me where are the instruction to build libmarpa.so from libmarpa repo only, not from the CPAN version
19:07 jeffreykegler The libmarpa repo has a target on top, which assembles autoconf distributions ...
19:08 jeffreykegler These in turn have all the standard autoconf targets, including for the shared library.
19:08 jdurand_ ok
19:09 jdurand_ Does you repo generate pkgconfig stuff btw
19:09 jeffreykegler I don't think I do, no.  Not unless it's standard with autoconf.
19:11 jdurand_ No pb - this could be a usefull thing though, c.f. http://lists.freedesktop.org/archives/pkg-config/2007-August/000219.html - but put that with a veyr low priority
19:12 jeffreykegler I just testing making a .so, btw.
19:13 jeffreykegler 1.) Use the "dist" target at the top of Libmarpa to make an autoconf distribution in the dist/ directory.
19:13 jeffreykegler 2.) cd into that directory.
19:13 jeffreykegler 3.) ./configure
19:14 jeffreykegler 4.) make
19:14 jeffreykegler The .so will be in dist/.libs
19:15 jdurand_ Fine - thx
21:10 jdurand_ https://github.com/jddurand/marpaWrapper.git - first version just to know if it links for any guinea pigs candidate
21:25 jdurand_ Note: except a file "genericLogger.c" that I would like to see elsewhere, all other files will stay in here
21:43 jdurand_ of course I invite readers to just read the file test/marpaWrapper_test.c - the most interesting part is the value phase, which consist of a single call: "marpaWrapper_vb(marpaWrapperp, &marpaWrapperValueOption, &marpaWrapperStackOption);"
21:45 jdurand_ the wrapper will take care of absolutely everything: the internal steps of Marpa, the management of the stack ,etc. Callbacks are registered in &marpaWrapperValueOption, and all callbacks always have a generic (void *) pointer that is passed as-is to userspace functions - so that they can do what they want. For instance the test is faking the (void *) to just be an integer...
21:46 jdurand_ In particular the wrapper explicitely hides the notions of "tree" and "bocage" of Marpa, vital for him, but not interesting for the end-user (IMHO).
21:47 jdurand_ (+ and the notion of "tree" - c.f. libmarpa API doc for more)
21:48 jdurand_ (/errata/ '+ and the notion of "order")
21:51 jdurand_ I'll reorganize the src and includes to just expose what is needed for outside, but the idea will remain the same: include "marpaWrapper.h" and that's all. AFK.
22:28 jeffreykegler joined #marpa
22:28 jeffreykegler jdurand: I hope to play "guinea pig" tonight California time

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