Debugger plugin : remote debugging : request + remarks

[killerbot]

I think it would be nice, to add a check box in the remote debugging configuration area, to allow to use "extended-remote", instead of just "remote".

secondly, I noticed in my very "first" remote debugging use case with gdb, that in CB, the debugger "Command" field didn't allow anything to be typed in.
Is this a bug or done on purpose ?

Third : I noticed that the remote ip address and port are stored in the project file, since this file is normally under version control it is not a good idea to store this in here. Since I am debugging on my target on a certain ip address/port, while another colleague is doing the same on his device, at yet another ip/port. And as such our cbp file get's changed all the time, and if this change get's into the the version control system, it is no fun.


What do the other devs think about this ?

[oBFusCATed]

I think it would be nice, to add a check box in the remote debugging configuration area, to allow to use "extended-remote", instead of just "remote".

Patches welcome.

Third : I noticed that the remote ip address and port are stored in the project file, since this file is normally under version control it is not a good idea to store this in here. Since I am debugging on my target on a certain ip address/port, while another colleague is doing the same on his device, at yet another ip/port. And as such our cbp file get's changed all the time, and if this change get's into the the version control system, it is no fun.

There is no general mechanism for storing staff in non-project files, so nothing will be done (at least by me) about this until some general API is added.
Currently I've not time to do it, but I have it in the TODO for a long time, so when I get some free time I'll see what I can do about this API.
I don't like the current situation with the .depend, .layout, .workspace.layout, .bmars and other files piling in the project directory, it is pretty ugly and I don't want to make it even worse...

[killerbot]

ok I will take care of the first part,

what is the answer to the second ?


New issue (can I ask for help from our debugger expert ?) :
Edit break point dialog is rather small, but the thing to improve is, it should be able to be resized, that way one can ensure that for example a long "expression" is fully visible.

[oBFusCATed]

what is the answer to the second ?

Probably a bug, but I don't know what was the purpose for these commands, you have to look at the code and svn blame to get the idea.

New issue (can I ask for help from our debugger expert ?) :
Edit break point dialog is rather small, but the thing to improve is, it should be able to be resized, that way one can ensure that for example a long "expression" is fully visible.

I think this one is simpe XRC dialog, so you can edit the file and it should be able to be resizable.

[ouch]

You know I always thought Codeblocks needed a separate .settings file to store misc settings for the project. Even so much as to say that we need an option of storing things in a separate .settings file or in the project file. (Some settings you want to share with everyone, but others you just want for yourself) But oBFusCATed is right, there might be getting too many "project" files. Maybe we need to make the cbp files an archive based format similar to the open document movement. Or maybe we should switch to a simple database like sqlite3. Personally I would prefer a database based approach as that would make loading a hell of a lot faster for large projects. You could even have export/import functions so people could still work with plain text files if they wanted too.

But that's just my 2 cents...

[oBFusCATed]

Maybe we need to make the cbp files an archive based format similar to the open document movement.

I'm thinking of a directory, probably hidden

Or maybe we should switch to a simple database like sqlite3. Personally I would prefer a database based approach as that would make loading a hell of a lot faster for large projects. You could even have export/import functions so people could still work with plain text files if they wanted too.

SQL is for the business people, we don't need to infest C::B with it, we have one business evil in the for of XML, we don't need another.
Also sqlite is not a fast database. My feed reader is using it and it is pretty damn slow to load, because of the sqlite.

[ouch]

The problem with hidden directories is that you will have cross platform issues. For instance my svn repositories has all those .svn sub-directories visible in windows, but hidden in linux.

You use SQL anytime you need to organize data in an fast and easy to access fashion while maintaining data integrity. Something which XML sorely lacks on all fronts. Also SQLite is one of, if not the fastest sql engines around. (I personally know it's faster than Postgresql or MySQL anyway, I've tested it against SQLite at work) So I'm not sure what your feed reader is doing with it.

[oBFusCATed]

You use SQL anytime you need to organize data in an fast and easy to access fashion while maintaining data integrity. Something which XML sorely lacks on all fronts. Also SQLite is one of, if not the fastest sql engines around. (I personally know it's faster than Postgresql or MySQL anyway, I've tested it against SQLite at work) So I'm not sure what your feed reader is doing with it.

You're joking aren't you? 

There is no point in arguing I won't use sql for this! And I hope no other dev will.

[stahta01]

You use SQL anytime you need to organize data in an fast and easy to access fashion while maintaining data integrity. Something which XML sorely lacks on all fronts. Also SQLite is one of, if not the fastest sql engines around. (I personally know it's faster than Postgresql or MySQL anyway, I've tested it against SQLite at work) So I'm not sure what your feed reader is doing with it.

You're joking aren't you?  

There is no point in arguing I won't use sql for this! And I hope no other dev will.

SQL is over kill for the information an IDE needs.

IMNSHO, A SQL Database design needs at least one table with 1000 plus rows and a hand full of tables with more than 100 rows.
Using third normal form (3NF), I do not see the requirements for an IDE reaching that level.
If the requirements are below the above, it is NOT likely a good candidate for an SQL Database.
Even if it meets these requirements; it might not be a good candidate for an SQL Database.

Tim S.

PS: Good luck using an SQL Lite database in version control system.
The first corrupt database will kill the use of an IDE using an SQL database.

[Alpha]

The problem with hidden directories is that you will have cross platform issues. For instance my svn repositories has all those .svn sub-directories visible in windows, but hidden in linux.

#ifdef __WXMSW__
FILE_ATTRIBUTE_HIDDEN
... Possibly?

[ouch]

oBFusCATed: I'm not sure how you think what I said is a joke, everything in that post is true to my knowledge.

stahta01: The codeblocks .depends file contains 3,693 files, and is 25k rows long. Data has a way creeping up unsuspectingly. And SVN works with binary files just fine. One of the benefits of SQL databases is that they are designed from the ground up to be corruption resistant.

All I am saying is that for the codeblocks project file codeblocks ends up reading around 1mb of text files just to load that single project...

But ultimately codeblocks is not my project and the developers should use what they are comfortable with. If SQL isn't it, then it isn't it, but it seems the amount of text based project files that codeblocks must load is only going to be increasing in the future.

[oBFusCATed]

ouch: <facepalm>.... you think text file with 25k rows is long... please no more off topic...

p.s. and sqlite is not the fastest sql engine, especially for projects where an sql database is really needed (10-100 millions of rows)!