#212 Win32 bug: LISTEN eats the first character
The bug is seen in Windows port only, it does not exist
under Linux and Solaris. The very first character is
skipped as reading files. It is seen with redirection as
you issue the command
clisp.bat < file.lisp
and as reading the files (example is attached). The
Windows port was taken from sourceforge.net (clisp-
2.33-win32.zip).
Example files are:
cl_test.lisp start it (clisp.bat cl_test.lisp)
and see results
bmdating1.lisp contains blank space as its first character
and is read OK
bmdating2.lisp does not contain blank space and fails
under Windows because the first '(' is
skipped
windows.txt results under Windows ME (bad)
solaris.txt results under Solaris 9 (OK)
There is also a suspicion that the Windows port does not
provide access to environment variables when reading
files but I has no explicit examples.
lisp files and test results under Windows and Solaris
Logged In: YES
user_id=5735
the cause appears to be in LISTEN...
PS. _very_ unusual programming style :-)
Logged In: YES
user_id=5735
this happens on both native win32 (mingw) and cygwin.
test case:
(let ((f "foo") (s "12345") l)
(with-open-file (o f :direction :output) (write-string s o))
(with-open-file (i f) (listen i) (push (read-char i) l))
(delete-file f)
l)
should be: (#\1)
win32: (#\2)
this is because read(2) in read_helper(no_hang=true) skips
the first character and puts "2345" into the buffarea.
Logged In: YES
user_id=47998
>> PS. _very_ unusual programming style :-)
Yes. The example is a fragment from bergman computer
algebra package (http://www.math.su.se/bergman). bergman
was written and is developing in PSL (commercial "Portable
Standard Lisp"), and afterwards was ported to CLISP to get a
free port. bergman itself is free with source.
We wrote a wrapper that redefines a set of CLISP functions
in PSL manner (e.g., NTH has reverse order of arguments,
comment is introduced by % instead of ;, etc.), and compile
PSL sources under CLISP.
The main argument to use PSL is that bergman makes huge
calculations and is strictly optimized by use of INUMs (short
integers) in appropriate places. Regrettably most of CLISP
implementations, esp. the Windows port, do not differentiate
integer types. As the result, calculations in PSL version of
bergmans are in 3-4 times faster than in CLISP version.
Logged In: YES
user_id=5735
the workaround is not to use LISTEN on file streams
(you _really_ don't need to!)
Logged In: YES
user_id=47998
>> the workaround is not to use LISTEN on file streams
>> (you _really_ don't need to!)
I really need! 'clisp.bat file.lisp' and 'clisp.bat < file.lisp' show
totally different output, and we use the effect widely. Now
the last one eats the first character. We were to add a line of
at least two comment signs (;; or %%) in the beginning of
each file.
Logged In: YES
user_id=5735
the bug is with both buffered and unbuffered streams:
(let ((f "foo") (s "12345") l)
(with-open-file (o f :direction :output) (write-string s o))
(with-open-file (i f :buffered t) (listen i) (push
(read-char i) l))
(with-open-file (i f :buffered nil) (listen i) (push
(read-char i) l))
(delete-file f)
l)
should be: (#\1 #\1)
win32: (#\2 #\2)
Logged In: YES
user_id=5735
please show the code that needs LISTEN on file streams.
Logged In: YES
user_id=5735
thank you for your bug report.
the bug has been fixed in the CVS tree.
you can either wait for the next release (recommended)
or check out the current CVS tree (see http://clisp.cons.org\)
and build CLISP from the sources (be advised that between
releases the CVS tree is very unstable and may not even build
on your platform).