SourceForge needs a Lisp foundry

This message is sent to mailing lists of some Lispy SF projects.
Reply-To & Followup-To are set to the maxima list (since Maxima is the
most popular Lispy SF project).

WIBNI there were a Lisp SF foundry? <http://foundries.sourceforge.net/>
All we need is a volunteer to administer the foundry.
<http://sourceforge.net/docman/display_doc.php?docid=889&group_id=1#foundryrequest>

Any volunteers?

--

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Failure is not an option. It comes bundled with your Microsoft product.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

*STANDARD-READTABLE* disclosed in readtable functions

Some reader functions, such as SET-MACRO-DISPATCH-CHARACTER, make the
readtable default to *STANDARD-READTABLE* when the explicit readtable
argument is NIL.  The compiler detects the type error, but the REPL
doesn't (as the attached test shows), so *STANDARD-READTABLE* is
updated, making WITH-STANDARD-IO-SYNTAX behave in a non-standard
manner.  (Um, I think!)

Here's the test case:

    (defun read-percent (stream char)
      (declare (ignore char))
      `'(,(read stream t nil t)))

    (set-macro-character #\% #'read-percent t nil)

    (assert (not (eql '%foo (read-from-string "%foo"))))

    (with-standard-io-syntax
      (assert (eql '%foo (read-from-string "%foo"))))

The attached patch removes *STANDARD-READTABLE* as a default in these
cases.

Comments welcome--perhaps DECLARE would be more SBCL-ish than
CHECK-TYPE?

                --Tony

Index: reader.lisp

Changes to `ppc-linux-os.c' unecessary on latest libc6

Hi, I don't know if this has been noticed before, but it appears that the
incompatible changes to sys/ucontext.h for the PowerPC have been fixed in
GLIBC HEAD (.../powerpc/sys/ucontext.h revision 1.9, from 09/2003); this
makes the GLIBC23._STYLE_UCONTEXT conditionals on ppc-linux-os.c
unnecessary (at least when compiling with Debian's libc6-2.3.2.ds1-10,
which included that change on 11/2003).

fc

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: Changes to `ppc-linux-os.c' unecessary on latest libc6

fc <at> gnu.org writes:

> Hi, I don't know if this has been noticed before, but it appears that the
> incompatible changes to sys/ucontext.h for the PowerPC have been fixed in
> GLIBC HEAD (.../powerpc/sys/ucontext.h revision 1.9, from 09/2003); this
> makes the GLIBC23._STYLE_UCONTEXT conditionals on ppc-linux-os.c
> unnecessary (at least when compiling with Debian's libc6-2.3.2.ds1-10,
> which included that change on 11/2003).

Oh good.  I propose the following patch (but I can't test it,
unfortunately); if someone could review it, preferably with testing,
that would be good.

Index: tools-for-build/where-is-mcontext.c
===================================================================
RCS file: /cvsroot/sbcl/sbcl/tools-for-build/where-is-mcontext.c,v
retrieving revision 1.1
diff -u -r1.1 where-is-mcontext.c
--- tools-for-build/where-is-mcontext.c	3 Oct 2003 10:59:34 -0000	1.1
+++ tools-for-build/where-is-mcontext.c	2 Jan 2004 21:18:35 -0000
 <at>  <at>  -1,8 +1,9  <at>  <at> 
 /*
  * Find the offset of uc_mcontext in a ucontext structure, to enable
- * building on both (glibc-2.3.1 and earlier) and (glibc-2.3.2 and
- * later), after the glibc developers broke source code compatibility.
- * (see also Debian bugs #207806 and #209074)
+ * building on all three of [glibc-2.3.1 and earlier],
+ * [glibc-2.3.2-ds1-1 to glibc-2.3.2-ds1-9], and [glibc-2.3.2-ds10 and

Various brokennesses

So, firstly, as pointed out by Paul Dietz, my implementation of
modular multiplication on the x86 appears to be broken, in that (as of
sbcl-0.8.7.5):

  * (funcall
     (compile
      nil
      '(lambda (a)
         (declare (type (integer 177547470 226026978) a))
         (declare (optimize (speed 3) (space 0) (safety 0) (debug 0)
                            (compilation-speed 1)))
         (logand a (* a 438810))))
     215067723)
  ; in: LAMBDA (A)
  ;     (LOGAND A (* A 438810))
  ; 
  ; note: deleting unreachable code
  ; compilation unit finished
  ;   printed 1 note

  debugger invoked on a TYPE-ERROR in thread 2649:
    The value 215067723 is not of type (INTEGER 177547470 226026978).

[ this does not happen if the form is (logand #xffffffff (* a 438810));
  it _does_ happen if the form is (logand #xffff0000 (* a 438810)).
  Any ideas?  It looks like another "lying to the compiler" thing
  prompted by OPTIMIZE-MULTIPLY, but what? ]

So, given that I'm not in a great position for first-stone casting,
I'm not convinced that the latest GC refactoring is entirely

Re: Various brokennesses

Christophe Rhodes wrote:
>  running Paul Dietz' regular test suite
> yielded me most recently vast numbers of SIMPLE-ERRORs (probably
> segfaults of some kind) followed eventually by
> 
>   fatal error encountered in SBCL pid 26584:
>   no transport function for object 0x0c91d1ef (widetag 0x0)
>   LDB monitor
>   ldb>
> 
> It's possible of course that my hardware is bad, or that I'm running a
> broken tree, so could someone try to reproduce this?

This bug can be invoked by something as simple as:

* (loop repeat 100 do (compile nil '(lambda (a b) (+ a b))) do (sb-ext::gc :full t))
fatal error encountered in SBCL pid 2685:
no transport function for object 0x0901e11f (widetag 0x89)
There's no LDB in this build; exiting.

	Paul

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: Various brokennesses

I wrote:

> This bug can be invoked by something as simple as:
> 
> * (loop repeat 100 do (compile nil '(lambda (a b) (+ a b))) do 
> (sb-ext::gc :full t))
> fatal error encountered in SBCL pid 2685:
> no transport function for object 0x0901e11f (widetag 0x89)
> There's no LDB in this build; exiting.

Even simpler:

This is SBCL 0.8.7.5, 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.
* (loop repeat 2 do (compile nil '(lambda () nil)) do (sb-ext::gc :full t))
fatal error encountered in SBCL pid 2712:
GC invariant lost, file "gc-common.c", line 154
There's no LDB in this build; exiting.

	Paul

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.

Re: Various brokennesses

Or even:

This is SBCL 0.8.7.5, 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.
* (progn (compile nil '(lambda (a) (+ a a))) (sb-ext::gc :full t))
fatal error encountered in SBCL pid 2734:
no transport function for object 0x0900d1d7 (widetag 0x41)
There's no LDB in this build; exiting.

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

purify.c: #ifdef's removed around x86-specific code

Hi,

purify.c revision 1.34 apparently removed one `#if defined' too many around
line 1344.  The `setup_i386_stack_scav' call should be enclosed back in 
#if (defined(LISP_FEATURE_GENCGC) && defined(LISP_FEATURE_X86))/#endif, I
believe.

fc

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: Various brokennesses

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

> So, firstly, as pointed out by Paul Dietz, my implementation of
> modular multiplication on the x86 appears to be broken

It is. You need to choose the behavior of %LEA for overflow: should it
cut the result to 32 bits (in this case the definition and the type
deriver are wrong) or to pass as is (then the declared type is wrong
and %LEA-MOD32 is necessary)?

--

-- 
Regards,
Alexey Dejneka

"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click