A multi-platform collection of C++ software libraries for Computer Vision and Image Understanding.
Home Page: https://sf.net/projects/vxl/
VXL (the Vision-something-Libraries) is a collection of C++ libraries designed for computer vision research and implementation. It was created from TargetJr and the IUE with the aim of making a light, fast and consistent system. VXL is written in ANSI/ISO C++ and is designed to be portable over many platforms. The core libraries in VXL are:
A comprehensive description of the VXL project can be viewed at https://vxl.github.io/
This issue should remain open until all the tests are commented back in.
From: Hans Johnson [email protected]
Date: Wednesday, December 9, 2015 at 4:13 PM
To: Octavian Biris [email protected]
Subject: Re: VXL test failures
PRUNING IS GOOD! Any pruning you can do will greatly improve the software.
I would really like to get to all test passing. Removing tests that are no longer meaningful is the quickest way to do that.
Can you please do the pruning?
Thanks,
Hans
From: Octavian Biris [email protected]
Date: Wednesday, December 9, 2015 at 3:51 PM
To: Hans Johnson [email protected]
Subject: Re: VXL test failures
I don't have access to a mac machine so I can't assess the status of those tests. Most of them are legacy and will require some pruning.
On Wed, Dec 9, 2015 at 4:18 PM, Johnson, Hans J [email protected] wrote:
Octavian,
Thank you! I ran test this morning, and this afternoon. It represents pre-and post your patch set changes (along with other changes in the repository today).
It appears that there is a new test failure boxm_util_test_plane_ransac
It also appears that many of the boxm2 tests are still failing with the clang compiler.
It should be noted that on mac with the clang compiler that unitialized variables are often NOT set to 0’s, and that the gcc compiler often does set uninitialized variables to 0’s. The standard does NOT require that uninitialized variables are set to zero.
The attached patch was my start at trying to fix this problem, but I quickly realized that I could not understand the code at a level necessary to make reasonable default values.
PRE-FAILURES: The following tests FAILED:
x156 - vgl_test_cartesian (Failed)
FIX258 - vil1_test_file_format_read (Failed)
FIX688 - bsta_algo_test_mean_shift (Failed)
FIX694 - bsta_test_histogram_io (Failed)
FIX813 - sdet_test_sel (Failed)
x714 - bocl_test_command_queue (SEGFAULT)
x793 - volm_test_find_overlapping (Failed)
x832 - bvxm_pro_test_rpc_registration_process (SEGFAULT)
x886 - boxm2_test_merge_function (Failed)
x887 - boxm2_ocl_pro_test_filter_kernel (SEGFAULT)
x892 - boxm2_ocl_test_kernel_filter (Failed)
x893 - boxm2_ocl_test_kernel_vector_filter (Failed)
x915 - boxm2_test_io (Timeout)
POST-FAILURES The following tests FAILED:
x156 - vgl_test_cartesian (Failed)
x714 - bocl_test_command_queue (SEGFAULT)
x793 - volm_test_find_overlapping (Failed)
x832 - bvxm_pro_test_rpc_registration_process (SEGFAULT)
NEW859 - boxm_util_test_plane_ransac (Failed)
x886 - boxm2_test_merge_function (Failed)
x887 - boxm2_ocl_pro_test_filter_kernel (SEGFAULT)
x892 - boxm2_ocl_test_kernel_filter (Failed)
x893 - boxm2_ocl_test_kernel_vector_filter (Failed)
x915 - boxm2_test_io (Timeout)
Hans
From: Octavian Biris [email protected]
Date: Wednesday, December 9, 2015 at 11:45 AM
To: Hans Johnson [email protected]
Subject: Re: VXL test failures
Hans,
I have committed the fixes for these tests. They were conceptually wrong to begin with as a result of a functionality change in the boxm2_block_class that never got carried over to the tests . This required some modifications to the underlying classes in order to have the tests work and pass as expected. Let me know if the tests succeed on your machine
Best,
-Octavian
On Sat, Nov 28, 2015 at 3:59 PM, Johnson, Hans J [email protected] wrote:
The test that I was tracking down was boxm2_test_cache and boxm2_test_cache2.
But there are also failures in boxm_test_io
It is failing on both a gcc 4.9 build on linux and a clang build on mac.
It feels like perhaps some variables are not being explicitly initialized, and that perhaps when they are lucky enough to get a starting point of zero that it works.
Hans
From: Octavian Biris [email protected]
Date: Friday, November 27, 2015 at 1:15 PM
To: Hans Johnson [email protected]
Subject: Re: VXL test failures
Which tests are in question? That line is required for boxm2_cache to work properly and safely. Let me know which tests fail and I will look into it.
Best,
-Octavian
On Fri, Nov 27, 2015 at 1:56 PM, Johnson, Hans J [email protected] wrote:
Octavian,
The command "this->trees().begin()"
On line 45 is causing a segmentation fault.
I also think that this should not be
boxm2_block::uchar16*
But rather:
boxm2_array_3d::const_iterator
Hans
From: Hans Johnson [email protected]
Date: Friday, November 27, 2015 at 12:36 PM
To: "[email protected]" [email protected]
Subject: VXL test failures
Octavian,
This commit isis caussing many tests to fail on multiple platforms. If I remove these 3 lines, then the tests begin to pass.
commit 4af9d00
Author: Octavian Biris [email protected]
Date: Thu Jul 16 12:18:22 2015
Protected boxm2_block tree array, changed the way ocl cache retrieves data
If I remove these 3 lines, then the tests begin to pass.
diff --git a/contrib/brl/bseg/boxm2/boxm2_block.cxx b/contrib/brl/bseg/boxm2/boxm2_block.cxx
index 3279984..fd10d96 100644
--- a/contrib/brl/bseg/boxm2/boxm2_block.cxx
+++ b/contrib/brl/bseg/boxm2/boxm2_block.cxx
@@ -12,7 +12,7 @@ boxm2_block::boxm2_block(boxm2_block_id id, char* buff): version_(1)
buffer_ = buff;
this->b_read(buff);
read_only_ = true;
boxm2_block::boxm2_block(boxm2_block_id id, boxm2_block_metadata data, char* buffer)
@@ -28,7 +28,7 @@ boxm2_block::boxm2_block(boxm2_block_id id, boxm2_block_metadata data, char* buf
buffer_ = buffer;
this->b_read(buffer_);
read_only_ = true;
boxm2_block::boxm2_block(boxm2_block_metadata data)
@@ -37,7 +37,7 @@ boxm2_block::boxm2_block(boxm2_block_metadata data)
block_id_ = data.id_;
this->init_empty_block(data);
read_only_ = false; // make sure that it is written back to disc
Regards,
Hans
Valgrind does not support "long double", so we need to make a suppression for it.
These are false positives due to the lack of long-double support in valgrind.
UMC ==62329== Conditional jump or move depends on uninitialised value(s)
==62329== at 0x38C7A81B96: std::ostreambuf_iterator<char, std::char_traits > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits > >::_M_insert_int(std::ostreambuf_iterator<char, std::char_traits >, std::ios_base&, char, long) const (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x38C7A81E25: std::num_put<char, std::ostreambuf_iterator<char, std::char_traits > >::do_put(std::ostreambuf_iterator<char, std::char_traits >, std::ios_base&, char, long) const (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x38C7A9543D: std::ostream& std::ostream::_M_insert(long) (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x567F3C: std::string print_hex(long double) (test_math.cxx:24)
==62329== by 0x562283: test_math() (test_math.cxx:330)
==62329== by 0x566492: test_math_main(int, char**) (test_math.cxx:593)
==62329== by 0x576694E: testlib_run_test_unit(unsigned long, int, char**) (testlib_main.cxx:95)
==62329== by 0x5766F16: testlib_main(int, char**) (testlib_main.cxx:146)
==62329== by 0x4615AB: main (test_driver.cxx:92)
==62329==
UMR ==62329== Use of uninitialised value of size 8
==62329== at 0x38C7A7D6F8: ??? (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x38C7A81BC2: std::ostreambuf_iterator<char, std::char_traits > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits > >::_M_insert_int(std::ostreambuf_iterator<char, std::char_traits >, std::ios_base&, char, long) const (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x38C7A81E25: std::num_put<char, std::ostreambuf_iterator<char, std::char_traits > >::do_put(std::ostreambuf_iterator<char, std::char_traits >, std::ios_base&, char, long) const (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x38C7A9543D: std::ostream& std::ostream::_M_insert(long) (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x567F3C: std::string print_hex(long double) (test_math.cxx:24)
==62329== by 0x562283: test_math() (test_math.cxx:330)
==62329== by 0x566492: test_math_main(int, char**) (test_math.cxx:593)
==62329== by 0x576694E: testlib_run_test_unit(unsigned long, int, char**) (testlib_main.cxx:95)
==62329== by 0x5766F16: testlib_main(int, char**) (testlib_main.cxx:146)
==62329== by 0x4615AB: main (test_driver.cxx:92)
==62329==
UMC ==62329== Conditional jump or move depends on uninitialised value(s)
==62329== at 0x38C7A7D6FE: ??? (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x38C7A81BC2: std::ostreambuf_iterator<char, std::char_traits > std::num_put<char, std::ostreambuf_iterator<char, std::char_traits > >::_M_insert_int(std::ostreambuf_iterator<char, std::char_traits >, std::ios_base&, char, long) const (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x38C7A81E25: std::num_put<char, std::ostreambuf_iterator<char, std::char_traits > >::do_put(std::ostreambuf_iterator<char, std::char_traits >, std::ios_base&, char, long) const (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x38C7A9543D: std::ostream& std::ostream::_M_insert(long) (in /usr/lib64/libstdc++.so.6.0.13)
==62329== by 0x567F3C: std::string print_hex(long double) (test_math.cxx:24)
==62329== by 0x562283: test_math() (test_math.cxx:330)
==62329== by 0x566492: test_math_main(int, char**) (test_math.cxx:593)
==62329== by 0x576694E: testlib_run_test_unit(unsigned long, int, char**) (testlib_main.cxx:95)
==62329== by 0x5766F16: testlib_main(int, char**) (testlib_main.cxx:146)
==62329== by 0x4615AB: main (test_driver.cxx:92)
I encountered the following linking error with MSVC 2015. It is missing instantiation file for vnl_sym_matrix< vcl_complex >, as needed by commit c68bf93.
10>test_complexify.obj : error LNK2019: unresolved external symbol "public: class vnl_sym_matrix<class std::complex > & __cdecl vnl_sym_matrix<class std::complex >::update(class vnl_sym_matrix<class std::complex > const &,unsigned int)" (?update@?$vnl_sym_matrix@V?$complex@M@std@@@@QEAAAEAV1@AEBV1@I@Z) referenced in function "public: __cdecl vnl_sym_matrix<class std::complex >::vnl_sym_matrix<class std::complex >(class vnl_sym_matrix<class std::complex > const &)" (??0?$vnl_sym_matrix@V?$complex@M@std@@@@qeaa@AEBV0@@z)
10>D:\Code\vxl\bin-vc14-x64\core\vnl\tests\Debug\vnl_test_all.exe : fatal error LNK1120: 1 unresolved externals
The nightly "VXL Nightly Date Stamp" commits seem like unnecessary noise in the commit messages.
commit f2f0bf1
Author: Kitware Robot [email protected]
Date: Fri Jan 8 00:01:23 2016 -0500
VXL Nightly Date Stamp
Is there a rational for having this in a git based source code repository?
If not, could we remove it?
@AJ
From: http://stackoverflow.com/questions/2404115/is-auto-ptr-deprecated
/scratch/johnsonhj/src/vxl/vcl/tests/test_memory.cxx:24:43: warning: ‘auto_ptr’ is deprecated (declared at /opt/rh/devtoolset-3/root/usr/include/c++/4.9.1/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
static vcl_auto_ptr generate_auto_ptr () { return vcl_auto_ptr(new A); }
^
/scratch/johnsonhj/src/vxl/vcl/tests/test_memory.cxx: In function ‘std::auto_ptr generate_auto_ptr()’:
/scratch/johnsonhj/src/vxl/vcl/tests/test_memory.cxx:24:75: warning: ‘auto_ptr’ is deprecated (declared at /opt/rh/devtoolset-3/root/usr/include/c++/4.9.1/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
static vcl_auto_ptr generate_auto_ptr () { return vcl_auto_ptr(new A); }
^
/scratch/johnsonhj/src/vxl/vcl/tests/test_memory.cxx: In function ‘int test_memory_main(int, char**)’:
/scratch/johnsonhj/src/vxl/vcl/tests/test_memory.cxx:32:21: warning: ‘auto_ptr’ is deprecated (declared at /opt/rh/devtoolset-3/root/usr/include/c++/4.9.1/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
vcl_auto_ptr pa0;
^
/scratch/johnsonhj/src/vxl/vcl/tests/test_memory.cxx:33:24: warning: ‘auto_ptr’ is deprecated (declared at /opt/rh/devtoolset-3/root/usr/include/c++/4.9.1/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
vcl_auto_ptr pa1(new A());
^
/scratch/johnsonhj/src/vxl/vcl/tests/test_memory.cxx:35:24: warning: ‘auto_ptr’ is deprecated (declared at /opt/rh/devtoolset-3/root/usr/include/c++/4.9.1/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
vcl_auto_ptr pa2(new B());
^
/scratch/johnsonhj/src/vxl/vcl/tests/test_memory.cxx:36:28: warning: ‘auto_ptr’ is deprecated (declared at /opt/rh/devtoolset-3/root/usr/include/c++/4.9.1/backward/auto_ptr.h:87) [-Wdeprecated-declarations]
vcl_auto_ptr pa3(pb1);
^
Build failures
You have a space in the path name "My Test", so perhaps this is not yet updated dashboard.
builds are failing:
https://open.cdash.org/viewBuildError.php?buildid=4224187
When you make the commit, include "resolves #158" in the commit message to close this issue.
In recent commit '3223fb2', old EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH were replaced by new CMAKE_LIBRARY_OUTPUT_DIRECTORY, CMAKE_ARCHIVE_OUTPUT_DIRECTORY and CMAKE_RUNTIME_OUTPUT_DIRECTORY.
EXECUTABLE_OUTPUT_PATH and LIBRARY_OUTPUT_PATH enable user to specify appropriate paths during configuration to store all built executable and static libraries, e.g., ${vxl_BINARY_DIR}/exe and ${vxl_BINARY_DIR}/lib.
In current configuration, CMAKE_LIBRARY_OUTPUT_DIRECTORY is ${vxl_BINARY_DIR}/lib by default, same as previous LIBRARY_OUTPUT_PATH. But this default setting doesn't not work and there is no option for user to specify the executable_output_path.
All the built library files and executables are in their individual location. For example, compiled vgl lib is in ${vxl_BINARY_DIR}/core/vgl/libvgl.a and compiled vgl_test executable is in ${vxl_BINARY_DIR}/core/vgl/tests/vgl_test_all
This is a big issue that need some careful consideration and consistency across several tools.
This community is closely linked with ITK, VTK, and VXL, so we should consider a coding style that has similarities across these domains.
Some good discussions:
Hans
I am running cmake 2.8.11 on CentOS 7, and can no longer get cmake to make vxl.
EXPORT_LINK_INTERFACE_LIBRARIES from here does not appear to be supported until cmake 2.8.12
This is a significantly troublesome version threshold, since the entire RHEL/CentOS 7 community does not have access to Cmake pass 2.8.11
From Brad King: In vnl, min/max values for long types are hardcoded to
assume 32bits. It should be possible to construct almost all the
values with tryrun programs during the configuration process, but
that may be overkill for now.
A deprecated function is currently being depended on. The entire jpeg infrastructure needs to be reconsidered, updated, and use of deprecated functions removed.
991 #if 0 // There is no need to report this warning. It just makes the dashboard noisy.
992 // If we explcitly set USE_OPJ_DEPRECATED to on, then we have determined that we
993 // want to use the deprecated function, and we should not warn about it.
994 //
995 #ifdef USE_OPJ_DEPRECATED
996 #ifdef _MSC_VER
997 #pragma message ("warning, opj_setup_encoder is deprecated")
998 #else
999 #warning "warning, opj_setup_encoder is deprecated"
1000 #endif
1001 #endif
There was an error where these tests were all given the same name, and therefore many of them were not being run.
The following tests are failing.
+if(0) # Previously this test was not run, and it fails
+ADD_TEST( NAME test_sun_hist_brad_test_all COMMAND $<TARGET_FILE:brad_test_all> test_sun_hist)
+ADD_TEST( NAME test_phongs_model_est_brad_test_all COMMAND $<TARGET_FILE:brad_test_all> test_phongs_model_est)
+ADD_TEST( NAME test_sun_dir_index_brad_test_all COMMAND $<TARGET_FILE:brad_test_all> test_sun_dir_index)
+endif()
Recent changes to VXL seem to have made transitive linking fail for libraries depending on VXL.
For instance, the following program requires vgl:
int main()
{
vgl_vector_2d vec(3,5);
double L=vec.length();
}
PROJECT(test_link_lib_project)
INCLUDE_DIRECTORIES(${VXL_CORE_INCLUDE_DIR})
INCLUDE_DIRECTORIES(${VXL_MUL_INCLUDE_DIR})
ADD_EXECUTABLE(test_prog test_prog.cxx)
one would expect the linking to work, since mbl depends on vgl, so vgl should be included.
Unfortunately this doesn't happen (when using Shared Libraries on Ubuntu with cmake 2.8.12.2 and gcc).
Instead I get the error:
undefined reference to `vgl_vector_2d::length() const'
This is fixed if I modify the target_link_library list to:
TARGET_LINK_LIBRARIES(test_prog mbl ${VXL_LIB_PREFIX}vgl)
However, I shouldn't have to do that.
Any ideas?
819: Test command: /Users/johnsonhj/src/delteme-bld/bin/sdet_test_all "test_sel"
819: Test timeout computed to be: 1500
819: -----------------------------------------------------------------------------
819: Start Testing Test sdet_edgel class:
819: -----------------------------------------------------------------------------
819: Test 001: Constructor --> PASSED
819: -----------------------------------------------------------------------------
819: Start Testing Test sdet_ES_curve_model class:
819: -----------------------------------------------------------------------------
819: Test 001: Compute curve bundle from(eA-eB) at eA --> FAILED
819: Test 002: Compute curve bundle from(eA-eB) at eB --> FAILED
819: Test 003: Compute curve bundle from a pair of edgels(eA-eC) --> FAILED
819: -----------------------------------------------------------------------------
819: Start Testing Test sdet_sel class:
819: -----------------------------------------------------------------------------
819: Test 001: Constructor --> PASSED
819: -----------------------------------------------------------------------------
819: Test sdet_sel class Test Summary: 1 test succeeded
819: -----------------------------------------------------------------------------
1/1 Test #819: sdet_test_sel .................... Passed 0.02 sec
The following tests passed:
sdet_test_sel
From Brad King: There no specializations for char types in vnl.
This would have to be done so that all exception code can be switched off,
since VXL does not require exception support. Converting many of the
calls to vcl_abort, into exceptions would be useful for programmers of
GUIs, giving the program a change to save state and possibly give a
useful bug report before exiting. Lots of VXL is probably not exception
safe, and needs to be fixed.
Github doesn't automatically recognize txx files as c++, and therefore does not provide syntax highlighting in the browser. This patch gives github a "hint" which allows it to provide in-browser syntax highlighting.
The problem is more widespread. We ran into this for ITK (see below). ITK has git hooks to prevent .txx files from being added in the future.
I would HIGHLY recommend (and emphatically request) that we fix the root problem and change from .txx to .hxx (or .hpp) file extensions.
I was planning to do that before integrating VXL with ITK. If you could do this I would be forever grateful.
STYLE: Change for development tool compliance
PREMISE:
The use of the .txx file extension for indicating the file
that is to hold the implementation of a template class is
only adopted by the ITK community and VNL communities (and has
slightly “infected” a few other small components of other projects).
Increasingly tools are being created to help the programmer better
understand and analyze, and provide hints to proper coding options
dynamically in the development environment (color coding, auto-completion).
The obscure .txx file requires special configuration of each development
environment tool to indicate that it is really a c++ header. For new
developers this is often a difficult and frustrating task. This is
confirmed by the large amount of documentation for just a few of the
common editors. Tools that recognize and respect the .hxx extension:
uncrustify, vim, emacs, VisualStudios, clang, SlickEdit,
kwrite, etc....) None of these tools recognize the .txx extension without
end user customizations.
CONS:
Many files will be changed, and it will not be backwards compatible for
those who accidently included the “.txx” files in their projects. The .txx
files should not be included in external packages.
BENEFITS:
Implementation files are properly mapped to C++ language type by default
for improved development environment experience.
CONSIDERATIONS:
There is no obvious single correct solution, but in general a common theme
from other guides is that the final extension should be “.hxx” or
some suffix that ends with “.h”. The extension should be all lower case
letters (to avoid problems on case insensitive file sysetms).
PROPOSAL:
In ITKv4 (and outside of the ThirdParty directory) change all implementation files
that currently have a “.txx” extension to have a “.hxx” extension.
An in-depth discussion was held near April 20, 2011 on the Insight-Developers
mailing list.
Using the vgl_plane_3d+int- instantiation will probably give unexpected results if actually used. Look for a way to remove it.
VXL has been ported to the Borland 5.5 compiler, but only for the core
libraries, not the contrib libraries. Brad King did the port for the
core libraries and may have some advice on getting contrib ported.
VXL is not threadsafe, but should be. Some of this is due to the
limitations of f2c in v3p/netlib. It produces static variables, where
automatic ones would do. This may be fixed with the latest version of
f2c and or lapack3e.
In other places, such as the vil image loader, and the vsl binary
loader, there are singleton classes. This code is inherently
nonthread safe. Such code can be clearly documented to indicate how
to avoid thread problems, e.g. by initialising such loaders in a single
thread.
From Brad King: In vnl Some of the constants are static methods and
some are static constants. I do not see any reason for the
inconsistency.
The vil1 library had indications in the code that it should be removed and replaced with the vil library.
There is a script in "vxl/core/vil/scripts/vil1tovil.pl" to assist with conversions from vil1 to vil.
It appears that these changes have been intended to occur since 2003, but have not been fully completed.
Is this a bug, or a desired side effect. If it is a desired side effect, then explicit static_cast should be used with vcl_math::abs().
vxl/contrib/brl/bbas/volm/desc/volm_desc_matcher.cxx:133:21: warning: using integer absolute value function 'abs' when argument is of floating point
type [-Wabsolute-value]
double x_dist = abs(gt_loc.x()-gt_closest.x())_sec_to_meter;
^
vxl/contrib/brl/bbas/volm/desc/volm_desc_matcher.cxx:133:21: note: use function 'std::abs' instead
double x_dist = abs(gt_loc.x()-gt_closest.x())_sec_to_meter;
^~~
std::abs
vxl/contrib/brl/bbas/volm/desc/volm_desc_matcher.cxx:134:21: warning: using integer absolute value function 'abs' when argument is of floating point
type [-Wabsolute-value]
double y_dist = abs(gt_loc.y()-gt_closest.y())_sec_to_meter;
^
vxl/contrib/brl/bbas/volm/desc/volm_desc_matcher.cxx:134:21: note: use function 'std::abs' instead
double y_dist = abs(gt_loc.y()-gt_closest.y())_sec_to_meter;
^~~
std::abs
CMake Warning (dev) at c:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindMFC.cmake:39 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Quoted variables like "MFC_HAVE_MFC" will no longer be dereferenced when
the policy is set to NEW. Since the policy is not set the OLD behavior
will be used.
Call Stack (most recent call first):
contrib/brl/bbas/bwm/CMakeLists.txt:100 (find_package)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Warning (dev) at c:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindMFC.cmake:39 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Quoted variables like "MFC_HAVE_MFC" will no longer be dereferenced when
the policy is set to NEW. Since the policy is not set the OLD behavior
will be used.
Call Stack (most recent call first):
config/cmake/Modules/NewCMake/FindECW.cmake:53 (find_package)
contrib/brl/bbas/bwm/algo/CMakeLists.txt:30 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
-- Could NOT find wxWidgets (missing: wxWidgets_FOUND)
-- Found JNI: C:/Program Files/Java/jdk1.7.0_79/lib/jawt.lib
-- Could NOT find EXPAT (missing: EXPAT_LIBRARY EXPAT_INCLUDE_DIR)
-- Could NOT find EXPAT (missing: EXPAT_LIBRARY EXPAT_INCLUDE_DIR)
CMake Warning (dev) at c:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindMFC.cmake:39 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Quoted variables like "MFC_HAVE_MFC" will no longer be dereferenced when
the policy is set to NEW. Since the policy is not set the OLD behavior
will be used.
Call Stack (most recent call first):
config/cmake/Modules/NewCMake/FindECW.cmake:53 (find_package)
contrib/brl/bseg/segv/CMakeLists.txt:16 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Warning (dev) at c:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindMFC.cmake:39 (if):
Policy CMP0054 is not set: Only interpret if() arguments as variables or
keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
details. Use the cmake_policy command to set the policy and suppress this
warning.
Quoted variables like "MFC_HAVE_MFC" will no longer be dereferenced when
the policy is set to NEW. Since the policy is not set the OLD behavior
will be used.
Call Stack (most recent call first):
config/cmake/Modules/NewCMake/FindECW.cmake:53 (find_package)
contrib/brl/bseg/sbin/CMakeLists.txt:42 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
The macro infrastructure for removing legacy code in ITK works really well. Add this infrastructure to VXL.
This pull request is incomplete and should not be merged.
#122
Matt McCormic provide the following comment hints:
Thanks for looking at this. This is very old CMake usage that really should be updated. This patch looks good for removing the old code. However, more code is needed to replace its functionality. Using install(EXPORT and export( commands, a VXLTargets.cmake file can be created that replaces the old functionality.
I don't have the time to take that on. If you are willing and able, this page:
https://cmake.org/cmake/help/v3.4/manual/cmake-packages.7.html
explains the context a bit.
Otherwise, I think we should just set the policy to OLD to silence the warning along with at comment an an issue opened that explains what needs to be done.
From ITK's perspective, I don't think this is used, unless perhaps ITK_USE_SYSTEM_VXL is ON.
in contrib/brl/bseg/bvxm/tests/test_voxel_world_mog_image.cxx:
Following test is comment out
TEST_NEAR("image diff should sum to 0", sum, 0.0f, 5.0f);
This test failure was due to difference in initial values used in two expected image from bvxm voxel world. Other than that, the rendered results were exactly same.
This will greatly reduce the code base, and much of the complexity and CMake variable spaghetti code that makes it difficult to track down behaviors.
contrib/brl/bseg/bvxm/tests/test_voxel_world_mog_image.cxx
According to the implementation file documentation (there is no documentation in the header), the function vnl_error_vector_index should "[r]aise exception for invalid index". However, my attempts to throw and catch with this function resulted in program termination. After drilling down into the preprocessor definitions, it looks as though the function is just calling std::abort(), and no exception is being raised. My questions are:
vnl_error_vector_index, and all the other functions in that file, are just calling std::abort()?Let's say I want to catch an exception thrown in the standard library. I can do it like this:
std::vector<int> std_vec;
try {std_vec.at(25);}
catch (...) { vcl_cout << "This gets caught." << vcl_endl; }
I thought perhaps I could do the same for a vxl exception, but the exception does not get caught:
try { vnl_error_vector_index("get", 25); } // Raise exception
catch (...) { vcl_cout << "Not caught." << vcl_endl; }
After poking around in the code for a while, I found that vxl actually defines its own try/catch structure, but unfortunately that doesn't catch it either:
vcl_try { vnl_error_vector_index("get", 25); } // Raise exception
vcl_catch_all { vcl_cout << "Not caught." << vcl_endl; }
Both of the vxl examples give an error and terminate execution.
vnl_error_vector_index:get: Invalid value 25 specified for index.
So I poked around some more and found the implementation of vxl_error_vector_index here:
//: Raise exception for invalid index
void vnl_error_vector_index (char const* fcn, int index)
{
//RAISE Error, SYM(vnl_error_vector), SYM(Invalid_Index),
vcl_cerr << "vnl_error_vector_index:" << fcn
<< ": Invalid value " << index << " specified for index.\n";
vcl_abort();
}
A little more investigating into vcl_abort() seems to show that no exception is actually being thrown. From vcl/generic/vcl_cstdlib.h:
// abort
#ifndef vcl_abort
#define vcl_abort vcl_generic_cstdlib_STD :: abort
#endif
And from vcl/iso/vcl_stdlib.h:
#ifdef vcl_generic_cstdlib_STD
** error **
#else
# define vcl_generic_cstdlib_STD std
#endif
So all in all vcl_abort() seems to resolve to std::abort().
Dear all,
Under VS12-Windows7, the newly added 4 macros don't have values if the checking returns failure during configuration, shown below
...
Performing Test VXL_HAS_STD_ISNAN
Performing Test VXL_HAS_STD_ISNAN - Failed
Performing Test VXL_HAS_STD_ISINF
Performing Test VXL_HAS_STD_ISINF - Failed
Performing Test VXL_HAS_STD_ISFINITE
Performing Test VXL_HAS_STD_ISFINITE - Failed
Performing Test VXL_HAS_STD_ISNORMAL
Performing Test VXL_HAS_STD_ISNORMAL - Failed
...
Afterwards, the created 'vxl_config.h' missed the values for these macros
/* true if <stdlib.h> declares lrand48() */
/* true if <stdlib.h> declares drand48() */
/* true if <stdlib.h> declares srand48() */
/* Check for C99 versions of is[finite|inf|nan|normal] in <math.h> */
This leads to the compile error c1017 (https://msdn.microsoft.com/en-us/library/h5sh3k99.aspx)
Any idea?
Thanks
Yi
There is likely an uninitialized variable.
for i in $(seq 1 30); do ctest -R rgrl_estimator; done
The test failed 2 out of 30 times, and passed 28 out of 30 times.
This was on a linux computer.
Hans
for i in $(seq 1 100); do ctest -R vnl_algo_test_svd_fixed; done
Test 012: Stack memory SVD is faster than heap memory SVD --> FAILED
This is a failure in speed testing that is not related to the quality of the results, just in the relative speed of two different approaches.
for i in vil1/.h ; do echo $(git grep $(basename $i) |sed "s#^$(dirname $i).##g" |grep vil1 |wc -l) $i; done|sort -n
0 vil1/vil1_16bit.h
0 vil1/vil1_32bit.h
0 vil1/vil1_block_cache_image_impl.h
0 vil1/vil1_byte_swap.h
0 vil1/vil1_clamp_image.h
0 vil1/vil1_clamp_image_impl.h
0 vil1/vil1_colour_space.h
0 vil1/vil1_convolve_simple.h
0 vil1/vil1_copy.h
0 vil1/vil1_crop_image_impl.h
0 vil1/vil1_file_format.h
0 vil1/vil1_file_image.h
0 vil1/vil1_flip_components.h
0 vil1/vil1_flip_components_impl.h
0 vil1/vil1_flipud.h
0 vil1/vil1_flipud_impl.h
0 vil1/vil1_fwd.h
0 vil1/vil1_image_impl.h
0 vil1/vil1_image_proxy.h
0 vil1/vil1_ip_traits.h
0 vil1/vil1_jpeglib.h
0 vil1/vil1_memory_image_impl.h
0 vil1/vil1_memory_image_window.h
0 vil1/vil1_ncc.h
0 vil1/vil1_new.h
0 vil1/vil1_open.h
0 vil1/vil1_property.h
0 vil1/vil1_resample.h
0 vil1/vil1_resample_image.h
0 vil1/vil1_resample_image_impl.h
0 vil1/vil1_scale_intensities.h
0 vil1/vil1_scale_intensities_image.h
0 vil1/vil1_scale_intensities_image_impl.h
0 vil1/vil1_skip.h
0 vil1/vil1_skip_image_impl.h
0 vil1/vil1_ssd.h
0 vil1/vil1_stream.h
0 vil1/vil1_stream_core.h
0 vil1/vil1_stream_fstream.h
0 vil1/vil1_stream_section.h
0 vil1/vil1_stream_url.h
1 vil1/vil1_clamp.h
1 vil1/vil1_convolve.h
1 vil1/vil1_interpolate.h
1 vil1/vil1_memory_image.h
1 vil1/vil1_pyramid.h
1 vil1/vil1_rgb_byte.h
1 vil1/vil1_smooth.h
1 vil1/vil1_warp.h
2 vil1/vil1_crop.h
2 vil1/vil1_image_as.h
2 vil1/vil1_rgb.h
2 vil1/vil1_rgba.h
2 vil1/vil1_vil.h
3 vil1/vil1_pixel.h
5 vil1/vil1_save.h
6 vil1/vil1_memory_image_of.h
10 vil1/vil1_load.h
11 vil1/vil1_image.h
VXL needs to have a wrapper header for Python.h. We need it for 2 reasons that I know of.
Bill Hoffman has suggested that a lot of the compiler version based
vnl_algo uses the netlib library to provide good numerical algorithms.
During VNL's design, it was thought that the much newer LAPACK was better
than the LINPACK library. However, it was faster to get something working
with LINPACK, since it had less dependencies than LAPACK. Now, LAPACK's
superiority is undisputed. LAPACK is faster, and more accurate. It is
designed for efficient parallel processing including on SMP machines
so it should be thread safe. We do not know if f2c'ed LAPACK is
automally thread safe, but it should be possible to hand edit it
to deal with f2c's deficiencies. LAPACK3E has been specifically updated
to avoid SAVE statements and so is definitely thread safe. It is written
in Fortran 90 whilst f2c can still only read Fortran77. There is a
developmental version of gcc supporting Fortran95, so maybe gcc users
could optionally use the native LAPACK library.
netlib.org has a library called CLAPACK where someone else has done the
f2c and tidyup already. I don't know if it is threadsafe. It might not
be too much work to strip out any remaining static values.
It should be possible to start using LAPACK incrementally. LAPACK
names do not appear to clash with LINPACK, and since they both need
BLAS, adding the LAPACK code to v3p/netlib would be sensible.
I suggest starting with SVD of double matrices. This will require
also converting some helper functions. After that it should be
relatively straight forward to start importing individual LAPACK
routines, and moving vnl_algo classes over one at a time.
Note that vnl does not use BLAS, but does its own vector and matrix
multiplications. The speed of the MKL (An Intel supplied/optimised copy
of BLAS) was compared with gcc's compilation of VNL, and gcc/VNL won.
gcc/VNL was marginally faster on the matrixvector operations, although
the difference was more marked on the vectorvector operations.
However, LAPACK and LINPACK both need a BLAS, and the MKL
was definitely faster than the gcccompiled version of the default BLAS
currently in netlib. So it would be worth providing an option to use an
external BLAS for vnl_algo/netlib. It might also be worth testing the
matrixmatrix operations where MKL's knowledge of cache behaviour
may help more than vnl's knowledge of the matrix data organisation.
See https://sourceforge.net/mailarchive/message.php?msg_id=3628964 for
more details.
Some compiler optimsers (gcc's notably) appear to break bits of netlib.
Different versions of gcc (or even the same version of gcc on different
computers) break different bits of netlib, so turning optimisation off
for all of netlib has too high a price. It would be worth testing the
builds of various bits of netlib in the configuration and adjusting
optimiser values until tests are passed. It is certainly not worth
doing any of this before moving from linpack to lapack.
Ian Scott.
@pcarr Thank you for addressing these outstanding patches.
Dev/calibration routines and tests #95 opened 4 days ago by hjmjohnson
Dev/fix clang warnings #94 opened 4 days ago by hjmjohnson
Dev/fix calibration matrix #93 opened 4 days ago by hjmjohnson
I have made this issue so that you can track changes and progress here.
Thanks,
Hans
Hi Hans,
Yes, I can take a look at those patches to see where things stand. I believe they are still relevant, as I haven't seen too much chatter about the vpgl library. I have a few high priority deadlines at the moment, so I don't think I'll be able to get to these patches before the end of January. If that's going to be an issue, I'll clone VXL into my github account and make sure the relevant branches are there (so that you can deleted them from the main repository to keep things clean). I can then work through the "pull request" model now that VXL has migrated to GitHub.
Peter
On Tue, Jan 12, 2016 at 8:10 AM, Peter Carr [email protected] wrote:
Begin forwarded message:
From: "Johnson, Hans J" [email protected]
Subject: Updated VXL patches
Date: January 8, 2016 at 5:10:11 PM EST
To: "[email protected]" [email protected]
Peter,
I found some outstanding VXL patches from you. They have been rebased onto recent versions of VXL.
Would you mind looking and commenting on these pull requests? Are the still relevant?
Thanks,
Hans
Unfortunately I can no longer build VXL at all (Ubuntu, cmake version 2.8.12.2)
When running configuring a fresh object directory using cmake ../vxl I get many errors of the form:
CMake Error: install(EXPORT "VXLTargets") given absolute DESTINATION "/usr/local/share/vxl/cmake" but the export references an installation of target "vcl" which has relative DESTINATION "lib".
The /= operator test is failing on newer gcc. I looked into this failure a little bit and don't quite understand. The test seems correct when I do that calculation by hand.
Hello, everyone,When I build the whole vxl project, I come cross the problems as the following, I
can not figure out what the reason is and when I search in google I can not find answers. Can any one help? I am new to linux. Thanks !!
This is produced after the "make" command:
[ 35%] Built target vpgl_io_test_template_include
[ 35%] Built target vpgl_xio
[ 35%] Built target vpgl_xio_test_all
[ 35%] Built target vpgl_xio_test_include
[ 35%] Building CXX object core/vidl/CMakeFiles/vidl.dir/vidl_ffmpeg_istream.cxx.o
In file included from /home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream.cxx:31:0:
/home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream_v3.hxx: In member function ‘virtual bool vidl_ffmpeg_istream::open(const string&)’:
/home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream_v3.hxx:147:43: error: ‘av_find_stream_info’ was not declared in this scope
if ( av_find_stream_info( is_->fmt_cxt_ ) < 0 ) {
^
/home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream_v3.hxx:169:43: error: ‘avcodec_open’ was not declared in this scope
if ( !codec || avcodec_open( enc, codec ) < 0 ) {
^
/home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream_v3.hxx: In member function ‘virtual void vidl_ffmpeg_istream::close()’:
/home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream_v3.hxx:220:5: warning: ‘void av_close_input_file(AVFormatContext_)’ is deprecated (declared at /usr/include/libavformat/avformat.h:1397) [-Wdeprecated-declarations]
av_close_input_file( is_->fmt_cxt_ );
^
/home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream_v3.hxx:220:40: warning: ‘void av_close_input_file(AVFormatContext_)’ is deprecated (declared at /usr/include/libavformat/avformat.h:1397) [-Wdeprecated-declarations]
av_close_input_file( is_->fmt_cxt_ );
^
/home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream_v3.hxx: In member function ‘virtual vidl_pixel_format vidl_ffmpeg_istream::format() const’:
/home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream_v3.hxx:336:69: error: ‘vidl_pixel_format_from_ffmpeg’ was not declared in this scope
vidl_pixel_format fmt = vidl_pixel_format_from_ffmpeg(enc->pix_fmt);
^
/home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream_v3.hxx: In member function ‘virtual vidl_frame_sptr vidl_ffmpeg_istream::current_frame()’:
/home/minzhe/Downloads/vxl-master/core/vidl/vidl_ffmpeg_istream_v3.hxx:477:71: error: ‘vidl_pixel_format_from_ffmpeg’ was not declared in this scope
vidl_pixel_format fmt = vidl_pixel_format_from_ffmpeg(enc->pix_fmt);
^
make[2]: *** [core/vidl/CMakeFiles/vidl.dir/vidl_ffmpeg_istream.cxx.o] Error 1
make[1]: *** [core/vidl/CMakeFiles/vidl.dir/all] Error 2
make: *** [all] Error 2
I got this infuriating error while building VXL with GCC 5.3.0 on Cygwin:
Building CXX object contrib/oxl/vrml/CMakeFiles/oxl_vrml.dir/vrml_out.cxx.o
/cygdrive/b/AF/workspace/mmm_aux/sources/vxl-master/contrib/oxl/vrml/vrml_out.cxx:503:51: error: no ‘void vrml_out::quad_t(int, int, int, int)’ member function declared in class ‘vrml_out’
void vrml_out::quad(int i1, int i2, int i3, int i4)
^
In the end, I went to that line in vrml_out.cxx and add that:
after that I got it compiled, but with new warning:
/cygdrive/b/AF/workspace/mmm_aux/sources/vxl-master/contrib/oxl/vrml/vrml_out.cxx:503:0: warning: "quad" redefined
#define quad quad
^
In file included from /usr/include/pthread.h:14:0,
from /usr/lib/gcc/i686-pc-cygwin/5.3.0/include/c++/i686-pc-cygwin/bits/gthr-default.h:35,
from /usr/lib/gcc/i686-pc-cygwin/5.3.0/include/c++/i686-pc-cygwin/bits/gthr.h:148,
from /usr/lib/gcc/i686-pc-cygwin/5.3.0/include/c++/ext/atomicity.h:35,
from /usr/lib/gcc/i686-pc-cygwin/5.3.0/include/c++/bits/ios_base.h:39,
from /usr/lib/gcc/i686-pc-cygwin/5.3.0/include/c++/ios:42,
from /usr/lib/gcc/i686-pc-cygwin/5.3.0/include/c++/ostream:38,
from /usr/lib/gcc/i686-pc-cygwin/5.3.0/include/c++/iostream:39,
from /cygdrive/b/AF/workspace/mmm_aux/sources/vxl-master/vcl/iso/vcl_iostream.h:6,
from /cygdrive/b/AF/workspace/mmm_aux/sources/vxl-master/vcl/vcl_iostream.h:42,
from /cygdrive/b/AF/workspace/mmm_aux/sources/vxl-master/vcl/vcl_fstream.h:8,
from /cygdrive/b/AF/workspace/mmm_aux/sources/vxl-master/contrib/oxl/vrml/vrml_out.cxx:11:
/usr/include/sys/types.h:90:0: note: this is the location of the previous definition
# define quad quad_t
^
After VXL is "make installed" the local VXL FindPackages for Expat, Tiff , GeoTiff, JPEG all change the location that they point to for finding the link libraries from the BUILD_DIR to the CMAKE_INSTALL_PREFIX dir versions.
This causes many very confusing build issues.
To replicate, build normally, make install, build again, then delete the installed directory. The builds no longer work! (Errors regarding missing geotiff library from the install tree are reported).
@hjmjohnson We have been including VXL in another project by including it as a subdirectory via CMake's add_directory. This was broken by 6f4c444 because CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR do not point to the root vxl directory, but the root of the base project. Would making the paths relative to CMAKE_CURRENT_BINARY_DIR and CMAKE_CURRENT_SOURCE_DIR instead satisfy the original goals of this commit?
From Brad King: In vnl, another problem is that test_math and
test_numeric_limits access the NaN values. There is nothing wrong
with this, but Borland throws floatingpoint exceptions by default.
I've fixed my local copy to use the _control87 function to disable
exceptions for those tests on that compiler, but I haven't committed
it yet. Is this something we want to abstract and add to testlib?
From Peter Vanroose: A similar problem on Alpha (OSF). I've commented
out the affected tests, but that's not really the best way to proceed.
So it's not just Borland C++, and it would indeed be nice to have an
elegant solution for this.
From Brad King: We could just put the floating point exception disable
code in the top of testlib_main just like the crtdbg stuff for getting
rid of the MSVC popup dialogs. Once we get it working everywhere with
a bunch of #ifdef lines then we could consider making it a function
somewhere useful outside testing.
Related to issues here #54
Tests tagged with "HACK_FORCE_BRL_FAILING_TESTS" for easy identification
To get these tests to run use "cmake -DHACK_FORCE_BRL_FAILING_TESTS:BOOL=ON"
These are the tests that fail on my Mac: ==================================
99% tests passed, 6 tests failed out of 980
These are tests that fail on Linux (some on travis CI, some on RHEL6) ==================================
99% tests passed, 3 tests failed out of 956
All--
I've recently needed access to a few subroutines from LAPACK which aren't shipped along with VXL. The README for v3p/netlib/ hasn't been updated in a while, but the instructions are pretty thorough. As a test case, I tried to add sgees.
sgees.f and its (LAPACK) dependencies from here.
v3p/netlib/lapack/single/ and committed them.
man f2c tells me that it is used to convert Fortran 77 to C or C++.for d in blas linpack temperton eispack laso arpack lapack/complex16 lapack/double lapack/single lapack/util napack minpack opt linalg toms datapac mathews; do
for f in ${d}/*.f; do
b=`echo "$f" | sed 's/.f$//'`
if [ ! -f "${b}.c" ]; then
echo "Converting ${b}.f to ${b}.c"
f2c -A -a -C++ -c -ec -E -P -d${d} ${b}.f &&
cat ${b}.c | sed 's/f2c.h/v3p_netlib.h/' > ${b}.c.tmp &&
mv ${b}.c.tmp ${b}.c
fi
done
done
Most of the conversions went along without trouble, but there were some errors in converting three files (below). I assume this is a 77/90 problem (this thread seems to confirm) but, as there may be more than one place where I'm going wrong, I thought I'd open an issue to ask for clarification on the process.
Best, and thanks,
--Davis
Converting lapack/single/slamch.f to lapack/single/slamch.c
lapack/single/slamch.f:
slamch:
Error on line 93 of lapack/single/slamch.f: Declaration error for digits: unknown intrinsic function
Error on line 93 of lapack/single/slamch.f: Declaration error for epsilon: unknown intrinsic function
Error on line 93 of lapack/single/slamch.f: Declaration error for huge: unknown intrinsic function
Error on line 93 of lapack/single/slamch.f: Declaration error for maxexponent: unknown intrinsic function
Error on line 93 of lapack/single/slamch.f: Declaration error for minexponent: unknown intrinsic function
Error on line 93 of lapack/single/slamch.f: Declaration error for radix: unknown intrinsic function
Error on line 93 of lapack/single/slamch.f: Declaration error for tiny: unknown intrinsic function
slamc3:
Converting lapack/single/slarft.f to lapack/single/slarft.c
lapack/single/slarft.f:
slarft:
Error on line 220 of lapack/single/slarft.f: syntax error
Error on line 221 of lapack/single/slarft.f: misplaced ENDDO
Error on line 234 of lapack/single/slarft.f: nested loops with variable lastv
Error on line 235 of lapack/single/slarft.f: syntax error
Error on line 236 of lapack/single/slarft.f: misplaced ENDDO
Error on line 259 of lapack/single/slarft.f: Execution error endif out of place
Error on line 261 of lapack/single/slarft.f: Execution error else out of place
Error on line 263 of lapack/single/slarft.f: nested loops with variable i
Error on line 278 of lapack/single/slarft.f: nested loops with variable lastv
Error on line 279 of lapack/single/slarft.f: syntax error
Error on line 280 of lapack/single/slarft.f: misplaced ENDDO
Error on line 293 of lapack/single/slarft.f: nested loops with variable lastv
Error on line 294 of lapack/single/slarft.f: syntax error
Error on line 295 of lapack/single/slarft.f: misplaced ENDDO
Error on line 317 of lapack/single/slarft.f: Execution error endif out of place
Error on line 319 of lapack/single/slarft.f: Execution error endif out of place
Error on line 326 of lapack/single/slarft.f: DO loop or BLOCK IF not closed
Converting lapack/single/xerbla.f to lapack/single/xerbla.c
lapack/single/xerbla.f:
xerbla:
Error on line 86 of lapack/single/xerbla.f: Declaration error for len_trim: unknown intrinsic function
Brad King: There are several ways that compilers provide isnan, isinf,
and isfinite tests. The C99 standard defines "isnan", "isinf", and
"isfinite" as macros that work with float, double, and long double.
BSD 4.3 (and many conforming platforms) define
int isinf(double value);
int isnan(double value);
int finite(double value);
in math.h. Many platforms also provide
int isinff(float value);
int isnanf(float value);
int finitef(float value);
and
int isinfl(long double value);
int isnanl(long double value);
int finitel(long double value);
However, no set of these works everywhere, and some implementations
have bugs. Alternatively one can implement these functions by hand.
Currently there is a handwritten implementation that works in most
cases, but not all. As hardware improves and long double gets bigger,
the implementation is working on fewer and fewer platforms.
For long double, the sign bit is not always the most significant bit
due to aligned sizes (see below). It is possible to detect the
location of the sign exponent bits by bitwise XORing the
representation of '1.0' and '1.0'. The lowest order bit of the
exponent portion can be detected by bitwise XORing the representation
of '1.0' and '0.5'. Unfortunately the assumption of IEEE conformance
for long double cannot be made. The representation on Intel
platforms, for example, has the following problems:
sizeof(long double) == 10 when compiling with Borland
sizeof(long double) == 12 when compiling with GCC
The 12byte version is the aligned size, but the number is really only
10 bytes long. It is a direct copy of the 80bit floating point
representation from the Intel FPU's registers. The implicit '1' bit
is represented explicitly as the MSB of the fraction component, and
thus is not IEEE conforming.
diff --git a/core/vgl/tests/test_cartesian.cxx b/core/vgl/tests/test_cartesian.cxx
index 9fc3ebb..9abb602 100644
--- a/core/vgl/tests/test_cartesian.cxx
+++ b/core/vgl/tests/test_cartesian.cxx
@@ -520,6 +520,7 @@ static void test_line_2d()
is >> line;
vcl_cout << "formatted line " << line << '\n';;
TEST("istream vgl_line_2d", line, vgl_line_2d(4.5f,-5,70));
+#if 0 // HACK This test is always failing
vcl_stringstream is1;
is1 << "9x+7y-8=0" << vcl_ends;
vcl_cout << "stringstr 1 "<< is1.str() << '\n';
@@ -527,6 +528,7 @@ static void test_line_2d()
is1 >> line1;
vcl_cout << "formatted line " << line1 << '\n';
TEST("istream vgl_line_2d formatted", line1, vgl_line_2d(9,7,-8));
+#endif
}
vcl_stringstream is; is << "\n4 6 7 9";
@@ -661,9 +663,11 @@ static void test_plane_3d()
vcl_cout << is.str();
vgl_plane_3d l; is >> l;
TEST("istream vgl_plane_3d", l, vgl_plane_3d(4.5,-5,70,0.5));
+#if 0 // HACK This test is always failing
is >> l;
vcl_cout << "second form for l " << l << '\n';
TEST("istream vgl_plane_3d formatted", l, vgl_plane_3d(-6,7,-8,9));
+#endif
}
In file included from /scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.txx:13:
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.h:101:7: warning: array index 2 is past the end of the array (which contains 2 elements) [-Warray-bounds]
min_[2] <= z && z <= max_[2];
^ ~
/scratch/johnsonhj/src/vxl/core/vbl/Templates/vbl_bounding_box+double.2-.cxx:3:1: note: in instantiation of member function 'vbl_bounding_box_base<double,
vbl_bounding_box_DIM<2> >::inside' requested here
VBL_BOUNDING_BOX_INSTANTIATE(double,2);
^
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.txx:42:16: note: expanded from macro 'VBL_BOUNDING_BOX_INSTANTIATE'
template class vbl_bounding_box_base<T , vbl_bounding_box_DIM< DIM > >;
^
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.h:162:3: note: array 'min_' declared here
T min_[DIM_::value];
^
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.h:101:28: warning: array index 2 is past the end of the array (which contains 2 elements) [-Warray-bounds]
min_[2] <= z && z <= max_[2];
^ ~
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.h:163:3: note: array 'max_' declared here
T max_[DIM_::value];
^
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.h:134:67: warning: array index 2 is past the end of the array (which contains 2 elements) [-Warray-bounds]
inline T const& zmin() const { assert(DIM_::value >= 3); return min_[2]; }
^ ~
/scratch/johnsonhj/src/vxl/core/vbl/Templates/vbl_bounding_box+double.2-.cxx:3:1: note: in instantiation of member function 'vbl_bounding_box_base<double,
vbl_bounding_box_DIM<2> >::zmin' requested here
VBL_BOUNDING_BOX_INSTANTIATE(double,2);
^
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.txx:42:16: note: expanded from macro 'VBL_BOUNDING_BOX_INSTANTIATE'
template class vbl_bounding_box_base<T , vbl_bounding_box_DIM< DIM > >;
^
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.h:162:3: note: array 'min_' declared here
T min_[DIM_::value];
^
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.h:135:67: warning: array index 2 is past the end of the array (which contains 2 elements) [-Warray-bounds]
inline T const& zmax() const { assert(DIM_::value >= 3); return max_[2]; }
^ ~
/scratch/johnsonhj/src/vxl/core/vbl/Templates/vbl_bounding_box+double.2-.cxx:3:1: note: in instantiation of member function 'vbl_bounding_box_base<double,
vbl_bounding_box_DIM<2> >::zmax' requested here
VBL_BOUNDING_BOX_INSTANTIATE(double,2);
^
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.txx:42:16: note: expanded from macro 'VBL_BOUNDING_BOX_INSTANTIATE'
template class vbl_bounding_box_base<T , vbl_bounding_box_DIM< DIM > >;
^
/scratch/johnsonhj/src/vxl/core/vbl/vbl_bounding_box.h:163:3: note: array 'max_' declared here
T max_[DIM_::value];
^
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.