Teemu Kalvas <chery@...> writes:
> This patch changes the 128--159 character names so that ~:C gives
> exactly the name, which'll fix one ansi-tests failure.
Merged in sbcl-0.8.13.77.character.35. Thank you.
Cheers,
Christophe
PS: testers for the character_branch are very welcome but now more
than before, since it's beginning to basically work for us early
adopters. Also, contributions of other external formats would be
acceptable: if you use cyrillic, turkish or similar locales on a daily
basis, now would be a good time to implement support for them.

Here's a patch that's related to the one I sent in at
http://article.gmane.org/gmane.lisp.steel-bank.devel/3584 . I hadn't
tried using (:method ...) methods in the defgeneric form until today,
and when I did I ran into the same sort of warning about #'foo.
To see the glitch in action:
(funcall (compile nil '(lambda ()
(flet ((foo () nil))
(defgeneric foo ()
(:method () t))))))
The attached patch fixes it and adds a test case.
Zach

Rob MacLachlan wrote:
> w.r.t. the string issue, I don't
> see any need to hypothesize a useless subtype of string.
Except that the standard appears to require that it exist.
(Bad standard. No cookie.)
Paul

> (make-array '(0) :element-type nil)
>
Hmmn, I should have known better. Let us say you could never create any
useful array with element type nil. w.r.t. the string issue, I don't
see any need to hypothesize a useless subtype of string.
Rob

Rob MacLachlan wrote:
> f.w.i.w. (VECTOR NIL) sounds like nonsense to me. Specialized to hold
> no objects? You could never create an instance of this type because
> there is no possible legal initial value.
(make-array '(0) :element-type nil)
Paul

Marco Antoniotti wrote:
> However, then I do not understand why in SBCL you need the (OR (VECTOR
> NIL) (VECTOR CHARACTER)) thingy when dealing with STRING.
STRING is defined to be the union of all (VECTOR FOO) types for FOO a
subtype
of CHARACTER. And NIL is a subtype of CHARACTER.
Yeah, it's probably a spec bug.
Paul

Hi
Thanks very much for the clarification. I understand the issue quite
better now, and I agree that adding the (ARRAY NIL) and companion
machinery for U-A-E-T is the most sensible way of doing things.
Cheers
Marco
PS. Sorry for the cross posting before.
On Sep 28, 2004, at 9:55 AM, Christophe Rhodes wrote:
> Marco Antoniotti <marcoxa@...> writes:
>
>> Please correct me if you think this is bogus.
>
> I think it's bogus. (And please stop adding irrelevant mailing lists:
> I've trimmed cmucl-imp because I'm sure that anyone who's even
> remotely interested in this point is on sbcl-devel anyway.)
>
> Thinking of type relationships in terms of disjointness is a losing
> practice, because in doing so one loses information. It is more
> helpful to examine these issues in terms of conjunction and
> disjunction: union and intersection, or supertype and subtype
> relationship. (See Baker's "Decision Procedure for SUBTYPEP" for
> why).
>
> NIL specifies the empty type. This makes it the universal subtype:
> for any (known) type <T>, (subtypep nil <T>) must return true. This
> is only mildly relevant to what follows: only to the behaviour of the
> objects that I "show" must exist.
>
> For any known type <U>, (vector <U>) specifies those objects which are
> one-dimensional arrays specialized to hold
> (upgraded-array-element-type <U>). So, trivially, (vector nil) is a
> valid type specifier, if (upgraded-array-element-type nil) does not
> signal an error. What grounds would we have to signal an error? Only
> if there were no arrays at all in the implementation: because all
> arrays can hold objects of their specialized types, and these
> specialized types are always supertypes of type NIL, by definition.
> So, we've shown that (vector nil) must be a valid type specifier; now
> all we need to do is work out what it denotes.
>
> What does upgraded-array-element-type do? It
>
> Returns the element type of the most specialized array
> representation capable of holding items of the type denoted by
> typespec.
>
> The sharp-eyed might spot a problem here: we implicitly have a total
> order on the specialized array types, because
> upgraded-array-element-type must return the most specialized upgraded
> type. This would lead to a contradiction if the only specialized
> array types we had (other than (vector t)) were bit-vector and string:
> because it would then not be clear whether
> (upgraded-array-element-type nil) should be BIT or CHARACTER: NIL is a
> subtype of both, and there isn't an ordering between them.
>
> We rescue ourselves from the implosion of the Universe, however, by
> requiring the existence of another specialized vector whose
> array-element-type is NIL: that is, it can hold no objects. While
> this may not have many practical uses to the application programmer --
> despite various airy speculations on comp.lang.lisp by people who
> should have known better -- it does prevent the implementation world
> from disappearing in a puff of logic, at the expense of two tags.
> Thus, (upgraded-array-element-type nil) returns nil, the type (vector
> nil) denotes vectors which cannot hold anything, for which the
> implementation must provide a specialized representation, and all is
> in fact well. This view is supported by CLHS 15.1.2.1, in addition:
>
> Type upgrading implies a movement upwards in the type hierarchy
> lattice. A type is always a subtype of its upgraded array element
> type. Also, if a type Tx is a subtype of another type Ty, then the
> upgraded array element type of Tx must be a subtype of the upgraded
> array element type of Ty. Two disjoint types can be upgraded to the
> same type.
>
> To see this, try the two (Tx, Ty) pairs (NIL, BASE-CHAR) and (NIL,
> BIT), which shows that the upgraded array element type of NIL must be
> a subtype of BASE-CHAR and a subtype of BIT.
>
> I hope this clears things up,
>
> Cheers,
>
> Christophe
>
--
Marco Antoniotti http://bioinformatics.nyu.edu
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th FL fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.

On Sep 28, 2004, at 10:03 AM, Paul F. Dietz wrote:
> Marco Antoniotti wrote:
>> On Sep 27, 2004, at 10:31 PM, Paul F. Dietz wrote:
>>> Marco Antoniotti wrote:
>>>
>>>> The above should always generate an error as (VECTOR NIL) is not a
>>>> valid type specifier.
>>>
>>>
>>> It's not? :)
>> I took it back yesterday, but I have been having nightmares about it
>> tonight (I should get a life, shouldn't I ? :) )
>> I checked with LW (which I find usually very good at compliance) and
>> it gives an error.
>> The reasoning why (ARRAY NIL) , hence (VECTOR NIL) should not be
>> valid type specifiers is because they would violate the disjointness
>> requirement on the array type hierarchy. Since NIL is the bottom of
>> the type hierarchy, all disjointness requirements break down there.
>> I.e.
>> REAL----+------- FLOAT--------------+--------NIL
>> +------- RATIONAL--------+
>> where I depicted the "disjoint" relation, which is fine.
>> However, for compound types (I know there are tons of Ph.D. theses on
>> the subject: I am not an expert) if we allowed (ARRAY NIL) to be a
>> valid type specifier, then we should allow the following
>> ARRAY -----+---- (ARRAY CHARACTER) ------+---- (ARRAY NIL) --------
>> NIL
>> +---- (ARRAY T) ------------------------+
>> which would be incorrect as we would "rejoin" the ARRAY hierarchy
>> above NIL, while this is expressively forbidden in the ARRAY and
>> VECTOR definitions (CLHS 15.2: System Class ARRAY and System Class
>> VECTOR.)
>> Since the CLHS is weak on typing issues, and I do not recall any
>> place where (ARRAY NIL) is explicitly forbidden, I would say that
>> disallowing it is ok and it is a fair work around the CLHS
>> incompleteness (or inconsistencies :) )
>> Please correct me if you think this is bogus.
>
>
> I think this is bogus. :)
>
> I think you are imagining that if T1 is a subtype of T2, then (array
> T1)
> must be a subtype of (array T2). That's not the case.
You are right. My bogosity score just went up :)
However, then I do not understand why in SBCL you need the (OR (VECTOR
NIL) (VECTOR CHARACTER)) thingy when dealing with STRING.
Cheers
--
Marco Antoniotti http://bioinformatics.nyu.edu
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th FL fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.

Nikodemus Siivola wrote:
> I believe this is STEP's fault. Unless someone gets there first, I'll
> investigate this later this week / early next week. "Should be simple."
Thanks very much for working on this.
Kevin

Marco Antoniotti wrote:
>
> On Sep 27, 2004, at 10:31 PM, Paul F. Dietz wrote:
>
>> Marco Antoniotti wrote:
>>
>>> The above should always generate an error as (VECTOR NIL) is not a
>>> valid type specifier.
>>
>>
>> It's not? :)
>
>
> I took it back yesterday, but I have been having nightmares about it
> tonight (I should get a life, shouldn't I ? :) )
>
> I checked with LW (which I find usually very good at compliance) and it
> gives an error.
>
> The reasoning why (ARRAY NIL) , hence (VECTOR NIL) should not be valid
> type specifiers is because they would violate the disjointness
> requirement on the array type hierarchy. Since NIL is the bottom of the
> type hierarchy, all disjointness requirements break down there. I.e.
>
> REAL----+------- FLOAT--------------+--------NIL
> +------- RATIONAL--------+
>
> where I depicted the "disjoint" relation, which is fine.
>
> However, for compound types (I know there are tons of Ph.D. theses on
> the subject: I am not an expert) if we allowed (ARRAY NIL) to be a valid
> type specifier, then we should allow the following
>
> ARRAY -----+---- (ARRAY CHARACTER) ------+---- (ARRAY NIL) -------- NIL
> +---- (ARRAY T) ------------------------+
>
> which would be incorrect as we would "rejoin" the ARRAY hierarchy above
> NIL, while this is expressively forbidden in the ARRAY and VECTOR
> definitions (CLHS 15.2: System Class ARRAY and System Class VECTOR.)
>
> Since the CLHS is weak on typing issues, and I do not recall any place
> where (ARRAY NIL) is explicitly forbidden, I would say that disallowing
> it is ok and it is a fair work around the CLHS incompleteness (or
> inconsistencies :) )
>
> Please correct me if you think this is bogus.
I think this is bogus. :)
I think you are imagining that if T1 is a subtype of T2, then (array T1)
must be a subtype of (array T2). That's not the case.
(array nil) is a type of arrays into which nothing can be stored. This
doesn't violate disjointness any more than the existence of (array bit)
and (array t) would (with bit being a subtype of t).
(array nil) would be *disjoint* from the other array types.
BTW, consider what (upgraded-array-element-type nil) must be. The requirements
on upgraded-array-element-type (see the CLHS) require this to be type-equivalent
to nil (this follows from the fact that nil is a subtype of bit and character,
and those are fixpoints of u-a-e-t, therefore their intersection must be as well.)
Paul

Marco Antoniotti <marcoxa@...> writes:
> Please correct me if you think this is bogus.
I think it's bogus. (And please stop adding irrelevant mailing lists:
I've trimmed cmucl-imp because I'm sure that anyone who's even
remotely interested in this point is on sbcl-devel anyway.)
Thinking of type relationships in terms of disjointness is a losing
practice, because in doing so one loses information. It is more
helpful to examine these issues in terms of conjunction and
disjunction: union and intersection, or supertype and subtype
relationship. (See Baker's "Decision Procedure for SUBTYPEP" for
why).
NIL specifies the empty type. This makes it the universal subtype:
for any (known) type <T>, (subtypep nil <T>) must return true. This
is only mildly relevant to what follows: only to the behaviour of the
objects that I "show" must exist.
For any known type <U>, (vector <U>) specifies those objects which are
one-dimensional arrays specialized to hold
(upgraded-array-element-type <U>). So, trivially, (vector nil) is a
valid type specifier, if (upgraded-array-element-type nil) does not
signal an error. What grounds would we have to signal an error? Only
if there were no arrays at all in the implementation: because all
arrays can hold objects of their specialized types, and these
specialized types are always supertypes of type NIL, by definition.
So, we've shown that (vector nil) must be a valid type specifier; now
all we need to do is work out what it denotes.
What does upgraded-array-element-type do? It
Returns the element type of the most specialized array
representation capable of holding items of the type denoted by
typespec.
The sharp-eyed might spot a problem here: we implicitly have a total
order on the specialized array types, because
upgraded-array-element-type must return the most specialized upgraded
type. This would lead to a contradiction if the only specialized
array types we had (other than (vector t)) were bit-vector and string:
because it would then not be clear whether
(upgraded-array-element-type nil) should be BIT or CHARACTER: NIL is a
subtype of both, and there isn't an ordering between them.
We rescue ourselves from the implosion of the Universe, however, by
requiring the existence of another specialized vector whose
array-element-type is NIL: that is, it can hold no objects. While
this may not have many practical uses to the application programmer --
despite various airy speculations on comp.lang.lisp by people who
should have known better -- it does prevent the implementation world
from disappearing in a puff of logic, at the expense of two tags.
Thus, (upgraded-array-element-type nil) returns nil, the type (vector
nil) denotes vectors which cannot hold anything, for which the
implementation must provide a specialized representation, and all is
in fact well. This view is supported by CLHS 15.1.2.1, in addition:
Type upgrading implies a movement upwards in the type hierarchy
lattice. A type is always a subtype of its upgraded array element
type. Also, if a type Tx is a subtype of another type Ty, then the
upgraded array element type of Tx must be a subtype of the upgraded
array element type of Ty. Two disjoint types can be upgraded to the
same type.
To see this, try the two (Tx, Ty) pairs (NIL, BASE-CHAR) and (NIL,
BIT), which shows that the upgraded array element type of NIL must be
a subtype of BASE-CHAR and a subtype of BIT.
I hope this clears things up,
Cheers,
Christophe

On Sep 27, 2004, at 10:31 PM, Paul F. Dietz wrote:
> Marco Antoniotti wrote:
>
>> The above should always generate an error as (VECTOR NIL) is not a
>> valid type specifier.
>
> It's not? :)
I took it back yesterday, but I have been having nightmares about it
tonight (I should get a life, shouldn't I ? :) )
I checked with LW (which I find usually very good at compliance) and it
gives an error.
The reasoning why (ARRAY NIL) , hence (VECTOR NIL) should not be valid
type specifiers is because they would violate the disjointness
requirement on the array type hierarchy. Since NIL is the bottom of
the type hierarchy, all disjointness requirements break down there.
I.e.
REAL----+------- FLOAT--------------+--------NIL
+------- RATIONAL--------+
where I depicted the "disjoint" relation, which is fine.
However, for compound types (I know there are tons of Ph.D. theses on
the subject: I am not an expert) if we allowed (ARRAY NIL) to be a
valid type specifier, then we should allow the following
ARRAY -----+---- (ARRAY CHARACTER) ------+---- (ARRAY NIL) -------- NIL
+---- (ARRAY T) ------------------------+
which would be incorrect as we would "rejoin" the ARRAY hierarchy above
NIL, while this is expressively forbidden in the ARRAY and VECTOR
definitions (CLHS 15.2: System Class ARRAY and System Class VECTOR.)
Since the CLHS is weak on typing issues, and I do not recall any place
where (ARRAY NIL) is explicitly forbidden, I would say that
disallowing it is ok and it is a fair work around the CLHS
incompleteness (or inconsistencies :) )
Please correct me if you think this is bogus.
Cheers
--
Marco
>
> Paul
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
> Project Admins to receive an Apple iPod Mini FREE for your judgement on
> who ports your project to Linux PPC the best. Sponsored by IBM.
> Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
> _______________________________________________
> Sbcl-devel mailing list
> Sbcl-devel@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
>
--
Marco Antoniotti http://bioinformatics.nyu.edu
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
715 Broadway 10th FL fax. +1 - 212 - 998 3484
New York, NY, 10003, U.S.A.

Teemu Kalvas <chery@...> writes:
> I enclose here a patch on character_branch which
[ Dunno when or if this, or my previous mail, will get through:
something 'twixt here and there seems to be eating my mail... ]
I've merged this into sbcl-0.8.13.77.character.33. Note that as of
this patch, not only does input/output not work in non-utf8 locales,
but also the system doesn't even start in non-utf8 locales. For me,
it says:
csr21@...:~/misc-cvs/sbcl$ LANG=C ./src/runtime/sbcl --core output/sbcl.core
This is SBCL 0.8.13.77.character.33, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/&gt;.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
internal error #1
SC: 14, Offset: 2 $nil= 0x0500000b: list pointer (NIL)
fatal error encountered in SBCL pid 4544:
internal error too early in init, can't recover
LDB monitor
ldb> backtrace
Can't backtrace on this hardware platform.
ldb> eat flaming death
unknown command: ``eat''
Oh well. Any ideas?
Cheers,
Christophe

"Paul F. Dietz" <dietz@...> writes:
> Christophe Rhodes wrote:
>> Right. My argument is that this is conforming behaviour: the symbol
>> SIMPLE-STRING means (SIMPLE-ARRAY CHARACTER) when used for sequence
>> creating functions, as per the CLHS "Type SIMPLE-STRING" page; no such
>> behaviour is implied anywhere for the Compound Type Specifier
>> (SIMPLE-STRING).
>
> I'll argue that this is contradicted by this statement (on the page
> for SIMPLE-STRING):
>
> When used as a type specifier for object creation, simple-string
> means (simple-array character (size)).
>
> Note the 'size'. This means it's supposed to be sensible to use
>
> (simple-string *)
>
> as a type specifier in object creation, where * is the size.
> According to 4.2.3, (simple-string) is just an abbreviation for that.
Hm. That's interesting, and also irritating in no small part. The
page for STRING has no such clause, and I'd be inclined to argue that
they actually meant that "simple-string means (simple-array character
(*))" -- because size at that point is an unbound reference... :-)
Cheers,
Christophe

Teemu Kalvas <chery@...> writes:
> I enclose here a patch on character_branch which
>
> 1. Fixes FAST-READ-CHAR completely and totally.
>
> 2. Includes neat macros for generating all necessary functions for
> an external format. Used for utf-8, latin-1, latin-9.
>
> 3. Fixes INTERNAL-LOAD when CONTENTS is not supplied. The previous
> version opened unknown files in :element-type character and
> :external-format :default, which broke with :utf-8 and a .fasl
> as the unknown file when FAST-READ-CHAR was fixed.
Excellent. I'm going to merge this very shortly, just as soon as I've
read it. :-) A couple of questions:
* have you benchmarked fast-read-char? Does it work faster than the
old version, and also does it help in non-ascii-locales?
* how are you planning to manage efficiency of external formats?
Or, to put it another way, is the processing of latin-9 noticeable
compared with the latin-1 background?
* I could also ask you here about composing external format
transformations, but I think you're ahead of me anyway, judging
from your comments linked from the sbcl-internals fu-streams page.
> Error reporting for external format is very limited indeed. Something
> needs to be designed for that.
Yes, and probably also for recovering from invalid input (unless
you've fixed that as well): invalid output is easy to recover from,
but if you get a malformed utf-8 sequence, for instance, how do you
recover? Ideally better than we currently do, which is a debugger
loop without hope of exiting...
Cheers,
Christophe

On Tue, 28 Sep 2004, Kevin Rosenberg wrote:
> I've reproduced your results. I'm not convinced that SBCL is operating
> correctly when DEBUG is set to 3:
I believe this is STEP's fault. Unless someone gets there first, I'll
investigate this later this week / early next week. "Should be simple."
>> ; compiling DEFUN READ-HTTP-REQUEST:
>> debugger invoked on a SB-INT:BUG in thread 18142:
>> full call to SB-KERNEL:DATA-VECTOR-SET
...but this actually looks related to bug #302. I wonder if this is a case
of two separate bugs, the new #302-lookalike being triggered by the
stepper bug.
> call to SB-KERNEL:DATA-VECTOR-SET when (OPTIMIZE (DEBUG 3)). Also,
> hopefully someone on that list knows about the general
> suitability/caveats of using DEBUG 3.
DEBUG 3 when SIZE & SPEED are less then DEBUG introduces a significant
performance penalty and code bloat these days (say a factor of x5 compared
to what it used to be?), due to the new instrumentation based single
stepper. Bugs there are just that --bugs-- and hopefully will be weeded
out soonish -- but the performance penalty is likely to stay. Then again,
as long as the performance is not a problem, I see no reason to avoid
DEBUG 3.
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."

Rudi Schlatte wrote:
> IIRC, sigpipe is only "handled" specially by aserve so that it can be
> ignored in the logs, because it happens frequently during normal
> operation. Turning sigpipe off should have no ill effects.
That's how it appeared to me as well. Thanks for the confirmation.
--
Kevin Rosenberg
kevin@...

[CC: sbcl-devel]
Gabor Melis wrote:
> On sbcl 0.8.14 I have a strange problem when using postgresql and
> aserve: if I connect to a database then sbcl sometimes gets killed
> when receiving a lot of http requests. I can reproduce this problem
> by load this file and reloading http://localhost:2001/ a lot of
> times. Holding f5 down in konqueror will do.
Thanks for the test case. I've also been able to reproduce this
using apache's ab program, such as
ab -n 6 -c 3 http://localhost:2001/
> Of course I'm not really sure who is the culprit. It suspect it clsql's
> postgresql connector, if postgresql-socket is used then the problem goes
> away.
I believe the problem may be an interaction with SIGPIPE handlers
between SBCL and libpq. I've cc'd this message to sbcl-devel to see if
any SBCL developers/users have some insight into this possibility.
Some data points:
1) Testing your example program with mysql and
postgresql-socket backends, a SIGPIPE error is caught by SBCL,
presumably due to the a incoming connection being closed by waiting
to for page request to be serviced.
2) When testing with SBCL and postgresql backend, at the time in the
test sequence that a SIGPIPE message would be printed using mysql
and postgresql-socket backends, SBCL is killed rather than
displaying the SIGPIPE message.
3) In http://linux.com.hk/docs/postgresql/libpq-threading.html,
the documentation states that libpq installs its own SIGPIPE
handler. I believe the SIGPIPE is perhaps being caught by libpq which
kills SBCL.
I'm not sure how to work-around this or indeed to prove my suspicion
is correct. One thing you may wish to look at whether sigpipe messages
can be turned off in sb-bsd-sockets, perhaps using
sockint::MSG-NOSIGNAL. While turning off sigpipe messages may fix SBCL
being killed, it may affect the function http-worker-thread in
paserve's main.cl which apparently handles sigpipe errors detected
with the function connection-reset-error.
I've attached a slightly modified version of your test case to this
message in case someone wants to look at this interaction.
Thanks again for the interesting report and the test case.
Kevin