Subject: [clisp-list] environment dependencies

From: "Hoehle, Joerg-Cyril" <[email-masked]>
Date: Wed Jan 8 04:14:13 2003

Don,

I understand your concern about being reliably able to start a program in a possibly different environment and still have it work as expected.

However I think the solution can only come from
- knowing which dependencies on the environment exist.

IMHO, this ought to be achieved by solely reading the documentation. It should not be achieved by tracing at run-time.
Remember: a trace is a *single* test - One shot. As opposed to static information, like documentation, which instead covers all possible runs, all imaginable traces.

clisp.html already mentions all internal getenv usage. Is something missing?

Some environment dependencies are more complex than getenv() can tell:
o E.g. is stdin/fd0 a (pseudo-)tty or a file? -> *standard-input* is bound to different stream types with different properties.
o Same for stdout/2
o Is CLISP started as a script (the #! and *args* features) or not?
- Some people have reported in clisp-list having been hit by this.

>- There should be a global variable containing a list of [...]
> environment variables used by the distributed code.
This could be achieved using a wrapper around getenv().
But it looks like one should run trace/truss/ltrace instead of implementing this in Lisp. With the ability to restart from images, it becomes a complex dependency maintenance project ("was this value used for values not in the current image?").

>- The distributed code should record in another global variable
>the set of values it has read (and is now using) for environment
>variables.
Considering restarting from images, I believe getenv() should not show functional behaviour. It ought to return the current value.

>- The distributed code should use that variable as a cache and avoid
>reading the same variable from the environment twice.
This is specifically against the idea behind -E information not being looked up in e.g. the image file: the current environment may be different from the one where the image was saved. Bruno Haible thought CLISP should always adapt to the current environment. Similarly, the exact nature of (the value of) *terminal-io* is derived from current environment (pseudo-tty or file).

>- There should be a setf method for CHANGING the value being used
>(or setting a value not yet used).
This may not be achievable in general. Sometimes a setting cannot be changed at arbitrary times (NLS directories come to mind) and you need special code to add this feature. When is it worth it?
E.g. some time ago, -L was a startup option. Now the language can be changed at run-time. Valuable or superfluous? People's and YMMV.

BTW, faq.html says:
"This means that you are trying to read a non-ASCII character from a stream which has ASCII STREAM-EXTERNAL-FORMAT. The default is described in The Fine Manual."
Maybe it could say:
... or that the interactive read eval print loop (REPL) is trying to print this character as the result of the evaluation to your terminal and finds that *standard-output* has this ASCII STREAM-EXTERNAL-FORMAT. See the Fine Manual [specific URL to -E section]."

Just my thoughts,
	Jorg Hohle.

---

From: Sam Steingold <[email-masked]>
Date: Wed Jan 8 07:11:03 2003

> * In message <[email-masked]>
> * On the subject of "[clisp-list] environment dependencies"
> * Sent on Wed, 8 Jan 2003 13:13:08 +0100
> * Honorable "Hoehle, Joerg-Cyril" <[email-masked]> writes:
>
> BTW, faq.html says:
> "This means that you are trying to read a non-ASCII character from a
> stream which has ASCII STREAM-EXTERNAL-FORMAT. The default is
> described in The Fine Manual."
> Maybe it could say:
> ... or that the interactive read eval print loop (REPL) is trying to
> print this character as the result of the evaluation to your terminal
> and finds that *standard-output* has this ASCII
> STREAM-EXTERNAL-FORMAT. See the Fine Manual [specific URL to -E
> section]."

it does point to that specific section.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Those who don't know lisp are destined to reinvent it, poorly.