User forums > General (but related to Code::Blocks)
"Portable" Code::blocks?
thomas:
--- Quote from: Pecan on February 07, 2007, 03:58:37 pm ---Never heard of it. wxWidgets wxFileConf is actually documented, and you can read and write to it with only two statement. It works very well.
--- End quote ---
It's sad you never heard of it, since it's used everywhere all over the application, and in all plugins (except the two above), and it's the recommended canonical way of saving user configuration. It is neither complicated, nor secret magic. And it's very convenient for complex datatypes that wxFileConfig does not support at all, too.
As far as documentation is concerned, I almost never document any of my code because I think if someone needs to read a manual to know what to do with a class, then the guy who wrote it in the first place has not done a particularly good job.
Also, the wxWidgets documentation is so blatantly wrong in some places that they had better written none at all. I don't know about the particular case of wxFileConfig, though.
Nevertheless, ConfigManager class is quite well documented (well... for my measures, anyway). Not like a function as void Write(const wxString& name, int value); needs an awful lot of documentation, anyway :)
--- Quote ---And I dont have to home brew all the xml calls and deal with the crashed, corrupted .conf files.
--- End quote ---
You don't use one single XML call using the configmanager. I'm surprised where you get that idea from.
Corrupted .conf files are something that happened a long time ago, partly because of implementation details from my side (insufficient user input error checking), but also from literal abuse (using user-entered strings as key names, and entering Chinese strings).
Most (hopefully all?) things you can do wrong should be caught by now, and there is no real recent issue regarding the config manager that I know of.
Clearly, ConfigManager works after the same principle like all software does at its core: shit in = shit out.
There is sure some way you can corrupt the config file, one way or the other. However, show me one piece of software which does not have that property.
All in all, "having to deal with crashed, corrupted .conf files" is a most unfair statement, given the fact that not few of the past crashes actually came from KeyBinder, and .conf files are saved a lot more reliably than anything in wxWidgets (because the often-used "safe" wxTempFile class is not safe at all). Yes, file corruption may occur, in any file, with any program, for whatever reason... that's an implementation detail of what we commonly call "reality". But I don't like it when people make it sound like ".conf files are corrupted all the time", because that's simply not true.
--- Quote ---I don't get it. Why can't CB just tell us where it's reading and writing the config from/to. That's all we need to know.
--- End quote ---
Apart from the fact Yiannis said "no", which concludes that subject, I'm not bothered about that if you believe that it absolutely has to be. It's not a state secret and we don't have to kill you if we tell you. However, it would not solve your problems!
To give an example why it won't help: Are you aware of the fact that Code::Blocks can be given a profile URL and will transparently read its configuration from a http:// URL?
We do not currently support WebDAV, so saving remote configuration does not work yet, but that is something which will be added in the future (in fact, it'll be anything supported by libcurl).
The idea behind that is that it does not matter where on your PC or where on this planet (or any place in the universe?) Code::Blocks is located and where the configuration is placed. As long as the internet has a route to it, things will just work. You don't need to know why or how, and you don't want to know.
If you implement your own config saving using whatever other library, you will have to take care of this, too.
Now please don't tell me about wxFileConfig reading from and writing to URLs via wxFileSystem... I'll fall off my chair otherwise. :)
Pecan:
--- Code: ---[quote author=thomas link=topic=5115.msg40099#msg40099 date=1170866901]
[quote author=Pecan link=topic=5115.msg40088#msg40088 date=1170860317]
Never heard of it. wxWidgets wxFileConf is actually documented, and you can read and write to it with only two statement. It works very well.[/quote]It's sad you never heard of it, since it's used everywhere all over the application, and in all plugins (except the two above), and it's the recommended canonical way of saving user configuration. It is neither complicated, nor secret magic. And it's very convenient for complex datatypes that wxFileConfig does not support at all, too.
As far as documentation is concerned, I almost never document any of my code because I think if someone needs to read a manual to know what to do with a class, then the guy who wrote it in the first place has not done a particularly good job.
Also, the wxWidgets documentation is so blatantly wrong in some places that they had better written none at all. I don't know about the particular case of wxFileConfig, though.
Nevertheless, ConfigManager class is quite well documented (well... for my measures, anyway). Not like a function as [tt]void Write(const wxString& name, int value);[/tt] needs an awful lot of documentation, anyway :)
[quote]And I dont have to home brew all the xml calls and deal with the crashed, corrupted .conf files.[/quote]You don't use one single XML call using the configmanager. I'm surprised where you get that idea from.
Corrupted [tt].conf[/tt] files are something that happened a long time ago, partly because of implementation details from my side (insufficient user input error checking), but also from literal abuse (using user-entered strings as key names, and entering Chinese strings).
Most (hopefully all?) things you can do wrong should be caught by now, and there is no real recent issue regarding the config manager that I know of.
Clearly, ConfigManager works after the same principle like all software does at its core: shit in = shit out.
There is sure some way you can corrupt the config file, one way or the other. However, show me one piece of software which does not have that property.
All in all, "having to deal with crashed, corrupted .conf files" is a most unfair statement, given the fact that not few of the past crashes actually came from KeyBinder, and [tt].conf[/tt] files are saved a lot more reliably than anything in wxWidgets (because the often-used "safe" [tt]wxTempFile [/tt]class is not safe at all). Yes, file corruption may occur, in any file, with any program, for whatever reason... that's an implementation detail of what we commonly call "reality". But I don't like it when people make it sound like ".conf files are corrupted all the time", because that's simply not true.
[quote]I don't get it. Why can't CB just tell us where it's reading and writing the config from/to. That's all we need to know.[/quote]Apart from the fact Yiannis said "no", which concludes that subject, I'm not bothered about that if you believe that it absolutely has to be. It's not a state secret and we don't have to kill you if we tell you. However, it would not solve your problems!
To give an example why it won't help: Are you aware of the fact that Code::Blocks can be given a profile URL and will transparently read its configuration from a [tt]http://[/tt] URL?
We do not currently support WebDAV, so saving remote configuration does not work yet, but that is something which will be added in the future (in fact, it'll be anything supported by libcurl).
The idea behind that is that it does not matter where on your PC or where on this planet (or any place in the universe?) Code::Blocks is located and where the configuration is placed. As long as the internet has a route to it, things will just work. You don't need to know why or how, and you don't want to know.
If you implement your own config saving using whatever other library, you will have to take care of this, too.
Now please don't tell me about [tt]wxFileConfig [/tt]reading from and writing to URLs via [tt]wxFileSystem[/tt]... I'll fall off my chair otherwise. :)
[/quote]
--- End code ---
Way over complicated and unuseful.
artoj:
--- Quote from: thomas on February 07, 2007, 05:48:21 pm ---To give an example why it won't help: Are you aware of the fact that Code::Blocks can be given a profile URL and will transparently read its configuration from a http:// URL?
--- End quote ---
I don't mean to hijack this thread or anything but I can't get that to work. I tried both Windows (rev 3577) + Ubuntu Edgy (rev 3583), both wxW 2.6.3p2. In Windows using a remote config just closes C::B, nothing happens. In Ubuntu I got a core dumped message. GDB output also had some problems in fact, GDB went to an infinite loop while I was debugging.
This is the output from the first run:
--- Code: ---GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) set args --profile=http://ajonsson.kapsi.fi/default.conf
(gdb) run
Starting program: /usr/local/bin/codeblocks --profile=http://ajonsson.kapsi.fi/default.conf
[Thread debugging using libthread_db enabled]
[New Thread -1230850384 (LWP 22439)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1230850384 (LWP 22439)]
0xb723bb8c in free () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb723bb8c in free () from /lib/tls/i686/cmov/libc.so.6
#1 0xb723d83f in malloc () from /lib/tls/i686/cmov/libc.so.6
#2 0xb73ec4b7 in operator new () from /usr/lib/libstdc++.so.6
#3 0xb76374c9 in wxMutex::wxMutex () from /usr/local/lib/libwx_gtk2u-2.6.so.0
#4 0xb7b7f735 in CfgMgrBldr (this=0xa53a768)
at /usr/local/include/wx-2.6/wx/thread.h:273
#5 0xb7b7fff6 in CfgMgrBldr::GetConfigManager (name_space=@0xbf3c1258)
at manager.h:144
#6 0xb7bee4bd in Manager::GetConfigManager (this=0xb7ef0460,
name_space=@0xbf3c1258) at manager.cpp:286
#7 0xb7b7dc3d in ConfigManager::GetProxy () at configmanager.cpp:443
#8 0xb7b7f2c3 in CfgMgrBldr::SwitchToR (this=0xa539e48,
absFileName=@0xbf3c13d0) at configmanager.cpp:281
#9 0xb7b7fa2d in CfgMgrBldr (this=0xa539e48) at configmanager.cpp:168
--- End code ---
Second run:
--- Code: ---Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1230084432 (LWP 22567)]
0xb72f87c6 in malloc () from /lib/tls/i686/cmov/libc.so.6
(gdb) bt
#0 0xb72f87c6 in malloc () from /lib/tls/i686/cmov/libc.so.6
#1 0xb76b93c9 in wxStringBase::Alloc ()
from /usr/local/lib/libwx_gtk2u-2.6.so.0
#2 0xb76b99b0 in wxStringBase::append ()
from /usr/local/lib/libwx_gtk2u-2.6.so.0
#3 0xb76c1641 in wxURI::ParseScheme ()
from /usr/local/lib/libwx_gtk2u-2.6.so.0
#4 0xb76c22e5 in wxURI::Parse () from /usr/local/lib/libwx_gtk2u-2.6.so.0
#5 0xb76c236a in wxURI::Create () from /usr/local/lib/libwx_gtk2u-2.6.so.0
#6 0xb76c44a7 in wxURI::wxURI () from /usr/local/lib/libwx_gtk2u-2.6.so.0
#7 0xb771398c in wxURL::wxURL () from /usr/local/lib/libwx_gtk2u-2.6.so.0
#8 0xb7c3a2bb in CfgMgrBldr::SwitchToR (this=0xa5414e8,
absFileName=@0xbf54f290) at configmanager.cpp:280
#9 0xb7c3aa2d in CfgMgrBldr (this=0xa5414e8) at configmanager.cpp:168
#10 0xb7c3aff6 in CfgMgrBldr::GetConfigManager (name_space=@0xbf54f328)
at manager.h:144
#11 0xb7ca94bd in Manager::GetConfigManager (this=0xb7fab460,
name_space=@0xbf54f328) at manager.cpp:286
#12 0xb7c38c3d in ConfigManager::GetProxy () at configmanager.cpp:443
#13 0xb7c3a2c3 in CfgMgrBldr::SwitchToR (this=0xa540bc8,
absFileName=@0xbf54f4a0) at configmanager.cpp:281
#14 0xb7c3aa2d in CfgMgrBldr (this=0xa540bc8) at configmanager.cpp:168
#15 0xb7c3aff6 in CfgMgrBldr::GetConfigManager (name_space=@0xbf54f538)
--- End code ---
Game_Ender:
--- Quote from: Pecan on February 07, 2007, 05:58:58 pm ---Way over complicated and unuseful.
--- End quote ---
Why are you so hostile? Its actually a pretty elegant system. You access data with file system like paths and you don't have to worry about whether you have actually written the config data of not and non-intrusively handles complex data types.
Pecan:
--- Quote from: Game_Ender on February 07, 2007, 08:38:59 pm ---
--- Quote from: Pecan on February 07, 2007, 05:58:58 pm ---Way over complicated and unuseful.
--- End quote ---
Why are you so hostile? Its actually a pretty elegant system. You access data with file system like paths and you don't have to worry about whether you have actually written the config data of not and non-intrusively handles complex data types.
--- End quote ---
I no longer care to write code tightly coupled to the CB sdk. When the day comes that it's more dependable and stable, I may change my mind.
I've been stung too many times to try to stick to the sdk. I'd rather spend my time creating something new and running down current bugs.
All thats needed for now is a function that returns the path to where core CB is going to read and write its .conf . If the core CB doesnt want a plugin to write, it can say so. But at least a plugin could read its ini, databases, text files, whatever.
I think it's a simple request.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version