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...> - 2003-12-16 13:57:58
|
a small description how preprocessing has been integrated into the refactoring tool. The preprocessor has replaced the former 'NoneSemanticBlanker' which was some special kind of preprocessing handling comments and strings. The preprocessor class still uses this blanker class to do the required processing after doing the usual preprocessing. The current implementation of preprocessing does currently support only simple macro replacements. This shows that the idea works. A next goal should be the handling of #include directives. I will check this in the next weeks. However, all preprocessing operations do change the text - how can we trace back these modifications when doing our refactorings ? Well, I have implemented this tracking very simple by using the TransformationList which was originally designed to store all code modifications of a refactoring operation - well, now it also stores entries of preprocessing operations. These can be used to calculate the source positions in original code and that's it !! Well I have also implemented a detection of conflics of doing refactorings to positions where macro replacement has been executed. Currently the refactoring engine simply stops the refactoring -> later we can think about strategies, like removing the macro and use the replacement text in this case. Or even we can try to modify the macro definition, but that are some gimmicks I believe. This preprocessing integration was not integrated into the part where the new CodeWriter has been used - I want to check this next. Until later, André |
|
From: Andre B. <and...@gm...> - 2003-12-14 23:26:25
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1"> <title></title> </head> <body> after month without time for the projekt I've now spend a couple of hours for<br> further improvements. Unfortunatly I recognized that it is to much work for only<br> three programmers to continue with the project. I have got not much time to <br> spend on the project, because of my job and family. However I believe in the<br> IDEA of this project. We have shown that it is possible to do refactorings with it. <br> We have developed Plugins for Eclipse and Visual Studio. And we're able to parse<br> full c++ syntax. As soon as my SSH software is working again I will provide the<br> first step toward PreProcessing C++ Code. I have allready written the tests for<br> simple refactoring operation in case of MACRO usage (well just simple replacements,<br> but this is the enabling technology...).<br> One of the bad news was the deletion of our Wiki pages. In the future we need <br> someone which can provide a managed webpage with ftp access and which will<br> help us to create some nice pages introducing the ideas.<br> In the next day I will start some advertisment in the c++ news groups and <br> developer pages.<br> In a time where Code-Refactoring is a synonym for Code-Quality this project<br> seems to be the GOAL for every C++ programmer. <br> <br> <b>Wouldn't it be nice to do your 'rename-operation' or 'extract-method-refactoring' <br> with just a couple of mouse clicks ? </b><br> <br> We're not far away from that - The ideas are all implemented, we<br> only need a couple of people helping us to implement those little nasty things<br> which need so much time.<br> <br> sincelery,<br> André<br> <br> back in a minute >;-)<br> <br> </body> </html> |
|
From: Andre B. <and...@gm...> - 2003-09-15 17:20:18
|
Hello together, I have submitted sources for global identifier resolving. An example can be seen in IdentifierResolverTest - testClassScope. It is far away from being complete, but the first steps have been done... As soon as there is more time, i will go on with it ... see you later, andré |
|
From: Baptiste L. <gai...@fr...> - 2003-09-07 08:59:23
|
Fixed. I removed that dependency (probably a leftover a some com/python/c= ++ exploration I made). Baptiste. ----- Original Message -----=20 From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Sunday, September 07, 2003 12:15 AM Subject: [Cpptool-develop] Still not able to compile pyrfta ... > hello baptiste, > > i#m still not able to compile "pyrfta" because of the missing file > > rfta\src\pyrfta\com\TextDocument.idl > > until later, > andr=E9 > > > > ------------------------------------------------------- > 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-09-06 22:01:47
|
hello baptiste, i#m still not able to compile "pyrfta" because of the missing file rfta\src\pyrfta\com\TextDocument.idl until later, andré |
|
From: Andre B. <and...@gm...> - 2003-09-06 21:58:27
|
Hello together, during the last weeks i started to work a little bit on identifier resolver. a first test has been added for a globally declared class, with an attribute and function. The resolver does not yet work fully... I will work on it next. extensions to ast need to be documented to... until later, André |
|
From: Baptiste L. <gai...@fr...> - 2003-08-26 12:11:33
|
I've added a small script in src/pyrfta/test: cppastdump.py. It dump the
generated ast to the output for the c++ file specified on the command line.
I've uploaded a few output examples to:
http://gaiacrtn.free.fr/temp/newparser_ast/
Not that some contains template, as well as non standard class
declaration (using macro for dll export). This cause the error recovery
mecanism to trigger.
Enjoy,
Baptiste.
----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Tuesday, August 26, 2003 12:22 AM
Subject: [Cpptool-develop] New C++ parser...
> Well, I glad to announce that the new C++ parser I was working on is
now
> working (at least the unit tests say so;-) ). It lives in
> src/pyrfta/test/rfta/parser. I've wrotten a small document (readme.txt)
that
> provides an overview of the parser, as well as instructions to run the
> tests.
>
> At the current time, there is no template support, but there is a
simple
> 'error recovery' mecanism for statements and declarations. It way more
> flexible and compact than the current C++ parser (the statement parser is
> about 30 lines of grammar long). It parses for all structures:
declaration,
> expression and statement. I want to stabilize the current grammar before
> adding template support (which will probably means adding a few not so
> predicatible twist to the grammar).
>
> Here is a few samples of successfully parsed code:
>
> // Ambiguity resolution example in ISO C++ Standard, p 129
> struct S {
> S(int x);
> };
> S w(int(a)); // function declaration
> S x(int()); // function declaration
> S y((int)a); // object declaration
> S z = int(a); // object declaration
>
> // Empty initializer list example in ISO C++ Standard, p 145
> struct S { };
> struct A {
> S s;
> static j;
> int i;
> } a = { {}, 3 };
>
> // Typedef look up example 2 in ISO C++ Standard, p 154
> typedef void fv(void);
> typedef void fvc(void) const;
> struct S {
> fv memfunc1; // equivalent to: void memfunc1(void);
> void memfunc2();
> fvc memfunc3; // equivalent to: void memfunc3(void) const;
> };
> fv S::* pmfv1 = &S::memfunc1;
> fv S::* pmfv2 = &S::memfunc2;
> fvc S::* pmfv3 = &S::memfunc3;
>
> class C : public A, public B {
> int f() { return A::f() + B::f(); }
> C();
> explicit C( int );
> ~C();
> friend C operator +( const C&, const C& );
> };
>
> // Local structure example in ISO C++ Standard, p 161
> int x;
> void f()
> {
> static int s;
> int x;
> extern int g();
>
> struct local {
> int h() { return s; }
> int k() { return ::x; }
> int l() { return g(); }
> };
> }
>
> Notes that because of the nature of the parser (it does not know if a
> identifier is a type, a variable...), in some case a code structure may be
> misinterpreted. For example:
>
> a f(x);
>
> could be either a function declaration (return type a, takes type x as
> argument), or a object instantiation (type a, name f, constructor paramter
> x).
>
> The same goes for expression:
> f(x) may be a function call, a 'functional style' type conversion, or a
> instiation of a object of type f.
>
> This means that there will be a bit of analysis works to do to try and
> fix the AST.
>
> Next steps includes running the parser against 'real' code and come up
> with some functional tests to detect regression.
>
> Baptiste.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
> at the same time. Free trial click
here:http://www.vmware.com/wl/offer/358/0
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>
|
|
From: Baptiste L. <gai...@fr...> - 2003-08-25 22:17:00
|
Well, I glad to announce that the new C++ parser I was working on is now
working (at least the unit tests say so;-) ). It lives in
src/pyrfta/test/rfta/parser. I've wrotten a small document (readme.txt) that
provides an overview of the parser, as well as instructions to run the
tests.
At the current time, there is no template support, but there is a simple
'error recovery' mecanism for statements and declarations. It way more
flexible and compact than the current C++ parser (the statement parser is
about 30 lines of grammar long). It parses for all structures: declaration,
expression and statement. I want to stabilize the current grammar before
adding template support (which will probably means adding a few not so
predicatible twist to the grammar).
Here is a few samples of successfully parsed code:
// Ambiguity resolution example in ISO C++ Standard, p 129
struct S {
S(int x);
};
S w(int(a)); // function declaration
S x(int()); // function declaration
S y((int)a); // object declaration
S z = int(a); // object declaration
// Empty initializer list example in ISO C++ Standard, p 145
struct S { };
struct A {
S s;
static j;
int i;
} a = { {}, 3 };
// Typedef look up example 2 in ISO C++ Standard, p 154
typedef void fv(void);
typedef void fvc(void) const;
struct S {
fv memfunc1; // equivalent to: void memfunc1(void);
void memfunc2();
fvc memfunc3; // equivalent to: void memfunc3(void) const;
};
fv S::* pmfv1 = &S::memfunc1;
fv S::* pmfv2 = &S::memfunc2;
fvc S::* pmfv3 = &S::memfunc3;
class C : public A, public B {
int f() { return A::f() + B::f(); }
C();
explicit C( int );
~C();
friend C operator +( const C&, const C& );
};
// Local structure example in ISO C++ Standard, p 161
int x;
void f()
{
static int s;
int x;
extern int g();
struct local {
int h() { return s; }
int k() { return ::x; }
int l() { return g(); }
};
}
Notes that because of the nature of the parser (it does not know if a
identifier is a type, a variable...), in some case a code structure may be
misinterpreted. For example:
a f(x);
could be either a function declaration (return type a, takes type x as
argument), or a object instantiation (type a, name f, constructor paramter
x).
The same goes for expression:
f(x) may be a function call, a 'functional style' type conversion, or a
instiation of a object of type f.
This means that there will be a bit of analysis works to do to try and
fix the AST.
Next steps includes running the parser against 'real' code and come up
with some functional tests to detect regression.
Baptiste.
|
|
From: Andre B. <and...@gm...> - 2003-08-24 18:24:30
|
hello together, don't wonder I'm still there - currently I'm working on adding ast-nodes/properties for identifiers within declarations. This is needed to build up a symbol table for classes / variables / namespaces etc. There're allready a couple of working and none working tests and implementation, but nothing yet for checking in.. These days I can spend only a few hours per week on this project... andre´ |
|
From: Baptiste L. <gai...@fr...> - 2003-08-12 07:11:41
|
----- Original Message -----=20 From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Sunday, August 03, 2003 1:13 PM Subject: Re: [Cpptool-develop] Back on CPP-Refactoring ... > > [...] > >The interesting part is that you can still write 'hand written' parser= to > >handle real weird case if needed. There is still much to work out, but it's > >really promising. > > > Sounds interesting - well it's good to have you, just so open minded to > even throw away ugly looking > code ;-) ... Sometimes I'm not so relaxed - since so much time has been > spend on the written code ... > But I like your idea. It's looking much more simple than the complex > stuff in the declaration parser. I like to think that I managed to keep the feature that worked well (leve= l of detail parsing, recursive LL descendent parser), and discarded the feature that got in the way (lazy parsing (it's an optimisation. Can be reintroduced anyway), explicit node type/properties declaration (ASTNodes stuff) ). There is still some features to add: - balanced brace matching with subparsing of brace content and creation o= f an 'error' node if subparsing failed. - probably extend the parse stuff so that the parser can match 'node tree= ' as well as token. This would allow us to roughly parse an expression whic= h failed to be parsed as an expression and extract the 'qualified identifier...' I started debugging some of the expression parsing. As I expected there i= s a need to introduce a 'match longuest alternative' parser (on the way). > At the moment I would like to work a little bit on the refactoring > features, just to show that Could you clarify, I'm not sure I understand what you'll be working on exactly. > the things are going on there, too. btw) I've checked again the eclipse > pages for CDT (that the C/C++ > Developer Plugin). At the moment their implementation is planned to wor= k > with an XML representation > of the parsed C/C++ code. > this weekend is so hot here in berlin - 35 degrees. Well, here in Paris we have been cooking under 35-40 degress for the last two weeks... Well, it's time for me to take some vacantion. I'll be away for the next = two weeks. Baptiste. > until later, > Andr=E9 |
|
From: Andre B. <and...@gm...> - 2003-08-03 11:01:37
|
> > >Welcome back Andre. > thanks :-) >I ported the 'mini parser' core to python last week-end, so it would be >easier to prototype a robust parser implementation. Current results are very >positive. > << skipped >> >The inheritance is not parsed here, because I'd like to implement a mecanism >to make a local parsing. We know were the inheritance declaration starts and >ends, this should help parsing potential templated inheritance more >robustly, doing a 'sub parsing' on the specific token range. > >The interesting part is that you can still write 'hand written' parser to >handle real weird case if needed. There is still much to work out, but it's >really promising. > Sounds interesting - well it's good to have you, just so open minded to even throw away ugly looking code ;-) ... Sometimes I'm not so relaxed - since so much time has been spend on the written code ... But I like your idea. It's looking much more simple than the complex stuff in the declaration parser. At the moment I would like to work a little bit on the refactoring features, just to show that the things are going on there, too. btw) I've checked again the eclipse pages for CDT (that the C/C++ Developer Plugin). At the moment their implementation is planned to work with an XML representation of the parsed C/C++ code. this weekend is so hot here in berlin - 35 degrees. until later, André |
|
From: Baptiste L. <gai...@fr...> - 2003-07-31 21:52:59
|
Welcome back Andre. I been fairly drained by work for the last month too. Though, I did divert a bit of time working on CppUnit V2. I ported the 'mini parser' core to python last week-end, so it would be easier to prototype a robust parser implementation. Current results are v= ery positive. You can find it in src/pyrfta/test/rfta/parser.py and parsertest.py. To run it, just install python 2.2 (you can get it from python.org), and run src/pyrfta/test/alltests.py. Notes that the parser u= se a tokenizer. Personnally, I would be enclined to move the full parser to python (it ta= kes a lot of less time to produce code in python), and only move it back to C= ++ when it's the only way remaining to improve performance. Python is a very simple language to grasp (about 2 hours to go through the tutorial), and = its dynamic nature make it very malleable. For instance, "::NameSpace::MyClass::myVar" is parsed using the following parser instantiation (it's actual python code): nested_id_p =3D (maybe_p( "::" ) >> list_p( id_p, symbol_p('::') ))[inline_child_at_a(1)]['nested_id'] =3D> it parse for an optinal '::' at the beginning, the a list of id sepa= rated by '::'. The trailing code in square brackets are action used to manipula= te the produced tree and name the resulting node. Parsing '::NameSpace::MyClass::myVar' Node(nested_id : 6 children) |-Token(symbol,'::') |-Token(id,'NameSpace') |-Token(symbol,'::') |-Token(id,'MyClass') |-Token(symbol,'::') |-Token(id,'myVar') I still need to add an action to filter out the '::' that occurs in the list, but that's it. A dummy 'class' declaration parser I wrote (just to experiment), look lik= e this: class_inheritance_p =3D maybe_p( (symbol_p( ":" ) >> anyuntil_p( "{" ))['inheritance'] ) null_statement_p =3D eos_p['null_statement'] class_body_statements_p =3D null_statement_p class_inheritance_and_body_decl_p =3D class_inheritance_p >> "{" >> maybe_p(class_body_statements_p) >> "}" class_decl_p =3D (symbol_p("class") | "struct") >> nested_id_p \ >> maybe_p( class_inheritance_and_body_decl_p ) >> eos_p Which produce the following tree when parsing: Parsing 'class MyClass : public MyParent<MyClass,simple_traits> { };' Node(? : 5 children) |-Token(symbol,'class') |-Node(nested_id : 2 children) |-|-NONE | |-Token(id,'MyClass') |-NONE |-Node(? : 4 children) | |-Node(inheritance : 2 children) | | |-Token(symbol,':') | | |-Node(? : 7 children) | | | |-Token(symbol,'public') | | | |-Token(id,'MyParent') | | | |-Token(symbol,'<') | | | |-Token(id,'MyClass') | | | |-Token(symbol,',') | | | |-Token(id,'simple_traits') | | | |-Token(symbol,'>') | |-Token(symbol,'{') |-|-NONE | |-Token(symbol,'}') |-Token(symbol,';') The inheritance is not parsed here, because I'd like to implement a mecan= ism to make a local parsing. We know were the inheritance declaration starts = and ends, this should help parsing potential templated inheritance more robustly, doing a 'sub parsing' on the specific token range. The interesting part is that you can still write 'hand written' parser to handle real weird case if needed. There is still much to work out, but it= 's really promising. Baptiste. ----- Original Message -----=20 From: "Andre Baresel" <and...@gm...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Monday, July 28, 2003 5:30 PM Subject: [Cpptool-develop] Back on CPP-Refactoring ... > Hello together, > > I'm back from workaholic days and 2 weeks holiday - > > I had some stressful and horrible days at work, after this two nice wee= k > holiday > in austria and one week at a conference in chicago... > > Now I'm a little bit more relaxed and there's time for some coding. > I plan to play arround with some refactoring at code level, > just to use the new features of the parser and show what's > possible with our implementation ... > > until later, > andr=E9 |
|
From: Andre B. <and...@gm...> - 2003-07-28 15:18:32
|
Hello together, I'm back from workaholic days and 2 weeks holiday - I had some stressful and horrible days at work, after this two nice week holiday in austria and one week at a conference in chicago... Now I'm a little bit more relaxed and there's time for some coding. I plan to play arround with some refactoring at code level, just to use the new features of the parser and show what's possible with our implementation ... until later, andré |
|
From: Andre B. <and...@gm...> - 2003-06-04 21:00:28
|
hello together, unfortunatly my job keeps me away until next week and than our two week holiday starts. I'll be back in july andre |
|
From: Baptiste L. <gai...@fr...> - 2003-05-29 08:37:23
|
htdocs/backup is now a symbolic links to ~cpptool/NightlyBackups. Anyone can now download the nightly backup using plain http from: http://cpptool.sourceforge.net/backup/ Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Monday, May 26, 2003 11:48 PM Subject: [Cpptool-develop] htdocs backups > I modified the backup procedure to store everything in > ~cpptool/NightlyBackups. Maybe Baptiste could move the backups away from > the htdocs directory, so they won't be included in each backup. The new > directory should be group writeable; the backup files are - so far - group > readable but owner writeable. > > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2003-05-26 21:48:41
|
I modified the backup procedure to store everything in ~cpptool/NightlyBackups. Maybe Baptiste could move the backups away from the htdocs directory, so they won't be included in each backup. The new directory should be group writeable; the backup files are - so far - group readable but owner writeable. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2003-05-26 06:21:07
|
htdocs/wiki2 is the real one. htdocs/wiki should be deleted is possible. Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Sunday, May 25, 2003 10:35 PM Subject: Re: [Cpptool-develop] Wiki and apologies (once more...) > On Sun, 25 May 2003, Baptiste Lepilleur wrote: > > > Sven, if you have the time, could you also manage to have your cron copying > > the backup tarball to htdocs/backup? That way anyone could download it, and > > responsability would be shared (I can easily set up a tool to download a > > fixed url, but running a automated script through ssh is another story). > I'll see what I can do. > > Concerning the wiki data, I moved them to htdocs/wiki2. I couldn't replace > > or delete htdocs/wiki for some reason (don't know why since it's supposed to > > be world writable). > > So which one is the actual wiki now? Need to know that in order to make > the backups. > > Sven. |
|
From: Sven R. <rei...@ma...> - 2003-05-26 03:01:15
|
Does this explain our problems with the Wiki? (From the shell login screen) On 2003-05-05, world-writable/nobody-owned files were removed from the project shell/web servers. Projects affected by this removal should restore these files/directories from their backups. Additional information on the Site Status page. Site Status: http://sf.net/docman/display_doc.php?docid=2352&group_id=1 Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2003-05-25 20:36:00
|
On Sun, 25 May 2003, Baptiste Lepilleur wrote: > Sven, if you have the time, could you also manage to have your cron copying > the backup tarball to htdocs/backup? That way anyone could download it, and > responsability would be shared (I can easily set up a tool to download a > fixed url, but running a automated script through ssh is another story). I'll see what I can do. > Concerning the wiki data, I moved them to htdocs/wiki2. I couldn't replace > or delete htdocs/wiki for some reason (don't know why since it's supposed to > be world writable). So which one is the actual wiki now? Need to know that in order to make the backups. Sven. |
|
From: Baptiste L. <gai...@fr...> - 2003-05-25 18:46:44
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Sunday, May 25, 2003 5:53 PM Subject: [Cpptool-develop] Wiki and apologies (once more...) > Hi guys, > > recently, I haven't followed the mailing list and other developments. The > reason is that I had to turn in my thesis, and that meant a few weeks of > 12-hr days. Now it's almost done; I will have my defense next week (still > a bit nerve-racking). We all have a live to live ;-) Good luck. > As for the wiki, I made daily backups, however they are only useful if we > discover vandalization within 24 hours. I will think about a better scheme > once I get around it. > > I am truly sorry for any incovenience my neglect has caused. Just took a bit of time to reformat the html copy. Nothing major. Anyway, probably more than 1 day had passed before I discovered the issue. Baptiste. > Greetings, > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2003-05-25 18:41:37
|
Sven, if you have the time, could you also manage to have your cron copying the backup tarball to htdocs/backup? That way anyone could download it, and responsability would be shared (I can easily set up a tool to download a fixed url, but running a automated script through ssh is another story). Concerning the wiki data, I moved them to htdocs/wiki2. I couldn't replace or delete htdocs/wiki for some reason (don't know why since it's supposed to be world writable). Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Sunday, May 25, 2003 6:09 PM Subject: Re: [Cpptool-develop] Wiki and apologies (once more...) > I updated my cron file to make backups ever day, every Sunday, and every > first day of the month, and to keep the two last copies of daily, weekly, > and monthly backups. BTW, the contents of the wiki has shrunk a lot since > yesterday; is that normal? Just in case I saved yesterday's version. > > I hope that this will prevent further damages. > > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2003-05-25 18:23:17
|
I investigated a bit, and the crashed were not really crash (just bad
command line passed to astdump. filename contained spaces).
The infinite loop are caused by K&R function style declaration, such as:
int
main (argc, argv)
int argc;
char **argv;
{
}
As weird as it sound, it is used in 'common' files, such as getopt.c,
getopt1.c or unzip.c.
Baptiste.
----- Original Message -----
From: "Baptiste Lepilleur" <gai...@fr...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Sunday, May 25, 2003 7:37 PM
Subject: [Cpptool-develop] astdump runner...
> Well, I run astdump on a large amount of files. Here are the result
> (number are files):
> Passed 3008 : 82%
>
> Failed 614 : 16%
>
> Crashed 9 : 0%
>
> Total tests: 3631
>
> I would say that it's pretty good considering how young the parser is.
>
> Some of the bugs I saw comming often:
>
> - constructor parsing
>
> - operator = support (or something like that)
>
> - friend function declaration
>
> - inline support
>
> - using symbol;
>
> - __asm
>
> Also, as indicated above, there was 9 crashes and the parser also went
> in an infinite loop while parsing some files (getopt.c for instance).
>
> I've updated bug/list.txt with those I found after looking at some of
> the failure (there is just too much to look at them all).
>
> Baptiste.
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Cpptool-develop mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>
|
|
From: Baptiste L. <gai...@fr...> - 2003-05-25 17:33:20
|
Well, I run astdump on a large amount of files. Here are the result
(number are files):
Passed 3008 : 82%
Failed 614 : 16%
Crashed 9 : 0%
Total tests: 3631
I would say that it's pretty good considering how young the parser is.
Some of the bugs I saw comming often:
- constructor parsing
- operator = support (or something like that)
- friend function declaration
- inline support
- using symbol;
- __asm
Also, as indicated above, there was 9 crashes and the parser also went
in an infinite loop while parsing some files (getopt.c for instance).
I've updated bug/list.txt with those I found after looking at some of
the failure (there is just too much to look at them all).
Baptiste.
|
|
From: Sven R. <rei...@ma...> - 2003-05-25 16:14:31
|
I updated my cron file to make backups ever day, every Sunday, and every first day of the month, and to keep the two last copies of daily, weekly, and monthly backups. BTW, the contents of the wiki has shrunk a lot since yesterday; is that normal? Just in case I saved yesterday's version. I hope that this will prevent further damages. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2003-05-25 15:53:45
|
Hi guys, recently, I haven't followed the mailing list and other developments. The reason is that I had to turn in my thesis, and that meant a few weeks of 12-hr days. Now it's almost done; I will have my defense next week (still a bit nerve-racking). As for the wiki, I made daily backups, however they are only useful if we discover vandalization within 24 hours. I will think about a better scheme once I get around it. I am truly sorry for any incovenience my neglect has caused. Greetings, Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
