Bruno Haible writes:
> What are you actually programming?
> - If you are programming an HTTP or SMTP server, you can use a clisp stream
> with charset ASCII - it will convert the CRLF to #\Newline for you.
This is what I thought I was programming. Your prescription seems
incorrect to me, since this will also convert a plain CR or LF to a
newline.
> - If you are programming the client, you can create a clisp stream with
> charset ASCII and line-terminator :DOS - it will convert the #\Newline to
> CRLF for you.
> - If you are programming a protocol checker, that verifies that the CRLF
> is really CRLF and not LF, then you'll need to use binary I/O. Are you
> doing that??
I'm just trying to write a program that follows the spec.
If the spec says
Simple-Request = "GET" SP Request-URI CRLF
then I think I should look for CRLF, not CR, not LF.
You might view accepting plain CR or LF as being "liberal in
what you accept", but that sort of thing can also result in
failing to correctly interpret some other input that does meet
the spec. I suspect that Request-URI is not allowed to contain
either CR or LF, but I've not read the spec carefully enough to
be sure.
Another small matter: I get the impression that the ASCII character
set only contains 0-127. Impnotes says:
ASCII, the well-known US-centric 7-bit character set (American
Standard Code for Information Interchange - ASCII).
(BTW that "ASCII" link seems to be broken.)
I'm not sure, but it may be that all 256 "octets" are allowed in some
of the "lines" that you seem to suggest that I read.

Hi Sam,
> it has come to my attention that defstruct mop extensions are neither
> exported nor documented.
>
> structure-slots structure-direct-slots structure-instance-size
> structure-kconstructor structure-boa-constructors structure-copier
> structure-predicate
- For whom would they be useful? Is there some code in clocc/src/port/ that
could profit from it?
- What do other implementations (like SBCL or ACL) offer here?
> do you think they should be exported from CLOS (and reexported from EXT
> like all other CLOS extensions) or directly from EXT?
If they should be exported - depends on the 2 questions above - then
I'd say, directly from EXT, because the comments say this:
;; A kind of Meta-Object Protocol for structures.
;; These function apply to structures of any representation
;; (structure classes as well as subtypes of LIST or VECTOR).
;; This differs from the CLOS MOP
;; 1. in the use of a structure name (symbol) instead of a class,
;; 2. in the different set of available operations: classes in general
;; don't have kconstructors, boa-constructors, copier, predicate,
;; whereas on the other hand structures in general don't have a prototype
;; and finalization.
And if exported, some renaming would probably be in order:
structure-kconstructor -> structure-keyword-constructor.
Bruno

Don Cohen wrote:
> The specs say things like
> [rfc 1945 - http]
> Simple-Request = "GET" SP Request-URI CRLF
> [rfc 821 - smtp]
> HELO <SP> <domain> <CRLF>
> They do not talk about byte sequences #x47, #x45, #x54 or
> #x48, #x45, #x4c, #x4f.
What are you actually programming?
- If you are programming an HTTP or SMTP server, you can use a clisp stream
with charset ASCII - it will convert the CRLF to #\Newline for you.
- If you are programming the client, you can create a clisp stream with
charset ASCII and line-terminator :DOS - it will convert the #\Newline to
CRLF for you.
- If you are programming a protocol checker, that verifies that the CRLF
is really CRLF and not LF, then you'll need to use binary I/O. Are you
doing that??
Bruno

Bugs item #1469663, was opened at 2006-04-13 03:15
Message generated for change (Comment added) made by sds
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1469663&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: modules
>Group: build problems
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Tomas Zellerin (zellerin)
>Assigned to: Sam Steingold (sds)
Summary: clisp-link run does not work w/o dynamic modules
Initial Comment:
If you run "clisp-link run ..." and do not have
dynamic modules, you get an error "/tmp/gtwhatever
already exists".
First, run) calls func_tmpdir that creates the
directory, and then add-module-sets) calls make_dest
that checks that the directory does not exist.
clisp-2.38, built on Linux.
Last few lines of clisp-link.in are relevant.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-20 20:19
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=1469663&group_id=1355

Bugs item #1578179, was opened at 2006-10-16 10:01
Message generated for change (Comment added) made by sds
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1578179&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: Open
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Tomas Zellerin (zellerin)
Assigned to: Bruno Haible (haible)
Summary: Compile-file: non-similarity of strings with cr/lf
Initial Comment:
Consider this (rather artificial) snippet:
(defmacro add-crlf (string)
(with-output-to-string (o)
(write-string string o)
(princ #\Return o)
(princ #\LineFeed o)
))
(print (length (add-crlf "a")))
It prints 3 when loaded without or with compiling, but
2 when compile-file is used and .fas loaded.
I think it is due to treatment described in impnotes
13.8., Treatment of Newline during Input and Output.
I believe this contradicts requirements of CLHS about
similarity of compile-file/loaded literals:
"The file compiler must cooperate with the loader in
order to assure that in each case where an
externalizable object is processed as a literal object,
the loader will construct a similar object." (3.2.4.1)
----------------------------------------------------------------------
>Comment By: Sam Steingold (sds)
Date: 2006-11-20 14:40
Message:
Logged In: YES
user_id=5735
Originator: NO
>If you care about symbol or package names
>that contain CR characters
>you can do the same with a #0Y|...|::|...| syntax.
yes, please.
----------------------------------------------------------------------
Comment By: Bruno Haible (haible)
Date: 2006-11-20 11:25
Message:
Logged In: YES
user_id=5923
Originator: NO
The faithful newline i/o introduces additional problems.
What we need is a solution such that
- .fas files are plain text file that can be edited with a text editor,
- .fas files can be edited and resaved with a different line-terminator
convention, without changing their semantics,
- .fas files can be concatenated to produce an executable script;
it should even be possible to concatenate Unix .fas files with DOS
.fas
files.
The simplest solution is to ignore the newlines when reading .fas files.
This requires a different string representation where all #\Return and
#\Linefeed are explicit. I.e. instead of
"multiline
string"
we write
#0Y"multiline\n
string"
The escape sequences \n and \r are well-known from C and Java, \n also
from Unix 'sed'.
Such a solution has been implemented on 2006-11-20 for strings, by
introducing a
#0Y"..." syntax. If you care about symbol or package names that contain CR
characters
you can do the same with a #0Y|...|::|...| syntax.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-10-16 10:16
Message:
Logged In: YES
user_id=5735
relevant links:
https://sourceforge.net/tracker/index.php?func=detail&aid=731952&group_id=1355&atid=351355http://clisp.cons.org/impnotes/clhs-newline.html
proposed solution: add faithful newline i/o,
via a new encoding facet binary-newline or something like that
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1578179&group_id=1355

Bruno,
it has come to my attention that defstruct mop extensions are neither
exported nor documented.
structure-slots structure-direct-slots structure-instance-size
structure-kconstructor structure-boa-constructors structure-copier
structure-predicate
do you think they should be exported from CLOS (and reexported from EXT
like all other CLOS extensions) or directly from EXT?
Sam.

Bruno Haible writes:
> The paradigm that is in use today is that on any platform, you have text
> files in one and text files in the other convention. And clisp supports this
> conventions.
> > If I could read the bytes 0-255 as 255 different characters I would
> > do so in my http/smtp servers.
>
> But there are a million of characters, not just 255! If you want binary
> I/O, use binary I/O and then use the code-char function as you like.
> CLISP supports binary I/O.
I do use binary IO and code-char. But I think of what I'm doing as a
work around. I think of the common internet protocols as specifying
text in a character set of size 256. The specs say things like
[rfc 1945 - http]
Simple-Request = "GET" SP Request-URI CRLF
[rfc 821 - smtp]
HELO <SP> <domain> <CRLF>
They do not talk about byte sequences #x47, #x45, #x54 or
#x48, #x45, #x4c, #x4f.
My code, similarly, translates the bytes to text strings and
looks for text GET or HELO. I don't think it's unreasonable to
wish that I could read the incoming data as a sequence of
characters drawn from a character set of size 256.
I don't really care how #\newline is interpreted in this character
set since I do not plan to use things like read-line or the ~%
format directive.

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: Closed
Resolution: Rejected
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-20 11:48
Message:
Logged In: YES
user_id=5735
Originator: YES
>Such a :line-terminator-strict option is indeed theoretically possible.
>You would need to assign #\Newline to a different code point, outside
the
>Unicode range, for example #x110000.
I don't see why I cannot use #x80 (#\Code128==#\U0080) for newline.
I am not inventing a new unicode char, I am assigning an integer to a
CLISP character, and this integer (128) is not used at this time.
also, your tables indicate that you are missing the point of my message.
Your first table (identical to my first table) is what you get if
:line-terminator-strict is non-nil and #\newline is distinct from both
#\lf and #\cr.
your second table is relevant only to binary input and cannot be produced
under any combinations of :line-terminator-strict and separate #\nl
proposals.
----------------------------------------------------------------------
Comment By: Bruno Haible (haible)
Date: 2006-11-20 11:22
Message:
Logged In: YES
user_id=5923
Originator: NO
Such a :line-terminator-strict option is indeed theoretically possible.
You would need to assign #\Newline to a different code point, outside the
Unicode range, for example #x110000. (The Unicode people for some time
favoured the use of #x85 as a 3rd newline character, but apparently
dropped the idea.)
So reading in normal mode would produce:
:UNIX :MAC :DOS
CR #\Return #\Newline #\Return
LF #\Newline #\Linefeed #\Linefeed
CRLF #\Return#\Newline #\Newline#\Linefeed #\Newline
And reading in :line-terminator-strict would produce:
:UNIX :MAC :DOS
CR #\Return #\Return #\Return
LF #\Linefeed #\Linefeed #\Linefeed
CRLF #\Return#\Linefeed #\Return#\Linefeed
#\Return#\Linefeed
But what would be the effect of such a change:
- No longer (eql #\Newline #\Linefeed) -> backward compatibility
problem,
- No longer (= (char-code #\Newline) 10) -> Unix compatibility problem
(because we would be copying a DOS concept into a Unix world),
- .fas files that are edited with an editor on Windows (and thus get
LF converted into CRLF) change their meaning when being saved.
So forget about it. It creates more problems than it solves.
----------------------------------------------------------------------
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

Don Cohen wrote:
> 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.
> I would like to point out that some of those paradigms of the 1980s
> are still in heavy use today, like smtp (probably 70's, maybe even
> 60s?) and http (might be the 90s) which specify that lines are to be
> terminated by CRLF, not CR, not LF, not newline.
You misunderstood what I meant by "the paradigms of the 1980ies". It's
the concept that on one platform all text files have lines that end in
LF, and on another platform all text files have lines that end in CR/LF.
The paradigm that is in use today is that on any platform, you have text
files in one and text files in the other convention. And clisp supports this
conventions.
> If I could read the bytes 0-255 as 255 different characters I would
> do so in my http/smtp servers.
But there are a million of characters, not just 255! If you want binary I/O,
use binary I/O and then use the code-char function as you like. CLISP supports
binary I/O.
Bruno

Bugs item #1578179, was opened at 2006-10-16 16:01
Message generated for change (Comment added) made by haible
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1578179&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: Tomas Zellerin (zellerin)
Assigned to: Bruno Haible (haible)
Summary: Compile-file: non-similarity of strings with cr/lf
Initial Comment:
Consider this (rather artificial) snippet:
(defmacro add-crlf (string)
(with-output-to-string (o)
(write-string string o)
(princ #\Return o)
(princ #\LineFeed o)
))
(print (length (add-crlf "a")))
It prints 3 when loaded without or with compiling, but
2 when compile-file is used and .fas loaded.
I think it is due to treatment described in impnotes
13.8., Treatment of Newline during Input and Output.
I believe this contradicts requirements of CLHS about
similarity of compile-file/loaded literals:
"The file compiler must cooperate with the loader in
order to assure that in each case where an
externalizable object is processed as a literal object,
the loader will construct a similar object." (3.2.4.1)
----------------------------------------------------------------------
>Comment By: Bruno Haible (haible)
Date: 2006-11-20 17:25
Message:
Logged In: YES
user_id=5923
Originator: NO
The faithful newline i/o introduces additional problems.
What we need is a solution such that
- .fas files are plain text file that can be edited with a text editor,
- .fas files can be edited and resaved with a different line-terminator
convention, without changing their semantics,
- .fas files can be concatenated to produce an executable script;
it should even be possible to concatenate Unix .fas files with DOS
.fas
files.
The simplest solution is to ignore the newlines when reading .fas files.
This requires a different string representation where all #\Return and
#\Linefeed are explicit. I.e. instead of
"multiline
string"
we write
#0Y"multiline\n
string"
The escape sequences \n and \r are well-known from C and Java, \n also
from Unix 'sed'.
Such a solution has been implemented on 2006-11-20 for strings, by
introducing a
#0Y"..." syntax. If you care about symbol or package names that contain CR
characters
you can do the same with a #0Y|...|::|...| syntax.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-10-16 16:16
Message:
Logged In: YES
user_id=5735
relevant links:
https://sourceforge.net/tracker/index.php?func=detail&aid=731952&group_id=1355&atid=351355http://clisp.cons.org/impnotes/clhs-newline.html
proposed solution: add faithful newline i/o,
via a new encoding facet binary-newline or something like that
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=1578179&group_id=1355

Feature Requests item #731952, was opened at 2003-05-03 22:56
Message generated for change (Comment added) made by haible
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: Closed
>Resolution: Rejected
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: Bruno Haible (haible)
Date: 2006-11-20 17:22
Message:
Logged In: YES
user_id=5923
Originator: NO
Such a :line-terminator-strict option is indeed theoretically possible.
You would need to assign #\Newline to a different code point, outside the
Unicode range, for example #x110000. (The Unicode people for some time
favoured the use of #x85 as a 3rd newline character, but apparently
dropped the idea.)
So reading in normal mode would produce:
:UNIX :MAC :DOS
CR #\Return #\Newline #\Return
LF #\Newline #\Linefeed #\Linefeed
CRLF #\Return#\Newline #\Newline#\Linefeed #\Newline
And reading in :line-terminator-strict would produce:
:UNIX :MAC :DOS
CR #\Return #\Return #\Return
LF #\Linefeed #\Linefeed #\Linefeed
CRLF #\Return#\Linefeed #\Return#\Linefeed
#\Return#\Linefeed
But what would be the effect of such a change:
- No longer (eql #\Newline #\Linefeed) -> backward compatibility
problem,
- No longer (= (char-code #\Newline) 10) -> Unix compatibility problem
(because we would be copying a DOS concept into a Unix world),
- .fas files that are edited with an editor on Windows (and thus get
LF converted into CRLF) change their meaning when being saved.
So forget about it. It creates more problems than it solves.
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2006-11-17 19: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 19: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 16: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 16: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 12: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

Community

Help

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

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

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