here's my attempt to get this thing going again. In the meantime I had a discussion with B. Lepilleur, one of the developers of CppUnit. He has some nice ideas on lazy parsing, but maybe he can discuss them himself. He also might suggest a version of CppUnit to use; I still think we should all use the same :)
My suggestion is to start working on the internals of the Refactoring tool, w/o GUI. In practice, this means having a text based program for each refactoring (or one program taking the refactoring to be performed as a parameter), taking as parameter a) any additional information needed by the program and b) a file containing the filenames in the project.
In the beginning, we can write the result to a separate directory.
So, something like
refactor -prj myproject.prj -rename-local -file class1.cpp
-line 25 -oldname x -newname prime -o newversion/
where myproject.prj looks like
class1.h
class1.cpp
class2.h
class2.cpp
I would suggest a yagni approach for the internal representation of the source code; Baptiste's work indicates that a pure textual representation works at least for most cases of "Rename Local Variable".
Maybe we can start with a "null refactoring", just to get the logistics worked out.
Any comments?
Sven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am happy that someone is restarting work on this project. I agree with your approach - specifically with regards to the "null" refactor. Some time back I was looking at source navigator - and we can pickup some ideas from there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just to give you a quick update on what is happening:
I had a longer discussion with Baptiste Lepilleur, who is developing a lazy parser with the idea of building a refactoring tool. The code looks quite nice; I got it to run under Linux, however the makefiles still need a bit of work. I suggested him to join efforts. Let's see what happens.
Independently, I think we need to develop the following classes to get started:
class File (represents a source file)
class Project (container of files)
class NullRefactoring (to become a subclass of Refactoring, acts on Project)
and some main program as described earlier.
That's it for tonight.
Sven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Viktor asked me via email what we have so far. The answer is: nothing :(
I'm currently implementing the infrastructure mentioned above. I'll upload it once it's kind of done. I need some help to make it run under Windows, too (issues of CRLF and (back)slashes in paths, Makefiles/.dsp).
I assume everybody has access to the latest version of CppUnit.
Quick survey: which OS and compiler are you using? (Linux and g++ here)
Have a good weekend,
Sven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe reading the file in text mode should take care of the end-of-line issue. Also, to make our live easier, all EOL are converted to a single '\n' when working internally on documents.
Baptiste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The boost-sandbox is where project live before they are integrated in the library. Boost.Filesystem is not included in boost 1.29.0
The main reason QT is not popular on Windows is that the only available version for open-source dev is QT 2.3 non commercial version. The license is very restrictive: you can not even change a label in a dialog at work. Also, it seems to be a dead-end: 3.0 has never been released in a non-commercial version license. This really suck, because from my point of view, QT would be an excellent solution for crossplatorm open-source project.
Windows' developers who got the chance to work with both MFC and QT do agree that QT is way easier to use. But it come with a price :-(
Concerning the filesystem API, Boost.Filesystem aims to be integrated in the next C++ standard. As such, it is not restricted to unix/windows path 'model'.
Baptiste.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Folks,
here's my attempt to get this thing going again. In the meantime I had a discussion with B. Lepilleur, one of the developers of CppUnit. He has some nice ideas on lazy parsing, but maybe he can discuss them himself. He also might suggest a version of CppUnit to use; I still think we should all use the same :)
My suggestion is to start working on the internals of the Refactoring tool, w/o GUI. In practice, this means having a text based program for each refactoring (or one program taking the refactoring to be performed as a parameter), taking as parameter a) any additional information needed by the program and b) a file containing the filenames in the project.
In the beginning, we can write the result to a separate directory.
So, something like
refactor -prj myproject.prj -rename-local -file class1.cpp
-line 25 -oldname x -newname prime -o newversion/
where myproject.prj looks like
class1.h
class1.cpp
class2.h
class2.cpp
I would suggest a yagni approach for the internal representation of the source code; Baptiste's work indicates that a pure textual representation works at least for most cases of "Rename Local Variable".
Maybe we can start with a "null refactoring", just to get the logistics worked out.
Any comments?
Sven.
I am happy that someone is restarting work on this project. I agree with your approach - specifically with regards to the "null" refactor. Some time back I was looking at source navigator - and we can pickup some ideas from there.
Just to give you a quick update on what is happening:
I had a longer discussion with Baptiste Lepilleur, who is developing a lazy parser with the idea of building a refactoring tool. The code looks quite nice; I got it to run under Linux, however the makefiles still need a bit of work. I suggested him to join efforts. Let's see what happens.
Independently, I think we need to develop the following classes to get started:
class File (represents a source file)
class Project (container of files)
class NullRefactoring (to become a subclass of Refactoring, acts on Project)
and some main program as described earlier.
That's it for tonight.
Sven.
Viktor asked me via email what we have so far. The answer is: nothing :(
I'm currently implementing the infrastructure mentioned above. I'll upload it once it's kind of done. I need some help to make it run under Windows, too (issues of CRLF and (back)slashes in paths, Makefiles/.dsp).
I assume everybody has access to the latest version of CppUnit.
Quick survey: which OS and compiler are you using? (Linux and g++ here)
Have a good weekend,
Sven.
Windows 2000 Pro, VC6 SP5.
Will probably upgrade to VS .NET sometime in the future.
Concerning file access, you should Boost.FileSystem which provides an OS indepent file access API. I think the lastest version lives in
http://sourceforge.net/projects/boost-sandbox.
I believe reading the file in text mode should take care of the end-of-line issue. Also, to make our live easier, all EOL are converted to a single '\n' when working internally on documents.
Baptiste.
I downloaded some version of Boost before (thought it was the latest release) but I didn't find anything on file systems yet. I'll keep trying.
Another tool kit providing this sort of OS independent access is QT, but I think it's not so popular in the Windows world.
Sven.
The boost-sandbox is where project live before they are integrated in the library. Boost.Filesystem is not included in boost 1.29.0
The main reason QT is not popular on Windows is that the only available version for open-source dev is QT 2.3 non commercial version. The license is very restrictive: you can not even change a label in a dialog at work. Also, it seems to be a dead-end: 3.0 has never been released in a non-commercial version license. This really suck, because from my point of view, QT would be an excellent solution for crossplatorm open-source project.
Windows' developers who got the chance to work with both MFC and QT do agree that QT is way easier to use. But it come with a price :-(
Concerning the filesystem API, Boost.Filesystem aims to be integrated in the next C++ standard. As such, it is not restricted to unix/windows path 'model'.
Baptiste.
OK, I downloaded the boost file system files (5 headers, hope that's all). I'll try to use them.
Sven.
Oops, apparently not. Do I really have to download all files individually?
Sven.
Never mind, I got it :)