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-12-14 18:01:50
|
On Fri, 13 Dec 2002, Andre Baresel wrote: > I started getting into the sources, but I'm still not usefull for the > project :-( Take your time :) > i think it will take some time to get all the ideas. However I started > to play arround with > this Mutator concept and tried to implement this ToDo Item "Adding a > variable declaration in > if/while statement" ... not to make this for the public, but this is > something I can check against > later on, when you Baptiste have checked your sources in. > > I got something working, but well, I'm not sure if this is ok and > there's a question: > The introduction of a new nodetype for the conditions makes some of the > tests failing, so how is this situation > handled ? Is it ok than to change the tests, too - since the assertion > only reports the new ast-node-type not > beeing expected. Two things: 1) I'm not sure if you need a new nodetype for this situation; we have a type for variable definitions, which can just be plugged into the condition of the if statement. 2) In order not to break existing tests, don't include the new mutator into the MaxLODMutator. Then most tests won't know about your addition, and pass as before. I would wait changing the existing tests until you better understand the whole structure. (You said yourself that you're still working on that.) > > Another thing is the MaxLODMutator ... In the beginning I stumbled > accross two things: > - the methods "mutate" and "doMutate" sound like the same action and > take the same parameters but they > do completely different things ... I would suggest some better naming > here ... maybe doMutate is just "doMultipleMutate" ? I agree that here the code needs to be cleaned up a bit. The two methods do different things, both useful. "mutate" can be applied to any node and will change the whole subtree rooted at that node. It calls "doMutate" for every subnode it encounters, and that method does the actual work. Maybe we'll rename it to "mutateTree" and "mutateNode"? We wanted to separate the recursion from what is done to each node. That what the Visitor class (and its subclasses) are for. The basic reason is that if we were to change the implementation of the AST, we would only need to adapt the Visitor classes, and not every single method that works recursively. > - this MaxLODMutatorVisitor, what about that class, is this really needed ? > As I understand this class is only used to be instanciated in each > recursion of the mutation operation. > Is there anything I can't see ? The use of this class confused me > a little bit. With this class the recursion comes > Invisible for a person reading the source.... Just my opinion. And that's the idea! If someone wants to change a tree, they don't need to know how this change is performed. In the long run, we hope to move more functionality from the subclasses up to the Visitor class itself. > See you later, > Andre Bis die Tage, Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-12-14 17:39:50
|
For emacs, I came up with the following solution: - Create a text-based application which understands an easy to parse set of commands, and which allows to interactively refactor source files on disk. - Create a mode for emacs which communicates with that application. Both parts shouldn't be too complicated to implement. The application (let's call it "refactor") would still be platform independent, and hence perhaps generally useful. Since it operates directly on the files it will have to implement its own undo mechanism. I'll think about the interface for refactor, and I'll put something on the Wiki. Basically, a run would look as follows: > addAll src/rfta added 25 files > apply RenameTemp ToolsBox.cpp 245 15 newVariableName replaced 14 occurrences > saveAll saved 1 file(s) > quit where the variable occurs in line 245, column 15. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Andre B. <and...@gm...> - 2002-12-13 22:13:35
|
I started getting into the sources, but I'm still not usefull for the
project :-(
i think it will take some time to get all the ideas. However I started
to play arround with
this Mutator concept and tried to implement this ToDo Item "Adding a
variable declaration in
if/while statement" ... not to make this for the public, but this is
something I can check against
later on, when you Baptiste have checked your sources in.
I got something working, but well, I'm not sure if this is ok and
there's a question:
The introduction of a new nodetype for the conditions makes some of the
tests failing, so how is this situation
handled ? Is it ok than to change the tests, too - since the assertion
only reports the new ast-node-type not
beeing expected.
Another thing is the MaxLODMutator ... In the beginning I stumbled
accross two things:
- the methods "mutate" and "doMutate" sound like the same action and
take the same parameters but they
do completely different things ... I would suggest some better naming
here ... maybe doMutate is just "doMultipleMutate" ?
- this MaxLODMutatorVisitor, what about that class, is this really needed ?
As I understand this class is only used to be instanciated in each
recursion of the mutation operation.
Is there anything I can't see ? The use of this class confused me
a little bit. With this class the recursion comes
Invisible for a person reading the source.... Just my opinion.
I'll next go into these Scope things -
and in parallel i'm still collecting the useful infos from the forum and
the mailing list.
See you later,
Andre
|
|
From: Sven R. <rei...@ma...> - 2002-12-13 15:33:09
|
I started working on the split temporary refactoring. So far, it passes the easiest test case. The code needs still some cleaning up, e.g., create an abstract base class "Refactoring"; I copied and pasted quite a bit from rename temp. I started with this one since I understand its mechanic better than "reduce scope". Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-12-12 16:21:29
|
I dealt with a few things on the todo list. Namely, - phony template lists (as in x<2&&y> t) aren't parsed anymore; - renamed the SourceBuilder methods. For the template issues, I just scan the list for "&&" and "||". This make the test pass; I'm still thinking if there's anything else that should make the parsing fail. (Actually, now that I'm writing this, we should also deal with the 'and' and 'or' keywords...) Sven. Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-12-12 04:47:23
|
On Thu, 12 Dec 2002, Dakshinamurthy K wrote: > > We are using gcc-3.x for some time now (that is the > officially-released-2.96) and are very happy about it. Quite a few > standard-incompatibilities that existed in 2.95 have been fixed in this. > Can't we plan to work with gcc-3.x directly. Expect this to become the > standard soon... > I'm using 3.0.4 (Mandrake 8.2), and everything works fine. The issue was whether or not to support 2.96, which is the version included in RedHat 7.x and SuSe. For this version, boost doesn't compile "out of the box". I suggest to work with 3.x, and wait whether the boost people will support the older versions, or whether more distributors switch to the new compiler. Chances are that one of these things will happen before we have a shippable product ;-) Is anybody here who doesn't have access to either VC++ 6 or gcc 3? Sven Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Dakshinamurthy K <kd...@su...> - 2002-12-12 04:22:28
|
We are using gcc-3.x for some time now (that is the officially-released-2.96) and are very happy about it. Quite a few standard-incompatibilities that existed in 2.95 have been fixed in this. Can't we plan to work with gcc-3.x directly. Expect this to become the standard soon... KD -----Original Message----- From: cpp...@li... [mailto:cpp...@li...]On Behalf Of Sven Reichard Sent: Thursday, December 12, 2002 3:43 AM To: CppTool Mailing List Subject: Re: [Cpptool-develop] ToDo list On Wed, 11 Dec 2002, Baptiste Lepilleur wrote: > Do you mean that gcc 2.96 is worth than gcc 2.95 ? 2.96 was sort of an experimental version, never officially released by the FSF. However, for some reason, many distributors included this version in their latest releases. > Thanks. Though, don't lose too much time on this. I expect the boost issues > to solve themselves over time. I'll keep that in mind. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Cpptool-develop mailing list Cpp...@li... https://lists.sourceforge.net/lists/listinfo/cpptool-develop |
|
From: Sven R. <rei...@ma...> - 2002-12-11 22:15:21
|
On Wed, 11 Dec 2002, Baptiste Lepilleur wrote: > Bicycle Repair Man seems to provide xemacs integration. It would probably be > a good starting point. The link is on the Resources page of the wiki. I'll look at that, even if I don't know much about Python (or Lisp, for that matter :) ). Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-12-11 22:13:10
|
On Wed, 11 Dec 2002, Baptiste Lepilleur wrote: > Do you mean that gcc 2.96 is worth than gcc 2.95 ? 2.96 was sort of an experimental version, never officially released by the FSF. However, for some reason, many distributors included this version in their latest releases. > Thanks. Though, don't lose too much time on this. I expect the boost issues > to solve themselves over time. I'll keep that in mind. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-12-11 19:11:40
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Wednesday, December 11, 2002 3:48 PM Subject: Re: [Cpptool-develop] ToDo list > On Wed, 11 Dec 2002, Baptiste Lepilleur wrote: > > Also, notes that some gcc 2.95 issues should solves themselves over time. > > >From what I remember, somebody is working on Boost.Format with gcc 2.95. On > > the other hand, you may want to contact Beman Dawes concerning > > Boost.Filesystem issues. Another things that would be interesting to know if > > is the STLPort + gcc 2.95 combination works. > > I realized that I have access to either > - gcc 2.96 under Linux > - gcc 2.95 under SunOS. > > STLPort doesn't compile under any of these (out of the box). For 2.96, > they don't claim they support it (it's not a very good compiler, but sort > of standard for recent Linux distributions). Do you mean that gcc 2.96 is worth than gcc 2.95 ? > For gcc 2.95 under SunOS, it obviously hasn't crossed their minds that > somebody would want to do something like that. Basically, their > configuration header file contains something like > > # ifdef __GCC__ > # define some variables a certain way > # endif > > # ifdef __SunOS__ > # define them another way > # endif > > So, if both are defined, this doesn't compile. Quite strange, STLPort is renowned for its portability. And using gcc on other platform than linux is fairly common. Well, if anything, it would mean that the STLPort solution will not be simple if anything. > I'll keep working on it. Thanks. Though, don't lose too much time on this. I expect the boost issues to solve themselves over time. Baptiste. > > SVen. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-12-11 19:03:51
|
----- Original Message ----- From: "Baptiste Lepilleur" <gai...@fr...> To: "Sven Reichard" <rei...@ma...>; "CppTool Mailing List" <Cpp...@li...> Sent: Wednesday, December 11, 2002 9:40 AM Subject: Re: [Cpptool-develop] ToDo list > ----- Original Message ----- > From: "Sven Reichard" <rei...@ma...> > To: "CppTool Mailing List" <Cpp...@li...> > Sent: Tuesday, December 10, 2002 10:19 PM > Subject: [Cpptool-develop] ToDo list > > > > Baptiste, > > > > thanks for the detailed ToDo list on the Wiki. I will start exploring some > > of the Unix-related issues (gcc 2.9x, emacs integration). > > Great. Please add a 'exploring status' for the emacs tasks so that we know > something is being done. [...] Bicycle Repair Man seems to provide xemacs integration. It would probably be a good starting point. The link is on the Resources page of the wiki. Baptiste. > > Baptiste. > > > > > Sven. > > > > -- > > Sven Reichard > > Dept. of Math. Sci. > > University of Delaware > > rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-12-11 18:59:49
|
----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, December 11, 2002 3:41 PM
Subject: Re: [Cpptool-develop] SplitTemporary refactoring
> On Wed, 11 Dec 2002, Baptiste Lepilleur wrote:
>
> > Not so easy. You need to find where a temporary is being reassigned to
which
> > means some additional expression analysis. I think that more 'thinking'
need
> > to be done concerning this refactoring for C++. For example:
> >
> > double temp = 2 * (height_ + width_);
> > print( temp );
> > computeArea( height_, width_, temp );
> > ...
> >
> > void computeArea( double height, double width, double &area )
> > {
> > area = height + width;
> > }
> >
> > computeArea() is an indirect assignment to the local variable temp...
>
> We can start by looking at direct assignments. Nobody says that this
> refactoring has to catch all hidden assignments to the temporary. Direct
> assignments are of the form
>
> <name> = <expr>;
>
> The first of those should be transformed to
> <type> <name> = <expr>;
Sound fine for me. Limiting ourselves to finding assignement to the local
variable and splitting each time, this would make thing simpler.
[...]
> > Also, I don't get what you means by 'determining the type of a
variable'.
> > For a given local variable identifier, we can already find its
declaration
> > (see ScopeHolderTest) and therefore its type. So the real issue is
> > determining where a temporary is being reassigned to.
>
> I tried playing around with this; maybe the issue was getting access to
> the contents of a boost::weak_pointer.
See the smart_ptr documentation the boost/libs directory. Basically:
- boost::make_shared( weakPointer ) creates a shared_ptr, returning a null
pointer is the pointed object not longer exist.
- shared_ptr constructor also take a weak_ptr, but throw an exception is the
pointed object no longer exist.
Baptiste.
>
> Sven.
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...
|
|
From: Sven R. <rei...@ma...> - 2002-12-11 14:48:45
|
On Wed, 11 Dec 2002, Baptiste Lepilleur wrote: > Also, notes that some gcc 2.95 issues should solves themselves over time. > >From what I remember, somebody is working on Boost.Format with gcc 2.95. On > the other hand, you may want to contact Beman Dawes concerning > Boost.Filesystem issues. Another things that would be interesting to know if > is the STLPort + gcc 2.95 combination works. I realized that I have access to either - gcc 2.96 under Linux - gcc 2.95 under SunOS. STLPort doesn't compile under any of these (out of the box). For 2.96, they don't claim they support it (it's not a very good compiler, but sort of standard for recent Linux distributions). For gcc 2.95 under SunOS, it obviously hasn't crossed their minds that somebody would want to do something like that. Basically, their configuration header file contains something like # ifdef __GCC__ # define some variables a certain way # endif # ifdef __SunOS__ # define them another way # endif So, if both are defined, this doesn't compile. I'll keep working on it. SVen. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-12-11 14:41:18
|
On Wed, 11 Dec 2002, Baptiste Lepilleur wrote:
> Not so easy. You need to find where a temporary is being reassigned to which
> means some additional expression analysis. I think that more 'thinking' need
> to be done concerning this refactoring for C++. For example:
>
> double temp = 2 * (height_ + width_);
> print( temp );
> computeArea( height_, width_, temp );
> ...
>
> void computeArea( double height, double width, double &area )
> {
> area = height + width;
> }
>
> computeArea() is an indirect assignment to the local variable temp...
We can start by looking at direct assignments. Nobody says that this
refactoring has to catch all hidden assignments to the temporary. Direct
assignments are of the form
<name> = <expr>;
The first of those should be transformed to
<type> <name> = <expr>;
and all prior occurences of <name> need to be renamed. If we deal with
"indirect assignments", we need a global analysis of the code (i.e., find
the definition of computeArea).
>
> Also, I don't get what you means by 'determining the type of a variable'.
> For a given local variable identifier, we can already find its declaration
> (see ScopeHolderTest) and therefore its type. So the real issue is
> determining where a temporary is being reassigned to.
I tried playing around with this; maybe the issue was getting access to
the contents of a boost::weak_pointer.
Sven.
--
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...
|
|
From: Baptiste L. <gai...@fr...> - 2002-12-11 08:45:19
|
----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Tuesday, December 10, 2002 10:19 PM
Subject: [Cpptool-develop] ToDo list
> Baptiste,
> [...]
> Another easy (?) refactoring to consider is SplitTemporary. This includes
> some things which might be generally useful, like determining the type of
> a variable.
Not so easy. You need to find where a temporary is being reassigned to which
means some additional expression analysis. I think that more 'thinking' need
to be done concerning this refactoring for C++. For example:
double temp = 2 * (height_ + width_);
print( temp );
computeArea( height_, width_, temp );
...
void computeArea( double height, double width, double &area )
{
area = height + width;
}
computeArea() is an indirect assignment to the local variable temp...
Also, I don't get what you means by 'determining the type of a variable'.
For a given local variable identifier, we can already find its declaration
(see ScopeHolderTest) and therefore its type. So the real issue is
determining where a temporary is being reassigned to.
Baptiste.
>
> Sven.
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...
|
|
From: Baptiste L. <gai...@fr...> - 2002-12-11 08:34:56
|
----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Tuesday, December 10, 2002 10:19 PM Subject: [Cpptool-develop] ToDo list > Baptiste, > > thanks for the detailed ToDo list on the Wiki. I will start exploring some > of the Unix-related issues (gcc 2.9x, emacs integration). Great. Please add a 'exploring status' for the emacs tasks so that we know something is being done. Also, notes that some gcc 2.95 issues should solves themselves over time. From what I remember, somebody is working on Boost.Format with gcc 2.95. On the other hand, you may want to contact Beman Dawes concerning Boost.Filesystem issues. Another things that would be interesting to know if is the STLPort + gcc 2.95 combination works. Baptiste. > > Sven. > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-12-10 21:19:36
|
Baptiste, thanks for the detailed ToDo list on the Wiki. I will start exploring some of the Unix-related issues (gcc 2.9x, emacs integration). Another easy (?) refactoring to consider is SplitTemporary. This includes some things which might be generally useful, like determining the type of a variable. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-12-09 09:06:56
|
Hi,
I'm in the process of adding variable declaration to if/while
statements:
if ( int c = nextChar() )
...
This is actually done. When updating the test for the ScopeGenerator, I
actually found a bug: the condition scope is not parent of the then and else
statement scopes. I'm in the process of changing this. It will likely
involve a partial rewrite of the ScopeGenerator class, so avoid change to
this class.
The current solution I've found is to drive more of the visitation from
the 'scope generation description'. Basically, the description should
indicate that for a while statement node,
- the condition scope should be created
- condition expression should generate scopes (variable declarations)
and make the condition scope the parent
- scopes should be generated for the then and else statements and the
scope generated by the condition expression should be their parent.
- then and else statement node should be visited for further scope
generation.
Not yet well defined, but that's the general idea.
Baptiste.
|
|
From: Dakshinamurthy K <kd...@su...> - 2002-12-06 17:36:13
|
I am also lurking for the time being - too much work pressures. I hope to get in few weeks from now. Thanks and Regards KD -----Original Message----- From: cpp...@li... [mailto:cpp...@li...]On Behalf Of Ian Davis Sent: Friday, December 06, 2002 10:53 PM To: Cpp...@li... Subject: Re: [Cpptool-develop] SourceBuilder::add3 > BTW, is there anybody on this list except for Baptiste and me? I'm lurking. Hoping to learn before diving in. -- Ian ------------------------------------------------------- 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: Ian D. <ia...@in...> - 2002-12-06 17:21:46
|
> BTW, is there anybody on this list except for Baptiste and me? I'm lurking. Hoping to learn before diving in. -- Ian |
|
From: JUDD J. <joh...@te...> - 2002-12-05 22:01:44
|
>=20 > Good :) You would also be the only one with access to the list of=20 > subscribers. >=20 Aren't you able to access that as an admin? > BTW, I got an email today from somebody from Germany who=20 > wanted to join.=20 > Unfortunately his email address was invalid, so I couldn't=20 > get back to=20 > him.=20 >=20 I got an email from a couple of people too. I told them to use the projects= general forum to enquire, or to contact you directly. Cheers John |
|
From: Sven R. <rei...@ma...> - 2002-12-05 20:35:29
|
On Thu, 5 Dec 2002, Baptiste Lepilleur wrote: > All cpp in bin/ are test datas. They should probably live in a test-data > directory or something like that. Since they don't change, there is no need > to change the test.bat script. > > All real sources live in include/ and src/. > Ok, thanks for clearing this up. I'll try to run the tests again. Sven. -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
|
From: Baptiste L. <gai...@fr...> - 2002-12-05 19:18:25
|
Great ! I was able to retrieve a recent version of the CppRefactoring page (in html) from my web cache at work. I'll update the wiki as soon as I can (need heavy reformatting). Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Thursday, December 05, 2002 4: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... > > > > ------------------------------------------------------- > 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-12-05 19:17:22
|
All cpp in bin/ are test datas. They should probably live in a test-data directory or something like that. Since they don't change, there is no need to change the test.bat script. All real sources live in include/ and src/. Baptiste. ----- Original Message ----- From: "Sven Reichard" <rei...@ma...> To: "CppTool Mailing List" <Cpp...@li...> Sent: Thursday, December 05, 2002 4:50 PM Subject: Re: [Cpptool-develop] ASTDumper > On Wed, 4 Dec 2002, Baptiste Lepilleur wrote: > > > What was the failure ? Are you sure you specified the range correctly ? > > > > I've just run bin/test.bat and all are correctly processed (Main.cpp is 11th > > test and works fine). Try to adapt bin/test.bat to linux (removing the > > initial del should do). > > > > Baptiste. > > I was a bit confused, since there are two copies of the ASTDumper files > (one is in src/astdumper, the other in bin). Which one is the correct one? > > > -- > Sven Reichard > Dept. of Math. Sci. > University of Delaware > rei...@ma... |
|
From: Sven R. <rei...@ma...> - 2002-12-05 15:51:10
|
On Wed, 4 Dec 2002, Baptiste Lepilleur wrote: > What was the failure ? Are you sure you specified the range correctly ? > > I've just run bin/test.bat and all are correctly processed (Main.cpp is 11th > test and works fine). Try to adapt bin/test.bat to linux (removing the > initial del should do). > > Baptiste. I was a bit confused, since there are two copies of the ASTDumper files (one is in src/astdumper, the other in bin). Which one is the correct one? -- Sven Reichard Dept. of Math. Sci. University of Delaware rei...@ma... |
