Page 4 of 4
Re: Portable (load "somelib.lsp") -- why not?
Posted: Mon Dec 16, 2013 10:26 am
by steve
Paul L wrote:but oddly, no error message is printed when a nonexistent file path is given to load.)
You could just change the last line to something like:
Code: Select all
(if (not (load name))
(format t "~a not found" name))))
To support Linux you should also look in ~/.audacity-files/plug-ins
http://wiki.audacityteam.org/wiki/Downl ... g_Plug-ins
Re: Portable (load "somelib.lsp") -- why not?
Posted: Tue Dec 17, 2013 4:05 pm
by Paul L
Did you verify that this works for you in Linux? As for the ~, that is the environment variable $HOME, correct? If XLisp gives you getenv, then doing the rest in Lisp should be easy enough.
Re: Portable (load "somelib.lsp") -- why not?
Posted: Tue Dec 17, 2013 7:14 pm
by steve
Paul L wrote:Did you verify that this works for you in Linux? As for the ~, that is the environment variable $HOME, correct? If XLisp gives you getenv, then doing the rest in Lisp should be easy enough.
On 'Nix systems, "~/" (
tilde, forward-slash) refers to the user home directory.
This is usually something like:
/home/<user-name>/
The first "/" is the root directory. There is nothing below the root directory, that is the start of the file system.
This is the environment variable $HOME (upper case).
In Bash shell:
in Nyquist:
Code: Select all
(get-env "HOME")
; returns /home/john-doe
It would probably be best for the "include" function to return "nil" on fail, then for Linux the user code can have something like:
Code: Select all
(if (not (include "plug-ins" "hello.lsp"))
(load (format nil "~a/.audacity-files/plug-ins/hello.lsp"
(get-env "HOME"))))
or something like that could be in the "include" function.
Also, Nyquist has a global: *file-separator* which returns the file separator character "" if on Windows or "/" if on 'Nix.
Re: Portable (load "somelib.lsp") -- why not?
Posted: Tue Dec 24, 2013 2:11 pm
by steve
Perhaps we could use *RUNTIME-PATH*
On Linux, this points to the nyquist folder where all the .lsp files are.
Code: Select all
(print *RUNTIME-PATH*)
; "/usr/local/share/audacity/nyquist/"
Re: Portable (load "somelib.lsp") -- why not?
Posted: Tue Dec 24, 2013 9:53 pm
by steve
steve wrote:Perhaps we could use *RUNTIME-PATH*
On Linux, this points to the nyquist folder where all the .lsp files are.
Sadly that does not appear to work on Windows.
How about something like this in init.lsp
Code: Select all
(setf *NYQPATH* (current-path))
(setf *PLUGINPATH*
(let ((parentpath (subseq *NYQPATH* 0 (- (length *NYQPATH*) 8))))
(format nil "~a~a~a" parentpath "Plug-ins" *file-separator*)))
(load (format nil "~a~a" *PLUGINPATH* "audacity.lsp"))
That gives us a lisp file that can ship Audacity specific functions and is in a known relative location.
Perhaps also a plug-ins configuration file?
Re: Portable (load "somelib.lsp") -- why not?
Posted: Thu Dec 26, 2013 7:19 pm
by Paul L
I wouldn't put the magic number 8 in the code, which assumes the seven letter folder name "nyquist". But anyway I think the point is proved that we have the means to fix the problem all in lisp. We would need to diverge init.lsp from Roger's project but that is all.
I chose to call the function include by an analogy with the #include directive of C. As with C, we could easily define not one but a sequence of path names to be searched for a relatively specified file.
Re: Portable (load "somelib.lsp") -- why not?
Posted: Sat Dec 28, 2013 1:15 pm
by steve
Paul L wrote:I wouldn't put the magic number 8 in the code, which assumes the seven letter folder name "nyquist".
Though the folder name IS "nyquist". True that it will break if the name is changed, but counting back to the previous file separator will break if the folder hierarchy is changed. Probably better would be to use a symbol for the name of the "nyquist" folder so that if updated it would only need updating in one place, but as you say, at this stage it is just about proof of concept.
Paul L wrote:We would need to diverge init.lsp from Roger's project but that is all.
I would not expect much objection to that as that is the "proper" place for customization.
Paul L wrote:I chose to call the function include by an analogy with the #include directive of C
Yes, good idea.
What I was thinking was, to keep changes to init.lsp to a minimum and for extensibility, to add an "audacity.lsp" file in which "include" and possibly other useful Audacity specific functions could be added. It's a little less direct, but I think would make adding more functions (or macros) cleaner because they could be added into the Audacity specific (audacity.lsp) file.