cpptool-develop

[Cpptool-develop] ToDo list

[Sven R. <rei...@ma...>]

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...

[Cpptool-develop] ToDo list

[Sven R. <rei...@ma...>]

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...

Re: [Cpptool-develop] ToDo list

[Baptiste L. <gai...@fr...>]

----- 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...

Re: [Cpptool-develop] ToDo list

[Sven R. <rei...@ma...>]

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...

Re: [Cpptool-develop] ToDo list

[Baptiste L. <gai...@fr...>]

----- 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...

Re: [Cpptool-develop] ToDo list

[Sven R. <rei...@ma...>]

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...

RE: [Cpptool-develop] ToDo list

[Dakshinamurthy K <kd...@su...>]

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

RE: [Cpptool-develop] ToDo list

[Sven R. <rei...@ma...>]

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...

Re: [Cpptool-develop] XEmacs integration (was: ToDo list)

[Baptiste L. <gai...@fr...>]

----- 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...

Re: [Cpptool-develop] XEmacs integration

[Sven R. <rei...@ma...>]

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...

Re: [Cpptool-develop] XEmacs integration

[Sven R. <rei...@ma...>]

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...

Re: [Cpptool-develop] XEmacs integration

[Baptiste L. <gai...@fr...>]

Well, I more or less expected something like this.

Concerning the undo, while it is not yet an issue for VC6, this will become
one when we will move to refactoring that change more than one file (though
I understand that VC7 can handle that). I also expect this to be an issue
for some other IDE. So, there will probably be a common solution.

One question though. How are complex user interactions handled ?

For instance, the RenameClass refactoring while provide the user with a list
of found occurrences, tagging each occurrences with some sort of probability
tag reflecting how confident the parser is that it is a reference to the
same class (we now we'll never be perfect). The user would be able to
validate which occurrences should be replaced.

How would this be handled in emacs ? Creating a buffer with the list of
occurrences (like the 'window manager' of emacs) ?

Baptiste.

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Saturday, December 14, 2002 6:39 PM
Subject: Re: [Cpptool-develop] XEmacs integration


> 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...

Re: [Cpptool-develop] XEmacs integration

[Sven R. <rei...@ma...>]

On Sun, 15 Dec 2002, Baptiste Lepilleur wrote:

> One question though. How are complex user interactions handled ?
> 
> For instance, the RenameClass refactoring while provide the user with a list
> of found occurrences, tagging each occurrences with some sort of probability
> tag reflecting how confident the parser is that it is a reference to the
> same class (we now we'll never be perfect). The user would be able to
> validate which occurrences should be replaced.
> 
> How would this be handled in emacs ? Creating a buffer with the list of
> occurrences (like the 'window manager' of emacs) ?
> 

I would rather think of something along the line of emacs' "query 
replace". Thus, we go through the list of possible occurrences, display 
the corresponding file with the expression in question highlighted, and 
ask the user something like
"Replace class name (rfta confidence: 80%)?"
Optionally, we can skip this step for occurrences where our confidence is 
100% (might happen every once in a while).
The user would have the possibility to replace this occurrence, skip it, 
or (maybe) abort the whole refactoring. In emacs, this can be done in the 
minibuffer.

Sven.

-- 
Sven Reichard
Dept. of Math. Sci.
University of Delaware
rei...@ma...

Re: [Cpptool-develop] XEmacs integration

[Baptiste L. <gai...@fr...>]

Hmm, if I understood well, this is a basic search and replace. That would
mean that at no point the user would have a overview of all the occurrences,
right ? I think this could be useful as it allow the user to have an idea of
how much work will be needed, or to estimate the overall confidence rfta as
in the refactoring, or to do multiple exclusion at once.

Baptiste.

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Sunday, December 15, 2002 10:54 PM
Subject: Re: [Cpptool-develop] XEmacs integration


> On Sun, 15 Dec 2002, Baptiste Lepilleur wrote:
>
> > One question though. How are complex user interactions handled ?
> >
> > For instance, the RenameClass refactoring while provide the user with a
list
> > of found occurrences, tagging each occurrences with some sort of
probability
> > tag reflecting how confident the parser is that it is a reference to the
> > same class (we now we'll never be perfect). The user would be able to
> > validate which occurrences should be replaced.
> >
> > How would this be handled in emacs ? Creating a buffer with the list of
> > occurrences (like the 'window manager' of emacs) ?
> >
>
> I would rather think of something along the line of emacs' "query
> replace". Thus, we go through the list of possible occurrences, display
> the corresponding file with the expression in question highlighted, and
> ask the user something like
> "Replace class name (rfta confidence: 80%)?"
> Optionally, we can skip this step for occurrences where our confidence is
> 100% (might happen every once in a while).
> The user would have the possibility to replace this occurrence, skip it,
> or (maybe) abort the whole refactoring. In emacs, this can be done in the
> minibuffer.
>
> 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
>
>

Re: [Cpptool-develop] SplitTemporary refactoring

[Baptiste L. <gai...@fr...>]

----- 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...

Re: [Cpptool-develop] SplitTemporary refactoring

[Sven R. <rei...@ma...>]

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...

Re: [Cpptool-develop] SplitTemporary refactoring

[Baptiste L. <gai...@fr...>]

----- 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...