Author Topic: FileManager: Version Control Browsing  (Read 29673 times)

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #15 on: February 11, 2015, 07:05:40 pm »
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.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: FileManager: Version Control Browsing
« Reply #16 on: February 11, 2015, 08:56:54 pm »
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...
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline blauzahn

  • Almost regular
  • **
  • Posts: 153
Re: FileManager: Version Control Browsing
« Reply #17 on: February 12, 2015, 10:21:35 pm »
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!


Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #18 on: February 12, 2015, 11:27:57 pm »
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.

Offline dmoore

  • Developer
  • Lives here!
  • *****
  • Posts: 1576
Re: FileManager: Version Control Browsing
« Reply #19 on: February 12, 2015, 11:32:32 pm »
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?
« Last Edit: February 13, 2015, 05:49:36 am by dmoore »

Offline blauzahn

  • Almost regular
  • **
  • Posts: 153
Re: FileManager: Version Control Browsing
« Reply #20 on: February 13, 2015, 06:46:21 am »
Quote
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?

Offline blauzahn

  • Almost regular
  • **
  • Posts: 153
Re: FileManager: Version Control Browsing
« Reply #21 on: February 13, 2015, 07:00:01 am »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: FileManager: Version Control Browsing
« Reply #22 on: February 13, 2015, 10:43:15 am »
I confirm the breakage. It happens in out-of-tree builds and only if using pch. If I specify --disable-pch it builds fine.
(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 Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: FileManager: Version Control Browsing
« Reply #23 on: February 13, 2015, 01:08:13 pm »
I have no issues building actual trunk (10118) out of tree, neither with pch, nor without pch.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: FileManager: Version Control Browsing
« Reply #24 on: February 13, 2015, 01:36:45 pm »
Probably it is something related to newer autotools, because it worked correctly on my CentOS 6 machine, but failed on my Gentoo machine.
(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 Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: FileManager: Version Control Browsing
« Reply #25 on: February 13, 2015, 08:20:31 pm »
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.

Offline blauzahn

  • Almost regular
  • **
  • Posts: 153
Re: FileManager: Version Control Browsing
« Reply #26 on: February 21, 2015, 08:24:58 am »
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.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7576
    • My Best Post
Re: FileManager: Version Control Browsing
« Reply #27 on: February 21, 2015, 02:00:59 pm »

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.





« Last Edit: February 21, 2015, 06:44:35 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7576
    • My Best Post
Re: FileManager: Version Control Browsing
« Reply #28 on: February 21, 2015, 04:56:28 pm »
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.
« Last Edit: February 21, 2015, 06:17:21 pm by stahta01 »
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org