No worries, Jürgen. My choice of project name is a poor representation of the scope of its capabilities.
On Wed, Dec 21, 2016 at 09:31:01PM +0100, Juergen Sauermann wrote: > Hi David, > > truly sorry that I forgot to mention it. > > /// Jürgen > > > On 12/21/2016 08:55 PM, David B. Lamkins wrote: > > This seems like a good time to again mention my APL package manager. > > [1]https://github.com/TieDyedDevil/apl-pkg > > This provides, among other things: > > - a way to organize APL code, > - analysis tools, and > - editor integration. > > I'll start with editor integration, since that's the current topic of > interest. You can edit any function that the package manager has loaded with > the command: > > ]pkg edit <function-name> > > This opens the function in an external editor, positioning the cursor to > the header line of the function within the .apl file from which the function > was loaded. > > The editor itself defaults to `vi`; this can be be changed by naming your > favorite editor in the package manager's configuration file. In the editor, > the keyboard is mapped for APL without using `loadkeys` or `xmodmap`. > > The package also provides a wrapper script `awe` (for APL Workbench > Environment) that, among other things, establishes a proper environment to > support the editor. By default this is `dvtm` in the Linux console and your > window manager under X. The `awe` script also supports `tabbed` (an XEmbed > container) and `dvtm` under X. > > The package manager's analysis tools include: > > - apropos (find APL functions, variables or operators by partial name) > - refs (list all non-local names referenced by a function) > - uses (list all functions that use a given user-defined function, > variable or operator) > - undefs (list names referenced but not defined) > - unrefs (list named defined but not referenced) > - locate (identify the file from which a function or operator has been > loaded) > - inspect (inspect/edit variables via navigation of their nested > structure) > > Then there's the actual package management functionality. Simply put, a > package is a collection of source code in one or more .apl files. A package > may depend upon other packages; dependencies are loaded as needed. You may > program the package loader (on a per-package basis) to perform different > actions depending upon certain environmental queries, e.g. what's the OS? > > A package's loader may shell out to do non-APL things. For example, you > can compile the code of a shared library to be loaded as a native function > using GNU APL's quad-FX extension. > > All of the above is already implemented. I use the package manager to > develop the package manager and some other utility libraries, such as my > ISO-compliant component file library. > > [2]https://github.com/TieDyedDevil/iso-apl-cf > > In the longer run, I intend to implement versioned dependency loading and > the ability to load packages from the `net. > > > > On Wed, Dec 21, 2016 at 01:35:36PM +0100, Juergen Sauermann wrote: > > Hi Alexey, > > I am myself not familiar with emacs and, as a matter of fact, I do > not even > have it > installed on my machine. I believe the most efficient way to write > APL programs > these days is to edit the functions and variables offline in a > separate .apl > file which > is then run in a separate window. Like you write a C/C++ program > beforehand. > compile it, and then execute it. With that approach you can use > whatever editor > you prefer and you have all the functions and variables in a single > file and in > a > consistent state. It also simplifies the documentation and publishing > of APL > programs lot. > You can also check-in the .apl files into a revision control system, > diff them, > and so on. > > The interactive mode of APL (including function editing) has always > had severe > limitations > and I have provided it only for compatibility and for the elder APL > programmers > who are used to it. > The interactive mode was definitely an improvement over the punch > cards used > when APL was invented, > but today the capabilities of computers are very different and I > would not > recommend the interactive mode > for newcomers to APL. > > > > References: > > [1] https://github.com/TieDyedDevil/apl-pkg > [2] https://github.com/TieDyedDevil/iso-apl-cf
