Scripting in V18

General APL language issues

Scripting in V18

Postby paulmansour on Mon Jun 15, 2020 12:10 pm

So in v18 we have the new Load parameter. However, it does not appear that I can load and execute a text file (let's call it a script file) like:

      ]box on
]display ⊂⍳10



Am I missing something? I can do this with no footprint by piping in standard input from another APL session using .NET (and with the new multi-line input feature its awesome, I can execute anything!). Shouldn't I be able to do this from a text file?
paulmansour
 
Posts: 341
Joined: Fri Oct 03, 2008 4:14 pm

Re: Scripting in V18

Postby paulmansour on Mon Jun 15, 2020 12:47 pm

I was just testing with a .txt file, but I assume the extension is immaterial. The load parameter currently recognizes .dws, .aplf, .aplc and .apln. Is there a convention yet for what a script file's extension should be ? .apl seems appropriate - its general and the fourth character then gets specific.
paulmansour
 
Posts: 341
Joined: Fri Oct 03, 2008 4:14 pm

Re: Scripting in V18

Postby Adam|Dyalog on Sun Jun 21, 2020 12:44 am

A problem with simply piping in is that any ⎕ or ⍞ will take the next line as its input.

Instead, call
Code: Select all
dyalog DYALOG_LINEEDITOR_MODE=1 -script filename
User avatar
Adam|Dyalog
 
Posts: 84
Joined: Thu Jun 25, 2015 1:13 pm

Re: Scripting in V18

Postby Morten|Dyalog on Sun Jun 21, 2020 7:23 am

Resolving the issues related to redirected input and output is an important goal of Dyalog v19.0.
User avatar
Morten|Dyalog
 
Posts: 388
Joined: Tue Sep 09, 2008 3:52 pm

Re: Scripting in V18

Postby paulmansour on Mon Jun 22, 2020 11:00 am

I'm not promoting piping nor do I have a problem with it. I asked how to execute a script.

The V18 documentation states this:

Loading a Script
Instead of starting a workspace, APL can be instructed to load a program from a
script file. This is achieved using the Load and LX parameters which may be
specified on the command line or via a Configuration file.
Examples:
"c:\program files\…\dyalog.exe" myapp maxws=64000
"c:\program files\…\dyalog.exe" session_file=special.dse
"c:\program files\…\dyalog.exe -x myapp aplt=mytrans.dot
default_io=0 myparam=42"
"c:\program files\…\dyalog.exe SALT\CommandFolder=c:\salt cellar"
"c:\program files\…\dyalog.exe SALT_CommandFolder=c:\salt cellar"


I cannot find any mention of -script. It does not appear to be documented as either a command line option or command line parameter. Is it documented somewhere else? Is it experimental or can I rely on it?

I tried it and it appears to work. I suppose with enough experimentation I can figure out how errors are handled and if any stdout or stderr or return code is provided.
paulmansour
 
Posts: 341
Joined: Fri Oct 03, 2008 4:14 pm

Re: Scripting in V18

Postby Morten|Dyalog on Mon Jun 22, 2020 1:21 pm

-script is not documented because it is considered to be work in progress, to be completed properly and documented in v19.0. If you can make do with LX and/our LOAD or configuration files in v18.0, that is what I would recommend. You may be able to get things to work with -script but we cannot support it or guarantee that it won't change in v19.0.

The examples in that documentation need to be updated to show some more up-to-date examples, we'll get that done too.
User avatar
Morten|Dyalog
 
Posts: 388
Joined: Tue Sep 09, 2008 3:52 pm

Re: Scripting in V18

Postby paulmansour on Mon Jun 22, 2020 3:19 pm

That's fine. I can probably make do with LOAD and LX, and I'll treat -script as experimental.
paulmansour
 
Posts: 341
Joined: Fri Oct 03, 2008 4:14 pm

Re: Scripting in V18

Postby paulmansour on Mon Jun 22, 2020 8:20 pm

Is there any reason that -script should fail if using the runtime interpreter and something is done in the session? I understand historically why it does now, but in V19, is there any reason that it should fail in using runtime?

Edit: and same question for piping in stdin.
paulmansour
 
Posts: 341
Joined: Fri Oct 03, 2008 4:14 pm

Re: Scripting in V18

Postby paulmansour on Mon Jun 22, 2020 8:35 pm

Maybe the real question is "are most if not all of the runtime restrictions not really appropriate at this point"? That is, the point that a no-questions-asked free download of the full interpreter is available?
paulmansour
 
Posts: 341
Joined: Fri Oct 03, 2008 4:14 pm


Return to Language

Who is online

Users browsing this forum: No registered users and 1 guest