headers
Rob MacLachlan | 1 Jan 2005 15:53
Picon
Favicon

Re: Sbcl-devel digest, Vol 1 #1292 - 4 msgs


I don't know about in SBCL, but in my original code, still in CMUCL, the 
variable *use-implementation-types* is supposed to determine whether 
type disjointness it determined based on the actual types in this 
particular implementation or the a more restrictive rule based on what 
could possible be done in a legal implementation.  So w.r.t. (vector 
package) v.s. (vector hashable), those objects would be distinguishable 
in an implementation where one or the other was a specialized array 
element type.

I recall leaving this switch set to false so that we would be able to 
detect more error situations where the code is not portable but is type 
legal in this implementation.  Hoever at some point, this seems to have 
changed to T in the cmucl sources, so this feature is off.

Anyway, this may be relevant.

(defvar *use-implementation-types* t
   "*Use-Implementation-Types* is a semi-public flag which determines how
    restrictive we are in determining type membership.  If two types are the
    same in the implementation, then we will consider them them the same 
when
    this switch is on.  When it is off, we try to be as restrictive as the
    language allows, allowing us to detect more errors.  Currently, this 
only
    affects array types.")

   Rob

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christophe Rhodes | 1 Jan 2005 22:00
Picon
Picon
Favicon

Re: (coerce #c(1 2) '(complex float)) => error

Vincent Arkesteijn <vincent <at> arkesteijn.net> writes:

> In SBCL 0.8.17.28:
> * (coerce #c(1 2) '(complex float))
>
> debugger invoked on a SIMPLE-TYPE-ERROR in thread 15242:
>   Argument REALPART is not a REAL: #C(1 2)
>
> The attached patch solves this.

Thank you.  I've merged this in sbcl-0.8.18.9.

Cheers,

Christophe

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 1 comment |
headers
Christophe Rhodes | 1 Jan 2005 22:01
Picon
Picon
Favicon

Re: a bug in 'filesys.lisp'

"Artem V. Andreev" <artem <at> AA5779.spb.edu> writes:

> This leads to an absurd situation when pathnames like
> #P"/usr/*/doc/x.y" are parsed correcly but an error is signalled if
> they passed to NAMESTRING

Thank you; I've merged a fix for this into sbcl-0.8.18.9.

Cheers,

Christophe

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 501 comments |
headers
Paolo Amoroso | 1 Jan 2005 22:37
Picon
Favicon

Re: (coerce #c(1 2) '(complex float)) => error

Christophe Rhodes <csr21 <at> cam.ac.uk> writes:

> X-Spam-Score: -2.6 (--)
> X-Spam-Report: Spam detection software, running on the system "sc8-sf-spam2.sourceforge.net", has
>        identified this incoming email as possible spam.  The original message
>        has been attached to this so you can view it (if it isn't spam) or label
>        similar future email.  If you have any questions, see
>        the administrator of that system for details.
>        Content preview:  Vincent Arkesteijn <vincent <at> arkesteijn.net> writes: >
>        In SBCL 0.8.17.28: > * (coerce #c(1 2) '(complex float)) > > debugger
>        invoked on a SIMPLE-TYPE-ERROR in thread 15242: > Argument REALPART is
>        not a REAL: #C(1 2) > > The attached patch solves this. [...] 
>        Content analysis details:   (-2.6 points, 5.0 required)
>        pts rule name              description
>        ---- ---------------------- --------------------------------------------------
>        -2.6 BAYES_00               BODY: Bayesian spam probability is 0 to 1%
>        [score: 0.0000]
>        0.0 AWL                    AWL: From: address is in the auto white-list

It looks like Sourceforge is tagging some of your messages as spam.
Ironically, my own spam filter, based on `mailfilter', in turn
identifies the Sourceforge header fields as spam, because the maximum
line length of fields in the message header is longer than the default
of 998 characters.

Paolo
--

-- 
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christophe Rhodes | 1 Jan 2005 22:38
Picon
Picon
Favicon

Re: Re: undefined-classoid bug

Cheuksan Edward Wang <wang02139 <at> gmail.com> writes:

> I have a fix for the forward-reference layout bug. It turns out that
> find-layout will make an undefined-classoid. There is no need to make
> another one in find-and-init-or-check-layout. I've attached a simple
> patch.

> -			      (make-undefined-classoid name))
> +			      (layout-classoid layout)) ; an undefined-classoid

Thanks.  Do you have a simple test case which demonstrates the problem?

Cheers,

Christophe

-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
Permalink | Reply | 1 comment |
headers
Ivan Shvedunov | 2 Jan 2005 08:06
Picon
Gravatar

Problem in src/code/fd-stream.lisp

Hello.
[tried to post this to c.l.l., but this is probably more appropriate place]
I've stumbled across an unpleasant problem with SBCL fd-stream
implementation. My app has a central SERVE-EVENT based event loop and
uses threaded Araneida for it's web UI. I'm using SBCL 0.8.17.
Sometimes I get a strange error:

Caught error: failure in Unix lseek() on #<FILE-STREAM for "a constant
string" {9F68E71}>:
                Bad file descriptor

[full backtrace at the end of msg] which is shortly followed by

   NIL have bad file descriptors.
...
0: (SB-IMPL::HANDLER-DESCRIPTORS-ERROR 0)[:EXTERNAL]
1: (SB-IMPL::SUB-SERVE-EVENT 2 0 204000)[:EXTERNAL]

The latter is SIMPLE-ERROR which makes it hard to handle properly and
occurs in the event thread.

I'm not an experienced Lisper, but I tried to investigate the problem.
I've took a look at SB-SYS:OUTPUT-RAW-BYTES which was mentioned in
backtrace for the first error.
It starts with:

(defun output-raw-bytes (fd-stream thing &optional start end)
  #!+sb-doc
  "Output THING to FD-STREAM. THING can be any kind of vector or a SAP. If
  THING is a SAP, END must be supplied (as length won't work)."
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Roberts | 2 Jan 2005 09:24

Info files installation patch

The other day I noticed that info files weren't being installed
correctly by the install.sh script. This patch seems to fix that. There
were a couple of problems. First, /sbin may not be in root's path.
Second, the install-info command wasn't being given a DIR parameter,
causing it to error.

Index: install.sh
===================================================================
RCS file: /cvsroot/sbcl/sbcl/install.sh,v
retrieving revision 1.19
diff -u -r1.19 install.sh
--- install.sh  21 Oct 2004 13:00:23 -0000      1.19
+++ install.sh  2 Jan 2005 08:17:36 -0000
 <at>  <at>  -84,7 +84,7  <at>  <at> 
 do
   cp $info $BUILD_ROOT$INFO_DIR/ \
       && echo -n " info $BUILD_ROOT$INFO_DIR/`basename $info`" \
-      && ( install-info $BUILD_ROOT$INFO_DIR/`basename $info`
> /dev/null 2>&1
\
+      && ( /sbin/install-info $BUILD_ROOT$INFO_DIR/`basename $info`
$BUILD_ROOT$INFO_DIR/dir > /dev/null 2>&1 \
            || echo -n " (could not add to system catalog)" ) \
       && echo
 done

--

-- 
Dave Roberts <ldave <at> droberts.com>
Permalink | Reply | 501 comments |
headers
Robert J. Macomber | 2 Jan 2005 11:07

string/octets and alien string conversion

I've got an implementation of string->octets and octets->string which
handles errors in UTF-8 encoding according to the utf decoder test at
http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt (almost; it
doesn't catch the utf-16 surrogates or "other illegal code positions"
from 5.1, 5.2, or 5.3 in order to ensure that octets->string is an
exact inverse of string->octets with :external-format :utf-8; not sure
that's right, and it's easy to fix if necessary, just another check or
two in the 3-byte path of bytes-per-utf8-character).

My patches to source files (build-order.lisp-expr and target-c-call.lisp)
are at:
  http://www.rojoma.com/octets/sbcl-octets-patch.diff
and the added "octets.lisp" file is at
  http://www.rojoma.com/octets/octets.lisp

A few random thoughts: Currently the implementation of
%naturalize-utf8-string in target-c-call.lisp unconditionally uses a
#xfffd character for replacing bad UTF-8 sequences (this is what
Mozilla does) on the grounds that it'd be really annoying to have to
wrap every call out to alienland in a handler-bind of some kind;
perhaps octet-{en,de}coding-error ought not to be errors at all, so
user code can catch them if it feels like it, but if it chooses not to
one of the various possible "right things" is done?  I'm not sure it
makes sense for external-format to be a non-required parameter except
for symmetry with streams.  I'd like to make the external
representation of #\Newline part of the external-format.
--

-- 
Robert Macomber
sf-sbcl-2 <at> rojoma.com
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christophe Rhodes | 2 Jan 2005 12:00
Picon
Picon
Favicon

Re: name-service-error subclass of condition, not of error

Antonio Martinez <antonio.martinez.shotton <at> gmail.com> writes:

> In name-service.lisp, name-service-error subclasses condition, not
> error.  From the name of the condition, I expected it to subclass
> error; is there a good reason not to?  (Perhaps better to have an
> abstract network-error subclass, which socket-error and
> name-service-error subclass?)

From the horse's mouth (otherwise known as "I asked Dan on IRC"): I
think there is some confusion lurking in the code which may or may not
be an indication of residual confusion in what name-service-errors
are.  On the other hand, you're the second person at least to raise
this, so if there's confusion it's quite likely to be in sbcl's side.

There is a try-again-error which is indicative of a temporary failure,
as I understand.  I don't know whether this should be an error or not;
I think it probably should; Dan seems to think that he was a lot less
clear on the condition system (and the distinction between the SIGNAL
and ERROR functions) when he wrote net-telent-sockets.

So, unless I hear otherwise I will probably make the change to the
name-service-error superclass; but it's not something that I
personally feel confident about, because I don't know much about
networking protocols or about the sb-bsd-sockets code.

Cheers,

Christophe

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Antonio Martinez | 2 Jan 2005 14:30
Picon

Re: name-service-error subclass of condition, not of error

On Sun, 02 Jan 2005 11:00:35 +0000, Christophe Rhodes <csr21 <at> cam.ac.uk> wrote:
> From the horse's mouth (otherwise known as "I asked Dan on IRC"): I
> think there is some confusion lurking in the code which may or may not
> be an indication of residual confusion in what name-service-errors
> are.  On the other hand, you're the second person at least to raise
> this, so if there's confusion it's quite likely to be in sbcl's side.

Heh.  Actually, it was the name inconsistency threw me, more than
whether or not this situation merits "errors" or "conditions."  I tend
to expect conditions with "error" in the name to subclass error, and
those with "condition" not to subclass error.

> There is a try-again-error which is indicative of a temporary failure,
> as I understand.  I don't know whether this should be an error or not;
> I think it probably should; Dan seems to think that he was a lot less
> clear on the condition system (and the distinction between the SIGNAL
> and ERROR functions) when he wrote net-telent-sockets.

I don't think the estimated duration of the problem is enough to
determine the condition class, but rather if there's a defined way to
handle it.  If the signaller has a defined retry strategy, then it
should probably signal a condition, but not hit the debugger.  In our
case, though, all we're being told is that the error is temporary and
amenable to retries, but we lack a handler definition (3 retries?  15?
 Infinite?  In linear time?  Exponential?  Should we suspend
processing until then?  Spawn a thread?  Pass back a retry-thunk? 
Etc.).

In a protocol with a defined retry strategy and a defined interaction
with other tasks (running in it's own thread, say), then we could just
(Continue reading)

Permalink | Reply | 0 comments |

Gmane