Author Topic: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.  (Read 19586 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2810_gcc451-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc451-TDM.7z

The 12 February 2011 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20110212_rev6992_DEBUGGER_BRANCH_win32.7z
  - Linux :
   none

Important changes compared to previous DEBUGGER BRANCH nightly:

* debugger_branch: applied patch cdb_fixed with the following features:
- grab the PID at launch so that process break / killing works - this allows setting breakpoints while running
- NotifyDebuggeeContinued on Continue so that the cursor doesn't disappear forever after setting breakpoints while running
- slightly improve recognising breakpoint & assert hits
- CDB is executed at the working directory
- CDB launches separate cmd window for console applications
* all updates that occurred on trunk


Note: Watch parsing prints an error message in the watches window if the parsing fails. If you see this string please report it as a bug.

THIS IS A SPECIAL TEST BUILD OF REFACTORINGS CARRIED OUT ON THE DEBUGGER BRANCH IN OUR SVN.
FOCUS IS ON ENHANCED DEBUGGING USABILITY.

Give your feedback on this version only in this thread, don't mix it with the regular nightly please.

Once we don't have any blockers on this version,we will merge the changes into trunk and it will be part of the regular nightlies.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #1 on: February 12, 2011, 09:06:16 pm »
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo.

If you want to use apt (or dselect, synaptic or whatever) you need to add the following entries to /etc/apt/sources.list :
Code
deb http://apt.jenslody.de/ any dbg
deb-src http://apt.jenslody.de/ any dbg
and remove entries for the normal nightlies.

Alternatively you can download the deb's directly from http://apt.jenslody.de/pool/dbg/c/codeblocks/ .

Offline grf

  • Multiple posting newcomer
  • *
  • Posts: 12
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #2 on: February 14, 2011, 08:48:18 am »
Nice work!

I would like to give an error report regarding the interpretation of the preprocessor directives ("#if..."). After enabling this and closing the editor configuration previuos version(s?) of Codeblocks crashed. This version gives an assertion:

File: sdk\wxscintilla\src\scintilla\lexlib\CharacterSet.h
Line: 62
Expression: val >= 0


Codeblocks Build 6992, DEBUGGER BRANCH, Windows XP SP2

As I remember it happens only for one of my projects. For other projects the editor does not crash, but the inactive preprocessor lines are not really greyed out, they are only become normal black characters. It would be fine if this could be configured in the syntax highlighting configuration. I would like to make this really grey...  :)

Offline Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #3 on: February 15, 2011, 10:37:53 am »
Compiling the current svn (7009), I get a bunch of warnings :
Quote
directorymonitor.cpp: In constructor ‘DirMonitorThread::DirMonitorThread(wxEvtHandler*, wxArrayString, bool, bool, int, int)’:
directorymonitor.cpp:102: warning: ignoring return value of ‘int pipe(int*)’, declared with attribute warn_unused_result
directorymonitor.cpp: In constructor ‘DirMonitorThread::DirMonitorThread(wxEvtHandler*, wxArrayString, bool, bool, int, int)’:
directorymonitor.cpp:102: warning: ignoring return value of ‘int pipe(int*)’, declared with attribute warn_unused_result
directorymonitor.cpp: In constructor ‘DirMonitorThread::DirMonitorThread(wxEvtHandler*, wxArrayString, bool, bool, int, int)’:
directorymonitor.cpp:102: warning: ignoring return value of ‘int pipe(int*)’, declared with attribute warn_unused_result
directorymonitor.cpp: In member function ‘virtual void* DirMonitorThread::Entry()’:
directorymonitor.cpp:217: warning: ignoring return value of ‘ssize_t read(int, void*, size_t)’, declared with attribute warn_unused_result
directorymonitor.cpp: In destructor ‘virtual DirMonitorThread::~DirMonitorThread()’:
directorymonitor.cpp:242: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result
directorymonitor.cpp: In destructor ‘DirMonitorThread::~DirMonitorThread()’:
directorymonitor.cpp:242: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result
directorymonitor.cpp: In destructor ‘virtual DirMonitorThread::~DirMonitorThread()’:
directorymonitor.cpp:242: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result
directorymonitor.cpp: In destructor ‘virtual DirMonitorThread::~DirMonitorThread()’:
directorymonitor.cpp:242: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result
directorymonitor.cpp: In member function ‘void DirMonitorThread::UpdatePaths(const wxArrayString&)’:
directorymonitor.cpp:262: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result
mv -f .deps/directorymonitor.Tpo .deps/directorymonitor.Plo
What is going wrong ?

(Kubuntu 10.10 64b)
Kernel Extremist - PedroM power ©

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #4 on: February 15, 2011, 11:15:24 am »
Folco: not a C::B problem, read the docs for gcc and glibc...
(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 Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #5 on: February 15, 2011, 12:28:42 pm »
Ah ? I didn't know, sorry
Kernel Extremist - PedroM power ©

Offline brucus

  • Single posting newcomer
  • *
  • Posts: 8
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #6 on: February 16, 2011, 02:58:10 pm »
Hallo, thanks for new version it's much much more stable than few versions before, but I have noticed a new annoying behavior - when I open or switch to another source file, there is a delay - time in which C::B doesn't respond to anything.

It looks it is caused by a symbol (function) parser - when I change the filter in symbols window to "Current project's symbols" or to "Everything" the delay is not there.
But when I use "Current file's symbols" the delay is back. I'm sure this  wasn't an issue in older versions.

O.K. Now I have noticed the problem is also present if "Current project's symbols" or to "Everything" is chosen - it's enough just to make some change to the file and save it. Now the parser is started and C::B is frozen for a while.


Would it be possible to eliminate the delay - just put the parser to background thread?
 I'm using the WinXP version.
Thanks.
« Last Edit: February 16, 2011, 03:14:31 pm by brucus »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #7 on: February 17, 2011, 02:00:59 am »
Hallo, thanks for new version it's much much more stable than few versions before, but I have noticed a new annoying behavior - when I open or switch to another source file, there is a delay - time in which C::B doesn't respond to anything.

It looks it is caused by a symbol (function) parser - when I change the filter in symbols window to "Current project's symbols" or to "Everything" the delay is not there.
But when I use "Current file's symbols" the delay is back. I'm sure this  wasn't an issue in older versions.

O.K. Now I have noticed the problem is also present if "Current project's symbols" or to "Everything" is chosen - it's enough just to make some change to the file and save it. Now the parser is started and C::B is frozen for a while.


Would it be possible to eliminate the delay - just put the parser to background thread?
 I'm using the WinXP version.
Thanks.
when switch a source file/header, CC will do several things:
1, update the toolbar(scope and function)
2, update the symbols browser tree.

But these things should be done in Main thread, because they are UI related.

Can you "disable" the CC's Toolbar to see the delay again?

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 brucus

  • Single posting newcomer
  • *
  • Posts: 8
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #8 on: February 17, 2011, 11:45:42 am »
when switch a source file/header, CC will do several things:
1, update the toolbar(scope and function)
2, update the symbols browser tree.

But these things should be done in Main thread, because they are UI related.

Can you "disable" the CC's Toolbar to see the delay again?

Hallo, thanks for response.
What exactly you mean by "disable" CC's toolbar?

Symbols are part of a management toolbar.
When I switch from "symbols" tab to "resources" or "files" and make a change in the source, there is again a delay.
Also when I change the file.
I think the parser become more complex and the parsing just takes too long.

I had to go back to 10.05, because I was unable to work in the 6992.
In 10.05, all is working fine even when symbols are not yet populated.
To me it looks the parsing is in another thread, but I may be wrong.

Regards.


Offline Folco

  • Regular
  • ***
  • Posts: 343
    • Folco's blog (68k lover)
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #9 on: February 17, 2011, 11:48:09 am »
Quote
What exactly you mean by "disable" CC's toolbar?
In the "View" menu, uncheck the Code Completion Toolbar to disable it.

[edit -> lot of mistakes]
« Last Edit: February 21, 2011, 05:13:32 pm by Folco »
Kernel Extremist - PedroM power ©

Offline brucus

  • Single posting newcomer
  • *
  • Posts: 8
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #10 on: February 21, 2011, 01:29:08 pm »
Quote
What exactly you mean by "disable" CC's toolbar?
In the "View" menu, unckeck the Code Completion Tollbar to disable it.

Didn't help.
The delay still present.
I have tried also 7017, no change, the delay is still there.
« Last Edit: February 21, 2011, 01:35:47 pm by brucus »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #11 on: February 21, 2011, 04:33:31 pm »
Quote
What exactly you mean by "disable" CC's toolbar?
In the "View" menu, unckeck the Code Completion Tollbar to disable it.

Didn't help.
The delay still present.
I have tried also 7017, no change, the delay is still there.
you need to upload the sample project and let us to reproduce this bug, then we can fix 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 brucus

  • Single posting newcomer
  • *
  • Posts: 8
Re: The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.
« Reply #12 on: February 23, 2011, 10:59:53 am »
Quote
you need to upload the sample project and let us to reproduce this bug, then we can fix it.

O.K. I will try to make a time and prepare sample project to demonstrate the problem.