Subject: [clisp-list] Re: environment dependencies

From: [email-masked] (Don Cohen)
Date: Wed Jan 8 12:58:03 2003

(as usual, answering multiple messages at once)

Hoehle, Joerg-Cyril:

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

I did eventually run across this.  Thanks.

 > IMHO, this ought to be achieved by solely reading the documentation

If this is unlikely to change then I suppose that's not bad.
I was suggesting something in the image so you could write a program 
that would capture the relevant environment.  You'd run that as part
of your build process.  Building in different lisp versions might 
give different environment variables.

   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. 

I agree.  I was not proposing that this info be determined by tracing.
I was more interested in a code analysis approach, for instance if
someone happens to know that clisp accesses environment only via
one particular function call.

 > 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.
Very good points.
I'd like to see all these collected into one place.
That place should also say what the values are in those cases,
and perhaps how to test which case you're in.

  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?").  

This raises another point.  I'd really like to know which environment
retains its effect across saves and which is reread at restart.

 > Considering restarting from images, I believe getenv() should not
   show functional behaviour. It ought to return the current value. 

Surely some of this is cached anyhow.  You don't look up LANG on every
write-char.  Maybe not on every open.  If the env is going to change
while you're running it would be worth while to know when it's reread.

I agree that you do have to reset some stuff at restart.  I'd like
to know what it is and what's read after that (and when).

 > 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." 

Actually I searched for "character" in impnotes and did not find
anything relevant.  I see that the relevant faq entry does contain the
word character, but it still doesn't answer my question.  The answer,
which I propose to add to FAQ is that ascii is used when LANG is unset.
I also suggest quoting this error message in addition to "invalid byte"
Character #\u00B3 cannot be represented in the character set CHARSET:ASCII

Sam Steingold:
 > > - There should be a global variable containing a list of strings,
 > > which are the names of environment variables used by the distributed
 > > code.
 > 
 > what is distributed code?
What I had in mind was that the modules go into the build should
know what environment they use and when the build finishes you should 
end up with an image that puts these all into a list.

 > Just pass -E utf-8 and all those encodings will use unicode.
 > the other environment variables should not matter for batch processing.
 > 
 > alternatively, you can set the -encoding* places in ~/.clisprc
 > alternatively, you can make the init function of your image set them

Ah, the answers!  Even better than setting env.
Put that in FAQ too.
(now rushing off to try them ...)

---

From: Sam Steingold <[email-masked]>
Date: Wed Jan 8 14:42:02 2003

> * In message <[email-masked]>
> * On the subject of "[clisp-list] Re: environment dependencies"
> * Sent on Wed, 8 Jan 2003 12:59:34 -0800
> * Honorable [email-masked] (Don Cohen) writes:
>
> I'd really like to know which environment retains its effect across
> saves

none.

> Surely some of this is cached anyhow.

environment is used to initialize some places, like -encoding*.

> Ah, the answers!  Even better than setting env.

FAQ already contains this information in the form of references to the
relevant parts of the manual and the impnotes.

-- 
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>
Takeoffs are optional.  Landings are mandatory.

---

From: Sam Steingold <[email-masked]>
Date: Wed Jan 8 20:37:01 2003

> * In message <[email-masked]>
> * On the subject of "clisp -E "
> * Sent on Wed, 8 Jan 2003 16:50:13 -0800
> Looks like the help msg knows about -E but the command line parser
> doesn't.  Is this something that was not working 18 months ago?

this feature (-E encoding) was introduced on 2002-03-18.
-Edomain encoding has been there longer.
(domain = file, terminal &c)

-- 
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>
When you talk to God, it's prayer; when He talks to you, it's schizophrenia.