Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2014-08-23

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

All times shown according to UTC.

Time Nick Message
00:56 jeffreykegler joined #marpa
01:06 jeffreykegler I just mentioned on the G+ group about a SLIF-to-C compiler.  This wouldn't be that hard, particular, if you start by prototyping subsets of the SLIF.
01:07 jeffreykegler That is, the SLIF has a self-grammar in SLIF, so you could implement the full syntax easily, just using Marpa::R2 to do the compile to AST.
01:08 jeffreykegler As a start, you could, for most of the features, just error with "Not implemented yet".
01:08 jeffreykegler At the extreme you could start by not implementing prioritized or sequence rules, and not implementing events.
01:09 jeffreykegler Also, you could ignore (or error on) all L0 rules, and require an external lexer.
01:10 jeffreykegler Semantics could be implemented a C callbacks, callbacks that the application has to provide in a library.
01:11 jeffreykegler Even this "bare bones", you've already got a tool that would beat yacc at a whole host of applications.
01:11 jeffreykegler And you can grow it feature by feature.
01:11 jeffreykegler jdurand: you've already implemented what would be large pieces of such a tool, haven't you?
01:47 ronsavage joined #marpa
01:48 ronsavage Is there no function in libmarpa which parses the BNF (i.e. is is all done in Perl)?
01:49 ronsavage 'is is' -> 'is it'
01:49 jeffreykegler Libmarpa contains the engine which actually parses the BNF rules
01:49 ronsavage Ahhh. Excellent.
01:50 jeffreykegler It also knows about sequence rules, but not prioritized rules, which is an inconsistency
01:50 ronsavage Oh. anti-excellent.
01:51 jeffreykegler The limitatiion of Libmarpa is that everything from its point of view is an integer
01:51 jeffreykegler That is symbols are integers
01:51 jeffreykegler Rules are integers
01:51 jeffreykegler Token values are integers
01:51 jeffreykegler Error results have codes which are (you guessed it) integers
01:52 jeffreykegler Things like names, the actual meaning of token values, and the semantic actions, all these are provided by the upper layer
01:54 jeffreykegler The advantage of this is that Libmarpa is totally flexible -- it imposes no restrictions on how symbols are named, what values tokens can have, or on how you implement the semantics.  Whatever you have in mind, nothing in the parse engine stops you from doing it.
01:55 ronsavage Right. The calls I make (no actions, all events) are Marpa::R2::Scanless::G -> new(...) and $recce = Marpa::R2::Scanless::R -> new(). Then for $recce the calls are:
01:56 ronsavage read(), resume(), events(), pause_span(), pause_lexeme(), literal(), lexeme_read() and value().
01:57 jeffreykegler You might try reading the Libmarpa doc, to get an idea of what Marpa looks like at its core.
01:58 ronsavage Yes. /That's/ what I confess having not done up to now.
01:58 jeffreykegler The Libmarpa doc does talk in terms of C prototypes, and C types, but otherwise does not really require any knowledge of the C language.
01:59 jeffreykegler I won't claim it's an easy read, especially if your C is very rusty, but I think it's not impossible.
01:59 jeffreykegler I think a few people on this channel have read it, and they might have advice on how to go about it.
02:00 ronsavage BTW I've made fabulous progress on the Graphviz DOT file parser. The draft article is at http://savage.net.au/Ron/html/A.New.Marpa-based.Parser.for.GraphViz.html
02:00 jeffreykegler Perhaps the worst thing about it is that, in reference manual style, it talks about topics in an order dictated by the implementation, rather than one that makes sense for a beginner.
02:02 jeffreykegler ronsavage: Looks pretty cool.
02:02 jeffreykegler One point, which I'm not sure is even a nit, and you might want to ignore.
02:03 jeffreykegler I differentiate between Libmarpa, which is a C language library, and the THIF, which is a thin Perl interface to it.
02:04 jeffreykegler The THIF does add some value, in a few cases where it was more difficult *not* to add value, than to do so.
02:05 jeffreykegler The most significant of this is error handling -- the THIF will throw Perl exceptions, something that Libmarpa, as a pure C library, obviously cannot do.
02:10 ronsavage Ok. Thanx for the feedback. Just going to lunch. I'll edit it upon return.
02:11 jeffreykegler It'd be reasonable to say Libmarpa, THIF, for the purposes of my table they are close enough to the same, but I wanted you to be aware that you were making a simplification there.
05:14 ronsavage joined #marpa
05:56 ronsavage For completeness, what sort of exceptions does libmarpa throw. And...
05:56 ronsavage I have some questions re your comment 'just using Marpa::R2 to do the compile to AST'.
05:56 jeffreykegler Libmarpa is a C library -- they don't really have exceptions.
05:57 ronsavage (1) What exactly would I do with this AST?
05:57 jeffreykegler It's all done with return values, which is pretty tedious let me tell ya.
05:58 jeffreykegler The set of suggestions about the compiler was targeted at someone willing to do a *lot* of C coding.
05:58 ronsavage (2) Is this AST the tree the one I already parse to tun into an image (with Marpa::Grammar::GraphViz2)?
05:58 jeffreykegler Yes.
05:58 ronsavage (3) Would I write the AST to a file and then process it, or work in Perl (given I was assuming my next step would be to switch to C)?
05:59 jeffreykegler What you would do with the AST is massage it into the Libmarpa C calls.
05:59 ronsavage OK. Thanx.
05:59 jeffreykegler My guess is work with it in Perl.
05:59 jeffreykegler And write the C code by converting the AST into C using Perl.
05:59 ronsavage Hmmmm. Without hitting the docs I'm doing too mch guessing to make much progress as this point.
06:00 jeffreykegler Doing this would require someone very comfortable with C coding.
06:00 ronsavage Yes, that makes sense. Perl is of course the ideal vehicle to circumvent coding in C!
06:01 ronsavage I have no fear of C, just that it's been a long time since I /exclusively/ worked in it. Perl of course is a fine day-to-day refresher.....
06:03 ronsavage In fact I remember the day - whose date has been list in the mists of time - when I received a phone call and was thereby headhuntedto switch from C++ to Perl. I took what was literally a leap into the dark, since up to that time I had barely ever written code in Perl.
06:04 jeffreykegler Like I say, I think Jean-Damien have major pieces of this solution already.
06:04 ronsavage But I was happy to leave C++ behind, since the project of the day was in Microsoft's C++, and hence required learning their vast and incomprehensible library code.
06:05 ronsavage Yeah - I've revisit his code
06:05 jeffreykegler It's probably an exaggeration to say that the SLIF-to-C compilier what would be left of one of Jean-Damien's projects, after deleting a lot of the code, but I get that impression. :-)
06:06 jeffreykegler Btw, changing subjects slightly.
06:06 jeffreykegler I've been listening to Stephanov's _Programming Conversations_ on Youtube
06:07 jeffreykegler This presents what seems like a reasonable approach to C++.
06:09 ronsavage OK. I've updated the article.
06:10 ronsavage I did contract work in C++ for 11 1/2 years, so if you don't mind I'll skip revisiting it.
06:11 ronsavage Another nit: In the THIF line, should the target column say Marpa::R2?
06:12 jeffreykegler I'm not 100% sure what "target" means in that context
06:15 jeffreykegler That is, I kind of know what you'd call the "target" of a compiler, but all these interfaces really interpret, rather than compile.  But perhaps "target" is being used in a different sense.
06:15 ronsavage 'target' is vague, but basically the language you would target i.e. in which you'd write your code to talk to Marpa. I'll have to clarify that.
06:16 jeffreykegler But that's already covered in the column labeled "Language", isn't it?
06:30 jeffreykegler It's late California time -- almost midnight
06:30 jeffreykegler AFK &
06:31 ronsavage OK. Article updated again. I chopped the Target column, and above the table added a comment about the Open Source nature of our work.
06:40 jdurand joined #marpa
06:41 jdurand Re http://irclog.perlgeek.de/marpa/2014-08-23#i_9230489 - this is a perl script that turns an EBNF grammar is marpaWrapper c code - e.g. https://github.com/jddurand/marpaXml/blob/master/src/internal/grammar/xml_1_0.c
06:42 jdurand "in marpaWrapper"
06:42 jdurand For instance, you are right, it isn't that hard to translate SLIF into C, because there is 1-1 mapping between SLIF grammar and marpa C library calls
06:50 jdurand joined #marpa
06:51 jdurand except for constructs that are implemented only in Perl or XS, a priori I think to latm + proritization
06:53 jdurand and everything about "actions" ([start,length,values], bless, forgiving, etc...)
06:53 jdurand the rest is OK AFAIK
16:20 jeffreykegler joined #marpa
16:21 jeffreykegler ronsavage: re http://irclog.perlgeek.de/marpa/2014-08-23#i_9230868 -- looks good!
16:44 jeffreykegler jdurand: re http://irclog.perlgeek.de/marpa/2014-08-23#i_9230879 -- maybe we should go for a SLIF-to-C compiler.
16:45 jeffreykegler If you like the idea, you can move that Perl script, test code for it, etc. into its own git repository.
16:46 jeffreykegler The result would be the ability to create very fast parsers from SLIF descriptions.
16:47 jeffreykegler The hardest part will be what to do about the lexer -- one solution is to simply provide their own lexer,
16:47 jeffreykegler but I could help with the translation of Marpa's lexer.
16:48 jeffreykegler And maybe other C-savvy Marpa community members would want to pitch in.
16:48 jeffreykegler I think this could come together very quickly, and be very, very useful.
16:52 jeffreykegler (Note we'd have to break strict SLIF compatibility in some respects -- we'd need to use a non-Perl regex library, for example.)
19:52 jeffreykegler joined #marpa
20:14 idiosyncrat joined #marpa
20:34 idiosyncrat Adventures with Cygwin:
20:34 idiosyncrat configure: line 18: $'\r': command not found
20:35 idiosyncrat Googling, I see that there is a "set -o igncr" bash setting
20:35 idiosyncrat Question: is it a good idea to just put this in my .bashrc?
20:46 idiosyncrat jdurand: btw, if a choice has to be made (and probably one does), the Perl 6 grammar could be back-burnered in favor of the SLIF-to-C compiler, is my opinion.
20:47 idiosyncrat If we do a Perl 6 proof of concept, a very likely (and appropriate) come-back is "Yes, OK, but if you're talking more than toy or utility use, it has to be fast"
20:47 idiosyncrat So the two are connected.
20:51 Aria Heh, igncr in .bashrc? No, that way is madness. plus then you emit scripts others can/r run.
21:17 jeffreykegler joined #marpa
21:17 jeffreykegler Aria: so what, then, is the work-around?
21:29 Aria Remove the cr from your scripts?
21:29 Aria Use only lf as line ending?
21:31 jeffreykegler That involves scripts being textually different between Windows and UNIX.
21:31 Aria Why? Unix only uses lf
21:32 jeffreykegler Oh I see.
21:32 jeffreykegler Get Perl to write just the ASCII newline, instead of "\n"
21:33 Aria Yeah. And time to put a stake in any notion of 'text mode' that hides a bytestream from you
21:33 jeffreykegler Some folks on this channel actually have the Marpa install working on Cygwin/Windows \
21:33 jeffreykegler I'm curious to hear how this resolved this.
21:40 jdurand joined #marpa
21:40 jdurand Re http://irclog.perlgeek.de/marpa/2014-08-23#i_9232687 - would you mind to try without cygwin
21:41 jdurand in a DOS, revisit your PATH by removing cygwin stuff in it
21:41 jdurand * Execute cmd
21:42 jdurand * to see your PATH: set PATH
21:42 jdurand then modify your path: set PATH=newValue
21:42 jdurand Before that:
21:42 jeffreykegler jdurand: I take it you're saying if that you don't use Cygwin, and for exactly this kind of reason.
21:43 jdurand yes -;
21:43 jeffreykegler Because I think Ruslan S. does use Cygwin IIRC
21:43 jdurand cygwin is a pain. I don't know how rns manages to be happy with it -;
21:43 Aria Yeah.
21:44 jdurand - install win32-bash: http://win-bash.sourceforge.net/
21:44 jeffreykegler I think it's useful for me to see the various trade-offs, because I wind up refereeing the builds.
21:44 jdurand - install GnuWin32 tools required by ./configure, a priori at least: make at http://gnuwin32.sourceforge.net/packages/make.htm
21:45 jdurand open a win32-bash and run configure
21:45 Aria http://www.mingw.org/wiki/MSYS has always been my go-to on Windows.
21:46 jeffreykegler So there is some use to my having at least a dim idea of what's going on.
21:46 jeffreykegler Fortunately I'm not dependent on the Windows install, so I can afford to take time to examine alternatives.
21:46 Aria Though it's been a half decade at this point.
21:46 jdurand Aria, yes, msys provides a bash. Some also suggest git-bash.
21:46 Aria Yeah. git-bash works pretty reasonably.
21:47 jdurand jeffreykegler: cygwin is adding a layer of complexity you do not imagine
21:47 jdurand Now, look to http://gnuwin32.sourceforge.net/packages.html : as you can see almost everything you need exit as native win32 executables
21:48 jdurand Re http://irclog.perlgeek.de/marpa/2014-08-23#i_9231946 - I already generate lexeme stuff, c.f. https://github.com/jddurand/marpaXml/blob/master/src/internal/grammar/xml_1_0.c#L6921
21:49 jdurand and this introduces the concept of a "reader". after all a lexer is a fixed state machine once your enter in it. It only depends on the input. That's why my code is doing.
21:50 jdurand "that's what"
21:51 jdurand jeffreykegler: tell me, what do you use ./configure for. to generate a makefile, that's all isn't it. And you makefile always have the same logic, I mean, its workflow almost sequential: call text, call compiler, generate libraries, do a tarball, etc... isn't it
21:52 jdurand 'is almost sequential: call TeX, call compiler, etc.'
21:52 * jeffreykegler is very interested in the current set of topics, but also having Internet connection issues.
21:53 jeffreykegler An important reason to use configure is autoconf-compatibility.
21:53 jdurand why autoconf
21:53 jeffreykegler Arguably, for the actual effort of Perl installation, it is more trouble than it is worth.
21:54 jeffreykegler autoconf is a kind of standard -- for the Debian port, for example, it gave Jonas and myself a "common language"
21:54 jdurand the very few variables that your autoconf is setting are not worth the autoconf dinosaur
21:54 jeffreykegler Debian has lots of tools that assume autoconf
21:54 jdurand Debian would be very happy if you would use something else, but Jonas did not mentioned that
21:55 jeffreykegler Actually, Jonas told me the opposite -- that he'd much prefer I avoid custom make files
21:56 jeffreykegler jdurand: unless you're talking some 3rd build/configuration tool -- not custom and not autoconf
21:56 * jdurand jeffrekegler: you go it
21:57 jeffreykegler Believe me, my love for autoconf does grow with familiarity
21:57 jdurand how many things do you se "on-the-glfly" with autoconf
21:57 jdurand "on-the-fly"
21:57 jdurand not a lot as far as I remember - then I suggest cmake
21:58 jeffreykegler I didn't follow the last set of statements
21:58 jdurand no pb
21:58 jdurand cmake is a true portable makefile generator with much more feature than ./configure
21:58 jdurand because it can target IDE's - ./configure is not doing that
21:58 jdurand anyway
21:59 jdurand give me the URL of the repo, I can provide you with a custome CMakeLists.txt (this is how cmake is calling its "configure")
22:00 jeffreykegler I think I'll ask Jonas about this on the Github issue
22:00 jdurand ok -;
22:01 jeffreykegler My impression is that one thing the Debian build guys know about, and that's builds
22:01 jeffreykegler I *do* note that while Perl's install does not use autoconf, it ends up looking *a lot* like autoconf.
22:02 jdurand And this is not a hasard perl looks like autoconf but is not. autoconf/automake/configure stuff is worth than their predecessor in the history of computing (I am thinkg of X11 s/w)
22:03 jeffreykegler Which is Stallman's classic line in defense of the autotools.  (Quoting from memory.)  "If all this looks like too much trouble, and you want to go your own route, what'll you'll end up will look like this."
22:04 jdurand He is right. The problem is that these dinosaurs. I never had as much headaches when I was trying to troubleshoot a problem with M4 for example.
22:05 jdurand X11 s/w was criticized because it was depending on hardcoded constants installed in site-wide configuration files.
22:05 jdurand Then autoconf came up and did the things right: on-the-fly.
22:06 jdurand But autoconf/autotolls/automake... this is far too much complicated for a single stuff that all developpers want: what is the current value of "this"
22:06 jdurand cmake comes back to this principle
22:06 jdurand I let you check with Jonas
22:06 jdurand Otherwise, please try the alternatives with win-bash:
22:07 jdurand first with cygwin if you insist
22:07 jdurand second with GnuWin32 tools
22:07 jdurand For the first alternative, I am pretty sure it will be enough to:
22:07 jdurand * open a cygwin shell
22:09 jdurand * execute bash.exe ./configure, where bash.exe will be the full location of win-bash, tradionnally under C:\Windows\System\bash.exe, but not guaranteed - I let you check
22:09 jeffreykegler I'll hold off on Cygwin, to give rns a chance to respond.
22:10 jeffreykegler And will install those pure Windows tools, you're talking about.
22:10 jeffreykegler I'll want them anyway.
22:12 jdurand Aria, have you already experienced with mobaxterm ?
22:12 jdurand jeffreykegler: ok

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