Audacity

Hi all,

I still had no time for extensive tests but with me at home
(Ubuntu 9.10) Nyquist SETDIR prints "/home/edgar", what is a
choice I can live with.

What I do not understand is why the Audacity working directory
(according to Steve's writing) on MS Windows is in directories
which in a professional Windows setup are write-protected for
all users without administrator privileges. To me his makes not
much sense. On MS Windows the working directory must be:

C:\documents and settings\[username]\myfiles

or something similar, the same value as returned by typing:

echo %HOME%

at the Windows command prompt. I will try to test this later
on a Windows machine.

- edgar



-- 
The author of this email does not necessarily endorse the following
advertisements, which are the sole responsibility of the advertiser:

edgar-rft wrote:
> 
> Hi all,
> 
> I still had no time for extensive tests but with me at home
> (Ubuntu 9.10) Nyquist SETDIR prints "/home/edgar", what is a
> choice I can live with.
> 
> What I do not understand is why the Audacity working directory
> (according to Steve's writing) on MS Windows is in directories
> which in a professional Windows setup are write-protected for
> all users without administrator privileges. To me his makes not
> much sense. On MS Windows the working directory must be:
> 
> C:\documents and settings\[username]\myfiles
> 
> or something similar, the same value as returned by typing:
> 
> echo %HOME%
> 
> at the Windows command prompt. I will try to test this later
> on a Windows machine.
> 
> - edgar
> 

At the top of fileio.lsp there is a conditional statement that set's the
working directory and the default-sf-dir if (not (boundp '*default-sf-dir*))
but it looks like *default-sf-dir* is already bound to the Modules
directory. (at least that's how it looks to me with my very limit knowledge
about this sort of thing :=)


Is there any way of entering a backslash from a text input widget? Escaping
a backslash with another backslash does not appear to work.


BTW, I notice that with a text input widget, if instead of entering a double
space after the "text right" you enter:
space text space
the text becomes the default string in the text box.

Example:
;control string-var "Enter some text" string "right text" default\ text 

(note that spaces within the default text must be escaped).

Steve
-- 
View this message in context: http://n2.nabble.com/Setting-Nyquist-working-directory-tp4134136p4142510.html
Sent from the audacity-nyquist mailing list archive at Nabble.com.

I haven't had time yet to read all the working directory discussion, but 
it might help to know that Windows path names can use forward slashes 
instead of back slashes. (Not always with a command prompt, but 
definitely if you have a path as a Nyquist string and try to open a 
file, forward slashes work fine.) -Roger


Stevethefiddle wrote:
> Is there any way of entering a backslash from a text input widget? Escaping
> a backslash with another backslash does not appear to work.
>
>

Hi Audacity Nyquist list,

Some Nyquist commands, defined in "audacity/lib-src/libnyquist/nyx.c"
to manipulate the Nyquist working directory:

(setdir "string")

Set the current working directory. As fas as I have understood the
Audacity Nyquist SETDIR function can be used in two ways:

(setdir ".") returns the current working directory as a string.
(setdir "string") sets the current working directory.

Note that the "current working directory" is not neccessarily the
same as the Nyquist *default-sf-dir*, which in CMU Nyquist is only
the name of a "dump" directory, (usually the system's TEMP dir),
where Nyquist stores temporary sound files.

(get-temp-path)

Returns the full path of the system's TEMP directory as a string.

(get-user)

Returns the name of the currently logged-in user as a string.

IMPORTANT: On MS Windows you cannot reliably re-construct the
user's HOME directory only by the username, because on Windows
the path of the HOME directory is localized:

In an english Windows the user's home directory is something like:
C:\documents and settings\[username]\my files

In a german Windows the same home directory is something like:
C:\Dokumente und Einstellungen\[username]\Meine Dateien

I still have found no way to read the HOME system environment
variable from the Lisp level, where the full path of the user's
home directory is stored on all systems (or at least on Windows,
Mac, and Linux). This, together with GET-TEMP-PATH, would solve
the problem where to write plugin files.

Currently I see no other way than to write plugin files in the
system's TEMP directory, which can be determined by GET-TEMP-PATH.

Currently its up to the plugin programmer to make sure Nyquist
writes into a write-enabled directory. The Audacity Nyquist
defaults do not guarantee this.

Any suggestions how this could be improved?


*** Other commands redefined in "audacity/lib-src/libnyquist/nyx.c"

(system "command")

Does nothing, returns T, for virus protection.

(getkey)

Get a key from the keyboard.
How does this work in an Audacity Nyquist plugin?

(setupconsole)

Does nothing, returns NIL.

(echoenabled)

Does nothing, returns NIL.




- edgar





-- 
The author of this email does not necessarily endorse the following
advertisements, which are the sole responsibility of the advertiser:

Steve wrote:

 > I notice that with a text input widget, if instead of entering a
 > double space after the "text right" you enter:
 >
 > space text space
 >
 > the "text" becomes the default string in the text box.
 >
 > Example:
 > ;control string-var "left text" string "right text" default\ text
 >
 > (note that spaces within the default text must be escaped).

Thanks, I will test this right now, this must definetly be added to
the text input widget documentation.

- egdar


-- 
The author of this email does not necessarily endorse the following
advertisements, which are the sole responsibility of the advertiser:

Edgar wrote:

> (get-temp-path)
>
> Returns the full path of the system's TEMP directory as a string.

I'm the person who orignally brought up the problems with Steve about finding a safe directory for writing files.   

I'm currently running 1.3.10Beta on Win XP/SP3.
and for this situation, Edgar's statement is incorrect.

(get-temp-path) returns the string:

"C:\\DOCUME~1\\User\\LOCALS~1\\Temp"

which is the old MSDOS way of truncating long file names to the 8.3 DOS format.

So this really points to
"C:\\Documents and Settings\\<username>\\Local Settings\\Temp"

(Luckily the (open Filename :direction :output) function also accepts the 8.3 format.  I presume that the OS-X and Linux versions don't do this 8.3 nonsense.)

This directory should be a safe place for writing temporary files, but there is no guarantee that the user won't "clean up" the hard drive by deleting all files in Temp directories, thus clobbering any supposedly permanent files set by a plug-in.

I'm writing a complex, script-driven signal generator plug-in, and I need a place for sample scripts which are distributed with it, and also a second directory for the user to place any new scripts they write.   This means that the plug-in must have a reliable  way to find a small file which contains the strings pointing at the other two directories.   I could put it in a temp directory somewhere, but this may get deleted, so I'd rather not use a temp directory.

It really seems like we need a Nyquist function which will return the users "home" directory on Windows, usually "C:/Documents and Settings/<user>/My Documents" (for English Windows, anyway.)

Dave

It would be simple to add a GET-HOME-PATH or maybe better a GET-ENV 
function to XLISP. GET-TEMP-PATH and GET-USER were never intended for 
the purposes being discussed, so I'm not surprised they don't do the job.

What would help is a clear proposal, ideally for something simple, 
general, and powerful. E.g. GET-ENV is better than GET-HOME-PATH if 
GET-ENV("HOME") really works on all systems.

One issue that should be considered is whether it is a good idea to 
allow Audacity to read/write arbitrary files. I think the current sense 
is that protecting users from plug-ins is not a big priority (and I 
think there's little or no protection now anyway.)

-Roger

Dave Storer wrote:

 > I'm currently running 1.3.10Beta on Win XP/SP3.
 > and for this situation, Edgar's statement is incorrect.
 >
 > (get-temp-path) returns the string:
 >
 > "C:\\DOCUME~1\\User\\LOCALS~1\\Temp"
 >
 > which is the old MSDOS way of truncating long file names
 > to the 8.3 DOS format
 > ...
 > Luckily the (open Filename :direction :output) function
 > also accepts the 8.3 format.

Thanks for the info, and yes, it's true and I apologize, I still hadn't
tested this on a Windows machine. The 8.3 DOS paths are propbably an
XLISP remainder, which originally was a MS-DOS program, so I assume
that all XLISP file functions should be able to "understand" 8.3 DOS
path strings (but again, still not tested on a Windows machine).

 > I presume that the OS-X and Linux versions don't do this 8.3 nonsense.

On Ubuntu Linux I get full untruncated Unix path names:

--- bourne again shell ---
bash$ export TMP=/tmp/verylongpathname/withsubdirectory
bash$ audacity
--- end of bourne again shell ---

Audacity complains: "temp directory not found", but starts.

In Audacity I create a dummy track with "Generate > Silence",
then I open "Effect > Nyquist Prompt" and type:

(print (get-temp-path))

which prints:

"/tmp/verylongpathname/withsubdirectory"

Maybe another bug: this directory does NOT exits on my harddisk,
but I assume nobody but me would try out such a nonsense.

 > It really seems like we need a Nyquist function which will return
 > the users "home" directory on Windows, usually:
 >
 > "C:/Documents and Settings/<user>/My Documents"

Yes, I agree, this would probably be the best solution.

Some background information from my side:

I'm frequently forced to work on Windows computers where I do not
have administrator privileges, so I do not have write permission
in "C:\\Windows...", where Windows lives, and "C:\\Programs...",
where programs like Audacity are installed.

Because of the same reason NO INSTALLED PROGRAM on the internal
harddisk, which is started by me myself without adiministrator
privileges, has write access to any folder in "C:\\Windows..."
and "C:\\Programs.." including all subfolders.

For many sloppily-developed Windows programs this means that
I cannot even change the program's preferences...

In this situation I often have to run programs from external USB or
Firewire devices, because without adiministrator privileges I cannot
install programs on the internal harddisk.

In this context I often have to manipulate the Windows PATH and HOME
and other environment variables, to make the programs being able to
find their own libraries in non-standard Windows directories.

 From this experience I can tell that the value of the HOME variable
on Windows *reliably* returns the full (untruncated) path of the
users HOME directory on all Windows versions I have worked with in
the last ten years.

Also on Mac OS X and Unix/Linux the full path to the user's HOME
directory ist stored in the system's HOME environment variable.

So theoretically with a bit of luck it could be sufficient to add
a GET-HOME-PATH function to the Nyquist interpreter like this one:

LVAL xget_home_path()
{
    char *tmp;

    tmp = getenv("HOME");
    return cvstring(tmp);
}

in the file: audacity/lib-src/libnyquist/nyx.c

Because I'm not an experienced C/C++ programmer I'm not sure if
there are additional modifications needed to make the Nyquist
interpreter recognize this function (answer: probably "yes").

I would be willing to fiddle out how this works but would need
some help from a more experienced developer...

- edgar

Roger wrote:

 > It would be simple to add a GET-HOME-PATH or maybe better a GET-ENV
 > function to XLISP. GET-TEMP-PATH and GET-USER were never intended
 > for the purposes being discussed, so I'm not surprised they don't
 > do the job.

 > What would help is a clear proposal, ideally for something simple,
 > general, and powerful. E.g. GET-ENV is better than GET-HOME-PATH if
 > GET-ENV("HOME") really works on all systems.

 > One issue that should be considered is whether it is a good idea to
 > allow Audacity to read/write arbitrary files. I think the current
 > sense is that protecting users from plug-ins is not a big priority
 > (and I think there's little or no protection now anyway.)

Sorry, I hadnt' seen Roger's mail. There's obviously once again too
much mess in my mailbox.

The GET-ENV proposal is of course better than another specialized
GET-HOME-PATH function.

I will try to find out how this could work...

- edgar





-- 
The author of this email does not necessarily endorse the following
advertisements, which are the sole responsibility of the advertiser:

Hi all on the Audacity Nyquist list,

This is an example how a GET-ENV function could be added to Nyquist
in Audacity as well as a general outline how to add a new C function
to the Audacity Nyquist interpreter.

* DISCLAIMER: I'm not at all a good C programmer and therefore cannot
* promise that the following code makes any sense in a multi-platform
* environment. A review from a more experienced programmer is needed.

The code was only tested on Ubuntu 9.10, where it seems to work.

Here is what I did:

*** file: audacity/lib-src/libnyquist/nyx.c

At the very end of the file I added a new function definition:

--- code ---
/* xget_env -- return the value of an environment variable as string
  * Lisp syntax: (get-env "string")
  * "string" is the name of an environment variable
  * GET-ENV returns the value of the variable as a string,
  * or NIL if the variable was not found in the environment
  */
LVAL xget_env()
{
    char *var = (char *)getstring(xlgastring());
    char *val;

    /* check for too many arguments */
    xllastarg();

    /* get the value of the environment variable */
    val = getenv(var);

    if (!val || !*val) {
       /* return NIL if no variable was found */
       return NULL;
    }
    else {
       /* if the variable exists return the value as a string */
       return cvstring(val);
    }
}
--- end of code ---

Next I added a new function declaration to the XLISP interpreter:

*** file: audacity/lib-src/libnyquist/nyquist/xlisp/xlisp.h

near the end of the file:

--- code ---
/* macstuff, unixstuff, winstuff */

     // ... [lots of other definitions]

LVAL xget_env(void);  // added by edgar
--- end of code ---

CAUTION: This is a list, so all elements except the last element must
be terminated by a comma, only the last element must be terminated by
a semicolon. Take care of this, or you wil get an compiler error.

Finally I added two entries to the XLISP function table:

*** file: audacity/lib-src/libnyquist/nyquist/xlisp/xlftab.c

--- code ---
#ifndef NO_PROTOTYPES_IN_XLISP_H
/* external functions */
extern LVAL

     // ... [lots of other definitions]

     xget_env(void);  // added by edgar
#endif

     // ... [approx 20 lines of other code]

/* the function table */
FUNDEF funtab[] = {

     // ... [lots of definitions]

     /* extra table entries */

     // at the end of the "extra table entries" section:

{   "GET-ENV",    S, xget_env   }, /* 308 */   // added by edgar
--- end of code ---

I re-compile audacity by typing "make" and start it from the
sorce-code directory by typing "./audacity".

In Audacity I create a dummy track with "Generate > Silence", then
I open "Effect > Nyquist Prompt" and type:

(print (get-env "HOME"))

and Nyquist prints:

"/home/edgar"

*** Next I did some error tests:

(print (get-env "USER")) ; different variable
=> "edgar"

(print (get-env "ARGH")) ; non-existent variable
=> NIL

(print (get-env)) ; wrong number of arguments
=> error: too few arguments

(print (get-env "HOME" "TMP")) ; wrong number of arguments
error: too many arguments

(print (get-env 123)) ; wrong-typed argument
=> error: bad argument type - 123

I still haven't tested this on any other system than Ubuntu 9.10,
where it seems to work.

A review from a more experienced programmer is recommended.

Hope this helps a bit and my code is not too much nonsense  :-)

- edgar




-- 
The author of this email does not necessarily endorse the following
advertisements, which are the sole responsibility of the advertiser:

edgar wrote:
> Dave Storer wrote:
>
>  > I'm currently running 1.3.10Beta on Win XP/SP3.
>  > and for this situation, Edgar's statement is incorrect.
>  >
>  > (get-temp-path) returns the string:
>  >
>  > "C:\\DOCUME~1\\User\\LOCALS~1\\Temp"
>  >
>  > which is the old MSDOS way of truncating long file names
>  > to the 8.3 DOS format
>  > ...
>  > Luckily the (open Filename :direction :output) function
>  > also accepts the 8.3 format.
>
> Thanks for the info, and yes, it's true and I apologize, I still hadn't
> tested this on a Windows machine. The 8.3 DOS paths are propbably an
> XLISP remainder, which originally was a MS-DOS program, so I assume
> that all XLISP file functions should be able to "understand" 8.3 DOS
> path strings (but again, still not tested on a Windows machine).
>   
You can find xget_temp_path() in winfun.c: Under Windows, XLISP calls 
the Win32 function GetTempPath(). If it comes back with 8.3 DOS names, 
that's done by Windows, not XLISP. Additional details: there was a case 
where Vista returned "c:\windows" but this is protected in Vista. The 
xget_temp_path() does not allow "c:\windows" and returns "" instead.
>  > I presume that the OS-X and Linux versions don't do this 8.3 nonsense.
>
> On Ubuntu Linux I get full untruncated Unix path names:
>
> --- bourne again shell ---
> bash$ export TMP=/tmp/verylongpathname/withsubdirectory
> bash$ audacity
> --- end of bourne again shell ---
>
> Audacity complains: "temp directory not found", but starts.
>
> In Audacity I create a dummy track with "Generate > Silence",
> then I open "Effect > Nyquist Prompt" and type:
>
> (print (get-temp-path))
>
> which prints:
>
> "/tmp/verylongpathname/withsubdirectory"
>
> Maybe another bug: this directory does NOT exits on my harddisk,
> but I assume nobody but me would try out such a nonsense.
>   
I think this is the correct behavior. If you designate a specific 
directory for temp files, programs should try to use that directory. OK, 
maybe it would be more robust for XLISP to check if the directory 
exists, and if not, return "" which would indicate use the current 
directory instead. I think it's probably better to fail until the user 
fixes what is obviously a problem outside of Audacity/Nyquist.

Based on the rest of edgar's message, it looks like a function to get 
environment strings would allow you to look up "HOME" on any system and 
get a useful result. I'll wait to hear if there are any other thoughts, 
but I will plan to add GET-ENV (maybe I should think about the exact 
name since Nyquist has an "environment" that's something different).

-Roger

Edgar, I changed your code slightly so that if an environment variable 
value is the empty string, then the empty string is returned. Nil is 
only returned if the variable does not exist. Also, I'm putting the 
function into xlsys.c because nyx.c is not part of stand-alone Nyquist 
or XLISP.

I'm not sure about any schedules to update Audacity with the latest Nyquist.

-Roger

edgar wrote:
> Hi all on the Audacity Nyquist list,
>
> This is an example how a GET-ENV function could be added to Nyquist
> in Audacity as well as a general outline how to add a new C function
> to the Audacity Nyquist interpreter.
>
>

Roger wrote:

 > Edgar, I changed your code slightly so that if an environment
 > variable value is the empty string, then the empty string is
 > returned. Nil is only returned if the variable does not exist.
 > Also, I'm putting the function into xlsys.c because nyx.c is
 > not part of stand-alone Nyquist or XLISP.
 >
 > I'm not sure about any schedules to update Audacity with the
 > latest Nyquist.

First of all thanks for reviewing the code.

I have to admit that there was no "deep thought" involved from my
side, I just simply tried to find out how to add a function to the
XLISP interpreter by more-or-less brainlessly copying examples
from other functions in "nyx.c" into a new function and in the
end I was happy that anything worked at all.

The "return NIL" clause was added because in my first attempts
Audacity crashed with non-existent environment variables.

Of course it's better if the return value of GET-ENV behaves
similar to functions like to GET-TEMP-PATH or GET-USER.

Feel free to change my code in whatever ways you think, it only
can get better...

Thanks,

- edgar




-- 
The author of this email does not necessarily endorse the following
advertisements, which are the sole responsibility of the advertiser:

As there may be a substantial delay before Audacity is updated with the 
latest Nyquist, would it be possible for you to post the changes that 
you have made so that we can try this out?

Steve D


Roger Dannenberg wrote:
> Edgar, I changed your code slightly so that if an environment variable 
> value is the empty string, then the empty string is returned. Nil is 
> only returned if the variable does not exist. Also, I'm putting the 
> function into xlsys.c because nyx.c is not part of stand-alone Nyquist 
> or XLISP.
>
> I'm not sure about any schedules to update Audacity with the latest Nyquist.
>
> -Roger
>
> edgar wrote:
>   
>> Hi all on the Audacity Nyquist list,
>>
>> This is an example how a GET-ENV function could be added to Nyquist
>> in Audacity as well as a general outline how to add a new C function
>> to the Audacity Nyquist interpreter.

Sure, look at the latest commit to Nyquist at sourceforge. -Roger

Steve the Fiddle wrote:
> As there may be a substantial delay before Audacity is updated with the 
> latest Nyquist, would it be possible for you to post the changes that 
> you have made so that we can try this out?
>
> Steve D
>
>
> Roger Dannenberg wrote:
>   
>> Edgar, I changed your code slightly so that if an environment variable 
>> value is the empty string, then the empty string is returned. Nil is 
>> only returned if the variable does not exist. Also, I'm putting the 
>> function into xlsys.c because nyx.c is not part of stand-alone Nyquist 
>> or XLISP.
>>
>> I'm not sure about any schedules to update Audacity with the latest Nyquist.
>>
>> -Roger
>>
>> edgar wrote:
>>   
>>     
>>> Hi all on the Audacity Nyquist list,
>>>
>>> This is an example how a GET-ENV function could be added to Nyquist
>>> in Audacity as well as a general outline how to add a new C function
>>> to the Audacity Nyquist interpreter.  
>>>       
>
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Audacity-nyquist mailing list
> Audacity-nyquist@...
> https://lists.sourceforge.net/lists/listinfo/audacity-nyquist
>
>

Thanks, that works a treat on Linux, (once I worked out the mysteries of how
to find the latest commit on sourceforge :-)

Has anyone tried this on Windows or Mac?

Steve



Roger Dannenberg wrote:
> 
> Sure, look at the latest commit to Nyquist at sourceforge. -Roger
> 
> Steve the Fiddle wrote:
>> As there may be a substantial delay before Audacity is updated with the 
>> latest Nyquist, would it be possible for you to post the changes that 
>> you have made so that we can try this out?
>>
>> Steve D
>>
>>
>> Roger Dannenberg wrote:
>>   
>>> Edgar, I changed your code slightly so that if an environment variable 
>>> value is the empty string, then the empty string is returned. Nil is 
>>> only returned if the variable does not exist. Also, I'm putting the 
>>> function into xlsys.c because nyx.c is not part of stand-alone Nyquist 
>>> or XLISP.
>>>
>>> I'm not sure about any schedules to update Audacity with the latest
>>> Nyquist.
>>>
>>> -Roger
>>>
>>> edgar wrote:
>>>   
>>>     
>>>> Hi all on the Audacity Nyquist list,
>>>>
>>>> This is an example how a GET-ENV function could be added to Nyquist
>>>> in Audacity as well as a general outline how to add a new C function
>>>> to the Audacity Nyquist interpreter.  
>>>>       
>>
> 

-- 
View this message in context: http://n2.nabble.com/Setting-Nyquist-working-directory-tp4134136p4207207.html
Sent from the audacity-nyquist mailing list archive at Nabble.com.

Tested with Audacity 1.3.12 (beta) and 1.3.13 (alpha).
(GETENV) is clearly in the Nyquist code now, but always returns NIL.
-- 
View this message in context: http://audacity.238276.n2.nabble.com/Setting-Nyquist-working-directory-tp4134136p5655755.html
Sent from the audacity-nyquist mailing list archive at Nabble.com.

(GETENV) is a macro to get the current LISP environment. Read all 
about it in runtime/evalenv.lsp

I take it you are trying to get operating system environment variables 
as in the getenv() C function. I don't see that in the documentation, 
and the only calls to getenv() in the Nyquist source are to get some 
specific variables like TMP, USER, and XLISPPATH.

I think you meant GETENV rather than GET-ENV. I don't see any GET-ENV uses.

-Roger

On 10/20/2010 12:59 PM, Stevethefiddle wrote:
> Tested with Audacity 1.3.12 (beta) and 1.3.13 (alpha).
> (GETENV) is clearly in the Nyquist code now, but always returns NIL.

Thanks Roger.
There's a parallel discussion on the Audacity forum and the confusion with
(GETENV) has just been discovered.
http://forum.audacityteam.org/viewtopic.php?f=39&t=42368

However the real question here is concerning the (GET-ENV) function, or
whatever it was eventually named, that you committed to the Nyquist source
back in December 2009
ref.
http://audacity.238276.n2.nabble.com/Setting-Nyquist-working-directory-tp4134136p4154995.html 

I've looked in xlsys.c and the changes that relate to this time period are
in 	revision 1.4 by rbd, Sat Dec 12 03:31:55 2009 UTC
http://nyquist.cvs.sourceforge.net/viewvc/nyquist/nyquist/xlisp/xlsys.c?r1=1.3&r2=1.4
This only mentions "getenv", but it appears to tie in with the code that
edgar-rtf wrote for determining the HOME-PATH.

The practical task in question is how to reliably write a text file to a
location that is accessible to the average Audacity user. This was the same
question back in December last year and I thought it had been resolved, but
we are still unable to do so.

The users "HOME" directory would be an obvious choice of where to output a
text file as the user will have read/write access on all platforms. The
question now, as it was last December, is how to do that.

For some reason (unknown to myself) if I enter (get-env "HOME") or (get-env
'home) at the Nyquist prompt, it returns my Home directory "/home/steve".
This is with Audacity 1.3.13 alpha built from SVN head on Ubuntu 10.10.
However if I enter (get-env "HOME") at the Nyquist prompt in Audacity 1.3.12
I get "error: unbound function - GET-ENV"

Another user has tried (get-env 'home) on Audacity 1.3.12-alpha-Oct 20 2010
(CVS HEAD from yesterday) on Debian_5 (Lenny) and also gets "error: unbound
function - GET-ENV"

Another user has tested with Audacity 1.3.12 (release build) on Windows XP
and also gets "error: unbound function - GET-ENV"

So the question is, is there a way for a Nyquist plug-in to determine the
users "HOME-Path", and if so, how?
-- 
View this message in context: http://audacity.238276.n2.nabble.com/Setting-Nyquist-working-directory-tp4134136p5658455.html
Sent from the audacity-nyquist mailing list archive at Nabble.com.

I'M JUST NOT INTRETED-I DON'T PLAY ANYMORE.THANX

Hi Steve,
     You are right. I searched for get-env and looked in released rather 
than latest documentation and I missed the fact that GET-ENV exists. And 
yes, I mistakenly referred to it at GETENV in a comment. The latest 
documentation in my sources is:

         (get-env /name/) - get from an environment variable
/name/ - the name (string or symbol) of the environment variable
            returns  - string value of the environment variable, nil if 
variable does not exist

I didn't check the Audacity sources, but it looks like version 1.3.12 
does not have GET-ENV, but version 1.3.13 does. If you want to check 
sources, try this:
     cd audacity-src/lib-src/libnyquist/xlisp
     grep xget_env *
This prints:

xlftab.c:    xget_env(void), xload(void),xtranscript(void),
xlftab.c:{       "GET-ENV",                      S, xget_env             
}, /* 308 */
xlisp.h:LVAL xget_env(void);
xlsys.c:/* xget_env - get the value of an environment variable */
xlsys.c:LVAL xget_env(void)

The key line is #2 (puts GET-ENV in the XLISP interpreters list of 
built-in functions). That line references xget_env, so if that line 
compiles and links, then xget_env (the actual implementation) is 
included, and it is accessible as GET-ENV in XLISP code.

This is in the latest Audacity sources.

-Roger


On 10/21/10 8:25 AM, Stevethefiddle wrote:
> Thanks Roger.
> There's a parallel discussion on the Audacity forum and the confusion with
> (GETENV) has just been discovered.
> http://forum.audacityteam.org/viewtopic.php?f=39&t=42368
>
> However the real question here is concerning the (GET-ENV) function, or
> whatever it was eventually named, that you committed to the Nyquist source
> back in December 2009
> ref.
> http://audacity.238276.n2.nabble.com/Setting-Nyquist-working-directory-tp4134136p4154995.html
>
> I've looked in xlsys.c and the changes that relate to this time period are
> in 	revision 1.4 by rbd, Sat Dec 12 03:31:55 2009 UTC
> http://nyquist.cvs.sourceforge.net/viewvc/nyquist/nyquist/xlisp/xlsys.c?r1=1.3&r2=1.4
> This only mentions "getenv", but it appears to tie in with the code that
> edgar-rtf wrote for determining the HOME-PATH.
>
> The practical task in question is how to reliably write a text file to a
> location that is accessible to the average Audacity user. This was the same
> question back in December last year and I thought it had been resolved, but
> we are still unable to do so.
>
> The users "HOME" directory would be an obvious choice of where to output a
> text file as the user will have read/write access on all platforms. The
> question now, as it was last December, is how to do that.
>
> For some reason (unknown to myself) if I enter (get-env "HOME") or (get-env
> 'home) at the Nyquist prompt, it returns my Home directory "/home/steve".
> This is with Audacity 1.3.13 alpha built from SVN head on Ubuntu 10.10.
> However if I enter (get-env "HOME") at the Nyquist prompt in Audacity 1.3.12
> I get "error: unbound function - GET-ENV"
>
> Another user has tried (get-env 'home) on Audacity 1.3.12-alpha-Oct 20 2010
> (CVS HEAD from yesterday) on Debian_5 (Lenny) and also gets "error: unbound
> function - GET-ENV"
>
> Another user has tested with Audacity 1.3.12 (release build) on Windows XP
> and also gets "error: unbound function - GET-ENV"
>
> So the question is, is there a way for a Nyquist plug-in to determine the
> users "HOME-Path", and if so, how?

Thanks very much Roger, it appears to work correctly with the latest Audacity
source code.
Just waiting now for colleagues to confirm that it works on Windows and Mac.

Steve


@ jsp67
If you are receiving e-mails from nabble you can unsubscribe here:
http://audacity.238276.n2.nabble.com/mailing_list/MailingListOptions.jtp?forum=238279
-- 
View this message in context: http://audacity.238276.n2.nabble.com/Setting-Nyquist-working-directory-tp4134136p5659202.html
Sent from the audacity-nyquist mailing list archive at Nabble.com.

| From jsp67@... 
| Thu, 21 Oct 2010 13:51:17 +0000 (UTC)
| Subject: [Audacity-nyquist] Nyquist GET-ENV function code example
> i'm just not intreted-i don't play anymore.

In that case please unsubscribe yourself at the bottom of this page:
https://lists.sourceforge.net/lists/listinfo/audacity-nyquist



Gale

"Stevethefiddle" wrote:
> Thanks very much Roger, it appears to work correctly with the latest
> Audacity source code.
> Just waiting now for colleagues to confirm that it works on Windows and
> Mac.
I tested it OK now on Windows 7 x64 and commented in the Bugzilla report
this relates to:
http://bugzilla.audacityteam.org/show_bug.cgi?id=60

Bug 60 can be closed if Mac and Nyquist Workbench tests OK. 


Gale 

--
View this message in context: http://audacity.238276.n2.nabble.com/Setting-Nyquist-working-directory-tp4134136p6781373.html
Sent from the audacity-nyquist mailing list archive at Nabble.com.