News:

Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!

Main Menu

The 12 February 2011 build (6992) DEBUGGER BRANCH version is out.

Started by killerbot, February 12, 2011, 05:33:22 PM

Previous topic - Next topic

killerbot

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.

Jenna

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 :
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/ .

grf

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...  :)

Folco

Compiling the current svn (7009), I get a bunch of warnings :
Quotedirectorymonitor.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 ©

oBFusCATed

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!]

Folco

Kernel Extremist - PedroM power ©

brucus

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.

ollydbg

Quote from: brucus 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.
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.

brucus

Quote from: ollydbg on February 17, 2011, 02:00:59 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.


Folco

QuoteWhat exactly you mean by "disable" CC's toolbar?
In the "View" menu, uncheck the Code Completion Toolbar to disable it.

[edit -> lot of mistakes]
Kernel Extremist - PedroM power ©

brucus

Quote from: Folco on February 17, 2011, 11:48:09 AM
QuoteWhat 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.

ollydbg

Quote from: brucus on February 21, 2011, 01:29:08 PM
Quote from: Folco on February 17, 2011, 11:48:09 AM
QuoteWhat 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.

brucus

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.