[Openmcl-devel] Hi from new user

[Gary Byers]

On Mon, 23 Feb 2009, Denis Bodyak wrote:

> Hi!
>
> I'm running ccl1.3 under win32. Some oddities are found.
>
> 1. unable to (rebuild-ccl :clean t). It seems to hang up at loading
> levelnfasload.wx32fsl. For now I've checked it on two hosts, will try
> one other host tomorrow. This may be caused by some viruses though.

Yeah, you just never know.

Actually, I think that that's a symptom of a pretty bad/stupid bug
in CCL:RUN-PROGRAM on Windows: if the program doesn't exist on the
shell's search path or can't be executed, RUN-PROGRAM waits (forever ...)
for it to finish.  (Er, um, it never started ...).  REBUILD-CCL
uses RUN-PROGRAM to run "svn" and "svnversion" so that it can
incorporate their output into LISP-IMPLEMENTATION-VERSION's result.

If that's the bug, then just doing:

? (run-program "svn" '("info") :output t)

will hang.

That bug's easy to fix, but it's hard to use an image that contains
that bug to build an image that doesn't (since the bug is triggered
by things that happen in the build process itself.)   Until we can
get new binaries built, the simplest workaround is to ensure that
"svn" and "svn" programs are on your path.


>
> So all subsequent is related to 1.3 release which I get from svn.
>
> 2. #p"md5.asd.lnk" -> #P"md5'.asd.lnk"
> Neither clisp nor lispworks do so, so I think it is a bug.

I think that the way that implementations parse physical-pathname
namestrings is implementation-dependent.

Peter Seibel's book offers a good discussion of some of these
differences.

>
> . Similar things happen under linux32:
> #p"md5.asd.lnk" -> #P"md5\.asd.lnk" or something like this.
>

Yes.  The printed representation of a pathname (and the result
of the function NAMESTRING) will escape/quote dots that are
constituents of the pathname's name or type components (as opposed
to a dot that separates these components.)  When a string is coerced
to a pathname, escaped dots are interpreted as constituents.

This solves some problems (removes ambiguity and possibly facilitates
round-tripping in some cases) and may introduce others (at the very
least, it quickly gets confusing when a namestring actually contains
the escape character.)  It's also different from what other
implementations do (and is a good example of "implementation-dependent"
behavior.)


>
> 3. When running on terminal,
> "a
> b"
>
> reads in as a string of
> #\a,#\Return,#\b

I believe that it reads as #\a,#\Return,#\Newline,#\b, which would
be exactly what the console sent (where #\Newline is also known as
#\Linefeed).  I can't reproduce a case where it drops the #\Linefeed
and can't really imagine why it would, so I assume that you're just
mistaken here.  (If that assumption's incorrect, please let me know.)

Since some Windows environments still use CRLF to terminate lines,
it's probably not unreasonable for the implementation to treat CRLF
as #\Newline on input.  Whether doing the same on output is "reasonably
following Windows conventions" or "annoyingly forcing other programs
to deal with this nonsense" is hard to know.

Dealing with CRLF on the input side of *TERMINAL-IO* in a command-line
environment is pretty simple, something like:

(when (typep *terminal-io* 'two-way-stream)
   (let* ((in (two-way-stream-input-stream *terminal-io*))
          (exf (stream-external-format in)))
     (setf (stream-external-format in)
           (make-external-format
             :character-encoding  (external-format-character-encoding exf)
             :line-termination :crlf))))

You can certainly do that in your init file, and there's little reason
not to do so (unless you really want to see CRLFs when they're present.)

I assume that you mean that the same issue (some - many - Windows
programs generate CRLF) gets in the way when trying to parse
RUN-PROGRAM's output (when it doesn't hang.)  Ideally, there'd be some
good way of saying something about how the process encodes output and
what line-termination conventions it expects.  Barring that, mapping
CRLF to #\Newline (or just dropping #\Returns, which isn't quite right
if there are isolated #\Returns ...) in process output on Windows
is probably reasonable behavior.

(I'm trying to force myself to actually use Windows without using
Cygwin.  There's only one thing that I can think of that's worse than
using Windows with Cygwin ... but yes, the lisp should deal with this
sort of thing better; it's likely too late to convince Microsoft that
CP/M interoperability isn't as important as it seemed to be in 1983.)

>
> not as string of
> #\a,#\Newline,#\b

>
> This causes problems when capturing
> output of win32 console programs.
>
> 4.
> (probe-file "d:/ccl/lib") -> ok
> (probe-file "d:/ccl\\lib") -> ok
> (probe-file "d:\\ccl\\lib") -> "d is not a defined logical host"

<http://trac.clozure.com/openmcl/wiki/WindowsNotes> probably should
be updated for the 1.3 release, but the paragraph that notes that:

"Windows pathnames can use either forward-slash or backward-slash
characters as directory separators. CCL translates backslashes to
forward slashes on namestrings returned by the OS and generally
doesn't interpret backslashes as directory separators in other
contexts."

is still accurate.  It's generally ambigous whether a namestring
like "d:foo" names a physical pathame (the file "foo" on device "d")
or a logical pathname ("foo" interpreted relative to the logical host "d".)
A namestring like "d:foo;bar.lisp" - that contains a logical directory
separator - or a namestring that contains a physical directory separator
like "d:/foo/bar.lisp" - is less ambiguous.  Since we don't yet recognizes
backslashes as directory separators, we guess wrong.



>
> I'd like to try fix it myself, but this looks
> impossible as I can't build.
>
> Thanks...
> Budden
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>