Author Topic: The 27 October 2014 build (10016) is out.  (Read 77938 times)

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: The 27 October 2014 build (10016) is out.
« Reply #30 on: November 05, 2014, 07:54:29 pm »
I made some changes on 10/29/2014 that might fix this.
Either update your svn or wait for the next nightly.

Please let us know if the 10/29 revert fixes the problem.

What version of CB (before 10/27) worked for you?

In, any case, I'll look into it.

Could you give me the exact steps to cause the problem.

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: The 27 October 2014 build (10016) is out.
« Reply #31 on: November 06, 2014, 12:22:18 am »
svn rev 10020 still exhibits the same problem. Unfortunately I couldn't find a working build after checking all the nightlies I have (back to rev 9673).

Steps to reproduce:
1- Launch cb, see the 'debugging windows' bindings are there before loading a project,
2- Load a project,
3- Check again to see the bindings are gone.

Some older revisions doesn't change 'cbkeybinder10.ini' file after closing cb even though the bindings are not listed on the shortcuts dialog, they don't work either. But latest nightlies change the file to add the targets of the opened project.

Offline gd_on

  • Lives here!
  • ****
  • Posts: 796
Re: The 27 October 2014 build (10016) is out.
« Reply #32 on: November 06, 2014, 02:47:24 pm »
There is a side effect problem introduced in autorevision.cpp in svn 10011.
I have a unix machine which does not have access to internet. The file autorevision.h has been correctly set on another one, and I copy it (with many others !) on this isolated unix machine.
But when I build C::B on this isolated machine, autorevision.h is modified by the task autorevision with a svn number 0, an unknown date ....
If I reset the test at line 240 with >= as it was before svn 10011, my autorevision.h file is not modified, and it's what I need on this isolated machine.

gd_on
« Last Edit: November 06, 2014, 03:28:21 pm by gd_on »
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 October 2014 build (10016) is out.
« Reply #33 on: November 06, 2014, 03:16:15 pm »
I can confirm this issue, either building from a git checkout or using release tar.bz2 file generated with make dist results in "svn 0" in the splashscreen.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline gd_on

  • Lives here!
  • ****
  • Posts: 796
Re: The 27 October 2014 build (10016) is out.
« Reply #34 on: November 06, 2014, 04:31:06 pm »
Also, bugs in BrowseTracker_wx30.cbp and BrowseTracker_wx30_64.cbp.
ExtraCommands add manifest.xml, the folder images and a .xrc file in /devel... It should be, I think, respectively in /devel30... and /devel30_64...
With those corrections, BrowseTracker toolbar is correct. As it was, it's a too large and empty toolbar.

gd_on
« Last Edit: November 06, 2014, 04:43:47 pm by gd_on »
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: The 27 October 2014 build (10016) is out.
« Reply #35 on: November 06, 2014, 07:53:11 pm »
Does this work better?
Code
diff --git a/src/build_tools/autorevision/autorevision.cpp b/src/build_tools/autorevision/autorevision.cpp
index b0220b6..514ebd7 100644
--- a/src/build_tools/autorevision/autorevision.cpp
+++ b/src/build_tools/autorevision/autorevision.cpp
@@ -227,17 +227,17 @@ bool QuerySvn(const string& workingDir, string& revision, string &date)
 
 bool WriteOutput(const string& outputFile, string& revision, string& date)
 {
-    string old;
-    string comment("/*");
-    comment.append(revision);
-    comment.append("*/");
-
     {
         ifstream in(outputFile.c_str());
         if (!in.bad() && !in.eof())
         {
+            string old;
             in >> old;
-            if(old == comment)
+            int oldRev = 0;
+            size_t pos = old.find('*');
+            if (pos != string::npos)
+                oldRev = atoi(old.c_str() + pos + 1);
+            if(oldRev >= atoi(revision.c_str()))
             {
                 if(be_verbose)
                     printf("Revision unchanged (%s). Skipping.", revision.c_str());
@@ -256,7 +256,7 @@ bool WriteOutput(const string& outputFile, string& revision, string& date)
         return false;
     }
 
-    fprintf(header, "%s\n", comment.c_str());
+    fprintf(header, "/*%s*/\n", revision.c_str());
     fprintf(header, "//don't include this header, only configmanager-revision.cpp should do this.\n");
     fprintf(header, "#ifndef AUTOREVISION_H\n");
     fprintf(header, "#define AUTOREVISION_H\n\n\n");

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 27 October 2014 build (10016) is out.
« Reply #36 on: November 06, 2014, 10:29:53 pm »
Same effect with less conversion, even if it should not matter much as it happens only one time:
Code
commit e2e7ed0e50fc1843cb0ae77cafd82f07305695cb
Author: Jens Lody <jens@codeblocks.org>
Date:   Thu Nov 6 22:26:28 2014 +0100

    * fix for commit 10011, which could lead to revision string "0"

Index: src/build_tools/autorevision/autorevision.cpp
===================================================================
--- src/build_tools/autorevision/autorevision.cpp
+++ src/build_tools/autorevision/autorevision.cpp
@@ -237,10 +237,12 @@
         if (!in.bad() && !in.eof())
         {
             in >> old;
-            if(old == comment)
+            size_t l_old = old.length();
+            size_t l_comment = comment.length();
+            if(l_old > l_comment || ((l_old == l_comment) && old >= comment))
             {
                 if(be_verbose)
-                    printf("Revision unchanged (%s). Skipping.", revision.c_str());
+                    printf("Revision unchanged or older (%s). Skipping.", revision.c_str());
                 in.close();
                 return false;
             }
« Last Edit: November 06, 2014, 10:35:16 pm by jens »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 October 2014 build (10016) is out.
« Reply #37 on: November 07, 2014, 12:28:14 am »
@gd_on: the two patches are in svn now...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 October 2014 build (10016) is out.
« Reply #38 on: November 07, 2014, 09:08:58 am »
@ollydbg: I've done some bisecting and r9931 seems to be the last working revision. r9932 is broken.
I still can't reproduce the issue in my system. :'(
As a workaround, you can just try to comment out the line "HandleMacroExpansion(id, peek);", thus disable the macro expansion for the first meet token, and see whether the issue happens again.
I have a local patch which only handles macro expansion in the Tokenizer level(low level), but not in the ParserThread level(high level), but that involves too many code changes......
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline gd_on

  • Lives here!
  • ****
  • Posts: 796
Re: The 27 October 2014 build (10016) is out.
« Reply #39 on: November 07, 2014, 09:20:36 am »
@oBFusCATed : Thanks
@jens and Alpha : I tried your two patches. Both give me the "good" result on the isolated machine : svn number not modified in my autorevision.h file and this is what I expected.
So, it's up to you to choose which one is better than the other. May be jens's one is a little bit shorter... and less conversion.

gd_on
Windows 11 64 bits (23H2), svn C::B (last version or almost!), wxWidgets 3.2.4 (tests with 3.3), Msys2 Compilers 13.2.0, 64 bits (seh, posix : gcc, g++ and gfortran in C:\msys64\mingw64) or 32 bits (dwarf2, posix  in C:\msys64\mingw32).

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: The 27 October 2014 build (10016) is out.
« Reply #40 on: November 07, 2014, 04:15:26 pm »
@jens, less work is generally better; go ahead and commit.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 27 October 2014 build (10016) is out.
« Reply #41 on: November 07, 2014, 08:35:27 pm »
@jens, less work is generally better; go ahead and commit.
In svn (r10029).
I build the new revision and try to upload it, but it might not be possible before monday, because my provider will switch internet off this night (don't know the exact time) and I will not have any internet access until monday (at least).

Offline wab

  • Single posting newcomer
  • *
  • Posts: 4
Auto-generated files path are not used when added to project
« Reply #42 on: November 10, 2014, 02:27:31 pm »
I found a tiny bug, or non finished functionality.

Settings -> Compiler... -> Global Compiler Settings -> Other Settings -> Advanced Options... -> Commands:

1. Add new "Source ext.": ui
2. Field "Command" stay on "Compile single file to object file"
3. "Command line macro": $(#qt5.uic) -o "Src/GeneratedFiles/ui_$file_name.h" "$file"
4. "Generated files (to be further compiled)": Src/GeneratedFiles/ui_$file_name.h

So, when I'm add "Src/Kreator/somefile.ui" to project and make rebuild then:
a. File is generated inside right path: Src/GeneratedFiles/ui_somefile.h
b. CodeBlocks always put fixed position of "Auto-generated" path in window "Management -> Projects" to: "Src/Kreator/ui_somefile.h"
c. Because my ui_somefile.h is into "Src/GeneratedFiles/ui_somefile.h" - compiler cannot find it

(First solution) For working well I need to change:
ch.3. "Command line macro": $(#qt5.uic) -o "ui_$file_name.h" "$file"
ch.4. "Generated files (to be further compiled)": ui_$file_name.h

(Second solution) Or for alternative working well solution I need to change:
ch.3. "Command line macro": $(#qt5.uic) -o "Src\Kreator\ui_$file_name.h" "$file"
ch.4. "Generated files (to be further compiled)": Src\Kreator\ui_$file_name.h


But it is really mess when I have all generated files into main folder (first solution) or in folder of my source file Src\Kreator\* (second solution).
Auto-generated files for new extensions always put same directory as source. So first solution shouldn't work at all, but it work well :-).

So either I cannot configure this Code::Blocks functionality or it doesn't work like it should.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 October 2014 build (10016) is out.
« Reply #43 on: November 15, 2014, 01:04:25 pm »
Debugged a while, I found the reason why this bug happens, but I don't have a clean way to fix this issue.
See, the CC setting was stored in configure file.
When C::B start up, CC will create a default parser object called "temp parser".
When a parser object is created, it will copy the settings(such as the "Case sensitive matches") from the configure file to its own member variable.
When you open the CC dialog, the active parser object's setting will be modified also the CC related setting in configure files will get updated. This means, the configure file contains the active parser's settings.

When a CB project loaded, a new parser object(we call "new parser" here) is created and activated. So far, so good. When you changed the CC setting, both the "new parser"'s setting and the configure file get updated.

The issue comes when you close C::B, which means, you need to
1, destroy "new parser"
2, destroy "temp parser"

When destroy "new parser", all its setting was saved, but after that, the active parser switches to "temp parser", the setting in "temp parser" was active, and finally the "temp parser" get destroyed, its setting was saved (not the "new parser"), so your setting was lost!

I have not a good idea to fix this issue. Say, we have a setting shared by several parser objects. But they may be different, but the last destroyed parser's setting will be saved to the configure file.
Any plans to fix this issue? If not please say so, so I can take a look at it ...  it is quite annoying...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

ToApolytoXaos

  • Guest
Re: The 27 October 2014 build (10016) is out.
« Reply #44 on: November 15, 2014, 03:49:11 pm »
Apologies if I have asked again in the past: is it possible to add the same feature Find declaration... with Ctrl+mouse hover hotkeys?

I use NetBeans a lot for web development (Java as well) and find this feature quite appealing; it helps tremendously while looking for certain information about a class or member function.

How difficult is it to implement it?