Re: Missing docs.

On Thu, Jul 31, 2008 at 10:16 PM, Robin Lee Powell
<rlpowell <at> digitalkingdom.org> wrote:
>
> I'm trying to get some CLOCC/Port stuff working with SBCL, and I've
> discovered quite a few things missing from the manual.  None of
> sb-simple-streams is documented at all, and almost nothing of sb-sys
> is either.
>
> Is there some way I can generate some of this locally or something?

A bunch of those symbols are dead (I'll commit a patch to clean up
those later today).

A bunch of them aren't really something users are supposed to mess
with, unless they really know what they're doing. (Like %PRIMITIVE,
*INTERRUPTS-ENABLED*, etc.) thse should be IMO moved elsewhere.

A bunch of them should be documented properly in the manual -- but
most of them already have docstrings, so that is not a terrible
ordeal. Some of these should be moved to SB-EXT (and some maybe to
SB-ALIEN.)

(dolist (x (sort (loop for s being each external-symbols in :sb-sys
collect s) #'string<))
  (when (or (boundp x) (fboundp x) (find-class x nil) (sb-int:info
:type :kind x))
    (write-line
"--------------------------------------------------------------------------")
    (describe x)))

Re: lisp optimization

On Wed, Apr 9, 2008 at 5:49 PM, Martin Rubey <martin.rubey <at> univie.ac.at> wrote:

> I believe I just realised that
>
> (* x y)
>
> is *exactly* as fast in sbcl as
>
> (* (the integer x) (the integer y))
>
> i.e., there is no point at all declaring integers, except of course, if for
> some reason sbcl can prove that x and y are in fact fixnums.
>
> Is that correct?
>
> I guess the same actually holds for
>
> (+ (the integer x) 1)
>
> doesn't it? (or is there a faster way to increment a bignum by one?)
>
> In case the answers to the above are "yes", is that a principal impossibility,
> or just because noone implemented something better (in sbcl)?

Sorry for the late answer, but...

Yes and no. If there isn't sufficient information to do something
better, calls to arithmentic functions tend to end up as calls to
their generic versions.

Re: Compiler bug?

On Wed, Jan 9, 2008 at 4:10 AM, Bob Felts <wrf3 <at> pair.com> wrote:
> This short program, which is about as small as have been able to make
> it and still demonstrate the problem, hangs SBCL.  I'm running SBCL
> 1.0.13.17-x86-darwin on Leopard 10.5.1; although this has been a
> problem with the last several releases, even before I upgraded to
> Leopard.
>
> (defun bug ( )
>   (labels ((foo (upper-limit step)
>             (let ((n (truncate (/ upper-limit step))))
>               (/ (* n (1+ n) step) 2))))
>     (let* ((a (foo 999 3))
>           (b (foo 999 5))
>           (c (foo 999 15)))
>       (- (+ a b) c))))
>
> I'm a rank novice when it comes to playing around in the debugger, but
> it looks like the compiler is stuck in SB-KERNEL::SIMPLIFY-UNIONS.

Not stuck per se, just spending aeons there. Instead of waiting to see
if it finished before heat death of the universe, this should help.

...and people with more then passing acquitance of SBCL's type system
will hopefully point out if I got this wrong.)

(in-package :sb-c)

;;; Take a list of types and return a canonical type specifier,
;;; combining any MEMBER types together. If both positive and negative
;;; MEMBER types are present they are converted to a float type.

sbcl 1.0.18 build on OS X fails at ppc-assem.S

Hello All,

I am new to this list, and am posting here because I have been 
trying to build sbcl 1.0.17/18 using the macports (BSD-based) 
build system for OS X, without a lot of success.

Hardware/build environemnt details as follows: machine is a PPC 
G5 1.6 GHz uniproc with 2 GB/RAM, running OS X Leopard 10.5.4. 
Development trees installed are Xcode 3.1 and macports 1.6.0. 
Compilers used been gcc 4.0.1 (Xcode and macports versions) and 
4.2.4 (macports).  The terms that I'm running from are the bash 
that comes with OS X 10.5.4, and the xterm that ships with 
Xquartz 2.2.3 - (xorg-server 1.3.0-apple21).

The paired bootstrap/source tarballs used so far have been sbcl 
1.0.17/0.9.15 and 1.0.18/1.0.2.

I clean up the previous attempts between builds.

I have discussed the problem with the macports maintainer for 
sbcl (Greg Wright), who has referred me here.

The problem is that the build chokes on the file 
<sbcl-dist>/src/runtime/ppc-assem.S. Compiler output flags both 
globals.h and ppc-assem.S as containing junk characters.

Looking at the code in emacs, I can't see anything that looks 
obviously wrong, such as control characters, although there is a 
"^L" sequence at line 391 that looks a bit odd (although I must 
confess that I know nothing at all about assembly language). I 

callbacks into SBCL from C/C++

Hi;

I am trying to resurrect some SBCL Lisp software that uses a C/C++
library which requires callbacks to implement its functionality.

With earlier, pre 1.x releases of SBCL, I had great success using a
"callback-sbcl.lisp" file, the header of which is reproduced here:

--- cut here ---

;;; callback.lisp -- callback support for CMUCL/x86

;;; This is a SBCL port of Helmut Heller's code from:
;;; http://article.gmane.org/gmane.lisp.cmucl.devel/2472
;;;
;;; Note that this is a straightforward `query-replace-regexp'-based
;;; port as I do not know the SBCL internals at all.
;;;
;;; Damien Diederen <diederen <at> swing.be>

--- cut here ---

Specifically, I used the file's:

(1) "defcallback" macro to define both the C/C++ trampoline function
and Lisp forms I wanted called

(2) "callback" macro to find the address of the trampoline function to
pass to the C/C++ functions that saved the C/C++ function pointers

Re: callbacks into SBCL from C/C++

On Thu, Aug 7, 2008 at 3:46 PM, John Morrison <morrison <at> mak.com> wrote:

> ;;; This is a SBCL port of Helmut Heller's code from:
> ;;; http://article.gmane.org/gmane.lisp.cmucl.devel/2472
> ;;;
> ;;; Note that this is a straightforward `query-replace-regexp'-based
> ;;; port as I do not know the SBCL internals at all.
> ;;;
> ;;; Damien Diederen <diederen <at> swing.be>

> Before I dive in and try and either modernize callback-sbcl.lisp or
> write my own (ugh), what is the Right Way to go about this?

Code based on this lives in SBCL already, but in unexported form.

 SB-ALIEN::DEFCALLBACK, etc.

grep -r "def.*callback" src/

shows most points of interest.

Cheers,

 -- Nikodemus

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

About the unused variables warnings

       Hello,

I just noticed that when compiling something like this:

(defmethod ((var1 class1) var2)
  nil)

SBCL will warn me that var2 is unused, but nothing about var1. I
currently don't have other Lisp implementations handy.

Comments ?

--

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier
Music (Jazz) site: http://www.didierverna.com

EPITA/LRDE, 14-16 rue Voltaire, 94276 Le Kremlin-Bicêtre, France
Tel. +33 (0)1 44 08 01 85       Fax. +33 (0)1 53 14 59 22

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: About the unused variables warnings

Didier Verna <didier <at> lrde.epita.fr> writes:

>        Hello,
>
> I just noticed that when compiling something like this:
>
> (defmethod ((var1 class1) var2)
>   nil)
>
> SBCL will warn me that var2 is unused, but nothing about var1. I
> currently don't have other Lisp implementations handy.

It doesn't signal any style-warning for me, neither for VAR1 nor for
VAR2---which makes sense as VAR1 and VAR2 _are_ used (albeit implicitly
during dispatching.) This makes especially sense for EQL specializers.

  -T.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: About the unused variables warnings

On 21.08.2008, at 10:46, Didier Verna wrote:
>
>      Hello,
>
> I just noticed that when compiling something like this:
>
> (defmethod ((var1 class1) var2)
> nil)
>
> SBCL will warn me that var2 is unused, but nothing about var1. I
> currently don't have other Lisp implementations handy.
>
> Comments ?

var1 is used for method dispatch.

Cheers,

Rudi

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Re: About the unused variables warnings

"Tobias C. Rittweiler" <tcr <at> freebits.de> wrote:

> Didier Verna <didier <at> lrde.epita.fr> writes:
>
>>        Hello,
>>
>> I just noticed that when compiling something like this:
>>
>> (defmethod ((var1 class1) var2)
>>   nil)
>>
>> SBCL will warn me that var2 is unused, but nothing about var1. I
>> currently don't have other Lisp implementations handy.
>
> It doesn't signal any style-warning for me, neither for VAR1 nor for
> VAR2---which makes sense as VAR1 and VAR2 _are_ used (albeit implicitly
> during dispatching.) This makes especially sense for EQL specializers.

  You're right. It was actually an /optional/ argument, as in:

(defmethod ((var1 class1) &optional var2)
   nil)

that triggered the warning. I just forgot that the argument was
optional; so everything is fine.

--

-- 
Resistance is futile. You will be jazzimilated.

Scientific site:   http://www.lrde.epita.fr/~didier