Re: Fwd: GNU VCG
--- Akim Demaille <firstname.lastname@example.org> wrote:
> | > Well, in the short term, I do plan to have Bison produce more
> | > For instance, Bison could, in addition to YYDEBUG, support some
> | > of YYVCG_PARSE_TREE which outputs the parse tree. I don't plan
> | > have Bison parser equipped with means to call vcg!!!
> | Sure, I have created a bison.xml that replaces bison.simple for
> | the parse tree and stack to xml.
> Nope, you don't want to do that for the same reason as there is no
> bison.simple.noyydebug and bison.simple.yydebug: combinatoric
Well, I just took the debug code and made it dump the debug to xml. The
fact that if you turn off the debug, it turns off the xml. I did not
want it in production anyway.
> | But in the long term I do plan on linking bison in.
> | Bison, bash, m4, gcc, all types of tools.
> This is very interesting. In particular, we are looking for libm4.
Me too, I have spent my vacation learning m4 and hating it.
I figure it should be possible to create a m4 macro to define m4_define
and translate these silly things into perl that can be debugged. But
besides that, the introspector approach to dumping the asts will be
great for m4!
> | I plan on creating a libintrospector that allows you to link in
> | types of gnu tools for data visualization.
> | Of course it wont happen over night, and untill then xml will help
> | the storage, it is easier to parse and easy to generate.
If you are interested in this, please join up on the introspector
mailling list, I get the feeling that debian legal will get pissed off
if we continue here forever.
James Michael DuPont
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More