Portable (load "somelib.lsp") -- why not?

[Paul L]

Wow, will version 4 let me inspect sound samples in the track outside of the selection? I have posted to the wish list and I wanted that capability for my very first Nyquist project, though I found another workaround.

Can you point me to a page telling me exactly what to expect for 4.0?

[Paul L]

I am contemplating my own radical but compatible rewrite of the XLisp folder for a faster and more fully featured Lisp (but still much less than all of Common Lisp), beyond a few little fixes. This would be my own hobby project of possible interest on this board. Perhaps I would start my own Sourceforge project, choose a name that does not suggest any endorsement by the Audacity or Nyquist projects, and instruct developers how to drop the replacement into Audacity builds and use at their own risk. Just for the fun and self education of it. XLisp 2.0 is not so big that this would be an unmanageble fun project.

Does that sound too presumptuous? But then Audacity is "our" name here.

[steve]

If you have a drop-box account, PM the necessary details to me so that I can share what I've got so far.

[steve]

I appreciate that working on an existing project that has low activity can be frustrating, especially when the project maintainer has limited availability, but pushing bug fixes and enhancements upstream is likely to be more beneficial for Audacity users / Audacity plug-in writers, and much more widely used than a forked project.
I see no harm in running your own "hobby project", but if it really is "compatible" then there would be no reason for not merging your bug fixes / enhancements back into CMU Nyquist would there?

[Paul L]

That might be the desirable outcome, but before that happens I would need more freedom to develop and share it at my own pace, and other volunteers must try it to build confidence in it. Why should Roger or anyone trust my project before that?

[steve]

Take all the time that you need

If you write drop-in replacements for existing lsp files then I'm sure that Robert and I can test them.
If your changes require building from source, then I can do some testing as long as your patches are against the current svn head/

Going back to your original question:

Remind me of the status of this. As I recall, loading a file with a pathname that is not absolute is not portable across supported Audacity platforms. Why not? This sounds like a big omission and a deterrent to developing more complicated effects with Nyquist.

It should not be a problem as long as the files to be loaded are placed in the Nyquist folder.
On Windows that is a subdirectory of the Audacity installation folder.
On Linux that is /usr/local/share/audacity/nyquist or /usr/share/audacity/nyquist
On Mac OS X, I think it will usually be under "Applications" (but check with a Mac user).
If the file is in the Nyquist folder then it can be loaded without specifying a path:

Code: Select all

(load "filename")

"filename" is case sensitive on Linux and may be case sensitive on Mac OS X.
It is safest to include the file extension, though XLisp should assume ".lsp" if not specified, but I've not tested how well behaved that is.

It would probably not require much of a hack to allow the plug-ins folder to be used as an alternative to the Nyquist folder. That would be a lot more convenient on Linux.

[Robert J. H.]

There's a forum member that seems to have a Common Lisp background.
I initially hoped for some input from this side.
http://forum.audacityteam.org/viewtopic ... 97#p214197

[Paul L]

Oh, so all is welk if new .lsp files go to nyquist? Somehow I misremembered things as not so simple or portable.

[steve]

Oh, so all is welk

More amusing with an "h"

Somehow I misremembered things as not so simple or portable.

It would be really nice if we could just put all the files into the Plug-ins folder, but that is the bit that has cross platform problems.

[Paul L]

I have found a simple all-lisp solution. Add these lines to the end of init.lsp:

Code: Select all

(setq *nyquist-home* (current-path))

(defun parent-path (path)
  (let ((path-length (length path)))
    (dotimes (ii (1- path-length) "")
      (when (equal (char path (- path-length ii 2)) *file-separator*)
        ;; return path that includes trailing separator
        (return (subseq path 0 (- path-length ii 1)))))))

(defun include (&rest relative-path-components)
  (let ((separator (string *file-separator*))
        (name (parent-path *nyquist-home*)))
    (when relative-path-components
      (setf name (strcat name (car relative-path-components)))
      (dolist (component (cdr relative-path-components))
        (setf name (strcat name separator component))))
    (load name)))

Now in a .ny file in plug-ins, this works to load a file in the same folder:

Code: Select all

(include "plug-ins" "hello.lsp")

The file just contains (print "hello") and I verified it with debug output of the plug in. (A message identifying the file also prints to debug whenever a file successfully opens for load, but oddly, no error message is printed when a nonexistent file path is given to load.)

We can argue about the best names and interface, I don't pretend these are the best, but look, it works for me on Windows, with no mention of the unportable "\" character or of absolute paths. Please verify on your system.

(Maybe the function could just work relative to *nyquist-home* instead and allow unix-y strings like "../hello.lsp" which could be parsed in Lisp so as to work with Windows too: interpret each ".." as a call of parent-path, and substitute *file-separator* for each / character. Unix-y bias in the naming convention but everything is there to make it work portably.)

This solution relies on (current-path) and *file-separator* which are not defined in xlisp proper but in all the things that nyinit.lsp loads. (current-path) uses *loadingfiles* which is part of xlisp. The global *loadingfiles* is a list of alternating file names and file objects for the current nested (load). I discovered that when you execute a Nyquist plug-in, you are not inside a call of (load), so it is necessary to capture the pathname once when lisp initializes.