Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Major CVS codebase changes

<< < (3/6) > >>

takeshimiya:

--- Quote from: mandrav on November 18, 2005, 12:47:09 am ---I forgot to mention that in case you want to build HEAD as soon as anonymous CVS catches up, only the codeblocks-NewBuild.cbp is up to date. It 's using global user vars, a feature introduced right after 1.0rc2 was released.
This means you must have a recent CVS binary to build this.

--- End quote ---
Funnily, that also means that you need HEAD from yesterday to build HEAD from today. Any other version will not work until the other projects gets updated :lol:

therion:
Ive just uploaded the files. They were update from head_merged_to_yt tag, but everything looks fine, should be some kind of temp tag, dont know :-)
BTW The KeyBinder is great! Really a great feature!
Ill test the new debug plugin and send a new build from HEAD revision (the real one) tomorrow (quite late here in Brazil, hehehe)

Enjoy the new build. http://paginas.terra.com.br/informatica/mauricio/codeblocks/

thomas:

--- Quote ---I'm not sure if I like breaking interface compatibility with wxConfig.
It is necesary to write [...]
--- End quote ---
Yes it is, unluckily. Apart from that, being compatible with wxConfig was never intended (the API misses *many* things of wxConfig and includes *many* things that wxConfig could only dream of).
By using namespaces, we already break compatibility (and all existing code), and when we store maps of serializable objects in the configuration, wxConfig has passed out of sight long ago.
Passing objects as parameters gave me a lot of headaches, the compiler would not easily accept polymorph functions with default arguments of different non-builtin types (such as wxString, wxArrayString and wxColour) either by reference or as pointers. Very often, it would convert an argument to void* and then call the wxString version with a void* argument (which is an awful mess!). Naming the functions differently solved the problem at once. Maybe there is a better workaround, but this is actually not so bad. It works, and it is very explicit.
If you don't like the T ReadT(name) functions, you can still use the Read(name, *T) versions, these are wxConfig compatible and are a few clock cycles faster too (since the other functions use them internally).


--- Quote ---On where to store the configuration files and data, ...
--- End quote ---
Every decent operating system understands what ~/.codeblocks means, so that is what is used on all platforms except Windows.
Under Windows, SHGetFolderPath is used with CSIDL_APPDATA. Whatever it is, this is what Windows thinks is the right place. Hardcoding anything differently is an extremely bad idea since it is a user-configurable setting. For example on my PC, the location is D:\system\appdata. The way it is, it should work well everywhere.
On the same subject, please note that ConfigManager also offers functions to get the paths to the data folder, the application folder, or the plugins folder, and even a function to locate a file in a defined way. You should always use these functions and never hardcode a path again. For example, if the Code::Blocks devs decide to move the plugin folder to a different location one day, the respective function will be changed, and you don't need to bother. It just works.


--- Quote ---About the XML file itself, following a based standard on the tags of the file
--- End quote ---
Oh I knew this was going to come... What can I say but these three things:
1. The config does not validate against a DTD, but it is perfectly legal xml (that's a standard too :))
2. The way tags are generated is neither a random choice, nor is it because I don't know any better. The file organisation has been thoroughly planned. The present layout allows O(1) access to child elements as opposed to O(N) in the "standard" schemes which scan through attributes. It also allows to have a key with the same name as a path unambiguously, and it allows several differently typed values tied to one key. Lastly, compound objects are stored in the most efficient and compatible manner.
3. Forget about xml. Use the API to write and read values. The mere fact that the configuration uses xml as a backend does not mean anything. It could as well be Chinese. You don't need to care, you don't want to care, you should not care.


--- Quote ---A posibility, like GConf does, is to put each major setting (like Editor, Compiler, To-Do, etc) in a separate physical XML file
--- End quote ---
It is not like I did not think about that. And indeed, we do that for personalities. The reason for this design choice is that personalities are a logical unit, and copying namespaces between personalities can easily be offered by a plugin (this is in planning). However, the processing overhead for opening 20 or 30 files at startup is prohibitively high. The initial cost to open a file and parse it is very noticeable. Accessing data stored in a node once the document has been parsed is almost zero (supposed you have laid out your data correctly).


--- Quote ---All of that is pretty standard now within the GNOME apps, and is working great :)
--- End quote ---
When I log onto GNOME, it takes about 30 seconds to start up on my AMD64 3500. See what I mean?


--- Quote ---~25% speed-up of project loading
--- End quote ---
Very likely, we can even do a lot better than that in the future. Not promising anything, but the present optimisations were rather conservative (changing one wxFileName function call, omitting some xml parsing, and block-allocating project files). A new class for handling project file paths is in work, and several recurring branches can probably be moved outside loops without affecting the end result. It is uncertain how much this will improve overall performance, but I think it will be quite noticeable, again.


--- Quote ---Funnily, that also means that you need HEAD from yesterday to build HEAD from today.
--- End quote ---
*big evil grin*  Yes indeed. Sorry, I didn't think about that :lol:

takeshimiya:
I agree with you.
Now that you said about performance of parsing XML files, it's true, like when parsing the lexers for Code::Blocks... it takes a lot (like 3 seconds or more sometimes) and it'll grow more.

About on where to store the configuration files and data, I was saying examples of what would be the %APPDATA% between systems. Of course hardcoding is bad.

PS: I do care what's the backend of the configuration, not that I like it being the windows registry

Now comes the part of updating contrib plugins to the new ConfigManager :)

squizzz:

--- Quote from: mandrav ---By the way, if anyone has a list of menu shortcuts for MSVisualC++ please share them so we can add a second keybinding profile for people migrating over to C::B ;)
--- End quote ---
If there is some easy way to export it, I can prepare keyboard scheme of Dev-C++ and Borland Builder. If just a list "action - key(s)" is enough, that's ok too.

Navigation

[0] Message Index

[#] Next page

[*] Previous page