gnudatalanguage / gdl Goto Github PK

GDL - GNU Data Language

License: GNU General Public License v2.0

CMake 0.78% Makefile 1.04% C++ 63.11% Shell 0.24% GAP 2.28% C 7.14% IDL 19.91% Prolog 0.84% Python 0.09% Fortran 0.01% Roff 4.45% NSIS 0.07% TeX 0.05%

astronomy data-analysis antlr python pv-wave programming-language geophysics mapping scientific-computing scientific-visualization

gdl's People

Contributors

Stargazers

Watchers

gdl's Issues

no lineno info in error mesgs using @ (also wrong filename in error message)

As reported on SF.net (https://sourceforge.net/p/gnudatalanguage/bugs/212/)

When instructions are read from a file using the '@' operator in interactive mode, no information on line number is included in the error message:

GDL> $cat const.pro
n[0] = 2
n[1,] = 1
GDL> @const.pro
% Variable is undefined: N
% Execution halted at: $MAIN$     
% Parser syntax error: unexpected token: ]

IDL> @const.pro

n[1,] = 1
^
% Syntax error.
At: /Users/slayoo/Temp/const.pro, Line 2

When including such bogus file from within a routine, the line number information is printed but the filename is wrong:

GDL> $cat aqq.pro
pro aqq
; read const
@const.pro
end
GDL> aqq
% Parser syntax error: unexpected token: ]
At: aqq.pro, Line 2 Column 5

IDL> aqq

n[1,] = 1
^
% Syntax error.
At: /Users/slayoo/Temp/const.pro, Line 2

Confirmed still present in 0.9.8

[0.9.8] Regression with mpfit test

With version 0.9.8, the Debian mpfit test fails. The test is

FUNCTION fitfunc, p, x=x, y=y, err=err
  gauss = p[0]*exp(-(x-p[1])^2/(2*p[2]^2))
  return, (y - gauss)/err
END

PRO test_mpfit
  x = findgen(101)
  y = 25.*exp(-(x-32.)^2/(2*5.^2))+2.*randomn(0,101)
  err = 0.1*y
  start_params = [10.,45.,10.]
  functargs = {x:x, y:y, err:err}
  params = mpfit("fitfunc",start_params,functargs=functargs)
  ref = [28.2524, 31.9683, -4.26773]
  print, params, ref
  for i = 0, 2 do $
     if params[i] lt ref[i]-.5 || params[i] gt ref[i]+.5 then exit, status=1
  exit, status=0
END

With version 0.9.7, we get the following result:

% Compiled module: TEST_MPFIT.
% Compiled module: MPFIT.
Iter      1   CHI-SQUARE =       4190239.5          DOF = 98
                         P(0) =              10.0000
                         P(1) =              45.0000
                         P(2) =              10.0000
Iter      2   CHI-SQUARE =       10100.730          DOF = 98
                         P(0) =         -0.000412941
                         P(1) =              44.7291
                         P(2) =              10.2571
[...]
Iter     13   CHI-SQUARE =       8029.7827          DOF = 98
                         P(0) =              28.2524
                         P(1) =              31.9683
                         P(2) =             -4.26773
      28.2524      31.9683     -4.26773
      28.2524      31.9683     -4.26773

Whith 0.9.8, one gets the following, wrong result:

% Compiled module: TEST_MPFIT.
% Compiled module: MPFIT.
Iter      1   CHI-SQUARE =       2531160.5          DOF = 98
                         P(0) =              10.0000
                         P(1) =              45.0000
                         P(2) =              10.0000
Iter      2   CHI-SQUARE =       11089.251          DOF = 98
                         P(0) =             0.186433
                         P(1) =              44.5224
                         P(2) =              10.1031
[...]
Iter     23   CHI-SQUARE =       8206.9775          DOF = 98
                         P(0) =              27.4550
                         P(1) =              31.5766
                         P(2) =              3.97340
      27.4550      31.5766      3.97340
      28.2524      31.9683     -4.26773

Relevant Debian bug report: #895119

Shared library (for python module)

As:

requested back in 2005 on SF.net by @smaret: https://sourceforge.net/p/gnudatalanguage/feature-requests/11/
discussed also here: https://sourceforge.net/p/gnudatalanguage/patches/95/ with @olebole and @maynardGK
implemented by @olebole inthe Debian package: https://sources.debian.org/patches/gnudatalanguage/0.9.8-2/Create-a-shared-library.patch/
it seems worth to offer the option to build GDL as a shared library.

add "implied print"

(https://sourceforge.net/p/gnudatalanguage/feature-requests/150/)

As reported by @GillesDuvert on SF.net:

Almost there if enabling AUTO_PRINT_EXPR in dinterpreter.cpp
See the related discussion: https://sourceforge.net/p/gnudatalanguage/discussion/338692/thread/3bfdc705/?limit=25#e58d

handling garbage on stdin

(extracted from ulysss's comments at https://sourceforge.net/p/gnudatalanguage/bugs/711/)

$ echo ugly_test | idl
% Attempt to call undefined procedure/function: 'UGLY_TEST'.
% Execution halted at: $MAIN$

$ echo ugly_test | gdl
% Procedure not found: UGLY_TEST
% Execution halted at: $MAIN$
terminate called without an active exception
Aborted

include setup.py

(https://sourceforge.net/p/gnudatalanguage/feature-requests/11/)

As requested back in 2005 by @smaret, it would be useful for Python users for GDL to ship with a setup.py script that would place the Python module in the correct location (probably this could also be triggered by make install).

launchtest linking problem on Linux/Intel compiler

As depicted here: https://travis-ci.org/slayoo/gdl/builds/362621901
in some cases execution of tests seems to be impossible on Travis Linux machines due to linkage problem:

CMakeFiles/launchtest.dir/launchtest.c.o: In function `main':
launchtest.c:(.text+0x3b): undefined reference to `__kmpc_begin'
launchtest.c:(.text+0x4d): undefined reference to `__kmpc_end'
launchtest.c:(.text+0xef): undefined reference to `__kmpc_end'
launchtest.c:(.text+0x10d): undefined reference to `__kmpc_end'

try out jupyter backend as a candidate for documentation engine

as noted by @GillesDuvert, there exist already a jupyter backend aimed at supporting GDL: https://github.com/lstagner/idl_kernel

CURSOR is no interuptable by ctrl-C

As reported by @alaingdl back in 2010 on SF.net (https://sourceforge.net/p/gnudatalanguage/bugs/205/):

When X11 mode active, CURSOR is not interuptable

I do try to add to add
if( sigControlC) return;
in while loops (3 loops)
without effects ...

Further comments:

by Marc on 2010-03-14:

Fixing would be difficult as plGetCursor waits.
Maybe in a future plplot version...

by @GillesDuvert on 2013-03-20:

It is now. I have rewritten cursor.
BTW, using cursor, one can move the cursor also with the keyboard arrows and speed it using modifiers combinations (ctrl,shift,alt).

Travis scripts TODOs

Tests that were disabled on Travis as failing at the time of SF->github migration:

shorthand notation for loop in command line mode

(https://sourceforge.net/p/gnudatalanguage/bugs/174/)

IDL> for i=0,2 do begin print,i
0
1
2

GDL> for i=0,2 do begin print,i
% Parser syntax error: unexpected end of file

Reported on SF.net back in 2009, and later mentioned in 2012 here:
https://sourceforge.net/tracker/index.php?func=detail&aid=3475493&group_id=97659&atid=618683

recreate pull request from #5 from gdl.off

@opoplawski unfortunatelly, we've needed to reimport the svn repo (to avoid directory reshuffling), could you please redirect your previous catch-by-reference PR to the new repo? Thanks
https://github.com/gnudatalanguage/gdl.off/pull/5

"Internal error: FCALL_LIB_RETNEW as left expr" instead of an error message

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/300/)
As reported on SF:

GDL> (strarr(1))[2] = 1
% Internal error: FCALL_LIB_RETNEW as left expr.
% Execution halted at: $MAIN$

IDL> (strarr(1))[2] = 1
% Expression must be named variable in this context: <STRING Array[1]>.
% Execution halted at: $MAIN$

(that's just a matter of a better error message)

[0.9.8] Does not compile on PowerPC 64 bit

This was already mentioned (originally by @opoplawski) in the mailing list: on ppc64 (both endians), the compilation fails with

[...]
cd /<<PKGBUILDDIR>>/obj-powerpc64le-linux-gnu/src && /usr/bin/c++  -DHAVE_CONFIG_H -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__WXGTK__ -Dgnudatalanguage_EXPORTS -I/usr/include/GraphicsMagick -I/usr/lib/powerpc64le-linux-gnu/wx/include/gtk2-unicode-3.0 -I/usr/include/wx-3.0 -I/usr/include/hdf5/serial -I/usr/include/hdf -I/usr/include/python2.7 -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/eigen3 -I/<<PKGBUILDDIR>> -I/<<PKGBUILDDIR>>/obj-powerpc64le-linux-gnu  -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -DBUILD_DATE="\"Apr  3 2018\"" -std=gnu++11 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC   -fopenmp -o CMakeFiles/gnudatalanguage.dir/basic_fun.cpp.o -c /<<PKGBUILDDIR>>/src/basic_fun.cpp
In file included from /<<PKGBUILDDIR>>/src/basic_fun.cpp:3936:0:
/<<PKGBUILDDIR>>/src/medianfilter.cpp: In function 'void lib::fastmedian::histogram_add(const uint16_t*, uint16_t*)':
/<<PKGBUILDDIR>>/src/medianfilter.cpp:676:14: error: missing template arguments before 'unsigned'
     *(vector unsigned short*) &y[0] = vec_add( *(vector unsigned short*) &y[0], *(vector unsigned short*) &x[0] );
              ^~~~~~~~
/<<PKGBUILDDIR>>/src/medianfilter.cpp:676:14: error: expected ')' before 'unsigned'
/<<PKGBUILDDIR>>/src/medianfilter.cpp:677:14: error: missing template arguments before 'unsigned'
     *(vector unsigned short*) &y[8] = vec_add( *(vector unsigned short*) &y[8], *(vector unsigned short*) &x[8] );
              ^~~~~~~~
/<<PKGBUILDDIR>>/src/medianfilter.cpp:677:14: error: expected ')' before 'unsigned'
/<<PKGBUILDDIR>>/src/medianfilter.cpp: In function 'void lib::fastmedian::histogram_sub(const uint16_t*, uint16_t*)':
/<<PKGBUILDDIR>>/src/medianfilter.cpp:710:14: error: missing template arguments before 'unsigned'
     *(vector unsigned short*) &y[0] = vec_sub( *(vector unsigned short*) &y[0], *(vector unsigned short*) &x[0] );
              ^~~~~~~~
/<<PKGBUILDDIR>>/src/medianfilter.cpp:710:14: error: expected ')' before 'unsigned'
/<<PKGBUILDDIR>>/src/medianfilter.cpp:711:14: error: missing template arguments before 'unsigned'
     *(vector unsigned short*) &y[8] = vec_sub( *(vector unsigned short*) &y[8], *(vector unsigned short*) &x[8] );
              ^~~~~~~~
/<<PKGBUILDDIR>>/src/medianfilter.cpp:711:14: error: expected ')' before 'unsigned'
make[3]: *** [src/CMakeFiles/gnudatalanguage.dir/build.make:426: src/CMakeFiles/gnudatalanguage.dir/basic_fun.cpp.o] Error 1

GCC version is 7.3.0. Other platforms using the same compiler version don't have this problem.
This is independent of whether -std=gnu++11 is set in CXXFLAG or not. 0.9.7 compiled fine (with gcc 7.2.0). Sample Debian build log here, corresponding Debian bug is #894324.

add keyword L64 to SORT()

(https://sourceforge.net/p/gnudatalanguage/users-contributions/13/)

As reported by @alaingdl on SF.net:

we need to add this keyword for compatibility
and also check whether the change Long/Long64
is well done now in GDL

A. + René + Ors @ miri meeting ;)

list of IDL/GDL routines with their status and remarks

Alain did a great job creating this: http://aramis.obspm.fr/~coulais/IDL_et_GDL/Matrice_IDLvsGDL_intrinsic.html

Any ideas how to streamline it here so that updates and teamwork could be easier?
Wiki? A permanent "issue" entry? Separate repository with "github pages" connected? Is markdown enough? What information to include? How to make it maintainable?

Comments welcome! I believe, from users' perspective this is very important.

automatic builds on Windows

This repo seems to have it already implemented by @pjb7687 : https://github.com/pjb7687/GNU-Data-Language-0.9.6

compiler errors with hdf5 1.10.0

As reported by Cody (https://sourceforge.net/u/roadkill-maker/) at SF.net (https://sourceforge.net/p/gnudatalanguage/bugs/699/):

I get a compiler error when using hdf5 1.10.0 It compiles fine with hdf 1.8.15. I'm on Arch linux, gcc 6.1.1.
The error is:

/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp: In function ‘BaseGDL* lib::h5a_read_fun(EnvT*)’:
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp:352:37: error: no matching function for call to ‘AssureLongScalarPar(int, hid_t&)’
     e->AssureLongScalarPar(0, h5a_id);
                                     ^
In file included from /data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.hpp:22:0,
                 from /data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp:32:
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/envt.hpp:837:8: note: candidate: void EnvT::AssureLongScalarPar(SizeT, DLong&) <near match>
   void AssureLongScalarPar( SizeT ix, DLong& scalar);
        ^~~~~~~~~~~~~~~~~~~
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/envt.hpp:837:8: note:   conversion of argument 2 would be ill-formed:
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp:352:37: error: invalid initialization of non-const reference of type ‘DLong& {aka int&}’ from an rvalue of type ‘DLong {aka int}’
     e->AssureLongScalarPar(0, h5a_id);
                                     ^
In file included from /data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.hpp:22:0,
                 from /data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp:32:
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/envt.hpp:838:8: note: candidate: void EnvT::AssureLongScalarPar(SizeT, DLong64&) <near match>
   void AssureLongScalarPar( SizeT ix, DLong64& scalar);
        ^~~~~~~~~~~~~~~~~~~
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/envt.hpp:838:8: note:   conversion of argument 2 would be ill-formed:
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp:352:37: error: invalid initialization of non-const reference of type ‘DLong64& {aka long long int&}’ from an rvalue of type ‘DLong64 {aka long long int}’
     e->AssureLongScalarPar(0, h5a_id);
                                     ^
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp: In function ‘BaseGDL* lib::h5d_read_fun(EnvT*)’:
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp:406:37: error: no matching function for call to ‘AssureLongScalarPar(int, hid_t&)’
     e->AssureLongScalarPar(0, h5d_id);
                                     ^
In file included from /data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.hpp:22:0,
                 from /data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp:32:
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/envt.hpp:837:8: note: candidate: void EnvT::AssureLongScalarPar(SizeT, DLong&) <near match>
   void AssureLongScalarPar( SizeT ix, DLong& scalar);
        ^~~~~~~~~~~~~~~~~~~
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/envt.hpp:837:8: note:   conversion of argument 2 would be ill-formed:
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp:406:37: error: invalid initialization of non-const reference of type ‘DLong& {aka int&}’ from an rvalue of type ‘DLong {aka int}’
     e->AssureLongScalarPar(0, h5d_id);
                                     ^
In file included from /data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.hpp:22:0,
                 from /data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp:32:
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/envt.hpp:838:8: note: candidate: void EnvT::AssureLongScalarPar(SizeT, DLong64&) <near match>
   void AssureLongScalarPar( SizeT ix, DLong64& scalar);
        ^~~~~~~~~~~~~~~~~~~
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/envt.hpp:838:8: note:   conversion of argument 2 would be ill-formed:
/data/Apps/AUR/gnudatalanguage/src/gdl-0.9.6/src/hdf5_fun.cpp:406:37: error: invalid initialization of non-const reference of type ‘DLong64& {aka long long int&}’ from an rvalue of type ‘DLong64 {aka long long int}’
     e->AssureLongScalarPar(0, h5d_id);
                                     ^
src/CMakeFiles/gdl.dir/build.make:1526: recipe for target 'src/CMakeFiles/gdl.dir/hdf5_fun.cpp.o' failed
make[2]: *** [src/CMakeFiles/gdl.dir/hdf5_fun.cpp.o] Error 1
CMakeFiles/Makefile2:124: recipe for target 'src/CMakeFiles/gdl.dir/all' failed
make[1]: *** [src/CMakeFiles/gdl.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

Further comment by @GillesDuvert:

According to https://www.hdfgroup.org/HDF5/doc/ADGuide/Changes.html, hid_t changed from 32 bits (aka int or DLong) to 64 bits (aka DLong64). Yet another dependency that we are to take into account! Rats!
In the meantime, you should install an older HDF version < 1.10 for GDL to compile.

Test the Python module

For the Debian package, I wrote some tests for the Python module. It would probably be useful to integrate them in Travis & Co.

set up code coverage service

This should monitor the percentage of added code covered with tests for each PR.
Example: codecov.io

APPLEMAN fractal does not display in black-red palette by default

Running freshly installed 0.9.8 (from Debian package), the graphical output of APPLEMAN is displayed in white-and-black palette. I'm pretty sure it was not the case previously - as depicted in various GDL screenshots.

GDL> appleman
% Compiled module: APPLEMAN.
% Compiled module: LOADCT.
% LOADCT: Loading table BOW SPECIAL

Support [start:end:interval] array generation

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/731/)
As reported on SF by Gilles:

A new (IDL8) feature:

IDL> x = [0:10:0.01]
IDL> help,x
X               FLOAT     = Array[1001]

GDL> x = [0:10:0.01]
% Lexer/Parser syntax error: expecting RSQUARE, found ':'

All formats should tolerate the absence of a numeric value after + or -:

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/702/)
Summary of things left to address in a bug reported on SF by David Murphy (@dnamurphy ?):

All formats should tolerate the absence of a numeric value after + or -:

IDL> print,'string1',5,format='(a-,i-)'     
string15
GDL> print,'string1',5,format='(a-,i-)'
% PRINT: Format parser: unexpected char: ','
% Execution halted at: $MAIN$

SF -> github migration

Bug with INTERPOL

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/728/)
As reported on SF by Mark Booth:

If p2 has values outside the range of p1 AND is multi-dimensional it will fail in the linear interpolation case.
For example:

GDL> test=interpol([1,2], [2, 1], [[3,4],[2,1]])
% Expression must be a scalar or 1 element array in this context.
% Error occurred at: INTERPOL 142 /usr/share/gnudatalanguage/lib/interpol.pro

Further comments:
Alain on 2018-01-04:

Thanks

I do confirm this bug.

What to do ?!

We do have other differences between IDL and GDL for this function and and we don't change because it was useful to found problems in special cases in some code ...
[it does help to debug !]

(Don't forgot you can compile the IDL one in GDL ...)

Alain

Mark on 2018-01-04:

Hi,

Indeed, I have a simple workaround for my particular case, so I wouldn't consider this bug a high priority, just wanted to let you know that it is there.

All the best,
Mark

H5D_READ fails to read compound datatypes

As reported by @rjp23 on SF.net (https://sourceforge.net/p/gnudatalanguage/bugs/600/):

file_id = H5F_OPEN(file)
data_id = H5D_OPEN(file_id, '/path/to/variable/')
variable = H5D_READ(data_id)
H5D_CLOSE, data_id

This works fine for almost all the variables I need to read in.

However, it fails on the "time" variable as this is a "H5T_compound" type:

Dataset: 'Time'
H5T_COMPOUND (12 bytes)
10 elements

When trying this I get:

% H5D_READ: Read failed

Segfault running test_xdr.pro 32 BITS ARCH

As reported by Harald Anlauf on SF.net: Segfault running test_xdr.pro

manually running the testcase test_xdr.pro I get a segfault.
Running it under gdb I find:

% Compiled module: TEST_XDR.
% TEST_READ_XDR: FAILED at tag #      10 in file idl.xdr
*** glibc detected *** /usr/local/src/cvs/gdl/build/src/gdl: munmap_chunk(): invalid pointer: 0x08f82cd8 ***
======= Backtrace: =========
....long output...

(gdb) bt
#0  0xb69c58c5 in raise () from /lib/libc.so.6
#1  0xb69c71d5 in abort () from /lib/libc.so.6
#2  0xb6a0174a in __libc_message () from /lib/libc.so.6
#3  0xb6a07f0b in malloc_printerr () from /lib/libc.so.6
#4  0xb6a08158 in munmap_chunk () from /lib/libc.so.6
#5  0xb6be6b2f in operator delete(void*) () from /usr/lib/libstdc++.so.6
#6  0xb6bce08b in std::string::_Rep::_M_destroy(std::allocator<char> const&) ()
   from /usr/lib/libstdc++.so.6
#7  0x088777bd in ProgNode::~ProgNode() ()
#8  0x0887cc46 in PCALLNode::~PCALLNode() ()
#9  0x08877755 in ProgNode::~ProgNode() ()
#10 0x0887cc46 in PCALLNode::~PCALLNode() ()
#11 0x08877755 in ProgNode::~ProgNode() ()
#12 0x0887cc46 in PCALLNode::~PCALLNode() ()
#13 0x08877755 in ProgNode::~ProgNode() ()
#14 0x0887cc46 in PCALLNode::~PCALLNode() ()
#15 0x08877755 in ProgNode::~ProgNode() ()
#16 0x0887cac6 in ASSIGNNode::~ASSIGNNode() ()
#17 0x08877755 in ProgNode::~ProgNode() ()
#18 0x0887cb46 in ASSIGN_REPLACENode::~ASSIGN_REPLACENode() ()
#19 0x08877755 in ProgNode::~ProgNode() ()
#20 0x0887cb46 in ASSIGN_REPLACENode::~ASSIGN_REPLACENode() ()
#21 0x08607653 in DSubUD::~DSubUD() ()
#22 0x085ee646 in DPro::~DPro() ()
#23 0x087ea236 in ResetObjects() ()
#24 0x088c45ad in AtExit() ()
#25 0xb69c8931 in __run_exit_handlers () from /lib/libc.so.6
#26 0xb69c89bd in exit () from /lib/libc.so.6
#27 0x086a4625 in lib::exitgdl(EnvT*) ()
#28 0x088766b9 in PCALL_LIBNode::Run() ()
#29 0x0818b76d in GDLInterpreter::statement(ProgNode*) ()
#30 0x0818c42c in GDLInterpreter::call_pro(ProgNode*) ()
#31 0x088791f1 in PCALLNode::Run() ()
#32 0x0818b76d in GDLInterpreter::statement(ProgNode*) ()
#33 0x0818c42c in GDLInterpreter::call_pro(ProgNode*) ()
#34 0x088791f1 in PCALLNode::Run() ()
#35 0x0818b76d in GDLInterpreter::statement(ProgNode*) ()
#36 0x0818c6c0 in GDLInterpreter::interactive(ProgNode*) ()
#37 0x085fe130 in DInterpreter::ExecuteLine(std::istream*, unsigned long long)
    ()
#38 0x08601210 in DInterpreter::InterpreterLoop(std::string const&, std::vector<std::string, std::allocator<std::string> >&, std::string const&) ()
#39 0x081546f5 in main ()

This is on i686-linux (32 bit).

interpreter bug

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/721/)
As reported on SF by Gilles:

This is a bug in two parts. First, there seems to be a misinterpretation of the meaning of () instead of [] in the last command, which should give exactly the same result as the command just above it. For some reason, GDL crashes due to a null address in the error handler. If this crash is avoided, the error becomes:

Expression must be a STRUCT in this context:

Now the crash code:

GDL> struct={array7:[3,3,7,7,7,5,5],z:ptr_new(/allocate_heap)}
GDL> 
GDL> zval=findgen(12)
GDL> 
GDL> pointer=ptr_new(struct,/no_copy)
GDL> 
GDL> *(*pointer).z=zval
GDL> 
GDL> print,(*(*pointer).z)[0:(*pointer).array7[3]]
      0.00000      1.00000      2.00000      3.00000      4.00000      5.00000      6.00000      7.00000
GDL> print,(*(*pointer).z)((*pointer).array7[1])
      3.00000          
GDL> print,(*(*pointer).z)((*pointer).array7(1))
Segmentation fault

clang pragmas not ifdefed in math_utl.cpp causing icc to report warnings

As logged e.g. here: https://travis-ci.org/gnudatalanguage/gdl/jobs/363482040

/home/travis/build/gnudatalanguage/gdl/src/math_utl.cpp(39): warning #161: unrecognized #pragma
  #pragma clang optimize off  
          ^
/home/travis/build/gnudatalanguage/gdl/src/math_utl.cpp(472): warning #161: unrecognized #pragma
  #pragma clang optimize on 
          ^
/home/travis/build/gnudatalanguage/gdl/src/math_utl.cpp(477): warning #161: unrecognized #pragma
  #pragma clang optimize off  
          ^
/home/travis/build/gnudatalanguage/gdl/src/math_utl.cpp(790): warning #161: unrecognized #pragma
   #pragma clang optimize on 
           ^

Coyote progress bar

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/729/)
As reported on SF by Alain:

Coyote proposes two verisons of a progress bar based on Widgets.
http://www.idlcoyote.com/widget_tips/show_progress.php

both are not working perfectly :(

I t may help to improve details in Widgets for GDL ?!

lets remark one is already packaged in the git Debian Coyote
with an example (you can downlod it :
git clone https://anonscm.debian.org/git/debian-astro/packages/coyote.git
)

GDL> .r cgprogressbar__define
GDL> PROGRESSBAR_EXAMPLE

NoViableAlt exception in format parser

% PRINT: Format parser: NoViableAlt
% Execution halted at: $MAIN$

IDL> print, complex(2,2), format='(H)'
% Value is out of allowed range (1 - 255).
  "(H)"
    ^
% Execution halted at: $MAIN$

at least 4 bugs in RESOLVE_ROUTINE !

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/730/)
As reported on SF by Alain:

at least 4 bugs in RESOLVE_ROUTINE :(

1/ take into account the path : should not
2/ accept with .pro suffix : should not
3/ fail if the path contain majuscules because all change into minuscule
(should not take into account the path !!)
4/ final message in case of success is bad (and again does contain the path !)

Furthermore, the "test_resolve_routine.pro" file added into the testsuite/
does not give same results (errors) in GDL and IDL

support new cprintf format

(https://sourceforge.net/p/gnudatalanguage/feature-requests/153/)

As reported by @alaingdl on SF.net:

Since IDL 8.6, a new C-style fomat was add
http://www.harrisgeospatial.com/docs/format_codes_cprintf.html

recreate pull request from #6 from gdl.off

@olebole could you please recreate your PR targetting the new repo? Thanks!
https://github.com/gnudatalanguage/gdl.off/pull/6

CHECK_MATH() does not work well

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/208/)
As reported on SF by Alain:

the code is in TEST_CHECK_MATH ...

.r testsuite/test_check_math.pro
[...]

then running TEST_CHECK_MATH_CUMUL than give bad results ...
(the problem may come from an inappropriate clean up of FE_ALL_EXCEPT
in dinterpreter.cpp
dinterpreter.cpp: feclearexcept(FE_ALL_EXCEPT); )

GDL> TEST_CHECK_MATH_CUMUL
(expected 1) 0
(expected 17) 0
(expected 145) 0
(expected 128) 0
(expected 128) 0
(expected 0) 0

Confirmed with 0.9.8

Add support for creating hdf5 files

(https://sourceforge.net/p/gnudatalanguage/feature-requests/142/)

As reported by @opoplawski on SF.net:

The hdf5 functions appear to only implement reading hdf5 files.

Further comment by @maynardGK on 2015-06-06:

HDF5 interface is very immature but that provided in IDL has 125
call points! This is a perfect candidate to get LINKIMAGE operational
so that the functionality can be added without bloating the program (when run without hdf5).

gdlhelp.cpp:390:16: error: use of undeclared identifier 'history_list'

Caught on Travis when building on OSX with this out-of-the-box setting as reported by CMake:

GNU Readline            ON /usr/lib/libreadline.dylib;HISTORY_LIBRARY-NOTFOUND
BSD Editline            ON /usr/lib/libedit.dylib

Build log: https://travis-ci.org/gnudatalanguage/ci-tests/builds/359548834#L5630

Named structure cannot contain anonymous ...

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/732/)
As reported on SF by Alain Coulais:

see in "test_suite.pro"

GDL does not complain on these 2 lines ...

IDL>   s={s:"a string",tag: indgen(5),c:complex(1,2)}
IDL>   s={s1,tag: indgen(5),s:s}                     
% Named structures can't contain anonymous structure members
% Execution halted at: $MAIN$

obj_destroy, called with more than one parameter, passes extra

As reported by @maynardGK at SF.net (https://sourceforge.net/p/gnudatalanguage/bugs/700/):

.cleanup returns an exception when obj_destroy is called with more than one argument. Evidently ti is seeing the caller's arguments.

$ gdl096

  GDL - GNU Data Language, Version 0.9.6 CVS 03/19

- For basic information type HELP,/INFO
- Please report bugs, feature or help requests and patches at:
  http://sourceforge.net/projects/gnudatalanguage/

GDL> tst=list(indgen(4),/ex)
GDL> tst1=list(indgen(4),/ex)
GDL> obj_destroy,tst1,tst
% CLEANUP: Incorrect number of arguments.
% Execution halted at: $MAIN$

    void obj_destroy( EnvT* e)
;...
;      BaseGDL* p= e->GetParDefined( 0);...
;      DObjGDL* op= static_cast<DObjGDL*>(p);
;      SizeT nEl=op->N_Elements();
;      for( SizeT i=0; i<nEl; i++)     {
;                 DObj actID=(*op)[i];
;                 e->ObjCleanup( actID);

Apparently addressed here (part of #32):
be6c58b

(machar()).eps() wrong on i386

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/695/)
As reported on SF by @olebole:

On a i386 CPU, the single precision "EPS" is wrongly calculated:

GDL> print, (machar(double=0)).eps
  1.08420e-19
GDL> print, (machar(double=1)).eps
   1.0842022e-19

When I do the same on a x86_64 machine, I get:

GDL> print, (machar(double=0)).eps
  1.19209e-07
GDL> print, (machar(double=1)).eps
   2.2204460e-16

Since the value (for double=0) is used as stepwidth in mpfit, mpfit fails on i386.
Interestingly, on another 32-bit platform (armhf), the value is correct:

GDL> print, (machar(double=0)).eps
  1.19209e-07
GDL> print, (machar(double=1)).eps
   2.2204460e-16

Further comments:

@GillesDuvert on 2016-05-17:

Hi Ole,
GDL implements (or is supposed to) this code: http://www.netlib.org/misc/machar. There are no apparent errors. I wonder what the above code gives on a i386?

@alaingdl on 2016-05-18:

I was able to replicate the bug on an old laptop (Ubuntu) and a VM in Debian 32b

yes, the current GDL code used a rather tricky way to compute that.

I made a few search and it seems that current C++ compilers do provide
interessting (simple) solutions but I had no time to test is.
http://www.cplusplus.com/reference/limits/numeric_limits/

gdl in non-interactive mode does not exit on stop or error

(https://sourceforge.net/p/gnudatalanguage/bugs/711/)

As reported by Gilles:

in non-interactive mode

gdl -e "some command"

if during the processing, GDL encounters a "stop" or throws an error, it should exit (idl does). It does not.

I believe it can be reproduced with:

$ cd gdl/testsuite
$ gdl -quiet -e "test_where, /test"
% Compiled module: TEST_WHERE.
% Compiled module: BANNER_FOR_TESTSUITE.
% Compiled module: GDL_IDL_FL.
% TEST_WHERE_NULL:   NO errors encountered during TEST_WHERE_NULL tests  
% Compiled module: ERRORS_CUMUL.
% TEST_WHERE_OVER_TPOOL_MIN_ELTS:   NO errors encountered during TEST_WHERE_OVER_TPOOL_MIN_ELTS tests  
% TEST_WHERE_OVER_TPOOL_MIN_ELTS:   NO errors encountered during TEST_WHERE_OVER_TPOOL_MIN_ELTS tests  
% TEST_WHERE_WITH_RANDOM:   NO errors encountered during TEST_WHERE_WITH_RANDOM tests  
% TEST_WHERE_WITH_RANDOM:   NO errors encountered during TEST_WHERE_WITH_RANDOM tests  
% TEST_WHERE: ===================================================
% TEST_WHERE: =                                                 =
% TEST_WHERE: =  NO errors encountered during TEST_WHERE tests  =
% TEST_WHERE: =                                                 =
% TEST_WHERE: ===================================================
% Stop encountered: TEST_WHERE         132 /home/slayoo/devel/gdl/testsuite/test_where.pro
GDL>

Address CMake warnings (CMP0054, CMP0012, CMP0026, CMP0042)

As can be seen in the Travis build logs (e.g. https://travis-ci.org/gnudatalanguage/gdl/jobs/363145175) there are several CMake warnings emitted in each build:

CMake Warning (dev) at /usr/local/cmake-3.9.2/share/cmake-3.9/Modules/FindOpenMP.cmake:200 (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 "c" 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):
  /usr/local/cmake-3.9.2/share/cmake-3.9/Modules/FindOpenMP.cmake:324 (_OPENMP_GET_FLAGS)
  CMakeLists.txt:316 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /usr/local/cmake-3.9.2/share/cmake-3.9/Modules/FindOpenMP.cmake:277 (if):
  if given arguments:
    "TRUE"
  An argument named "TRUE" appears in a conditional statement.  Policy
  CMP0012 is not set: if() recognizes numbers and boolean constants.  Run
  "cmake --help-policy CMP0012" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
Call Stack (most recent call first):
  /usr/local/cmake-3.9.2/share/cmake-3.9/Modules/FindOpenMP.cmake:380 (_OPENMP_GET_SPEC_DATE)
  CMakeLists.txt:316 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at /usr/local/cmake-3.9.2/share/cmake-3.9/Modules/FindOpenMP.cmake:277 (if):
  if given arguments:
    "TRUE"
  An argument named "TRUE" appears in a conditional statement.  Policy
  CMP0012 is not set: if() recognizes numbers and boolean constants.  Run
  "cmake --help-policy CMP0012" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
Call Stack (most recent call first):
  /usr/local/cmake-3.9.2/share/cmake-3.9/Modules/FindOpenMP.cmake:380 (_OPENMP_GET_SPEC_DATE)
  CMakeLists.txt:316 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at testsuite/CMakeLists.txt:92 (get_target_property):
  Policy CMP0026 is not set: Disallow use of the LOCATION target property.
  Run "cmake --help-policy CMP0026" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
  The LOCATION property should not be read from target "launchtest".  Use the
  target name directly with add_custom_command, or use the generator
  expression $<TARGET_FILE>, as appropriate.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev) at CMakeLists.txt:998 (get_target_property):
  Policy CMP0026 is not set: Disallow use of the LOCATION target property.
  Run "cmake --help-policy CMP0026" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.
  The LOCATION property should not be read from target "gdl".  Use the target
  name directly with add_custom_command, or use the generator expression
  $<TARGET_FILE>, as appropriate.
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.
  MACOSX_RPATH is not specified for the following targets:
   test_ce
This warning is for project developers.  Use -Wno-dev to suppress it.

GDL uses deprecated numpy API

As reported by @GillesDuvert at SF.net (https://sourceforge.net/p/gnudatalanguage/bugs/589/):

$ make
[ 16%] Built target antlr
[ 17%] Building CXX object src/CMakeFiles/gdl.dir/datatypes.cpp.o
In file included from /usr/lib64/python2.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1760:0,
                 from /usr/lib64/python2.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:17,
                 from /usr/lib64/python2.7/site-packages/numpy/core/include/numpy/arrayobject.h:4,
                 from /tmp/gdl/src/datatypes.cpp:21:
/usr/lib64/python2.7/site-packages/numpy/core/include/numpy /npy_1_7_deprecated_api.h:15:2: warning: 
#warning "Using deprecated NumPy API, disable it by #defining    NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]

Compilation error with clang 4.0 / sincos

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/733/)
As reported on SF by Thierry Thomas:

Trying to compile GDL v. 0.9.8 on FreeBSD 11.1 (with clang 4.0), it produces the following error:

In file included from /wrkdirs/usr/ports/science/gnudatalanguage/work/gdl-0.9.8/src/triangulation.cpp:27:
/wrkdirs/usr/ports/science/gnudatalanguage/work/gdl-0.9.8/src/ssrfpack.c:2584:1: error: use of undeclared identifier 'sincos'
sincos (*plat, &p[2], &cos_plat);    sincos (*plon, &p[1], &p[0]);    p[0] *= cos_plat;    p[1] *= cos_plat;
^
/wrkdirs/usr/ports/science/gnudatalanguage/work/gdl-0.9.8/src/ssrfpack.c:2584:38: error: use of undeclared identifier 'sincos'
sincos (*plat, &p[2], &cos_plat);    sincos (*plon, &p[1], &p[0]);    p[0] *= cos_plat;    p[1] *= cos_plat;

With clang 5.0, everything is OK.

always verbose in EXECUTE()

As reported by @alaingdl at SF.net (https://sourceforge.net/p/gnudatalanguage/bugs/692/):

two weakness in EXECUTE()

1/ the argument QuietCompile (now CompileFlags in IDL) is not well enforced
and has now 3 possible values (0,1, [2 : implied print])

1a/ quietCompile = p1->True(); is not OK (odd/even effect)
1b/ line 1553 is always verbose, even if flag asks to be quiet ...
RetCode retCode = caller->Interpreter()->execute( progAST);

e.g. : ok=EXECUTE("a = ABCDEF(/version)", flag) & print, ok
(assuming ABCDEF does not exist)
if flag=0 then message should appears (syntax error)
if flag != 0 then no message at all

2/ A new argument was added to EXECUTE(), I will (try to)
add it in the arg. number but it will not be enforced

idl vs. gdl difference in foreach behaviour

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/630/)
As reported on SF:

GDL> a = [1,2,3]
GDL> foreach a, a do print, a
1
2
3
GDL>

IDL> a = [1,2,3]
IDL> foreach a, a do print, a
1
IDL>

No exception on GDL errors in Python

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/680/)
As reported on SF by @olebole:

When a GDL routine has an error (for example, a undefined procedure), no exception is thrown, but instead one gets a GDL console:

$ cat pr.py 
import GDL
GDL.pro("rubbish")
$ cat rubbish.pro 
pro rubbish
  bla
end
$ python pr.py 
% Compiled module: RUBBISH.
% RUBBISH: Procedure not found: BLA
% Execution halted at: RUBBISH              2 [...]/rubbish.pro
%                      $MAIN$          
GDL>

This makes it impossible to handle the problem within Python. Instead, an error should be given back. Ideally, also a Python stacktrace could be created containing the GDL trace as well.

nullgdl.hpp: no corresponding operator delete issue reported by icc

As logged e.g. here: https://travis-ci.org/gnudatalanguage/gdl/jobs/363482040
Intel compiler reports numerous warnings for lack of delete operator in nullgdl.hpp

/home/travis/build/gnudatalanguage/gdl/src/nullgdl.hpp(55): warning #873: function "NullGDL::operator new(size_t={unsigned long}, char *)" has no corresponding operator delete (to be called if an exception is thrown during initialization of an allocated object)
  	instance = new (NullGDL::buf) NullGDL();
  	           ^

Unable to compile with GPLK ON on various systems

(moved from https://sourceforge.net/p/gnudatalanguage/bugs/726/)
As reported on SF by Alain:

by defaut, GPLK is OFF.

I am able to compile with GPLK ON only on Debian.

I am not able to compile with it ON on various systems (u1604, u1404)

furthermore, GPLK installed on OSX 10.11 with Brew is not detected.

(I tried alternative version of FindGLPK.cmake with same result)

message as follow :

/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libplplotd.so: undefined reference to symbol 'lt_dlexit'
//usr/lib/x86_64-linux-gnu/libltdl.so.7: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
src/CMakeFiles/gdl.dir/build.make:3660: recipe for target 'src/gdl' failed
make[2]: [src/gdl] Error 1
CMakeFiles/Makefile2:124: recipe for target 'src/CMakeFiles/gdl.dir/all' failed
make[1]: [src/CMakeFiles/gdl.dir/all] Error 2
Makefile:138: recipe for target 'all' failed
make: *** [all] Error 2

Further comments:
Gilles on 2017-11-22:

This looks like a plplot error, not glpk related?

Alain on 2017-11-22:

Just linking problem ?
wrong with cmake -DGPLK=on, ok witjout (default OFF)

On two of these machines I complied by myself the GPLK then linked within GDL with sucess ... then the FindGLPK is not that bad !

also it seems that we will have to change HAVE_GPLK and USE_GLPK around ...

Alain on 2018-01-25:

the situation seems to be clarified on Linux (compilation OK
using packages or by_hand; execution of "test_simplex" OK).

On OSX, compilation OK too, but execution failed :

GDL> test_simplex
% Compiled module: TEST_SIMPLEX.
glp_load_matrix: ja[1] = 1072693248; column index out of range
Error detected in file api/prob1.c at line 1009

option to regenerate antlr files with system antlr

#As discussed at SF.net:

https://sourceforge.net/p/gnudatalanguage/patches/39/ with @sfabbro
https://sourceforge.net/p/gnudatalanguage/patches/100/ with @olebole and @GillesDuvert
the idea of shipping all ANTLR files within GDL does not have fans among packagers, for good reasons.

As pointed out in the SF issues, the solution which was introduced e.g. in:

Gentoo (https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-lang/gdl/files/0.9.5-antlr.patch)
Debian (https://sources.debian.org/patches/gnudatalanguage/0.9.8-2/Build-with-Debian-s-antlr-instead-of-the-embedded-copy-in.patch/)
to link with system antlr has the problem of creating version mismatch between the generated files used in compilation and the system files used.

I believe, we should offer via CMake the option to use system antlr (as in the Gentoo patch) but then trigger a regeneration of all antlr-generated files, i.e.:

$ cd gdl/src
$ for i in *.g; do antlr $i; done;

Another issue is that reportedly the GDL-shipped antlrheaders are modified with respect to the original (https://sourceforge.net/p/gnudatalanguage/patches/100/).

gnudatalanguage / gdl Goto Github PK

gdl's People

Contributors

Stargazers

Watchers

Forkers

gdl's Issues

Recommend Projects

Recommend Topics

Recommend Org