A Session QuadLX

[paulmansour]

When Dyalog starts up, something, somewhere, looks for user commands and decides whether or not to rebuild the user command cache. In other words, there must be some sort of ⎕LX for the session that Dyalog runs internally. I assume there is no access to such a thing now?

It would be useful if there was some access to this for the programmer. For example, in a user command file, in addition to Run, Help and List, if we could have a function named, say StartUp or Init, that was run once on startup.

That would be through a user command. Or maybe outside the framework of user commands there should be some sort of way to add a function to run on starting the session.

Or maybe all this exists and I don't what I am doing, which is highly likely.

[paulmansour]

I see there is a ⎕SE.onCreate event that I can use.

[Morten|Dyalog]

The issue of populating and initialising the session is something we are working on for v18.0 (spring/summer of 2020). The somewhat ad hoc mechanisms that were created for SALT a long time ago, and for Link in 17.1, will all be replaced by a documented mechanism that will allow you to specify additions to the session on startup. The current plan is to do this simply by placing code that is to be loaded in specific locations (with configuration options to change the default locations).

I'll be talking about this at Dyalog'19. Come to Elsinore September 8th-12th!

[paulmansour]

Excellent, thanks!

[ray]

Having come from STSC mainframe environment with User Commands, back under Dyalog version 7 and 8, I wrote and implemented a "Pseudo-User Command" system (utilising ⎕SE) that I have been using ever since in all (Windows) versions of Dyalog APL. (Now I use it in parallel with Dyalog's own User Commands)

Rather than save the modified (⎕SE) session, I decided to build the session anew each time Dyalog started, by simply loading my user command start up workspace (start.dws) at the start of each session. (This made upgrading to new versions of Dyalog very simple.)

Part of "start.dws" (once the ⎕SE session had been modified) would then ⎕LOAD any application workspace specified in the command line used to start Dyalog.

Code: Select all

"C:\Program Files\Dyalog\Dyalog APL-64 17.0 Unicode\dyalog.exe" C:\Users\Ray\Documents\UCMD141\start.dws LOADWS=application.dws

(You may notice that the start,dws I am currently using dates from Dyalog 14.1 when I converted from Classic to Unicode, although I still have a version 12 for use with Dyalog Pocket APL under Windows CE.)

The ability to easily start a session without triggering the Session QuadLX (akin to ")XLOAD") is a useful feature (if not requirement), as is the ability to "un-modify" any changes made to the session.

PS In the past I have spent quite some time implementing what amounts to "⎕XLOAD", but that a different problem.

[paulmansour]

Ray, thanks. That's nice, and simple way to modify the session!

I guess where that breaks down is when you want less personal stuff (third party tool) to modify the session - then you need to open modify and save the start.dws. Hmm, on the other hand, with a simple convention, start.dws could load in code in .dyalog files found in the same location as start.dws.

That looks like it would do exactly what Morten mentions above - - a good technique until it is baked into the interpreter in v18.

[paulmansour]

So we can get session startup functionality by adding one or more .dyalog files to the UCMD search path in the following form:

Code: Select all

:namespace                                           
      ∇ z←List
        Do whatever you want here
        z←⍬
      ∇
:endnamespace

And if your session initialization itself is needed for a user command, simply name your user command {myname}_Main.dyalog and the associated initialization {myname}_Init.dyalog, and the initialization will happen first.

[paulmansour]

Opps, except that won't work if no UCMD file has changed or been added. Must run ]ureset, which defeats the purpose.