Feature Requests item #731952, was opened at 2003-05-03 16:56
Message generated for change (Comment added) made by sds
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=731952&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sam Steingold (sds)
Assigned to: Bruno Haible (haible)
Summary: faithful character i/o
Initial Comment:
CLISP READ-CHAR reads bytes 10 and 13 as #\Newline:
&lt;http://article.gmane.org/gmane.lisp.clisp.general/6970&gt;
&lt;http://article.gmane.org/gmane.lisp.clisp.general/4718&gt;
Is it possible to read them differently?
----------------------------------------------------------------------
>Comment By: Sam Steingold (sds)
Date: 2006-11-17 13:50
Message:
Logged In: YES
user_id=5735
Originator: YES
actually, using #\Code128==#\U0080 seems to be a good option!
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-17 13:47
Message:
Logged In: YES
user_id=5735
Originator: YES
Suppose we add :line-terminator-strict slot to encodings, making the
newline input "faithful":
:UNIX :MAC :DOS
CR #\Return #\Newline #\Return
LF #\Newline #\Linefeed #\Linefeed
CRLF #\Return#\Newline #\Newline#\Linefeed #\Newline
(row: input characters; column: line terminator of the encoding).
alas, in CLISP #\Linefeed == #\Newline (as explicitly permitted &c), so
the reality is thus:
:UNIX :MAC :DOS
CR #\Return #\Newline #\Return
LF #\Newline #\Newline #\Newline
CRLF #\Return#\Newline #\Newline#\Newline #\Newline
which plain sucks for everything but the :UNIX line terminator.
How about using something other than 10 for Newline?
How about 0? (i.e., #\Null = #\Newline)
0 does not normally occur in _text_ streams, so it will not cause the
confusion we are experiencing.
just about any control character (except bs/tab/nl/ret) would do too.
http://en.wikipedia.org/wiki/ASCII
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-10-16 10:17
Message:
Logged In: YES
user_id=5735
looks like this is more than just a user issue
https://sourceforge.net/tracker/index.php?func=detail&aid=1578179&group_id=1355&atid=101355
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2004-05-25 10:53
Message:
Logged In: YES
user_id=5735
this item is now closed as invalid.
thanks to Bruno for clarifying it.
see <impnotes.html#clhs-newline>
for the exhaustive treatement of the matter.
----------------------------------------------------------------------
Comment By: Bruno Haible (haible)
Date: 2004-03-18 06:55
Message:
Logged In: YES
user_id=5923
No. Accepting CR, LF and CRLF as different variations of
#\Newline implements the recommendations of the Unicode
consortium in
http://www.unicode.org/reports/tr13/tr13-9.html. Quote:
"Even if you know which characters represents NLF on your
particular platform, on input and in interpretation, treat
CR, LF, CRLF ...L the same. Only on output do you need to
distinguish between them."
It also reflects user wishes: 1) For years, GCC used to give
parse errors on some C input files that used CRLF as line
terminators, whereas with just LF the parse succeeded. 2)
GNU gettext had similar problems, and it was reported as a
bug, because apparently users on Unix sometimes have Windows
written files on their disks.
The way CLISP does it, a priori prevents this kind of bug
from the beginning.
There is no need to add complexities to CLISP to implement
the paradigms of the 1980ies, that are just not valid any
more in today's world.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=731952&group_id=1355

Feature Requests item #731952, was opened at 2003-05-03 16:56
Message generated for change (Comment added) made by sds
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=731952&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sam Steingold (sds)
Assigned to: Bruno Haible (haible)
Summary: faithful character i/o
Initial Comment:
CLISP READ-CHAR reads bytes 10 and 13 as #\Newline:
&lt;http://article.gmane.org/gmane.lisp.clisp.general/6970&gt;
&lt;http://article.gmane.org/gmane.lisp.clisp.general/4718&gt;
Is it possible to read them differently?
----------------------------------------------------------------------
>Comment By: Sam Steingold (sds)
Date: 2006-11-17 13:47
Message:
Logged In: YES
user_id=5735
Originator: YES
Suppose we add :line-terminator-strict slot to encodings, making the
newline input "faithful":
:UNIX :MAC :DOS
CR #\Return #\Newline #\Return
LF #\Newline #\Linefeed #\Linefeed
CRLF #\Return#\Newline #\Newline#\Linefeed #\Newline
(row: input characters; column: line terminator of the encoding).
alas, in CLISP #\Linefeed == #\Newline (as explicitly permitted &c), so
the reality is thus:
:UNIX :MAC :DOS
CR #\Return #\Newline #\Return
LF #\Newline #\Newline #\Newline
CRLF #\Return#\Newline #\Newline#\Newline #\Newline
which plain sucks for everything but the :UNIX line terminator.
How about using something other than 10 for Newline?
How about 0? (i.e., #\Null = #\Newline)
0 does not normally occur in _text_ streams, so it will not cause the
confusion we are experiencing.
just about any control character (except bs/tab/nl/ret) would do too.
http://en.wikipedia.org/wiki/ASCII
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-10-16 10:17
Message:
Logged In: YES
user_id=5735
looks like this is more than just a user issue
https://sourceforge.net/tracker/index.php?func=detail&aid=1578179&group_id=1355&atid=101355
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2004-05-25 10:53
Message:
Logged In: YES
user_id=5735
this item is now closed as invalid.
thanks to Bruno for clarifying it.
see <impnotes.html#clhs-newline>
for the exhaustive treatement of the matter.
----------------------------------------------------------------------
Comment By: Bruno Haible (haible)
Date: 2004-03-18 06:55
Message:
Logged In: YES
user_id=5923
No. Accepting CR, LF and CRLF as different variations of
#\Newline implements the recommendations of the Unicode
consortium in
http://www.unicode.org/reports/tr13/tr13-9.html. Quote:
"Even if you know which characters represents NLF on your
particular platform, on input and in interpretation, treat
CR, LF, CRLF ...L the same. Only on output do you need to
distinguish between them."
It also reflects user wishes: 1) For years, GCC used to give
parse errors on some C input files that used CRLF as line
terminators, whereas with just LF the parse succeeded. 2)
GNU gettext had similar problems, and it was reported as a
bug, because apparently users on Unix sometimes have Windows
written files on their disks.
The way CLISP does it, a priori prevents this kind of bug
from the beginning.
There is no need to add complexities to CLISP to implement
the paradigms of the 1980ies, that are just not valid any
more in today's world.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=731952&group_id=1355

Bugs item #1595306, was opened at 2006-11-13 00:24
Message generated for change (Comment added) made by hoehle
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1595306&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: build problems
Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Matthew Kennedy (matthewbk)
Assigned to: Sam Steingold (sds)
Summary: fastcgi build error
Initial Comment:
gmake[1]: Entering directory `/tmp/clisp-2.41/src/fastcgi'
gcc -g -O2 -W -Wswitch -Wcomment -Wpointer-arith
-Wimplicit -Wreturn-type -Wmissing-declarations
-Wno-sign-compare -O2 -fexpensive-optimizations
-falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. .. -I..
-c fastcgi.c
In file included from fastcgi.c:1:
../clisp.h:682: warning: register used for two global
register variables
fastcgi.c: In function 'module__fastcgi__init_function_2':
fastcgi.c:27: error: 'fcgi_getenv' undeclared (first
use in this function)
fastcgi.c:27: error: (Each undeclared identifier is
reported only once
fastcgi.c:27: error: for each function it appears in.)
fastcgi.c:28: error: 'fcgi_env' undeclared (first use
in this function)
fastcgi.c:29: error: 'fcgi_read_stdin' undeclared
(first use in this function)
fastcgi.c:30: error: 'fcgi_write_stdout' undeclared
(first use in this function)
fastcgi.c:31: error: 'fcgi_write_stderr' undeclared
(first use in this function)
fastcgi.c:32: error: 'fcgi_accept_wrapper' undeclared
(first use in this function)
fastcgi.c:33: error: 'fcgi_finish_wrapper' undeclared
(first use in this function)
fastcgi.c:34: error: 'fcgi_is_cgi_wrapper' undeclared
(first use in this function)
gmake[1]: *** [fastcgi.o] Error 1
----------------------------------------------------------------------
>Comment By: Jörg Höhle (hoehle)
Date: 2006-11-17 16:12
Message:
Logged In: YES
user_id=377168
Originator: NO
for 2.41, do as I sketched : Select the alternative
- either add the *output-c-functions* code like I did for file v1.10, or
- keep or rename the local fastcgi.h *and* if not renamed, make sure that
this one gets included, not a global one like in Debian
/usr/include/fastcgi.h and ensure fastcgi.lisp contains (c-lines "#include
"localfastcgi_wrappers.h") or whatever you name it.
Currently, my favourite name goes to fastcgi_wrappers.h, because there's
the .c file of same name.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-16 15:06
Message:
Logged In: YES
user_id=5735
Originator: NO
please download the source distribution from SF and not from gnu.org.
gnu.org does not allow me to replace the broken distribution.
----------------------------------------------------------------------
Comment By: Matthew Kennedy (matthewbk)
Date: 2006-11-16 07:07
Message:
Logged In: YES
user_id=171319
Originator: YES
I built it successfully from CVS, with ./configure --prefix=/tmp/build
--with-module=fastcgi. The full build log can be found here
http://dev.gentoo.org/~mkennedy/clisp-cvs-build.log
Could you please comment on what the solution might be for patching our
clisp-2.41 in Gentoo to work? I diffed clisp/modules/fastcgi from cvs
with clisp-2.41's and there seem to be quite a few other changes.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-15 15:18
Message:
Logged In: YES
user_id=5735
Originator: NO
please confirm that the problem is gone in the CVS head or clisp as
downloaded from SF.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-15 15:18
Message:
Logged In: YES
user_id=5735
Originator: NO
this is the standard request for more information.
1. what is your platform?
("uname -a" on a Unix system)
compiler version? libc (on Linux)?
2. where did you get the sources? when?
(absolute dates are prefered over the relative ones)
3. how did you build CLISP? (what command, options &c)
please do a clean build (remove your build directory and
build CLISP with "./configure --build build" or at least
do a "make distclean" before "make")
4. if you are using pre-built binaries, the problem is likely
to be in the incompatibilities between the platform on which
the binary was built and yours;
please try compiling the sources.
5. what is the output of (lisp-implementation-version)?
6. what is the value of *features*?
7. please supply the full output (copy and paste)
of all the error messages.
If you cannot build CLISP, you can obviously skip 5 and 6,
but then you should provide more information in 1.
please see <http://clisp.cons.org/clisp.html#bugs&gt;
for more information.
Thanks.
PS. This bug report is now marked "pending"
and will auto-close unless you respond
(in which case it will auto-re-open).
----------------------------------------------------------------------
Comment By: Jörg Höhle (hoehle)
Date: 2006-11-15 13:56
Message:
Logged In: YES
user_id=377168
Originator: NO
>why didn't you just remove the fastcgi.h
I didn't see it, or when I saw it in #include "fastcgi.h" I confused it
with the official/public include file for fastcgi (which also explains my
comment: "completely wrapped" -- only the official API functions are
completely wrapped). Therefore, my previous explanation was wrong: the
local fastcgi.h indeed helps with prototypes for e.g. fcgi_read_stdin.
Anyway, the current build does not use it anymore, declaring prototypes
itself via (setq ffi:*output-c-functions* t).
One may argue that this is not the examples in the impnotes which advises
to include a .h for all referenced functions. Only the .h can protect from
mismatches from subsequent changes in the declarations.
So a better fix might be:
- reinstall it, (maybe under different name, e.g. fcgiwrapper.h, never to
be confused with the public include)
- (c-lines "#include it")
- remove setq *output-c-functions*
E.g. the same state as before.
So the cause of the bug is as follows: The OP must have tried to build
clisp-2.41 from sources. fastcgi.lisp v1.9 is in 2.41 but does not have
the #include anymore, add I only added 6 days later to v1.10 the
*output-c-functions* patch.
http://clisp.cvs.sourceforge.net/clisp/clisp/modules/fastcgi/fastcgi.lisp?hideattic=0&sortby=date&view=log
My apologies for the mess caused by my confusion & actions.
Alternatives exist:
- leave it as fastcgi.h. No, that's really a bad name. On Debian I have
/usr/include/fastcgi.h. No wonder I got confused. Who's gonna guarantee
what file gets included when?
- perhaps include in it the original fastcgi includes, then one can
- use direct calls to e.g. FCGX_IsCGI() and wrappers to others e.g.
write-stdout.
See my comments at bottom of fastcgi_wrappers.c on some pros and cons of
wrappers vs. direct calls
http://clisp.cvs.sourceforge.net/clisp/clisp/modules/fastcgi/fastcgi_wrappers.c?hideattic=0&r1=1.3&r2=1.4&sortby=date
The pro argument can be considered futile given all that direct
interfacing to e.g. dynamic shared libraries.
I have removed the original comment there, namely "These [wrappers for
e.g. FCGX_IsCGI] are needed only due to the use of upper case (how
annoying)" because it did not consider the (:NAME) option to DEF-CALL-OUT.
There's no problem in interfacing to mixed case.
[Off topic] All that talk still doesn't solve the problem that
fastcgi:slurp-stdin is IMHO misdesigned. It lacks the ability to read
binary data (e.g. attachments). Any API designer volunteers?
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-13 19:42
Message:
Logged In: YES
user_id=5735
I confirm that the cvs head (unpatched) generated fastcgi.c
includes all the necessary declarations.
could this be a dupe of the problem resolved in this message?
http://article.gmane.org/gmane.lisp.clisp.general/11634/
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-13 18:03
Message:
Logged In: YES
user_id=5735
why didn't you just remove the fastcgi.h file from the
source tree?
----------------------------------------------------------------------
Comment By: Jörg Höhle (hoehle)
Date: 2006-11-13 17:50
Message:
Logged In: YES
user_id=377168
I'm sorry. A patch about "fastcgi.h" inclusion *cannot*
remove any problem associated with fcgi_read_stdin etc. for
the very simple reason that these functions do not come from
the public fastcgi API. They come from our fastcgi_wrappers.c.
I removed the inclusion of fastcgi.h last month because the
FFI module has not a single DEF-CALL-OUT to a function from
the official fastcgi.h. It solely calls our wrappers.
If fastcgi.c (which results from compilation of
fastcgi.lisp) complains, it means that it does not see the
declarations for fcgi_read_stdin etc. This should not
happen because I wrote:
(eval-when (compile)
;;NB this global affects further compilations in this session
(setq ffi:*output-c-functions* t))
which should cause declarations to be output during
compilation of fastcgi.lisp into fastcgi.c.
If this does not happen, then that's what needs to be
investigated.
In my Linux environment, this caused the following
declarations to appear in fastcgi.c:
...
object module__fastcgi__object_tab[1];
object_initdata_t module__fastcgi__object_tab_initdata[1];
uintC module__fastcgi__object_tab_size = 0;
extern char* (fcgi_getenv)();
extern char* * (fcgi_env)();
extern char* (fcgi_read_stdin)();
extern int (fcgi_write_stdout)();
extern int (fcgi_write_stderr)();
extern int (fcgi_accept_wrapper)();
extern void (fcgi_finish_wrapper)();
extern int (fcgi_is_cgi_wrapper)();
void module__fastcgi__init_function_1 (module_t* module);
...
Maybe the build process in cygwin is different?
I wrote (eval-when (compile) #) because only during
compilation will CLISP create the file fastcgi.c.
In any case, "fastcgi.h" is not the answer to a problem
involving fcgi_read_stdin.
Please investigate further the origin of the gcc error.
What's going on with fastcgi.h?
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-13 17:11
Message:
Logged In: YES
user_id=5735
Reini, the patch _uncomments_ (i.e., enables) the header
inclusion, _not_ comments it out (i.e., disables).
----------------------------------------------------------------------
Comment By: Reini Urban (rurban)
Date: 2006-11-13 17:02
Message:
Logged In: YES
user_id=13755
BTW: I've needed to comment out the header inclusion for
cygwin also.
Just forgot to email it after my holidays.
----------------------------------------------------------------------
Comment By: Matthew Kennedy (matthewbk)
Date: 2006-11-13 06:35
Message:
Logged In: YES
user_id=171319
Yes, that fixes the problem. Thanks!
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-13 03:47
Message:
Logged In: YES
user_id=5735
does this patch fix the problem?
--- fastcgi.lisp 19 Oct 2006 04:11:32 -0400 1.10
+++ fastcgi.lisp 12 Nov 2006 21:46:36 -0500
@@ -145,7 +145,7 @@
; -------------- "C" functions
-;(c-lines "#include \"fastcgi.h\"~%"); completely wrapped
+(c-lines "#include \"fastcgi.h\"~%")
(eval-when (compile)
;;NB this global affects further compilations in this session
(setq ffi:*output-c-functions* t))
----------------------------------------------------------------------
Comment By: Matthew Kennedy (matthewbk)
Date: 2006-11-13 00:26
Message:
Logged In: YES
user_id=171319
Add
#include "fastcgi.h"
To top of fastcgi.c
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1595306&group_id=1355

Bugs item #1483768, was opened at 2006-05-08 08:12
Message generated for change (Comment added) made by sds
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1483768&group_id=1355
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clisp
Group: ANSI compliance issue
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jörg Höhle (hoehle)
>Assigned to: Sam Steingold (sds)
Summary: automatic pretty-printing of symbols in conses
Initial Comment:
[Report by Tobias C. Rittweiler [tcr@...]:]
According to the CLHS, if no suitable entry for some
object is found in the current PPRINT-DISPATCH table
(assuming pretty-printing enabled), the internal
printer (i.e. some PRINT-OBJECT method) is supposed to
be invoked in an environment where *PRINT-PRETTY* is
_still_ bound to T. (See last paragraph in 22.2.1.4
[1])
Joerg Hoehle pointed out that Clisp seems to implement
CLtL2 behaviour which means that "if there is no
specification for how to pretty print a particular
kind of object, it is then printed using the standard
mechanisms as if *print-pretty* were nil." ([2])
Rationale why this change from NIL to T happened
between CLtL2 and standardization, can be found within
the UNIFY issue. [3]
This change comes apparent when one's trying to pretty-
print an aggregated data type, as for instance a LIST:
(flet ((my-symbol-pprint (stream obj)
(let ((*print-pretty* nil))
(princ "++" stream) (princ obj stream)
(princ "++" stream))))
(let ((*print-pprint-dispatch* (copy-pprint-
dispatch)))
(set-pprint-dispatch 'symbol #'my-symbol-pprint)
(princ-to-string (macroexpand '(loop for i
in '(1 2 3) collect i)))))
This should prepend and append a "++" to every symbol
within the macroexpansion, because -- while the value
returned from MACROEXPAND isn't actually of type
SYMBOL (that a pprint-dispatch entry was added for) --
the respective PRINT-OBJECT method should be invoked
with *PRINT-PRETTY* bound to T. As a result and as a
consequence of the default list printing algorithm (as
outlined in 22.1.3.5 [4]), the function #'MY-SYMBOL-
PPRINT should be invoked for every symbol _within_ the
list returned as macroexpansion.
That this behaviour is desired by the standard, can
also be seen in one of the examples of the
section "22.2.2 Examples of using the Pretty Printer"
[5] in the hyperspec:
(setq *print-pprint-dispatch* (copy-pprint-dispatch
nil))
(set-pprint-dispatch 'ratio
#'(lambda (s obj)
(format s "#.(/ ~W ~W)"
(numerator obj) (denominator obj))))
[...]
(pprint '(1/3 -2/3)) ==> (#.(/ 1 3) #.(- (/ 2 3)))
There has been a short discussion about the subject on
the clisp.general mailinglist. [6]
[1] http://www.lisp.org/HyperSpec/Body/sec_22-2-1-
4.html
[2] http://www.supelec.fr/docs/cltl/clm/node259.html
[3] http://www.lisp.org/HyperSpec/Issues/iss180-
writeup.html
[4] http://www.lisp.org/HyperSpec/Body/sec_22-1-3-
5.html
[5] http://www.lisp.org/HyperSpec/Body/sec_22-2-2.html
[6]
http://article.gmane.org/gmane.lisp.clisp.general/11050
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-17 00:29
Message:
Logged In: YES
user_id=5735
Originator: NO
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).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1483768&group_id=1355

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details