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: Sven R. <rei...@ma...> - 2002-10-27 22:11:45
|
Right,
I started writing this test when I had checked out the code under Windows,
before having set up the cvs stuff under linux. I fixed the implementation
file, and forgot the header..
Sven.
--
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...
---------- Forwarded message ----------
Date: Sun, 27 Oct 2002 21:02:23 +0100
From: Baptiste Lepilleur <gai...@fr...>
To: Sven Reichard <rei...@ma...>,
CppTool Mailing List <Cpp...@li...>
Subject: Re: [Cpptool-develop] blanker fixed
Great! I'm done with testing the variable declaration collector and visitor,
and I'm tackling testing the refactoring ToolsBox.
The NonSemanticBlankerTest.h file had some strange EOL (\r\r\n instead of
\r\n). I fixed this. I think this happen when you check-in a 'windows' text
file from a unix box (is keep the \r\n), and then check-out the file on a
windows box (it adds a \r).
Baptiste.
----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Sunday, October 27, 2002 8:16 PM
Subject: [Cpptool-develop] blanker fixed
> The blanker source has been fixed. It now handles strings in comments and
> vice versa correctly.
>
> Sven.
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Cpptool-develop mailing list
Cpp...@li...
https://lists.sourceforge.net/lists/listinfo/cpptool-develop
|
|
From: Baptiste L. <gai...@fr...> - 2002-10-27 19:57:32
|
Great! I'm done with testing the variable declaration collector and visitor, and I'm tackling testing the refactoring ToolsBox. The NonSemanticBlankerTest.h file had some strange EOL (\r\r\n instead of \r\n). I fixed this. I think this happen when you check-in a 'windows' text file from a unix box (is keep the \r\n), and then check-out the file on a windows box (it adds a \r). Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Sunday, October 27, 2002 8:16 PM Subject: [Cpptool-develop] blanker fixed > The blanker source has been fixed. It now handles strings in comments and > vice versa correctly. > > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-10-27 19:16:31
|
The blanker source has been fixed. It now handles strings in comments and vice versa correctly. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-10-27 17:01:17
|
I added unit tests for the blanker. One test still fails; it is commented out. I will fix it now. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-10-26 18:28:20
|
Well, a first implementation is there (src/rfta). It's very simple (the
simplest case of my article), but it does a full cycle:
- find the compound statement the temporary live in
- find the temporary declaration
- find all temporary name occurrences between the temporary declaration
and the end of the compound block
- keep only the name that are local variable
- replace all the occurrences by the new temporary identifier.
It's probably not working since no test was done (I'm tackling this).
Also, notes that the class TextDocument is supposed to be an abstraction
from a text file (which may be a CW or VC++ text document). The current
TextDocument is stream based (selection range are indicated as the number of
characters since the beginning of the document), while CW and VC++
TextDocument are line/Column based. I'll try to see if creating a conversion
layer can be done, as this would mean that the text range in TextDocument
would be the same as ASTNodeRange...
Well, onto testing...
Baptiste.
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/
|
|
From: Baptiste L. <gai...@fr...> - 2002-10-26 13:50:47
|
I change ASTNode type and property represents. Instead of string, they
are now full fledge object, ASTNodeType and ASTNodeProperty.
Both provide a list of feature supported by the node type or property.
This will help when visiting the AST knowing which node are statements for
example, or which node can be mutated...
Also, the type and property declarations, which used to be in
StatementASTNode.h and ExpressionASTNode.h have been moved to
include/rfta/parser/ASTNodes.h. ASTNodes.h declares two classes:
ASTNodeTypes and ASTNodeProperties which contain the declaration of type and
property.
Baptiste.
---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/
|
|
From: Baptiste L. <gai...@fr...> - 2002-10-25 21:43:53
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Friday, October 25, 2002 9:32 PM Subject: Re: [Cpptool-develop] Linux port > On Fri, 25 Oct 2002, Baptiste Lepilleur wrote: > [...] > > A gcc 2.96 + STLPort combination might work... > > What is STLPort? http://stlport.org/ It's a free, open-source implementation of STL, which I'm told is quite portable and fairly good (use concept check and has debug iterator). In fact, Borland shipped it with Borland C++ 6.0. My guess is that it should get ride of most STL issue for gcc 2.9.6. Baptiste. |
|
From: Sven R. <rei...@ma...> - 2002-10-25 19:32:06
|
On Fri, 25 Oct 2002, Baptiste Lepilleur wrote: > > It does work! Good job. > > I do have a few question though: > > Why where aclocal.m4 and makefile.in modfiied in deplib/cppunit ? I'd rather > keep that as the original version of CppUnit 1.9.10. It's there so it can > compile (nearly, still need to install boost) out of the box on Windows. Oops !? I didn't touch these files. So far I'm working with a separately installed copy of CppUnit 1.9.10. I'm not sure what went wrong. I'll try to reverse the changes. Now that I think of it, I tried to build CppUnit; that must have changed the files, and I did a global commit afterwards. > You should consider using the CompilerOutputter which provides better > integration with your compilation environment. Or better, setting up the > DllPlugInTester to test the unit test DLL. It's really worth it. You get a > shorter compilation/test cycle, and as such compile more often. It can also > run tests contained in multiple dll and can produce many kind of output. > Basically it's the 'ultimate' bootstrap app for unit test. I'll get to that later. However, my "programming environment" consists of emacs and a terminal, where I type "make check" every couple of minutes :) So far, compile time is not a problem. > A gcc 2.96 + STLPort combination might work... What is STLPort? Sven. > Baptiste. > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > _______________________________________________ > Cpptool-develop mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpptool-develop > -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-10-25 19:18:49
|
Glad to know that lynx is not disturbed by the nested table. The only thing I can think of that might disturb Netscape are the <P> </P>. It's fairly basic HTML otherwise. Works fine with Netscape 6.2 though. Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Friday, October 25, 2002 7:08 PM Subject: Re: [Cpptool-develop] Linux port > The ASTDumper example program runs. I haven't committed the changes yet. > The weird thing is: The output doesn't display on my version of netscape; > I have long suspected that there's something wrong with that version. > However, it looks fine under lynx - a text-based (!) HTML-browser. > > Cheers, > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... > > > > ------------------------------------------------------- > This sf.net email is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en > _______________________________________________ > Cpptool-develop mailing list > Cpp...@li... > https://lists.sourceforge.net/lists/listinfo/cpptool-develop > > |
|
From: Baptiste L. <gai...@fr...> - 2002-10-25 19:15:36
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Friday, October 25, 2002 5:52 PM Subject: [Cpptool-develop] Linux port > I got it to run under Linux, and committed the changes. I had to fix a > couple of source files, so make sure it still runs under Windows. It does work! Good job. I do have a few question though: Why where aclocal.m4 and makefile.in modfiied in deplib/cppunit ? I'd rather keep that as the original version of CppUnit 1.9.10. It's there so it can compile (nearly, still need to install boost) out of the box on Windows. > So far only the rftaparser directory works; I divided the code into a > library, librfta.a, and the testing program, UnitTest. Building it is You should consider using the CompilerOutputter which provides better integration with your compilation environment. Or better, setting up the DllPlugInTester to test the unit test DLL. It's really worth it. You get a shorter compilation/test cycle, and as such compile more often. It can also run tests contained in multiple dll and can produce many kind of output. Basically it's the 'ultimate' bootstrap app for unit test. > still a bit tricky, e.g., needs gcc 3.x. Is anybody else here using Linux? > I will update the installation instructions in a while. A gcc 2.96 + STLPort combination might work... Baptiste. > > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-10-25 17:08:25
|
The ASTDumper example program runs. I haven't committed the changes yet. The weird thing is: The output doesn't display on my version of netscape; I have long suspected that there's something wrong with that version. However, it looks fine under lynx - a text-based (!) HTML-browser. Cheers, Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-10-25 15:52:20
|
I got it to run under Linux, and committed the changes. I had to fix a couple of source files, so make sure it still runs under Windows. So far only the rftaparser directory works; I divided the code into a library, librfta.a, and the testing program, UnitTest. Building it is still a bit tricky, e.g., needs gcc 3.x. Is anybody else here using Linux? I will update the installation instructions in a while. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-10-25 13:38:04
|
On Fri, 25 Oct 2002, Baptiste Lepilleur wrote: > ----- Original Message ----- > From: "Sven Reichard" <rei...@ma...> > > Folks, > > > > the code submitted by Baptiste looks nice.. from the outside. > > Unfortunately, the extended use of the Boost library is more than gcc 2.96 > > (the most widespread version of the GNU Compiler Collection for Linux) can > > handle <snip> > Hmm, are you refering to lexical_cast ? I just looked over the compiler > status and it seems to be the only one not to compile with gcc 2.95 with > STLPort. I expect the compilation issue for Boost.FileSystem to be fixed > once the development start again. No, it's that some headers (like <ostream>, which is included by <boost/format/format.hpp>) do not exist. > Though, it would be nice if we could compile on gcc 2.95 which it a widely > spread compiler I believe. It would be, but I wouldn't give it top priority. > Are you refering to ParseError destructor and what() methods which should be > marked with throw(), or something else ? Yes, right on. I'll try to fix whatever is necessary. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-10-25 06:54:33
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Friday, October 25, 2002 6:35 AM Subject: [Cpptool-develop] Linux build problems > Folks, > > the code submitted by Baptiste looks nice.. from the outside. > Unfortunately, the extended use of the Boost library is more than gcc 2.96 > (the most widespread version of the GNU Compiler Collection for Linux) can > handle. This is neither Boost's nor Baptiste's fault; gcc 2 implemented > just an "approximation" of the standard library; in fact it was developed > while the standard wasn't fixed yet. Hmm, are you refering to lexical_cast ? I just looked over the compiler status and it seems to be the only one not to compile with gcc 2.95 with STLPort. I expect the compilation issue for Boost.FileSystem to be fixed once the development start again. Though, it would be nice if we could compile on gcc 2.95 which it a widely spread compiler I believe. > So I moved to gcc 3. After figuring out how to run both versions on the > same machine, this lead to an interesting other problem. This compiler > tries to implement Standard C++ -- and is very picky about non-standard > code, much more so than MSVC6, which Baptiste used for development. One > example was in the blanker; the code looked something like > std::string str; > const char* _textBegin = str.begin(); Left over of the original implementation which used std::string::iterator. But I switched back to using plain char, which works just as well. > What's wrong with that? Well, str.begin() is a string::iterator, and there > is no standard way to convert that into a character pointer. However, this > is easy to fix, since str.c_str() returns exactly what we need. > Other things that happens are throw-specifications being too general. This > all is just to let you know that it will take a few days to have a running > program under Linux. I will fix the necessary files and commit the changes > once it runs. After that I'll go back to testing. Are you refering to ParseError destructor and what() methods which should be marked with throw(), or something else ? > BTW, maybe my edition of Stroustrup is a bit outdated. Has <stdexception> > been renamed to <stdexcept>? Both compilers seem to agree on that one. I think it does. At least I know that it works for VC++ STL, gcc STL, CodeWarrior MTL... Baptiste. > Have a good night (even if the Europeans are about to get up :) ) > > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-10-25 04:36:32
|
Folks, the code submitted by Baptiste looks nice.. from the outside. Unfortunately, the extended use of the Boost library is more than gcc 2.96 (the most widespread version of the GNU Compiler Collection for Linux) can handle. This is neither Boost's nor Baptiste's fault; gcc 2 implemented just an "approximation" of the standard library; in fact it was developed while the standard wasn't fixed yet. So I moved to gcc 3. After figuring out how to run both versions on the same machine, this lead to an interesting other problem. This compiler tries to implement Standard C++ -- and is very picky about non-standard code, much more so than MSVC6, which Baptiste used for development. One example was in the blanker; the code looked something like std::string str; const char* _textBegin = str.begin(); What's wrong with that? Well, str.begin() is a string::iterator, and there is no standard way to convert that into a character pointer. However, this is easy to fix, since str.c_str() returns exactly what we need. Other things that happens are throw-specifications being too general. This all is just to let you know that it will take a few days to have a running program under Linux. I will fix the necessary files and commit the changes once it runs. After that I'll go back to testing. BTW, maybe my edition of Stroustrup is a bit outdated. Has <stdexception> been renamed to <stdexcept>? Both compilers seem to agree on that one. Have a good night (even if the Europeans are about to get up :) ) Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-10-24 19:24:05
|
I fixed the switch keyword parser bug.
I also added parser for 'case' and 'default'.
The parser should now be able to parse the most of the common C++ code.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2002-10-24 18:01:21
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Thursday, October 24, 2002 6:00 PM Subject: [Cpptool-develop] working on linux port > Folks, > > I'm working on the linux port. So far, the cppunit as included in our > package doesn't compile; I think a few files are missing. Hmm, I removed the examples directory. But the default 'make' probably try to some of the examples. I'll fix that later (by the way, it's version 1.9.10 of CppUnit) > About the parsing: As I said, I wrote a few tests for NonSemanticBlanker > (which I will commit after the linux port works), and found another > problem. It is about comments in strings or vice versa. The following will > not parse correctly: > > // use " to delimit strings > const char* text = "a string"; > > nor does the following: > > const char* beginCComment = "/*"; > const char* beginOneLineComment = "file://"; Well spotted. I wrote that piece of code a while ago (before that project) and never got around using it... > These examples are not as exotic as they appear; I have certainly written > programs in the past which print out "file://". It looks like you can't > separate blanking comments and blanking strings. (I would try and fix it > myself, but I want to have it compile first.) Fell free to fix it. Though, we could easily pass it in the 'known bugs' section for the time being (the probably of running into that isn't so big)... > Cheers, > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-10-24 16:00:26
|
Folks, I'm working on the linux port. So far, the cppunit as included in our package doesn't compile; I think a few files are missing. About the parsing: As I said, I wrote a few tests for NonSemanticBlanker (which I will commit after the linux port works), and found another problem. It is about comments in strings or vice versa. The following will not parse correctly: // use " to delimit strings const char* text = "a string"; nor does the following: const char* beginCComment = "/*"; const char* beginOneLineComment = "//"; These examples are not as exotic as they appear; I have certainly written programs in the past which print out "//". It looks like you can't separate blanking comments and blanking strings. (I would try and fix it myself, but I want to have it compile first.) Cheers, Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-10-24 08:09:15
|
I added try/catch parser. The amount of code than can be parsed now is
nothing short of amazing !!!
I'll tackle the switch keyword UT next.
Baptiste.
|
|
From: Baptiste L. <gai...@fr...> - 2002-10-23 22:37:42
|
Greet. I already fixed two annoying parsing bugs (see KNOWSBUG). I'm tackling try/catch parsing, but that's for tomorrow (or should I say this morning ;-) ). Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Wednesday, October 23, 2002 11:45 PM Subject: [Cpptool-develop] I'm here > <nt> > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-10-23 21:45:22
|
<nt> -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
