revamped... > >Inline::CPP overloads only 3 of these build steps: > > - Inline::CPP::get_parser() creates a C++ parser, not a C parser. > > - [2 more] > >All the other parts of the build process are inherited from > Inline::C. > Same for me Inline::Flex. It does not reuse any code (I mean copy paste) from Inline::C > > So I wrote two new versions of Inline::Jacc, one overloading parse() > and one using a filter. Both of them work similarly well until > bootstrapping which still fails with an error (like the previous > release). I'll send both versions with private mail to the > yacc people, > could you please have a look? I suppose it has something to do with > Inline internals I'm not aware of. > > Greetings > > Jochen
Hi all, some new from the Inline::Y* front. I finally found time to try some ideas. I did produce a simple parser with Inline::Pbyacc and Inline::Flex and compared it with a pure Inline::Pbyacc and a solution using P::RD. Here are the results. # Pbyacc and Flex $ time perl inline_pbyacc_no.pl < td_pr real 0m4.116s user 0m0.010s sys 0m0.020s # Pbyacc $ time perl inline_pbyacc_fs.pl < td_pr real 0m14.541s user 0m0.020s sys 0m0.010s # P::RD $ time perl recdes.pl < td_pr real 1m40.785s user 0m0.010s sys 0m0.021s we have to take these figures with a pinch of salt. The perl lexer in the PByacc only solution could be better and the parser in P::RD is suboptimal (I still have problems with non left recursive parser) I also tried a 'real' C parser. The code generated by flex was 440 KB (C source). On its own it compiles with a second or two. But when pased to Inline::C (that is P::RD) it happily sucks 30 MB ram and I had to stop it after 15 mn. All this enegy goes into extracting one (1) function name. We have a big problem! The tools we are using to generate lexers and parsers are broken. Flex, Bison, Byacc, ... are aging tools. they were introduced and used in the 80s by people having simpler parsing needs. We can't use them if we are going to have multiple parsers running at the same time. I'd love to use Yacc but what's the use if it doesn't work properly in multi-threaded env. PByacc, in its objectified version, is good but a bit slow (depending on what one is parsing). The other tools are to be fixed or forgotten. What do we do ? (yes I would like some help here) Another problem is when having two or more Inline sections in the same file. Each section gets it own build directory. If the Inliners (C, flex, ...) need to share files, they have to know about each other or write files in a non standard location. Can we decide of a standard location or get a standard API to know about all the section and where they are going to reside. Could we totally eliminate the need for P::RD or other by declaring to Inline::C what functions we want to define (Not nice at all but very cost effective) It might seem that I bang on P:RD each and every line but I am not. It's a module fun to use (except for no left recursion :-) but for massive amount of data, it is too slow. I still think the solution using 'nm' would be best. Nadim.
