Author Topic: The 11 February 2012 build (7789) is out.  (Read 81702 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 11 February 2012 build (7789) is out.
« Reply #30 on: March 21, 2012, 08:25:42 am »
Keep in mind that make uninstall is not the most reliable thing in the world. Nor the most easy to use thing in the world!
So it is advised to do one of two things:
1. use a prefix specific for codeblocks, like --prefix=/home/yourusers/software/codeblocks, by doing, so you have an easy uninstall procedure (just delete the directory).
2. make your own packages for your distro, c::b has build in support for debian(-based) and all the rpm based distros (some changes are needed here and there, but they are trivial).

BTW: Can you explain why are you changing something in configure.in and in Makefile.am (explained here: http://ssofroni1982.users.sourceforge.net/dokuwiki/codeblocks-svn-mint )? Why haven't you provided a patch, so we can integrate your changes? (this link is from the irc.freenode.net channel posted by the user _stefanos_ (I guess this is you)).

p.s. also it could be a good idea to use a separate build directory, our build system supports it pretty well (I've not tried it, but this is what people say:)).
(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!]

stefanos_

  • Guest
Re: The 11 February 2012 build (7789) is out.
« Reply #31 on: March 21, 2012, 11:31:46 am »
Keep in mind that make uninstall is not the most reliable thing in the world. Nor the most easy to use thing in the world!
So it is advised to do one of two things:
1. use a prefix specific for codeblocks, like --prefix=/home/yourusers/software/codeblocks, by doing,
so you have an easy uninstall procedure (just delete the directory).

2. make your own packages for your distro, c::b has build in support for debian(-based) and all the rpm
based distros (some changes are needed here and there, but they are trivial).

BTW: Can you explain why are you changing something in configure.in and in Makefile.am (explained here:
http://ssofroni1982.users.sourceforge.net/dokuwiki/codeblocks-svn-mint )? Why haven't you provided a patch,
so we can integrate your changes? (this link is from the irc.freenode.net channel posted by
the user _stefanos_ (I guess this is you)).

p.s. also it could be a good idea to use a separate build directory, our build system supports it
pretty well (I've not tried it, but this is what people say:)).

Yeah that's my website. Well, I had an issue from the start with many awkward messages about missing macros from
those two files and searched about it on the web. I have found bits and pieces as plausible fixes and assembled
them as one whole solution and managed to make it work; frankly I thought it was a minor bug that had to do
with my system, not with Code::Blocks. I thought it would, could, (should?) have got fixed by now; I didn't know that
still causes building problems so I could report my solution as an official patch for Code::Blocks.

As far as concern the build directory, I have tried it once and I found it irritating with all this switch between
build version and installed version, that is the one I have compiled myself, and the one that comes on Debian
by default. It was based on this irritation that I decided to compile everything myself, which is more or less
an old habit I would say; it helps me stay focus on one thing.

Right now I am at work and cannot really tell what is the cause of my issue. I think tomorrow I will be able to check it,
because today I have a seminar and I won't get home before 22:00, which I will be way too exhausted.

In case I find the time to check it, I will surely let you know.

stefanos_

  • Guest
Re: The 11 February 2012 build (7789) is out.
« Reply #32 on: March 22, 2012, 09:32:07 pm »
did you really clean your sozrce folder before building, especially remove the +.gch's in c::B's include ? They have moved to another place, but if old ones exist, they will probably be used by the compiler, what can lead to weird crashes.

A fresh svn-checkout is usually the easiest way to avoid such issues.

As far as I can see with make distclean, it removes .gch files but to be 100% I have added a find command on my script that searches the entire local repository for precompiled header files and delete them. I am anxiously waiting for it to finish and I will let you know after a few minutes.

Offline Paul_Wortmann

  • Single posting newcomer
  • *
  • Posts: 5
    • PhysHex Games
Re: The 11 February 2012 build (7789) is out.
« Reply #33 on: March 31, 2012, 08:16:30 am »
I think I may have found a small, insignificant bug...
If I highlight just the class name without the double colon "::" all instances of the class name are highlighted, but if I highlight the class name including the double colon, all instances excluding the destructor are highlighted.
It appears that a class name followed by two colons and then any other symbol other than a letter or a number has the same effect.



I am using the 11 February 2012 build (7789) on windows 7.
It also does the same on my Linux machine with build 7899.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 11 February 2012 build (7789) is out.
« Reply #34 on: March 31, 2012, 09:05:56 am »
I think I may have found a small, insignificant bug...
If I highlight just the class name without the double colon "::" all instances of the class name are highlighted, but if I highlight the class name including the double colon, all instances excluding the destructor are highlighted.
It appears that a class name followed by two colons and then any other symbol other than a letter or a number has the same effect.



I am using the 11 February 2012 build (7789) on windows 7.
It also does the same on my Linux machine with build 7899.

The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/ 

Thank you.
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 Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7252
Re: The 11 February 2012 build (7789) is out.
« Reply #35 on: March 31, 2012, 09:10:15 am »
The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/ 

That's not correct.
HighlightOccurrences() is implemented in cbeditor.cpp.
So please do not report it to scintilla mailinglist.

I look into it.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 11 February 2012 build (7789) is out.
« Reply #36 on: March 31, 2012, 09:15:04 am »
The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/ 

That's not correct.
HighlightOccurrences() is implemented in cbeditor.cpp.
So please do not report it to scintilla mailinglist.

I look into it.

Oh, You are correct, 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 Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7252
Re: The 11 February 2012 build (7789) is out.
« Reply #37 on: March 31, 2012, 09:16:48 am »
The hightlight occurrences feature is implemented in scintilla control, Code::blocks only use this control. So, can you report this bug here:http://www.scintilla.org/ 

That's not correct.
HighlightOccurrences() is implemented in cbeditor.cpp.
So please do not report it to scintilla mailinglist.

I look into it.

Works fine here.
Can you create a small file, where this occurs and send it me via mail ( my_nickname at codeblocks dot org ) , or attach it here ?

Offline Paul_Wortmann

  • Single posting newcomer
  • *
  • Posts: 5
    • PhysHex Games
Re: The 11 February 2012 build (7789) is out.
« Reply #38 on: March 31, 2012, 02:57:04 pm »
I included files as requested that exhibit this behavior.  "rs232.cpp"

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7252
Re: The 11 February 2012 build (7789) is out.
« Reply #39 on: March 31, 2012, 04:20:10 pm »
I included files as requested that exhibit this behavior.  "rs232.cpp"

It still works here with my default settings, but after checking "Whole words only" in "Settings -> Editor... -> General settings -> Highlight occurrences", I get the same behaviour as you.
My guess, is that scintilla treats the double-colon with the following tilde as one word.

So if you uncheck  "Whole words only", it should work

Offline Paul_Wortmann

  • Single posting newcomer
  • *
  • Posts: 5
    • PhysHex Games
Re: The 11 February 2012 build (7789) is out.
« Reply #40 on: March 31, 2012, 04:37:20 pm »
I included files as requested that exhibit this behavior.  "rs232.cpp"

It still works here with my default settings, but after checking "Whole words only" in "Settings -> Editor... -> General settings -> Highlight occurrences", I get the same behaviour as you.
My guess, is that scintilla treats the double-colon with the following tilde as one word.

So if you uncheck  "Whole words only", it should work

I adjusted the setting as you indicated and am now able to highlight the destructor too.
Thank you very much, Jens.  :)

Offline VinniPuh

  • Single posting newcomer
  • *
  • Posts: 2
Re: The 11 February 2012 build (7789) is out.
« Reply #41 on: April 03, 2012, 10:11:23 am »
Hi,
I compiled Code::Blocks (trunk, rev 7916, minGW32) with -Wextra and saw some warnings what is similar to a bug:

Code
D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:348:36: warning: comparison of unsigned expression < 0 is always false
D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:381:54: warning: comparison of unsigned expression >= 0 is always true
D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenizer.cpp:273:53: warning: comparison of unsigned expression >= 0 is always true
D:\WORK\cb\trunk\src\plugins\scriptedwizard\wizpage.cpp:482:54: warning: comparison of unsigned expression < 0 is always false
D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenstree.cpp:222:41: warning: comparison is always false due to limited range of data type

Regards,
VinniPuh.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 11 February 2012 build (7789) is out.
« Reply #42 on: April 03, 2012, 10:58:06 am »
Hi,
I compiled Code::Blocks (trunk, rev 7916, minGW32) with -Wextra and saw some warnings what is similar to a bug:

Code
D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:348:36: warning: comparison of unsigned expression < 0 is always false
D:\WORK\cb\trunk\src\plugins\codecompletion\parser/tokenizer.h:381:54: warning: comparison of unsigned expression >= 0 is always true
D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenizer.cpp:273:53: warning: comparison of unsigned expression >= 0 is always true
D:\WORK\cb\trunk\src\plugins\scriptedwizard\wizpage.cpp:482:54: warning: comparison of unsigned expression < 0 is always false
D:\WORK\cb\trunk\src\plugins\codecompletion\parser\tokenstree.cpp:222:41: warning: comparison is always false due to limited range of data type

Regards,
VinniPuh.

Hi, many thanks.
I will fix them.

EDIT: Here is the candidate change.

Code
    /** Return (peek) the previous character */
    wxChar PreviousChar() const
    {
        if ( ((m_TokenIndex - 1) < 0) || (m_BufferLen==0) ) // (m_TokenIndex - 1) >= m_BufferLen can never be true
            return 0;

        return m_Buffer.GetChar(m_TokenIndex - 1);
    };

Here:

Code
(m_TokenIndex - 1) < 0
The left is unsigned int, so its result is always >=0.

The only right case is (m_TokenIndex==0), right?

The next issue:
Code
m_TokenIndex - 2 >= 0

So, it need to change to
Code
m_TokenIndex >= 2

Then
Code
((m_TokenIndex - numBackslash) >= 0)
should be change to
Code
m_TokenIndex >= numBackslash


Forth issue:
Code
                       id = (cmb->GetCount() - 1) < 0 ? 0 : (cmb->GetCount() - 1);
should change to:
Code
cmb->GetCount() < 1


The last issue:
Code
size_t TokensTree::FindMatches(const wxString& s, TokenIdxSet& result, bool caseSensitive, bool is_prefix, short int kindMask)
{
    result.clear();

    std::set<size_t> lists;
    int numitems = m_Tree.FindMatches(s, lists, caseSensitive, is_prefix);
    if (!numitems)
        return 0;

    // now the lists contains indexes to all the matching keywords
    // first loop will find all the keywords
    for (std::set<size_t>::iterator it = lists.begin(); it != lists.end(); ++it)
    {
        TokenIdxSet* curset = &(m_Tree.GetItemAtPos(*it));
        // second loop will get all the items mapped by the same keyword,
        // for example, we have ClassA::foo, ClassB::foo ...
        if (curset)
        {
            for (TokenIdxSet::iterator it2 = curset->begin(); it2 != curset->end(); ++it2)
            {
                Token* token = at(*it2);
                if (   token
                    && (   (kindMask == tkUndefined)
                        || (token->m_TokenKind & kindMask) ) )
                    result.insert(*it2);
            }
        }
    }
    return result.size();
}

If I remember correct, the function parameter "short int" should be changed to Enum TokenKind type.




« Last Edit: April 03, 2012, 11:23:29 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: 9693
Re: The 11 February 2012 build (7789) is out.
« Reply #43 on: April 03, 2012, 08:33:09 pm »
Here:
Code
(m_TokenIndex - 1) < 0
The left is unsigned int, so its result is always >=0.

The only right case is (m_TokenIndex==0), right?
I would do this differently (to improve readability) and change if clause to check for the opposite:
Code
    /** Return (peek) the previous character */
    wxChar PreviousChar() const
    {
        if ( (m_TokenIndex > 0) && (m_BufferLen > 0) ) // m_TokenIndex > m_BufferLen can never be true
            return m_Buffer.GetChar(m_TokenIndex - 1);

        return 0;
    };
The rest seems OK.
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: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 11 February 2012 build (7789) is out.
« Reply #44 on: April 04, 2012, 03:11:10 am »
Ok, committed the fix. Thanks.

Quote
Revision: 7917
Author: ollydbg
Date: 2012-4-4 9:08:11
Message:
- fix log errors when comparing unsigned int with int, see: http://forums.codeblocks.org/index.php/topic,15945.msg109050.html#msg109050 (Thanks VinniPuh)
-------------------------------
M : /trunk/src/plugins/codecompletion/parser/tokenizer.cpp

M : /trunk/src/plugins/codecompletion/parser/tokenizer.h

M : /trunk/src/plugins/codecompletion/parser/tokenstree.cpp

M : /trunk/src/plugins/codecompletion/parser/tokenstree.h

M : /trunk/src/plugins/scriptedwizard/wizpage.cpp

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.