Custom Query (1030 matches)

in the working-0711 branch, the compiler traps certain kinds of compile-time PROGRAM-ERRORs (at least), WARNs about them, and produces a function that, when executed, complains about whatever errors were detected at compile-time.

? (defun bogus (x y) (eq x) y) ; misplaced paren
;Compiler warnings :
;   In BOGUS: Required arguments in (EQ X) don't match lambda list (FORM1 FORM2).
BOGUS

Unfortunately, the function that's created in this case takes 0 arguments; unless it's called with 0 arguments, one won't see the compile-time error reported.

When this happens when something is defined interactively, any previous (more) correct version of the function is quietly replaced with the 0-arg error-signaling version. Under the old behavior (where an error was signaled at compile-time), the old (presumably working) definition would have remained in place. With the new behavior, it may be necessary to reload code (if possible) and repeat a number of development steps to get back to the point where one has the opportunity to correct a simple syntax error. (I noticed this while working on the compiler, and find this aspect of the new behavior to be a big impediment to productivity.)

If this happens during COMPILE-FILE, I assume that the same sort of unfortunate side-effects occur (unless one is lucky enough to press ^{C before the binary is loaded.)}

I think that I understand some of the motivations for this change and hope that we can think of ways of satisfying the needs of all concerned parties.

 (run-program ''prog'' args :output ''lisp-stream'' :error ''lisp-stream'')

doesn't work as expected. CCL::MONITOR-EXTERNAL-PROCESS only has the ability to watch output on a single file descriptor, and in this case it winds up watching the input side of a pipe used as the error descriptor by the external program, and output is lost.

Example:

(defun foo ()
  (with-output-to-string (out)
    (with-output-to-string (err)
      (run-program "ls" '("-l") :output out :error err)
      (format t "~& out = ~a" (get-output-stream-string out))
      (format t "~& err = ~a" (get-output-stream-string err))))
  nil)

Calling (FOO) produces the output:

out =
err =

which basically means "there was no error output, and we weren't watching standard output"

Even though this is apparently a litte obscure (I don't recall it ever having been reported), it's probably fair to call it 'major'.

Using :ERROR :OUTPUT provides a way of getting both standard and error output, but not a way of distinguishing between them.

Many standard programs (many GNU tools, including GCC) produce output in UTF-8 or some other non-empty encoding. CCL::MONITOR-EXTERNAL-PROCESS just interprets each octet it receives as a character-code; ideally, there should be some way of specifying how those octets encode characters.

Non-interactive input to external processes sometimes involves writing a lisp stream's contents to a temporary file and passing a descriptor to that file as the subprocess' standard input; similarly, there should be some way of ensuring that that input is encoded according to the external program's expectations.

How significant a problem this is may depend on how visible it is, which in turn depends on lots of factors ("locales", terminal/Emacs settings) outside of the lisp's control. It seems desirable that the lisp offer a way of doing (its part of) this right.