Kevin Rosenberg <kevin@...> writes:
> I realize that mips/mipsel are not commonly used platforms for
> SBCL. If there are ideas on fixing this, I'll be glad to help as well
> as the Debian Project Leader who has a convertible mips/mipsel system.
> Alternately, so as to not hold up the progress of SBCL from Debian
> unstable to Debian testing on x86, powerpc, and sparc, I can ask the
> Debian ftpmasters to remove the SBCL mips/mipsel from the archive.
At a guess, these build failures are probably indicative of a backend
bug: somewhere, there isn't sufficient waiting for results to arrive
in memory or in registers. Fixing this, if I'm right, will probably
involve finding people with time, detailed knowledge of the mips
platform, and motivation. (However, I'm not ruling out something
simpler: maybe we're treading on a newly-placed library space, or
something; look at /proc/<pid>/maps for emacs, and look for suspicious
overlaps with the spaces in src/compiler/mips/vm.lisp).
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)

"Paul F. Dietz" <dietz@...> writes:
> Christophe Rhodes wrote:
>
>> All of these are definitely suboptimal from a user-experience point
>> of view. However, what are the requirements on an implementation?
>
> These are not ANSI spec violations, as far as I can tell.
>
> However, they are similar to a bug (involving LAMBDA) you've already
> fixed.
Yeah. I can't imagine these bugs are hard to fix either.
I'm glad that you seem to think that an implementation has latitude to
print `(,foo) as (SB-IMPL::BACKQ-LIST FOO) or whatever, because
otherwise this, in conjunction with the ability to pick apart
backquoted expressions with list operations, would make things really
hard.
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)

Andreas Fuchs wrote:
> This seems to work, and it is reasonably fast:
>
> 0.025 seconds of real time
> 0.005963 seconds of user run time
> 0.008231 seconds of system run time
> 0 page faults and
> 200,552 bytes consed.
>
> significantly better than the 20 second timing that I posted about
> before. Also, I don't feel ashamed of the code in interface.lisp any
> more, so that's a bonus. Please try this patch and tell me if the
> timings improved:
Thanks a lot for the patch. It works, and while it's a bit slower than
in 0.8.10 this is not a problem, at least not for me (it's slower by
less than a factor of two).
Regards,
Carlos
>

Andreas Fuchs <asf@...> writes:
> +;;; XXX: We are automatically freeing foreign memory. This breaks if
> +;;; there are pointers to the alien object held by C code.
> +;;;
> +;;; XXX: We must never create two objects that point to the same
> +;;; alien. When we do, and one loses all references, the alien
> +;;; will be FREEd.
XXX: (as Dan Barlow pointed out when I suggested this implementation
to him one time) We must ensure that we cons enough in Lisp code
that we do enough GCs to free up foreign memory: if calls to
stat() are in otherwise consing-free code, the foreign memory
will never be freed.
What happens if you provide an automatically-generated specialized
converter from alien to class (or indeed struct, if the CLOS
fully-generalized class indirection is costing too much)? I'd guess
that the excessive consing comes from generic alien code rather than
from constructing one lisp-land object, no matter how many layers of
indirection it has.
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)