gnudatalanguage / gdl Goto Github PK
View Code? Open in Web Editor NEWGDL - GNU Data Language
License: GNU General Public License v2.0
GDL - GNU Data Language
License: GNU General Public License v2.0
(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/
% 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$
This should monitor the percentage of added code covered with tests for each PR.
Example: codecov.io
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
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
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'
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
Tests that were disabled on Travis as failing at the time of SF->github migration:
(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
(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.
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.
(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 ':'
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);
(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
For the Debian package, I wrote some tests for the Python module. It would probably be useful to integrate them in Travis & Co.
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
(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
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]
(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>
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();
^
(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).
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
(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
(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).
This repo seems to have it already implemented by @pjb7687 : https://github.com/pjb7687/GNU-Data-Language-0.9.6
(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
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).
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.
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.
(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
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
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).
(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
@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
(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$
as noted by @GillesDuvert, there exist already a jupyter backend aimed at supporting GDL: https://github.com/lstagner/idl_kernel
(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 ;)
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.
(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>
(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$
#As discussed at SF.net:
As pointed out in the SF issues, the solution which was introduced e.g. in:
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/).
(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
(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)
(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
As:
(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
@olebole could you please recreate your PR targetting the new repo? Thanks!
https://github.com/gnudatalanguage/gdl.off/pull/6
(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.
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
^
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.