Author Topic: Ceniza's CodeCompletion Project  (Read 21452 times)

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Ceniza's CodeCompletion Project
« on: February 07, 2009, 10:03:05 am »
I've been thinking that maybe, just maybe, I should publish the code of my preprocessor. Questions are: where should I upload it (CB's svn respository, code.google.com, just a zip file somewhere, ...), and, most importantly, is it really going to be used?

I doubt it's going to be used right away in its current state. Chances are some modifications will be needed and some extra information saved during the process. Perhaps some more optimizations may be required, but it would be, at least, a starting point.

What's a real shame is that the document that explains its development is written only in Spanish. Well, you can always learn a new language, so it shouldn't be a problem either :wink:

Offline JGM

  • Lives here!
  • ****
  • Posts: 518
  • Got to practice :)
Ceniza's CodeCompletion Project
« Reply #1 on: February 07, 2009, 06:55:41 pm »
What's a real shame is that the document that explains its development is written only in Spanish. Well, you can always learn a new language, so it shouldn't be a problem either :wink:

Well people that doesnt know spanish use google translate :D

Offline joubertdj

  • Multiple posting newcomer
  • *
  • Posts: 120
Ceniza's CodeCompletion Project
« Reply #2 on: February 09, 2009, 07:39:40 am »
I've been thinking that maybe, just maybe, I should publish the code of my preprocessor. Questions are: where should I upload it (CB's svn respository, code.google.com, just a zip file somewhere, ...), and, most importantly, is it really going to be used?

I doubt it's going to be used right away in its current state. Chances are some modifications will be needed and some extra information saved during the process. Perhaps some more optimizations may be required, but it would be, at least, a starting point.

What's a real shame is that the document that explains its development is written only in Spanish. Well, you can always learn a new language, so it shouldn't be a problem either :wink:

We need to start somewhere ... this is basically the only thing I currently want in C::B ... if you could post the code here, maybe we could all have a look? Hell if it does Allegro, correctly then I am satisfied it will work with everything!

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5395
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Ceniza's CodeCompletion Project
« Reply #3 on: February 09, 2009, 01:44:38 pm »
I'm also interested in improving the Code Completion. Especially, pre-process is necessary.
For example:
Now, these code can't be recognized as a function declaration.
Code
CVAPI(void*)  cvAlloc( size_t size );
 
because CVAPI is a macro defined by
Code
  #ifndef CVAPI
    #define CVAPI(rettype) CV_EXTERN_C CV_EXPORTS rettype CV_CDECL
  #endif
Also, there are macros nested.

So, I think pre-process is complicated.
But why not we borrow code from a general c compiler source code? :D
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Ceniza's CodeCompletion Project
« Reply #4 on: February 10, 2009, 07:53:31 pm »
With the information you provided, my preprocessor outputs:

Quote
CV_EXTERN_C CV_EXPORTS void * CV_CDECL cvAlloc ( size_t size ) ;

I'll have to check the source code first, and try to isolate a few things. Maybe for this weekend I'll be doing that. I also need to find where I put the test for the optimized string type, and put that code along with it. The doxygen generated documentation may be worth uploading too, and the Spanish document for those who can read it.

Let's hope I don't forget...

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5395
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Ceniza's CodeCompletion Project
« Reply #5 on: February 11, 2009, 02:56:11 pm »
Great work!
Thank you! I'm looking forward to see the new update.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Ceniza's CodeCompletion Project
« Reply #6 on: February 15, 2009, 10:05:19 am »
I have started to upload files already. Right now I have only uploaded all documentation files (or the like) I found. I hope to have the source code ready this afternoon (UTC+1), which will be uploaded to the same place.

URL: http://sites.google.com/site/ceniza666/ccpp

[edit]
It looks like it was organized enough to upload it like that :D
[/edit]
« Last Edit: February 15, 2009, 10:41:06 am by Ceniza »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5395
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Ceniza's CodeCompletion Project
« Reply #7 on: February 15, 2009, 10:14:33 am »
I have started to upload files already. Right now I have only uploaded all documentation files (or the like) I found. I hope to have the source code ready this afternoon (UTC+1), which will be uploaded to the same place.

URL: http://sites.google.com/site/ceniza666/ccpp
Great! I'm happily reading the CCP document. It's a new string type. Hopefully I can do some help to improve the plugin.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5395
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Ceniza's CodeCompletion Project
« Reply #8 on: February 15, 2009, 01:07:01 pm »
I download the "CCPP.zip" from your site, then open the "CCP.cbp" with codeblocks svn5456 in windows xp.
I can successfully build the project named "Test + Lib -debug" shown  in "build target" toolbar. :D

When I want to run the "CCPP\bin\Debug\test.exe", by default it's argument is "../../tests/pptest05.cpp"
It complained that it can't find "iostream". So, I manually add the below code to main.cpp.
Code
fsp.addLocalSearchPath(defaultStringType("D:/MinGW/lib/gcc/mingw32/4.3.2/include/c++"));

But it still complained
Quote
D:/MinGW/lib/gcc/mingw32/4.3.2/include/c++/iostream:44: 'bits/c++config.h' not f
ound
Process returned 1 (0x1)   execution time : 0.015 s
Press any key to continue.

So, I add another search path
Code
fsp.addLocalSearchPath(defaultStringType("D:/MinGW/lib/gcc/mingw32/4.3.2/include/c++/bits"));

But it still can't open the "c++config.h".

There is the code in iostream , showing that it use a relative path to include "c++config.h" .
Code
...
#ifndef _GLIBCXX_IOSTREAM
#define _GLIBCXX_IOSTREAM 1

#pragma GCC system_header

#include <bits/c++config.h>
#include <ostream>
#include <istream>
...

So, I suspect that your code has bugs to search a relative path. Thanks.



If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5395
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Ceniza's CodeCompletion Project
« Reply #9 on: February 15, 2009, 01:28:00 pm »
Addition.
I modify the pptest05.cpp to check it can preprocess correctly.

Code
#include<cv.h>
#include<cxcore.h>
#include<highgui.h>
using namespace std;
int main() {
    double a[5][5]={
        0,4,6,9,0,
        -5,2,0,1,2,
        -2,0,1,6,7,
        -6,1,1,1,1,
        -1,2,3,0,4
    };
    CvMat ma=cvMat(5,5,CV_64FC1,a);
    CvMat* m=cvCreateMat(5,5,CV_64FC1);
    m=cvCloneMat(&ma);
    CvMat *mb=cvCreateMat(5,5,CV_8UC1);
    cvCmpS(m,0,mb,CV_CMP_LT );
    return 0;
}

and add those search path to main.cpp

Code
    fsp.addLocalSearchPath(defaultStringType("D:/MinGW/lib/gcc/mingw32/4.3.2/include/c++"));
    fsp.addLocalSearchPath(defaultStringType("D:/MinGW/lib/gcc/mingw32/4.3.2/include/c++/bits"));
    fsp.addLocalSearchPath(defaultStringType("F:/opencv/include/opencv"));
    fsp.addLocalSearchPath(defaultStringType("D:/MinGW/include"));
    fsp.addLocalSearchPath(defaultStringType("D:/MinGW/lib/gcc/mingw32/4.3.2/include"));

Then, it reported
Quote
src/test/../../tests/pptest05.cpp:19: #endif expected

Process returned 1 (0x1)   execution time : 0.359 s
Press any key to continue.


But I don't think I'm missing #endif in the last line of my test code.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Ceniza's CodeCompletion Project
« Reply #10 on: February 15, 2009, 06:32:26 pm »
After setting all include dirs and defines from the GCC version I'm using in Linux, pptest05.cpp was preprocessed successfully. However, your test file gives me another problem here: /usr/include/bits/endian.h:4: #error "Never use <bits/endian.h> directly; include <endian.h> instead."

Too bad I don't have enough time to check into it :(

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5395
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Ceniza's CodeCompletion Project
« Reply #11 on: February 16, 2009, 04:52:18 am »
Some suggestions:

Why not using " GCC -E" command to generate a "preprocessed file". After that, we can use our parser to read the output file.

See the example here:
http://www.network-theory.co.uk/docs/gccintro/gccintro_36.html

In my environment, I can use this command
 gcc -E test.c -o test.i

Then we could take the parser on "test.i".

The "test.i" has very strict syntax like below:

# linenum filename flags

see the document here:

http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/cpp/Preprocessor-Output.html


If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5395
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Ceniza's CodeCompletion Project
« Reply #12 on: February 16, 2009, 02:28:17 pm »
Quote
include <endian.h> instead
But I don't want to change the standard header file supplied by mingw. endian.h was include in <iostream> :D.

Your code contains too many templates. It's a bit hard for me to read :D.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7254
Re: Ceniza's CodeCompletion Project
« Reply #13 on: February 16, 2009, 02:49:58 pm »
I just split this topic, because we went away from Ultimate++.
I did not find a better name, so you have to live with it, or suggest a better one  :roll: .

Offline Ceniza

  • Developer
  • Lives here!
  • *****
  • Posts: 1441
    • CenizaSOFT
Re: Ceniza's CodeCompletion Project
« Reply #14 on: February 16, 2009, 07:09:54 pm »
Quote
include <endian.h> instead
But I don't want to change the standard header file supplied by mingw. endian.h was include in <iostream> :D.

Your code contains too many templates. It's a bit hard for me to read :D.

The error message is reported because a name is not defined. It's a shame I did not consider to include some sort of tracking in the code for debugging purposes. That could be a next step. It could report, for example, include files in a "tree" view (something that lets you know what included what and where and the level of depth), when a define is added, when removed, when an #if/#ifdef/#ifndef is checked and satisfied, when it's ignored, and so on. I must admit that I was in a rush to finish that project, and now I lack the time to work on it again. Just to make it more evil and template abusive, the tracker could become another template parameter, with a no-op tracker as default.

I am really aware I abused templates and macros. Also, just like with any other project, I like to improvise and try to come up with different ways to do things. Since the project was originally conceived as a C++ parser, I also tried to make the project a test case. When I realized it would take way too long to make the parser, I reduced the project just to the preprocessor. I fixed many bugs on the way, but it looks like there are still some in there. Too bad the document that gives more insight on the project is in Spanish. Still, I tried to make the Doxygen documentation as complete as possible.

@Jens: Names are my strongest weakness. You can leave the topic name like that. Also, it was a good idea to split it.