Menu
▾
▴
cpptool-develop
|
From: Sven R. <rei...@ma...> - 2002-10-28 17:02:50
|
I solved the problem by reloading the whole code into a new directory :0 well, there should be a better way. The code doesn't compile under Linux. I'm trying to fix this. One issue is the "MSVC for-scope bug"; I'll write more on that on the Wiki. I would strongly suggest that we stop adding functionality at this point, and thoroughly test what we have so far. Any comments? Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-10-28 19:06:30
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Monday, October 28, 2002 6:02 PM Subject: [Cpptool-develop] checkout [...] > The code doesn't compile under Linux. I'm trying to fix this. One issue is > the "MSVC for-scope bug"; I'll write more on that on the Wiki. > Sven. I aware of that bug. I probably splipped. I take as a coding not to use twice the same loop iterator name in a method. That way, you show that there is no relation between the first and the second loop, and it's also a source of portability issues. Baptiste. [...] > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... > > > > ------------------------------------------------------- > 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...> - 2002-10-28 19:35:23
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Monday, October 28, 2002 6:02 PM Subject: [Cpptool-develop] checkout [...] > I would strongly suggest that we stop adding functionality at this point, > and thoroughly test what we have so far. Any comments? I don't agree. The parsing base is already fairly good (it can parse a lot of sources). I'm trying to have a working refactoring as soon as possible (see below for the reason). My current toward testing is: - If I find a bug, don't fix it until there is a test case for it (the 'switch' bug is an example of this). - If I have any doubt weither a bug is in the code I'm testing or in a 'base' used by the code, add test for the 'base'. - Test complex stuffs - When testing assumes that your 'base' is working (it has its one test). For example, when testing VariableDeclCollector, a specialization of VariableDeclVisitor, I only tested for the added functionnalities. The parse test coverage is already fairly good. Only a few parser don't have UT yet, and they are fairly trivial. astdump seems to indicates they work somewhat as expected. The *core* part of the parser is the VariableDeclMutator (which is ill named since it is a parser...). This is the inovative part as it recognize a variable declaration without any complex analysis, that's one of the real breakthough of my approach to parsing C++. This piece of code is already reasonnably tested (though not completly). What I'm targetting now is getting one or two refactorings to work. Once we have something working reasonnably well (I'm thinking of RenameTemp with scope), we can release it to the 'world' and show that our approach is 'working'. A proof of concept if you want. This should help attracting more people on this project, especially since it's so simple... rfta is what I expect to become the 'refactoring' engine (mid term). For now it does refactoring and source rewritting (and some bit of parsing). The current (untested) implementation uses a TextDocument as input and output (an abstraction of the source container in the IDE), and does the full cycle of parsing, analysing (temporary declaration location, temporary occurrences) and transforming (replacing the temporary name). We're working on an open-source project and time is precious (at least mine is ;-) ). Being able to release something quickly is a great motivational factor. The exposure you get with a release is way greater that any set of tests you can build (that why open-source works). I also have some other projects that are in the background for now, but will need to be worked on soon (need cppunit release, CppUnit 2.0...). If there is some particular area of the code you would like me to explain, let me know. A lot of the code is somewhat crude, but then I expect a lot refactoring to occurs when a complete parser is implemented (parsing for parameter, attribute, return type... is a lot like parsing for variable declaration). Baptiste. > > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... --- Baptiste Lepilleur <gai...@fr...> http://gaiacrtn.free.fr/ |
|
From: Sven R. <rei...@ma...> - 2002-10-28 21:49:30
|
Ok, I see your point. However, I believe in the philosophy of "If it's not tested, consider it broken". So, unless you have anything else for me to do, I will continue to write unit tests. Our project tester, Victor, doesn't appear to be subscribed to this list. There are plenty of untested classes in the rftaparser directory, which you probably consider trivial, but which I still need to understand. A conceptual question: Does the refactoring engine directly rewrite the sources, or does it change the AST representation, which then writes the sources independently? This is not an issue yet, but the latter strategy would help avoiding re-parsing for each refactoring step. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-10-29 06:34:19
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Monday, October 28, 2002 10:48 PM Subject: Re: [Cpptool-develop] checkout > Ok, I see your point. However, I believe in the philosophy of "If it's not > tested, consider it broken". So, unless you have anything else for me to > do, I will continue to write unit tests. Our project tester, Victor, > doesn't appear to be subscribed to this list. There are plenty of untested > classes in the rftaparser directory, which you probably consider trivial, > but which I still need to understand. The class that need the most tests is VariableDeclMutator. It's non trivial and not so easy to test. All other class are fairly simple and can be tested/fixed in a few minutes... > A conceptual question: Does the refactoring engine directly rewrite the > sources, or does it change the AST representation, which then writes the > sources independently? This is not an issue yet, but the latter strategy > would help avoiding re-parsing for each refactoring step. I did it the 'simplest way that could possibly work', in this case, the refactoring creates a list of ReplaceTextTransform which are applied on the TextDocument. There is no need for an AST rewritter at the current time. In fact I don't have a clue on how to write one. There is a lot of issues raised by this (which part of the AST did change, how to deal with spacing, how to represent the AST transform...) Baptiste. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-10-29 15:52:52
|
On Tue, 29 Oct 2002, Baptiste Lepilleur wrote: > > The class that need the most tests is VariableDeclMutator. It's non trivial > and not so easy to test. All other class are fairly simple and can be > tested/fixed in a few minutes... Ok, I'll look into that. > I did it the 'simplest way that could possibly work', in this case, the > refactoring creates a list of ReplaceTextTransform which are applied on the > TextDocument. There is no need for an AST rewritter at the current time. In > fact I don't have a clue on how to write one. There is a lot of issues > raised by this (which part of the AST did change, how to deal with spacing, > how to represent the AST transform...) You're right. I went ahead of myself. However, I didn't see exactly what was going on. One reason I tried to insist on more tests was also that they can serve as some kind of documentation; so far you are the only one who really understands the code. I don't mean to say that it is hard to read, it just will take some time and effort from my side. Sven. > Baptiste. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X