I agree with John. This needs more discussion.

In my experience, the #1 question for Windows users of Csound is, "How do I set an environment variable?" This is something most Windows users never need to do.

Also, it is a frequent request to developers, and not only from Windows users, that Csound function without any environment variable settings at all. I would prefer this myself.

I suggest that files be located as follows:

1) Try using the absolute path.
2) Try using the environment variables.
3) Try using hard-coded paths (this is what would work if no environment variables were used). It is a question whether these paths should be relative to (a) the root directory, (b) the Csound bin directory, or (c) the current working directory.
4) Try the current working directory itself.

Regards,
Mike

-----Original Message-----
>From: jpff 
>Sent: May 16, 2007 10:21 AM
>To: Developer discussions 
>Cc: csound-devel@lists.sourceforge.net
>Subject: Re: [Cs-dev] Proposal for changes to opening certain files
>
>Not totally happy about this.
>
>A HOSTOUTDIR seems odd for ftload for example
>When i use dumpk I definitely want it in the current directory
>I am not sure about all the environment variables anyway -- may be a
>Unix/Linux way of working but it seems to cause lots of problems on
>Windows
>
>I am just suggesting that we think about this first
>
>==John ffitch
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by DB2 Express
>Download DB2 Express C - the FREE version of DB2 express and take
>control of your XML. No limits. Just data. Click to get it now.
>http://sourceforge.net/powerbar/db2/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote on 5/16/07 10:37 AM:

> I agree with John. This needs more discussion.
> 
> In my experience, the #1 question for Windows users of Csound is, "How do I
> set an environment variable?" This is something most Windows users never need
> to do.

I hope that I am not being misunderstood.  I am not proposing adding a new
environment variable that would need to be set by users.  The proposal for
HOSTOUTDIR is for a path variable set via the API that would allow the host
application to specify an output directory for files that do not already
have a "default location".  HOSTOUTDIR would _not_ be read from the current
shell environment.

Thus, commandline Csound would be unaffected.  But hosts could be made more
user-friendly by automatically setting HOSTOUTDIR to the same location as
the orchestra or score for example.

> Also, it is a frequent request to developers, and not only from Windows users,
> that Csound function without any environment variable settings at all. I would
> prefer this myself.

I think it would still be unnecessary to set any environment variables with
my proposed changes.  (OPCODEDIR excepted on some platforms).

> I suggest that files be located as follows:
> 
> 1) Try using the absolute path.
> 2) Try using the environment variables.
> 3) Try using hard-coded paths (this is what would work if no environment
> variables were used). It is a question whether these paths should be relative
> to (a) the root directory, (b) the Csound bin directory, or (c) the current
> working directory.
> 4) Try the current working directory itself.

Csound already has a similar and quite flexible system like this.  If you
look over the code in envvar.c, you will see that the functions
csoundFindInputFile() and csoundFindOutputFile() already take care of most
or all of this.  These functions are called by the csound->FileOpen2()
function pointer.

The problem is that some opcodes are not using the already existing
mechanism of csound->FileOpen2() to open their files.  They are using
fopen() directly and are not utilizing the flexibility of
csound->FileOpen2() and thus are not behaving in a consistent manner with
the rest of Csound.

I am actually trying to introduce more consistency to the way that opcodes
open files while simultaneously solving a problem that affects host
applications.  (So perhaps there are really two separate issues here).

Anthony
 


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:
..
> 
> I hope that I am not being misunderstood.  I am not proposing adding a new
> environment variable that would need to be set by users.  The proposal for
> HOSTOUTDIR is for a path variable set via the API that would allow the host
> application to specify an output directory for files that do not already
> have a "default location".  HOSTOUTDIR would _not_ be read from the current
> shell environment.
> 

I think it is important that Csound itsel deasl as little as posisble 
with external environment issues. This is more properly the domain of 
the host application. On Windows, the idiomatic place to store path and 
other environment-related information is in the Registry; on the Mac it 
would be in a  Preferences file and/or in "Application Support" etc. The 
Csound engine itself needs to be as system-agnostic as possible, with 
the host supplying search paths to the engine via the API, which should 
employ a minimum set of defaults. In this regard, even a command-line 
wrapper is a host; so that it would query enviornment variables, the 
Registry, the Perferences file, or whatever, and the Csound engine 
itself would not search for these things at all. This way, a host can, 
if it so wishes, supply distinct environments to multiple instances of 
Csound.

Richard Dobson




-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Richard Dobson wrote on 5/16/07 12:13 PM:

> I think it is important that Csound itsel deasl as little as posisble
> with external environment issues. This is more properly the domain of
> the host application. On Windows, the idiomatic place to store path and
> other environment-related information is in the Registry; on the Mac it
> would be in a  Preferences file and/or in "Application Support" etc. The
> Csound engine itself needs to be as system-agnostic as possible, with
> the host supplying search paths to the engine via the API, which should
> employ a minimum set of defaults. In this regard, even a command-line
> wrapper is a host; so that it would query enviornment variables, the
> Registry, the Perferences file, or whatever, and the Csound engine
> itself would not search for these things at all. This way, a host can,
> if it so wishes, supply distinct environments to multiple instances of
> Csound.

Yes, I agree completely with this logic.  One of things that I am trying to
do is give the host more control over these issues.  I believe that the
current system is not too bad in these regards.

Currently, Csound's "environment variables" are internal strings **.  These
may be set or appended to by a host or from the commandline with the flag
--env (see csoundParseEnv() envvar.c).  I believe that Istvan implemented
this system (at my request) so that platforms without real environment
variables could continue to work correctly.  There are internal functions
csoundSetEnv(), csoundAppendEnv(), and csoundPrependEnv() for modifying
these internal variables.  And csoundInitEnv() is called during
csoundPreCompile() to read the variables from the operating system on
systems where they exist.

This last bit is one of the only parts that is not consistent with Richard's
viewpoint but it could be made so by moving the querying of the system
environment to the commandline host.  The other part that IMHO is not
consistent is the use of the system "current directory" concept.  I propose
a possible solution to this latter issue below.

I had believed that csoundSetEnv() and csoundAppendEnv() were public API
functions but they are not.  Perhaps they should be so that hosts do not
have to use the --env flag.  (There is a public function
csoundSetGlobalEnv() but that does not work on a per-instance basis, so I am
not sure why it is there).

Of course, the reason that I have brought all of this up is because some
parts of Csound ignore the system in envvar.c entirely and just read or
write to the current directory.  Since a host application cannot control
this on a per-instance basis, this is "bad".

So, at a minimum, I think that the opcodes and other parts of Csound that
call fopen() directly need to be cleaned up to use csound->FileOpen2()
instead.  In doing so, it is possible to specify a search path for these
changed opcodes or to specify an empty path.  I think that these opcodes
should be assigned search paths consistent with similar opcodes (or with
their purposes if different).

I was also suggesting that some opcodes (like the dumpk family) that already
use csound->FileOpen2() with an empty search path might be modified to have
a non-empty search path consistent with other similar opcodes.

If others think that adding or modifying search paths for existing opcodes
is a problem -- or that we need a better solution for when SFDIR, etc. are
undefined -- then I can suggest another more comprehensive solution to the
issue of files ending up in the "current directory" when that is
inappropriate for a host application:

A new API function (or functions) could be added for setting a per-instance
"working directory" (or an "input directory" and an "output directory"?).
csoundFindInputFile() and csoundFindOutputFile() would be modified so that
when this internal variable is set, ALL file operations that would affect
the current directory will use the specified directory instead.  If the
variable is not set, Csound would function as it does now.
csound->FileOpen2() would still have to be used in place of fopen() in the
places that I have previously described.

Thanks for this very productive discussion :)

Anthony

** A truly platform-agnostic system would not use pathnames stored as
strings, but a platform-defined datatype for locating files.  MacOS 9 does
not work 100% reliably when using pathnames.


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Wed, 2007-16-05 at 10:37 -0400, Michael Gogins wrote:
> I agree with John. This needs more discussion.
> 
> In my experience, the #1 question for Windows users of Csound is, "How do I set an environment variable?" This is something most Windows users never need to do.
> 

+1 on the above comment. I vividly remember getting frustrated with that
when I first started playing with csound many years ago. Defaults would
be good with environment variables available for "power users". 

Iain



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net