Start Here

[Morten|Dyalog]

From version 11.0, Dyalog supports the use of Unicode scripts (usually stored as UTF8 text files) for storage of Classes and Namespaces. The Simple APL Library Toolkit (SALT) provides a simple mechanism for loading and saving these scripts.

Version 12.1 introduced User Commands, which are entirely based on APL source code stored in Unicode text files - and make SALT easier to use (all SALT commands are now available as User Commands).

The Documentation Centre (available via the Help|Documentation centre menu in version 12.0, or online at http://www.dyalog.com/documentation) contains a documents introducing both SALT and user Commands.

Since 2008, Dyalog is been using SubVersion (http://subversion.tigris.org/) for management of source code written in APL, C and other languages used to implement the Dyalog system. If SALT is used to store APL source code, tools like SubVersion can manage APL code in exactly the same way as code written in any other language.

[mhicham]

Hello,
i'm looking for a svn-client-plugin for dyalog apl like http://ankhsvn.open.collab.net/ankhsvn/screenshots for visual studio.
can someone help me or give a tip?

thanks
Hicham

[Morten|Dyalog]

The number of SVN users in the Dyalog community is still fairly small (most people still use homegrown source code management systems implemented in APL), so nobody has (yet) been sufficiently motivated to work on tight integration between SVN and APL. There is a set of "user commands" which allow you to issue SVN commands from within APL, but the way most people seem to work is to map a set of classes and workspaces to similar external structure containing text files, and then use a tool like Tortoise to "manage" committing these to SVN from outside APL. This works well enough that nobody has yet done them work to integrate APL directly with an APL session (within the workspace explorer, for example).

We have plans to extend APL to support external text files directly (rather than using the current "SALT" component). This was on the table for the next release but got pushed back a year for various reasons (including the desire to keep Dyalog APL and the coming APL# system "on the same page" wrt source code management). When we do that work, we will think about whether we can provide an SVN plugin or at least a general mechanism for writing plugins for source code management systems.

Can you tell us a bit more about the source code structure that you are trying to manage?