Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2015-01-19

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

All times shown according to UTC.

Time Nick Message
00:04 ronsavage jk: In https://jeffreykegler.github.io/Ocean-of-Awareness-blog/individual/2013/06/mixing-procedural.html there's a typo: 'all every'. Should be one or the other, I'd say.
00:18 jeffreykegler hobbs: Yes, in the future, I'm hoping Marpa will be *the* way of crunching huge files.  But that ain't what it's like today.
00:22 jeffreykegler ronsavage: Fixed.  *All every* writer can do is try. :-)
00:35 ronsavage What do others think of Jean-Damien's suggestion to rename Text :: Balanced :: Marpa to Text :: Delimited :: Marpa? There is already a Text :: Delimited on MetaCPAN, but it reads files whose columns are separated by e.g. pipe symbols. Perhaps JD didn't know that. Certainly the current name (of my module) follows from the fact that Text :: Balanced is on MetaCPAN.
00:36 jeffreykegler ronsavage: No opinion.  Do what you think best.
01:59 ronsavage joined #marpa
02:28 ronsavage jdurand: Yes I use Moo. No I've never used Moops. I won't feel comfortable until the issues on RT are dealt with, at least. I much prefer more stable technology.
02:47 ilbot3 joined #marpa
02:47 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 ronsavage Very-Good-News Flash: The $work from last year, which I thought was over, is starting up again this week.
02:49 jeffreykegler ronsavage: Glad to hear the news from Melbourne.
02:51 jeffreykegler re Marpa Praxis #1 -- the short praxis note seems like a nice idea.
02:53 jeffreykegler you may want to repost the link.  ilbot3 is the logger and apparently it took a 2 minute snooze just as you typed it.
04:45 hobbs I got this working using events, but I can't say I'm completely happy with it. Anyone have input on how to do it more gracefully? https://gist.github.com/arodland/cefdd4212e043f45fa2f
04:45 hobbs (Should I post stuff like this to the list instead?)
05:41 jdurand joined #marpa
05:42 jdurand ronsavage: Re http://irclog.perlgeek.de/marpa/2015-01-19#i_9964675 - oups I was not clear sorry. I was really talking about an ventual other module, doing delimited matching instead of balanced matching. A la Regexp::Common::balanced v.s. Regexp::Common::delimited ...
06:06 ronsavage joined #marpa
06:08 ronsavage Trying again: Here's my 1st mini-lightning talk/article: http://savage.net.au/Perl-modules/html/marpa.praxis/MarpaX.Languages.SVG.Parser.html
06:09 ronsavage jdurand: Oh! And Phew! Having thought about it, I decided not to change the module's name.
06:16 ronsavage jdurand: I have a look at the docs for Regexp :: Common :: (balanced, delimited). I don't really see any point in another module. Is there some specific feature in * :: delimited which you think is worth a module?
06:51 jdurand joined #marpa
06:54 jdurand ronsavage: Re http://irclog.perlgeek.de/marpa/2015-01-19#i_9965223 - these are two different behaviours. For example balanced stuff with a start '/*' and end '*/' will happily see two matches on '/* ... /* something */ ... */'. While a delimited match will see only one match.
06:59 ronsavage jdurand: Ah. OK. Thanx for the clarification.
07:03 ronsavage let me think about that. I can see nesting depth being the key factor here. And since T :: B :: M already detects nested matching it should be 'fairly simple' to extend it with a subclass. 'fairly simple' will be defined at a later date!
07:11 jluis joined #marpa
07:29 rns hobbs: re http://irclog.perlgeek.de/marpa/2015-01-19#i_9965043 -- Not sure if this counts for 'more gracefully': you can parse the input not enforcing the length constraint and enforce it later by walking the parse tree.
07:29 rns example of (ambiguous) grammar, which can parse the input -- https://gist.github.com/rns/ba250ed6a5ed1c82ce7b
07:33 rns Another option is external lexing with regexes, where you can enforce string length rule with backreferences at lexing stage and, again, enforce array count rule by walking the parse tree.
07:48 rns But for external lexing, ambiguity https://gist.github.com/rns/ba250ed6a5ed1c82ce7b#file-ambiguity has to be resolved by pruning the invalid parse trees in ASF (abstract syntax forests) before enforcing the length/count constraints.
07:53 rns All-in-all and efficiency-wise (catching errors early and avoiding unneeded parsing), events-based solution looks more graceful to me.
07:54 basiliscos joined #marpa
08:12 koo5 joined #marpa
08:27 basiliscos joined #marpa
10:37 koo5 joined #marpa
11:56 LLamaRider joined #marpa
15:48 jeffreykegler joined #marpa
17:11 lwa joined #marpa
17:52 koo5 joined #marpa
17:55 basiliscos joined #marpa
19:37 basiliscos joined #marpa
19:58 hobbs rns: yeah, I'm not unhappy with events, I'm just unhappy with my code :)
20:00 jdurand_ joined #marpa
21:03 ronsavage joined #marpa
21:15 jeffreykegler joined #marpa
22:24 flaviu joined #marpa
23:56 jeffreykegler I'm adding the ability to run tests to Libmarpa, Marpa's core code, the stuff that actually implements the parse engine.
23:56 jeffreykegler Previously, I have just used Marpa::R2 as Libmarpa's test environment.
23:57 jeffreykegler I am thinking of using Russ Allbery's implementation of the TAP parsing framework: http://www.eyrie.org/~eagle/software/c-tap-harness/
23:57 jeffreykegler Comments, sugggestions of alternative approaches, etc., etc., are welcome.

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