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.13% IDL 19.92% Prolog 0.84% Python 0.09% Fortran 0.01% Roff 4.44% NSIS 0.07% TeX 0.05%

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

gdl's Introduction

GDL - GNU Data Language

GDL is a free/libre/open source incremental compiler compatible with IDL (Interactive Data Language) and to some extent with PV-WAVE. Together with its library routines it serves as a tool for data analysis and visualization in such disciplines as astronomy, geosciences and medical imaging. GDL development had been started by Marc Schellens back in early noughties and has since continued with help of a team of maintainers, developers, packagers and thanks to feedback from users.

IDL is a registered trademark of Harris Geospatial Solutions. PV-WAVE is a product of Rogue Wave Software.

Overview

GDL is a domain-specific programming language and a data analysis environment. As a language, it is dynamically-typed, array-oriented, vectorised and has object-oriented programming capabilities. GDL library routines handle numerical calculations, data visualisation, signal/image processing, interaction with host OS and data input/output. GDL supports several data formats such as netCDF, HDF4, HDF5, GRIB, PNG, TIFF, DICOM, etc. Graphical output is handled by X11, PostScript, SVG or z-buffer terminals, the last one allowing output graphics (plots) to be saved in a variety of raster graphics formats. GDL features integrated debugging facilities. The built-in widget functionality enables development of GUI-based software. GDL has also a Python bridge (Python code can be called from GDL; GDL can be compiled as a Python module). Development and maintenance of GDL is carried out targeting Linux, BSD, OSX and Windows (MinGW, Cygwin).

GDL is invoked just by typing gdl but see gdl -h as it has a number of commandline options. GDL may be known as gnudl or gnudatalanguage on some operating systems.

Other open-source numerical data analysis tools similar to GDL include SciPy, GNU Octave, Scilab, PDL, NCL, R, Yorick.

Getting GDL

See:

Find specific information on GDL

Browse the WIKI
Be aware of current problems/limitations: Check the issues.

Dependencies

Packaged versions of GDL are available for several Linux distributions, BSD and Mac OS X. Please note that several features of GDL depend on compile-time configuration, and might not be available in pre-built or pre-configured packages.

GDL has numerous dependencies, most of the optional but highly recommended if you want it to be areally useful tool.

readline mandatory. For easy command line editing, recalling, history.
[n]curses mandatory. Terminal management.
zlib mandatory. compressed file access.
GSL mandatory, for many math functions.
OpenMP optional, but speed will suffer if not present
Magick++ / GraphicsMagick optional, but don't you want to read/write many image formats?
wxWidgets mandatory unless you do not want graphic outputs and widgets?
Xlib/X11 not used unless you explictly ask for it (replaced by wxWidgets for sake of compatibility on Windows, linux and MacOSX.
netCDF optional, but useful for reading this kind of data.
HDF4 optional, but useful for reading this kind of data.
HDF5 optional, but useful for reading this kind of data.
FFTW optional, but don't you need a fast fft at times?
PROJ optional but forget about mapping capabilities if absent.
Shapelib optional but forget about mapping capabilities if absent.
Expat optional but helps implement IDLffXMLSAX parser objects.
MPI optional but provides clustering facilities.
Python/NumPy optional but add python bridge and jupyter notebook.
udunits optional, units conversion
Eigen optional but provides inordinate speed enhancements...
ecCodes optional, for GRIB support.
GLPK optional, provides the SIMPLEX command.

Besides, for optimal use (speed mainly), GDL incorporates slightly edited code of

dSFMT as our parallel random Generator.
delaunator as our new hyperfast triangulation.
ANTLR3 as interpretor.
Median Filtering (S. Perreault)
Median Filtering (J. Suomela)
Radix Sorting (we have written all variants up to doubles).
whereami

Build-time dependencies

Build and test automation is carried out using CMake.

GDL interpreter has been developed using ANTLR v2 but unless you want to change the grammar (*.g files) you don't need ANTLR. All relevant ANTLR files are included in the source tree.

Support, feedback and contributions

Your comments are welcome! Let us know what you use GDL for. Or if you don't, why not. Which functionality are you missing/would appreciate most for coming versions. Please use the github issue-tracking system to report bugs, complaints, suggestions and comments.

Code enhancements in the form of pull requests are very welcome! Note that contributions can be made in C++, IDL/GDL or Python, as well as by providing enhancements and extensions of the README files, diagnostic messages, etc.

Among the major challenges GDL development is facing currently, there are:

enhancing test coverage by writing test programs in GDL
streamlining development and maintenance of GDL reference docs and examples (using the Jupyter kernel?)
bringing in into the team the needed know-how to address the backlog of ANTLR-related issues
increasing presence within and interoperability with the Python ecosystem, including adding support for Python 3 (calling GDL from Python 2 and calling Python 2 from GDL is already implemented!)

Help welcome!

Information resources

GDL does not maintain a proper documentation: as GDL is aimed as a drop-in replacement for IDL, resources for IDL constitute the valuable sources of information for GDL users as well. GDL MUST behave (at least) as IDL, and any discrepancy should be reported by opening an issue. Conversely, the GDL issues and discussion forum on GitHub are not the good place for beginners to ask for advice on how to use IDL (or GDL). Use the forum below. IDL freely available resources include:

the official IDL documentation
the idl-pvwave Google Group
the comp.lang.idl-pvwave usenet group archives (dating back to 1991!)
Wikipedia article on IDL and references therein
websites of IDL gurus including David Fanning and Michael Galloy
numerous tutorials and lecture notes introducing IDL
old, used, but still very valid IDL booklets can be found in various libraries, second-hand bookstores etc.

There are several open source packages compatible or interoperable with GDL, including:

the MPFIT curve fitting library written in IDL (also available as a Debian package)
the IDL Astronomy User's Library written in IDL (also available as a Debian package)
the Coyote library of IDL-written utilities (also available as a Debian package)
the TeXtoIDL package
the gdlde IDE
the IDL/GDL Jupyter kernel
the IDLWAVE Emacs mode
IDL syntax highlighting module for Vim
the SingleCompile extension for Vim

Alain Coulais maintains the GDL-announces mailing list.

There have been quite some mentions of GDL in scientific literature which also provide example use cases. The Coulais et al. papers from the ADASS conferences are the best way to cite GDL as of now.

Acknowledgements

GDL development had been carried out at SourceForge in years 2003-2018 - thank you!

gdl's People

Stargazers

Watchers

Forkers

olebole gillesduvert opoplawski cenit maynardgk rexso alaingdl sflinois jdkloe siamar csega pstrub ananyadevaraju alexmyczko dschnitzeler sixy6e zj0324 bourgesl abbgstar fallingelf ezhangle edromzans hillbergt pkubanek stjordanis huayue21 tckosvic yulong-ma halcyon-gh ezeeyahoo tyronebj roche-emmanuel lconaboy slayoo amolh12 philippefoubert eloirozier pjb7687 ogressel hdfeos algorab-dream rnavarromal jkohnert swrh scigeliu andrewaehlisch brbarker jeanne-jw neuroradiology kevin-mattheus-moerman im-going-nowng ey-parthenon sjfrasier hansbothe bonekamp saynkas mattrenderedai boudjemaas frankmri ritwik-ritnov

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

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

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.

SF -> github migration

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.

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 
           ^

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).

(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/

set up code coverage service

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

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$

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.

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

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

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.

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.

[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

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'

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 #6 from gdl.off

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

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

[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.

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

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 ;)

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

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$

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>

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]

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).

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

"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)

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

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

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

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

Travis scripts TODOs

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

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/).

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>

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$

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.

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

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

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

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).

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).

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

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 ':'

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

gnudatalanguage / gdl Goto Github PK

gdl's Introduction

GDL - GNU Data Language

Overview

Getting GDL

Find specific information on GDL

Dependencies

Build-time dependencies

Support, feedback and contributions

Information resources

Acknowledgements

gdl's People

Stargazers

Watchers

Forkers

gdl's Issues

Recommend Projects

Recommend Topics

Recommend Org