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

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Intergrate the nativeparser_base to our parsertest project
« on: July 07, 2012, 03:37:02 am »
When review our CC code, I see that the core type matching code is:
Code
    // find all other matches
    std::queue<ParserComponent> components;
    BreakUpComponents(actual_search, components);

    m_LastAISearchWasGlobal = components.size() <= 1;
    if (!components.empty())
        m_LastAIGlobalSearch = components.front().component;

    ResolveExpression(tree, components, *search_scope, result, caseSensitive, isPrefix);

    if (s_DebugSmartSense)
        CCLogger::Get()->DebugLog(F(_T("AI() AI leave, returned %d results"),result.size()));

    return result.size();
The components is the statement when user write.
The ResolveExpression is in Nativeparser_base now. So, I think we can safely add the nativeparser_base to our parsertest project.

I see that the class Nativeparser_base is quite nice for testing. It does not contains UI related code. (simply remove #include <cbstyledtextctrl.h> in the cpp file)

I'm going to write the test for the ResolveExpression.(mostly after the parsing stage)

E.g.

Code
class A
{
public:
int m_Member1;
int m_Member2;
};

class B:public A
{
};

B obj;


Now, we have a expression "obj.m_Member1".
The initial search scope is the -1 (the global namespace)

Running the function: ResolveExpression should return the one exact matches, which is the Token "m_Member1".
So, this is only the start point, later we can test more complex expressions or more classes in the hierarchy or template related code.

I'm starting the work on my local git repos. :) I will report any progress here in this thread.
« Last Edit: July 07, 2012, 03:45:58 am by ollydbg »
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 #1 on: July 07, 2012, 04:33:00 am »
Ok, it works nice.

Copy nativeparser_base.h and nativeparser_base.cpp to the parser folder.

I have add some code snippet in frame.cpp
Code
    //Here we are going to test the expression solving algorithm

    NativeParserTest nativeParserTest;

    wxString exp = _T("obj.m_Member1");

    TokenIdxSet searchScope;
    searchScope.insert(-1);

    TokenIdxSet result;

    TokensTree *tree = ParserTest::Get()->GetTokensTree();

    nativeParserTest.TestExpression(exp,
                                    tree,
                                    searchScope,
                                    result );

    wxLogMessage(_T("Result have %d matches"), result.size());


    for (TokenIdxSet::iterator it=result.begin(); it!=result.end(); ++it)
    {
        Token* token = tree->at(*it);
        if (token)
        {
            wxString log;
            log << token->GetTokenKindString() << _T(" ")
                << token->DisplayName()        << _T("\t[")
                << token->m_Line               << _T(",")
                << token->m_ImplLine           << _T("]");
            CCLogger::Get()->Log(log);
        }
    }

And here is the class declaration and implementation:
Code
#ifndef NATIVEPARSERTEST_H
#define NATIVEPARSERTEST_H

#include "nativeparser_base.h"

class NativeParserTest : public NativeParserBase
{
public:
    NativeParserTest();
    ~NativeParserTest();
    bool TestExpression(wxString& expression,
                        TokensTree * tree,
                        const TokenIdxSet& searchScope,
                        TokenIdxSet&   result);
};

#endif //NATIVEPARSERTEST_H


Code
#include <sdk.h>

#ifndef CB_PRECOMP
#endif

#include "nativeparsertest.h"

#include "parser/cclogger.h"



#define CC_NATIVEPARSERTEST_DEBUG_OUTPUT 0

#if CC_GLOBAL_DEBUG_OUTPUT == 1
    #undef CC_NATIVEPARSERTEST_DEBUG_OUTPUT
    #define CC_NATIVEPARSERTEST_DEBUG_OUTPUT 1
#elif CC_GLOBAL_DEBUG_OUTPUT == 2
    #undef CC_NATIVEPARSERTEST_DEBUG_OUTPUT
    #define CC_NATIVEPARSERTEST_DEBUG_OUTPUT 2
#endif

#ifdef CC_PARSER_TEST
//    #define ADDTOKEN(format, args...) \
//            CCLogger::Get()->AddToken(F(format, ##args))
//    #define TRACE(format, args...) \
//            CCLogger::Get()->DebugLog(F(format, ##args))
//    #define TRACE2(format, args...) \
//            CCLogger::Get()->DebugLog(F(format, ##args))

    #define ADDTOKEN(format, args...) \
            wxLogMessage(F(format, ##args))
    #define TRACE(format, args...) \
            wxLogMessage(F(format, ##args))
    #define TRACE2(format, args...) \
            wxLogMessage(F(format, ##args))
#else
    #if CC_NATIVEPARSERTEST_DEBUG_OUTPUT == 1
        #define ADDTOKEN(format, args...) \
                CCLogger::Get()->AddToken(F(format, ##args))
        #define TRACE(format, args...) \
            CCLogger::Get()->DebugLog(F(format, ##args))
        #define TRACE2(format, args...)
    #elif CC_NATIVEPARSERTEST_DEBUG_OUTPUT == 2
        #define ADDTOKEN(format, args...) \
                CCLogger::Get()->AddToken(F(format, ##args))
        #define TRACE(format, args...)                                              \
            do                                                                      \
            {                                                                       \
                if (g_EnableDebugTrace)                                             \
                    CCLogger::Get()->DebugLog(F(format, ##args));                   \
            }                                                                       \
            while (false)
        #define TRACE2(format, args...) \
            CCLogger::Get()->DebugLog(F(format, ##args))
    #else
        #define ADDTOKEN(format, args...)
        #define TRACE(format, args...)
        #define TRACE2(format, args...)
    #endif
#endif


extern bool s_DebugSmartSense;

NativeParserTest::NativeParserTest( )
{

}
NativeParserTest::~NativeParserTest()
{

}
bool NativeParserTest::TestExpression(wxString& expression,
                                      TokensTree * tree,
                                      const TokenIdxSet& searchScope,
                                      TokenIdxSet&   result)
{
    // find all other matches
    std::queue<ParserComponent> components;
    BreakUpComponents(expression, components);

    ResolveExpression(tree, components, searchScope, result, true, false);

    if (s_DebugSmartSense)
        CCLogger::Get()->DebugLog(F(_T("NativeParserTest::TestExpression , returned %d results"),result.size()));

    return true;
}

The test code is in my previous post, and I can see the final result:
Quote
...
000033. NativeParserTest::TestExpression , returned 1 results
000034. variable int A::m_Member1   [5,0]
...
:) :) :)

EDIT:
I add the diff file, so it is test only patch.(Note, the diff file contains my other part of changes to CC, like adding some comments, re-direct the TRACE message to standard console, so I can still see these messages when the app hit a breakpoint.....)
The patch is generated by git, but I think using the patch command under msys, it can directly apply the change on a SVN trunk.
BTW: Maybe, some EOL should be changed after patching, because my git use Linux-style EOL.
« Last Edit: July 07, 2012, 04:59:23 am by ollydbg »
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 #2 on: July 07, 2012, 05:56:59 am »
The ResolveExpression is in Nativeparser_base now. So, I think we can safely add the nativeparser_base to our parsertest project.
[...]
I see that the class Nativeparser_base is quite nice for testing. It does not contains UI related code.
That was the overall goal of this re-factoring. ;-)

Ok, it works nice.
[...]
I add the diff file, so it is test only patch.
Good to know - I didn't have the time to test, but I believe there is even more we can transfer to the test project, if we include a cbStyledTextCtrl into it.
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 MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #3 on: July 07, 2012, 11:05:54 am »
The patch is generated by git, but I think using the patch command under msys, it can directly apply the change on a SVN trunk.
Nope, doesn't work here. So I cannot try. Maybe you can do a proper svn diff-based patch. Its easy: just transfer the changes to the svn controlled folder and do a svn diff > patch in the root folder of Code::Blocks's sources.
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: Intergrate the nativeparser_base to our parsertest project
« Reply #4 on: July 07, 2012, 03:22:03 pm »
I also use git for my local repo and creating svn compatible  patches needs just one more step: see http://abombss.com/blog/2007/12/10/creating-patches-for-subversion-from-git/, or use the attached python script (if it works on windows).
It's not created by me, I found it somewhere in the internet (do not recall where).

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #5 on: July 07, 2012, 03:27:22 pm »
I also use git for my local repo and creating svn compatible  patches needs just one more step: [...] or use the attached python script (if it works on windows).
Right... I'll try that but this becomes really annoying! I mean: Whats the point in pre-processing patches in a platform dependent way, if we can have proper patches done right using subversion? ::) ??? :-\
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: Intergrate the nativeparser_base to our parsertest project
« Reply #6 on: July 07, 2012, 03:40:59 pm »
I also use git for my local repo and creating svn compatible  patches needs just one more step: [...] or use the attached python script (if it works on windows).
Right... I'll try that but this becomes really annoying! I mean: Whats the point in pre-processing patches in a platform dependent way, if we can have proper patches done right using subversion? ::) ??? :-\
I use git for my local workspace, because it is more flexible, if I work with several patches, because I can easily create local branches.
And running one script after creating a patch to be applied on windows is not too much work for me.
On linux the git-created patches can be easily applied using the "patch" executable without any further processing.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #7 on: July 07, 2012, 03:52:41 pm »
At work I use git-svn-diff script, it generates proper windows svn patches, but as far as I know it doesn't work on windows...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #8 on: July 07, 2012, 03:53:13 pm »
I use git for my local workspace, because it is more flexible,
Surely one can use locally whatever (s)he thinks is right. My point is: I would like to see that even if people use GIT or whatever locally that we post patches here created by svn diff. This will cause no hassle on all platforms - it just works. Everything else is a nightmare... at least on Windows.

Besides: Even after installing (updating) Python and running the script, applying the modified patch still doesn't work and errors with my favourite error message "chunk info expected". So I give up on this.
« Last Edit: July 07, 2012, 03:54:45 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 #9 on: July 07, 2012, 05:12:19 pm »
The patch is generated by git, but I think using the patch command under msys, it can directly apply the change on a SVN trunk.
Nope, doesn't work here. So I cannot try. Maybe you can do a proper svn diff-based patch. Its easy: just transfer the changes to the svn controlled folder and do a svn diff > patch in the root folder of Code::Blocks's sources.

Here it is.

It was created from the plugins folder.

BTW: I can still use the command :
patch -p1 < aaa.patch
to apply the patch (generated in git )on svs local copy.
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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #10 on: July 07, 2012, 05:15:56 pm »
ollydbg:
What patch executable are you using?
All I've tried crashed badly when used with linux generated patches.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #11 on: July 07, 2012, 05:19:18 pm »
ollydbg:
What patch executable are you using?
All I've tried crashed badly when used with linux generated patches.
I use the patch command shipped with MSYS.
I always download the MSYS zip file from mingw64 site(some one has maintain a full msys environment which contains everything), see:MSYS-20111123.zip


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 #12 on: July 07, 2012, 05:44:32 pm »
Here it is.
Thanks, this works. BTW: I still need to modify it if you don't do the diff from the root of trunk. When you are using a subversion 1.7 working copy, applying a patch only works well from root and then the path's are not correct. However, I could handle this... :P

Just looking at the diff I realised you copied the nativeparser_base into the parser folder. I wouldn't do this. Already now they are out of sync. I think a better solution is to either move nativeparser_base into the "parser" sub-folder or move the project file of parsertest one level up.

Your changes conflict a little with the ones of my working copy, but I can handle. For the record, I have touched in parserthread:
- GetTokenBaseType
- HandleFunction
So once you are touching those, we should sync.
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 #13 on: July 08, 2012, 03:38:01 am »
Here it is.
Thanks, this works. BTW: I still need to modify it if you don't do the diff from the root of trunk. When you are using a subversion 1.7 working copy, applying a patch only works well from root and then the path's are not correct. However, I could handle this... :P
Sorry about this, but handling different patches is a problem for me(that's why I start using the git), because I have some other changes to the cb_trunk in my local copy, 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. :)


Quote
Just looking at the diff I realised you copied the nativeparser_base into the parser folder. I wouldn't do this. Already now they are out of sync. I think a better solution is to either move nativeparser_base into the "parser" sub-folder or move the project file of parsertest one level up.
I suggest move the nativeparer_base to the sub-folder, it is all related to c/c++ parser.

Quote
Your changes conflict a little with the ones of my working copy, but I can handle. For the record, I have touched in parserthread:
- GetTokenBaseType
- HandleFunction
So once you are touching those, we should sync.
All my changes were record in my git local clone, so I can safely pull the changes you made, and merge it.
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 #14 on: July 08, 2012, 05:15:50 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.

I suggest move the nativeparer_base to the sub-folder, it is all related to c/c++ parser.
Fine with me.

All my changes were record in my git local clone, so I can safely pull the changes you made, and merge it.
The are not "ready for production" yet. :-[
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 #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

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #30 on: July 12, 2012, 08:45:00 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...
I think CC just add all the files belong to the project, you can see below:
Code
void NativeParser::AddProjectToParser(cbProject* project)
{
....



    if (project)
    {
        size_t fileCount = 0;
        for (FilesList::iterator it = project->GetFilesList().begin(); it != project->GetFilesList().end(); ++it)
        {
            ProjectFile* pf = *it;
            if (pf && FileTypeOf(pf->relativeFilename) == ftHeader)
            {
                if (AddFileToParser(project, pf->file.GetFullPath(), parser))
                    ++fileCount;
            }
        }
        for (FilesList::iterator it = project->GetFilesList().begin(); it != project->GetFilesList().end(); ++it)
        {
            ProjectFile* pf = *it;
            if (pf && FileTypeOf(pf->relativeFilename) == ftSource)
            {
                if (AddFileToParser(project, pf->file.GetFullPath(), parser))
                    fileCount++;
            }
        }

        wxString log(F(_("Done adding %d files of project (%s) to parser."), fileCount, prj.wx_str()));
        CCLogger::Get()->DebugLog(log);
    }

...

BTW: I noticed that in our codeblocks.cbp, there are different targets which have the save class name "Token", CodeCompletion plugin target and debugger plugin target. Click on the "Token" and context menu select goto declaration will bring me to:
Code
plugins\debuggergdb\parsewatchvalue.cpp

This is pretty annoying...... :(
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 #31 on: July 13, 2012, 09:37:28 am »
I think CC just add all the files belong to the project, you can see below:
[...]
Hmmm... seems you are right. But if that is a good idea... I don't know. At least we should skip files not related to any target. This would avoid the freeze you are mentioning.

BTW: I've done the directory layout changes in trunk. I merged them from the xml_compiler branch which was actually an error. I meant these 4 commits to be applied in trunk had not switched back to trunk before the first commit. ::) :-[

However - we have the history.... although its in a branch. And as it doesn't do any functional change its OK I'd say...
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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #32 on: July 13, 2012, 10:41:21 am »
BTW: I've done the directory layout changes in trunk. I merged them from the xml_compiler branch which was actually an error. I meant these 4 commits to be applied in trunk had not switched back to trunk before the first commit.
Wow, you're using single working copy for all the branches? You're a brave man:)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Intergrate the nativeparser_base to our parsertest project
« Reply #33 on: July 13, 2012, 10:54:22 am »
Wow, you're using single working copy for all the branches? You're a brave man:)
You can switch only partially to a branch, like I did for the CC plugin. This is nice if the changes are related to a single directory, only. Unfortunately here, I forgot to switch this folder back to trunk before. After the first commit I realised that I had even clicked away the warning of the SVN software... maybe it was too early today. ::)
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