debuging C::B

[roshi]

Hi people,
I'm trying the SVN version of C::B build 4564, with wxGTK 2.6.8 GCC 4.1.1-r3
Previously I was using codeblocks-1.0_pre20070511 (this is on gentoo linux).

Anyway, I've noticed that an old bug has apparently returned.
When I open certain cpp files they show up empty.
If I open them on another app, save, and them and open them again on C::B then it works...

Is there a way to know what was the error that C::B encountered while opening the file?

Also, apparently the scrolling still has that problem of high CPU usage.
No hint of why as of now?

Thanks

 

[Biplab]

Anyway, I've noticed that an old bug has apparently returned.
When I open certain cpp files they show up empty.
If I open them on another app, save, and them and open them again on C::B then it works...

Is there a way to know what was the error that C::B encountered while opening the file?

It's due to wrong encoding conversion. Currently C::B supports UTF-8/16/32 and system default encoding.

This problem can happen if a file has mixed encoding and C::B can detect wrongly in some cases. Just check which encoding is detected in your case.

[roshi]

Thank
I just noticed that doing a diff between the old and the edited version of the file I got:
<             << "Can´t resize screen to "
---
>             << "Can�t resize screen to "

The thing is that the previous version that I was using did not have this problem.
Don't you think that it should open the file even the encoding is wrong?
Some fallback....
This might be philosophical discussion but it's interesting to see the contents even if partially wrong.
Moreover it might be interesting to turn on this kind of debugging output to the C::B debug tab.

Thanks

[Biplab]

Thank
I just noticed that doing a diff between the old and the edited version of the file I got:
<             << "Can´t resize screen to "
---
>             << "Can�t resize screen to "

The thing is that the previous version that I was using did not have this problem.
Don't you think that it should open the file even the encoding is wrong?
Some fallback....
This might be philosophical discussion but it's interesting to see the contents even if partially wrong.
Moreover it might be interesting to turn on this kind of debugging output to the C::B debug tab.

Which revision are you using? If possible please upgrade to 4564.

Yes even if the conversion fails, we should be able to see the raw data. But once conversion fails, one will get an empty string (this is how we detect failure). We can feed the raw data as a fallback to wxScintilla only if there is no embedded null chars inside a string. Otherwise you'll see only one or two chars and the remaining portion will get rejected.

[roshi]

Yes that is the revision that I'm using.
I also noticed that the cut and paste is acting strange.
The copy/cut fails allot.

For example, I do ctrl+x, the selected text actually disappears but, when I try to paste, C::B pastes the old cut/copied block and not the new one.

cheers

[Biplab]

Yes that is the revision that I'm using.

If possible, please attach the source file as a zip/7z file. It will help us track down any encoding related bugs.

[roshi]

No problem.
It looks like only 1 char is problematic...
If you can't open the file say it. I'll create a different one.
Good bug hunt.

[attachment deleted by admin]

[Biplab]

No problem.
It looks like only 1 char is problematic...
If you can't open the file say it. I'll create a different one.
Good bug hunt.

The problem is that the file is a plain ascii file. The encoding detection correctly detects that it's Not an UTF-8 file. But the fallback code sets the encoding to System Default, which is UTF-8 for Linux. And the problem starts there. wxWidgets conversion routine fails there and the fallback code also tries convert the file, again, to UTF-8. That particular character is malformed as per UTF-8.

I reverted this code in two revision back which resets to system default. But I think I should make a re-revert of that. I think I can rely on the utf-8 detection code.

I've committed a fix in revision 4565 which should solve your problem.

I'll add some messages to it so that it can inform us when such conversion fails.

[roshi]

Good work