Re: patch for OS X 10.3 Panther G5

--- David Steuber <david <at> david-steuber.com> wrote:
> Vipul Periwal <vipulp <at> mail.nih.gov> writes:
> 
> > G5 works, but the bsd-sockets contrib module does not get built.  All
> > the other contrib modules did get built. The vector.pure.lisp test
> > crashes.
> 
> I've not gone through the tests.  It would certainly be nice to have
> them all work on the ppc-darwin arch.  I had all 13 contribs build.
> This is not to say that they all work, but:
> 
> $ sbcl
> This is SBCL 0.8.10, 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.
> * (require :sb-simple-streams)
> 
> ; loading system definition from
> ; #P"/Users/david/usr/lib/sbcl/systems/sb-posix.asd" into #<PACKAGE
> "ASDF2760">
> ; registering #<SYSTEM SB-POSIX {40C46069}> as SB-POSIX
> ; registering #<SYSTEM SB-POSIX-TESTS {481B9F61}> as SB-POSIX-TESTS
> ; loading system definition from
> ; #P"/Users/david/usr/lib/sbcl/systems/sb-bsd-sockets.asd" into
> ; #<PACKAGE "ASDF2900">

Re: patch for OS X 10.3 Panther G5

First, apologies for the blank mail.  

> 
> I find it interesting that neither likes to use the actual
> array-total-size-limit.  Maybe the mystery is resolved in the CLHS.
> 

Yes, the clhs says that array-total-size-limit is:
"The upper _exclusive_ bound on the array total size of an array."

So there is nothing wrong with the behaviour as described.

incidentally SBCL/CMUCL make array-total-size-limit as big as possible
given the requirement that it be a fixum
ie, (= array-total-size-limit most-positive-fixnum) => T

openmcl elects to make array-total-size-limit much smaller than
most-positive-fixnum for some reason.

	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 

-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE. 

Re: patch for OS X 10.3 Panther G5

David Steuber <david <at> david-steuber.com> writes:

> (let ((f (make-array '(4096 4096) :element-type 'double-float)))
>    (= (aref f 10 11) 99d0))

double-float is 8 bytes long.  4096 * 4096 * 8 is 128Mb.  Your dynamic
space is the difference between dynamic-0-space-end and
dynamic-0-space-start; unless you've changed it, this is #x7fff000, or
slightly less than 128Mb.  See src/compiler/ppc/parms.lisp

I would welcome a patch which enables sbcl on ppc to use larger
spaces, or even a patch which detects out-of-memory conditions and
prints a more informative message.  In the meantime, this endless 
speculation is not really adding information: please see
"How to report bugs effectively" by Simon Tatham at
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

-dan

--

-- 
"please make sure that the person is your friend before you confirm"

[Antonio.Leitao <at> evaluator.pt: Bug in SBCL]

Antonio Menezes Leitao wrote
  +>From what I could read on SBCL pages at sourceforge, you prefer bug
  +reports by email.  Se here is one.
You're correct, but even better than mailing bug reports to me
personally is to mail them to sbcl-help <at> lists.sf.net or
sbcl-devel <at> lists.sf.net, where many developers and other users can see
them immediately, and where they will be archived for later reference.
Thus, I have forwarded this message to sbcl-devel.

Thank you for the bug report; it does look like broken behavior. I'm
responsible for a fair amount of the nasty DEFSTRUCT-related code, so
I'm likely responsible for the problem, and I'm sorry it turned out to
be especially confusing to diagnose.

What version of SBCL were you using? I just tried the test in
sbcl-0.8.10 on OpenBSD/x86, and the problem seems not to exist there.

----- Forwarded message from Antonio Menezes Leitao <Antonio.Leitao <at> evaluator.pt> -----

Envelope-to: a0019176 <at> airmail.net
Delivery-date: Thu, 29 Apr 2004 17:09:24 -0500
To: wnewman <at> users.sourceforge.net
Subject: Bug in SBCL
From: Antonio Menezes Leitao <Antonio.Leitao <at> evaluator.pt>
Date: Thu, 29 Apr 2004 23:08:58 +0100
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
X-Spam-Score: 0.3 (/)
X-Spam-Report: Spam Filtering performed by sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001

Re: Re: [Sbcl-help] sb-thread programming tutorial?

On Thu, Apr 29, 2004 at 12:01:51PM -0400, David Steuber wrote:
> William Harold Newman <william.newman <at> airmail.net> writes:
> 
> > Things can be subject to this host-vs.-target distinction even if they
> > don't have to do with physical differences between host and target.
> > For example, if you change the definition of the PPRINT-LOGICAL-BLOCK
> > macro or the layout of the PACKAGE structure, then use SBCL to rebuild
> > SBCL, during the compilation the for-the-target macroexpansion of a
> > PPRINT-LOGICAL-BLOCK form and the for-the-target address offsets for
> > PACKAGE references will not be the same as those used in the host.
> 
> This all makes good sense.  The only question that leaves me with
> then is where is the make-package to go with the in-package?  I
> missed it with grep.

I'm not sure I understand the question; I find it confusing when you
you write "the in-package" when there's no earlier reference to
IN-PACKAGE in your text or the quoted text above. Perhaps you mean
"OK, I see various forms like (IN-PACKAGE "SB!VM") in the sources, but
I haven't been able to figure out where the corresponding packages
like SB!VM are created." If that's what you mean, try looking at
src/cold/set-up-cold-packages.lisp.

--

-- 
William Harold Newman <william.newman <at> airmail.net>
Clan McCthulhu.  In the end, there can be only one.
  -- Cael at Raytheon Systems Company
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C

-------------------------------------------------------

Re: [Antonio.Leitao <at> evaluator.pt: Bug in SBCL]

> From: Antonio Menezes Leitao <Antonio.Leitao <at> evaluator.pt>
[...]
> Here it goes (starting from a fresh SBCL session):
> 
> * (defparameter *f* #'identity)
> *F*
> * (defstruct foo
>     bar)
> FOO
> * (defun bug ()
>     (let ((foo-bar *f*))
>       (if (functionp foo-bar)
> 	(funcall foo-bar 1)
> 	nil)))
> ; in: LAMBDA NIL
> ;     (FUNCALL FOO-BAR 1)
> ; --> SB-C::%FUNCALL FOO-BAR TRULY-THE SB-KERNEL:%INSTANCE-REF 
> ; ==>
> ;   (THE FOO #:G5)
> ; 
> ; caught WARNING:
> ;   Asserted type FOO conflicts with derived type
> ;   (VALUES (INTEGER 1 1) &OPTIONAL).
> ; compilation unit finished
> ;   caught 1 WARNING condition
> 
> BUG
> * (bug)
> debugger invoked on a TYPE-ERROR in thread 7535: The value 1 is not of type FOO.

Patch: make-instances-obsolete skipping subclasses

The attached patch is, I think, a somewhat more elegant fix to the
make-instances-obsolete bug reported by Bruno Haible than the explicit
obsoletion of all subclasses proposed by Christophe Rhodes.

The problem of consecutive class redefinitions resulting in a single call
to update-i-f-r-c remains.

The bug is demonstrated by:

(defclass foo () (a))
(defclass bar (foo) ())
(defparameter *bar* (make-instance 'bar))
(defparameter *foo* nil)
(defmethod update-instance-for-redefined-class ((o bar) a d pl &key)
  (setf *foo* t))
(make-instances-obsolete 'foo)
(slot-boundp *bar* 'a)
*foo* ;; should be T, without the patch is NIL

Cheers,

 -- Nikodemus

Index: src/pcl/cache.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/pcl/cache.lisp,v
retrieving revision 1.30
diff -u -r1.30 cache.lisp
--- src/pcl/cache.lisp	1 Jun 2003 11:15:55 -0000	1.30
+++ src/pcl/cache.lisp	1 May 2004 18:49:33 -0000

Patch: fix for bogus LOOP warnings

The attached patch fixes bogus warnings for multiple value-returning
termination clauses, reported by Kalle Olavi Niemitalo on #lisp.

The bug is demonstatrated by:

(defvar *x* (list nil nil 1))
(defvar *y* (list nil 2 nil))
(loop thereis (pop *x*)
      thereis (pop *y*))

Cheers,

 -- Nikodemus

Index: src/code/loop.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/code/loop.lisp,v
retrieving revision 1.35
diff -u -r1.35 loop.lisp
--- src/code/loop.lisp	9 Nov 2003 13:35:31 -0000	1.35
+++ src/code/loop.lisp	1 May 2004 18:38:41 -0000
 <at>  <at>  -479,8 +479,8  <at>  <at> 
 (defvar *loop-after-epilogue*)
 
 ;;; the "culprit" responsible for supplying a final value from the
-;;; loop. This is so LOOP-EMIT-FINAL-VALUE can moan about multiple
-;;; return values being supplied.
+;;; loop. This is so LOOP-DISALLOW-AGGREGATE-BOOLEANS can moan about
+;;; disallowed anonymous collections.
 (defvar *loop-final-value-culprit*)

Re: patch for OS X 10.3 Panther G5

John Klein <jk271828 <at> yahoo.com> writes:

> I don't know if these changes are safe, because of all the issues
> raised in the x86 version of this file, like collisions with the malloc
> space and library spaces, so the following diff is merely informative.

Right, and I don't have a macos box to test on either.  Things you
might want to check include that load-1-foreign and suchlike still
work without mysterious heap trashing at next gc, etc.

> Still, I ran 1000 allocations and GCs of a 128 mb array and the lisp process
> survived fine.  I take it that dynamic-space-1 is the 2nd space of
> the stop and copy GC in cheneygc.c.

That's correct.

> Curiously, I still couldn't repeadly allocate/GC a larger array [256
> MB, still less than the 500MB dynamic space size] but this is
> because (gc :full t) didn't free the array, at least not inside a
> loop.  The following test function fails even though it allocates
> only 256MB per pass, and then tries to GC it.  Probably some known
> quirk of the GC.

The GC uses machine registers as roots, but doesn't know which
registers are 'live' at any given point.  It's possible (but I'm only
guessing here) that there's still a register pointing at the array
even after A has been NILled out.  You'd have to look at the
disassembly to be sure.

-dan

Re: patch for OS X 10.3 Panther G5

--- Daniel Barlow <dan <at> telent.net> wrote:
> 
> Right, and I don't have a macos box to test on either.  Things you
> might want to check include that load-1-foreign and suchlike still
> work without mysterious heap trashing at next gc, etc.

These changes seem to work nicely with 1) a toy load-1-foreign program
and 2) loading a fairly heavy Fortran and X11 graphics library.
It is possible to allocate ~450MB in an array, load libraries, 
check array for trashing, gc the array, call libraries, etc, without
encountering any problems (yet).   So this is good enough for my purposes,
but I don't know if it is proof enough for production [but see 1].  

> 
> The GC uses machine registers as roots, but doesn't know which
> registers are 'live' at any given point. 

I had figured it might be something like this, but I thought this was
only a concern with the conservative gc and the stack.  But GC always
cleans up array from the REPL, so it certainly some local phenomenon like this.

At any rate, thanks for pointing out the location of the memory limitation.
This lets me solve my problem of a limited array size.

============

[1] vmmap of an SBCL process on Darwin shows that user level object files are
loaded into low memory, and the system libraries seem to be loaded
above #x9000000, so if my very very naive understanding of the memory map