gnudatalanguage-devel — GDL Development

[gnudatalanguage-devel] problem for OSX 10.14, llvm 7, openmp + GDL 0.9.9 !

[Coulais A. <Ala...@ob...>]

Hi

for your information I spend litteraly hours to try to compile GDL (git) on
a Mac with OSX 10.14, without success. The script I hav before not working anymore,
and I need many "tricks" for me to go to link, then link fails !!

Before upgrade of this machine, I was in LLVM 6.0.0 and with Sylvain we succeed to switch on OpenMP and got results OK (used for tracking the speed regression :)

The problem is activating OpenMP, which is not avaialble in default compiler. But the message at linking also may link to Eigen3 ...

With the default compiler, and the updated "minimal_script.sh", no problem to compile Vanilla 0.9.9 and Git version

best regards

Alain

$ sw_vers 
ProductName:	Mac OS X
ProductVersion:	10.14
BuildVersion:	18A391

$ /usr/local/Cellar/llvm/7.0.0_1/bin/clang++ -v
clang version 7.0.0 (tags/RELEASE_700/final)
Target: x86_64-apple-darwin18.0.0
Thread model: posix
InstalledDir: /usr/local/Cellar/llvm/7.0.0_1/bin


cmake .. -DCMAKE_CXX_COMPILER=/usr/local/Cellar/llvm/7.0.0/bin/clang++ -DCMAKE_C_COMPILER=/usr/local/Cellar/llvm/7.0.0/bin/clang  -DOpenMP_CXX_FLAGS="-Xpreprocessor -fopenmp -I/usr/local/Cellar/libomp/7.0.0/include" -DOpenMP_CXX_LIB_NAMES="omp" -DOpenMP_omp_LIBRARY=/usr/local/Cellar/libomp/7.0.0/lib/libomp.dylib  -DOpenMP_C_LIB_NAMES="omp" -DOpenMP_C_FLAGS="-Xpreprocessor -fopenmp -I/usr/local/Cellar/libomp/7.0.0/include" -DWXWIDGETS=OFF -DGEOTIFF=OFF -DHDF=OFF  -DPSLIB=OFF -DREADLINEDIR=/Users/coulais/Vanilla098/readline-6.3/Compilation/ -DEIGEN3DIR=/Users/coulais/GDL/Eigen3/Eigen3.3.7/

(and yes, I need to duplicate  DOpenMP_CXX_FLAGS & DOpenMP_C_FLAGS !)

I got a super long message, maybe related to Eigen3, I also tried with the last Eigen3 version, delivered few weeks ago


Undefined symbols for architecture x86_64:
  "___kmpc_barrier", referenced from:
      _.omp_outlined. in datatypes.cpp.o
      _.omp_outlined..23 in datatypes.cpp.o
      _.omp_outlined..24 in datatypes.cpp.o
      _.omp_outlined..27 in datatypes.cpp.o
      _.omp_outlined..28 in datatypes.cpp.o
      _.omp_outlined..31 in datatypes.cpp.o
      _.omp_outlined..32 in datatypes.cpp.o
      ...
  "___kmpc_end_reduce", referenced from:
      _.omp_outlined..405 in datatypes.cpp.o
      _.omp_outlined..406 in datatypes.cpp.o
      _.omp_outlined..435 in datatypes.cpp.o
      _.omp_outlined..541 in datatypes.cpp.o
      _.omp_outlined..630 in datatypes.cpp.o
      _.omp_outlined..718 in datatypes.cpp.o
      _.omp_outlined..806 in datatypes.cpp.o
      ...
  "___kmpc_end_serialized_parallel", referenced from:
      Data_<SpDString>::AddInv(BaseGDL*) in datatypes.cpp.o
      Data_<SpDString>::AddS(BaseGDL*) in datatypes.cpp.o
      Data_<SpDString>::AddInvS(BaseGDL*) in datatypes.cpp.o
      Data_<SpDFloat>::NotOp() in datatypes.cpp.o
      Data_<SpDDouble>::NotOp() in datatypes.cpp.o
      Data_<SpDObj>::LogNeg() in datatypes.cpp.o
      Data_<SpDFloat>::LogNeg() in datatypes.cpp.o
      ...
  "___kmpc_for_static_fini", referenced from:
      _.omp_outlined. in datatypes.cpp.o
      _.omp_outlined..23 in datatypes.cpp.o
      _.omp_outlined..24 in datatypes.cpp.o
      _.omp_outlined..27 in datatypes.cpp.o
      _.omp_outlined..28 in datatypes.cpp.o
      _.omp_outlined..31 in datatypes.cpp.o
      _.omp_outlined..32 in datatypes.cpp.o
      ...
  "___kmpc_for_static_init_4", referenced from:
      _.omp_outlined..378 in datatypes.cpp.o
      _.omp_outlined..381 in datatypes.cpp.o
      _.omp_outlined..387 in datatypes.cpp.o
      Data_<SpDDouble>::Log() in datatypes.cpp.o
      _.omp_outlined..388 in datatypes.cpp.o
      _.omp_outlined..389 in datatypes.cpp.o
      _.omp_outlined..390 in datatypes.cpp.o
      ...
  "___kmpc_for_static_init_8", referenced from:
      _.omp_outlined..432 in datatypes.cpp.o
      _.omp_outlined..538 in datatypes.cpp.o
      _.omp_outlined..627 in datatypes.cpp.o
      _.omp_outlined..715 in datatypes.cpp.o
      _.omp_outlined..803 in datatypes.cpp.o
      _.omp_outlined..891 in datatypes.cpp.o
      _.omp_outlined..981 in datatypes.cpp.o
      ...
  "___kmpc_for_static_init_8u", referenced from:
      _.omp_outlined. in datatypes.cpp.o
      _.omp_outlined..23 in datatypes.cpp.o
      _.omp_outlined..24 in datatypes.cpp.o
      _.omp_outlined..27 in datatypes.cpp.o
      _.omp_outlined..28 in datatypes.cpp.o
      _.omp_outlined..31 in datatypes.cpp.o
      _.omp_outlined..32 in datatypes.cpp.o
      ...
  "___kmpc_fork_call", referenced from:
      Data_<SpDString>::AddInv(BaseGDL*) in datatypes.cpp.o
      Data_<SpDString>::AddS(BaseGDL*) in datatypes.cpp.o
      Data_<SpDString>::AddInvS(BaseGDL*) in datatypes.cpp.o
      Data_<SpDFloat>::NotOp() in datatypes.cpp.o
      Data_<SpDDouble>::NotOp() in datatypes.cpp.o
      Data_<SpDObj>::LogNeg() in datatypes.cpp.o
      Data_<SpDFloat>::LogNeg() in datatypes.cpp.o
      ...
  "___kmpc_global_thread_num", referenced from:
      Data_<SpDString>::AddInv(BaseGDL*) in datatypes.cpp.o
      _.omp_outlined. in datatypes.cpp.o
      Data_<SpDString>::AddS(BaseGDL*) in datatypes.cpp.o
      _.omp_outlined..23 in datatypes.cpp.o
      Data_<SpDString>::AddInvS(BaseGDL*) in datatypes.cpp.o
      _.omp_outlined..24 in datatypes.cpp.o
      Data_<SpDFloat>::NotOp() in datatypes.cpp.o
      ...
  "___kmpc_push_num_threads", referenced from:
      Data_<SpDByte>::Transpose(unsigned short*) in datatypes.cpp.o
      Data_<SpDInt>::Transpose(unsigned short*) in datatypes.cpp.o
      Data_<SpDUInt>::Transpose(unsigned short*) in datatypes.cpp.o
      Data_<SpDLong>::Transpose(unsigned short*) in datatypes.cpp.o
      Data_<SpDULong>::Transpose(unsigned short*) in datatypes.cpp.o
      Data_<SpDLong64>::Transpose(unsigned short*) in datatypes.cpp.o
      Data_<SpDULong64>::Transpose(unsigned short*) in datatypes.cpp.o
      ...
  "___kmpc_reduce", referenced from:
      _.omp_outlined..405 in datatypes.cpp.o
      _.omp_outlined..406 in datatypes.cpp.o
      _.omp_outlined..435 in datatypes.cpp.o
      _.omp_outlined..541 in datatypes.cpp.o
      _.omp_outlined..630 in datatypes.cpp.o
      _.omp_outlined..718 in datatypes.cpp.o
      _.omp_outlined..806 in datatypes.cpp.o
      ...
  "___kmpc_serialized_parallel", referenced from:
      Data_<SpDString>::AddInv(BaseGDL*) in datatypes.cpp.o
      Data_<SpDString>::AddS(BaseGDL*) in datatypes.cpp.o
      Data_<SpDString>::AddInvS(BaseGDL*) in datatypes.cpp.o
      Data_<SpDFloat>::NotOp() in datatypes.cpp.o
      Data_<SpDDouble>::NotOp() in datatypes.cpp.o
      Data_<SpDObj>::LogNeg() in datatypes.cpp.o
      Data_<SpDFloat>::LogNeg() in datatypes.cpp.o
      ...
  "_omp_get_dynamic", referenced from:
      SysVar::InitSysVar() in initsysvar.cpp.o
  "_omp_get_max_threads", referenced from:
      void Eigen::internal::parallelize_gemm<true, Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 1, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> >, long>(Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 1, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> > const&, long, long, long, bool) in datatypes.cpp.o
      void Eigen::internal::parallelize_gemm<true, Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 0, false, unsigned char, 1, false, 0>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> >, long>(Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 0, false, unsigned char, 1, false, 0>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> > const&, long, long, long, bool) in datatypes.cpp.o
      void Eigen::internal::parallelize_gemm<true, Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 0, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> >, long>(Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 0, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> > const&, long, long, long, bool) in datatypes.cpp.o
      void Eigen::internal::parallelize_gemm<true, Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 0, false, unsigned char, 0, false, 0>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> >, long>(Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 0, false, unsigned char, 0, false, 0>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> > const&, long, long, long, bool) in datatypes.cpp.o
      void Eigen::internal::parallelize_gemm<true, Eigen::internal::gemm_functor<short, long, Eigen::internal::general_matrix_matrix_product<long, short, 1, false, short, 1, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, short, short, -1, -1, -1, 1, false> >, long>(Eigen::internal::gemm_functor<short, long, Eigen::internal::general_matrix_matrix_product<long, short, 1, false, short, 1, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, short, short, -1, -1, -1, 1, false> > const&, long, long, long, bool) in datatypes.cpp.o
      void Eigen::internal::parallelize_gemm<true, Eigen::internal::gemm_functor<short, long, Eigen::internal::general_matrix_matrix_product<long, short, 0, false, short, 1, false, 0>, Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Transpose<Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, short, short, -1, -1, -1, 1, false> >, long>(Eigen::internal::gemm_functor<short, long, Eigen::internal::general_matrix_matrix_product<long, short, 0, false, short, 1, false, 0>, Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Transpose<Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, short, short, -1, -1, -1, 1, false> > const&, long, long, long, bool) in datatypes.cpp.o
      void Eigen::internal::parallelize_gemm<true, Eigen::internal::gemm_functor<short, long, Eigen::internal::general_matrix_matrix_product<long, short, 1, false, short, 0, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, short, short, -1, -1, -1, 1, false> >, long>(Eigen::internal::gemm_functor<short, long, Eigen::internal::general_matrix_matrix_product<long, short, 1, false, short, 0, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Map<Eigen::Matrix<short, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, short, short, -1, -1, -1, 1, false> > const&, long, long, long, bool) in datatypes.cpp.o
      ...
  "_omp_get_num_procs", referenced from:
      lib::cpu(EnvT*) in basic_pro.cpp.o
      SysVar::InitSysVar() in initsysvar.cpp.o
      get_suggested_omp_num_threads() in objects.cpp.o
      lib::get_random_state(EnvT*, lib::DSFMT_STATE, unsigned int) in randomgenerators.cpp.o
      lib::init_seeds(lib::DSFMT_STATE, unsigned int) in randomgenerators.cpp.o
      lib::random_fun_dsfmt(EnvT*) in randomgenerators.cpp.o
      InitOpenMP() in gdl.cpp.o
      ...
  "_omp_get_num_threads", referenced from:
      void Eigen::internal::parallelize_gemm<true, Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 1, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> >, long>(Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 1, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> > const&, long, long, long, bool) in datatypes.cpp.o
      _.omp_outlined..1363 in datatypes.cpp.o
      Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 1, false, 0>::run(long, long, long, unsigned char const*, long, unsigned char const*, long, unsigned char*, long, unsigned char, Eigen::internal::level3_blocking<unsigned char, unsigned char>&, Eigen::internal::GemmParallelInfo<long>*) in datatypes.cpp.o
      void Eigen::internal::parallelize_gemm<true, Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 0, false, unsigned char, 1, false, 0>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> >, long>(Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 0, false, unsigned char, 1, false, 0>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> > const&, long, long, long, bool) in datatypes.cpp.o
      _.omp_outlined..1364 in datatypes.cpp.o
      Eigen::internal::general_matrix_matrix_product<long, unsigned char, 0, false, unsigned char, 1, false, 0>::run(long, long, long, unsigned char const*, long, unsigned char const*, long, unsigned char*, long, unsigned char, Eigen::internal::level3_blocking<unsigned char, unsigned char>&, Eigen::internal::GemmParallelInfo<long>*) in datatypes.cpp.o
      void Eigen::internal::parallelize_gemm<true, Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 0, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> >, long>(Eigen::internal::gemm_functor<unsigned char, long, Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 0, false, 0>, Eigen::Transpose<Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> > const>, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::Map<Eigen::Matrix<unsigned char, -1, -1, 0, -1, -1>, 16, Eigen::Stride<0, 0> >, Eigen::internal::gemm_blocking_space<0, unsigned char, unsigned char, -1, -1, -1, 1, false> > const&, long, long, long, bool) in datatypes.cpp.o
      ...
  "_omp_get_thread_num", referenced from:
      _.omp_outlined..1363 in datatypes.cpp.o
      Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 1, false, 0>::run(long, long, long, unsigned char const*, long, unsigned char const*, long, unsigned char*, long, unsigned char, Eigen::internal::level3_blocking<unsigned char, unsigned char>&, Eigen::internal::GemmParallelInfo<long>*) in datatypes.cpp.o
      _.omp_outlined..1364 in datatypes.cpp.o
      Eigen::internal::general_matrix_matrix_product<long, unsigned char, 0, false, unsigned char, 1, false, 0>::run(long, long, long, unsigned char const*, long, unsigned char const*, long, unsigned char*, long, unsigned char, Eigen::internal::level3_blocking<unsigned char, unsigned char>&, Eigen::internal::GemmParallelInfo<long>*) in datatypes.cpp.o
      _.omp_outlined..1365 in datatypes.cpp.o
      Eigen::internal::general_matrix_matrix_product<long, unsigned char, 1, false, unsigned char, 0, false, 0>::run(long, long, long, unsigned char const*, long, unsigned char const*, long, unsigned char*, long, unsigned char, Eigen::internal::level3_blocking<unsigned char, unsigned char>&, Eigen::internal::GemmParallelInfo<long>*) in datatypes.cpp.o
      _.omp_outlined..1366 in datatypes.cpp.o
      ...
  "_omp_set_dynamic", referenced from:
      SysVar::InitSysVar() in initsysvar.cpp.o
  "_omp_set_num_threads", referenced from:
      lib::cpu(EnvT*) in basic_pro.cpp.o
      SysVar::InitSysVar() in initsysvar.cpp.o
      InitOpenMP() in gdl.cpp.o
ld: symbol(s) not found for architecture x86_64
clang-7: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/gdl] Error 1
make[1]: *** [src/CMakeFiles/gdl.dir/all] Error 2
make: *** [all] Error 2

Re: [gnudatalanguage-devel] IDL Package Manager IPM --> GPM

[Alain C. <ala...@ob...>]

> > Shall we fit with the IDL template ?! Or start with a GPM ?
> > (we can start with a simple GPM subset of functionalities
> > then fully emulate the full IPM, which is rich in functionalities !)
> 
> Just be aware that there is already an open source project named gpm:
> the "General Purpose Mouse interface", providing mouse and copy &
> paste functionality on the Linux text console:
> https://nico.schottelius.org/software/gpm/
> https://packages.debian.org/stable/gpm
> 
> Chances for a file conflict on Debian are though rather low as the
> existing gpm is installed as /usr/sbin/gpm, i.e. not in a directory
> where user-called software will be installed.
> 

Ha, ok, but absolutely no chance of conflict
since it will just an internal functionality,
not in the path (maybe a gpm.pro)

A.

Re: [gnudatalanguage-devel] IDL Package Manager IPM --> GPM

[Axel B. <ab...@de...>]

Hi,

On Thu, Dec 06, 2018 at 12:52:00PM +0100, Alain Coulais wrote:
> in IDL 8.7.1, IDL added IPM, the IDL Package Manager
> 
> https://www.harrisgeospatial.com/docs/whatsnew.html
[…]
> Now we have a name IPM, a !PACKAGE_PATH ...
> https://www.harrisgeospatial.com/docs/prefs_directory.html#PACKPATH
> 
> Shall we fit with the IDL template ?! Or start with a GPM ?
> (we can start with a simple GPM subset of functionalities
> then fully emulate the full IPM, which is rich in functionalities !)

Just be aware that there is already an open source project named gpm:
the "General Purpose Mouse interface", providing mouse and copy &
paste functionality on the Linux text console:
https://nico.schottelius.org/software/gpm/
https://packages.debian.org/stable/gpm

Chances for a file conflict on Debian are though rather low as the
existing gpm is installed as /usr/sbin/gpm, i.e. not in a directory
where user-called software will be installed.

		Kind regards, Axel
-- 
PGP: 2FF9CD59612616B5      /~\  Plain Text Ribbon Campaign, http://arc.pasp.de/
Mail: ab...@de...  \ /  Say No to HTML in E-Mail and Usenet
Mail+Jabber: ab...@no...  X
https://axel.beckert.ch/   / \  I love long mails: https://email.is-not-s.ms/

[gnudatalanguage-devel] IDL Package Manager IPM --> GPM

[Alain C. <ala...@ob...>]

Hi

in IDL 8.7.1, IDL added IPM, the IDL Package Manager

https://www.harrisgeospatial.com/docs/whatsnew.html


We discussed adding such king of utility before
and I have somewhere a draft for easy install 
of Debian Astro GDL packages (idlastro, mpfit, coyote)
but I was not satisfy (no simple name, 
no clear way for repository)

Now we have a name IPM, a !PACKAGE_PATH ...
https://www.harrisgeospatial.com/docs/prefs_directory.html#PACKPATH

Shall we fit with the IDL template ?! Or start with a GPM ?
(we can start with a simple GPM subset of functionalities
then fully emulate the full IPM, which is rich in functionalities !)


I think it can be very useful for beginners
and also for us to package or promote some packages
(and also to extend test cases ...)

best regards

A.


I think we can also add a list of aliases

GPM, /install, lib='idlastro'

Re: [gnudatalanguage-devel] idl postscript plots in gdl

[Lucio C. <lu...@la...>]

First of all my apologies for the spam-filter blocking (I did not expect 
replies to come from poster's address but from the mailing list, I have 
now included the subject tag in the whitelisting rules).

On Thu, 18 Oct 2018, Greg Jung wrote:

> The best place nowdays to get current with GDL is on github 
> https://github.com/gnudatalanguage where 
> https://github.com/gnudatalanguage/gdl/issues/463#issuecomment-424628768

I was aware of the recent move from sourceforge to github, actually I 
downloaded from there, but I must say the "documentation" part is a bit 
hidden. What I'm looking for is sort of a "migration guide for idl users".
Does such a beast exhist ?

> PSLib is itself an old source, and not maintained.  The SVG device is 
> probably the best answer for hardcopy

I am not actually that interested in hardcopies (although svg could be 
an interesting way to put plots on the web). The point (besides the 
fact I do not know svg at all while I'm quite keen on Postscript also for 
fun "writing ps files by hand" 
http://sax.iasf-milano.inaf.it/~lucio/WWW/Opinions/postscriptum.html) is 
that scientific journals require postscript or pdf files, Nobody I know in 
the astronomical community has been using svg.

So what you say on PSlib (or GDL support to postscript in general) is sad 
news. Thanks anyhow.

-- 
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------
"All that is google does not glitter
  Nor all who use alpine/procmail are lost"

[gnudatalanguage-devel] idl postscript plots in gdl

[Lucio C. <lu...@la...>]

I am a long time idl user (*) and I have just installed gdl Version 0.9.8 
git on openSUSE Leap 42.3 (when I tried on my old suse 11 there were too 
many library incompatibilities).

(*) one of my main uses of idl is as a plotter, to produce figures for 
publication or internal use. Also I am not the kind of person who runs 
after any new feature in version n.m, but rather I'd like a stable core 
with basic idl functionalities.

I followed the suggestion to use cmake .. -LAH | grep -A1 "// GDL: " to 
find out presence of optional libraries (it is indeed an handy tool), and 
in a first instance I added those available in the opensuse repository
and built gdl with

cmake .. -DGEOTIFF=OFF -DNETCDF=OFF -DHDF=OFF -DPYTHON=OFF -DEIGEN3=OFF 
-DPSLIB=OFF -DCMAKE_INSTALL_PREFIX=/Milano/Software/gdl

I then picked up a selection of my procedures and scripts and found that 
most of them worked nicely, including those dealing with binary files and 
/structures. Great !

However I found out there are problems producing postscript plots.

- first I got this message "Warning: pslib support is mandatory for the
   PostScript driver to handle correctly the following keywords:
   [X,Y]OFFSET, [X,Y]SIZE, SCALE_FACTOR"

   So I recovered pslib, compiled and installed it and rebuilt gdl
   removing -DPSLIB=OFF

- then I re-tested my maximal test plot (a 20-page complex stuff) and
   in THIS case I got repeated messages

   % Warning: multi-page PostScript not supported yet (FIXME!)

- In the remainder I refer to the last build (with pslib) as "gdl"
   and to the previous as "gdl-nopslib" (actually I kept executables
   of both)

- only at this stage I inspected the produced postscript files and
   found out that gdl-nopslib actually produced a valid 20 page plot,
   rather similar to the original idl one (with the bounding box
   somewhere differently located in the page, also pages in %%Page
   are numbered 1-20 instead of 0-19 as in idl), while gdl produces 20
   almost empty plots (except for the label of the first page)

   This is simply due to recurrent calls of "plot" (in a loop, if I
   replace for j=0,19 to e.g. for j=5,5 I can produce a single page
   OK).

   So since I won't need to actually repeat any old plot (and multipage
   plots are not for publication but mainly for internal use), I would
   just take note. A possible workaround would be to produce multipage
   plots one by one and concatenate the files later.

- then I tried with a somewhat simpler plot (six frames in a page)
   and here both gdl and gdl-nopslib (with somewhat different bounding
   box) give these messages

   Warning: Keyword parameter HELVETICA not supported in call to: DEVICE.
   Warning: Keyword parameter FONT_SIZE not supported in call to: DEVICE.
   *** PLPLOT WARNING ***
   '+', '-', and 'b/B' text escape sequences not processed.

I wonder whether there is a checklist of postscript features not (yet?)
supported in GDL, and/or a description of the viewport positioning with 
and without pslib,

... and a general gdl "user" documentation

I found a reference to http://gnudatalanguage.sourceforge.net/gdl.pdf
but it looks a 2012 draft.

Also online help like ?plot gives

% Expression must be a scalar or 1 element array in this context.
% Error occurred at: ONLINE_HELP        124

(I sometime need to be reminded of the calling sequence of some routine 
and found the online help helpful)

Thanks

-- 
Lucio Chiappetti - INAF/IASF - via Bassini 15 - I-20133 Milano (Italy)
For more info : http://www.iasf-milano.inaf.it/~lucio/personal.html
------------------------------------------------------------------------
"All that is google does not glitter
  Nor all who use alpine/procmail are lost"

[gnudatalanguage-devel] a GDL paper in referee journal ?

[Alain C. <ala...@ob...>]

Hi

We already discussed this point in the past
but, yes, it would be great to have a paper,
in a referee journal 
(eg https://www.journals.elsevier.com/astronomy-and-computing ???)
if possible in a open access context.

I received question "how to cite GDL" and, up to now,
except the ADASS papers, nothing

I am not sure it is that a large work to do it

the python consortium already did it

Alain

Re: [gnudatalanguage-devel] Clean room reimplementation of SAVE and RESTORE anyone?

[Ole S. <gdl...@li...>]

Alain Coulais <ala...@ob...> writes:
> Thanks to Gilles, since mid of December 2017,
> SAVE & RESTORE are intrinsic (and written in C/c++) in GDL.
> (based on XDR lib (bsd-xdr library). A problem
> for recent GCC version, with the need of tirpc lib ...)

Ah, I didn't check the C++ sources; only the .pro files (which refer to
CMSVLIB). Great to see it there! Nice work!

Best

Ole

Re: [gnudatalanguage-devel] Clean room reimplementation of SAVE and RESTORE anyone?

[Alain C. <ala...@ob...>]

Le Fri, 14 Sep 2018 11:21:36 +0200,
Ole Streicher <gdl...@li...> a écrit :

> Hi all,
> 
> I am not sure whether this was brought up already...
> 
> The current GDL version lacks the functionality of "save" files (SAVE
> and RESTORE). 

Hi

Thanks to Gilles, since mid of December 2017,
SAVE & RESTORE are intrinsic (and written in C/c++) in GDL.
(based on XDR lib (bsd-xdr library). A problem
for recent GCC version, with the need of tirpc lib ...)

It is available in 0.9.8 vanilla

It can be tested by "test_save_restore.pro"

best regards

A.

PS: performance are very good, as fast as the IDL one,
 on "very large" (few Gb) files in reading & writing
--tested also on experimental data written with pointers--

> The current GDL implementation requires the (non-free)
> CMSVLIB by Craig B. Marwardt for this.
> 
> However, Craig also wrote a specification of the data format (he
> reverse engineered it):
> 
> http://cow.physics.wisc.edu/~craigm/idl/savefmt.pdf
> http://cow.physics.wisc.edu/~craigm/idl/savefmt
> 
> which would allow a clean-room implementation. So, anyone who is
> interested (except Craig himself) could just take this document and
> write a GPLled implementation without violating RSIs copyright.
> 
> https://en.wikipedia.org/wiki/Clean_room_design
> 
> Cheers
> 
> Ole
> 
> 
> _______________________________________________
> gnudatalanguage-devel mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnudatalanguage-devel

[gnudatalanguage-devel] Clean room reimplementation of SAVE and RESTORE anyone?

[Ole S. <gdl...@li...>]

Hi all,

I am not sure whether this was brought up already...

The current GDL version lacks the functionality of "save" files (SAVE and
RESTORE). The current GDL implementation requires the (non-free) CMSVLIB
by Craig B. Marwardt for this.

However, Craig also wrote a specification of the data format (he reverse
engineered it):

http://cow.physics.wisc.edu/~craigm/idl/savefmt.pdf
http://cow.physics.wisc.edu/~craigm/idl/savefmt

which would allow a clean-room implementation. So, anyone who is
interested (except Craig himself) could just take this document and
write a GPLled implementation without violating RSIs copyright.

https://en.wikipedia.org/wiki/Clean_room_design

Cheers

Ole

Re: [gnudatalanguage-devel] GIT: a space for exchanges

[Sylwester A. <sl...@st...>]

Alain, All,

On 17/06/18 22:21, Alain Coulais wrote:
> I did not found a space for exchanges in the Git Repo
> (all in PR or Issues :(

It's part of the gnudatalanguage organisation 
(https://github.com/gnudatalanguage) and it's related with the "teams" 
functionality (https://github.com/orgs/gnudatalanguage/teams) where we 
already have the @gdlteam list aimed to resemble gnudatalanguage-devel 
list (https://github.com/orgs/gnudatalanguage/teams/gdlteam).

Whoever on the hereby mailing list is not part of the @gdlteam and wants 
to be, please just send us your github login name.

> The topics I would like to discuss :
> 
> * the need for a 0.9.8-1 ASAP !
> * what to wait for a 0.9.9 ?
> * what should be in a 1.0 ??

Perhaps we could follow up here on all of the above:
https://github.com/orgs/gnudatalanguage/teams/gdlteam/discussions/3

> * how to focus for a MS-win release

The news is that we have now automatic Windows builds + test execution 
for every PR using Appveyor. As of now this is limited to 32-bit mingw 
with minimal set of dependencies, but hope to have much more included 
within the next weeks.

It would be great to have gdl included in some of the Windows package 
systems:
- https://cygwin.com/packaging-contributors-guide.html
- https://github.com/msys2/msys2/wiki/Creating-Packages
- https://github.com/Microsoft/vcpkg/blob/master/CONTRIBUTING.md
- https://chocolatey.org/docs/create-packages
- http://mxe.cc/#creating-packages
Anyone could help?

Best,
Sylwester

[gnudatalanguage-devel] GIT: a space for exchanges

[Alain C. <ala...@ob...>]

Hi

I did not found a space for exchanges in the Git Repo
(all in PR or Issues :(


The topics I would like to discuss :

* the need for a 0.9.8-1 ASAP !
* what to wait for a 0.9.9 ?
* what should be in a 1.0 ?? 
* how to focus for a MS-win release 


A.

[gnudatalanguage-devel] GDL & OSX

[Alain C. <ala...@ob...>]

Hi all

tested on a up-to-date OSX 10.13.4

1/ GDL & Brew

in mid-December just after I finished a tuto for OSX, the
homebrew-science was declared obsolete without clear documentation or
alternative

$ brew tap Homebrew/homebrew-science
Error: homebrew/science was deprecated. This tap is now empty as all
its formulae were migrated.

Now, we have a solution !

https://github.com/brewsci/homebrew-science/blob/master/README.md

brew tap brewsci/science
brew install gnudatalanguage

this is the 0.9.7-4 version, which is OK when run from Xquartz

You may need to unlink plplot if a previous version of
it was install before (then it is install again for GDL)

2/ OpenMP on OSX

As Eric H. recalled to us yesterday, GDL does not compiled with OpenMP
(historical reasons)
That need to be fixed !

3/ GDL without Xquartz

On remote (ssh -X), no problem

On local, when started in a terminal "outside" Xquartz, GDL
cannot gives plots

Two cases :

brew version :

GDL> plot, findgen(100)  
% Cannot connect to X server
% Execution halted at: $MAIN$

compiled from sources :

GDL> plot, findgen(100)  
% PLplot installation lacks the requested driver: xwin
% Execution halted at: $MAIN$

(those problems do not happen when we launch GDL from
a terminal provided by Xquartz. Furthermore, the graphical outputs
are of poor quality when started from a terminal not provided
by Xquartz (and Xquartz launched))

It would be great to have a better message



I have a question ! 
Who remember what is the MAC device we have in the device list on OSX ?!


best regards

A.

[gnudatalanguage-devel] large chnage between 5 & 20 March : I am lost !

[Alain C. <ala...@ob...>]

Hi

Today, with a colleague also working with GDL on OSX, we processed
experiment data :)

It is not really a problem  that I got more than 4 or 5 minor *bugs*
(or unfinished features), few are know or very old : details !
(I have a list ...)


But I have a *big* bug after the big change between
March 5 & 20, with more than 30 files changed  !!!
And I have no idea how to fix it !

Yes, reproducible on OSX (10.12) & Linux (u 16.04)

thanks for the help !

Alain

PS: and a strange change now in some plots : the axis
arrived after the plot of data (yes, data with millions of points ...)

PS: testing ? just doing :

plot, findgen(10000)      
surface, findgen(10,10)

surface is plotted in lower left corner ... minuscule !

recover good scales after doing a call to /dev helps, in two steps :

surface, findgen(10,10),/dev  <-- bad but better
surface, findgen(10,10)     <-- OK  

[gnudatalanguage-devel] C++ return types

[Orion P. <or...@nw...>]

One thing that as come up with GCC 8 are C++ warnings like this:

warning: no return statement in function returning non-void [-Wreturn-type]

Which can lead to crashes as this is undefined behavior in C++.  So I've
started taking a look at those warnings in GDL.  One that I can't figure out is:

/builddir/build/BUILD/gdl-0.9.8/src/saverestore.cpp:167:3: warning: no return
statement in function returning non-void [-Wreturn-type]

This is here:

   uint32_t writeEnd(XDR *xdrs) {
     uint32_t cur=writeNewRecordHeader(xdrs, 6);
   }

I think we're missing "return cur"?

It's called here:

    nextptr=writeEnd(xdrs);

but then nextptr is never accessed.


There are also a lot of warning like:

/builddir/build/BUILD/gdl-0.9.8/src/basic_pro_jmg.cpp:297:13: warning: control
reaches end of non-void function [-Wreturn-type]

for functions that must return earlier and end with something like:

    assert( false);
  }

I'm thinking of adding:

  return 0  // Not reached

to at least quiet the warning.  Thoughts?

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [gnudatalanguage-devel] SF : pb with link to latest TGZ

[Sylwester A. <sl...@st...>]

All,

On 11/04/18 19:43, Alain Coulais wrote:> see from here, if I click on 
the "download" link
> https://sourceforge.net/projects/gnudatalanguage/
> on the main page
> 
> I got :  gdl-0.9.7.tgz
> 
> I look around but found nothing to change that behaviour ...

Just for the record, there are 17 releases of GDL archived on github as 
well (thank Ole!) listed at https://github.com/gnudatalanguage/gdl/releases

0.9.8 is available for download at:
https://github.com/gnudatalanguage/gdl/archive/v0.9.8.tar.gz

Sylwester

Re: [gnudatalanguage-devel] 0.9.8 ?!

[Alain C. <ala...@ob...>]

Le Wed, 11 Apr 2018 10:58:47 -0600,
Orion Poplawski <or...@nw...> a écrit :

> On 03/26/2018 12:54 PM, Alain Coulais wrote:
> > Le Mon, 26 Mar 2018 12:02:29 -0600,
> > Orion Poplawski <or...@nw...> a écrit :
> > 
> >> On 03/26/2018 04:06 AM, Alain Coulais wrote:
> >>>
> >>> no objection ?
> >>>
> >>> https://sourceforge.net/projects/gnudatalanguage/files/gdl/0.9.8/
> >>>
> >>> A.
> >>
> >> I'm seeing lots of test failures.  It also appears that test
> >> failures no longer fail "make check", which is disturbing.
> >> Although now that I look back at older 0.9.7 builds this has been
> >> the case for a while
> >> - at least for tests that segfault - which are probably due to
> >> display issues with the build environment.
> >>
> >> See
> >> https://kojipkgs.fedoraproject.org//work/tasks/299/25990299/build.log
> >> for details.  Look at the %check section.
> >>
> > 
> > ok, I will look at that !
> > 
> >> On the positive side, looks like test_sem may not only be failing
> >> on i386 now, and test_xdr is now working on arm.
> > 
> > * one very important test is : test_save_restore.pro 
> > 
> > 
> > * many tests should failed because we have pending issues
> > in not urgent cases : 
> > 
> > test_fix, test_total, test_rounding, test_file_delete
> > 
> > totally unclear for me : test_resolve_routine.pro
> > 
> > to be fixed : test_n_tags.pro
> > 
> > missing : test_obj_isa.pro
> > 
> > "parse_url" to be rewrite to fit IDL : test_parse_url.pro
> > (excellent work for an intern)
> > 
> > * test_sem : in fact, Gilles removed test in "test_sem" 
> > because the test case is not well written 
> > 
> > working for him (Mageia)
> > not working for me on several cases (ubuntu, osx), ok on CentOS
> 
> So here's an updated set of failures on EL7 x86_64:
> 
> The following tests FAILED:
>          93 - test_fft_leak.pro (Failed) -
> https://github.com/gnudatalanguage/gdl/issues/147
>          96 - test_file_delete.pro (Failed) -
> https://github.com/gnudatalanguage/gdl/issues/148
>         103 - test_fix.pro (Failed) -
> https://github.com/gnudatalanguage/gdl/issues/149
>         106 - test_formats.pro (Failed) -
> https://github.com/gnudatalanguage/gdl/issues/144
>         140 - test_n_tags.pro (Failed) -
> https://github.com/gnudatalanguage/gdl/issues/150
>         142 - test_obj_isa.pro (Failed) -
> https://github.com/gnudatalanguage/gdl/issues/151
>         144 - test_parse_url.pro (Failed) -
> https://github.com/gnudatalanguage/gdl/issues/153
>         166 - test_resolve_routine.pro (Failed) -
> https://github.com/gnudatalanguage/gdl/issues/146
>         168 - test_rounding.pro (Failed) -
> https://github.com/gnudatalanguage/gdl/issues/154
>         190 - test_total.pro (Failed) -
> https://github.com/gnudatalanguage/gdl/issues/155


OK, sorry for that, it is not real failures, just missing features !

nothing unexpected !

I hope we will have most of then implemented before summer holidays !

> 
> Still have serious issue with Fedora 28+ and gcc 8.  Seems to
> segfault deep in antlr parser code.

I am afraid not being able to help for that

A.

Re: [gnudatalanguage-devel] 0.9.8 ?!

[Orion P. <or...@nw...>]

On 03/26/2018 12:54 PM, Alain Coulais wrote:
> Le Mon, 26 Mar 2018 12:02:29 -0600,
> Orion Poplawski <or...@nw...> a écrit :
> 
>> On 03/26/2018 04:06 AM, Alain Coulais wrote:
>>>
>>> no objection ?
>>>
>>> https://sourceforge.net/projects/gnudatalanguage/files/gdl/0.9.8/
>>>
>>> A.
>>
>> I'm seeing lots of test failures.  It also appears that test
>> failures no longer fail "make check", which is disturbing.  Although
>> now that I look back at older 0.9.7 builds this has been the case for
>> a while
>> - at least for tests that segfault - which are probably due to
>> display issues with the build environment.
>>
>> See
>> https://kojipkgs.fedoraproject.org//work/tasks/299/25990299/build.log
>> for details.  Look at the %check section.
>>
> 
> ok, I will look at that !
> 
>> On the positive side, looks like test_sem may not only be failing on
>> i386 now, and test_xdr is now working on arm.
> 
> * one very important test is : test_save_restore.pro 
> 
> 
> * many tests should failed because we have pending issues
> in not urgent cases : 
> 
> test_fix, test_total, test_rounding, test_file_delete
> 
> totally unclear for me : test_resolve_routine.pro
> 
> to be fixed : test_n_tags.pro
> 
> missing : test_obj_isa.pro
> 
> "parse_url" to be rewrite to fit IDL : test_parse_url.pro
> (excellent work for an intern)
> 
> * test_sem : in fact, Gilles removed test in "test_sem" 
> because the test case is not well written 
> 
> working for him (Mageia)
> not working for me on several cases (ubuntu, osx), ok on CentOS

So here's an updated set of failures on EL7 x86_64:

The following tests FAILED:
         93 - test_fft_leak.pro (Failed) -
https://github.com/gnudatalanguage/gdl/issues/147
         96 - test_file_delete.pro (Failed) -
https://github.com/gnudatalanguage/gdl/issues/148
        103 - test_fix.pro (Failed) -
https://github.com/gnudatalanguage/gdl/issues/149
        106 - test_formats.pro (Failed) -
https://github.com/gnudatalanguage/gdl/issues/144
        140 - test_n_tags.pro (Failed) -
https://github.com/gnudatalanguage/gdl/issues/150
        142 - test_obj_isa.pro (Failed) -
https://github.com/gnudatalanguage/gdl/issues/151
        144 - test_parse_url.pro (Failed) -
https://github.com/gnudatalanguage/gdl/issues/153
        166 - test_resolve_routine.pro (Failed) -
https://github.com/gnudatalanguage/gdl/issues/146
        168 - test_rounding.pro (Failed) -
https://github.com/gnudatalanguage/gdl/issues/154
        190 - test_total.pro (Failed) -
https://github.com/gnudatalanguage/gdl/issues/155

Still have serious issue with Fedora 28+ and gcc 8.  Seems to segfault deep in
antlr parser code.

-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

[gnudatalanguage-devel] SF : pb with link to latest TGZ

[Alain C. <ala...@ob...>]

Hi

see from here, if I click on the "download" link
https://sourceforge.net/projects/gnudatalanguage/
on the main page

I got :  gdl-0.9.7.tgz

I look around but found nothing to change that behaviour ...

thanks to solve it or help me to solve it !!

Alain

PS: yes I connected, and I am supposed to be an admin ...

Re: [gnudatalanguage-devel] [[gdl-announces]] GDL 0.9.8 delivered

[Orion P. <or...@nw...>]

On 03/26/2018 06:04 AM, Alain Coulais wrote:
> 
> Dear GDL users and contributors,
> 
> GDL 0.9.8 is now available here :
> https://sourceforge.net/projects/gnudatalanguage/files/gdl/0.9.8/

Another issue with the tarball.  It contains a stale link:


 $ ls -l /export/home/orion/fedora/gdl/gdl-0.9.8/src/gdl
lrwxrwxrwx. 1 orion orion 43 Mar 26 03:57
/export/home/orion/fedora/gdl/gdl-0.9.8/src/gdl ->
/home/coulais/GDL/gdl-098/gdl/build/src/gdl

Which lead to:

/usr/bin/cmake -E create_symlink
/export/home/orion/fedora/gdl/gdl-0.9.8/build/src/gdl
/export/home/orion/fedora/gdl/gdl-0.9.8/src/gdl
make[2]: *** [CMakeFiles/symlink_gdl] Error 1

with cmake 2.8.12.  cmake 3 seems to not care.


-- 
Orion Poplawski
Manager of NWRA Technical Systems          720-772-5637
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       or...@nw...
Boulder, CO 80301                 https://www.nwra.com/

Re: [gnudatalanguage-devel] GDL : OSX, openmp and "minmax_include.cpp"

[Ole S. <gdl...@li...>]

Sylwester Arabas <sl...@st...> writes:
> As I've written in my previous list posting, please do continue
> committing to SVN if using github would be a huge problem at this

Github also allows to be accessed via subversion:

https://help.github.com/articles/support-for-subversion-clients/

I never tried that; it may however a solution until you (Alain) get
familar with git :-)

Cheers

Ole

Re: [gnudatalanguage-devel] GDL : OSX, openmp and "minmax_include.cpp"

[Sylwester A. <sl...@st...>]

On 10/04/18 17:37, Alain Coulais wrote:
> And warning for 'finite' is deprecated: first deprecated
> 
> /Users/coulais/GDL/gdl-0.9.8svn180410CMake/src/minmax_include.cpp:327:11:
> warning: 'finite' is deprecated: first deprecated in macOS 10.9
> [-Wdeprecated-declarations] AVOID_INF
>            ^
> /Users/coulais/GDL/gdl-0.9.8svn180410CMake/src/minmax_include.cpp:42:35:
> note: expanded from macro 'AVOID_INF' #define AVOID_INF if (omitNaN
> && !finite(COMPLEX_ABS((*this)[i]))) continue; ^
> /usr/include/math.h:757:12: note: 'finite' has been explicitly marked
> deprecated here extern int finite(double)
> __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0, __MAC_10_9, __IPHONE_NA,
> __IPHONE_NA); ^

I've opened a ticket for it here:
https://github.com/gnudatalanguage/gdl/issues/70

S.

Re: [gnudatalanguage-devel] GDL : OSX, openmp and "minmax_include.cpp"

[Sylwester A. <sl...@st...>]

Alain, to whom it may concern,

On 10/04/18 17:22, Alain Coulais wrote:
> I even don't realize if I should continue to commit on SVN !

As I've written in my previous list posting, please do continue 
committing to SVN if using github would be a huge problem at this 
moment, or if this would make it easier to commit already developed code 
- I'll convert these commits into github pull requests. Please notify me 
if this would not be your intention.

Will do that today for your yesterday's r4096.

Of course, it would be great to switch, but I don't want the github 
initiative to be a headache for anyone! On the contrary.

For the moment, I'm opening a "ticket" on github to monitor these 
post-migration commits: https://github.com/gnudatalanguage/gdl/issues/127

> OK, current version of "minmax_include.cpp" does not compiled
> on OSX 10.12, I made few attempts to overpass it,
> without success ...
> 
> And I have no idea to do if the "gomp.h" is not around !
> 
> /Users/coulais/GDL/gdl-0.9.8svn180410CMake/src/minmax_include.cpp:248:27:
> error: use of undeclared identifier
>        'omp_get_thread_num'
>            int thread_id = omp_get_thread_num();

I guess this is already addressed by Gilles' pull request:
https://github.com/gnudatalanguage/gdl/pull/31/commits/fd94847f1c70672ff85d8c34da7d9fcaecea5bef

Sylwester

Re: [gnudatalanguage-devel] GDL : OSX, openmp and "minmax_include.cpp"

[Alain C. <ala...@ob...>]

> OK, current version of "minmax_include.cpp" does not compiled
> on OSX 10.12, I made few attempts to overpass it, 
> without success ...
> 
> And I have no idea to do if the "gomp.h" is not around !
> 
> /Users/coulais/GDL/gdl-0.9.8svn180410CMake/src/minmax_include.cpp:248:27:
> error: use of undeclared identifier
>       'omp_get_thread_num'
>           int thread_id = omp_get_thread_num();
> 

And complains also :

/Users/coulais/GDL/gdl-0.9.8svn180410CMake/src/minmax_include.cpp:331:19:
error: variable length array of non-POD element type 'Ty' (aka
'basic_string<char, char_traits<char>, allocator<char> >') Ty
maxVArray[CpuTPOOL_NTHREADS];



And warning for 'finite' is deprecated: first deprecated


/Users/coulais/GDL/gdl-0.9.8svn180410CMake/src/minmax_include.cpp:327:11:
warning: 'finite' is deprecated: first deprecated in macOS 10.9
[-Wdeprecated-declarations] AVOID_INF
          ^
/Users/coulais/GDL/gdl-0.9.8svn180410CMake/src/minmax_include.cpp:42:35:
note: expanded from macro 'AVOID_INF' #define AVOID_INF if (omitNaN
&& !finite(COMPLEX_ABS((*this)[i]))) continue; ^
/usr/include/math.h:757:12: note: 'finite' has been explicitly marked
deprecated here extern int finite(double)
__OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0, __MAC_10_9, __IPHONE_NA,
__IPHONE_NA); ^

[gnudatalanguage-devel] GDL : OSX, openmp and "minmax_include.cpp"

[Alain C. <ala...@ob...>]

Hi all

sorry to use this way to post my problem,
I am totally loose with GitLab messages,
no time now ... (and I had email problems last WE)

I even don't realize if I should continue to commit on SVN !



OK, current version of "minmax_include.cpp" does not compiled
on OSX 10.12, I made few attempts to overpass it, 
without success ...

And I have no idea to do if the "gomp.h" is not around !

/Users/coulais/GDL/gdl-0.9.8svn180410CMake/src/minmax_include.cpp:248:27:
error: use of undeclared identifier
      'omp_get_thread_num'
          int thread_id = omp_get_thread_num();