Author Topic: Intergrate the nativeparser_base to our parsertest project  (Read 56627 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #15 on: July 08, 2012, 06:14:46 am »
so it is a mess up when I need to select all the changed files in TortoiseSVN, and generate a diff file. For me, the simplest way is just select a folder like "codecompletion", and generate the diff file. :)
If you are using TortoiseSVN IMHO is should be possible even from trunk to only select the files in question. If not, I am using SmartSVN where you have a "flat view", meaning that the files are shown in a big list as if there were not directories from the root folder. Then you can select only the files you want to create a diff from. I am not sure if TortoiseSVN has a similar feature.
Yes, TortoiseSVN has this feature, but I'm a bit lazy because that there are too many changed files show in the listed in the root folder. ;)
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #16 on: July 08, 2012, 06:30:36 am »
Yes, TortoiseSVN has this feature, but I'm a bit lazy because that there are too many changed files show in the listed in the root folder. ;)
That's where "flat view" comes into play again: You can still sort by folder as a second sort criteria. Then you have it all aligned again and can easily select a certain sub-set of files.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Integrate the nativeparser_base to our parsertest project
« Reply #17 on: July 08, 2012, 10:07:31 am »
But with svn you run into trouble, if you work on the same file for different patches.
you can easily select single files, but not single changed lines with svn.
But you can use either different local branches wih git or pull single changed lines or hunks to be committed or to be removed from a commit.

But as alaways it's also a matter of taste, and it should be clear that patches we attach for testing purposes should be usable by svn, as this is the software we use for our vcs.
« Last Edit: July 08, 2012, 10:12:12 am by jens »

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Integrate the nativeparser_base to our parsertest project
« Reply #18 on: July 08, 2012, 11:42:58 am »
But with svn you run into trouble, if you work on the same file for different patches.
That is true. I have nothing against GIT itself. Just the combination we do here between SVN and GIT. If we all agree we should consider moving towards GIT completely if most of the devs use it anyways. I recall we were discussing this already, just not why we didn't do it (was it the lack of support from BerliOS?!).

I wonder if some of you already did a migration from SVN to GIT. I mean in terms of keep existing branches and (of course) the whole history...?!

I recall the time when I personally migrated from CVS to SVN. It wasn't easy, but doable if you had the right tools at hand.

BTW: We are getting OT... ;-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #19 on: July 08, 2012, 03:30:08 pm »
For the record:

This works Ok currently.
Code:
Code
class wxWindow
{
     int aaaaa;
};


// The template parameter W must be a wxWindow-derived class.
template <class W>
class wxNavigationEnabled
{
public:
    W m_T;
   
};
wxNavigationEnabled<wxWindow> ccccc;
Statement:
Code
ccccc.m_T.aaaaa;

To solve the problem stated here:Re: CodeCompletion wxWidgets, we need to solve below:
Code
class wxWindow
{
     int aaaaa;
};


// The template parameter W must be a wxWindow-derived class.
template <class W>
class wxNavigationEnabled : public W
{
public:
    typedef W BaseWindowClass;
};


class wxPanelBase : public wxNavigationEnabled<wxWindow>
{

};

wxPanelBase ccccc;

Statement:
Code
ccccc.aaaaa;

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: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #20 on: July 11, 2012, 05:16:16 am »

To solve the problem stated here:Re: CodeCompletion wxWidgets, we need to solve below:
Code
class wxWindow
{
     int aaaaa;
};


// The template parameter W must be a wxWindow-derived class.
template <class W>
class wxNavigationEnabled : public W
{
public:
    typedef W BaseWindowClass;
};


class wxPanelBase : public wxNavigationEnabled<wxWindow>
{

};

wxPanelBase ccccc;

Statement:
Code
ccccc.aaaaa;



I implement this a bit, it at least works in some simple cases. (only works on template with only one ancestor with is actually the formal template argument)

See the image shown when I try to find the declaration of the function: SetFocus(). In a wx2.9.x project.



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: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #21 on: July 11, 2012, 05:37:33 am »
@Morten:
I think that the parsertest project should make as simple as possible, so I'm planning to remove the "codeblocks.dll" dependency, also, I think cbStyleTextCtrl is not necessary. :)

My plan is:
One file for test parsing(test.h)
Code
class wxWindow
{
     int aaaaa;
};


// The template parameter W must be a wxWindow-derived class.
template <class W>
class wxNavigationEnabled : public W
{
public:
    typedef W BaseWindowClass;
};


class wxPanelBase : public wxNavigationEnabled<wxWindow>
{

};

wxPanelBase ccccc;
and one file for test resolving expression(test_expression.exp)
The expression file can contains something like:
Code
expression:
ccccc.aaaaa
expected result:
variable int wxWindow::aaaaa

The only issue is that it can only test expression from "global namespace". ;) But I think it was just enough good if we have many testing files. Introducing the class cbStyleTextCtrl was just trying to find the which function the cursor was located in.


 
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #22 on: July 11, 2012, 06:45:42 am »
also, I think cbStyleTextCtrl is not necessary. :)
But in that case we cannot test all functions related to NativeParser (CC in general), like the whole AI. I don't know if that's a good idea. My plan was in the direction to provide the parser test project with a simple (maybe hidden and/or abstract) cbStyledTextCtrl which allows to test the AI, too.
« Last Edit: July 11, 2012, 07:13:49 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #23 on: July 11, 2012, 11:02:08 am »
also, I think cbStyleTextCtrl is not necessary. :)
But in that case we cannot test all functions related to NativeParser (CC in general), like the whole AI. I don't know if that's a good idea. My plan was in the direction to provide the parser test project with a simple (maybe hidden and/or abstract) cbStyledTextCtrl which allows to test the AI, too.
I just give up on "removing the "codeblocks.dll" dependency", it was too complex and need a lot of code changes. :(
Maybe, you are right, we will use "cbStyledTextCtrl" some days later. :)

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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #24 on: July 11, 2012, 12:20:04 pm »
Maybe, you are right, we will use "cbStyledTextCtrl" some days later. :)
Probably... :-)

BTW: I am thinking of a directory structure as attached. It is an archive of the new/moved files without (!) the files that did not change. It incorporates all the work you had provided with cc_patch2. I renamed "parsertest" to "cc_test" and in the end we want to test CC, not only the parser. Have a look at the "tree.txt" file which shows the complete directory structure for reference. As I said: The files missing in the archive are the same as in SVN.

Would that be a good thing to do?

[attachment deleted by admin]
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #25 on: July 11, 2012, 02:58:15 pm »

BTW: I am thinking of a directory structure as attached. It is an archive of the new/moved files without (!) the files that did not change. It incorporates all the work you had provided with cc_patch2. I renamed "parsertest" to "cc_test" and in the end we want to test CC, not only the parser. Have a look at the "tree.txt" file which shows the complete directory structure for reference. As I said: The files missing in the archive are the same as in SVN.

Would that be a good thing to do?
Good! That's fine. Thanks.

BTW: I'm currently testing some new Token kind like "tkClassTemplate", "tkClassTemplate", and "tkClassTemplateSpecialization" which support some kind of better template handling, but there are still a lot of work to do.
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: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #26 on: July 11, 2012, 03:40:28 pm »
There is a question, I see test.h belong to cc_test.cbp
Code
		<Unit filename="cc_test\test.h">
<Option target="&lt;{~None~}&gt;" />
</Unit>
This may cause some issue. E.g. When you are testing a parser hang problem, you put some code snippet to test.h, then you open the cc_test.cbp in a C::B , as test.h belong to cbp, the parser in C::B will parse it, this will cause the host C::B hangs.

So, I think we should remove "test.h" from cc_test.cbp to avoid such hang issue.
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #27 on: July 11, 2012, 05:17:48 pm »
So, I think we should remove "test.h" from cc_test.cbp to avoid such hang issue.
It doesn't belong to a project nor a target though. Are you sure that it is being parsed therefore? I thought only files that belong to a project/target are being parsed...?!

EDIT: If you are happy with the layout I would do the same in trunk, but only the changed / moved files, not (yet) the new template stuff. Is that OK?
« Last Edit: July 11, 2012, 05:21:35 pm by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #28 on: July 12, 2012, 02:17:04 am »
So, I think we should remove "test.h" from cc_test.cbp to avoid such hang issue.
It doesn't belong to a project nor a target though. Are you sure that it is being parsed therefore? I thought only files that belong to a project/target are being parsed...?!
You may not understand my idea. For test.h which contain some code snippet will let the parser hang. I only want the cc_test.exe(parsertest.exe) to parse it, not the normal C::B. Because if a normal C::B hangs, I have no way to develop/debug the cc_test.exe.

Quote
EDIT: If you are happy with the layout I would do the same in trunk, but only the changed / moved files, not (yet) the new template stuff. Is that OK?
OK, please go ahead.
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #29 on: July 12, 2012, 07:34:50 am »
You may not understand my idea.
...maybe I need to rre-phrase. As you see:
Code
		<Unit filename="cc_test\test.h">
<Option target="&lt;{~None~}&gt;" />
</Unit>
...although the file is in the project, it belongs to a the special target "{~None~}" which means in no target it is checked. I was under the impression hat only those files are parsed, that belong to a real target (like "default") and this file only in case it is being opened (which you don't need to do). How does CC collect its list of files to parse precisely? I'll have a look...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ