Have a question, i hope CB term can fix it. Thanks!If you mean "team" by "term" the it's "fixed" (probably better to say adjusted) in trunk.
Oh. god.Have a question, i hope CB term can fix it. Thanks!If you mean "team" by "term" the it's "fixed" (probably better to say adjusted) in trunk.
hello èéhello ийThe two western characters with ASCII codes 0xE8 and 0xE9 aren't displayed correctly.
svn build rev 5717 (2009-07-28T07: 15:12.319835 Z) gcc 4.4.1 Windows / unicodeThat's not wrong, that's exactly how SVN reports the date/time. It's just "a" format. Check any "entries" file in a .svn sub-foldr if you like. It's all the same.
We parse the date with a regex, if we use automake on linux.svn build rev 5717 (2009-07-28T07: 15:12.319835 Z) gcc 4.4.1 Windows / unicodeThat's not wrong, that's exactly how SVN reports the date/time. It's just "a" format. Check any "entries" file in a .svn sub-foldr if you like. It's all the same.
Index: autorevision.cpp
===================================================================
--- autorevision.cpp (Revision 5716)
+++ autorevision.cpp (Arbeitskopie)
@@ -122,6 +122,8 @@
if(d && d->GetText())
{
date = d->GetText();
+ date.replace(date.find('T'),1," ");
+ date.resize(date.find('.'));
}
return 1;
}
We parse the date with a regex, if we use automake on linux.Linux I don't know. But he was talking about Windows. However - what's wrong with using the format as it is used in the (any) SVN repository? I mean: We *are* talking about a SVN revision here, right?
We parse the date with a regex, if we use automake on linux.Linux I don't know. But he was talking about Windows. However - what's wrong with using the format as it is used in the (any) SVN repository? I mean: We *are* talking about a SVN revision here, right?
We parse the date with a regex, if we use automake on linux.Linux I don't know. But he was talking about Windows. However - what's wrong with using the format as it is used in the (any) SVN repository? I mean: We *are* talking about a SVN revision here, right?
I know that he is talking about windows.
I don't know, why subversion uses this format for date/time of last commit (internally), but are there any objections against using a format, that's (better) human-readable for the date and time ?
The only cause would be, if we have to distinguish between to revision, that came in at the same second, but we also use the revision-number, so I don't see any problem.
And I don't think the patch to autorevision.cpp can break anything, unless the svn date-format changes.
We parse the date with a regex, if we use automake on linux.Linux I don't know. But he was talking about Windows. However - what's wrong with using the format as it is used in the (any) SVN repository? I mean: We *are* talking about a SVN revision here, right?
I know that he is talking about windows.
I don't know, why subversion uses this format for date/time of last commit (internally), but are there any objections against using a format, that's (better) human-readable for the date and time ?
The only cause would be, if we have to distinguish between to revision, that came in at the same second, but we also use the revision-number, so I don't see any problem.
And I don't think the patch to autorevision.cpp can break anything, unless the svn date-format changes.
Better consult with Thomas first. Once I wanted to fix this issue. But he didn't want to touch that code. I forgot the exact objection. :)
We parse the date with a regex, if we use automake on linux.Linux I don't know. But he was talking about Windows. However - what's wrong with using the format as it is used in the (any) SVN repository? I mean: We *are* talking about a SVN revision here, right?
I know that he is talking about windows.
I don't know, why subversion uses this format for date/time of last commit (internally), but are there any objections against using a format, that's (better) human-readable for the date and time ?
The only cause would be, if we have to distinguish between to revision, that came in at the same second, but we also use the revision-number, so I don't see any problem.
And I don't think the patch to autorevision.cpp can break anything, unless the svn date-format changes.
Better consult with Thomas first. Once I wanted to fix this issue. But he didn't want to touch that code. I forgot the exact objection. :)
Thomas ?
Thomas ?
Yes!!
LOL! :lol: :lol: :lol:I just cried for him, so he can not overread it, if he looks through unread topics.Thomas ?Yes!!
BUT: what did you do with the patch that saved me, about SDCC and static libs?...probably overseen? The next nightly will take care. I've submitted the modification.
Thanks!We parse the date with a regex, if we use automake on linux.svn build rev 5717 (2009-07-28T07: 15:12.319835 Z) gcc 4.4.1 Windows / unicodeThat's not wrong, that's exactly how SVN reports the date/time. It's just "a" format. Check any "entries" file in a .svn sub-foldr if you like. It's all the same.
We can do something similar on windows (of course without regexes).
Any objections against this patch:CodeIndex: autorevision.cpp
===================================================================
--- autorevision.cpp (Revision 5716)
+++ autorevision.cpp (Arbeitskopie)
@@ -122,6 +122,8 @@
if(d && d->GetText())
{
date = d->GetText();
+ date.replace(date.find('T'),1," ");
+ date.resize(date.find('.'));
}
return 1;
}
Hello CodeBlocks team,
First, CB is great. I use the nightly builds even for production. The degree of flexibility is just beyond everything I know from certain M$ products.
But the last 3 nightly builds include a bug in the command macro expansion. I filed a bug report here:
http://developer.berlios.de/bugs/?func=detailbug&bug_id=16072&group_id=5358 (http://developer.berlios.de/bugs/?func=detailbug&bug_id=16072&group_id=5358)
Regards
S.B.
anyone already an idea on this regression ? wxAUi related ?If this is true:
Apparently the bug was introduced in svn build 5678....then "no". Because the wxAUI merge came later.
anyone already an idea on this regression ? wxAUi related ?If this is true:QuoteApparently the bug was introduced in svn build 5678....then "no". Because the wxAUI merge came later.
EDIT: Cannot even reproduce. Works fine here...?!
which is a change to 'compilercommandgenerator.cpp' base upon work of 'Biplab' : "replace macros for compiler options".It seems so.
Basically 2 lines have been added, doing a macro substitution, could it be it is carried out too early ??
So my proposal is to revert commit 5636, unless we find a way to protect C::B's internal variables.Agreed. Still: It works for me on Windows even with the patch!!!
In the global settings everything seems fine.Now THAT clarifies why it seemed to work for me. ;-)
which is a change to 'compilercommandgenerator.cpp' base upon work of 'Biplab' : "replace macros for compiler options".
Basically 2 lines have been added, doing a macro substitution, could it be it is carried out too early ??
Sorry for my insistence,...
only to be sure that someone could confirm the File Encoding problem (see my previous post).
I can't use C::B anymore in this situation because all the characters like à, è, ò, ... are messed up.
And my C/C++ comments are full of them because they're quite common in Italian language (but I think also in French, Spanish, ...)
At the end I had to switch back to the old 5678 Nightly Build, but if I made some mistake during upgrading I could try to solve it....
Thanks for your help
Sorry for my insistence,...I can confirm this (on wondows), and will have a look into it.
only to be sure that someone could confirm the File Encoding problem (see my previous post).
I can't use C::B anymore in this situation because all the characters like à, è, ò, ... are messed up.
And my C/C++ comments are full of them because they're quite common in Italian language (but I think also in French, Spanish, ...)
At the end I had to switch back to the old 5678 Nightly Build, but if I made some mistake during upgrading I could try to solve it....
Thanks for your help
could you please send me example-files that fail, if possible ?
The reason is quite simple, I decided to also search for latin-2 encoding needed for langauges like Bosnian, Croatian, Czech, Hungarian, Polish, Romanian, Serbian (when in the Latin script), Slovak, Slovenian, Upper Sorbian, and Lower Sorbian, but it breaks some latin-1 encoded texts due to their similarity, not all and not always (depending of the used characters).could you please send me example-files that fail, if possible ?
just sent
The reason is quite simple, I decided to also search for latin-2 encoding needed for langauges like Bosnian, Croatian, Czech, Hungarian, Polish, Romanian, Serbian (when in the Latin script), Slovak, Slovenian, Upper Sorbian, and Lower Sorbian, but it breaks some latin-1 encoded texts due to their similarity, not all and not always (depending of the used characters).
If I understood, the encoding is not saved into the file, so C::B tries to guess the right one when the file is opened. So when you add the latin-2 encoding, some latin-1 files are seen as latin-2, so some characters are displayed in a wrong way.
So I change the option Settings >> Editor >> General Settings >> Use This Encoding to "As default encoding", so the C::B's auto-detectionis bypassed, and this solved my problem.
If this is the situation, I think that your idea of the configuration-option is the easiest one: I'm afraid that detecting latin-1 from latin-2 is not easy...
Code:Blocks is an IDE & IMO we should try not to transform it to a Text Editor or a Browser.Amen. In addition what worries me: Most users don't even understand what "encoding" means and why detection has to fail using a wrong setup. For those it'll always be hard to find the right setup even with the option we have or the options Biplab is proposing. So we will always be claimed "somehow" as long as encoding exists. ;-)
If I understood, the encoding is not saved into the file, so C::B tries to guess the right one when the file is opened. So when you add the latin-2 encoding, some latin-1 files are seen as latin-2, so some characters are displayed in a wrong way.
So I change the option Settings >> Editor >> General Settings >> Use This Encoding to "As default encoding", so the C::B's auto-detectionis bypassed, and this solved my problem.
If this is the situation, I think that your idea of the configuration-option is the easiest one: I'm afraid that detecting latin-1 from latin-2 is not easy...
A file encoding is never saved to a file. At least I'm unaware of any widely popular method of storing file encoding data to a file. Reason is pretty simple. One need to strip that data (encoding detection data) before feeding it to another program. Or the other program should be aware of how to strip that data.
Most of the known software performs encoding detection by sampling data from file. There are BOM for UTF encoded file. But for other encoding sampling and measuring frequency of encoded characters is the only way to detect an encoding. Mozilla's encoding detection is an example of this.
For a large project with files encoded with a less popular encoding scheme will surely degrade Code:Blocks' performance. Precisely this was the reason Yiannis objected (long ago) to the inclusion of Mozilla's encoding detection code to trunk. IMHO it should be turned on as an Option only.
IMHO the solution should be to give user two option.
1) Use a simple encoding detection scheme (to detect most of the popular encodings).
2) Use Mozilla's code to detect encoding (we should make it very clear that this option may affect performance in some cases).
3) Don't detect encoding.
And to each of the above options Fallback Encoding options shall be-
a) Use System encoding.
b) Use User-provided encoding.
Code:Blocks is an IDE & IMO we should try not to transform it to a Text Editor or a Browser.
You are right, C::B is not a browser, but C::B is an IDE, so the editor is an important part, otherwise it would be not much more than a build-system like makefiles.
This might be different for some less popular (rare?) encoding schemes,as you wrote.
But in my opinion it is better to have a somewhat slower encoding-detection that works, than a fast detection, where the user has to force something to make it work.
The new encoding detection does the following:
- check for user-forced-encoding
- search bom
- try to detect uft16
- try to detect uft32
- try to detect ascii or extended ascci encoding like HZ-GB-2312, ISO-2022-CN
- or try to detect singlebyte, multibyte and latin1 charsets
The first four did not change with new encoding detection, ...
void setupGLUT(int *argc, char **argv, int winid[]) {
glutInit(argc, argv);
glutInitDisplayMode(GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE);
winid[0] = glutCreateWindow("OpenSG");
//winid[1] = glutCreateWindow("OpenSG2");
glutReshapeFunc(reshape);
glutDisplayFunc(display);
glutKeyboardFunc(keyboard);
glutSpecialFunc(keyboard_special);
glutIdleFunc(display);
}
template <class T>
struct C1
{
T obj;
};
struct C2
{
void func() {}
};
C1<C2> obj;
obj.obj.
#define DECLARE_SINGLE(Class) \
private:\
Class() {}\
~Class() {}\
Class(const Class &obj);\
Class& operator=(const Class &obj);\
public:\
Class& inst()\
{\
static Class obj;\
return obj;\
}
class SingletonTest
{
DECLARE_SINGLE(SingletonTest)
public:
void func() {}
};
SingletonTest::inst().
Who can say when C::B will have a modern codecompletion?Nobody.
Who can say when C::B will have a modern codecompletion? This functionality is very important in everyday work of programmer and I don't know when to expect it: a month, a year or never?Hi, critic, I have attempt to improve codecompletion, but for some reasons it is still not as good as I expect.
is there a way to disable the ".dll" for the lib name ???Search the forums.
ahh, so there is a way, I'll have a search, thx... ;)is there a way to disable the ".dll" for the lib name ???Search the forums.
another problem when creating a DLL...Since after a SVN version, it becomes the case.
let's say I'm compiling a DLL called "Irrlicht.dll", now the lib file is named "libIrrlicht.dll.a"...
but I don't want the ".dll" between "libIrrlicht" and ".a" !!!
now I either need to rename the lib manually or change the project settings for all my projects... :?
is there a way to disable the ".dll" for the lib name ???
Morten: can you see now that we do not like that behavior?...no?!
Morten: can you see now that we do not like that behavior?...no?!
The point is:
The behavior we had before did not work for the cases I told you. In addition users complained.
The behavior we have now works on all cases but is less "intuitive". In addition users complain.
So - what's the better choice? Make it an option? What's the default value then?
When the user wants to create a non-as-common-as-a-plain-.dll-file (like .Plugin),Notice that this was only *one* problem.
When the user wants to create a non-as-common-as-a-plain-.dll-file (like .Plugin),Notice that this was only *one* problem.
Even worse was if you tried to create a System.Management.DLL file. This did not work, too. And that's the one I was referring to at most. Because such misbehaviour is in fact not acceptable.
If I remember right, it was turned int "System.dll" .When the user wants to create a non-as-common-as-a-plain-.dll-file (like .Plugin),Notice that this was only *one* problem.
Even worse was if you tried to create a System.Management.DLL file. This did not work, too. And that's the one I was referring to at most. Because such misbehaviour is in fact not acceptable.
What was wrong with System.Management.DLL again? (I have forget only memory)
If I remember right, it was turned int "System.dll" .When the user wants to create a non-as-common-as-a-plain-.dll-file (like .Plugin),Notice that this was only *one* problem.
Even worse was if you tried to create a System.Management.DLL file. This did not work, too. And that's the one I was referring to at most. Because such misbehaviour is in fact not acceptable.
What was wrong with System.Management.DLL again? (I have forget only memory)
Output file name: System.Management (user input)Right - I should have been more precise: It's a wx function that tricks us so you cannot distinguish by a base file name "System.Management" whether it has an extension or not. Cause wx will report "Management" as extension. So is than the extension you want or do you need to add another ".dll"? How do you differ? What happened in the past was than if I enabled "auto ext" and put "System.Management" as file name it resulted not in System.Management.dll but in System.dll because we remove any existing extension before automatically adding the new one. If you don't do that a library called "system.dll" with "auto-ext" enabled would become "system.dll.dll" and again we surely will have complaints.
Output file name: System.Management (user input)Right - I should have been more precise: It's a wx function that tricks us so you cannot distinguish by a base file name "System.Management" whether it has an extension or not. Cause wx will report "Management" as extension. So is than the extension you want or do you need to add another ".dll"? How do you differ? What happened in the past was than if I enabled "auto ext" and put "System.Management" as file name it resulted not in System.Management.dll but in System.dll because we remove any existing extension before automatically adding the new one. If you don't do that a library called "system.dll" with "auto-ext" enabled would become "system.dll.dll" and again we surely will have complaints.
To make it short: If you see a way tat copes with all the cases correctly and looks "nice" - tell me or better just implement it. I just don't see any. All I did was at least making it functioning correctly because that has highest priority for me and not if the file names are "correct". Cause again: GCC handles the files just fine the way it is now.
Actually i changed my mind and i like this way.Thanks! You are the first saying so which makes me glad. I like it, too obviously. ;-)