Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-01-24

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

All times shown according to UTC.

Time Nick Message
23:19 jeffreykegler joined #marpa
01:06 jeffreykegler left #marpa
03:53 jeffreykegler joined #marpa
03:53 jeffreykegler ronsavage: the icons are taking over.  nothing can stop them.  resistance is useless.
03:55 jeffreykegler ronsavage: actually the icons are provided (or not) by your client.  :-)  I see icons in my IRC client and text when I backlog.  In at least some clients they'd be configurable.
04:58 jeffreykegler I have just uploaded Marpa-R2 2.079_012 to CPAN.  It represents the end of Phase 2.
05:00 jeffreykegler The initial CPANtesters results are good.  This release contains a lot of revisions to internals.
05:00 jeffreykegler Testing will be very much appreciated.  Thanks!
05:01 jeffreykegler Marpa is now a much simpler algorithm than it was 2 weeks ago.
05:07 ronsavage joined #marpa
05:16 jeffreykegler left #marpa
05:22 rns_ joined #marpa
05:24 rns_ Marpa-R2-2.079_012 installed successfully on winxp (5.18.1) and cygwin (5.14.2)
05:54 jdurand joined #marpa
05:56 jdurand Marpa-R2-2.079_012 ok with gcc/perl-5.18.2 on Linux/Debian - will check win7 cl+gcc later
06:37 ronsavage Marpa::R2 V 2.079012
06:37 ronsavage Counts: Tests: 542. Modules: 8. Passes: 8. Fails: 0
06:37 ronsavage Duration: 1 minute and 30 seconds
09:14 jeffreykegler joined #marpa
09:15 jeffreykegler rns: jdurand: ronsavage: Thanks for the results!
09:18 jeffreykegler left #marpa
13:45 jeffreykegler joined #marpa
14:40 jdurand joined #marpa
14:48 jdurand jeffrey there are warnings on Win7 with both gcc and cl - shall send you that in pm, or pastebin, or?
14:49 jdurand jeffrey, another thing: can you give me an example of afile you want to see indented - preferably one without function decoration since you mentionned this can happen - thx
16:44 jeffreykegler jdurand: re the warnings -- can you do a Github issue?
16:45 jeffreykegler jdurand: my intended first application is for the code fragments in marpa.w -- so you can take any of the C code sections in the latest marpa.w
17:57 jeffreykegler I've started the Phase 2/3 interphase, merging some of the easier pull requests.
18:12 jdurand jeffreykegler: 'ok' x 2
18:13 jeffreykegler jdurand: great
18:13 jeffreykegler I hope last time I gave you a feeling why I believe an indenter is more important than it might seem ...
18:14 jeffreykegler A lot of people will say, "Oh, another C indenter, when we already have the GNU one"
18:14 jeffreykegler ... but the difference is that yours can be used as a template for other utilities, and that's a huge difference.
18:15 jeffreykegler But since it's "under the hood", a lot of people will miss it.
18:21 jdurand jeffreykegler: -;
18:22 jeffreykegler jdurand: hello
18:22 jdurand github issues done
18:23 jdurand jeffrekegler: hello - I was looking to gnu indent options - shall I reuse them or event redo option names from scratch ? I am in favour of everything from scratch using a sort of templating system
18:23 jeffreykegler great.  I've been working on them.  I'm doing them in reverse order of difficulty to wind my mind down from Phase 2. :-)
18:23 jdurand which under the hood as you say would be a transpiling engine
18:23 jdurand because in fact indent is nothing else but transpiling C to C -;
18:24 jeffreykegler jdurand: Exactly.  Previous indenters have been kludges, not full transpilers.
18:24 jeffreykegler jdurand: Hold a second, let me get a page reference for you ...
18:26 jeffreykegler jdurand: Page 11 of the Cweb manual ...
18:26 jeffreykegler There Knuth talks about how he parses C for Cweb, and you can see what you're up against.  It's totally different from our approach ...
18:27 jeffreykegler and could never form the basis of a compiler/transpiler.
18:27 jeffreykegler Plus it doesn't work all that well.  To spot typedefs, you often have to help it out.  And there is some syntax "@s xyz int" so that you can help the parser.
18:28 jeffreykegler "@s xyz int" tells Cweb that xyz is to be parsed as if it were an "int" declarator.
18:28 jdurand ok, but in case of a "partial" soure code I can understand such hint
18:29 jeffreykegler But having all the code is not sufficient to help Cweb.
18:30 jdurand today, I have worked on the C::AST engine, and added such possibility, deaulting to empty of course.
18:30 jeffreykegler Knuth's parsing code for Cweb is also available (in Cweb of course!)
18:30 jdurand But the most important is that added a "lazy"ness option: for partial source code, at a given moment, there will always be the need
18:30 jeffreykegler And you can see how his parser works.
18:30 jeffreykegler And why I think we very much have something to contribute here.
18:30 jdurand to decide between an indentifier, a typedef name, or an enum name
18:31 jeffreykegler Yes, so the indenter might need that kind of help.
18:32 jdurand but this "lazy" option will be very new and really marpa oriented: in case the parser could NOT know, then it will do as many lexeme_alternative() as there are expected terminals
18:32 jdurand in the range: TYPEDEF_NAME, ENUMERATION_NAME, IDENTIFIER
18:32 jdurand by definition this mean that there could be more than one parse tree value, then
18:32 jdurand and it is in this case that a hint could help
18:32 jeffreykegler jdurand: Sounds very cool.
18:33 jdurand but what I mean is that doing this "lazy"ness mean that C::AST could always parse a source without knowing in advance the typedefs/enums
18:33 jdurand i.e. without these hints we just talked about
18:33 jeffreykegler HEre's the link to the Cweb manual: http://mmix.cs.hm.edu/doc/cwebman.pdf  Knuth talks about his parsing strategy on p. 11
18:34 jeffreykegler It sounds really nice.
18:34 jdurand and I am prety sure at 99.9% that this will always work fine without these hints because the grammar has very special rules that forces a declaration specifier to consist of a preordered
18:34 jdurand type of specifiers
18:34 jdurand ok
18:35 jdurand many thanks for the references. I will look to the CWeb manual
18:35 jdurand page 11 in particular
18:35 jeffreykegler As I say, at the beginning, most people will see only the externals and do a straight option for option comparison with say, GNU's indenter, and they will say "So what is the big deal?"
18:36 jdurand I will provide much more than GNU indent can do -; at every position of every item of the source there will be the possibility to act "before" and "after" the lexeme
18:36 jdurand or act "before" and "after" a grammar rule
18:36 jeffreykegler Do you mean configurable?
18:37 jdurand I want to template the transpiling stuff, yes
18:37 jdurand there will be a transpiling engine, that will take take a configurable template
18:37 jdurand this is how I imagined it
18:38 jeffreykegler Good.  And you'll have a ready user base, because I need an extensible indenter, one that can be extended to understand Cweb syntax.
18:38 jdurand so GNU will be one template, K&R another etc... and the ultimate...: user can do its own template, because he has is /own/ style of coding, that fits in none of the standardized ones
18:38 jeffreykegler jdurand: I am toying with the idea of switching to the Linux standard, by the way.
18:39 jeffreykegler The GNU one is strange to my eye, even after using it a lot ...
18:39 jeffreykegler and it does a lot to help out Emacs, which I do not use.
18:40 jdurand well, if I look to the styles at http://en.wikipedia.org/wiki/Indent_style, mine is
18:40 jeffreykegler jdurand: "You may not like the way CWEAVE handles certain situations. If you’re desperate, you can customize CWEAVE
18:40 jeffreykegler by changing its grammar. This means changing the source code, a task that you might find amusing."
18:41 jeffreykegler jdurand: the just previous is a quote from Knuth, from the Cweb manual.
18:41 jdurand 1TBS favourite, I mean natural - Linux/Unix style in fact
18:41 jdurand thanks for quote, and I agree with JNuth of course
18:41 jdurand Knuth
18:42 jdurand ABout Cweave, my only asumption that C code is line oriented
18:42 jdurand any line that I will not understand will passed as-is
18:42 jeffreykegler I'll look at that indenting style.
18:43 jeffreykegler jdurand: Initially ignore the Cweb syntax, and just do an indenter, is my advice ...
18:43 jeffreykegler Then we extend.
18:44 jdurand as I said, anything that will trigger a parsing error will be handle as the following:
18:44 jdurand the line(s) will be passed through
18:44 jdurand Cweb syntax will a priori trigger immediate errors
18:45 jeffreykegler But, of course, you do have to be ready for defective syntax, and act "reasonably".
18:45 jdurand yes. Ok let me explain how I prepared the things:
18:46 jdurand C::AST will have four new options
18:46 jdurand * typedefs for eventual hints to typedef. Defaults to empty
18:46 jdurand * enums for eventual hints to enum. Default to empty.
18:46 * jeffreykegler is "listening"
18:47 jdurand * lazy for eventual lexeme_read(à of a TYPEDEF_NAME; or ENUMERATION_NAME, or IDENTIFIER replaced by lexeme_alternative() of TYPEDEF_NAME if this is an expected terminal
18:47 jdurand ./.. same for ENUMERATION_NAME, same for IDENTIFIER, followed by of crouse a lexeme_complete
18:48 jdurand * start to give on-the-fly the "::start" option of the grammar
18:48 jdurand By default cpretty will instance different grammars, all having "lazy", eventual typedef/enum hints given on the command-line
18:49 jdurand and with "::start" defaulting to the top, i.e. translationUnit, the middles "declaration" and "function definition" and others that are line-oriented from my experience
18:49 jdurand but "start" will be also available on the command-line
18:50 jdurand the rest will look the source given in input to C::AST
18:50 jdurand up to the user to give a source non-preprocessed
18:51 * jeffreykegler is still listening
18:51 jdurand there will be a loop that is line-oriented. For each line not marked "processed", the different sub-grammars will be triggered
18:52 jdurand the grammar that will win is the one that will eat the most number of lines
18:52 jdurand and when I said "eat", I mean have at last one successful parsed expression.
18:52 jeffreykegler Very nice!
18:53 jdurand Ok, one question nevertheless:
18:54 jdurand when the grammar failed to parse entire source code but at at least one successful parsed expression, can I call value() ? I guess not
18:54 jdurand and will have to reparse/value on the subset that was successful
18:54 jeffreykegler jdurand: Currently not.
18:55 jeffreykegler You're talking about parsing using a start point other than location 0, right?
18:56 jdurand Hmmm... no, I am only interested by successful parsing from location 0
18:56 jdurand but if location 0 is:
18:56 jdurand ::start ::= this*
18:56 jeffreykegler In that case, yes you can call value()
18:56 jdurand ah !? Formidable -;
18:57 jdurand so if it successfully parsed n "this", I can call value() !?
18:57 jeffreykegler You just reset the end point.  There are examples of that in the test suite.
18:57 jdurand ok; very important. Resetting the end point, something that I have not done up to now.
18:58 jeffreykegler I test parses of various lengths by recognizing the longest of the strings ...
18:58 jdurand ok - set the end point, or reset the end point ?
18:58 jeffreykegler and then, rather than call the recognizer, I just call value(), resetting the end point each time.
18:59 jeffreykegler judrand: Look at t/sl_pascal.t
18:59 jeffreykegler There's also a NAIF equivalent: t/pascal.t
19:00 jdurand ok,many thanks, this is perfect and is synchroneous with my feeling that I had to evenalte multiple grammar by changing ::start, instead of plyaing with locations != 0
19:01 jdurand marpa ::= great*
19:01 jeffreykegler Need to shift laundry.  Will be AFK a few minutes.
19:01 jeffreykegler jdurand: Thanks!!!
19:01 jdurand lunch time, see u later
19:02 jdurand typo: "had to evaluate", not "had to evenalte"
19:02 jdurand lunch time again -;
19:29 jeffreykegler left #marpa
19:51 jdurand jeffrey, I wondered if lexeme_alternative would raise an exception if the token name is not one of the alternatives
19:52 jdurand my code is protected against that because I call terminals_expected() before, but if I could get rid of this call, which cost, I would be happy
20:01 jeffreykegler joined #marpa
20:07 jeffreykegler judrand: re http://irclog.perlgeek.de/m​arpa/2014-01-24#i_8171279: The token should be rejected, and alternative() should return a Perl false.  Rejects are efficiently handled by Libmarpa, so that trying an alternative is the preferred way.
20:07 jeffreykegler left #marpa
22:30 ronsavage My style is Allman
22:37 jdurand FYI I have tried the new lazy mode with c2ast on marpa.w: of course more than one parse tree value but, at the end, the exact same result on reserved names as per GNU C Library!
22:40 jdurand ronsave: at work this is style used sometimes as well, quite good style IMHO -;
22:41 jdurand ans is forced to do Whitesmiths on another project -; less easy...
22:41 jdurand "and" I mean
22:47 jdurand jeffrey, is $slr->ambiguity_metric() returning the number of parse tree values when its return value is >= 2?

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