headers
Juho Snellman | 2 Aug 2005 19:23
Picon
Picon
Favicon

Re: trouble building the documentation

On Sun, Jul 31, 2005 at 02:16:20PM -0400, Dan Starr wrote:
> Sent you a message about this a couple weeks ago using 0.9.2.  
> Apparently nothing has changed in 0.9.3.  The build works OK as do the 
> tests.  Cannot, however, get the documentation to build correctly.  I 
> get the feeling that I'm doing something very simply wrong.

As the error message says, you do not have TeX installed (required
for the pdf and ps formats of the manual):

>> /usr/bin/texi2dvi: line 599: tex: command not found
>> /usr/bin/texi2dvi: tex exited with bad status, quitting.

Either install a TeX distribution or only build the manual for the
other available formats:

make info html

> My own programs execute OK, and I still have man pages from 0.9.0, 
> which I installed as a binary.  I did find that I had to move the man 
> pages somewhere else to get man to recognize them.

The sbcl manual != the sbcl Unix man page. The man page already exists
in the source distribution and doesn't need to be built separately.

--

-- 
Juho Snellman

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Michael Price | 1 Aug 2005 21:48
Picon

FreeBSD build issue.

I'm on a FreeBSD 5.3-RELEASE-p20 box trying to build and install sbcl
0.9.3 using the sbcl-0.8.17 FreeBSD port.

The build appears to finish normally but the run-tests.sh script fails with:

unhandled SIMPLE-ERROR:
  The assertion (RAISES-ERROR? (SCALE-FLOAT 1.0 MOST-POSITIVE-FIXNUM)
                               FLOATING-POINT-OVERFLOW) failed.

...followed by a large stack trace and ending with...

unhandled condition in --disable-debugger mode, quitting
test (pure.lisp files) failed, expected 104 return code, got 1

If you install this build then sbcl seg-faults on startup.

This happens for me with the entire 0.9.x line. What am I doing wrong?

Michael

-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
Permalink | Reply | 1 comment |
headers
Christophe Rhodes | 1 Aug 2005 21:53
Picon
Picon
Favicon

Re: FreeBSD build issue.

Michael Price <ectospheno <at> gmail.com> writes:

> I'm on a FreeBSD 5.3-RELEASE-p20 box trying to build and install sbcl
> 0.9.3 using the sbcl-0.8.17 FreeBSD port.
>
> The build appears to finish normally but the run-tests.sh script fails with:
>
> unhandled SIMPLE-ERROR:
>   The assertion (RAISES-ERROR? (SCALE-FLOAT 1.0 MOST-POSITIVE-FIXNUM)
>                                FLOATING-POINT-OVERFLOW) failed.
>
> ...followed by a large stack trace and ending with...
>
> unhandled condition in --disable-debugger mode, quitting
> test (pure.lisp files) failed, expected 104 return code, got 1

I think I would expect this -- this is one of those things that is not
fixed on the FreeBSD platform, as the text that is printed at the end
of the build suggests.  (It's not a terribly huge problem, unless
you're trying to do sophisticated things with IEEE floating point)

> If you install this build then sbcl seg-faults on startup.

This is more unexpected.  What are the values of $LANG and $LC_ALL (or
other locale-affecting variables)?  Does the installed sbcl start up
if you do "LANG=C sbcl" at the shell prompt?

Cheers,

Christophe
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell McManus | 4 Aug 2005 04:13
Picon
Favicon

help with octets-to-string and string-to-octets


I'm attempting to write a subclass of sb-gray:fundamental-stream with
the following properties:

1. at make-instance time you must supply :external-format.

2. one can read and write strings to/from it.

3. it transparently converts these strings into bytes for you with
calls to the above functions, and directly calls unix-read and
unix-write at the proper times.

4. it buffers input and output intelligently.

5. it supports read-n-bytes with the nifto-matic ability to not block
if the requested number of bytes is not available.

Given all of that, here is my question.

Assume I've read some data from the network as bytes, and stored it
into a (vector (unsigned-byte 8) *).  To implement read-char, I need
to call sb-ext:octets-to-string.  But here I need to know how many
bytes will make up a character, which I don't know how to figure out
in general.

From reading octets.lisp, I think that I can assume that 1 byte = 1
char at this time, but I know that this isn't right in general.  I'm
not very well read in the character encoding department, so any ideas
you might have here would help.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyrus Harmon | 6 Aug 2005 00:06

sb-alien:enum question


So I've been trying to figure out how to map C enums to SBCL types.  
UFFI's approach seems to be to do a define-alien-type <enum-name>  
SIGNED and constants for the values. sb-alien, however, has a nice sb- 
alien:enum type. Christophe was kind enough to provide an example of  
how to do this. Here's a similar example:

(sb-alien:define-alien-type moose-enum
                             (sb-alien:enum moose-enum-name
                                            (:moose 1)
                                            (:bear 2)))

this works great and I can do:

(defparameter moose-var (sb-alien:make-alien moose-enum))

and I can do

(setf (sb-alien:deref moose-var) :bear) to set the value to :bear.  
Other keywords don't work, which is great. Is there a way to actually  
get the value represented by the keyword :bear in the context of the  
enum? I know this sort of defeats the purpose of the enum, but it  
would still be nice to get.

Thanks,

Cyrus

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
(Continue reading)

Permalink | Reply | 1 comment |
headers
Thomas F. Burdick | 6 Aug 2005 09:45
Picon

Re: sb-alien:enum question

Cyrus Harmon writes:
 > (setf (sb-alien:deref moose-var) :bear) to set the value to :bear.  
 > Other keywords don't work, which is great. Is there a way to actually  
 > get the value represented by the keyword :bear in the context of the  
 > enum? I know this sort of defeats the purpose of the enum, but it  
 > would still be nice to get.

Sure.  When you dereference a (* moose-enum), you get a valid
moose-enum value.  If you want an int, you should be dereferencing a
(* int).  How do you get from the one to the other?  By casting it,
naturally.

  (defun moose-to-int (moose)
    (deref (cast moose (* int))))

DEREF, CAST, and INT are all in the SB-ALIEN package of course, but if
you're writing code that uses Alien, you really want to be working in
a package the uses SB-ALIEN so you can see the content for the package
qualifications.

--

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | Free Mumia Abu-Jamal! |
     ,--'    _,'   | Abolish the racist    |
    /       /      | death penalty!        |
   (   -.  |       `-----------------------'
   |     ) |                               
  (`-.  '--.)                              
   `. )----'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Geir Tj|rhom | 8 Aug 2005 15:35
Picon
Picon
Favicon

SPARC compiler bug?

I wonder if I've come across a bug in the compiler for the Solaris/SPARC
version of SBCL. Given the macro TEST below, the expression (TEST 1000)
generates a type error from inside the code generator, but (TEST 500)
works fine.

I've tried it on SBCL 0.9.0 on Solaris. SBCL for x86 and PPC seem to
handle the macro, but the time required to compile the expression rises
rapidly with larger N values.

Is the Solaris version being maintained, BTW? I've gotten the impression
that almost all development takes place on the Linux/x86 version.

(defmacro test (n)
  `(let ((v (make-array ,n :element-type '(unsigned-byte 8))))
     ,(let (forms)
        (dotimes (i n `(list , <at> forms))
          (push `(dpb (aref v ,i) (byte 8 0) 0) forms)))))

--
Geir Tjørhom
geirtj <at> idi.ntnu.no

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
Permalink | Reply | 2 comments |
headers
Christophe Rhodes | 8 Aug 2005 16:05
Picon
Picon
Favicon

Re: SPARC compiler bug?

Geir Tj|rhom <geirtj <at> idi.ntnu.no> writes:

> I wonder if I've come across a bug in the compiler for the Solaris/SPARC
> version of SBCL. Given the macro TEST below, the expression (TEST 1000)
> generates a type error from inside the code generator, but (TEST 500)
> works fine.
>
> I've tried it on SBCL 0.9.0 on Solaris. SBCL for x86 and PPC seem to
> handle the macro, but the time required to compile the expression rises
> rapidly with larger N values.

There is almost certainly an O(N^(1+\delta)) algorithm, if not more,
in the implementation of SBCL's compiler, which would explain growth
of compilation times in this way.

> Is the Solaris version being maintained, BTW? I've gotten the impression
> that almost all development takes place on the Linux/x86 version.

It is being maintained, in the sense that we check that it builds and
passes (most) tests; we occasionally release binary versions; and we
treat bug reports as bugs.  Because available manpower is slight, I at
least tend to focus in development, as opposed to maintenance, on
things that either directly benefit me or are interesting; I would
imagine a similar attitude from most part-time SBCL maintainers.
(And, as an additional health warning, I should note that even bug
fixes aren't guaranteed in any sense from volunteers...)

So.  In the meantime, what about the specifics?  Well, you should note
at the very least that code of the form (test <largenum>) is not
portable, because of CALL-ARGUMENTS-LIMIT; although SBCL is, erm,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Geir Tj|rhom | 9 Aug 2005 10:31
Picon
Picon
Favicon

Re: SPARC compiler bug?

On Mon, Aug 08, 2005 at 03:05:54PM +0100, Christophe Rhodes wrote:
> Having said that, as best I can see, the bug lies in the definition of
> the LIST VOP, or possibly in the :EXTRA argument to the PSEUDO-ATOMIC
> macro.  The problem is that the ADD instruction on the sparc takes
> either a register or a sign-extended 13-bit quantity, so attempts to
> allocate fixed amount of space taking more than 4100 (= 2^12 + 4, for
> technical reasons) bytes will fail.  So (test 512) will succeed, while
> (test 513) will fail to compile with the same error that you've
> observed.
>
> To fix this, PSEUDO-ATOMIC probably needs to be extended to take a
> temporary register argument in the case that the :EXTRA parameter is
> supplied, so that the addition can be performed safely by loading the
> extra quantity into a register if necessary.
>
> I hope that helps somewhat,

Thanks for the explanation. The problem (from my perspective) was that I
was thinking along the wrong track - I suspected it might have something
to do with the optimization of bit-manipulation instructions...

Please excuse me while I go and bang my head in the wall.

--
Geir Tjørhom
geirtj <at> idi.ntnu.no

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
(Continue reading)

Permalink | Reply | 0 comments |
headers
binghe | 15 Aug 2005 07:33
Picon

This code cannot compile with sbcl, but cmucl & clisp

(defstruct (type (:constructor allocate-type (serial-number kind tag
parameters =-name /=-name))
(:predicate type?))
(name nil :type symbol)
(serial-number nil :type integer)
(kind nil :type typekind :read-only t)
(tag nil :read-only t)
(parameters nil :type list :read-only t)
(=-name nil :type symbol)
(/=-name nil :type symbol)
(order-alist nil)
(range-set-encode nil :type symbol)
(range-set-decode nil :type symbol))

When I unlock the package :common-lisp and input them into sbcl:
This is SBCL 0.9.3.36, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

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.
* (sb-ext:unlock-package :common-lisp)

T
* (defstruct (type (:constructor allocate-type (serial-number kind tag
parameters =-name /=-name))
(:predicate type?))
(name nil :type symbol)
(serial-number nil :type integer)
(Continue reading)

Permalink | Reply | 2 comments |

Gmane