Re: 0.8.14 and md5 1.8.3: segmentation violation

Stefan Scholl <stesch <at> no-spoon.de> writes:

> * (md5:md5sum-sequence "foo")
>
> debugger invoked on a SIMPLE-ERROR in thread 24272:
>   segmentation violation at #X97A9418

So although this isn't the friendliest way of telling you so, lying to
the compiler under (speed 3) (safety 0) is a relatively good way of
convincing the system that zero is equal to minus one, and once we've
reached that point, well, all bets are off.  Essentially, given the
false ftype declamation for MD5::I, the compiler proves that the
universe is inconsistent: given that, the fact that it doesn't format
your hard drive is perhaps a bonus 

(Note that it _does_ tell you that the compilation failed: when
compiling md5.lisp, it throws a full WARNING when compiling MD5::I,
complaining of the type mismatch between the derived type and the
declared type; COMPILE-FILE also returns a failure value of T.)

So, this is really a feature.  

Cheers,

Christophe
--

-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)

Re: 0.8.14 and md5 1.8.3: segmentation violation

On 2004-09-01 01:45:59, Christophe Rhodes wrote:

> (Note that it _does_ tell you that the compilation failed: when
> compiling md5.lisp, it throws a full WARNING when compiling MD5::I,
> complaining of the type mismatch between the derived type and the
> declared type; COMPILE-FILE also returns a failure value of T.)

; /home/stesch/.sbcl/site/md5-1.8.3/md5.fasl written
; compilation finished in 0:00:08
; compilation unit finished
;   printed 303 notes

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

PPC changes for character_branch

Attached is a patch containing minimal changes that allow the SBCL
character_branch to compile and function properly (AFAICT) on Linux/PPC.
Probably on OS X as well, but I haven't tested it.

Cheers.

-- 
Julian Squires

? barpat
? foopat
? contrib/sb-simple-streams/test-data.tmp
Index: src/compiler/ppc/array.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/compiler/ppc/array.lisp,v
retrieving revision 1.6
diff -u -Fdef -r1.6 array.lisp
--- src/compiler/ppc/array.lisp	10 Aug 2004 14:20:48 -0000	1.6
+++ src/compiler/ppc/array.lisp	1 Sep 2004 17:26:44 -0000
 <at>  <at>  -110,10 +110,11  <at>  <at>       (define-vop (,(symbolicate "DATA-VE
        (:results (result :scs ,scs))
        (:result-types ,element-type)))))
   (def-data-vector-frobs simple-base-string byte-index
-    base-char base-char-reg)
+    character character-reg)
+  (def-data-vector-frobs simple-character-string byte-index
+    character character-reg)
   (def-data-vector-frobs simple-vector word-index

Re: Re: 0.8.14 and md5 1.8.3: segmentation violation

Stefan Scholl <stesch <at> no-spoon.de> writes:

> On 2004-09-01 01:45:59, Christophe Rhodes wrote:
>
>> (Note that it _does_ tell you that the compilation failed: when
>> compiling md5.lisp, it throws a full WARNING when compiling MD5::I,
>> complaining of the type mismatch between the derived type and the
>> declared type; COMPILE-FILE also returns a failure value of T.)
>
> ; /home/stesch/.sbcl/site/md5-1.8.3/md5.fasl written
> ; compilation finished in 0:00:08
> ; compilation unit finished
> ;   printed 303 notes

[ apologies for the late reply: my mail server appears to be heading
for an accident, and I've spent the last while attempting to migrate
ancient mailboxes, transports, and so on to a hopefully more reliable
place. ]

This is odd.  I confess that I was wrong, too -- it doesn't throw a
full WARNING, it throws a STYLE-WARNING (even though the intersection
of the ftypes is, by inspection, NIL).  Probably the fact that it's a
style warning is related to bug #217.

However, with sbcl-0.8.13.7x, I definitely do get a style-warning.
Could you put a full transcript up on the web somewhere?

Cheers,

Christophe

mailer error: redo from start

Hi,

Over the last week, my desktop has begun acting sufficiently flakily
that I thought it prudent to transfer various services it provided,
such as mail reading, elsewhere.  This would not normally be announced
to all and sundry, except that this transfer was not
information-preserving: though I have not lost any mails, to the best
of my knowledge, what I have lost are the 100-or-so marks on
sbcl-devel messages that I thought needed revisiting.  In some ways,
this is good, as I will no longer feel guilty about having amongst
others a marked message from February 2003 from Robert Brown that I
haven't dealt with... on the other hand, this is perhaps a good
opportunity to remind people that if they have an outstanding issue
that seems to be ignored, it is adviseable to remind us gently of the
fact.

Cheers,

Christophe
--

-- 
This space for rent

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: unicode request

Ben <ben <at> medianstrip.net> writes:

> as per our #lisp discussion, of a unicode feature request:
>
> request: to play nicely with the FFI, aliens.  more specifically,
> access to the underlying bytes of a unicode string (as a lisp (array
> (unsigned-byte 32)) probably) at least for passing to foreign
> funtions.  a function which converts an (foreign) array of the
> appropriate type to a unicode string, with minimal fuss.

What I enviseage here is something which probably meets your needs,
but let me know if not.

The C-STRING alien type (and the associated UTF8-STRING alien type
which I'm planning) are certainly not going to be the only way to pass
strings in to and receive them from foreign functions.  Those types
are, I think, intended for when part of the semantics of the object,
as well as the raw binary layout, is known: for instance, a C function
which is sensibly called with a C-STRING object is probably declared
as accepting char[] or *char as its argument, but the routine will use
the knowledge that it is getting a null-terminated sequence of char.
I believe one can already pass strings in as alien (array char) or
(array unsigned-char) types; I don't anticipate this changing -- and
certainly there will be equivalent behaviour for (array wchar-t) or
similar.  (I can't remember off-hand the status of wchar-t these days
-- is its width specified in POSIX or C9X?)

The only change I'd propose won't in fact affect your application,
though it might affect others': that is, to change the C-STRING type
such that it only accepts ASCII.  [(SIMPLE-ARRAY CHARACTER (*))

Re: Problem on the character_branch

Stig E Sandoe <stig <at> boblycat.org> writes:

> as requested, I ran into this iffy with the character_branch.
> It might've been me that have been interpreting the clhs wrong,
> but here goes:
>
> debugger invoked on a TYPE-ERROR in thread 3077:
>   The value "& wooden torch~" is not of type (SIMPLE-ARRAY BASE-CHAR (*)).

We talked about this a little on IRC: here's what attempts to be a
summary of the issues.

In Common Lisp, the type (SIMPLE-ARRAY X (*)) does not mean "a simple
array of dimension 1 (of unspecified length) which holds only objects
of type X".  It means "a simple array of dimension 1 (of unspecified
length) which can only hold objects of type X"[*].  In a world where
BASE-CHAR and CHARACTER are distinct, (SIMPLE-ARRAY BASE-CHAR (*)) and
(SIMPLE-ARRAY CHARACTER (*)) are likewise distinct, but are both
subtypes of SIMPLE-STRING.

The reader macro for #\" must create a string.  However, leeway is
given to the implementation as to what kind of string it produces: it
is not required either that the most general string type, nor the most
specific string type (if an ordering can even be defined) should be
returned.  At the moment, on the character branch, the #\" reader
macro always returns an object of type (SIMPLE-ARRAY CHARACTER (*)) --
that is, it always returns the string type which can contain any
character.

One might, as Stig suggests, read literal strings containing only

Re: PPC changes for character_branch

tek <at> wiw.org writes:

> Attached is a patch containing minimal changes that allow the SBCL
> character_branch to compile and function properly (AFAICT) on Linux/PPC.
> Probably on OS X as well, but I haven't tested it.

Patrik tested it and merged it.  Thank you very much.

Cheers,

Christophe
--

-- 
Writing out signatures by hand?  What a character!

-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: unicode request

On Thu, 2 Sep 2004, Christophe Rhodes wrote:

> What I enviseage here is something which probably meets your needs,
> but let me know if not.
>
> The C-STRING alien type (and the associated UTF8-STRING alien type
> which I'm planning) are certainly not going to be the only way to pass
> strings in to and receive them from foreign functions.  Those types
> are, I think, intended for when part of the semantics of the object,
> as well as the raw binary layout, is known: for instance, a C function
> which is sensibly called with a C-STRING object is probably declared
> as accepting char[] or *char as its argument, but the routine will use
> the knowledge that it is getting a null-terminated sequence of char.
> I believe one can already pass strings in as alien (array char) or
> (array unsigned-char) types; I don't anticipate this changing -- and
> certainly there will be equivalent behaviour for (array wchar-t) or
> similar.  (I can't remember off-hand the status of wchar-t these days
> -- is its width specified in POSIX or C9X?)

this is perfect.

> The only change I'd propose won't in fact affect your application,
> though it might affect others': that is, to change the C-STRING type
> such that it only accepts ASCII.  [(SIMPLE-ARRAY CHARACTER (*))
> objects can be converted to C-STRINGS, provided that they only contain
> BASE-CHARs.]  The Rationale here is that, viewed as a string,
> higher-bit characters are possibly ambiguous -- and at least in our
> current interpretation, don't fit into a BASE-STRING; things
> potentially go wrong if the application is using char rather than

Re: unicode request

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

| The only change I'd propose won't in fact affect your application,
| though it might affect others': that is, to change the C-STRING type
| such that it only accepts ASCII.  [(SIMPLE-ARRAY CHARACTER (*))
| objects can be converted to C-STRINGS, provided that they only
| contain BASE-CHARs.]

But there is a vast sea of legacy data out there encoded in various
8-bit character sets.  We need a way to deal with those in the
foreseeable future.

| The Rationale here is that, viewed as a string, higher-bit
| characters are possibly ambiguous

Agreed, but that can be remedied in various ways.  Perhaps even by
having a special variable containing a (specification of a) suitable
8-bit charset for these conversions.  If it is NIL (the default
value), then only ASCII is allowed, otherwise characters are
converted.

| -- and at least in our current interpretation, don't fit into a
| BASE-STRING; things potentially go wrong if the application is using
| char rather than unsigned char, etc.

Hmmm.  Do you mean, if the C routine uses arrays of char (signed or
unsigned) as arrays of tiny integers?  Then they should not be treated
as strings in the first place.  But probably I misunderstood what you
are saying.