Creating a WS under Program Control

[paulmansour]

Is it me, or is it a bit awkward to create a workspace with just the objects you want in it, with the proper latent expression, under program control, without messing up your current workspace?

How about allowing a namespace left argument to ⎕SAVE? This namespace would represent the root of the newly created workspace. There would need to be some way to specify ⎕LX, not exactly sure how that would be done.

Or maybe an inverse of sorts to ⎕CY (as suggested to me at the conference) , which would put objects into an existing workspace on disk, and create it too if the dws did not exist. This might provide an elegant way to get the latent expression in.

Any other suggestions for a good solution?

Right now, as far as I can tell, the only way to accomplish this is to have a stub namespace that is launched via ⎕CMD in a new Dyalog session from you current session, which then via ⎕LX loads in some code somehow, and saves itself. Not very elegant.

[Morten|Dyalog]

As we transition to building systems from text source, we're going to need new tools to build workspaces for distribution. I do not yet have a clear idea of how to go about this, but I agree that it is something we need to look at in the near future.

[gil]

I agree, a ⎕PASTE or ⎕CY⍣¯1 would be useful :)

An alternative to using a stub namespace is the use of dyapp files. You can create a static file and launch it or build it dynamically like this:

      ∇ Build;lines;fn;exe;res
[1]   ⍝ Create a dyapp file to build app
[2]    lines←⎕NR⊃⎕SI
[3]    lines↓⍨←1⍳⍨⊣/'⍝→'⍷↑lines
[4]    fn←(⊃1 ⎕NPARTS'./'),'Build.dyapp'
[5]    (⊂lines)⎕NPUT fn
[6]    exe←⊃2 ⎕NQ'.' 'GetCommandLineArgs'
[7]    res←⎕CMD'"',exe,'" DYAPP=',fn
[8]    ⎕NDELETE fn
[9]    :Return
[10]
[11]  ⍝→ Custom build script starts here
[12]   Build
[13]  ⍝⎕SE.Link.Import '#.here' '/this'
[14]  ⍝⎕SE.acre.OpenProject'.'
[15]   #.⎕LX←'#.App.Run'
[16]   0 #.⎕SAVE'app.dws'
[17]   ⎕OFF 0
     ∇

[kai]

I start with a workspace that contains a namespace "Make". This runs a function that collects all the code needed for that workspace (load scripts, copy namespaces) and then executes basically this:

Code: Select all

#.⎕EX↑needed~⍨' '~¨⍨↓#.⎕NL⍳16
0 ⎕SAVE ⎕WSID


where "needed" is a vtv (vector of text vectors) with the names of top-level (#) objects supposed to survive. "needed" does not carry "Make", so that is deleted as well, and exists only on the stack until the function quits.

The left argument (0) of ⎕SAVE tells the interpreter to save the workspace without the stack.

Works well.

[Veli-Matti]

Hi Kai,
I'm just curious: why iota 16?
I'd write the peppered line a little bit shortedly:

      ⎕EX needed~⍨#.⎕NL-⍳9

..but I've been wrong so many times before
-wm

[StefanoLanzavecchia]

It would be great to get more help from Dyalog on this topic. the dyapp files are an interesting proposal, but somehow I did not manage to make them work in my scenario. Instead I discovered something equally interesting: the Unicode version of the interpreter can have its standard input redirected even on Windows. And if we push in the pipe UTF-8 encoded code, it will execute it as if typed from the keyboard. So, if you combine this with []SE.[]FIX which can fix code from source files in a namespace that never gets saved, you have all you need to fill a workspace with code coming from wherever you want without pollution.
In your particular case, Paul, you might be interested in building the workspace through Acre. I don't know the tool well enough to remember if it gets loaded in []SE. Assuming it does, you can literally type statements to be executed under program control in a blank session and clear workspace, including the last []SAVE. I repeat: this only works in the Unicode version and the pipe must be fed with UTF-8 encoded data. You don't even need to install the interpreter properly: all it needs is a minimal command line which includes the apltrans and the aplt parameters. If I remember correctly it works even with the runtime version.

I must credit my colleagues at Simcorp for discovering this hidden feature of the interpreter.

[gil]

the dyapp files are an interesting proposal, but somehow I did not manage to make them work in my scenario.

Can you tell me more about why this didn't work for you?

I hear that dyapp files are not promoted by Dyalog, or rather, that the intention is to replace them with something better. Until then, I find them useful for doing things like building distribution workspaces (.dws files) and/or just loading up a project into the active workspace from text files. I should add that the function defined in a dyapp file does not "pollute" the workspace, so it is particularly useful for building dist files.

Example - Build.dyapp

Code: Select all

 Build
 ⎕SE.Link.Import '#.App' 'path/to/source'
 #.⎕LX←'#.App.Run'
 0 #.⎕SAVE'app.dws'
 ⎕OFF 0

Example - XLoad.dyapp

Code: Select all

 XLoad
 ⎕SE.Link.Import '#.App' 'path/to/source'

Example - Load.dyapp

Code: Select all

 Load
 ⎕SE.Link.Import '#.App' 'path/to/source'
 #.App.Run

Note that path to source is best kept relative to where the dyapp files are to make the project relocatable. Also, on Windows it is easy enough to launch one of these by double clicking (less smooth on other platforms).

[StefanoLanzavecchia]

DYAPP vs. redirection: they seem to achieve similar results and have similar drawbacks.
Neither is documented (I've just checked the 17.0 manual and dyapp= is never mentioned). Somehow, for an old geek like me, redirection feels more natural, and since you can also redirect stdout (and stderr), you can really treat your WS building like a batch job.
Yes, batch jobs: Jenkins, TeamCity and friends. No double-clicking. We like that: double-cliking requires humans. Batch jobs relieve humans from mundane tasks.

The fact that the .dyapp extension is described in the manual as "Dyalog APL SALT application file" makes me fear that the DYAPP= configuration parameter on the command linea might need SALT. In my scenario there's no SALT. There could be, but it's an extra dependency which I don't want to take on and also, I would need to reverse engineer what's needed to use SALT without actually installing an interpreter and add all sort of extra parameters on the command line. The batch job I was referring to earlier, just needs exe and dlls and nothing else to build the WS: no registry. Nothing, except for the silly .dot file whose need might go away in a feature version of the interpreter.

[Morten|Dyalog]

It is one of the top priorities for v18.0 to have a good answer to this question - and the more general issue of launching applications from text/script files only.

DYAPP files are part of SALT and are not recommended as a long term solution, although they do work today.

We have been working on properly supporting redirected input/output and, although some people have discovered that some things work, we have not sorted out all the issues and therefore not yet documented anything. It is unlikely that we will try to get this to work for Classic interpreters.

[kai]

I'm just curious: why iota 16?

Because that means I will always catch whatever Dyalog might introduce in the future ;)

      ⎕EX needed~⍨#.⎕NL-⍳9

..but I've been wrong so many times before
-wm

Well, it's not the same: -⎕NL⍳9 might produce the same as ' '~⍨¨↓⎕nl ⍳9 but that is not guaranteed.

From the documentation:

Furthermore, if ⎕NL is being evaluated inside the namespace associated with a Class or an Instance of a Class, and any element of Y is negative, R includes the Public names exposed by the Base Class (if any) and all other Classes in the Class hierarchy.

And this i not just your own classes! I have seen every now and then something popping up with the name class ¯8.6 - I don't want that!