FileManager: Version Control Browsing

[dmoore]

My 2 cents for today...:
1.) I don't understand the "favourites" system: I can setup favourites (that works nice), but how do I access them?

The first items in the ComboBox that shows the current path will be populated with your favorites. (It's a little clunky, I admit.)

...and m_exec_timer is "0xbaadf00d" -> unallocated.

Naaah... fixed in SVN.

You'd better remember to ALWAYS initialise pointer variables in the constructor in the future... ;-)

Well, that's embarrassing.

...but I'll give you another one: If in debug mode, a missing VCS executable will raise a wxExecute error dialog that freezes C::B completely.

Thanks for the tip. I had already refactored all of the wxExecute calls into a single place for the threaded parts and will do the same for the remaining calls.

[MortenMacFly]

The first items in the ComboBox that shows the current path will be populated with your favorites. (It's a little clunky, I admit.)

Aaah - dammed - I missed it. :-/ But if you know it makes sense. Maybe a "hint" like a label would help to discover...

[blauzahn]

Hi, nice idea but...the recent svn-changes are breaking my build :-(

I use Ubuntu 14.04 and compile the trunk via makefile quite regularly. That stopped 3 days ago.
It looks like this bug has been introduced by svn 10107 since I have a working 10106.

Compiling cb stops with:

Code

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../../../trunk/src/plugins/contrib/FileManager -I../../../../src/include -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../trunk/src/include -I../../../../../trunk/src/sdk/wxscintilla/include -I../../../../../trunk/src/include/mozilla_chardet -I../../../../../trunk/src/include/mozilla_chardet/mfbt -I../../../../../trunk/src/include/mozilla_chardet/nsprpub/pr/include -I../../../../../trunk/src/include/mozilla_chardet/xpcom -I../../../../../trunk/src/include/mozilla_chardet/xpcom/base -I../../../../../trunk/src/include/mozilla_chardet/xpcom/glue -ansi -DTIXML_USE_STL -Wno-unused-local-typedefs -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -D__FAM__ -MT FileExplorerUpdater.lo -MD -MP -MF .deps/FileExplorerUpdater.Tpo -c ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp  -fPIC -DPIC -o .libs/FileExplorerUpdater.o
In file included from ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp:9:0:
../../../../../trunk/src/plugins/contrib/FileManager/se_globals.h:10:17: fatal error: ../../../../src/include/sdk.h: No such file or directory
 #include <sdk.h>
                 ^
compilation terminated.
Preprocessed source stored into /tmp/ccirly8F.out file, please attach this to your bugreport.
make[4]: *** [FileExplorerUpdater.lo] Error 1

The file sdk.h exists in:

Code

codeblocks/trunk/src/plugins/contrib/FileManager$ ls -l ../../../include/sdk.h 
-rw-r--r-- 1 user user 457 Apr  2  2013 ../../../include/sdk.h

I always build cb in a directory named build that is parallel to the trunk directory. The plugins up to FileManager compile and the
file sdk.h.gch has been written as usual.

Can you fix this, please? Thank you!



Btw: A cppcheck over the plugin files yields several issues. A few of those might be of a help:

Code

cppcheck --verbose --enable=all *.h *.cpp

Code

[FileExplorerUpdater.h:44]: (warning) Member variable 'Updater::m_exec_cond' is not initialized in the constructor.

Is there a reason why you put initializations, if any, into the body instead of the initializer list?

Code

[FileExplorerUpdater.cpp:1410]: (error) Uninitialized variable: hg_not_done

Code

  bool hg_not_done;
  if (m_repo_type == _T("Hg"))
  {
      long last;
      if (m_last_commit_retrieved.ToLong(&last))
          if (last > 0)
              hg_not_done = true;
  }
  if (hg_not_done)
      m_retrieved_all = false;

This is definitely undefined behaviour.

Code

[FileExplorer.cpp:1340] -> [FileExplorer.cpp:1340]: (style) Finding 
  the same expression on both sides of an operator 
  is suspicious and might indicate a cut and paste 
  or logic error. Please examine this code carefully to determine if it is correct.

Code

 if(!wxFileName::DirExists(mkd) &&!wxFileName::DirExists(mkd))

To me this looks being unintended.

Code

[directorymonitor.cpp:621]: (warning) Possible leak in public function. 
  The pointer 'm_monitorthread' is not deallocated before it is allocated.

Code

bool wxDirectoryMonitor::Start()
{
    m_monitorthread=new DirMonitorThread(this, m_uri, false, false, m_eventfilter, 100);
    m_monitorthread->Create();
    m_monitorthread->Run();
    return true;
}

Since Start is a public method, and m_monitorthread is a naked pointer this is not safe.


Thanks!

[dmoore]

Thanks for all of the fixes. A few oopses in there  

Maybe I'm being dense but I'm not sure what the problem here is

I use Ubuntu 14.04 and compile the trunk via makefile quite regularly. That stopped 3 days ago.
It looks like this bug has been introduced by svn 10107 since I have a working 10106.

Compiling cb stops with:

Code

libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../../../../trunk/src/plugins/contrib/FileManager -I../../../../src/include -I/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../trunk/src/include -I../../../../../trunk/src/sdk/wxscintilla/include -I../../../../../trunk/src/include/mozilla_chardet -I../../../../../trunk/src/include/mozilla_chardet/mfbt -I../../../../../trunk/src/include/mozilla_chardet/nsprpub/pr/include -I../../../../../trunk/src/include/mozilla_chardet/xpcom -I../../../../../trunk/src/include/mozilla_chardet/xpcom/base -I../../../../../trunk/src/include/mozilla_chardet/xpcom/glue -ansi -DTIXML_USE_STL -Wno-unused-local-typedefs -O2 -ffast-math -DCB_AUTOCONF -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -D__FAM__ -MT FileExplorerUpdater.lo -MD -MP -MF .deps/FileExplorerUpdater.Tpo -c ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp  -fPIC -DPIC -o .libs/FileExplorerUpdater.o
In file included from ../../../../../trunk/src/plugins/contrib/FileManager/FileExplorerUpdater.cpp:9:0:
../../../../../trunk/src/plugins/contrib/FileManager/se_globals.h:10:17: fatal error: ../../../../src/include/sdk.h: No such file or directory
 #include <sdk.h>
                 ^
compilation terminated.
Preprocessed source stored into /tmp/ccirly8F.out file, please attach this to your bugreport.
make[4]: *** [FileExplorerUpdater.lo] Error 1

The file sdk.h exists in:

Code

codeblocks/trunk/src/plugins/contrib/FileManager$ ls -l ../../../include/sdk.h 
-rw-r--r-- 1 user user 457 Apr  2  2013 ../../../include/sdk.h

I always build cb in a directory named build that is parallel to the trunk directory. The plugins up to FileManager compile and the
file sdk.h.gch has been written as usual.

Comparing the makefiles, it's really not obvious to me what's different.

[dmoore]

And looking at the makefile diff, I struggle to see how anything changed there can be the cause:

http://sourceforge.net/p/codeblocks/code/10107/tree//trunk/src/plugins/contrib/FileManager/Makefile.am?diff=51421f1dc431436b6eb31d56:10106

Are you sure there isn't some sort of corruption of the FileManager sources?

[blauzahn]

Are you sure there isn't some sort of corruption of the FileManager sources?

Yes I am. I downloaded a fresh, vanilla trunk into a newly created empty directory. Same result.

Code

mkdir tmp
cd tmp
svn checkout svn://svn.code.sf.net/p/codeblocks/code/trunk
cd trunk
./bootstrap
cd ..
mkdir build
cd build
../trunk/configure --prefix=/usr/local --with-contrib-plugins=all,-NassiShneiderman
make

I do not see either a thing within the Makefile.am diff that may have caused that. What else?

[blauzahn]

If I skip the FileManager, the code compiles cleanly:

Code

 ../trunk/configure --prefix=/usr/local --with-contrib-plugins=all,-NassiShneiderman,-FileManager
make -j

The breaking change might also be introduced by a version higher than 10107. Haven't bisected it yet.

[oBFusCATed]

I confirm the breakage. It happens in out-of-tree builds and only if using pch. If I specify --disable-pch it builds fine.

[Jenna]

I have no issues building actual trunk (10118) out of tree, neither with pch, nor without pch.

[oBFusCATed]

Probably it is something related to newer autotools, because it worked correctly on my CentOS 6 machine, but failed on my Gentoo machine.

[Jenna]

It tested it on my Fedora 21 system and did a build in mock chroots for CentOS 5 to 7 and Fedora 19 to Rawhide (22) (sse: https://copr.fedoraproject.org/coprs/jenslody/codeblocks/build/71814/).
For the record: the copr-builds are all build without pch's and not out of tree.

[blauzahn]

I solved the problem I had compiling the plugin starting exactly from version r10107 upwards.

If I change the include-order it works. I changed the first lines of FileExplorerUpdater.cpp from:

Code

#include <sdk.h>

#include <wx/sstream.h>
#include <wx/regex.h>
#include <set>

#include "FileExplorerUpdater.h"
#include "FileExplorer.h"
#include "se_globals.h"

to:

Code

#include "FileExplorerUpdater.h"
#include "FileExplorer.h"
#include "se_globals.h"

#include <sdk.h>
#include <wx/sstream.h>
#include <wx/regex.h>
#include <set>

The main point is to move sdk.h downwards. This should be fixed in trunk. Thanks!

And another point, where the dependency can be reduced: in FileManager.h there is no need to include FileExplorer.h. Instead
a forward declaration is sufficient. The include can be moved into FileManager.cpp instead.

IMHO, the include order should follow advices of:
* Herb Sutter (C++ Coding Standards §22: "Minimize definional dependencies.[...]",
* Herb Sutter (C++ Coding Standards §23: "Make header files self-sufficient" and
 * John Lakos (Large Scale C++ Software Design: Major Design Rule "The .c[pp] file of every component should include
   its own .h file as the first substantial line of code."

Therefore, I personally would prefer the #include order.

own header
plugin
cb
wx
std

The interference with pre-compiled header is another story.

[stahta01]

IMHO, the include order should follow advices of:
* Herb Sutter (C++ Coding Standards §22: "Minimize definional dependencies.[...]",
* Herb Sutter (C++ Coding Standards §23: "Make header files self-sufficient" and
 * John Lakos (Large Scale C++ Software Design: Major Design Rule "The .c[pp] file of every component should include
   its own .h file as the first substantial line of code."

Therefore, I personally would prefer the #include order.

own header
plugin
cb
wx
std

The interference with pre-compiled header is another story.

I prefer this order

PCH
std
wx
cb
own header

Last time I checked this header had issues "se_globals.h" so moving it till just below sdk.h might be needed till the issues are fixed.

When I have time I will see if I can submit a patch on the headers in FileManager CB Plugin.

Tim S.

[stahta01]

Quick patch that needs more testing.

https://github.com/stahta01/cb_misc/blob/master/Patches/svn/cb_PCH_FileManager.patch

Builds on Windows 7 64 Bit using 32 bit TDM GCC.
Tested both wx30 and wx28 builds.

Yes, I have finally confirmed that GCC on Linux acts like MinGW GCC and needs an include to the object folder to work.

Tested on Debian Wheezy 64 bit (wx28) it took about 30+ seconds to build without patch about 15 seconds with patch.
(The patch includes both the one linked above and the one in the code below).

Code

Index: src/plugins/contrib/FileManager/FileManager-unix.cbp
===================================================================
--- src/plugins/contrib/FileManager/FileManager-unix.cbp	(revision 10123)
+++ src/plugins/contrib/FileManager/FileManager-unix.cbp	(working copy)
@@ -44,6 +44,7 @@
 			<Add option="-DcbDEBUG" />
 			<Add option="-DCB_PRECOMP" />
 			<Add option="-D__FAM__" />
+			<Add directory="../../../.objs/include" />
 			<Add directory="../../../include" />
 			<Add directory="../../../sdk/wxscintilla/include" />
 			<Add directory="../../../include/mozilla_chardet" />

Edit2: I plan to test Debian wxWidgets 3.0 branch once I get it built. My Internet connection is very slow today so it might be a while before I get the git checkout done.

Tim S.