Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-06-30

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

All times shown according to UTC.

Time Nick Message
00:10 idiosyncrat joined #marpa
00:12 idiosyncrat daxim: re https://irclog.perlgeek.de/marpa/2017-06-29#i_14802426 -- Thanks for this link.
00:18 idiosyncrat Interesting -- I only skimmed -- the focus seems to be on memory violations & security issues, with parsing theory coming in in response to these concerns.
00:19 idiosyncrat The comments in the conclusion (p. 11 of http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf) could easily be re-purposed as arguments for the use of Marpa.
00:20 idiosyncrat That is, any parsing package is, in principle, more secure and less prone to memory leaks, than an individually hand-coded parser, and if Marpa handles even needs that combinator parsing cannot, it is a more general solution.
00:21 idiosyncrat I've tried in the past to motivate the case for Marpa on security grounds, without it seeming to catch on.
00:23 idiosyncrat In particular, PEG, where you usually don't even know what the language is that your parsing recognizes, is very fraught on security grounds.
00:24 idiosyncrat This paper documents the fact that parsers *are* a security issue, and Marpa can only benefit from this realization.
00:25 idiosyncrat A note here -- in claiming that Marpa/Libmarpa is free of security and memory violation problems, I am making that claims on 2 bases, one weaker and one stronger.
00:26 idiosyncrat First, the weaker, Libmarpa has an excellent record, a very low reported bug rate and has been checked several times by the Marpa team.
00:28 idiosyncrat Second, and more strongly, in principle resources can be devoted to thoroughly checking the Marpa algorithm, and their cost amortized over many projects ...
00:29 idiosyncrat whereas a per-app per-grammar hand-crafted parser can only lay claim to a portion of the resources available for the project of which it's a part ...
00:29 idiosyncrat so you rarely could reach anything like the same degree of assurance.
01:49 ilbot3 joined #marpa
01:49 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Code paste/run: https://f.perlbot.pl/#marpa - Jeffrey's Marpa site: http://jeffreykegler.github.io/Marpa-web-site/ - IRC log: http://irclog.perlgeek.de/marpa/today - Youtube channel: https://www.youtube.com/channel/UCYKVfGBtfTqbs1JdYq-dc5g
02:30 idiosyncrat ronsavage: I'm thinking about the timing of my next release, which I don't want to make before you've ironed out the event logic.
02:30 idiosyncrat In particular, there's cleanups I could do, but which would delay the next release, or I could try to make more of a bee-line toward it.
03:15 ronsavage JK: I suggest release ASAP.
03:16 idiosyncrat Really?  You've converted all your stuff?
03:17 ronsavage I've simply not had time to work on this, although it's Friday afternoon here, so I'll hit the code over the w/e. Converted? Nope. Do nothing :-( since I reported problems.
03:17 idiosyncrat Because I'd like to eliminate the $recce->events() call in this next release.
03:17 ronsavage I'm not calling events(). Go for it!
03:18 idiosyncrat Great.  Because of some of your IRC comments I thought you were having trouble with the conversion.
03:18 ronsavage Hmm. Your Events.pod page does not even mention it.
03:19 ronsavage Ahh, trouble yes. Don't worry about it.
03:19 idiosyncrat $recce->events(), you mean?  That's because I planned to eliminate it.
03:19 ronsavage Yes, that's what I mean. It's only a non-existent gleam in my eye.
03:20 idiosyncrat IIRC correctly your modules had used $recce->events a lot.
03:20 ronsavage Oops. Above 'Do nothing :-(' should have read 'Done nothing :-('.
03:21 idiosyncrat What I'm trying to do with the release timing is to pace the incompatible changes, so that you're not dealing with a 2nd set before you've resolved the 1st.
03:22 idiosyncrat I imagine you *could* do several at once, but I've discovered the slowest traveler often arrives first.
03:22 ronsavage events()? No. Don't use it. I just checked 3 modules. You were probably thinking of my internal known_events() where I validate event names.
03:23 idiosyncrat OK, then.  $recce->events() will probably be gone in a few hours time. :-)
03:26 ronsavage Ahhhhhhhhhhhhh. I double-checked a module. I previously searched for 'events(' but now see I've used it as @{$self -> recce -> events}. No '('! But the new version of the code no longer calls it anyway, so we're both good to go with the next release. The reason I don't call it is I assume the callbacks are called instead, which is why I push details during each call onto a stack (1 version anyway of new code).
03:27 ronsavage '1 version' of course means '1st version'.
03:27 idiosyncrat And you're comfortable with my torching the bridge behind you on this?
03:27 ronsavage Absolutely.
03:28 idiosyncrat Because, while Marpa::R3 is alpha, and I mean it, I do like to keep it as gentle an alpha as I can.
03:29 ronsavage The think which worries me is that I put a print stmt in the callback and it didn't ever print anything. /That's/ what got me confused ATM.
03:29 ronsavage I certainly don't worry if with an alpha you go hard, actually. I assume that's the point of calling it an alpha, surely :-).
03:30 idiosyncrat When I'm extremely puzzled I'll put a die() statement in.  There's no way that'll get executed without my test suite noticing. :-)
03:33 ronsavage Double-check. The die dies and the print prints. My fault missing that.
03:33 ronsavage Back to $work.
03:34 idiosyncrat Happy hacking!
03:38 ronsavage Not so happy. It's unpack actually since I'm tracking a serious bug in my own code.
03:39 ronsavage 'Unpack' => 'Unpaid'. The KolloX module I'm working on is KollosX::Languages::Perl::PackUnpack.pm!
03:58 idiosyncrat ronsavage: A note that may be useful when you take on the forthcoming release:
03:58 idiosyncrat Removing $recce->events() indirectly broke 2 of my tests --
03:59 idiosyncrat previously the default behavior for an event not mentioned anywhere was to pause the recognizer --
04:00 idiosyncrat in the new 'event_handlers' callback mechanism default is to throw a fatal error, complaining there's no handler.
04:00 idiosyncrat Workaround is this code:
04:00 idiosyncrat event_handlers => {
04:00 idiosyncrat 'card' => sub () { 'pause' },
04:00 idiosyncrat }
04:00 idiosyncrat Where 'card' is the name of the event.
04:01 idiosyncrat s/Workaround/Fix/
04:02 idiosyncrat IMHO an improvement, since in the previous scheme it was complicated to figure out why the recognizer was pausing when it did, and the new callback mechanism forces everything to be explicit.
07:23 idiosyncrat joined #marpa
10:41 sirdancealot joined #marpa
20:30 shadowpaste joined #marpa
23:46 idiosyncrat joined #marpa

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