cpptool-develop — CppRefactory Developer Mailing List

[Cpptool-develop] Re: Changes for symbol extraction by grammar keywords...

[Baptiste L. <gai...@fr...>]

Great ! I look into this. I'm curious to see how you integrated the parse=
r
with the symbol table. Though, to me it seems difficult to integrated the
symbol parsing with the symbol table (you need some tough 'undo' in case =
a
rule fails to match and has already made some change in the symbol table)=
.

Changing the examples stuff was the correct thing to do. The src/ don't h=
ave
unit test execution environment yet.

To debug C++ extension, you put something like:
Debug program:
python.exe

Argument:
E:\prg\vc\CppParser\src\pyrfta\dumpnodetree.py
E:\prg\vc\CppParser\src\pyrfta\samples\sources\declspec.h.tree

Working directory:
E:\prg\vc\CppParser\src\pyrfta

in the debugging tab of your c++ extension project.

Good luck with your second child ;-)

Baptiste.

----- Original Message -----=20
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>;
"Baptiste Lepilleur" <gai...@fr...>
Sent: Friday, August 20, 2004 9:34 PM
Subject: Changes for symbol extraction by grammar keywords...


> Hello Baptiste,
>
> I checked in the proposed changes to the grammar for symbol extraction.
> A simple case the declaration of a class-id has been integrated into th=
e
> cpp_grammar.txt file
> and the symboldeclarator code for this part has been deactivated.
>
> I used the "example" branch since it runs fine with my vc6 and also
> debugging c++ problems
> from the running python environment was not yet comfortable for me yet.
> any suggestions ?
>
> greetings,
> from Andr=E9
>
> My holiday has ended today - we will see when i find time for some more
> coding.
> (will not be easy with my second child born now :-)
>
>

[Cpptool-develop] Changes for symbol extraction by grammar keywords...

[Andre B. <and...@gm...>]

Hello Baptiste,

I checked in the proposed changes to the grammar for symbol extraction.
A simple case the declaration of a class-id has been integrated into the 
cpp_grammar.txt file
and the symboldeclarator code for this part has been deactivated.

I used the "example" branch since it runs fine with my vc6 and also 
debugging c++ problems
from the running python environment was not yet comfortable for me yet. 
any suggestions ?

greetings,
from André

My holiday has ended today - we will see when i find time for some more 
coding.
(will not be easy with my second child born now :-)

Re: [Cpptool-develop] About extracting symbol information

[Baptiste L. <gai...@fr...>]

Well, you could certainly extends the parser to do something like that. =
Though, you would have to use something similar to :node instead of =
push/pop (it's a stupid backtracking parser: it tries all alternatives =
and backtracks on failure. pop() would never be called in the case of a =
partially matched rule. It's one of the reason why it's so slow).

That being said, I've been thinking in the last few days about what's =
need to be done to do a 'type' aware parser.

The first major issue is that you need multiple passes to resolve =
symbols. Example:

class A {
    int size() const { return size_; }   // size_ is refered to before =
being declared.
    int size_;
};

Clearly all symbols in function bodies need to be resolved after =
declaring all the 'outer' stuff, but the detail aren't clear for me yet. =
There might be similar issues with function parameter types and default =
value (and maybe a similar case with template parameter default value).

The second issue is handling (template) function and 'type' overload =
(template specialization). The current symbol table is clearly not =
suited for this. If a symbol is either a function or a template type, =
then in a given scope, you have N valid declaration to look up to find =
the correct overloading.

The python ast.py module actually extracts most of the node information =
and wraps them in typed node which are much easier to use (mostly =
class/members stuff aren't wrapped yet). My guess is that the next step =
is probably to try to implement a more robust symbol table with =
multi-passes tree traversal around those typed nodes. While the current =
cppparser has some bugs it's often correct. So the current tree output =
would provide a good base to design the symbol table and find out how =
the multi-pass stuff should works.

By the way, an overview of the declaration node structures can be found =
in src/cppparser/grammar_tree.txt.

Baptiste
----- Original Message -----=20
  From: Andre Baresel=20
  To: CppTool Mailing List=20
  Sent: Tuesday, August 17, 2004 10:08 AM
  Subject: [Cpptool-develop] About extracting symbol information


  Hello baptiste,

  Have you ever thought about moving the symbol extraction part also =
into the grammar ?
  I've notice this idea on a parser-generator language and was wondering =
if the same mechanism
  can help us to simplify the work of symboltable extraction. Currently =
it's not so easy to synchronize
  the cpp_grammar.txt file and the "symboldeclarator.cpp" where symbol =
extraction takes place.
  what about extending the grammar-syntax by keywords for symbol =
extraction. Some examples:

  Entry-Point:
  translation_unit =3D :enterscope('translation-unit') :node( =
'translation_unit', declaration_seq ) :leavescope;

  Declaring a class:

  class_head_name =3D :node( 'class_name',
      optional_alternative( :node('dll_macro', id ),
                            ?( :node('nested_name_specifier', =
nested_name_specifier) )=20
                            [:node('id', id) | template_id] ) );

  class_head =3D class_key ?( class_head_name ) ?( base_clause );

  class_specifier =3D :node( 'class_specifier', class_head =
:declareSymbol('class',$subnode('class_name') )=20
                             :enterscope('class-scope', =
:subnode('class_name'))
                             '{' ?( member_specification ) '}'=20
                              :leavescope
                              );

  New scope declaration extension:
  named_namespace_definition =3D 'namespace' id :push($2) namespace_body =
:pop;      ## $2 means second element which is 'id'

  namespace_body =3D '{' :enterscope($top) declaration_seq :leavescope =
'}'; ## $top is the top element in element stack

  unnamed_namespace_definition =3D 'namespace' :push('<>') =
namespace_body :pop;

  namespace_definition =3D :node( 'named_namespace_def', =
named_namespace_definition )
                       | :node( 'unnamed_namespace_def', =
unnamed_namespace_definition )
                       ;

  I'm not sure about that push/pop mechanism, but I think we need =
something to propagate information across=20
  none-terminal-elements.

  :enterscope(<string>)
  :enterscope(<scope-type>,<named-node>)
  :leavescope
  :push(<string>)
  :push(<number>)
  :push(<named-node>)
  :pop
  :subnode(<string>)

  What do you think about this ? I haven't read through the parser-code =
for grammar, so I don't know about the pit falls.

  greetings from=20
  Andr=E9

  ------------------------------------------------------- SF.Net email =
is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic =
DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off =
Retail on Ink & Toner - Free Shipping and Free Gift. =
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 =
_______________________________________________ Cpptool-develop mailing =
list Cpp...@li... =
https://lists.sourceforge.net/lists/listinfo/cpptool-develop 

[Cpptool-develop] About extracting symbol information

[Andre B. <and...@gm...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello baptiste,<br>
<br>
Have you ever thought about moving the symbol extraction part also into
the grammar ?<br>
I've notice this idea on a parser-generator language and was wondering
if the same mechanism<br>
can help us to simplify the work of symboltable extraction. Currently
it's not so easy to synchronize<br>
the cpp_grammar.txt file and the "symboldeclarator.cpp" where symbol
extraction takes place.<br>
what about extending the grammar-syntax by keywords for symbol
extraction. Some examples:<br>
<br>
<b></b><b>Entry-Point:</b><br>
translation_unit = <b>:enterscope('translation-unit')</b> :node(
'translation_unit', declaration_seq ) <b>:leavescope</b>;<br>
<br>
<b>Declaring a class:</b><br>
<br>
class_head_name = :node( 'class_name',<br>
&nbsp;&nbsp;&nbsp; optional_alternative( :node('dll_macro', id ),<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ?( :node('nested_name_specifier',
nested_name_specifier) ) <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [:node('id', id) | template_id] ) );<br>
<br>
class_head = class_key ?( class_head_name ) ?( base_clause );<br>
<br>
class_specifier = :node( 'class_specifier', class_head <b>:declareSymbol('class',$subnode('class_name')
)</b> <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp; <b>:enterscope('class-scope',
:subnode('class_name'))</b><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '{' ?( member_specification ) '}' <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; &nbsp;&nbsp; <b>:leavescope</b><br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; );<br>
<br>
<b>New scope declaration extension:</b><br>
named_namespace_definition = 'namespace' id <b>:push($2)</b>
namespace_body <b>:pop</b>;&nbsp;&nbsp; &nbsp;&nbsp; ## $2 means second element which is
'id'<br>
<br>
namespace_body = '{' <b>:enterscope($top) </b>declaration_seq <b>:leavescope
</b>'}'; ## $top is the top element in element stack<br>
<br>
unnamed_namespace_definition = 'namespace' <b>:push('&lt;&gt;')</b>
namespace_body <b>:pop</b>;<br>
<br>
namespace_definition = :node( 'named_namespace_def',
named_namespace_definition )<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | :node( 'unnamed_namespace_def',
unnamed_namespace_definition )<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ;<br>
<br>
I'm not sure about that push/pop mechanism, but I think we need
something to propagate information across <br>
none-terminal-elements.<br>
<br>
<b>:enterscope(&lt;string&gt;)<br>
:enterscope(&lt;scope-type&gt;,&lt;named-node&gt;)<br>
:leavescope<br>
:push(&lt;string&gt;)<br>
</b><b>:push(&lt;number&gt;)</b><br>
<b>:push(&lt;named-node&gt;)<br>
:pop<br>
:subnode(&lt;string&gt;)<br>
<br>
</b>What do you think about this ? I haven't read through the
parser-code for grammar, so I don't know about the pit falls.<br>
<br>
greetings from <br>
Andr&eacute;<br>
<br>
</body>
</html>

[Cpptool-develop] python dumpast output inspection result...

[Baptiste L. <gai...@fr...>]

    Well, one of the purpose behind dumpast was to be able to carefully
review the output of the c++ parser on some 'real' life sources.

    I managed to find some (unplanned) parsing issue due to the fuzzy
nature of the parser (it doesn't know about types):

---
1)
CTag* newtag = new CTag(searchresult->taglist[i]->tag);

Is not parsed as a declaration, but an expression were CTag and newtag are
variable  (a*b)

2)
CBarShader CPartFile::s_LoadBar(PROGRESS_HEIGHT);

Is parsed as a declaration of a function pointer instead of a declaration
with a constructor (assumes that PROGRESS_HEIGHT is a type).
---

   The first issue is particularly annoying. None of thoses issues have
simple fixes (would require to make the parser knowing about type in some
way). While the parser is great for prototyping, I would trust production
work on it.

    That being said, it still usefull for prototyping and did provide
interesting input on how to mix preprocessing, c++ parsing and refactoring.
I started looking into ANTLR to implement a serious parser with type
handling last week. I'm currently toying with the tinyc grammar to get
features similar to our framework for ast manipulations and ast to source
conversion.

    Baptiste.

Re: [Cpptool-develop] Got my first run with python as entry point...

[Baptiste L. <gai...@fr...>]

dumpast is the 'real' tool. dumpnodetree is just something I needed on th=
e
way (one great thing about python is that it takes no time to make a
project). I haven't been able to spent much time on this project in the l=
ast
few month, and using python always help me reduce the time to implement a=
n
idea. It is also a language which is much 'softer' than c++ and it is eas=
ier
to implement something, discard it and replacing it with something else.

The goal was simply to 'get' this project moving. I did get some feedback
from the dumpast tool. See my other mail.

Baptiste.

----- Original Message -----=20
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Monday, August 16, 2004 1:26 PM
Subject: [Cpptool-develop] Got my first run with python as entry point...


> Hello baptiste,
>
> the good news -  I got it working, the dumpnodetree works as expected.
> However, at the moment I do not understand the reason of using python.
> Can you explain my shortly, what are the goals of this ?
>
> thanks in advance,
> Andr=E9

Re: [Cpptool-develop] Another question about DLL-Linking...

[Baptiste L. <gai...@fr...>]

warning 4251 is 'normal'. You always get it when exporting class containing
STL stuff in VC 6.

Heap error aren't normal. I don't get any of those under vc 7.1. Try
checking if all the projects use the same version of the run-time library.

Baptiste.

----- Original Message ----- 
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Monday, August 16, 2004 8:38 PM
Subject: [Cpptool-develop] Another question about DLL-Linking...


> Hello Baptiste,
>
> with VC6 i get warnings C4251 when compiling the DLLs and under Python I
> get many Heap-Check errors during the
> execution of the code (with ignoring them the correct output is done).
>
> But these pointer problems seem to be not related...
>
> Some examples:
>
> f:\projects\cpptool\cppparser\include\rfta\cppparser\token.h(117) :
> warning C4251: 'ids_' : class 'std::map<class
> Parser::ConstString,unsigned int,struct std::less<class
> Parser::ConstString>,class std::allocator<unsigned int> >' needs to have
> dll-in terface to be used by clients of class 'Parser::TokenIdManager'
> f:\projects\cpptool\cppparser\include\rfta\cppparser\token.h(119) :
> warning C4251: 'texts_' : class 'std::map<unsigned int,class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> >,struct std::less<unsigned int>,class s
> td::allocator<class std::basic_string<char,struct
> std::char_traits<char>,class std::allocator<char> > > >' needs to have
> dll-interface to be used by clients of class 'Parser::TokenIdManager'
> f:\projects\cpptool\cppparser\include\rfta\cppparser\token.h(146) :
> warning C4251: 'types_' : class 'std::map<class
> Parser::ConstString,class Parser::TokenType,struct std::less<class
> Parser::ConstString>,class std::allocator<class Parser::TokenType>
>  >' needs to have dll-interface to be used by clients of class
> 'Parser::TokenTypeManager'
> f:\projects\cpptool\cppparser\include\rfta\cppparser\token.h(148) :
> warning C4251: 'names_' : class 'std::map<class Parser::TokenType,class
> Parser::ConstString,struct std::less<class Parser::TokenType>,class
> std::allocator<class Parser::ConstString>
>  >' needs to have dll-interface to be used by clients of class
> 'Parser::TokenTypeManager'
> f:\projects\cpptool\cppparser\include\rfta\cppparser\node.h(51) :
> warning C4251: 'current_' : class 'boost::intrusive_ptr<class
> Parser::Node>' needs to have dll-interface to be used by clients of
> class 'Parser::NodeEnumerator'
> f:\projects\cpptool\cppparser\include\rfta\cppparser\node.h(70) :
> warning C4251: 'parents_' : class 'std::stack<class Parser::Node *,class
> std::deque<class Parser::Node *,class std::allocator<class Parser::Node
> *> > >' needs to have dll-interface to
>  be used by clients of class 'Parser::DepthFirstEnumerator'
> f:\projects\cpptool\cppparser\include\rfta\cppparser\node.h(233) :
> warning C4251: 'firstChild_' : class 'boost::intrusive_ptr<class
> Parser::Node>' needs to have dll-interface to be used by clients of
> class 'Parser::Node'
> f:\projects\cpptool\cppparser\include\rfta\cppparser\node.h(235) :
> warning C4251: 'nextSibling_' : class 'boost::intrusive_ptr<class
> Parser::Node>' needs to have dll-interface to be used by clients of
> class 'Parser::Node'
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>

Re: [Cpptool-develop] debugging example/cppparser/tests

[Baptiste L. <gai...@fr...>]

No it's current boost CVS (very close to 1.32 which should hopefully be
released soon). Though, you probably should be able to compile it with 1.=
31,
but I might have used some boost.python specific to the current CVS.

Baptiste.

----- Original Message -----=20
From: "Andre Baresel" <and...@gm...>
To: "Baptiste Lepilleur" <gai...@fr...>; "CppTool Mailing List"
<Cpp...@li...>
Sent: Monday, August 16, 2004 8:47 PM
Subject: Re: [Cpptool-develop] debugging example/cppparser/tests


>
> >src/* should compile (under vc 7.1, I haven't updated the vc 6 project=
s,
and
> >I doubt vc6 can compile the boost.python stuff). Are you still using v=
c 6
?
> >
> >
> >
> is this Boost 1.31.0 ?
> I got the latest version of boost working  (regexp and python libraries=
).
>
> greetings,
> Andr=E9
>
>

Re: [Cpptool-develop] debugging example/cppparser/tests

[Andre B. <and...@gm...>]

>src/* should compile (under vc 7.1, I haven't updated the vc 6 projects, and
>I doubt vc6 can compile the boost.python stuff). Are you still using vc 6 ?
>
>  
>
is this Boost 1.31.0 ?
I got the latest version of boost working  (regexp and python libraries).

greetings,
André

[Cpptool-develop] Another question about DLL-Linking...

[Andre B. <and...@gm...>]

Hello Baptiste,

with VC6 i get warnings C4251 when compiling the DLLs and under Python I 
get many Heap-Check errors during the
execution of the code (with ignoring them the correct output is done).

But these pointer problems seem to be not related...

Some examples:

f:\projects\cpptool\cppparser\include\rfta\cppparser\token.h(117) : 
warning C4251: 'ids_' : class 'std::map<class 
Parser::ConstString,unsigned int,struct std::less<class 
Parser::ConstString>,class std::allocator<unsigned int> >' needs to have 
dll-in terface to be used by clients of class 'Parser::TokenIdManager'
f:\projects\cpptool\cppparser\include\rfta\cppparser\token.h(119) : 
warning C4251: 'texts_' : class 'std::map<unsigned int,class 
std::basic_string<char,struct std::char_traits<char>,class 
std::allocator<char> >,struct std::less<unsigned int>,class s
td::allocator<class std::basic_string<char,struct 
std::char_traits<char>,class std::allocator<char> > > >' needs to have 
dll-interface to be used by clients of class 'Parser::TokenIdManager'
f:\projects\cpptool\cppparser\include\rfta\cppparser\token.h(146) : 
warning C4251: 'types_' : class 'std::map<class 
Parser::ConstString,class Parser::TokenType,struct std::less<class 
Parser::ConstString>,class std::allocator<class Parser::TokenType>
 >' needs to have dll-interface to be used by clients of class 
'Parser::TokenTypeManager'
f:\projects\cpptool\cppparser\include\rfta\cppparser\token.h(148) : 
warning C4251: 'names_' : class 'std::map<class Parser::TokenType,class 
Parser::ConstString,struct std::less<class Parser::TokenType>,class 
std::allocator<class Parser::ConstString>
 >' needs to have dll-interface to be used by clients of class 
'Parser::TokenTypeManager'
f:\projects\cpptool\cppparser\include\rfta\cppparser\node.h(51) : 
warning C4251: 'current_' : class 'boost::intrusive_ptr<class 
Parser::Node>' needs to have dll-interface to be used by clients of 
class 'Parser::NodeEnumerator'
f:\projects\cpptool\cppparser\include\rfta\cppparser\node.h(70) : 
warning C4251: 'parents_' : class 'std::stack<class Parser::Node *,class 
std::deque<class Parser::Node *,class std::allocator<class Parser::Node 
*> > >' needs to have dll-interface to
 be used by clients of class 'Parser::DepthFirstEnumerator'
f:\projects\cpptool\cppparser\include\rfta\cppparser\node.h(233) : 
warning C4251: 'firstChild_' : class 'boost::intrusive_ptr<class 
Parser::Node>' needs to have dll-interface to be used by clients of 
class 'Parser::Node'
f:\projects\cpptool\cppparser\include\rfta\cppparser\node.h(235) : 
warning C4251: 'nextSibling_' : class 'boost::intrusive_ptr<class 
Parser::Node>' needs to have dll-interface to be used by clients of 
class 'Parser::Node'

[Cpptool-develop] Got my first run with python as entry point...

[Andre B. <and...@gm...>]

Hello baptiste,

the good news -  I got it working, the dumpnodetree works as expected.
However, at the moment I do not understand the reason of using python.
Can you explain my shortly, what are the goals of this ?

thanks in advance,
André

Re: [Cpptool-develop] debugging example/cppparser/tests

[Baptiste L. <gai...@fr...>]

nodetracker.cpp & nodetrackertest.cpp should not be part of the =
cppparser sources (there's the stuff to modifying the source tree =3D> =
refactoring).

Baptiste.
  ----- Original Message -----=20
  From: Andre Baresel=20
  To: CppTool Mailing List=20
  Sent: Friday, August 13, 2004 10:59 AM
  Subject: Re: [Cpptool-develop] debugging example/cppparser/tests


  Hello baptiste,


I'm not sure about the status of the two source trees at the moment.
However I could not get the "src/*" tree compiled because of missing
    files.
  header for Nodetracking and nodetrackingtest are missing !


For that reason I continued to look through "example/cppparser/tests".
Aspecially the refactoring tests were intressting for me
"refactoring/test1.cpp - test6.cpp
   =20
src/* should compile (under vc 7.1, I haven't updated the vc 6 projects, =
and
I doubt vc6 can compile the boost.python stuff). Are you still using vc =
6 ?

By the way, test6.cpp is not in CVS.
  this is my own creation while playing arround with the code... I want =
to extend the tests a little bit
  to understand whats going on...

  ------------------------------------------------------- SF.Net email =
is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic =
DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off =
Retail on Ink & Toner - Free Shipping and Free Gift. =
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 =
_______________________________________________ Cpptool-develop mailing =
list Cpp...@li... =
https://lists.sourceforge.net/lists/listinfo/cpptool-develop 

Re: [Cpptool-develop] python startup ok, but nothing happens with "dumpast.py"

[Baptiste L. <gai...@fr...>]

To you the python script, you need to:
- copy boost_python_debug.dll dll to src/pyrfta
- copy rfta_cppparser_vc7_mdd.dll to src/pyrfta
- copy src/cppparser/cpp_grammar.txt to src/pyrfta

You must use python 2.3.x (which I used to compile boost.python, or
recompile boost.python for your specific version).

There is two usable script:
- dumpnodetree.py source_file
  Dump the output from cppparser (the 'raw' node tree)

- dumpast.py source_file
  Dump a typed ast tree (using python wrapper around node, see ast.py for
the hierarchy). It's much more readable than dumpnodetree.py, but not all
wrapping have been implemented yet (it will fail with classes for example).
I've added a small set of sources that works with this tools in the samples
subdir.

Baptiste.

----- Original Message ----- 
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Friday, August 13, 2004 9:55 PM
Subject: [Cpptool-develop] python startup ok, but nothing happens with
"dumpast.py"


> Hello Baptiste,
>
> do you know what's going wrong - I got the first .py files running (dlls
> of extension modules are loaded).
> however nothing happens after startup:
>
> F:\Projects\Cpptool\CppParser\src>c:\programme\python23\python -v -u
> pyrfta\dump
> ast.py  F:\Projects\Cpptool\CppParser\src\cppparser\commandstream.cpp
> # installing zipimport hook
> import zipimport # builtin
> # installed zipimport hook
> # c:\programme\python23\lib\site.pyc matches
> c:\programme\python23\lib\site.py
> import site # precompiled from c:\programme\python23\lib\site.pyc
> # c:\programme\python23\lib\os.pyc matches c:\programme\python23\lib\os.py
> import os # precompiled from c:\programme\python23\lib\os.pyc
> import nt # builtin
> # c:\programme\python23\lib\ntpath.pyc matches
> c:\programme\python23\lib\ntpath.py
> import ntpath # precompiled from c:\programme\python23\lib\ntpath.pyc
> # c:\programme\python23\lib\stat.pyc matches
> c:\programme\python23\lib\stat.py
> import stat # precompiled from c:\programme\python23\lib\stat.pyc
> # c:\programme\python23\lib\UserDict.pyc matches
> c:\programme\python23\lib\UserDict.py
> import UserDict # precompiled from c:\programme\python23\lib\UserDict.pyc
> # c:\programme\python23\lib\copy_reg.pyc matches
> c:\programme\python23\lib\copy_reg.py
> import copy_reg # precompiled from c:\programme\python23\lib\copy_reg.pyc
> # c:\programme\python23\lib\types.pyc matches
> c:\programme\python23\lib\types.py
>
> import types # precompiled from c:\programme\python23\lib\types.pyc
> # c:\programme\python23\lib\locale.pyc matches
> c:\programme\python23\lib\locale.py
> import locale # precompiled from c:\programme\python23\lib\locale.pyc
> import _locale # builtin
> # c:\programme\python23\lib\codecs.pyc matches
> c:\programme\python23\lib\codecs.py
> import codecs # precompiled from c:\programme\python23\lib\codecs.pyc
> import _codecs # builtin
> import encodings # directory c:\programme\python23\lib\encodings
> # c:\programme\python23\lib\encodings\__init__.pyc matches
> c:\programme\python23\lib\encodings\__init__.py
> import encodings # precompiled from
> c:\programme\python23\lib\encodings\__init__.pyc
> # c:\programme\python23\lib\encodings\cp1252.pyc matches
> c:\programme\python23\lib\encodings\cp1252.py
> import encodings.cp1252 # precompiled from
> c:\programme\python23\lib\encodings\cp1252.pyc
> # c:\programme\python23\lib\warnings.pyc matches
> c:\programme\python23\lib\warnings.py
> import warnings # precompiled from c:\programme\python23\lib\warnings.pyc
> # c:\programme\python23\lib\linecache.pyc matches
> c:\programme\python23\lib\linecache.py
> import linecache # precompiled from
c:\programme\python23\lib\linecache.pyc
> Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
> # F:\Projects\Cpptool\CppParser\src\pyrfta\pycppparser.pyc matches
> F:\Projects\Cpptool\CppParser\src\pyrfta\pycppparser.py
> import pycppparser # precompiled from
> F:\Projects\Cpptool\CppParser\src\pyrfta\pycppparser.pyc
> import pycppparser_ # dynamically loaded from
> F:\Projects\Cpptool\CppParser\src\pyrfta\pycppparser_.pyd
> # F:\Projects\Cpptool\CppParser\src\pyrfta\ast.pyc matches
> F:\Projects\Cpptool\CppParser\src\pyrfta\ast.py
> import ast # precompiled from
> F:\Projects\Cpptool\CppParser\src\pyrfta\ast.pyc
> # F:\Projects\Cpptool\CppParser\src\pyrfta\nodetools.pyc matches
> F:\Projects\Cpptool\CppParser\src\pyrfta\nodetools.py
> import nodetools # precompiled from
> F:\Projects\Cpptool\CppParser\src\pyrfta\nodetools.pyc
> ----
> nothing after this point ...

[Cpptool-develop] python startup ok, but nothing happens with "dumpast.py"

[Andre B. <and...@gm...>]

Hello Baptiste,

do you know what's going wrong - I got the first .py files running (dlls 
of extension modules are loaded).
however nothing happens after startup:

F:\Projects\Cpptool\CppParser\src>c:\programme\python23\python -v -u 
pyrfta\dump
ast.py  F:\Projects\Cpptool\CppParser\src\cppparser\commandstream.cpp
# installing zipimport hook
import zipimport # builtin
# installed zipimport hook
# c:\programme\python23\lib\site.pyc matches 
c:\programme\python23\lib\site.py
import site # precompiled from c:\programme\python23\lib\site.pyc
# c:\programme\python23\lib\os.pyc matches c:\programme\python23\lib\os.py
import os # precompiled from c:\programme\python23\lib\os.pyc
import nt # builtin
# c:\programme\python23\lib\ntpath.pyc matches 
c:\programme\python23\lib\ntpath.py
import ntpath # precompiled from c:\programme\python23\lib\ntpath.pyc
# c:\programme\python23\lib\stat.pyc matches 
c:\programme\python23\lib\stat.py
import stat # precompiled from c:\programme\python23\lib\stat.pyc
# c:\programme\python23\lib\UserDict.pyc matches 
c:\programme\python23\lib\UserDict.py
import UserDict # precompiled from c:\programme\python23\lib\UserDict.pyc
# c:\programme\python23\lib\copy_reg.pyc matches 
c:\programme\python23\lib\copy_reg.py
import copy_reg # precompiled from c:\programme\python23\lib\copy_reg.pyc
# c:\programme\python23\lib\types.pyc matches 
c:\programme\python23\lib\types.py

import types # precompiled from c:\programme\python23\lib\types.pyc
# c:\programme\python23\lib\locale.pyc matches 
c:\programme\python23\lib\locale.py
import locale # precompiled from c:\programme\python23\lib\locale.pyc
import _locale # builtin
# c:\programme\python23\lib\codecs.pyc matches 
c:\programme\python23\lib\codecs.py
import codecs # precompiled from c:\programme\python23\lib\codecs.pyc
import _codecs # builtin
import encodings # directory c:\programme\python23\lib\encodings
# c:\programme\python23\lib\encodings\__init__.pyc matches 
c:\programme\python23\lib\encodings\__init__.py
import encodings # precompiled from 
c:\programme\python23\lib\encodings\__init__.pyc
# c:\programme\python23\lib\encodings\cp1252.pyc matches 
c:\programme\python23\lib\encodings\cp1252.py
import encodings.cp1252 # precompiled from 
c:\programme\python23\lib\encodings\cp1252.pyc
# c:\programme\python23\lib\warnings.pyc matches 
c:\programme\python23\lib\warnings.py
import warnings # precompiled from c:\programme\python23\lib\warnings.pyc
# c:\programme\python23\lib\linecache.pyc matches 
c:\programme\python23\lib\linecache.py
import linecache # precompiled from c:\programme\python23\lib\linecache.pyc
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
# F:\Projects\Cpptool\CppParser\src\pyrfta\pycppparser.pyc matches 
F:\Projects\Cpptool\CppParser\src\pyrfta\pycppparser.py
import pycppparser # precompiled from 
F:\Projects\Cpptool\CppParser\src\pyrfta\pycppparser.pyc
import pycppparser_ # dynamically loaded from 
F:\Projects\Cpptool\CppParser\src\pyrfta\pycppparser_.pyd
# F:\Projects\Cpptool\CppParser\src\pyrfta\ast.pyc matches 
F:\Projects\Cpptool\CppParser\src\pyrfta\ast.py
import ast # precompiled from 
F:\Projects\Cpptool\CppParser\src\pyrfta\ast.pyc
# F:\Projects\Cpptool\CppParser\src\pyrfta\nodetools.pyc matches 
F:\Projects\Cpptool\CppParser\src\pyrfta\nodetools.py
import nodetools # precompiled from 
F:\Projects\Cpptool\CppParser\src\pyrfta\nodetools.pyc
----
nothing after this point ...

[Cpptool-develop] VC6 compilation does work, how to run the python stuff ?

[Andre B. <and...@gm...>]

hello baptiste,

regex and python modules of the lastest boost-version "1.31.0" are 
compiled (one fix in a header was needed).
pycppparser project  also compiles without an error.
How do I get the things running in Phyton ? I've got the DLLs
"pycppparser.dll"
"cppparser.dll"
and of course cpput_.....dll

greetings,
André

Re: [Cpptool-develop] debugging example/cppparser/tests

[Andre B. <and...@gm...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hello baptiste,<br>
<br>
<blockquote cite="mid005701c48104$a6649b40$1c24223e@lain" type="cite">
  <blockquote type="cite">
    <pre wrap="">
I'm not sure about the status of the two source trees at the moment.
However I could not get the "src/*" tree compiled because of missing
    </pre>
  </blockquote>
  <pre wrap=""><!---->files.
  </pre>
</blockquote>
header for Nodetracking and nodetrackingtest are missing !<br>
<br>
<blockquote cite="mid005701c48104$a6649b40$1c24223e@lain" type="cite">
  <blockquote type="cite">
    <pre wrap="">For that reason I continued to look through "example/cppparser/tests".
Aspecially the refactoring tests were intressting for me
"refactoring/test1.cpp - test6.cpp
    </pre>
  </blockquote>
  <pre wrap=""><!---->
src/* should compile (under vc 7.1, I haven't updated the vc 6 projects, and
I doubt vc6 can compile the boost.python stuff). Are you still using vc 6 ?

By the way, test6.cpp is not in CVS.
  </pre>
</blockquote>
this is my own creation while playing arround with the code... I want
to extend the tests a little bit<br>
to understand whats going on...<br>
<br>
</body>
</html>

Re: [Cpptool-develop] debugging example/cppparser/tests

[Baptiste L. <gai...@fr...>]

----- Original Message ----- 
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Thursday, August 12, 2004 11:14 AM
Subject: [Cpptool-develop] debugging example/cppparser/tests


> hello Baptiste,
>
> I'm not sure about the status of the two source trees at the moment.
> However I could not get the "src/*" tree compiled because of missing
files.
> For that reason I continued to look through "example/cppparser/tests".
> Aspecially the refactoring tests were intressting for me
> "refactoring/test1.cpp - test6.cpp

src/* should compile (under vc 7.1, I haven't updated the vc 6 projects, and
I doubt vc6 can compile the boost.python stuff). Are you still using vc 6 ?

By the way, test6.cpp is not in CVS.

Baptiste.

Re: [Cpptool-develop] debugging example/cppparser/tests

[Baptiste L. <gai...@fr...>]

You're correct, there's something broken (but then, I've been growing thi=
s
on a test basis).

I think something along the line of:

>      Parser::SymbolDeclarationPtr declaration =3D table.findDeclaration=
At(
> location );
    Parser::DeclarationPtrEnum enumDeclarations =3D
table.enumSiblingDeclaration( declaration ); // the enum includes
'declaration'. Give all declarations that resolve into the same qualified
identifier based on global scope.

    (e.g. you're second option).

Baptiste.

----- Original Message -----=20
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Thursday, August 12, 2004 11:14 AM
Subject: [Cpptool-develop] debugging example/cppparser/tests


> hello Baptiste,
>
> I'm not sure about the status of the two source trees at the moment.
> However I could not get the "src/*" tree compiled because of missing
files.
> For that reason I continued to look through "example/cppparser/tests".
> Aspecially the refactoring tests were intressting for me
> "refactoring/test1.cpp - test6.cpp
>
> I found out that the symboltable generates two entries for the
> declarations "class C1;" and "class C1 { .... }".
>
> SymbolDeclarator::declareClass     inserts:
>    SymbolDeclarationPtr declaration =3D symbolTable_.declare( classSymb=
ol );
>
> SymbolDeclarator::declareForwardClass   does the same:
>    SymbolDeclarationPtr declaration =3D symbolTable_.declare( classSymb=
ol );
>
> Last but not least the member "symboltable.declare" does:
> SymbolTable::declare( const Symbol &symbol )
> {
>    SymbolDeclarationPtr declaration( new SymbolDeclaration( symbol ) );
>    references_[ declaration ].push_back( symbol.location() );
>    return declaration;
> }
>
> =3D=3D=3D=3D=3D=3D
> this leads to a hashmap "references_" which has two entries.
>
> During refactoring tests the test code asks for the declaration at
> position 'x':
>      Parser::SymbolDeclarationPtr declaration =3D table.findDeclaration=
At(
> location );
>
> This will only return a single declaration and it's references. However=
,
> all other forward declarations are missed.
>
> Possible solutions are:
> - model the declaration type differently, such that multiple locations
> of declarations are possible
>    (sounds a little bit ugly)
> - make references between all forward-declarations and declarations,
> these need to be two way
>    links, because the user could select the forward-declaration for
> rename-operation...
>
> any idea ?
> greetings from Berlin,
> Andr=E9

Re: [Cpptool-develop] "boost/regex/v4/regex.hpp" is not compilable with VC6 ...

[Baptiste L. <gai...@fr...>]

Could you be a little more specific, I can't figure out what you're refer=
ing
too.

Are you using the new dependency ? I couldn't get v3 to compile on vc 7.1=
...

Baptiste.

----- Original Message -----=20
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Thursday, August 12, 2004 10:36 AM
Subject: [Cpptool-develop] "boost/regex/v4/regex.hpp" is not compilable w=
ith
VC6 ...


> Hello Baptiste,
>
> this is something wired - why is this subclass-use "basic_regex" inside
> a base class "reg_expression"
> that smells a little bit... isn't it ? A base class should not know
> about their childs ... a design rule ?
> anyway "v3" works.
>
> until later,
> Andr=E9
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>

Re: [Cpptool-develop] Question for "refactoringtest3"

[Baptiste L. <gai...@fr...>]

src/cppparser is a library which contains only the 'parser' part of
examples/parser. It does not contains the symbol/refactoring stuff.

I did this to be able to create pycppparser (python binding for the parse=
r).

Since I haven't made a project for the 'refactoring' part (and enabled un=
it
test in the cppparser dll), I still leaving examples/parser around.

Baptiste.

----- Original Message -----=20
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Thursday, August 12, 2004 10:22 AM
Subject: [Cpptool-develop] Question for "refactoringtest3"


> Hello Baptiste,
>
> I was just checking some parts of the code.
> What is the difference between the sourcetree "example/parser" and
> "src/cppparser" ?
>
> have a nice day,
> Andr=E9
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>

[Cpptool-develop] debugging example/cppparser/tests

[Andre B. <and...@gm...>]

hello Baptiste,

I'm not sure about the status of the two source trees at the moment.
However I could not get the "src/*" tree compiled because of missing files.
For that reason I continued to look through "example/cppparser/tests".
Aspecially the refactoring tests were intressting for me 
"refactoring/test1.cpp - test6.cpp

I found out that the symboltable generates two entries for the
declarations "class C1;" and "class C1 { .... }".

SymbolDeclarator::declareClass     inserts:
   SymbolDeclarationPtr declaration = symbolTable_.declare( classSymbol );

SymbolDeclarator::declareForwardClass   does the same:
   SymbolDeclarationPtr declaration = symbolTable_.declare( classSymbol );

Last but not least the member "symboltable.declare" does:
SymbolTable::declare( const Symbol &symbol )
{
   SymbolDeclarationPtr declaration( new SymbolDeclaration( symbol ) );
   references_[ declaration ].push_back( symbol.location() );
   return declaration;
}

======
this leads to a hashmap "references_" which has two entries.

During refactoring tests the test code asks for the declaration at 
position 'x':
     Parser::SymbolDeclarationPtr declaration = table.findDeclarationAt( 
location );

This will only return a single declaration and it's references. However,
all other forward declarations are missed.

Possible solutions are:
- model the declaration type differently, such that multiple locations 
of declarations are possible
   (sounds a little bit ugly)
- make references between all forward-declarations and declarations, 
these need to be two way
   links, because the user could select the forward-declaration for 
rename-operation...

any idea ?
greetings from Berlin,
André

[Cpptool-develop] "boost/regex/v4/regex.hpp" is not compilable with VC6 ...

[Andre B. <and...@gm...>]

Hello Baptiste,

this is something wired - why is this subclass-use "basic_regex" inside 
a base class "reg_expression"
that smells a little bit... isn't it ? A base class should not know 
about their childs ... a design rule ?
anyway "v3" works.

until later,
André

[Cpptool-develop] Question for "refactoringtest3"

[Andre B. <and...@gm...>]

Hello Baptiste,

I was just checking some parts of the code.
What is the difference between the sourcetree "example/parser" and 
"src/cppparser" ?

have a nice day,
André

Re: [Cpptool-develop] Fixes for VS6 compilation...

[Baptiste L. <gai...@fr...>]

Thanks for fixing this. I haven't use VC6 in a while.

You can remove the failing test by removing it from the __test__.txt list=
.
It's a bit like saying what's the next thing to do.

Here is the big picture:
- symboldeclarator walk the parsed node tree and declare symbols and scop=
es
in the symbol table.
- the refactoringtest use the symbol table to find occurrences of a speci=
fic
identifier.

Baptiste.

----- Original Message -----=20
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Monday, August 09, 2004 12:26 PM
Subject: [Cpptool-develop] Fixes for VS6 compilation...


> hello baptiste,
>
> A few fixes for compiling the code under VC6:
>
> - the code is compilable with "v3" of regexpr.
> - one additional problem is the type "std::size_t" which is not defined
> that way in VC6
>    When using "size_t" instead, the code is fully compilable.
> - the files "symboltabletestprocessor" were not in the project ... is
fixed.
> - with this all tests run through only one failes:
>      Testing 'All Tests/SymbolTableTest/variable1.txt' : ASSERTION
>      don't know how to check node type: variable
>      At line: 5, column: 1
>      Failures: 1, Tested: 182
>    "I think you expected this ;-)"
>
> I'm going through the code...
>
> greetings,
> Andr=E9
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technolog=
y
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>

Re: [Cpptool-develop] CppParser not compilable because of not actual dependencies.rar (sourceforge-download)

[Baptiste L. <gai...@fr...>]

I've uploaded the new dependency packaged required to compile the
pycppparser (boost.python binding to use the parser in python). It's for
VC++ 7.1 only (I doubt VC6 could handle the python binding).

You need to copy all the dll (cppparser,pycppparser to python/). Then you
can use dumpast.py or dumpnodetree.py to inpsect the produced ast.

Baptiste.

----- Original Message -----=20
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Monday, August 09, 2004 12:16 PM
Subject: [Cpptool-develop] CppParser not compilable because of not actual
dependencies.rar (sourceforge-download)


> Hello Baptiste,
>
> the following compile error occures when compiling current files
> together with "CppParser_Dependencies_CVS20040608.rar"
>
>    cpptool\cppparser\examples\parser\cpplexer.cpp(3) : fatal error
> C1083: Cannot open include file: 'boost/regex/v4/regex.hpp': No such
> file or directory
>
> This is because in the RAR-File the directory "boost/regex/v3/" exists.=
.
>
> greetings from berlin.
> Andr=E9
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by OSTG. Have you noticed the changes on
> Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
> one more big change to announce. We are now OSTG- Open Source Technolog=
y
> Group. Come see the changes on the new OSTG site. www.ostg.com
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>