The new Release 20.03 is out! You can download binaries for Windows and many major Linux distros here .
Quote from: jens on July 28, 2009, 04:24:26 pmQuote from: MortenMacFly on July 28, 2009, 03:18:40 pmQuote from: jens on July 28, 2009, 02:09:35 pmWe 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.
Quote from: MortenMacFly on July 28, 2009, 03:18:40 pmQuote from: jens on July 28, 2009, 02:09:35 pmWe 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.
Quote from: jens on July 28, 2009, 02:09:35 pmWe 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.
Quote from: Biplab on July 28, 2009, 04:48:39 pmQuote from: jens on July 28, 2009, 04:24:26 pmQuote from: MortenMacFly on July 28, 2009, 03:18:40 pmQuote from: jens on July 28, 2009, 02:09:35 pmWe 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 ?
Quote from: jens on July 28, 2009, 05:18:38 pmThomas ?Yes!!
Thomas ?
Quote from: Biplab on July 28, 2009, 05:20:09 pmQuote from: jens on July 28, 2009, 05:18:38 pmThomas ?Yes!!I just cried for him, so he can not overread it, if he looks through unread topics.
BUT: what did you do with the patch that saved me, about SDCC and static libs?
Quote from: MortenMacFly on July 28, 2009, 12:53:55 pmQuote from: Loaden on July 28, 2009, 10:32:15 amsvn 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.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; }
Quote from: Loaden on July 28, 2009, 10:32:15 amsvn 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.
svn build rev 5717 (2009-07-28T07: 15:12.319835 Z) gcc 4.4.1 Windows / unicode
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; }
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=5358RegardsS.B.
anyone already an idea on this regression ? wxAUi related ?
Apparently the bug was introduced in svn build 5678.
Quote from: killerbot on July 30, 2009, 04:04:35 pmanyone 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...?!
