Menu
▾
▴
cpptool-develop
|
From: Andre B. <and...@gm...> - 2003-07-28 15:18:32
|
Hello together, I'm back from workaholic days and 2 weeks holiday - I had some stressful and horrible days at work, after this two nice week holiday in austria and one week at a conference in chicago... Now I'm a little bit more relaxed and there's time for some coding. I plan to play arround with some refactoring at code level, just to use the new features of the parser and show what's possible with our implementation ... until later, andré |
|
From: Baptiste L. <gai...@fr...> - 2003-07-31 21:52:59
|
Welcome back Andre. I been fairly drained by work for the last month too. Though, I did divert a bit of time working on CppUnit V2. I ported the 'mini parser' core to python last week-end, so it would be easier to prototype a robust parser implementation. Current results are v= ery positive. You can find it in src/pyrfta/test/rfta/parser.py and parsertest.py. To run it, just install python 2.2 (you can get it from python.org), and run src/pyrfta/test/alltests.py. Notes that the parser u= se a tokenizer. Personnally, I would be enclined to move the full parser to python (it ta= kes a lot of less time to produce code in python), and only move it back to C= ++ when it's the only way remaining to improve performance. Python is a very simple language to grasp (about 2 hours to go through the tutorial), and = its dynamic nature make it very malleable. For instance, "::NameSpace::MyClass::myVar" is parsed using the following parser instantiation (it's actual python code): nested_id_p =3D (maybe_p( "::" ) >> list_p( id_p, symbol_p('::') ))[inline_child_at_a(1)]['nested_id'] =3D> it parse for an optinal '::' at the beginning, the a list of id sepa= rated by '::'. The trailing code in square brackets are action used to manipula= te the produced tree and name the resulting node. Parsing '::NameSpace::MyClass::myVar' Node(nested_id : 6 children) |-Token(symbol,'::') |-Token(id,'NameSpace') |-Token(symbol,'::') |-Token(id,'MyClass') |-Token(symbol,'::') |-Token(id,'myVar') I still need to add an action to filter out the '::' that occurs in the list, but that's it. A dummy 'class' declaration parser I wrote (just to experiment), look lik= e this: class_inheritance_p =3D maybe_p( (symbol_p( ":" ) >> anyuntil_p( "{" ))['inheritance'] ) null_statement_p =3D eos_p['null_statement'] class_body_statements_p =3D null_statement_p class_inheritance_and_body_decl_p =3D class_inheritance_p >> "{" >> maybe_p(class_body_statements_p) >> "}" class_decl_p =3D (symbol_p("class") | "struct") >> nested_id_p \ >> maybe_p( class_inheritance_and_body_decl_p ) >> eos_p Which produce the following tree when parsing: Parsing 'class MyClass : public MyParent<MyClass,simple_traits> { };' Node(? : 5 children) |-Token(symbol,'class') |-Node(nested_id : 2 children) |-|-NONE | |-Token(id,'MyClass') |-NONE |-Node(? : 4 children) | |-Node(inheritance : 2 children) | | |-Token(symbol,':') | | |-Node(? : 7 children) | | | |-Token(symbol,'public') | | | |-Token(id,'MyParent') | | | |-Token(symbol,'<') | | | |-Token(id,'MyClass') | | | |-Token(symbol,',') | | | |-Token(id,'simple_traits') | | | |-Token(symbol,'>') | |-Token(symbol,'{') |-|-NONE | |-Token(symbol,'}') |-Token(symbol,';') The inheritance is not parsed here, because I'd like to implement a mecan= ism to make a local parsing. We know were the inheritance declaration starts = and ends, this should help parsing potential templated inheritance more robustly, doing a 'sub parsing' on the specific token range. The interesting part is that you can still write 'hand written' parser to handle real weird case if needed. There is still much to work out, but it= 's really promising. Baptiste. ----- Original Message -----=20 From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Monday, July 28, 2003 5:30 PM Subject: [Cpptool-develop] Back on CPP-Refactoring ... > Hello together, > > I'm back from workaholic days and 2 weeks holiday - > > I had some stressful and horrible days at work, after this two nice wee= k > holiday > in austria and one week at a conference in chicago... > > Now I'm a little bit more relaxed and there's time for some coding. > I plan to play arround with some refactoring at code level, > just to use the new features of the parser and show what's > possible with our implementation ... > > until later, > andr=E9 |
|
From: Andre B. <and...@gm...> - 2003-08-03 11:01:37
|
> > >Welcome back Andre. > thanks :-) >I ported the 'mini parser' core to python last week-end, so it would be >easier to prototype a robust parser implementation. Current results are very >positive. > << skipped >> >The inheritance is not parsed here, because I'd like to implement a mecanism >to make a local parsing. We know were the inheritance declaration starts and >ends, this should help parsing potential templated inheritance more >robustly, doing a 'sub parsing' on the specific token range. > >The interesting part is that you can still write 'hand written' parser to >handle real weird case if needed. There is still much to work out, but it's >really promising. > Sounds interesting - well it's good to have you, just so open minded to even throw away ugly looking code ;-) ... Sometimes I'm not so relaxed - since so much time has been spend on the written code ... But I like your idea. It's looking much more simple than the complex stuff in the declaration parser. At the moment I would like to work a little bit on the refactoring features, just to show that the things are going on there, too. btw) I've checked again the eclipse pages for CDT (that the C/C++ Developer Plugin). At the moment their implementation is planned to work with an XML representation of the parsed C/C++ code. this weekend is so hot here in berlin - 35 degrees. until later, André |
|
From: Baptiste L. <gai...@fr...> - 2003-08-12 07:11:41
|
----- Original Message -----=20 From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Sunday, August 03, 2003 1:13 PM Subject: Re: [Cpptool-develop] Back on CPP-Refactoring ... > > [...] > >The interesting part is that you can still write 'hand written' parser= to > >handle real weird case if needed. There is still much to work out, but it's > >really promising. > > > Sounds interesting - well it's good to have you, just so open minded to > even throw away ugly looking > code ;-) ... Sometimes I'm not so relaxed - since so much time has been > spend on the written code ... > But I like your idea. It's looking much more simple than the complex > stuff in the declaration parser. I like to think that I managed to keep the feature that worked well (leve= l of detail parsing, recursive LL descendent parser), and discarded the feature that got in the way (lazy parsing (it's an optimisation. Can be reintroduced anyway), explicit node type/properties declaration (ASTNodes stuff) ). There is still some features to add: - balanced brace matching with subparsing of brace content and creation o= f an 'error' node if subparsing failed. - probably extend the parse stuff so that the parser can match 'node tree= ' as well as token. This would allow us to roughly parse an expression whic= h failed to be parsed as an expression and extract the 'qualified identifier...' I started debugging some of the expression parsing. As I expected there i= s a need to introduce a 'match longuest alternative' parser (on the way). > At the moment I would like to work a little bit on the refactoring > features, just to show that Could you clarify, I'm not sure I understand what you'll be working on exactly. > the things are going on there, too. btw) I've checked again the eclipse > pages for CDT (that the C/C++ > Developer Plugin). At the moment their implementation is planned to wor= k > with an XML representation > of the parsed C/C++ code. > this weekend is so hot here in berlin - 35 degrees. Well, here in Paris we have been cooking under 35-40 degress for the last two weeks... Well, it's time for me to take some vacantion. I'll be away for the next = two weeks. Baptiste. > until later, > Andr=E9 |
Thanks for helping keep SourceForge clean.
X