Menu
▾
▴
cpptool-develop — CppRefactory Developer Mailing List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(33) |
Nov
(51) |
Dec
(134) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(18) |
Feb
(11) |
Mar
(1) |
Apr
(55) |
May
(29) |
Jun
(1) |
Jul
(2) |
Aug
(5) |
Sep
(4) |
Oct
|
Nov
|
Dec
(6) |
| 2004 |
Jan
(1) |
Feb
(11) |
Mar
(4) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(27) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andre B. <and...@gm...> - 2004-08-09 10:27:05
|
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é
|
|
From: Andre B. <and...@gm...> - 2004-08-09 10:16:42
|
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é |
|
From: Baptiste L. <gai...@fr...> - 2004-06-13 15:24:09
|
Well, we should really have done this a year ago. It's based on sources
back from 2003/08/25, the last compilable/working version I found.
It has been tagged in CVS with RFTA_REL_0_1.
Source & precompiled add-ins are available for download on sourceforge
download page:
http://www.sourceforge.net/projects/cpptool
You'll need boost 1.30.2 to compile the sources. It's available in the
'build dependencies' download.
Have fun,
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2004-06-10 17:57:23
|
I finally moved the new parser approach in the CVS. It is in the module
/CppParser. Check out the wiki for details.
Build dependencies required to build the project can be download from
the project page.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2004-06-10 17:56:10
|
I've updated the web site. Wiki now use MoinMoin wiki, which have a
better help and nicer functionnalities. I also added the backup cron I'm
running on CppUnit to backup the wiki.
The homepage has been removed and redirect to the wiki homepage (a page
with a 2 years old date in the news section is BAD)...
I've put in some content related to rfta & the new parser. I also upload
a demo video of the rename local variable refactoring on the
RefactoringAssistant page.
Backup are accessible from:
http://cpptool.sourceforge.net/backup
You can also force a backup creation by running
python autobackup.py
in /home/groups/c/cp/cpptool/bin.
Backup are not world writable.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2004-03-08 20:45:34
|
I've just made a breakthrough concerning refactoring code that contains
alternative code blocks selected by the preprocessor (#if #else #endif
stuffs).
The solution is fairly simple: the transformation that represents a
refactoring applied on a source with multiple code alternatives is the union
of the transformations of the refactoring applied on each code alternative.
Take for example the following slice of code (from boost.filesystem):
---
inline bool dot_or_dot_dot( const char * name )
{
# if !BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT(0x0564) )
return std::strcmp( name, "." ) == 0
|| std::strcmp( name, ".." ) == 0;
# else
return name[0]=='.'
&& (name[1]=='\0' || (name[1]=='.' && name[2]=='\0'));
# endif
}
---
Say you want to rename the parameter 'name'.
You first apply the refactoring on the code using the first alternative.
You obtains a first set of transformations.
Then, you apply the refactoring on the code using the second
alternative. You obtains a second set of transformations.
Adding the two sets of transformation give you the transformation to two
for this refactoring.
There is still a lot to be worked out (how to you select code
alternatives in a coherent way...), but I believe there core idea is there.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2004-03-03 20:22:17
|
I fixed the cvs commit notification. We're now using a version of a
syncmail script that generates those notifications that is kept up to date
by the sourceforge team. So we shouldn't have anymore troubles.
For notes, this is documented in sf doc CVS/Enhancing Project CVS
Services Using Scripts:
http://sourceforge.net/docman/display_doc.php?docid=772&group_id=1
And the syncmail project can be found at:
http://sourceforge.net/projects/cvs-syncmail/
Though, there is no public release that contains the bug fix (bug the
CVS should be ok).
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2004-03-02 19:10:16
|
----- Original Message -----=20 From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Tuesday, March 02, 2004 3:04 PM Subject: [Cpptool-develop] new parser approach - compile and test success= ful > just a short message - compiling the project works now. > "All 168 tests passed..." what about the time for each test step - does > it initialize > the complete syntax each time ? Yes, the grammar was being parsed and build each time. I can't believe I hadn't though of that (I had a similar problem that was even worth with boost regular expression compilation for the lexer). I switched to a singleton and build time went down from 30s to 8s. Thanks !!! > I will now look through the code and also check the problem with vc6 plugin. Great. Once it's stable I'd like us to release the current version. Hopefully, this will attract some people. Baptiste. > until later, > andr=E9 |
|
From: Andre B. <and...@gm...> - 2004-03-02 14:17:56
|
just a short message - compiling the project works now. "All 168 tests passed..." what about the time for each test step - does it initialize the complete syntax each time ? I will now look through the code and also check the problem with vc6 plugin. until later, andré |
|
From: Baptiste L. <gai...@fr...> - 2004-02-29 09:04:07
|
Thanks, I finally got the project to build correctly. Though, when I inst= all the VC6 add-in, I always got a crash when trying to apply the rename loca= l variable refactoring. Do you have the same issue ? Concerning CVS, I also have similar message. They probably changed someth= ing in the server configuration. I'll try to investigate this when I got the time. Baptiste. ----- Original Message -----=20 From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Sunday, February 29, 2004 1:50 AM Subject: [Cpptool-develop] fixed problem with "textdocumentmock" > hello together - sorry for late fix, no spare time for this during the > last weeks. > when checking in I got the message - > ________________________________________________ > Traceback (most recent call last): > File "/cvsroot/cpptool/CVSROOT/syncmail", line 322, in ? > main() > File "/cvsroot/cpptool/CVSROOT/syncmail", line 315, in main > blast_mail(subject, people, specs[1:], contextlines, fromhost) > File "/cvsroot/cpptool/CVSROOT/syncmail", line 221, in blast_mail > conn.connect(MAILHOST, MAILPORT) > File "/usr/lib/python2.2/smtplib.py", line 276, in connect > for res in socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM): > socket.gaierror: (-2, 'Name or service not known') > ________________________________________________ > so maybe no cvs message will be generated. > > sincelery, > andr=E9 |
|
From: Andre B. <and...@gm...> - 2004-02-29 01:02:08
|
hello together - sorry for late fix, no spare time for this during the
last weeks.
when checking in I got the message -
________________________________________________
Traceback (most recent call last):
File "/cvsroot/cpptool/CVSROOT/syncmail", line 322, in ?
main()
File "/cvsroot/cpptool/CVSROOT/syncmail", line 315, in main
blast_mail(subject, people, specs[1:], contextlines, fromhost)
File "/cvsroot/cpptool/CVSROOT/syncmail", line 221, in blast_mail
conn.connect(MAILHOST, MAILPORT)
File "/usr/lib/python2.2/smtplib.py", line 276, in connect
for res in socket.getaddrinfo(host, port, 0, socket.SOCK_STREAM):
socket.gaierror: (-2, 'Name or service not known')
________________________________________________
so maybe no cvs message will be generated.
sincelery,
andré
|
|
From: Baptiste L. <gai...@fr...> - 2004-02-25 08:11:29
|
cpptool was a previous experimentation that did not produce anything usable. The current project is rfta. So you should do: cvs -d:pserver:ano...@cv...:/cvsroot/cpptool login cvs -z3 -d:pserver:ano...@cv...:/cvsroot/cpptool co rfta There is some doc in the docs/ directory. Notes that I've been having trouble getting the lastest version to compile & run. I'm waiting Andre feedback on this. Also, I'm currently working on a new approach to this project. It can be found at: http://gaiacrtn.free.fr/backup/ Just grab the most recent version of the cppparser project. It does do any refactoring yet, but some of the basic components for this are there... Interesting stuff to look at are in examples/parser. cpp_grammar.txt: the grammar cppparsertest.cpp: the unit test for the grammar nodetracker.cpp/nodetrackertest.cpp: proof of concept for ast modification that automatically update the source parser.h/parsercontext.h: parsing framework commandstream.cpp/commandstreamtest.cpp: converts the parser production into an ast. Baptiste. ----- Original Message ----- From: "??" <li...@ki...> To: "cpptool-develop" <cpp...@li...> Sent: Wednesday, February 25, 2004 6:07 AM Subject: [Cpptool-develop] Help: how to checkout the source code of CppRefactory? > I've tried these commands: > cvs -d:pserver:ano...@cv...:/cvsroot/cpptool login > cvs -z3 -d:pserver:ano...@cv...:/cvsroot/cpptool co cpptool > But only got a directory as below: > > $ ls -R cpptool > cpptool: > CVS Docs > > cpptool/CVS: > Entries Entries.Extra Repository Root > > cpptool/Docs: > CVS readme.txt > > cpptool/Docs/CVS: > Entries Entries.Extra Repository Root > |
|
From: ?? <li...@ki...> - 2004-02-25 05:17:00
|
I've tried these commands:
cvs -d:pserver:ano...@cv...:/cvsroot/cpptool login
cvs -z3 -d:pserver:ano...@cv...:/cvsroot/cpptool co cpptool
But only got a directory as below:
$ ls -R cpptool
cpptool:
CVS Docs
cpptool/CVS:
Entries Entries.Extra Repository Root
cpptool/Docs:
CVS readme.txt
cpptool/Docs/CVS:
Entries Entries.Extra Repository Root
|
|
From: Baptiste L. <gai...@fr...> - 2004-02-24 20:24:36
|
I added the project and depdency lib for VC++ 6.0. Did some code clean =
up and removed usage of token text inside the parser framework =
(TokenType is now a composite of token category and symbol id). I'll =
probably try to do a proof of concept for the preprocessor and renaming =
of macro parameters.
Baptiste.
----- Original Message -----=20
From: Baptiste Lepilleur=20
To: CppTool Mailing List=20
Sent: Sunday, February 15, 2004 10:42 PM
Subject: Re: [Cpptool-develop] C++ parser progress...
Added some basic template support and fixed a serious bug (pointer =
were not allowed as function return type). It is now possible to have =
template declaration (class, function).
The CppParserTest::testTranslationUnit() test is a good place to start =
playing with the parser. It contains a few code snippet. If you want to =
see the produced ast, change the assertion macro to =
CPPPARSER_ASSERT_TREE and add a dummy testNode("").
Baptiste.
----- Original Message -----=20
From: Baptiste Lepilleur=20
To: CppTool Mailing List=20
Sent: Saturday, February 14, 2004 9:53 PM
Subject: Re: [Cpptool-develop] C++ parser progress...
Port finished and error recovery added. Uploaded at the same place.
I'll try to enhance the template support before moving back to the =
nodetracker.
Baptiste.
----- Original Message -----=20
From: Baptiste Lepilleur=20
To: CppTool Mailing List=20
Sent: Saturday, February 14, 2004 11:13 AM
Subject: Re: [Cpptool-develop] C++ parser progress...
Well, I've ported the expression parsing. After a rough start =
(some bug that went unoticed before in the grammar builder), I'm now =
progressing quickly (about 25% of the port is done).
The most recent version can be found in:
http://gaiacrtn.free.fr/backup/
just peek the most recent version of cppparser.
Interesting stuff to look at are in examples/parser.
cpp_grammar.txt: the grammar
cppparsertest.cpp: the unit test for the grammar
nodetracker.cpp/nodetrackertest.cpp: proof of concept for ast =
modification that automatically update the source
parser.h/parsercontext.h: parsing framework
commandstream.cpp/commandstreamtest.cpp: converts the parser =
production into an ast.
Baptiste.
----- Original Message -----=20
From: Baptiste Lepilleur=20
To: CppTool Mailing List=20
Sent: Monday, February 09, 2004 11:13 PM
Subject: [Cpptool-develop] C++ parser progress...
Some news about the C++ parser I'm working on...
I've ported the core parser framework to C++. I've also =
decided to abstract the grammar away in a text file instead of =
executable code. This greatly improve grammar readability and avoid some =
mistakes that can easily be made when writing grammar in C++ (or python =
for the matter). This will also make the grammar much less sensible to =
change of the actual implementation of the parser (which I can see that =
evolving a lot).
I'll tackle the actual port the C++ grammar written in =
python to C++ soon. I'm still undecided on weither I should also =
abstract the unit test into text file or having them in code...
I have implemented a proof of concept of 'update the AST and =
get the modified source'. It handles insertion and removal of node =
(which can be composite node). It currently assumes the a depth first =
traversal of the ast tree will process the token node is the 'source' =
order. Giving a quick look at the python unit test, I didn't see this as =
being a false assertion (It can be worked around if need be, but it =
would complicate things a lot).
If a preprocessor was postprocessing the lexer tokens, it =
could tag macros parameter occurrence as special 'token'. That way, when =
renaming that token we could detect that it is an actual macro parameter =
occurrence and renaming should be done at the macro call. This would =
allow dealing with a lot of macros occurence (for example renaming a =
method present in a CPPUNIT_TEST macro).
=20
A snapshot of the sources is available at:
http://gaiacrtn.free.fr/backup/CppParser-20040209-22h30.rar
It includes VC++ 2003 projects, cppunit 2, boost and =
precompiled regex librairies for VC++ 2003.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2004-02-15 21:44:59
|
Added some basic template support and fixed a serious bug (pointer were =
not allowed as function return type). It is now possible to have =
template declaration (class, function).
The CppParserTest::testTranslationUnit() test is a good place to start =
playing with the parser. It contains a few code snippet. If you want to =
see the produced ast, change the assertion macro to =
CPPPARSER_ASSERT_TREE and add a dummy testNode("").
Baptiste.
----- Original Message -----=20
From: Baptiste Lepilleur=20
To: CppTool Mailing List=20
Sent: Saturday, February 14, 2004 9:53 PM
Subject: Re: [Cpptool-develop] C++ parser progress...
Port finished and error recovery added. Uploaded at the same place.
I'll try to enhance the template support before moving back to the =
nodetracker.
Baptiste.
----- Original Message -----=20
From: Baptiste Lepilleur=20
To: CppTool Mailing List=20
Sent: Saturday, February 14, 2004 11:13 AM
Subject: Re: [Cpptool-develop] C++ parser progress...
Well, I've ported the expression parsing. After a rough start (some =
bug that went unoticed before in the grammar builder), I'm now =
progressing quickly (about 25% of the port is done).
The most recent version can be found in:
http://gaiacrtn.free.fr/backup/
just peek the most recent version of cppparser.
Interesting stuff to look at are in examples/parser.
cpp_grammar.txt: the grammar
cppparsertest.cpp: the unit test for the grammar
nodetracker.cpp/nodetrackertest.cpp: proof of concept for ast =
modification that automatically update the source
parser.h/parsercontext.h: parsing framework
commandstream.cpp/commandstreamtest.cpp: converts the parser =
production into an ast.
Baptiste.
----- Original Message -----=20
From: Baptiste Lepilleur=20
To: CppTool Mailing List=20
Sent: Monday, February 09, 2004 11:13 PM
Subject: [Cpptool-develop] C++ parser progress...
Some news about the C++ parser I'm working on...
I've ported the core parser framework to C++. I've also =
decided to abstract the grammar away in a text file instead of =
executable code. This greatly improve grammar readability and avoid some =
mistakes that can easily be made when writing grammar in C++ (or python =
for the matter). This will also make the grammar much less sensible to =
change of the actual implementation of the parser (which I can see that =
evolving a lot).
I'll tackle the actual port the C++ grammar written in python =
to C++ soon. I'm still undecided on weither I should also abstract the =
unit test into text file or having them in code...
I have implemented a proof of concept of 'update the AST and =
get the modified source'. It handles insertion and removal of node =
(which can be composite node). It currently assumes the a depth first =
traversal of the ast tree will process the token node is the 'source' =
order. Giving a quick look at the python unit test, I didn't see this as =
being a false assertion (It can be worked around if need be, but it =
would complicate things a lot).
If a preprocessor was postprocessing the lexer tokens, it =
could tag macros parameter occurrence as special 'token'. That way, when =
renaming that token we could detect that it is an actual macro parameter =
occurrence and renaming should be done at the macro call. This would =
allow dealing with a lot of macros occurence (for example renaming a =
method present in a CPPUNIT_TEST macro).
=20
A snapshot of the sources is available at:
http://gaiacrtn.free.fr/backup/CppParser-20040209-22h30.rar
It includes VC++ 2003 projects, cppunit 2, boost and =
precompiled regex librairies for VC++ 2003.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2004-02-14 20:56:25
|
Port finished and error recovery added. Uploaded at the same place. I'll try to enhance the template support before moving back to the = nodetracker. Baptiste. ----- Original Message -----=20 From: Baptiste Lepilleur=20 To: CppTool Mailing List=20 Sent: Saturday, February 14, 2004 11:13 AM Subject: Re: [Cpptool-develop] C++ parser progress... Well, I've ported the expression parsing. After a rough start (some = bug that went unoticed before in the grammar builder), I'm now = progressing quickly (about 25% of the port is done). The most recent version can be found in: http://gaiacrtn.free.fr/backup/ just peek the most recent version of cppparser. Interesting stuff to look at are in examples/parser. cpp_grammar.txt: the grammar cppparsertest.cpp: the unit test for the grammar nodetracker.cpp/nodetrackertest.cpp: proof of concept for ast = modification that automatically update the source parser.h/parsercontext.h: parsing framework commandstream.cpp/commandstreamtest.cpp: converts the parser = production into an ast. Baptiste. ----- Original Message -----=20 From: Baptiste Lepilleur=20 To: CppTool Mailing List=20 Sent: Monday, February 09, 2004 11:13 PM Subject: [Cpptool-develop] C++ parser progress... Some news about the C++ parser I'm working on... I've ported the core parser framework to C++. I've also decided = to abstract the grammar away in a text file instead of executable code. = This greatly improve grammar readability and avoid some mistakes that = can easily be made when writing grammar in C++ (or python for the = matter). This will also make the grammar much less sensible to change of = the actual implementation of the parser (which I can see that evolving a = lot). I'll tackle the actual port the C++ grammar written in python to = C++ soon. I'm still undecided on weither I should also abstract the unit = test into text file or having them in code... I have implemented a proof of concept of 'update the AST and get = the modified source'. It handles insertion and removal of node (which = can be composite node). It currently assumes the a depth first traversal = of the ast tree will process the token node is the 'source' order. = Giving a quick look at the python unit test, I didn't see this as being = a false assertion (It can be worked around if need be, but it would = complicate things a lot). If a preprocessor was postprocessing the lexer tokens, it could = tag macros parameter occurrence as special 'token'. That way, when = renaming that token we could detect that it is an actual macro parameter = occurrence and renaming should be done at the macro call. This would = allow dealing with a lot of macros occurence (for example renaming a = method present in a CPPUNIT_TEST macro). =20 A snapshot of the sources is available at: http://gaiacrtn.free.fr/backup/CppParser-20040209-22h30.rar It includes VC++ 2003 projects, cppunit 2, boost and precompiled = regex librairies for VC++ 2003. Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2004-02-14 10:15:27
|
Well, I've ported the expression parsing. After a rough start (some bug = that went unoticed before in the grammar builder), I'm now progressing = quickly (about 25% of the port is done). The most recent version can be found in: http://gaiacrtn.free.fr/backup/ just peek the most recent version of cppparser. Interesting stuff to look at are in examples/parser. cpp_grammar.txt: the grammar cppparsertest.cpp: the unit test for the grammar nodetracker.cpp/nodetrackertest.cpp: proof of concept for ast = modification that automatically update the source parser.h/parsercontext.h: parsing framework commandstream.cpp/commandstreamtest.cpp: converts the parser production = into an ast. Baptiste. ----- Original Message -----=20 From: Baptiste Lepilleur=20 To: CppTool Mailing List=20 Sent: Monday, February 09, 2004 11:13 PM Subject: [Cpptool-develop] C++ parser progress... Some news about the C++ parser I'm working on... I've ported the core parser framework to C++. I've also decided to = abstract the grammar away in a text file instead of executable code. = This greatly improve grammar readability and avoid some mistakes that = can easily be made when writing grammar in C++ (or python for the = matter). This will also make the grammar much less sensible to change of = the actual implementation of the parser (which I can see that evolving a = lot). I'll tackle the actual port the C++ grammar written in python to = C++ soon. I'm still undecided on weither I should also abstract the unit = test into text file or having them in code... I have implemented a proof of concept of 'update the AST and get = the modified source'. It handles insertion and removal of node (which = can be composite node). It currently assumes the a depth first traversal = of the ast tree will process the token node is the 'source' order. = Giving a quick look at the python unit test, I didn't see this as being = a false assertion (It can be worked around if need be, but it would = complicate things a lot). If a preprocessor was postprocessing the lexer tokens, it could = tag macros parameter occurrence as special 'token'. That way, when = renaming that token we could detect that it is an actual macro parameter = occurrence and renaming should be done at the macro call. This would = allow dealing with a lot of macros occurence (for example renaming a = method present in a CPPUNIT_TEST macro). =20 A snapshot of the sources is available at: http://gaiacrtn.free.fr/backup/CppParser-20040209-22h30.rar It includes VC++ 2003 projects, cppunit 2, boost and precompiled = regex librairies for VC++ 2003. Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2004-02-09 22:14:02
|
Some news about the C++ parser I'm working on...
I've ported the core parser framework to C++. I've also decided to =
abstract the grammar away in a text file instead of executable code. =
This greatly improve grammar readability and avoid some mistakes that =
can easily be made when writing grammar in C++ (or python for the =
matter). This will also make the grammar much less sensible to change of =
the actual implementation of the parser (which I can see that evolving a =
lot).
I'll tackle the actual port the C++ grammar written in python to C++ =
soon. I'm still undecided on weither I should also abstract the unit =
test into text file or having them in code...
I have implemented a proof of concept of 'update the AST and get the =
modified source'. It handles insertion and removal of node (which can be =
composite node). It currently assumes the a depth first traversal of the =
ast tree will process the token node is the 'source' order. Giving a =
quick look at the python unit test, I didn't see this as being a false =
assertion (It can be worked around if need be, but it would complicate =
things a lot).
If a preprocessor was postprocessing the lexer tokens, it could tag =
macros parameter occurrence as special 'token'. That way, when renaming =
that token we could detect that it is an actual macro parameter =
occurrence and renaming should be done at the macro call. This would =
allow dealing with a lot of macros occurence (for example renaming a =
method present in a CPPUNIT_TEST macro).
=20
A snapshot of the sources is available at:
http://gaiacrtn.free.fr/backup/CppParser-20040209-22h30.rar
It includes VC++ 2003 projects, cppunit 2, boost and precompiled =
regex librairies for VC++ 2003.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2004-02-07 18:58:30
|
I finally got some free time to look into this, but I run into some issue= s: - it seems that (src/rftaparser/)/TextDocumentMock.h is missing. Did you forgot to add it to the CVS ? Also, when compiling and installing the release configuration (only one I can compile easily), there is a crash when I try to use the rename local variable command. Did you run into this too ? (I add to completly reinsta= ll my system last month, so there may be some oddities remaining)... I've updated the README with the installation step for the vc6 add-in, yo= u might want to give it a look... Baptiste. ----- Original Message -----=20 From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Tuesday, January 13, 2004 11:50 PM Subject: [Cpptool-develop] Preprocessor implementation added to repositor= y > I have just added the current implementation. Some small tests are > written in preprocessor unit test code. > However <include> mechanism has been deactivated in the plugins because > no implementation for open > and changing multiple files is done yet (look at interface > 'sourcemanager'). AstDumper uses a simple > implementation of sourcemanager accessing the header files by file > system (FileSourceManager) - however > the limitations of parsing expressions of '#ifdef' and '#if' do not > allow to parse usual system headers correctly. > For that reason I deactivcated the includes by setting the preprocessor > option 'skipIncludes'. > > Output of correct parsing error positions inside included files is wron= g > because of problems in position > translation. That problem needs to be checked. > > not much time in the next weeks, > until later, > Andr=E9 |
|
From: Andre B. <and...@gm...> - 2004-02-07 16:39:42
|
project status:
- first refactorings have been implemented
- parser is working for a large set of c++ code
- simple preprocessor implementation has been implemented which enables us
to work on code containing macros and includes - such that the
refactorings keep preprocessed code as it is
- an approach on formatted code rewriting has been implemented for
easier code transformations
- a python based parser has been started to solve the problem with
complex parser decisions (e.g. declaration parsing)
overview on the code:
* rfta is the main directory (forget about the others)
* the following modules have been defined:
- rftaparser (DLL) .... parser and preprocessor
- rfta (DLL) ..... refactoring operations
- pyrfta ..... python based parser
- rftavc6addin ..... Plugin for Visual Studio
- eclipseplugin ..... Plugin for Eclipse IDE
- astdump ..... Test tool for dumping an AST parsed by
'rftaparser' module
|
|
From: Andre B. <and...@gm...> - 2004-01-13 22:50:14
|
I have just added the current implementation. Some small tests are written in preprocessor unit test code. However <include> mechanism has been deactivated in the plugins because no implementation for open and changing multiple files is done yet (look at interface 'sourcemanager'). AstDumper uses a simple implementation of sourcemanager accessing the header files by file system (FileSourceManager) - however the limitations of parsing expressions of '#ifdef' and '#if' do not allow to parse usual system headers correctly. For that reason I deactivcated the includes by setting the preprocessor option 'skipIncludes'. Output of correct parsing error positions inside included files is wrong because of problems in position translation. That problem needs to be checked. not much time in the next weeks, until later, André |
|
From: Andre B. <and...@gm...> - 2003-12-20 23:43:45
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> </head> <body> I'm fine with these ideas - this tracker concept will be the thing that can be taken from<br> the codemodel. The "micro ast transformation" is something to have in background when<br> starting with the real big refactoring operations, i agree.<br> <br> About that macro / preprocessing stuff.<br> <pre wrap="">> An issue that is not solved by the above idea is macro handling. It's clear > that macro should be expanded for correct parsing, but we also need to be > able to track the parameters passed to macro. For example, if a type is > passed to a macro as a parameter, we need to be able to rename the parameter > passed to the macro instead of its expanded instance. Also, some refactoring > may operate on macro (rename macro...), though in this case, it might be > easier to make a specific parser... Well, I think there's no real chance to get arround to do this preprocessing before parsing. However, a possible solution could be - and is implemented by the current preprocessor class - to save all changes done during preprocessing and use this information for later textual transformation of the refactoring. So that the needed transformations recognized in the preprocessed code can be mapped to the locations in the original code. e.g. A macro replacement changes the offset of all characters coming after the macro replacement area. At the moment only simple replacements can be handled. However, I see the chance to get this working even with the '#include' directive and parameterized macros - so that the preprocessor really includes the given header file (transformations are than mapped to the different files by using preprocess information). One hard point would be 'conflicts' where a transformation hits a macro area - here a some clever checking of preprocess information is needed. I have a good feeling that this can work even to track the parameters passed to macro. I'm currently working on this "include" thing. And of course refactoring of the current preprocess code ... and after this parameterized macros. I have added open points in the sourceforge RFE list just for your information. -- have a nice day André </pre> <blockquote type="cite" cite="mid02d001c3c6f9$00230fc0$67c2c3d4@gaia"> <pre wrap=""><!----></pre> </blockquote> <br> </body> </html> |
|
From: Baptiste L. <gai...@fr...> - 2003-12-20 12:49:31
|
The goal of the CodeModel was to provide an easy way to modify the source= . I think it partially succeed: it easier to modify the source, but 'explorin= g' the source structure is tricky (dealing with compound statement is not easy). And, as you point out, it's not easy to maintain. Having written a nearly complete c++ parser, it is clear for me that this approach is not realistic in face of the huge amount of diversity of the = c++ grammar. Those last months, I've being thinking about a new approach to this. My current idea is as follow: - have the lexer generate token for all source elements (this includes spaces and comments) - have the parser generate an AST that contains all those elements - have some kind of generic listener/tracker tracks change to the ast, an= d impacting the source code when requested. Refactoring would be implemented using highly reusable micro ast transformation (instead of a code model). For example, you would have 'insert local variable declaration', 'replace local variable initializer'= ... I'm currently focusing on getting the parser done (at this time lexer spa= ces & comments are discarded). An issue that is not solved by the above idea is macro handling. It's cle= ar that macro should be expanded for correct parsing, but we also need to be able to track the parameters passed to macro. For example, if a type is passed to a macro as a parameter, we need to be able to rename the parame= ter passed to the macro instead of its expanded instance. Also, some refactor= ing may operate on macro (rename macro...), though in this case, it might be easier to make a specific parser... Baptiste. ----- Original Message -----=20 From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Wednesday, December 17, 2003 10:59 PM Subject: [Cpptool-develop] Question for CodeModel... > Hello Baptiste, > > i was checking the codemodel/coderewriter sources and i hope i do > understand now the general > idea of it. this is enough to do the changes needed to add support for > the new macro-replacement > feature. However a general idea arises from looking through the sources > of code model - what is > the main reason to have this parallel implementation of all the > statement/expression/declaration > elements ? Please correct me if i'm wrong, but I have the feeling that > this code makes extensions > and modifications of the ast harder, since the code model needs to be > synchronized manually > (error prone...) wouldn't it be possible to integrate the change > tracking functionality which looks > very clever :-) ... into the ast ? and reuse the ast - visiting to > collect the changes ? > > Well, my changes to the code model do not affect this ... so in next > days there'll be the extension > for code model working with preprocessor. > > bye bye > Andr=E9 |
|
From: Andre B. <and...@gm...> - 2003-12-17 21:59:29
|
Hello Baptiste, i was checking the codemodel/coderewriter sources and i hope i do understand now the general idea of it. this is enough to do the changes needed to add support for the new macro-replacement feature. However a general idea arises from looking through the sources of code model - what is the main reason to have this parallel implementation of all the statement/expression/declaration elements ? Please correct me if i'm wrong, but I have the feeling that this code makes extensions and modifications of the ast harder, since the code model needs to be synchronized manually (error prone...) wouldn't it be possible to integrate the change tracking functionality which looks very clever :-) ... into the ast ? and reuse the ast - visiting to collect the changes ? Well, my changes to the code model do not affect this ... so in next days there'll be the extension for code model working with preprocessor. bye bye André |
|
From: Andre B. <and...@gm...> - 2003-12-16 14:41:47
|
well I regulary check the status of the CDT project since one of the goals of the project is also refactoring operations. Unfortunatly the progress of CDT on refactoring is very small. For version 2.0 in Q2/2003 they plan to implement a write CDOM (Ast as XML document). I do not know how far they are with parsing full c++ code. One reason to continue with CppTool is the open api for any IDE - so as long as there's no real refactoring operation implemented in CDT let's continue... until later andré |
