cpptool-develop — CppRefactory Developer Mailing List

Re: [Cpptool-develop] welcome back

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

On Wed, 23 Apr 2003, Baptiste Lepilleur wrote:
> 
> You're fast, I intented to write the mail this morning with a fresher head
> ;-)

I finally sbuscribed to the CVS mailing list :)

> 
> By the way Sven, would you mind changing your editor settings from 'insert
> tabs' to 'insert spaces' ? This would allow the code to be correctly
> indented without regards to the editor settings.

Hmmm... usually emacs inserts spaces. The only issue that I can think of 
is that when adding a statement, it uses the indentation space found in 
the previous statement. Where there tabs in all the code I added?

I still need to remember to change the indentation space; right now emacs 
uses 2 spaces, where as in most of the code, 3 spaces are used, if I'm not 
mistaken.
> 
> Don't ever do that. stdafx.h is an optimization only (I made some benchmark
> a while ago with an old project and it saved about 5 seconds out of 35
> seconds for a complete build). The project should compile correctly fine if
> stdafx.h is a blank file. Only widely used STL headers should go there. If
> it does not compile on Unix, then it is a bug, and the missing STL include
> should be added.

Ok. BTW, your timing is impressive. gcc is way slower. Just tested, it 
uses 7 min for a complete rebuild (with tests, but without eclipse and VC 
plugins) :( But then, I have a slow computer.

 > 
> I figured it was something like that. I usually deal with this by either
> configuring the compiler to break when a C++ exception is thrown, or by
> placing a break point in the exception constructor. Is it not possible to do
> that for you ?

I'll think about that. 
> 
> If so, we may want to introduce a asssertion facilities (throw exception in
> standard mode, break in 'advanced debug mode').

Is it correct that during normal execution of the code, no exceptions are 
thrown? Then I could just switch off support for exceptions. However, I 
think that at least CppUnit relies heavily on them.
> 
> Check out the boost documentation in boost/libs/smart_ptr. You'll find the
> few functions to deal with smart-pointer (cast...), as well as a new page
> explaining the many use of shared_ptr.
> 
> > The other point is that I understand the use of shared pointers if we have
> > several pointers to the same object, and it is not clear which one will
> > survive longer. IMO this is not the case when dealing with a visitor; the
> > host calls a method of the visitor in its accept method, and the host
> > certainly exists during the execution of the method. Thus an ordinary
> > pointer is sufficient in this case; since it is simpler to manage (and
> > more efficient) it should be preferred.
> > Please let me know if I'm missing a good reason why to use shared pointers
> > here.
> 
> Yes there is. This allow you to collect code element while visiting and
> reuse them when transforming the code. Main use though would probably be to
> move statements and declarations around.

I still need to get used to the idea of a visitor modifying the structure 
(not only the content) of the object it is visiting.

> > doubley[3];
> >
> > We have to find some policy to sensibly add a space in such situations. I
> > still haven't figured it out, but I'll keep thinking.
> 
> My thougth as do have something like insert a space if the primary type
> (+secondary ?) ends with a letter, > or ] (probably slightly more complexes
> because of secondary type prefix). When stumbling on weird case like this, I
> tried to apply test first design (write the test and get them to work).

I have added a test for this.

> 
> 
> > Do we have any class that does this, or should I derive my own document
> > from LineBasedTextDocument?
> 
> Yes, that what you need to do (and what is done in by the VC++ add-in). Be
> aware that there is still a known bug to deal with: tabulations are not
> converted to the correct column number.

Ok, that's what I'll do.


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

[Cpptool-develop] Emacs, was: welcome back

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

On Wed, 23 Apr 2003, Rohith Rajagopal wrote:

>    I use Xemacs for writing all my code. So I could be your tester.
> Thanks,
> Rohith.

   Ok, I'll let you know when something works. I'll try to get two or 
three of our refactorings to work. Most of the code (or at least the 
ideas) so far are shamelessly stolen from BRM.

Sven.

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

Re: [Cpptool-develop] Declaration parsing started...

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

I'll give this a more thorough look later on. A few primilary remarks
though:

Our 'C++' is wider than the standard (we have single pass parsing). For
example, we should support class declaration such as:

class RFTA_API TextDocument { };

Were RFTA_API is stored as the optional 'export macro name'. This is a
widely used idiom on Win32.

The AST should capture all data required for the source code manipulation
(capture the range of all element that might be removed, inserted,
modified).

A primary goal would probably be able to identify the function/method bodies
(this would solve the issue you raised concerning the starting compound
statement for variable declaration search).

Next, I would probably go for class parsing (rough, just extract the name,
methods, and method/function implementation parsing. Having those two open
doors for ExtractInterface refactoring (just needs the class methods), and
ExtractMethod refactoring (need to add a method in the class declaration,
adding a new method body, and know what are the method parameters).

Baptiste.

----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Thursday, April 17, 2003 9:26 PM
Subject: [Cpptool-develop] Declaration parsing started...


> hello together,
>
> I'm currently working on the "declaration" parsing.
>
> That's stuff like:
>
> typedef class x { ... } x_type;
> const int * (*f)(...);
>
> I've analyzed the C++ Spec. and identified the following elements.
> However I'm not yet sure if the parsing has to go that deep at the moment.
> Maybe at implementation phase I decide to reduce the level for the first.
>
> Here comes a proposal for a possible AST structure:
> ===============================================================
> * Declaration-Level-Elements
>
> // each declaration consists of a list of specifier and a list of
> declarators (with optional init part)
> [simple-declaration]
>   declaration-specifier-property => [declaration-specifier-list]    //
> specifiers for all declarators...
> n [init-declarator]        // each declaration can declare 'n' identifier
>
> [declaration-specifier-list]    // type declaration is organized as list
> n [declaration-specifier]
>
> [init-declarator]                   // each declarator consist of a
> declarator identifier, initialize-part and the declarator-description
> (pointer, const, ref etc.)
>   ?identifier-property => [#declarator-identifier]
>   ?initializer => [expression]
>   declarator-property => [unparsed-declarator] , [declarator]
>
> [unparsed-declarator]
> #mutate: declarator
>
> [declarator]                    // declarators are organized
> hierarchical, the property 'sub-declarator-property' links to the sub
> element.
>   ?sub-declarator-property => [declarator]
> ?[function-declarator]            // int ... (...)
> ?[array-declarator]            // int ... [...]
> ?[#braces]                // int (...)
> ?[ptr-declarator]            // int (* ...)
> ?[#ref-declarator]            // int (& ...)
> ?[named-ptr-declarator]            // int (::c::d * ...)
>
> [declaration-specifier]
> ?[#type-specifier]   // "simple-type-specifier" (char, wchar_t, bool,
> etc.) also "cv-qualifier" ---> see C++ Spec.
> ?[class-specifier]          // full class spec: "class x { ... }"
> ?[enum-specifier]          // full enum spec
> ?[elaborated-type-specifier]  // something like "class xxx" or "struct y"
> ===============================================================
>
> I will put this on a wiki page for discussion
> and add examples which use this ast.
>
> Just feel free to send your opinion !
>
> greetings,
> André

Re: [Cpptool-develop] Status...

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

----- Original Message -----
From: "Devrim Erdem" <de...@ma...>
To: <and...@gm...>; <cpp...@li...>
Sent: Saturday, April 12, 2003 4:35 PM
Subject: Re: [Cpptool-develop] Status...


> Andre Baresel wrote:
>
> > Devrim Erdem wrote:
> >
> >> I have been a member of the mailing list for some time now,but I
> >> shall confess I haven't been reading all the mails posted.
> >>
> >> I use Jedit for C++ development on Linux. As far as I know cpptool
> >> has a plugin for Eclipse. I am not well informed about how it can be
> >> interfaced to other editor, e.g. jedit but I would like to hear and
> >> learn about it.
> >>
> >> Jedit being a java based editor, it supports python for plugins.
> >> Therefore it is possible to write a python script and run it in Jedit.
> >>
> >> I would be interested in learning how it can be possible to integrate
> >> CppTool to Jedit via python interface. Or is there any other way of
> >> doing it ?
> >>
> >>>
> >>>  I'm thinking of using python to implement the code analysis and
> >>> refactoring layer of the code. This would hopefully help us going
> >>> faster. What do you think ?
> >>>
> >>
> >> I am not familiar with internals of CppTool but this kind of  layer I
> >> have for my own projects and they significantly speed up development.
> >>
> > Hello Devrim,
> >
> > I'm the author of the eclipse plugin. The way I've implemented this
> > was very similar to the Visual-Studio-Plugin. I've written a native
> > class which
> > simply maps the access/modify routines of a text document of our
> > CppTool into access/modify routines of the java-class responsible for
> > the editor
> > of eclipse. This was very simple since only very basic operations need
> > to be written.
> > - get selection text
> > - set selection area
> > - set selection text
> > such things are very common for an editor. So if you find such an
> > interface in phyton it would be possible to integrate.
>
> Sure there exists such functionality in Jedit's python interface.

Does Jython support python extension (python module implemented in DLL) ? If
it is the case, the we could move from using JNI for binding to using
Boost.Python + Jython.

What would be needed then is subclassing a TextDocument class exported to
python.

>
> But i have a question. I understand that there are refactoring
> operations which will need to modify several files at once.  Are those
> also supported already in CppTool and in your native class ?

Modification are done using the TextDocument interface, which at the current
you provide when asking for a refactoring (all works on the active
document).

Working on multiple files introduce other issues, such as:

undo/redo: does the IDE support group command (all text modification made on
multiple documents can be automatically undo) ?

project interface: interfacing with the IDE to retreive the files that
compose the project, and obtaining a TextDocument interface for those file.

Baptiste.

> > To check the other plugins look at
> >    EclipseDocumentHelper.cpp/h            (this is the interface
> > between CppTool and Eclipse-Editor)
> >    VCLinebasedTextDocument.cpp/h     (this is the interface between
> > CppTool and VisualStudio-Editor)
> >
> > nice to meet you,
> > André Baresel
> >
> > The summer is starting in berlin,
> > GREAT !
>
> Also in Rosenheim, Bayern !

Re: [Cpptool-develop] welcome back

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

----- Original Message -----
From: "Sven Reichard" <rei...@ma...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Wednesday, April 23, 2003 6:04 AM
Subject: [Cpptool-develop] welcome back


> Hi guys,
>
> first of all a warm welcome back to blep; I hope you enjoyed your holiday.
> I also appreciate the improvements you made to the code I recently
> submitted. Let me explain the rationale behind some of the things I had
> there.

You're fast, I intented to write the mail this morning with a fresher head
;-)

By the way Sven, would you mind changing your editor settings from 'insert
tabs' to 'insert spaces' ? This would allow the code to be correctly
indented without regards to the editor settings.

> - Preprocessor condition around <map> inclusion: I figured that for VC the
> template declarations should go into stdafx; I should have actually
> included <stdafx.h> to make it compatible.

Don't ever do that. stdafx.h is an optimization only (I made some benchmark
a while ago with an old project and it saved about 5 seconds out of 35
seconds for a complete build). The project should compile correctly fine if
stdafx.h is a blank file. Only widely used STL headers should go there. If
it does not compile on Unix, then it is a bug, and the missing STL include
should be added.

> - The extraneous assert: This was due to my limited use of the debugger;
> if rfta throws an exception, I only know that some error occurs. If an
> assertion fails, I can inspect (via a core dump) the complete call stack
> and all local variables. I should have removed this once I found the bug.

I figured it was something like that. I usually deal with this by either
configuring the compiler to break when a C++ exception is thrown, or by
placing a break point in the exception constructor. Is it not possible to do
that for you ?

If so, we may want to introduce a asssertion facilities (throw exception in
standard mode, break in 'advanced debug mode').

> - Changing shared to regular pointers: Part of it was, as I have said,
> that I didn't feel comfortable with shared pointers yet; thanks for
> pointing out the possibility of a dynamic cast for shared pointers. I
> actually had to deal with a bug where a null DeclarationPtr was
> dereferenced; I changed it to a regular pointer to see better what was
> going on.

Check out the boost documentation in boost/libs/smart_ptr. You'll find the
few functions to deal with smart-pointer (cast...), as well as a new page
explaining the many use of shared_ptr.

> The other point is that I understand the use of shared pointers if we have
> several pointers to the same object, and it is not clear which one will
> survive longer. IMO this is not the case when dealing with a visitor; the
> host calls a method of the visitor in its accept method, and the host
> certainly exists during the execution of the method. Thus an ordinary
> pointer is sufficient in this case; since it is simpler to manage (and
> more efficient) it should be preferred.
> Please let me know if I'm missing a good reason why to use shared pointers
> here.

Yes there is. This allow you to collect code element while visiting and
reuse them when transforming the code. Main use though would probably be to
move statements and declarations around.

This also makes binding to python slightly easier (Boost.Python autmatically
figure out was is the life-time of the function parameter).

> As I said, I like the code model. However, one of the known bugs in
> SplitDeclaration is related to a problem in the Rewriter, which I still
> don't know how to circumvent.
>
> Consider the following declaration
>
> double* x,y[3];
>
> This might not be good style, but it is perfectly legal, and I have
> actually seen something similar in several programs. If we remove the
> first declarator "* x," (note that I moved the '*' to the secondary type
> of the declarator, to prevent a more dangerous bug), we end up with
>
> doubley[3];
>
> We have to find some policy to sensibly add a space in such situations. I
> still haven't figured it out, but I'll keep thinking.

My thougth as do have something like insert a space if the primary type
(+secondary ?) ends with a letter, > or ] (probably slightly more complexes
because of secondary type prefix). When stumbling on weird case like this, I
tried to apply test first design (write the test and get them to work).

>
> I haven't gotten Eclipse yet, but I continue working on the Emacs
> integration. In general it is clear what has to be done. BTW, is anybody
> else here using Emacs? If yes, I will upload the code as soon as it does
> something; otherwise, I will keep it here for now.
>
> What I would need would be something like line based text document, where
> all I need is the plain text document interface, together with a
> translation from 2-d coordinates to 1-d indices. Selection won't be
> supported for a while, I think. More accurately, selection will be used
> only unidirectionally from emacs to rfta, and not vice versa.

> Do we have any class that does this, or should I derive my own document
> from LineBasedTextDocument?

Yes, that what you need to do (and what is done in by the VC++ add-in). Be
aware that there is still a known bug to deal with: tabulations are not
converted to the correct column number.

Baptiste.

>
> Enough for tonight.
>
> Later,
> Sven.
>
> --
> Sven Reichard
> Dept. of Math. Sci.
> University of Delaware
> rei...@ma...

[Cpptool-develop] welcome back

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

Hi guys,

first of all a warm welcome back to blep; I hope you enjoyed your holiday. 
I also appreciate the improvements you made to the code I recently 
submitted. Let me explain the rationale behind some of the things I had 
there.

- Preprocessor condition around <map> inclusion: I figured that for VC the 
template declarations should go into stdafx; I should have actually 
included <stdafx.h> to make it compatible.

- The extraneous assert: This was due to my limited use of the debugger; 
if rfta throws an exception, I only know that some error occurs. If an 
assertion fails, I can inspect (via a core dump) the complete call stack 
and all local variables. I should have removed this once I found the bug.

- Changing shared to regular pointers: Part of it was, as I have said, 
that I didn't feel comfortable with shared pointers yet; thanks for 
pointing out the possibility of a dynamic cast for shared pointers. I 
actually had to deal with a bug where a null DeclarationPtr was 
dereferenced; I changed it to a regular pointer to see better what was 
going on. 
The other point is that I understand the use of shared pointers if we have 
several pointers to the same object, and it is not clear which one will 
survive longer. IMO this is not the case when dealing with a visitor; the 
host calls a method of the visitor in its accept method, and the host 
certainly exists during the execution of the method. Thus an ordinary 
pointer is sufficient in this case; since it is simpler to manage (and 
more efficient) it should be preferred.
Please let me know if I'm missing a good reason why to use shared pointers 
here.

As I said, I like the code model. However, one of the known bugs in 
SplitDeclaration is related to a problem in the Rewriter, which I still 
don't know how to circumvent.

Consider the following declaration

double* x,y[3];

This might not be good style, but it is perfectly legal, and I have 
actually seen something similar in several programs. If we remove the 
first declarator "* x," (note that I moved the '*' to the secondary type 
of the declarator, to prevent a more dangerous bug), we end up with

doubley[3];

We have to find some policy to sensibly add a space in such situations. I 
still haven't figured it out, but I'll keep thinking.

I haven't gotten Eclipse yet, but I continue working on the Emacs 
integration. In general it is clear what has to be done. BTW, is anybody 
else here using Emacs? If yes, I will upload the code as soon as it does 
something; otherwise, I will keep it here for now.

What I would need would be something like line based text document, where 
all I need is the plain text document interface, together with a 
translation from 2-d coordinates to 1-d indices. Selection won't be 
supported for a while, I think. More accurately, selection will be used  
only unidirectionally from emacs to rfta, and not vice versa.

Do we have any class that does this, or should I derive my own document 
from LineBasedTextDocument?

Enough for tonight.

Later,
Sven.

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

[Cpptool-develop] new refactoring

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

In order to understand the code model component, I tried to implement a 
silly little refactoring which I would call SplitDeclaration. Basically, 
it transforms something like
{
  double *x, y[3], &z;
}
to
{
  double *x;
  double y[3];
  double &z;
}
This is useful if e.g., we want to modify the declaration of one of the 
variables, like make it const. It also avoids one common mistake, namely

int* x, y; // these are not two pointers

It is fully implemented using the code model, though the code is still a 
bit ugly, since I haven't gotten used to dealing with shared pointers yet. 
I will clean it up a bit before committing it.

In order to make it run, I had to modify the way declaration expressions 
are handled in the model/rewriter. I committed the changes, as well as the 
tests that made them necessary.

As I said, the main purpose was to understand the code model, and I start 
to like it :) I still have a few questions, but they can wait until 
Baptiste gets back.

More later,
Sven.

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

Re: [Cpptool-develop] linux

[Andre B. <and...@gm...>]

Sven Reichard wrote:

>[eclipse]
>I just checked it out, and it's a 70 MB download... I'll find some way, 
>though :)
>  
>
Take the SDK version since this contains the plug-ins to build a PlugIn 
comfortably.
I think I have included a text file where you can see how to develop and 
debug plugins.

-- until later,
andré

Re: [Cpptool-develop] linux

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

On Thu, 17 Apr 2003, Andre Baresel wrote:
> Btw) Do you have tried to use Eclipse under linux ?

I just checked it out, and it's a 70 MB download... I'll find some way, 
though :)

> It would be nice to have also running libraries for the linux version of 
> eclipse.
> This integration is done in windows by DLLs, but I think there's a 
> simple solution
> for native java-code under linux too.
> 
> until later,
> Andre
> 
> 
> 

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

[Fwd: Re: [Cpptool-develop] linux]

[Andre B. <and...@gm...>]

[Cpptool-develop] Declaration parsing started...

[Andre B. <and...@gm...>]

hello together,

I'm currently working on the "declaration" parsing.

That's stuff like:

typedef class x { ... } x_type;
const int * (*f)(...);

I've analyzed the C++ Spec. and identified the following elements.
However I'm not yet sure if the parsing has to go that deep at the moment.
Maybe at implementation phase I decide to reduce the level for the first.

Here comes a proposal for a possible AST structure:
===============================================================
* Declaration-Level-Elements

// each declaration consists of a list of specifier and a list of 
declarators (with optional init part)
[simple-declaration]
  declaration-specifier-property => [declaration-specifier-list]    // 
specifiers for all declarators...
n [init-declarator]        // each declaration can declare 'n' identifier

[declaration-specifier-list]    // type declaration is organized as list
n [declaration-specifier]

[init-declarator]                   // each declarator consist of a 
declarator identifier, initialize-part and the declarator-description 
(pointer, const, ref etc.)
  ?identifier-property => [#declarator-identifier]
  ?initializer => [expression]
  declarator-property => [unparsed-declarator] , [declarator]

[unparsed-declarator]
#mutate: declarator

[declarator]                    // declarators are organized 
hierarchical, the property 'sub-declarator-property' links to the sub 
element.
  ?sub-declarator-property => [declarator]
?[function-declarator]            // int ... (...)
?[array-declarator]            // int ... [...]
?[#braces]                // int (...)
?[ptr-declarator]            // int (* ...)
?[#ref-declarator]            // int (& ...)
?[named-ptr-declarator]            // int (::c::d * ...)

[declaration-specifier]
?[#type-specifier]   // "simple-type-specifier" (char, wchar_t, bool, 
etc.) also "cv-qualifier" ---> see C++ Spec.
?[class-specifier]          // full class spec: "class x { ... }"
?[enum-specifier]          // full enum spec
?[elaborated-type-specifier]  // something like "class xxx" or "struct y"
===============================================================

I will put this on a wiki page for discussion
and add examples which use this ast.

Just feel free to send your opinion !

greetings,
André

[Cpptool-develop] linux

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

Hello guys,

yes, I'm still alive... I'm just currently very busy with my thesis, 
that's why I didn't do anything for the project for the last couple of 
months. 

I know I have still at least two open tasks, i.e., split temp and emacs 
integration. Before I continue to work on this, I would like to understand 
the source code as it is now.

I managed to compile the current source code, with two exceptions. The 
first was a littly typo in some file (I forgot which one) where the first 
line started with
/ ///////
instead of 
////////
The second is more serious. In the file rfta/CodeModelGeneratorTest.cpp, 
line 51, we initialize a non-constant reference to 
CodeModel::DeclaratorExpressionPtr
with the result of a call to generator.generateDeclarator. This method 
does not return a reference, but a DeclaratorExpressionPtr; at least in 
gcc such an intialization is illegal. I guess this could be fixed by 
removing the "&" from the declaration, but I wanted to check with you 
first.

I have seen that you did quite some work on various plugins and a Python 
interface; good job. However, can you tell me if there have been 
fundamental changes in the core libraries rfta and rftaparser? I haven't 
checked out the Wiki yet. In particular, is the CodeModel used in any of 
the refactorings yet? Any pointers would be appreciated.

Cheers, and keep up the good work,
Sven.

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

[Cpptool-develop] File level parsing has been checked in !

[Andre B. <and...@gm...>]

Hello together,

it's done - the first code for parsing at file level has been added to 
the repository.
Look at the tests in files "DeclarationParserTest.cpp" and 
"DeclarationListParserTest.cpp".
The List testing is not much, but I expect we will add there special 
cases of declaration combinations.

until later,
André

Re: [Cpptool-develop] Status...

[Andre B. <and...@gm...>]

>
>
>> Hello Devrim,
>>
>> I'm the author of the eclipse plugin. The way I've implemented this 
>> was very similar to the Visual-Studio-Plugin. I've written a native 
>> class which
>> simply maps the access/modify routines of a text document of our 
>> CppTool into access/modify routines of the java-class responsible for 
>> the editor
>> of eclipse. This was very simple since only very basic operations 
>> need to be written.
>> - get selection text
>> - set selection area
>> - set selection text
>> such things are very common for an editor. So if you find such an 
>> interface in phyton it would be possible to integrate. 
>
>
> Sure there exists such functionality in Jedit's python interface.
>
> But i have a question. I understand that there are refactoring 
> operations which will need to modify several files at once.  Are those 
> also supported already in CppTool and in your native class ?


Well, refactoring is only working at file level at the moment, so 
there's no interface yet defined to do modifications at project level where
several files need to be changed. So the interface described above, is 
the only thing is needed at the moment.

As you can see due the last postings, we are preparing the next step 
which is operating at file level.
Routines to parse and modify source at the level of a file have been 
created during the last weeks.

until later,
André

Re: [Cpptool-develop] Status...

[Devrim E. <de...@ma...>]

Andre Baresel wrote:

> Devrim Erdem wrote:
>
>> I have been a member of the mailing list for some time now,but I 
>> shall confess I haven't been reading all the mails posted.
>>
>> I use Jedit for C++ development on Linux. As far as I know cpptool 
>> has a plugin for Eclipse. I am not well informed about how it can be 
>> interfaced to other editor, e.g. jedit but I would like to hear and 
>> learn about it.
>>
>> Jedit being a java based editor, it supports python for plugins. 
>> Therefore it is possible to write a python script and run it in Jedit.
>>
>> I would be interested in learning how it can be possible to integrate 
>> CppTool to Jedit via python interface. Or is there any other way of 
>> doing it ?
>>
>>>
>>>  I'm thinking of using python to implement the code analysis and 
>>> refactoring layer of the code. This would hopefully help us going 
>>> faster. What do you think ?
>>>    
>>
>> I am not familiar with internals of CppTool but this kind of  layer I 
>> have for my own projects and they significantly speed up development.
>>
> Hello Devrim,
>
> I'm the author of the eclipse plugin. The way I've implemented this 
> was very similar to the Visual-Studio-Plugin. I've written a native 
> class which
> simply maps the access/modify routines of a text document of our 
> CppTool into access/modify routines of the java-class responsible for 
> the editor
> of eclipse. This was very simple since only very basic operations need 
> to be written.
> - get selection text
> - set selection area
> - set selection text
> such things are very common for an editor. So if you find such an 
> interface in phyton it would be possible to integrate. 

Sure there exists such functionality in Jedit's python interface.

But i have a question. I understand that there are refactoring 
operations which will need to modify several files at once.  Are those 
also supported already in CppTool and in your native class ?

>
>
> To check the other plugins look at
>    EclipseDocumentHelper.cpp/h            (this is the interface 
> between CppTool and Eclipse-Editor)
>    VCLinebasedTextDocument.cpp/h     (this is the interface between 
> CppTool and VisualStudio-Editor)
>
> nice to meet you,
> André Baresel
>
> The summer is starting in berlin,
> GREAT ! 

Also in Rosenheim, Bayern !

Re: [Cpptool-develop] Status...

[Andre B. <and...@gm...>]

Devrim Erdem wrote:

> I have been a member of the mailing list for some time now,but I shall 
> confess I haven't been reading all the mails posted.
>
> I use Jedit for C++ development on Linux. As far as I know cpptool has 
> a plugin for Eclipse. I am not well informed about how it can be 
> interfaced to other editor, e.g. jedit but I would like to hear and 
> learn about it.
>
> Jedit being a java based editor, it supports python for plugins. 
> Therefore it is possible to write a python script and run it in Jedit.
>
> I would be interested in learning how it can be possible to integrate 
> CppTool to Jedit via python interface. Or is there any other way of 
> doing it ?
>
>>
>>  I'm thinking of using python to implement the code analysis and 
>> refactoring layer of the code. This would hopefully help us going 
>> faster. What do you think ?
>>
> I am not familiar with internals of CppTool but this kind of  layer I 
> have for my own projects and they significantly speed up development.
>
Hello Devrim,

I'm the author of the eclipse plugin. The way I've implemented this was 
very similar to the Visual-Studio-Plugin. I've written a native class which
simply maps the access/modify routines of a text document of our CppTool 
into access/modify routines of the java-class responsible for the editor
of eclipse. This was very simple since only very basic operations need 
to be written.
- get selection text
- set selection area
- set selection text
such things are very common for an editor. So if you find such an 
interface in phyton it would be possible to integrate.

To check the other plugins look at
    EclipseDocumentHelper.cpp/h            (this is the interface 
between CppTool and Eclipse-Editor)
    VCLinebasedTextDocument.cpp/h     (this is the interface between 
CppTool and VisualStudio-Editor)

nice to meet you,
André Baresel

The summer is starting in berlin,
GREAT !

[Cpptool-develop] Progress on FullParser...

[Andre B. <and...@gm...>]

Hello together,

i started the work on writing parser classes for a full parser.
I got a lot of things working allready, so the main things discussed
at the wiki pages have been done. Of course this is only the first
step since mutators to step in the different declarations have not
been written yet. Most of the things are unparsed, but with this
we can parse files from top level. As soon as I managed to
refactor the code a little bit more I will check in the first files
and the tests which are allready working.
This direct testing is really nice ;-)

until later,
André

Re: [Cpptool-develop] Status...

[Devrim E. <de...@ma...>]

Baptiste Lepilleur wrote:

>  I'll be on holidays until April 22. 
>
>  Progress on the CodeModel are going well. I'm currently working on the 
>declaration expression (declaration of variables). Some case still need to be 
>tested (and maybe implemented):
>  - modifying primary type
>  - modifying variable name
>  - modifying/adding a secondary type prefix
>  - modifying/adding a type suffix
>  - modifying/adding a variable initializer (assignment or constructor)
>
>  You're welcome to try your hand at it.
>
>  Once it is done, the code model for expression will need to be extended to 
>include datas required for refactoring (ids, and symbol for inline temp).
>
>  The aim is to provide a high-level layer for source code manipulation, so 
>refactoring are implemented without 'touching' the text directly.
>
>  Also, last week-end I've played a bit with Boost.Python, a library for 
>binding C++ to python objects. Results are fairly impressive (take very little 
>time to map a class once you figured out how to do it).
>
Hi,

I have been a member of the mailing list for some time now,but I shall 
confess I haven't been reading all the mails posted.

I use Jedit for C++ development on Linux. As far as I know cpptool has a 
plugin for Eclipse. I am not well informed about how it can be 
interfaced to other editor, e.g. jedit but I would like to hear and 
learn about it.

Jedit being a java based editor, it supports python for plugins. 
Therefore it is possible to write a python script and run it in Jedit.

I would be interested in learning how it can be possible to integrate 
CppTool to Jedit via python interface. Or is there any other way of 
doing it ?

>
>  I'm thinking of using python to implement the code analysis and refactoring 
>layer of the code. This would hopefully help us going faster. What do you 
>think ?
>
I am not familiar with internals of CppTool but this kind of  layer I 
have for my own projects and they significantly speed up development.


>
>  Baptiste.
>
>---
>Baptiste Lepilleur <gai...@fr...>
>http://gaiacrtn.free.fr/index.html
>Language: English, French
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger 
>for complex code. Debugging C/C++ programs can leave you feeling lost and 
>disoriented. TotalView can help you find your way. Available on major UNIX 
>and Linux platforms. Try it free. www.etnus.com
>_______________________________________________
>Cpptool-develop mailing list
>Cpp...@li...
>https://lists.sourceforge.net/lists/listinfo/cpptool-develop
>
>
>  
>

[Cpptool-develop] Status...

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

  I'll be on holidays until April 22. 

  Progress on the CodeModel are going well. I'm currently working on the 
declaration expression (declaration of variables). Some case still need to be 
tested (and maybe implemented):
  - modifying primary type
  - modifying variable name
  - modifying/adding a secondary type prefix
  - modifying/adding a type suffix
  - modifying/adding a variable initializer (assignment or constructor)

  You're welcome to try your hand at it.

  Once it is done, the code model for expression will need to be extended to 
include datas required for refactoring (ids, and symbol for inline temp).

  The aim is to provide a high-level layer for source code manipulation, so 
refactoring are implemented without 'touching' the text directly.

  Also, last week-end I've played a bit with Boost.Python, a library for 
binding C++ to python objects. Results are fairly impressive (take very little 
time to map a class once you figured out how to do it).

  I'm thinking of using python to implement the code analysis and refactoring 
layer of the code. This would hopefully help us going faster. What do you 
think ?

  Baptiste.

---
Baptiste Lepilleur <gai...@fr...>
http://gaiacrtn.free.fr/index.html
Language: English, French

[Cpptool-develop] Modified variable declaration generated by the parser

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

    I modified the range of variable-decl-expression (n child of
declaration-expression) as follow:

    Type {1a}name1,  {1b}* name2[]{2b};

1a-1b indicates the range of the first variable declaration. It now starts
at the name instead of at beginning of the expression, and it ends after the
',' separator and its whitespace (which may includes a comment associated to
the variable).
1b-2b indicates the range of the second variable declaration.

    InlineTemp has already been impacted.

    Baptiste.

[Cpptool-develop] Upgraded to Boost 1.30

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

    The current CVS as been upgraded to use boost 1.30. Better
smart-pointer, official Boost.FileSystem.

    Installation steps have not changed.

    Baptiste.

Re: [Cpptool-develop] Bug1 located -- it's not IdentifierResolver...

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

----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Saturday, April 05, 2003 10:52 AM
Subject: [Cpptool-develop] Bug1 located -- it's not IdentifierResolver...


> Hello,
>
> I was debugging the problem which has been reported by Baptiste,
> luckily the problem is not located in the identifier resolver.
> The Problem lies within the refactoring routines.
> the code searches for the surrounding Compound Statement of the
> currently selected temporary variable and parses only this source code
area:
>
> int x;
> {                    // parsing from here
>    y = x;              // <-- select this "x" for refactoring
> }                    // parsing ends here
>
> If you select the inner variable 'x' the refactoring will report
> 'x' is not a local variable because it does not parse the declaration.

Great finding!

> I'll check how to get arround this. Currently I have in mind to
> implement an iterative procedure which first parses the inner compound
> and than takes more code if the declaration was not found.
> However with this we can run into a problem if we get out side the
> function which is analysed. Parsing will than fail.

I don't see another way around for now. The failure to parse would translate
into a error like "local variable not declared or parsing error..."

Baptiste.

>
> until later,
> andré

[Cpptool-develop] Bug1 located -- it's not IdentifierResolver...

[Andre B. <and...@gm...>]

Hello,

I was debugging the problem which has been reported by Baptiste,
luckily the problem is not located in the identifier resolver.
The Problem lies within the refactoring routines.
the code searches for the surrounding Compound Statement of the
currently selected temporary variable and parses only this source code area:

int x;
{                    // parsing from here
   y = x;              // <-- select this "x" for refactoring
}                    // parsing ends here

If you select the inner variable 'x' the refactoring will report
'x' is not a local variable because it does not parse the declaration.

I'll check how to get arround this. Currently I have in mind to
implement an iterative procedure which first parses the inner compound
and than takes more code if the declaration was not found.
However with this we can run into a problem if we get out side the
function which is analysed. Parsing will than fail.

until later,
andré

[Cpptool-develop] CodeModel...

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

As you may have seen if you are subscribed to the cvs mailing list, I've
been working on the CodeModel. It is progressing well, and most of the
statement types have been dealt with.

Give a look to CodeWritterTest and CodeWritterInsertTest to understand how
it is used.

Implementation:
The rewritter switches between two modes when visiting the code model:
- inserting (when 'inserting' some new code)
- updating (when visiting an element that have not moved)

Change made to the model are captured by the Element. There is two different
kinds of change tracking:
- mandatory element: unmodified/replaced (for example, a while statement
condition must always be present)
- optional element: unmodified/added/removed/replaced (for example, the
value associated to a return statement).

The rewritter combines the change type and the current mode to decide how
the source code should be updated.

There is still much to do, but there is enough to know that it is a working
solution.

To do:
- ForStatement (need to change the declaration node from statement type to
expression type first)
- expressions handling
- code style (the indent manager is definitely not what it should be, and
should probably have more responsabilities, such as
CodeWritter::beginNewStatement).

Feedbacks are more than welcome,
Baptiste.

Re: [Cpptool-develop] Encountered a problem with Windows-DLL concept of the parser.

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

This should work correctly if all applications are using the same run-time
library (in C++/Code Generation) dll. If that was not the case, neither the
vc6 plug-in nor cppunit would work and creating MFC extension DLL would be
impossible.

Using pointer across DLL is fine as long as they have the same memory model.
For example, even if no pointer was passed, a exception can not cross DLL
boundary if the application is 'release' and the dll 'debug' because they do
not have the same stack structure.

Linking the libraries directly directly in the plug-in code would work, and
it might be easier for deployment (just one dll to copy). On the other hand,
dll are faster to test (no extra link step).

Baptiste.

----- Original Message -----
From: "Andre Baresel" <and...@gm...>
To: "CppTool Mailing List" <Cpp...@li...>
Sent: Saturday, February 15, 2003 1:49 PM
Subject: [Cpptool-develop] Encountered a problem with Windows-DLL concept of
the parser.


> I'm currently debugging the eclipse plugin and found out a problem with
> the DLL usage of the parser. I'm instanciating the
> 'RenameLocalVariableClass'
> and calling 'getOldVariableName'. This passes a String from the DLL to
> the PluginDLL.
> Both DLLs are using different Heaps ofcourse, and for this reason the
> destructor
> of the passed string does not point to the Local-Heap of the PluginDLL
> and the
> DebugAssertions do report an error. The Plugin runs fine, but the
> passing of  a pointer
> across DLL borders is not correct, isn't it ? Does the same thing happen
> to VC6addin ?
>
> I'm currently thinking about linking the RFTA & RFTA_PARSER Library
> directly to
> the PluginCode.
>
> Any suggestions will help...
>
> -- Andre