The very beginning: MAIN not found

[avgetling]

Hello,

I am experienced with IDL but my first step in GDL was not successful. In the Workbench, I opened the following simple program called COLOURS, which works well under IDL:

x=indgen(21) y0=intarr(21) y=x^2 plot,x,y0,xrange=[0,20],yrange=[0,400] oplot,x,y,color=255 y1=200(1+sin(2!pix/20)) y2=y0+200 oplot,x,y1,color=256L255L oplot,x,y2,color=256L255L255L end

The reply was as follows:

% Procedure not found: COLOURS % Execution halted at: $MAIN$

For reasons unknown to me, no HELP is available (likely, something was wrong while installing the package, so that no information is available. I use a Windows version of GDL.

Thank you in advance for your comments.

[alaingdl]

which version do you use ? on which system print, !gdl

in recent (0.9.8+) GDL> gdl_status wil give some information on what is really available (linked with)

help,/lib too

because of typo & missing "*" on those lines, IDL & GDL will give same messages :

GDL> y1=200(1+sin(2!pix/20)) % Parser syntax error: unexpected token: ( GDL> y2=y0+200 GDL> oplot,x,y1,color=256L255L % Parser syntax error: unexpected token: 255 GDL> oplot,x,y2,color=256L255L255L % Parser syntax error: unexpected token: 255

HELP is working in the CLI ?plot should work

plot too (only in GDL)

[slayoo]

There are several issues here:

1. GDL apparently cannot find the file where the procedure is defined - it should find it if the file would be called colours.pro
2. the code contains some typos (?) in the "y1=200(1+sin(2!pix/20))" statement - "200(1...", "2!pi/"?
3. GDL will not understand color=256L255L (IDL as of v8.1 neither)

[avgetling]

Thank you, alaingdl and slayoo.

Let me first reply to slayoo's comments.

1. It is indeed called colours.pro. 2, 3. As can easily be seen, all the asterisks were lost while copying the procedure, where the expressions look as follows: 200(1+sin(2!pix/20)), 256L255L etc. In the next post, I shall copy the text again.

[avgetling]

I tried to do it. What is strange is that when I write my comment, everything looks correctly. However, upon saving the comment, the asterisks disappear.

[slayoo]

please try using triple backticks to instruct github to render the code:

```IDL
pro hello_world
  print, "hello"
end

results in:
```IDL
pro hello_world
  print, "hello"
end

[avgetling]

Now it looks fine, thank you:

x=indgen(21)
y0=intarr(21)
y=x^2
plot,x,y0,xrange=[0,20],yrange=[0,400]
oplot,x,y,color=255
y1=200*(1+sin(2*!pi*x/20))
y2=y0+200
oplot,x,y1,color=256L*255L
oplot,x,y2,color=256L*255L*255L
end

[avgetling]

alaingdl,

which version do you use ? on which system print, !gdl

I use version 0.9.6.

in recent (0.9.8+) GDL> gdl_status wil give some information on what is really available (linked with)

This command results in the complaint:

GDL> gdl_status % Procedure not found: GDL_STATUS % Execution halted at: $MAIN$

help,/lib too

And this command returns a list of 101 Library procedures.

because of typo & missing "*" on those lines, IDL & GDL will give same messages :

GDL> y1=200(1+sin(2!pix/20)) % Parser syntax error: unexpected token: ( GDL> y2=y0+200 GDL> oplot,x,y1,color=256L255L % Parser syntax error: unexpected token: 255 GDL> oplot,x,y2,color=256L255L255L % Parser syntax error: unexpected token: 255

No, there are no typos (see my comment above).

HELP is working in the CLI ?plot should work

plot too (only in GDL)

HELP returns the following list:

Compiled Procedures: $MAIN$ Compiled Functions:

Finally, the last two commands yield the following output: GDL> ?plot % Compiled module: ONLINE_HELP. % ONLINE_HELP: WEB Browser not found : firefox % ONLINE_HELP: Please provide the name (+path) to the browser you want to use % Error occurred at: ONLINE_HELP 126 C:\Program Files (x86)\gnudatalanguage\share\gnudatalanguage\lib\online_help.pro % $MAIN$
% Execution halted at: $MAIN$
GDL> #plot Internal PROCEDURE : PLOT,[2 Args],BACKGROUND,CHARSIZE,CHARTHICK,..

Thus, I have not yet understood what to do.

It would clearly be great to get a newer version (which should soon be much easier for Windows - stay tuned), but let's first solve the issue of GDL not finding the colours.pro file.

Could you try changing the directory from within gdl before executing the procedure, i.e.:

GDL> cd, "<PATH>"
GDL> colours

(where <PATH> would be the location of the colours.pro script)

[avgetling]

Thank you. Your suggestion clearly refers to operations with the command line. The console that I have available and can open does not accept pasted commands (!) but if I enter the 'cd' command manually, it declines both the Windows backslash and the disk specification 'D:/' ("unexpected token").

My problem arose, however, in dealing with the GDL Workbench, which is much more convenient. The Workbench also has a command line, which works normally. Nevertheless, entering the path in the command line does not change the results.

The problem looks all the more strange, since the Workbench does not need seeking the main program at all if the latter is opened in its window.

I downloaded the GDL from https://sourceforge.net/projects/gnudatalanguage-win32/, where only Windows version 0.9.6 (marked as "unofficial") is available. The last update of the webpage was on 2016-01-04 -- too long ago! Could you recommend a resource with a newer version?

(However, it can hardly be imagined that a release unable to execute even simplest codes could be put at public disposal!)

[slayoo]

Please ensure if there is a comma between cd and '<PATH>':

GDL> cd 'temp'
% Parser syntax error: unexpected token: temp
GDL> cd, 'temp'

[avgetling]

Yes, it is present but I accidently omitted the quotation marks. Now the code can be run from the console although it returns wrong colours in the graphs.

However, the point is that the working directory is normally automatically specified in the GDL Workbench (user's interface), where the text of the main module is explicitly opened. This is an unambiguous specification!

[slayoo]

Please also include the quotation marks so that the path is a string, i.e.:

GDL> cd, "D:\IDL"

(I can hardly comment on the GDL Workbench or Windows issues as I've never myself used the GDL Workbench or GDL on Windows yet, but as I wrote above - the path problem seems the first thing to solve)

[avgetling]

Please see my preceding comment: it works with the quotation marks but with wrong colours in graphics. If the Workbench problem stems from its bug, I would be happy to install a newer version but where to find it?

[slayoo]

To my knowledge, the "Unofficial Win32 binary distrubution for GNU Data Language" at SourceForge (the one you've pointed to in one of earlier comments above) had been the only attempt to provide GDL binaries for Windows for now.

There is ongoing work here at github (despite the misleading name, included here: #431) to offer nightly builds for Windows, but it is still not ready IIUC. You could try with a recent build from there, e.g.: https://ci.appveyor.com/api/buildjobs/cvln9j3jbes8icng/artifacts/gdl_build.zip but it will not include the Workbench.

The GDL Workbench development (now moved here: https://github.com/gnudatalanguage/gdlde) has been last active in 2015, and for now the code seems unusable to to incompatibilities with current releases of Java ecosystem: https://github.com/gnudatalanguage/gdlde/issues/2)

Problems with colours are quite likely to have been fixed from 0.9.6 as there has been significant work going on around the plotting subsystem in the last three years.

@alaingdl @pjb7687 @maynardGK any more comments to help @avgetling ?

[alaingdl]

My student Amar, with the help of Sylvain, delivered a version in July GDL 4 mswin with the mandatory libs. as DLL.

A script should be republish very soon, to allow compilation of current Git version.

[maynardGK]

Until recently I had thought this thread applied to the Linux GDL. Indeed the 64-bit build referenced above is up to-date and more, and many issues found in that will also apply to the linux build. Exception to this are graphics, widgets, and procedures (such as online_help) that have been developed in linux. In the build referenced, widgets are excluded because of the problems with this aspect.

[avgetling]

Thank you, @slayoo and @alaingdl.

@slayoo:

There is ongoing work here at github (despite the misleading name, included here: #431) to offer nightly builds for Windows, but it is still not ready IIUC. You could try with a recent build from there, e.g.: https://ci.appveyor.com/api/buildjobs/cvln9j3jbes8icng/artifacts/gdl_build.zip but it will not include the Workbench.

My attempt to run GDL from this package yielded the message:

"PLplot installation lacks the requested driver: wingdi"

@alaingdl:

My student Amar, with the help of Sylvain, delivered a version in July GDL 4 mswin with the mandatory libs. as DLL.

A script should be republish very soon, to allow compilation of current Git version.

This package plots the graphs correcty, with the colours specified in the code. However, if I try to write an .eps file, I get only two of the three graphs, in black.

What kind of script do you mean?

[maynardGK]

PLplot installation lacks the requested driver: wingdi" @avgetling This is probably because you are using a plplot_LIB from a different installation. Wingdi is a new driver (wingcc is the old one) The install/plplot5.13/drivers shipping with this package contains the wingdi.driver_info file that you are missing. If you simply copy this into where the current PLPLOT_LIB is pointed at, it may just work: the plplot version is earlier but this aspect is the same.

[avgetling]

@maynardGK Thank you. The name PLPLOT_LIB is not present in the package. I have tentatively copied wingdi.driver_info into two directories, 'build\plplot\msys\lib' and 'install\plplot5.13\lib'. It is also present in 'build\plplot\msys\drivers' and 'build\plplot\msys\drivers\test_dyndrivers_dir'. Unfortunately, nothing changed: the same message "PLplot installation lacks the requested driver: wingdi" appears.

[maynardGK]

You can delete the buid directory, that is for error diagnostics. When you installed the old GDL it set up some environment variables, such as GDL_PATH or PLPLOT_LIB.
in my window's console window, when I check these I see

PLPLOT_DRV_DIR=C:/usr/plplot5.13.0/drivers
PLPLOT_LIB=C:/usr/plplot5.13.0/lib

ahh ok so I gave you the wrong name, it is PLPLOT_DRV_DIR which holds these files. Sorry about that.

I think this will work (locate as install/gdl.bat) as target of a desktop link

@echo off
@set cur=%cd%
@set path=%cd%\gdl\bin;%path%
@set GDL_PATH=+%cd%\gdl\gdllib
@set PLPLOT_DRV_DIR=%cd%\plplot5.13\drivers
@set PLPLOT_LIB=%cd%\plplot5.13\lib
gdl.exe

[avgetling]

Thank you very much, @maynardGK. This .bat file really launches the GDL (however, it fails if the 'buid' directory is removed). At the moment, the following problems still exist: (1) The .eps output does not reproduce all the colours correctly. While a window opens with the required colors (as in your above post), the image in the .eps file appears as follows: (2) I linked a desktop label to this .bat file but if I try to run GDL clicking this label, I receive the message that the 'drivers' directory cannot be opened. (3) Commands cannot be copied and pasted in the console.

[maynardGK]

You can get (windows' style) cut/paste in the console by checking "Quick Edit Mode" box in properties->options from the desktop link. Normally I run from a Windows-7 machine which has all that stuff as default. Today I can get on a windows' 8.2 machine:

  GDL - GNU Data Language, Version 0.9.8 git

- For basic information type HELP,/INFO
- No startup file read (GDL_STARTUP/IDL_STARTUP env. var. not set).
- Please report bugs, feature or help requests and patches at:
  https://github.com/gnudatalanguage/gdl

GDL> print,!path
D:\gdl64\install\gdl\gdllib/dicom;D:\gdl64\install\gdl\gdllib/envi;D:\gdl64\inst
all\gdl\gdllib/obsolete;D:\gdl64\install\gdl\gdllib/utilities;D:\gdl64\install\g
dl\gdllib
GDL> hash(!gdl)
EPOCH:  1533970800
RELEASE:0.9.8 git
BUILD_DATE:Aug 11 2018
GDL> hash(!version)
OS:Windows
ARCH:x64
OS_NAME:Windows
RELEASE:8.2
OS_FAMILY:Windows
BUILD_DATE:Aug 11 2018

MEMORY_BITS:      64
FILE_OFFSET_BITS:      64

To generate a stand-alone console program that inherits the GDL environment, GDL> spawn,/nowait

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

D:\gdl64\install>set
ALLUSERSPROFILE=C:\ProgramData

This spawned shell does not have quickEdit mode set, even though the originating console did.

I don't know why the build directory is interfering, I just created by downloading and unzipping only the install directory to gdl64/.

Colors in PS: There is no "PSLIB enhancement" in the windows' build that debian-linux users might be seeing, so this is going through the PLPLOT driver. I don't know much more than that, I remember testing early on and found the SVG driver seemed better. trying that here:

!p.charsize=1.6
!P.title="Sample plot"
!x.title="X Axis title"
!p.thick=2
x=indgen(21)
y0=intarr(21)
y=x^2
plot,x,y0,xrange=[0,20],yrange=[0,400]
oplot,x,y,color=255
y1=200*(1+sin(2*!pi*x/20))
y2=y0+200
oplot,x,y1,color=256L*255L
oplot,x,y2,color=256L*256L*255L,thick=2

I clipped this test run, spawned a new process to preserve the origiinal GDL as I exit the gdl used to create the SVG file (it stays open until gdl exits). Then the SVG file can be read by chrome.

[maynardGK]

(I'm moved back to the Win 7 machine now) After first not being set, the Quick Edit mode was set on later uses of the spawned console, so that may/may not be a recurring issue. Instead of exiting the spawned process, you can just "DEVICE,/CLOSE" to get a usable image file:

GDL> $del gdl.svg
GDL> set_plot,'svg'
GDL> x=indgen(21)
GDL> y0=intarr(21)
GDL> y=x^2
GDL> plot,x,y0,xrange=[0,20],yrange=[0,400]
GDL> oplot,x,y,color=255
GDL> y1=200*(1+sin(2*!pi*x/20))
GDL> y2=y0+200
GDL> oplot,x,y1,color=256L*255L
GDL> oplot,x,y2,color=256L*256L*255L
GDL> $dir
 Volume in drive F is Fdata
 Volume Serial Number is 5E12-64CE

 Directory of f:\github\gdl64\install

09/19/2018  02:48 PM    <DIR>          .
09/19/2018  02:48 PM    <DIR>          ..
08/12/2018  01:34 PM    <DIR>          gdl
08/14/2018  01:59 PM               173 gdl.bat
09/19/2018  02:48 PM                 0 gdl.svg
08/14/2018  02:04 PM               173 gdl.txt
08/11/2018  01:06 AM             1,375 INSTALL.plplot
08/12/2018  01:34 PM    <DIR>          plplot5.13
               4 File(s)          1,721 bytes
               4 Dir(s)  253,665,406,976 bytes free
GDL> device,/close
GDL> $dir
 Volume in drive F is Fdata
 Volume Serial Number is 5E12-64CE

 Directory of f:\github\gdl64\install

09/19/2018  02:48 PM    <DIR>          .
09/19/2018  02:48 PM    <DIR>          ..
08/12/2018  01:34 PM    <DIR>          gdl
08/14/2018  01:59 PM               173 gdl.bat
09/19/2018  02:48 PM            25,886 gdl.svg
08/14/2018  02:04 PM               173 gdl.txt
08/11/2018  01:06 AM             1,375 INSTALL.plplot
08/12/2018  01:34 PM    <DIR>          plplot5.13
               4 File(s)         27,607 bytes
               4 Dir(s)  253,665,411,072 bytes free

[maynardGK]

The render that chrome does looks good, and it prints like it looks:

[GillesDuvert]

To get a correct PS output, you need to tell the PS driver that the color scheme is DECOMPOSED device,/decomposed,/color,/encap Otherwise the color indexes abov 255, like color=256L*256L*255L are lost. This is true for IDL too, AFAIK. Of course, this is based on my experience of GDL 0.9.8 and IDL 8.4 for Linux only.

[avgetling]

I thank you, @maynardGK, again and consider your comments step by step.

You can get (windows' style) cut/paste in the console by checking "Quick Edit Mode" box in properties->options from the desktop link. Normally I run from a Windows-7 machine which has all that stuff as default.

This box was already checked but got working only after unchecking another box, "Use Former Console Version".

Today I can get on a windows' 8.2 machine:

  GDL - GNU Data Language, Version 0.9.8 git

- For basic information type HELP,/INFO
- No startup file read (GDL_STARTUP/IDL_STARTUP env. var. not set).
- Please report bugs, feature or help requests and patches at:
  https://github.com/gnudatalanguage/gdl

GDL> print,!path
D:\gdl64\install\gdl\gdllib/dicom;D:\gdl64\install\gdl\gdllib/envi;D:\gdl64\inst
all\gdl\gdllib/obsolete;D:\gdl64\install\gdl\gdllib/utilities;D:\gdl64\install\g
dl\gdllib

Alas, I found the path list empty. How could I add the needed paths?

GDL> hash(!gdl) EPOCH: 1533970800 RELEASE:0.9.8 git BUILD_DATE:Aug 11 2018 GDL> hash(!version) OS:Windows ARCH:x64 OS_NAME:Windows RELEASE:8.2 OS_FAMILY:Windows BUILD_DATE:Aug 11 2018

MEMORY_BITS: 64 FILE_OFFSET_BITS: 64

I received this output.

To generate a stand-alone console program that inherits the GDL environment, GDL> spawn,/nowait

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

D:\gdl64\install>set
ALLUSERSPROFILE=C:\ProgramData

This spawned shell does not have quickEdit mode set, even though the originating console did.

I have not understood in which case such a console may be needed. However, in my case, it shows the location of the previous gdl version and does not print anything else. I hope that I shall not encounter this awkward situation If I have no need for this additional console. Is it true?

I don't know why the build directory is interfering, I just created by downloading and unzipping only the install directory to gdl64/.

Colors in PS: There is no "PSLIB enhancement" in the windows' build that debian-linux users might be seeing, so this is going through the PLPLOT driver. I don't know much more than that, I remember testing early on and found the SVG driver seemed better. trying that here:

!p.charsize=1.6
!P.title="Sample plot"
!x.title="X Axis title"
!p.thick=2
x=indgen(21)
y0=intarr(21)
y=x^2
plot,x,y0,xrange=[0,20],yrange=[0,400]
oplot,x,y,color=255
y1=200*(1+sin(2*!pi*x/20))
y2=y0+200
oplot,x,y1,color=256L*255L
oplot,x,y2,color=256L*256L*255L,thick=2

I clipped this test run, spawned a new process to preserve the origiinal GDL as I exit the gdl used to create the SVG file (it stays open until gdl exits). Then the SVG file can be read by chrome.

What is the SVG file? If I make a similar experiment pasting the test code, I receive the following output:

InterpreterLoop: Exception: basic_string::substr: __pos (which is 4294967295) > this->size() (which is 0) GDL> plot,x,y0,xrange=[0,20],yrange=[0,400], title='Test', xtitle='x axis',ytitle='y title' PLPLOT_LIB="C:\Program Files (x86)\gnudatalanguage\bin\plplot5.13\lib" PLPLOT_LIB="C:\Program Files (x86)\gnudatalanguage\bin\plplot5.13\lib" PLPLOT_LIB="C:\Program Files (x86)\gnudatalanguage\bin\plplot5.13\lib"

PLPLOT ERROR, ABORTING OPERATION plInitDispatchTable: Could not open drivers directory, aborting operation % PLplot installation lacks the requested driver: wingdi % Execution halted at: $MAIN$ GDL> oplot,x,y,color=255L PLPLOT_LIB="C:\Program Files (x86)\gnudatalanguage\bin\plplot5.13\lib" PLPLOT_LIB="C:\Program Files (x86)\gnudatalanguage\bin\plplot5.13\lib" PLPLOT_LIB="C:\Program Files (x86)\gnudatalanguage\bin\plplot5.13\lib"

(the PLPLOT ERROR message is repeated after each plotting command; the PLPLOT_LIB is again specified for the previous GDL version).

If I try to run a file with this test, GDL fails to find it:

GDL> .r 'D:\IDL\colours.pro' % Error opening file. File: 'D:\IDL\colours.pro'.

Likely, there is some interference of the previous version. The only thing that withholds me from uninstalling it is the hope to make the Workbench work.

[avgetling]

(I'm moved back to the Win 7 machine now) After first not being set, the Quick Edit mode was set on later uses of the spawned console, so that may/may not be a recurring issue. Instead of exiting the spawned process, you can just "DEVICE,/CLOSE" to get a usable image file:

I think all your remaining recommendations will be in a pend state until the above-mentioned errors having been fixed. Thank you once again.

[avgetling]

Thank you, @GillesDuvert

To get a correct PS output, you need to tell the PS driver that the color scheme is DECOMPOSED device,/decomposed,/color,/encap Otherwise the color indexes abov 255, like color=256L*256L*255L are lost. This is true for IDL too, AFAIK. Of course, this is based on my experience of GDL 0.9.8 and IDL 8.4 for Linux only.

Is it not a mistake? In IDL, I obtained the needed colors after introducing the command device, decomposed=0 This is just opposite to what you write. In my test code, DECOMPOSED is set to zero.

[maynardGK]

@avgetling This box was already checked but got working only after unchecking another box, "Use Former Console Version". (This is something I never see) So my assumption has been that you are using windows 10 and the "console" is the CMD.exe found in windows/system32/CMD.exe - is that correct? GDL> plot,x,y0,xrange=[0,20],yrange=[0,400], title='Test', xtitle='x axis',ytitle='y title' PLPLOT_LIB="C:\Program Files (x86)\gnudatalanguage\bin\plplot5.13\lib" These are the kind of messages that happen when the PLPLOT lib-finder is using PLPLOT_HOME; if PLPLOT_LIB is defined it should be silent. The gdl you should be using is provided in install/gdl/bin/ and the current idl procedures (.pro) are found in install/gdl/gdllib. The old Win32 version may be giving you a GDL_STARTUP environment that is messing with things. Add the line @set GDL_PATH=+%cd%\gdl\gdllib to the gdl.bat file and run with GDL_STARTUP undefined:

F:\github\gdl64>type install\gdl.bat
@echo off
@set cur=%cd%
@set path=%cd%\gdl\bin;%path%
@set GDL_PATH=+%cd%\gdl\gdllib
@set PLPLOT_DRV_DIR=%cd%\plplot5.13\drivers
@set PLPLOT_LIB=%cd%\plplot5.13\lib
gdl.exe

F:\github\gdl64>set GDL_STARTUP=
F:\github\gdl64>install\gdl.bat
'gdl.exe' is not recognized as an internal or external command,
operable program or batch file.

F:\github\gdl64>cd install

F:\github\gdl64\install>gdl

  GDL - GNU Data Language, Version 0.9.8 git

- For basic information type HELP,/INFO
- No startup file read (GDL_STARTUP/IDL_STARTUP env. var. not set).
- Please report bugs, feature or help requests and patches at:
  https://github.com/gnudatalanguage/gdl

GDL> print,!path
F:\github\gdl64\install\gdl\gdllib/dicom;F:\github\gdl64\install\gdl\gdllib/envi;F:\github\gdl ...
llib
GDL>

`What is the SVG file? If I make a similar experiment pasting the test code, I receive the following output:

InterpreterLoop: Exception: basic_string::substr: __pos (which is 4294967295) > this->size() (which is 0)`

gdl.svg is what will, by default, be created once SVG is the plot device - unless, probably, you specify DEVICE,FILE="another.svg". The InterpreterLoop error is insignificant but it talles me you are executing another file prior to startup, so take out the GDL_STARTUP environment definition.

[avgetling]

@slayoo, as far as I understand, you are an administrator. For reasons unknown to me, this my issue turned out recently to be closed. This is definitely an error (maybe, mine). I has today some problems with finding the issue and entering it. Could you reopen it? Thank you in advance.

[avgetling]

Thank you, @alaingdl.

[slayoo]

BTW, messaging @gnudatalanguage/gdlmaintainers notifies all those with admin rights

[GillesDuvert]

@avgetling this (quote) ...

Is it not a mistake? In IDL, I obtained the needed colors after introducing the command device, decomposed=0 This is just opposite to what you write. In my test code, DECOMPOSED is set to zero.

... is strange because I have the exact opposite with IDL8.4 on linux:

IDL> set_plot,'ps'
IDL> device,/color
IDL> @color       
IDL> exit

makes a grey postscript where one barely sees the plot;

IDL> set_plot,'ps'
IDL> device,/color
IDL> print,!d     
{ PS       17780       12700       17780       12700         222         352      1000.00      1000.00         256       256           1          -1           0      266807           0           0           1           1}
IDL> device,/decomp
IDL> @color        
IDL> print,!d      
{ PS       17780       12700       17780       12700         222         352      1000.00      1000.00   16777216         256           1          -1         100      266807           0           0           1           1}

make a colored plot (as GDL does). The print,!d is here to show that the number of available colors go from 256 (decomposed=0) to 16777216 (decomposed=1).

[GillesDuvert]

@avgetling (and others), set_plot,'svg'is unique to GDL. It creates a Scalable Vector Graphics which is the open web counterpart of PostScript or PDF. The plplot svg driver is so much better written than their PostScript driver that it is a shame we do not use it more often. For scientists, including SVG plots in LaTeX is apparently feasable today.

[avgetling]

@maynardGK This box was already checked but got working only after unchecking another box, "Use Former Console Version". (This is something I never see) So my assumption has been that you are using windows 10 and the "console" is the CMD.exe found in windows/system32/CMD.exe - is that correct?

Yes, I have Windows 10; this command opens a console, precisely as windows/SysWOW64/CMD.exe does. I opened the console running (via an icon on the desktop) the gdl.bat file, i.e., ultimately dgl.exe.

GDL> plot,x,y0,xrange=[0,20],yrange=[0,400], title='Test', xtitle='x axis',ytitle='y title' PLPLOT_LIB="C:\Program Files (x86)\gnudatalanguage\bin\plplot5.13\lib" These are the kind of messages that happen when the PLPLOT lib-finder is using PLPLOT_HOME; if PLPLOT_LIB is defined it should be silent. The gdl you should be using is provided in install/gdl/bin/ and the current idl procedures (.pro) are found in install/gdl/gdllib. The old Win32 version may be giving you a GDL_STARTUP environment that is messing with things. Add the line @set GDL_PATH=+%cd%\gdl\gdllib to the gdl.bat file and run with GDL_STARTUP undefined:

The bat file was originally composed with this line included (according to your recommendation).

F:\github\gdl64\install>gdl

GDL - GNU Data Language, Version 0.9.8 git

• For basic information type HELP,/INFO
• No startup file read (GDL_STARTUP/IDL_STARTUP env. var. not set).
• Please report bugs, feature or help requests and patches at: https://github.com/gnudatalanguage/gdl

This works exactly in this way. However, after saying

GDL> print,!path

I receive an empty line instead of

F:\github\gdl64\install\gdl\gdllib/dicom;F:\github\gdl64\install\gdl\gdllib/envi;F:\github\gdl ... llib

If I make a similar experiment pasting the test code, I receive the following output:

InterpreterLoop: Exception: basic_string::substr: __pos (which is 4294967295) > this->size() (which is 0)`

gdl.svg is what will, by default, be created once SVG is the plot device - unless, probably, you specify DEVICE,FILE="another.svg". The InterpreterLoop error is insignificant but it talles me you are executing another file prior to startup, so take out the GDL_STARTUP environment definition.

Where is it defined? The bat file does not contain it.

[maynardGK]

I think that the installation procedure used in the sourceforge-originated GDL build has put the environment variables into your system, so you need to find them and edit them away. You may be able to get there by right-clicking at the "Your PC" (from an explorer window or a desktop shortcut, if there) and opening properites/advanced system properties, etc. This would go to control panel and open a dialog from which "environment variables" button should appear.

You can eliminate GDL_STARTUP also in the bat file with the line "@set GDL_STARTUP=" You can see what the GDL_STARTUP file is by "echo %GDL_STARTUP%" at the console. also, just the command "set" from the console will list all of the environment variables in your system.

[avgetling]

I think that the installation procedure used in the sourceforge-originated GDL build has put the environment variables into your system, so you need to find them and edit them away. You may be able to get there by right-clicking at the "Your PC" (from an explorer window or a desktop shortcut, if there) and opening properites/advanced system properties, etc. This would go to control panel and open a dialog from which "environment variables" button should appear.

I removed PLPLOT_DRV_DIR=C:\Program Files (x86)\gnudatalanguage\share\plplot\drivers PLPLOT_HOME=C:\Program Files (x86)\gnudatalanguage\share\plplot

As for GDL_HOME and GDL_PATH, I changed their values into new ones, corresponding to the currently used version.

You can eliminate GDL_STARTUP also in the bat file with the line "@set GDL_STARTUP="

No, the bat file does not contain this line!

You can see what the GDL_STARTUP file is by "echo %GDL_STARTUP%" at the console.

GDL> echo %GDL_STARTUP% % Token stream error: unexpected char: '%'

also, just the command "set" from the console will list all of the environment variables in your system.

GDL> set % PRINT: Variable is undefined: SET % Execution halted at: $MAIN$

GDL> print,!path

returns an empty line.

Thus, regrettably, I have made no progress.

[maynardGK]

%var% is the syntax for the DOS console. From GDL you can see what GDL_STARTUP is by GDL> print,getenv('GDL_STARTUP') You can also spawn,/nowait from GDL and from that console window, the %var% should work. also, simply a "$" should take you to a CMD shell in the GDL window. try also: GDL> spawn, 'set' ,setoutput

which should give you the list of environment variables in GDL strings: GDL> foreach s, setoutput do if(strpos(s,'GDL') ge 0) then print,s

Also, BTW, instead of describing what is happening it would help if you paste the contents of the CMD window with your GDL session into the dialog, as I have been doing for you. If you precede the contents with three back ticks you start a "literal" formatting mode suitable for such:

DL> jj=expand_path('+'+getenv('GDLGIT'))
GDL> jsp=strsplit(jj,':',/extract)
GDL> foreach j,jsp do print,j
/f/github/gdlgit/src/pro/dicom
/f/github/gdlgit/src/pro/envi
/f/github/gdlgit/src/pro/obsolete
/f/github/gdlgit/src/pro/utilities
/f/github/gdlgit/src/pro
/f/github/gdlgit/src
/f/github/gdlgit/testsuite/benchmark
/f/github/gdlgit/testsuite/file_etc
/f/github/gdlgit/testsuite
GDL> 

(expand_path will provide a string suitable for use in !path)

[slayoo]

Let me close this ticket and suggest opening a new one in case further help would be needed.