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: Baptiste L. <gai...@fr...> - 2003-05-24 21:24:35
|
I finally took the time to restore the wiki. I restored the backup from
the 13 december and mixed in reformatted html page from my web browser cache
and google cache.
I believe most of the page are fairly recent, but there might be a few
thing missing.
You can get a backup of the current wiki at:
http://cpptool.sourceforge.net/backup/htdocs.tar.gz
Does anyone know how we could set up a cron task to do that on a daily
basis ?
Notes that the wiki data directory is now htdocs/wiki2 (I couldn't
remove htdocs/wiki, which is weird given that it is supposed to be world
writable...)
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-20 08:27:57
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "Baptiste Lepilleur" <gai...@fr...>; "CppTool Mailing List" <Cpp...@li...> Sent: Friday, May 16, 2003 10:29 AM Subject: Re: [Cpptool-develop] Ready to release ? > > A release is a good idea since the first steps have been done and the > refactoring does work... > > > What should we release ? > > > > > > Binaries version of the add-ins: > >* Visual C++ 6: > > - a simple zip, with install instruction (and a .bat for installation if > >the environment variable is correctly set. Should we bother with a setup ? > >(VC add-in can be deduced from the registry). > > > well, the easiest way for the first would be a ZIP file containing the > files which need to be copied into > the 'addins' directory and a readme-file describing where this file is > located. we do not need to spend > much time on this, since the release is very small. I have added a > possible distribution to this mail. > > >* Eclipse: > > - ? Andre what would be the most convenient for Eclipse user ? Eclipse > >probably have a special place for ad-in announcement. Do we need to prepare > >something for that ? > > > I've attached a ZIP file containing a distribution. A readme file > describes where to unzip the file. > The file "about.html" does contain some about information. Fine with me. Though avoid posting attachement bigger than 60Ko, it's a killer for modem user. > > Source version: > > - zip and/or tar.gz ? > > - do we need more details about the dependencies (were boost should be > >installed) ? I'm thinking of making a 'precompiled dependencies package' > >that could be dropped into deplib/ > > > Well, this is interesting since it should be very easy to get the > compiler running since a badly > documented environment will keep away developers that want to join us. OK. I'll try to prepare that. > > Documentation: > > What do we need to do ? > > - We should probably at least describe each refactoring and their > >limitation. > > - A brief description of each add-in and specifities (VC6 'bad' undo...) > > > > > I'll try for the operation "inline temporary". I started making a small doc for vc7 add-ins. It's in the doc directory. I added a few screenshots. I think we also need a doc for each refactoring (describing the limitation, known pitfall (e.g. inline locale variable should not be used if you take the address of the variable, or rename locale variable does not check if a variable already exist with the same name...). > > We also need to update the home page (cpptool.sf.net). If somebody come > >by, there is no indication that we even got some refactoring working ! > > > > > Well, currently there's nothing. Unfortunatly also the google cache > seems to be a little bit old. > My changes to the full-parser page are not stored. I was actually refering to the PHP page (http://cpptool.sf.net), not the wiki. I think the 'news' section needs to be moved to the wiki, that way it would at least be updated every now and then ;-). Concerning the wiki, I'm waiting for Sven feedback to know if he has a recent backup. In the worth case, I have a tarball from december, and I managed to grab the html form of most of the page from my Internet Explorer cache and google cache. I'll need to merge both and determine which version of each page is the last. Baptiste. > > -- André > > |
|
From: Andre B. <and...@gm...> - 2003-05-16 05:50:43
|
Baptiste Lepilleur wrote:
>Yes, and it's fairly common (pimpl idiom):
>class Main
>{
> class Impl;
>};
>
>class Main::Impl : public BaseImpl
>{
>};
>
>
Oh yes I forgot about that....
>>The miniparser stuff sounds good - seems to go into the direction of the
>>boost parser but a little
>>bit more lightweight. I like this idea, since much code of the
>>declaration parser is not very easy to
>>understand and I do feel that this could make some things easier.
>>
>>
>
>Its strongly inspired from Boost.Spirit, but I took all the thing we don't
>need out, prefering simplicity over flexibility (we can have only one
>scanner, but it's enough for us). I started experimental with after fixing a
>few parsing issues with class declaration. There so much things that could
>be optional and different but similar alternative that the code was getting
>fairly complicated. The parser would solve this if we could get the matched
>ranges out, as well as the matched alternative.
>
yep I strongly agree with this - the declaration parser did get very
complex and in some parts not
very readable.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-15 21:33:15
|
Forgot that point. We need to settle on a license for the project and
update all the headers accordingly.
I agree with the features defined by Sven in the wiki (here is a link to
google cache:
http://www.google.fr/search?q=cache:yX4_QKduraQC:cpptool.sourceforge.net/cgi-bin/wiki.pl%3FCppToolLicense+site:cpptool.sourceforge.net+license&hl=fr&ie=UTF-8).
Here is the feature list:
Necessary Features
a.. compatible with tools and libraries we use:
a.. cppunit
b.. boost
b.. allows us to use the program in conjunction with
a.. VC++6
b.. GNU emacs/ Xemacs
c.. other IDE's
c.. Warranty disclaimer: We can't be responsible if the user's source code
will be screwed up.
Nice Features
a.. easy to read and understand
b.. puts no restrictions on the use of the user's refactored code
("derivative works")
c.. avoid that someone uses the code to build a commercial refactoring
browser (this clause would make it non-open software, so we'll have to think
about it)
d.. no restriction on modification and redistribution of the source code,
provided that the license is preserved
e.. credit to original authors
Finding a license on http://www.opensource.org/ is difficult. The LGPL is
not suitable because it not 'understandable', and is restrictive, even for
other open-source project.
I found a potential candidate in the Eiffel Forum License, Version 1:
http://www.opensource.org/licenses/eiffel.php
I think it meet all the above criteria (I'm not sure what make a license
no compatible with cppunit and boost), but allow for commercial usage. The
interesting aspect is that 'you MUST publicly release the modified version
of the package).
Of course, there would be nothing to prevent them from selling the
product of this project as this, but I can hardly see that working if you
can get the same things for free (we just have to advertise the project
enough). Also, think about it the other way, we would get any change they
would make on the project.
Also, there is no mention concerning derivative works. But I doubt we'll
found many licenses with that. May be we could add a simple statement
granting that permission. Suggestions?
Once this project is mature, it will have a lot of reuse potential.
That's one reason why I'd rather not restrict it too much. For instance, the
parser and the code rewritter are just what a UML tool need for round-trip.
What do you think ?
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-15 20:15:25
|
We have been working on this project for a while now, and I think the
time has come for us to release something.
We don't have much refactorings yet, but they works fairly well. I still
amazed by the excellent result we get with RenameLocaleVariable with the
such a simple implementation.
We have add-ins for 3 popular IDE, which is enough to demonstrate that
it is not tied to a particluar IDE.
Most of the development we currently have underway (full parser, code
rewritter) will take some time before being ready for release, so I think
the time is right for an 'early release'.
What should we release ?
Binaries version of the add-ins:
* Visual C++ 6:
- a simple zip, with install instruction (and a .bat for installation if
the environment variable is correctly set. Should we bother with a setup ?
(VC add-in can be deduced from the registry).
* Visual Studio 7:
- a simple zip with a register.bat and unregister.bat for 'installation'
of the add-in.
- a MSI based installer (generated by VS7). Seems to work fine for me,
but I've seen that failing badly in the past (weird error message).
* Eclipse:
- ? Andre what would be the most convenient for Eclipse user ? Eclipse
probably have a special place for ad-in announcement. Do we need to prepare
something for that ?
Source version:
- zip and/or tar.gz ?
- do we need more details about the dependencies (were boost should be
installed) ? I'm thinking of making a 'precompiled dependencies package'
that could be dropped into deplib/
Documentation:
What do we need to do ?
- We should probably at least describe each refactoring and their
limitation.
- A brief description of each add-in and specifities (VC6 'bad' undo...)
We also need to update the home page (cpptool.sf.net). If somebody come
by, there is no indication that we even got some refactoring working !
Remarks, suggestions ?
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-15 19:30:31
|
----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Thursday, May 15, 2003 6:22 PM
Subject: Re: [Cpptool-develop] astdump runner...
> Baptiste Lepilleur wrote:
> >One idea I had was something like that:
> >
> >CStringView classDecl, className;
> >// parser for: 'class' class-name :
> >const Xtl::MiniParser &parser2 = (Xtl::StringMiniParser( "class " )
> > >>
> >Xtl::CppIdentifierMiniParser()[className]
> > >> Xtl::CharMiniParser(
> >':' ))[classDecl];
> >
> >But this would not work when working with repetition parser (for example,
to
> >match the repetition of ('::' id) ). Any ideas ?
> >
> Well - it should work if the repeatition parser does some look ahead and
> allows only "::" to be 'eaten'
I not clear in my question. I was not refering to 'how to get the (::id)*
pattern to work' (the mini-parser has infinite look-ahead, but how to store
the matched results. When this pattern is matched, you will want the range
of each matched 'token' (:: or id), and the range of the matched pattern.
That same pattern can be part of a much larger one (the begining of a class
declaration). The resulting matched range can be seen as a list, but the
user will need the tree structure to use them. For example, if you match
something like 'class' +(::Id) ?( '{' ... '}') ';', the resulting would look
like something like this:
+ ['class' range]
+ [+(::Id) range]
|-+['::']
|-+[Id]
|-+['::']
|-+[Id]
+ ['{' ... '}'] // may not be present
+ [';']
The user need to be able to request a given matched range easily, but I not
found a simple way to do that yet. The tree structure and optional element
make this difficult, and I'm not even getting into the presence of
alternative...
> (than it will stop at a single colon).
> Apart from that:
> is it possible to declare a class like this
> class XXX::class_name : public C {
> };
Yes, and it's fairly common (pimpl idiom):
class Main
{
class Impl;
};
class Main::Impl : public BaseImpl
{
};
> The miniparser stuff sounds good - seems to go into the direction of the
> boost parser but a little
> bit more lightweight. I like this idea, since much code of the
> declaration parser is not very easy to
> understand and I do feel that this could make some things easier.
Its strongly inspired from Boost.Spirit, but I took all the thing we don't
need out, prefering simplicity over flexibility (we can have only one
scanner, but it's enough for us). I started experimental with after fixing a
few parsing issues with class declaration. There so much things that could
be optional and different but similar alternative that the code was getting
fairly complicated. The parser would solve this if we could get the matched
ranges out, as well as the matched alternative.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-15 19:24:44
|
Well, I'm nearly done with the VS7 add-ins. Rename locale variable is
working like a charm ;-). The nice thing is that you even get the name of
the variable that was renamed in the undo combobox. The refactoring is
undone/redone in a single step. The implementation of TextDocument use
EditPoint instead of the user selection (TextSelection). Those allow text
buffer manipulation without impacting the 'view' (no scroll, no selection
being changed...)
Visual Object model is fairly flexible (though the documentation could
use improvement). The only weird thing I found concerns absolute character
offset returned by the IDE and the text returned for a given range. The text
is returned with '\r\n' at the end of each line, but only one character is
counted for an end of line !!! I solved this by stripped '\r' from the text
returned by the getText() like methods.
Baptiste.
----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, May 14, 2003 9:59 PM
Subject: [Cpptool-develop] Add-in for Visual Studio .Net 202 (vc 7.0)
> I'm currently working on the add-in for vc7. It took me a while to get
> started. The template code generated by the wizard is really bad (It stink
> like hell ;-) ). Would you believe they used macro that did goto when a
COM
> function returned an error :-(.
>
> What I have now is command register in a 'Refactoring' menu, and a
> toolbar created. The icon for the toolbar are located in what is called a
> 'satellite dll' (a pure resource dll). The magic that update the registry
> when the add-in is registered live in Connect::UpdateRegistry.
>
> I have a working implementation of TextDocument for VC7 (its character
> offset based, not line based). Also, VC7 provides an UndoContext that can
be
> used to undo multiple action in a single step (the cool things is that you
> can give it a name that appears in the combo).
>
> I'll tackle the command implementation soon.
>
> Baptiste.
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-15 19:01:12
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Thursday, May 15, 2003 6:02 PM Subject: Re: [Cpptool-develop] TextDocument interface change... > Baptiste Lepilleur wrote: > > > There is a lot of stuff we don't need there. The only need for > > refactoring are: > > > >// retrieve all the text > > const std::string getAllText() const; > >// retrieve a specified text range > > > > std::string getTextRange( const Refactoring::SourceRange &range ); > > > >// replace a specified text range > > > > void replaceTextRange( const Refactoring::SourceRange &range, > > const std::string &text ); > > > > > > This make the interface simpler and less ambiguous. With this interface, > >there is no 'state'. It is simpler to implement and less ambigous. > > > > Does anybody have suggestion to further improve the interface ? > > > well don't forget the method > > // get an area/position selected by the user: > virtual SourceRange getSelectionRange() const =0; > > since we need to know what text area is currently selected within a IDE. Actually it's not needed by the refactoring engine since the active selection range is passed to the constructor. Though, this method is probably common to all add-ins. Baptiste. > > -- André |
|
From: Andre B. <and...@gm...> - 2003-05-15 16:15:31
|
Baptiste Lepilleur wrote:
>Welcome back Andre. I saw that you fixed a few parsing bugs. It's now up to
>81% being parsed. The major remaining bug concerns parsing constructor
>declaration inside class (see file bug/list.txt for details).
>
ok, I missed that point - i check these as soon as possible.
>I've also experimented with implementing a mini-parser (see MiniParserTest).
>It's work well, but I have not yet figured out a good way to collect matched
>range. My idea is not to use those mini-parser for the full implementation,
>but for small piece of the parser, such as
>
>'class' export-macro class-name ':' inheritance {
>
>Nearly everything to parse the above structure is optional and the code get
>difficult to read. I believe such a thing would allow for serious code clean
>up, if we found a good way to retrieve the matched range.
>
>One idea I had was something like that:
>
>CStringView classDecl, className;
>// parser for: 'class' class-name :
>const Xtl::MiniParser &parser2 = (Xtl::StringMiniParser( "class " )
> >>
>Xtl::CppIdentifierMiniParser()[className]
> >> Xtl::CharMiniParser(
>':' ))[classDecl];
>
>But this would not work when working with repetition parser (for example, to
>matchthe repetition of ('::' id) ). Any ideas ?
>
Well - it should work if the repeatition parser does some look ahead and
allows only "::" to be 'eaten'
(than it will stop at a single colon).
Apart from that:
is it possible to declare a class like this
class XXX::class_name : public C {
};
The miniparser stuff sounds good - seems to go into the direction of the
boost parser but a little
bit more lightweight. I like this idea, since much code of the
declaration parser is not very easy to
understand and I do feel that this could make some things easier.
During the last days I started to work a little bit on the
IdentifierResolver for supporting
Class/Namescopes. That will take a while -depending on the time I can
spent for this
project, I will see if bug fixing and code clean up will be done first /
in parallel or what ever :-).
I have finished a class "IdentifierScope" which can hold information on
sub scopes, as well as
parent and root scope. It is possible to register identifier with their
ASTNodePtr. Some more
tests need to be written. Next step will be the integration in
"IdentifierScopeResolverContext".
I plan to move some of the implementation into IdentifierScope.
What do you think about this ?
Next week I'm definitly away and I don't know yet how much time is taken
by my job
after this...
until then,
André
|
|
From: Andre B. <and...@gm...> - 2003-05-15 15:55:46
|
Baptiste Lepilleur wrote: > There is a lot of stuff we don't need there. The only need for > refactoring are: > >// retrieve all the text > const std::string getAllText() const; >// retrieve a specified text range > > std::string getTextRange( const Refactoring::SourceRange &range ); > >// replace a specified text range > > void replaceTextRange( const Refactoring::SourceRange &range, > const std::string &text ); > > > This make the interface simpler and less ambiguous. With this interface, >there is no 'state'. It is simpler to implement and less ambigous. > > Does anybody have suggestion to further improve the interface ? > well don't forget the method // get an area/position selected by the user: virtual SourceRange getSelectionRange() const =0; since we need to know what text area is currently selected within a IDE. -- André |
|
From: Baptiste L. <gai...@fr...> - 2003-05-14 20:38:02
|
I'm thinking of simplifying the interface of TextDocument.
Actually, it is:
virtual const std::string getAllText() const =0;
virtual const std::string getSelection() const =0;
virtual void replaceSelection( const std::string &text ) =0;
virtual SourceRange getSelectionRange() const =0;
virtual void setSelectionRange( const SourceRange &selection ) =0;
There is a lot of stuff we don't need there. The only need for
refactoring are:
// retrieve all the text
const std::string getAllText() const;
// retrieve a specified text range
std::string getTextRange( const Refactoring::SourceRange &range );
// replace a specified text range
void replaceTextRange( const Refactoring::SourceRange &range,
const std::string &text );
This make the interface simpler and less ambiguous. With this interface,
there is no 'state'. It is simpler to implement and less ambigous.
Does anybody have suggestion to further improve the interface ?
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-14 20:31:24
|
Welcome back Andre. I saw that you fixed a few parsing bugs. It's now up to
81% being parsed. The major remaining bug concerns parsing constructor
declaration inside class (see file bug/list.txt for details).
I've also experimented with implementing a mini-parser (see MiniParserTest).
It's work well, but I have not yet figured out a good way to collect matched
range. My idea is not to use those mini-parser for the full implementation,
but for small piece of the parser, such as
'class' export-macro class-name ':' inheritance {
Nearly everything to parse the above structure is optional and the code get
difficult to read. I believe such a thing would allow for serious code clean
up, if we found a good way to retrieve the matched range.
One idea I had was something like that:
CStringView classDecl, className;
// parser for: 'class' class-name :
const Xtl::MiniParser &parser2 = (Xtl::StringMiniParser( "class " )
>>
Xtl::CppIdentifierMiniParser()[className]
>> Xtl::CharMiniParser(
':' ))[classDecl];
But this would not work when working with repetition parser (for example, to
matchthe repetition of ('::' id) ). Any ideas ?
Baptiste.
----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Monday, May 05, 2003 10:25 AM
Subject: Re: [Cpptool-develop] astdump runner...
> Fixed a few more bugs:
> - nested case constant (case X::value :)
> - enum parsing (parsed as a declaration list failed (no ';') )
> - support for class EXPORT_MACRO ClassName
> - general macro acceptance in declaration list based on case style
(matched
> if ID_ID(...)). Allow wxWindow & MFC macros to be parsed succesfully
>
> 74% of the files are now being parsed. I've checked
> ast/ogre/ogrebspscenemanager.cpp.html at statement level and the parsing
is
> nearly perfect (spotted two minors bugs).
>
> For the curious, you can find the zipped resultat (I've fixed the url link
> bug):
> http://gaiacrtn.free.fr/temp
> the ast directory you'll find there only contains a subset of the zip file
> (audacity, ogre & rfta).
>
> On major bug remaining concerns the parsing of constructor declaration in
> class declaration.
>
> Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-14 19:55:48
|
I'm currently working on the add-in for vc7. It took me a while to get
started. The template code generated by the wizard is really bad (It stink
like hell ;-) ). Would you believe they used macro that did goto when a COM
function returned an error :-(.
What I have now is command register in a 'Refactoring' menu, and a
toolbar created. The icon for the toolbar are located in what is called a
'satellite dll' (a pure resource dll). The magic that update the registry
when the add-in is registered live in Connect::UpdateRegistry.
I have a working implementation of TextDocument for VC7 (its character
offset based, not line based). Also, VC7 provides an UndoContext that can be
used to undo multiple action in a single step (the cool things is that you
can give it a name that appears in the combo).
I'll tackle the command implementation soon.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-10 11:50:45
|
I fixed a few bug:
- Tabulations are now handled correctly in LineBasedTextDocument
- crash on resolving an identifier that as gone out of scope:
{
int index;
}
index;
=> crashed when attemping to resolve the reference to the local variable
index.
I've also modified the implementation of
VCLineBasedTextDocument::doGetSelectionRange, making for friendly for
undoing (a single undo is now enough to undo the renaming of a given
variable).
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-07 18:23:13
|
Sven, I hope you kept up with the backup. This has happened again :-( htdocs/wiki is empty. I have a backup but it's a really old one. Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Thursday, December 05, 2002 5:46 PM Subject: Re: [Cpptool-develop] Our wiki was vandalized... > Starting from last night, I'm making nightly backups of the htdocs > directory. I'm keeping two copies around, so we should be able to recover > from "accidents" at the wiki if we discover them within 24 hours. > > I'll devise a more intelligent, incremental backup system later this week. > > Sven > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2003-05-05 08:21:04
|
Fixed a few more bugs: - nested case constant (case X::value :) - enum parsing (parsed as a declaration list failed (no ';') ) - support for class EXPORT_MACRO ClassName - general macro acceptance in declaration list based on case style (matched if ID_ID(...)). Allow wxWindow & MFC macros to be parsed succesfully 74% of the files are now being parsed. I've checked ast/ogre/ogrebspscenemanager.cpp.html at statement level and the parsing is nearly perfect (spotted two minors bugs). For the curious, you can find the zipped resultat (I've fixed the url link bug): http://gaiacrtn.free.fr/temp the ast directory you'll find there only contains a subset of the zip file (audacity, ogre & rfta). On major bug remaining concerns the parsing of constructor declaration in class declaration. Baptiste. ----- Original Message ----- From: "Baptiste Lepilleur" <gai...@fr...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Friday, May 02, 2003 12:02 AM Subject: Re: [Cpptool-develop] astdump runner... > Fixed 4 bugs and removed all crashes: > - readUntilNextOf() caused silent failures as it iterated to the end without > throwing exception. It now throw an exception uppon failure. tryReadNextOf() > as been added to handle case were you need to continue > - class forward declaration support > - destructor declaration support (not clean, will need to be made more > robust) > - multiple access declaration support 'public: protected:' > > 51% of the 49 files are now being parsed ! Things are looking up. > > Baptiste. > > ----- Original Message ----- > From: "Baptiste Lepilleur" <gai...@fr...> > To: "CppTool Mailing List" <Cpp...@li...> > Sent: Thursday, May 01, 2003 12:14 PM > Subject: [Cpptool-develop] astdump runner... > > > > I've added a python script in the bin/ directory. It scan the > > subdirectories of bin/testdata/ and run the parser in all the file found > > there. The directory structure is duplicated in ast/ and the HTML ast dump > > are copied here. An index page is created in ast/index.html with link to > all > > ast, as well as parsing status (ok, failed, and crashed). > > > > The script must be run from the bin/ directory, and expect to find a > > binary named 'astdump' there. > > > > For the curious, you can find the zipped resultat: > > http://gaiacrtn.free.fr/temp > > the ast directory you'll find there only contains a subset of the zip > > file (ogre & rfta). > > > > The source were picked up from some C++ project on sourceforge. > > > > Baptiste. |
|
From: Baptiste L. <gai...@fr...> - 2003-05-01 21:58:37
|
Fixed 4 bugs and removed all crashes: - readUntilNextOf() caused silent failures as it iterated to the end without throwing exception. It now throw an exception uppon failure. tryReadNextOf() as been added to handle case were you need to continue - class forward declaration support - destructor declaration support (not clean, will need to be made more robust) - multiple access declaration support 'public: protected:' 51% of the 49 files are now being parsed ! Things are looking up. Baptiste. ----- Original Message ----- From: "Baptiste Lepilleur" <gai...@fr...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Thursday, May 01, 2003 12:14 PM Subject: [Cpptool-develop] astdump runner... > I've added a python script in the bin/ directory. It scan the > subdirectories of bin/testdata/ and run the parser in all the file found > there. The directory structure is duplicated in ast/ and the HTML ast dump > are copied here. An index page is created in ast/index.html with link to all > ast, as well as parsing status (ok, failed, and crashed). > > The script must be run from the bin/ directory, and expect to find a > binary named 'astdump' there. > > For the curious, you can find the zipped resultat: > http://gaiacrtn.free.fr/temp > the ast directory you'll find there only contains a subset of the zip > file (ogre & rfta). > > The source were picked up from some C++ project on sourceforge. > > Baptiste. > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Cpptool-develop mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpptool-develop > |
|
From: Baptiste L. <gai...@fr...> - 2003-05-01 10:10:44
|
I've added a python script in the bin/ directory. It scan the
subdirectories of bin/testdata/ and run the parser in all the file found
there. The directory structure is duplicated in ast/ and the HTML ast dump
are copied here. An index page is created in ast/index.html with link to all
ast, as well as parsing status (ok, failed, and crashed).
The script must be run from the bin/ directory, and expect to find a
binary named 'astdump' there.
For the curious, you can find the zipped resultat:
http://gaiacrtn.free.fr/temp
the ast directory you'll find there only contains a subset of the zip
file (ogre & rfta).
The source were picked up from some C++ project on sourceforge.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2003-04-30 19:55:20
|
Fixed the bug. Anonymous were simply not handled. It's working now. Baptiste. ----- Original Message ----- From: "Baptiste Lepilleur" <gai...@fr...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Wednesday, April 30, 2003 12:03 AM Subject: Re: [Cpptool-develop] Some bug fixes with declaration parsing ... > I gave a try to the new astdumper and result are really impressive. I've > managed to find a parsing failure when attempting to parse CPPParser.cpp > (added to test.bat). I think it's related to the anonymous namespace. I'll > give it a more in depth look later. > > I've finally implemented CPPParser::parseForFunctionBodyAt(). It worked > right the first time (at least, the test says so ;-). > > Next step will be to refactor the Refactoring to use the CPPParser. > > Baptiste. > > ----- Original Message ----- > From: "Andre Baresel" <and...@gm...> > To: "CppTool Mailing List" <Cpp...@li...> > Sent: Tuesday, April 29, 2003 12:40 PM > Subject: [Cpptool-develop] Some bug fixes with declaration parsing ... > > > > tests with real world applications have shown some bugs which > > did occure only if the parsers were called from the MaxLODMutator > > context. I have fixed them. > > > > I'm now on holiday for one week and much work is waiting for me next > > week. So there'll be a little silence for a while ... > > > > Until than, keep on the good work :-) > > I will be back as soon as possible > > -- André > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Cpptool-develop mailing list > > Cpp...@li... > > https://lists.sourceforge.net/lists/listinfo/cpptool-develop > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Cpptool-develop mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpptool-develop > |
|
From: Baptiste L. <gai...@fr...> - 2003-04-29 21:59:08
|
I gave a try to the new astdumper and result are really impressive. I've managed to find a parsing failure when attempting to parse CPPParser.cpp (added to test.bat). I think it's related to the anonymous namespace. I'll give it a more in depth look later. I've finally implemented CPPParser::parseForFunctionBodyAt(). It worked right the first time (at least, the test says so ;-). Next step will be to refactor the Refactoring to use the CPPParser. Baptiste. ----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Tuesday, April 29, 2003 12:40 PM Subject: [Cpptool-develop] Some bug fixes with declaration parsing ... > tests with real world applications have shown some bugs which > did occure only if the parsers were called from the MaxLODMutator > context. I have fixed them. > > I'm now on holiday for one week and much work is waiting for me next > week. So there'll be a little silence for a while ... > > Until than, keep on the good work :-) > I will be back as soon as possible > -- André > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Cpptool-develop mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpptool-develop > |
|
From: Andre B. <and...@gm...> - 2003-04-29 10:34:01
|
tests with real world applications have shown some bugs which did occure only if the parsers were called from the MaxLODMutator context. I have fixed them. I'm now on holiday for one week and much work is waiting for me next week. So there'll be a little silence for a while ... Until than, keep on the good work :-) I will be back as soon as possible -- André |
|
From: Baptiste L. <gai...@fr...> - 2003-04-29 08:43:16
|
----- Original Message ----- From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Monday, April 28, 2003 10:58 PM Subject: [Cpptool-develop] Class-Body-Parsing now works... > Hello together, > > class body parsing has now been implemented. First test can be seen in > DeclarationListMutatorTests. > Current MaxLODMutator should work with this and parse a declared > class down to it's members (has not yet been tested). > I've checked in the ASTDumper now parsing from FILE-Level. > So the test.bat will work only for full file level parsing areas. I'll check this out. Ignore my previous question concerning the LODParser ;-) > > -- André |
|
From: Baptiste L. <gai...@fr...> - 2003-04-29 08:42:11
|
----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "Baptiste Lepilleur" <gai...@fr...>
Sent: Monday, April 28, 2003 10:55 PM
Subject: Re: [Cpptool-develop] Error recovery...
> Baptiste Lepilleur wrote:
>
> > I was reading some of the new parsing code, that is template parsing:
> >
> >---
> > if (tryNextIs('<'))
> > {
> > // skipping all the parameters until next '>'
> > findNextBalanced('<','>');
> >---
> >
> > The issue is not specific to that code, it's just the one that got me
> >thinking. We know an obvious way to have findNextBalanced fails is to
have
> >some constant comparison expression in the template parameter (very
unlikely
> >though), that is "template <const bool optimize = sizeof(A) < sizeof(B) >
> >... ;"
> >
> I've never seen such code, however this is really problematic !
Likehood is very small. This might only be use in advanced generic
programming (running the parser over boost mpl will be interesting).
> Note that another problem is the shift operator '<<' which has not to be
> balanced.
> I'm thinking about some general tokinizing algorithm implemented in the
> new ParserTools.
This can be easily done by implementing a skip policy and passing it to
ParserTools::findNextBalanced.
> The balancing algorithm should than use the tokenizer.
> Note that a tokenizer is now implemented in ExpressionParser and
> DeclarationParser.
> DeclarationParser does except only a subset (defined by the syntax).
> exceptTokenSet would be
> some useful util.
I'll give this alook. My initial idea when I started the parser was that
continuous refactoring would lead us to some mini-parser framework. We'll
see what come out.
> > While it is not dramatic if we failed to parse this correctly, but it
> >would be better if we could do some error recovery. One of the way I
think
> >this could be achieve would be by introducing a findNextBalanced, but
stop
> >parsing if '{' or ';' is found. Then the error recovery could start here.
> >
> > What do you think ?
> >
> Yes - a good idea. I have the feeling that a good error recovery is very
> hard to
> design, maybe we get some ideas when the parser fails with real world
code.
Yes, that would help a lot. By the way, is there a LODMutator that mutate
all the node (parse the declaration list, then declaration...). I'd like to
run some real world test and implements CPPParser::parserAll().
Baptiste.
PS: check your email-client settings. I'm getting two copy of most mail. One
in standard text format, and another as a mail containing a single attached
file ?!?
>
> -- André
|
|
From: Andre B. <and...@gm...> - 2003-04-28 20:52:21
|
|
From: Andre B. <and...@gm...> - 2003-04-28 20:52:04
|
Hello together, class body parsing has now been implemented. First test can be seen in DeclarationListMutatorTests. Current MaxLODMutator should work with this and parse a declared class down to it's members (has not yet been tested). I've checked in the ASTDumper now parsing from FILE-Level. So the test.bat will work only for full file level parsing areas. -- André |
