Startup.dyalog in V18

[paulmansour]

This function bootstraps Link. But then it does not use Link to load additional code located in folders specified by DyalogStartupSE. This means you can't load anything other than flat folder of code. Is there any reason for this?

[paulmansour]

So the startup mechanism appears to be less than useful.

I want to be able to execute code on startup. I can only do this by highjacking the DyalogStartup parameter and pointing to my own function, which means whatever Dyalog wants to do on startup does not get done (instantiating Link). So I can have Link, or I can execute my own stuff, but I can't do both. Correct? Or am I missing something?

How about providing a UserStartup parameter (or some such name) that executes after DyalogStartup? This would allow me to actually use Link to load more code, instead of using the DyalogStartupSE parameter which doesn't even use Link to load the additional code, and thus cannot handle anything more than a flat folder.

[paulmansour]

Perhaps the DyalogStartup parameter should be a folder rather than a file. Then any and all functions dropped in this folder would get executed on startup.

[paulmansour]

In startup.dyalog it says:

      ⍝ Please do not rely on the current behaviour of this function, as it may change without warning.

What does this mean? Does it mean that the parameters "DyalogStartup" and "DyalogStartUpSE" are experimental and that what (not how) startup.dyalog does with them is experimental and may change without warning?

As far as I can tell, all this function does is make sure Link is installed and then fixes other code it finds in folders defined in DyalogStartupSE. Can I rely on this behavior or end-result in the future? (not what the function actually does or even if it even exists). Or is the whole thing experimental?

[Morten|Dyalog]

Hi Paul,

The new "startup" code was written because we started using Git[Hub] to develop and maintain a small number of things that need to be loaded and enabled when Dyalog APL starts, at least in the default configuration.

That warning is there because it is our experience that, when we use APL code to extend the environment, users often read the code and decide to piggy-back on things that we did not polish enough for us to want to document them and make them public.

I expect that we *will* soon do as you suggest and base the mechanism on Link. However, we did not want to make the mechanism dependent on Link always being there just yet, because we know that we have clients who selectively install parts of the full Dyalog package and might not include the Link folder. Link itself is also relatively new technology that could do with a burn-in period before we make the entire APL IDE completely dependent upon on it.

As an alternative: have you looked at the new capabilities of version 18.0, in particular the LOAD and LX parameters, which can be set in configuration files? I would hope that these should give you everything you need to customize your APL startup.

[paulmansour]

Morten thanks.

I'm happy to use the LOAD and LX parameters instead.

For some reason I had it in my head I should use DyalogStartup and DyalogStartupSE for session initialization. It didn't really occur to me that LOAD and LX is really a less restrictive way to do the same thing.

It does beg the question of why DyalogStartup and DyalogStartupSE are documented at this point.

[Morten|Dyalog]

Deciding what to document is always tricky, perhaps we did get this one wrong. Alas, sometimes decisions get taken too close to the release date, when people have little time to think everything through. I'm sure that never happens to you ;-).

I often set DyalogStartupSE to point to a different branch than the one shipped with Dyalog APL, during development and testing - and sometimes instruct users to do the same if they want to test bug-fixes or a pre-release version rather than the one that was shipped with the Dyalog APL that they have installed.

LOAD and LX are really useful (if I say so myself), as is the ability to run directly off a text file representing an APL function, class or namespace - and the new configuration files. If y'all haven't started playing with this stuff yet, take a look at the webinar series on v18.0, starting with https://dyalog.tv/Webinar/?v=BSQr203sbWc.