You can subscribe to this list here.
2000 |
Jan
|
Feb
(1) |
Mar
(11) |
Apr
|
May
(16) |
Jun
(5) |
Jul
(5) |
Aug
(27) |
Sep
(25) |
Oct
(10) |
Nov
(40) |
Dec
(40) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(78) |
Feb
(80) |
Mar
(35) |
Apr
(73) |
May
(97) |
Jun
(44) |
Jul
(38) |
Aug
(43) |
Sep
(94) |
Oct
(124) |
Nov
(13) |
Dec
(79) |
2002 |
Jan
(144) |
Feb
(68) |
Mar
(128) |
Apr
(117) |
May
(90) |
Jun
(63) |
Jul
(42) |
Aug
(66) |
Sep
(97) |
Oct
(89) |
Nov
(92) |
Dec
(88) |
2003 |
Jan
(101) |
Feb
(127) |
Mar
(103) |
Apr
(145) |
May
(211) |
Jun
(143) |
Jul
(67) |
Aug
(184) |
Sep
(212) |
Oct
(117) |
Nov
(181) |
Dec
(86) |
2004 |
Jan
(92) |
Feb
(95) |
Mar
(163) |
Apr
(242) |
May
(202) |
Jun
(114) |
Jul
(94) |
Aug
(148) |
Sep
(163) |
Oct
(111) |
Nov
(95) |
Dec
(133) |
2005 |
Jan
(148) |
Feb
(102) |
Mar
(213) |
Apr
(178) |
May
(202) |
Jun
(199) |
Jul
(189) |
Aug
(309) |
Sep
(126) |
Oct
(128) |
Nov
(148) |
Dec
(156) |
2006 |
Jan
(222) |
Feb
(184) |
Mar
(152) |
Apr
(176) |
May
(189) |
Jun
(186) |
Jul
(75) |
Aug
(182) |
Sep
(103) |
Oct
(144) |
Nov
(265) |
Dec
(197) |
2007 |
Jan
(175) |
Feb
(202) |
Mar
(212) |
Apr
(309) |
May
(203) |
Jun
(162) |
Jul
(207) |
Aug
(156) |
Sep
(136) |
Oct
(99) |
Nov
(199) |
Dec
(201) |
2008 |
Jan
(190) |
Feb
(201) |
Mar
(180) |
Apr
(132) |
May
(204) |
Jun
(149) |
Jul
(125) |
Aug
(102) |
Sep
(86) |
Oct
(269) |
Nov
(167) |
Dec
(291) |
2009 |
Jan
(155) |
Feb
(119) |
Mar
(174) |
Apr
(186) |
May
(168) |
Jun
(217) |
Jul
(107) |
Aug
(134) |
Sep
(111) |
Oct
(184) |
Nov
(81) |
Dec
(140) |
2010 |
Jan
(91) |
Feb
(93) |
Mar
(132) |
Apr
(137) |
May
(86) |
Jun
(112) |
Jul
(38) |
Aug
(112) |
Sep
(111) |
Oct
(124) |
Nov
(52) |
Dec
(49) |
2011 |
Jan
(72) |
Feb
(115) |
Mar
(91) |
Apr
(38) |
May
(119) |
Jun
(129) |
Jul
(34) |
Aug
(140) |
Sep
(37) |
Oct
(58) |
Nov
(130) |
Dec
(59) |
2012 |
Jan
(20) |
Feb
(9) |
Mar
(41) |
Apr
(89) |
May
(69) |
Jun
(21) |
Jul
(14) |
Aug
(24) |
Sep
(52) |
Oct
(49) |
Nov
(45) |
Dec
(21) |
2013 |
Jan
(36) |
Feb
(53) |
Mar
(50) |
Apr
(142) |
May
(125) |
Jun
(120) |
Jul
(89) |
Aug
(82) |
Sep
(45) |
Oct
(104) |
Nov
(69) |
Dec
(40) |
2014 |
Jan
(28) |
Feb
(85) |
Mar
(99) |
Apr
(108) |
May
(92) |
Jun
(73) |
Jul
(49) |
Aug
(65) |
Sep
(48) |
Oct
(61) |
Nov
(34) |
Dec
(41) |
2015 |
Jan
(84) |
Feb
(46) |
Mar
(81) |
Apr
(83) |
May
(56) |
Jun
(27) |
Jul
(47) |
Aug
(30) |
Sep
(31) |
Oct
(57) |
Nov
(65) |
Dec
(90) |
2016 |
Jan
(52) |
Feb
(71) |
Mar
(76) |
Apr
(37) |
May
(43) |
Jun
(16) |
Jul
(17) |
Aug
(51) |
Sep
(48) |
Oct
(40) |
Nov
(21) |
Dec
(36) |
2017 |
Jan
(40) |
Feb
(57) |
Mar
(47) |
Apr
(45) |
May
(28) |
Jun
(30) |
Jul
(53) |
Aug
(71) |
Sep
(48) |
Oct
(58) |
Nov
(42) |
Dec
(49) |
2018 |
Jan
(94) |
Feb
(50) |
Mar
(59) |
Apr
(56) |
May
(27) |
Jun
(35) |
Jul
(32) |
Aug
(56) |
Sep
(35) |
Oct
(26) |
Nov
(35) |
Dec
(46) |
2019 |
Jan
(36) |
Feb
(53) |
Mar
(53) |
Apr
(37) |
May
(28) |
Jun
(12) |
Jul
(75) |
Aug
(81) |
Sep
(70) |
Oct
(46) |
Nov
(115) |
Dec
(124) |
2020 |
Jan
(65) |
Feb
(95) |
Mar
(289) |
Apr
(106) |
May
(165) |
Jun
(63) |
Jul
(129) |
Aug
(107) |
Sep
(86) |
Oct
(85) |
Nov
(94) |
Dec
(107) |
2021 |
Jan
(67) |
Feb
(103) |
Mar
(131) |
Apr
(98) |
May
(116) |
Jun
(85) |
Jul
(26) |
Aug
(133) |
Sep
(60) |
Oct
(130) |
Nov
(196) |
Dec
(120) |
2022 |
Jan
(155) |
Feb
(107) |
Mar
(123) |
Apr
(232) |
May
(194) |
Jun
(139) |
Jul
(82) |
Aug
(58) |
Sep
(49) |
Oct
(71) |
Nov
(69) |
Dec
(117) |
2023 |
Jan
(142) |
Feb
(64) |
Mar
(114) |
Apr
(34) |
May
(56) |
Jun
(113) |
Jul
(87) |
Aug
(99) |
Sep
(49) |
Oct
(97) |
Nov
(88) |
Dec
(131) |
2024 |
Jan
(158) |
Feb
(106) |
Mar
(181) |
Apr
(107) |
May
(87) |
Jun
(68) |
Jul
(125) |
Aug
(73) |
Sep
(56) |
Oct
|
Nov
|
Dec
|
From: Nikodemus S. <nik...@ra...> - 2006-08-26 07:59:18
|
mrd <md...@an...> writes: > I'm getting a Warning from SBCL during compilation of some methods, > that seems to be caused when the compiler is unable to delete certain > invalid code generated by CALL-NEXT-METHOD. The macro-expansion > below is taken from a portion of the expansion of DEFMETHOD that > contains a CALL-NEXT-METHOD. Can you please confirm that this happens with 0.9.16? The macroexpansions you show seem to result from an earlier version of invoke-effective-method-function then the one you quote, which was very recently changed to deal with exactly this issue. (Note the LET for the EMF.) Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: mrd <md...@an...> - 2006-08-25 23:33:56
|
I'm getting a Warning from SBCL during compilation of some methods, that seems to be caused when the compiler is unable to delete certain invalid code generated by CALL-NEXT-METHOD. The macro-expansion below is taken from a portion of the expansion of DEFMETHOD that contains a CALL-NEXT-METHOD. This code is present in every usage of DEFMETHOD with CALL-NEXT-METHOD inside. However, most of the time the bogus code in question is deleted before it is ever analyzed, because the TYPEP in question is determined statically NIL. Sometimes, it is not deleted, due to causes that I am still trying to figure out, and then SBCL emits Warnings which are fatal to the ASDF compile operation. When it does try to compile the bogus code, it ends up with: (SB-PCL::CLOS-SLOTS-REF SB-PCL::.SLOTS. (THE (OR FUNCTION SB-PCL::METHOD-CALL SB-PCL::FAST-METHOD-CALL) SB-PCL::.NEXT-METHOD-CALL.))) which is an SVREF with the index asserted to be something other than a FIXNUM. ;; portion of macro expansion: (COND ((TYPEP (SB-PCL::FAST-NARROWED-EMF SB-PCL::.NEXT-METHOD-CALL.) 'SB-PCL::FAST-METHOD-CALL) (FUNCALL (SB-PCL::FAST-METHOD-CALL-FUNCTION (SB-PCL::FAST-NARROWED-EMF SB-PCL::.NEXT-METHOD-CALL.)) (SB-PCL::FAST-METHOD-CALL-PV-CELL (SB-PCL::FAST-NARROWED-EMF SB-PCL::.NEXT-METHOD-CALL.)) (SB-PCL::FAST-METHOD-CALL-NEXT-METHOD-CALL (SB-PCL::FAST-NARROWED-EMF SB-PCL::.NEXT-METHOD-CALL.)) ACT)) ;; the TYPEP in question ((TYPEP (THE (OR FUNCTION SB-PCL::METHOD-CALL SB-PCL::FAST-METHOD-CALL) SB-PCL::.NEXT-METHOD-CALL.) 'FIXNUM) (LET* ((SB-PCL::.SLOTS. (SB-PCL::GET-SLOTS-OR-NIL ACT)) (SB-PCL::VALUE (WHEN SB-PCL::.SLOTS. ;; CLOS-SLOTS-REF is inlined to become SVREF (SB-PCL::CLOS-SLOTS-REF SB-PCL::.SLOTS. (THE (OR FUNCTION SB-PCL::METHOD-CALL SB-PCL::FAST-METHOD-CALL) SB-PCL::.NEXT-METHOD-CALL.))))) (IF (EQ SB-PCL::VALUE SB-PCL::+SLOT-UNBOUND+) (SB-PCL::SLOT-UNBOUND-INTERNAL ACT (SB-PCL::FAST-NARROWED-EMF SB-PCL::.NEXT-METHOD-CALL.)) SB-PCL::VALUE))) (T (ETYPECASE (SB-PCL::FAST-NARROWED-EMF SB-PCL::.NEXT-METHOD-CALL.) (SB-PCL::METHOD-CALL (SB-PCL::INVOKE-METHOD-CALL (SB-PCL::FAST-NARROWED-EMF SB-PCL::.NEXT-METHOD-CALL.) NIL ACT)) (FUNCTION (FUNCALL (THE FUNCTION (SB-PCL::FAST-NARROWED-EMF SB-PCL::.NEXT-METHOD-CALL.)) ACT))))) ;; portions of PCL responsible ;; boot.lisp: (defmacro invoke-effective-method-function (emf-form restp &rest required-args+rest-arg) (unless (constantp restp) (error "The RESTP argument is not constant.")) ;; FIXME: The RESTP handling here is confusing and maybe slightly ;; broken if RESTP evaluates to a non-self-evaluating form. E.g. if ;; (INVOKE-EFFECTIVE-METHOD-FUNCTION EMF '(ERROR "gotcha") ...) ;; then TRACE-EMF-CALL-CALL-INTERNAL might die on a gotcha error. (setq restp (constant-form-value restp)) (with-unique-names (emf) `(let ((,emf ,emf-form)) (trace-emf-call ,emf ,restp (list ,@required-args+rest-arg)) (cond ((typep ,emf 'fast-method-call) (invoke-fast-method-call ,emf ,@required-args+rest-arg)) ;; "What," you may wonder, "do these next two clauses do?" ;; In that case, you are not a PCL implementor, for they ;; considered this to be self-documenting.:-| Or CSR, for ;; that matter, since he can also figure it out by looking ;; at it without breaking stride. For the rest of us, ;; though: From what the code is doing with .SLOTS. and ;; whatnot, evidently it's implementing SLOT-VALUEish and ;; GET-SLOT-VALUEish things. Then we can reason backwards ;; and conclude that setting EMF to a FIXNUM is an ;; optimized way to represent these slot access operations. ,@(when (and (null restp) (= 1 (length required-args+rest-arg))) `(((typep ,emf 'fixnum) (let* ((.slots. (get-slots-or-nil ,(car required-args+rest-arg))) (value (when .slots. (clos-slots-ref .slots. ,emf)))) (if (eq value +slot-unbound+) (slot-unbound-internal ,(car required-args+rest-arg) ,emf) value))))) ,@(when (and (null restp) (= 2 (length required-args+rest-arg))) `(((typep ,emf 'fixnum) (let ((.new-value. ,(car required-args+rest-arg)) (.slots. (get-slots-or-nil ,(cadr required-args+rest-arg)))) (when .slots. (setf (clos-slots-ref .slots. ,emf) .new-value.)))))) ;; (In cmucl-2.4.8 there was a commented-out third ,@(WHEN ;; ...) clause here to handle SLOT-BOUNDish stuff. Since ;; there was no explanation and presumably the code is 10+ ;; years stale, I simply deleted it. -- WHN) (t (etypecase ,emf (method-call (invoke-method-call ,emf ,restp ,@required-args+rest-arg)) (function ,(if restp `(apply (the function ,emf) ,@required-args+rest-arg) `(funcall (the function ,emf) ,@required-args+rest-arg))))))))) (defmacro fast-narrowed-emf (emf) ;; INVOKE-EFFECTIVE-METHOD-FUNCTION has code in it to dispatch on ;; the possibility that EMF might be of type FIXNUM (as an optimized ;; representation of a slot accessor). But as far as I (WHN ;; 2002-06-11) can tell, it's impossible for such a representation ;; to end up as .NEXT-METHOD-CALL. By reassuring INVOKE-E-M-F that ;; when called from this context it needn't worry about the FIXNUM ;; case, we can keep those cases from being compiled, which is good ;; both because it saves bytes and because it avoids annoying type ;; mismatch compiler warnings. ;; ;; KLUDGE: In sbcl-0.7.4.29, the compiler's type system isn't smart ;; enough about NOT and intersection types to benefit from a (NOT ;; FIXNUM) declaration here. -- WHN 2002-06-12 (FIXME: maybe it is ;; now... -- CSR, 2003-06-07) ;; ;; FIXME: Might the FUNCTION type be omittable here, leaving only ;; METHOD-CALLs? Failing that, could this be documented somehow? ;; (It'd be nice if the types involved could be understood without ;; solving the halting problem.) `(the (or function method-call fast-method-call) ,emf)) ;; low.lisp: (declaim (inline clos-slots-ref (setf clos-slots-ref))) (declaim (ftype (function (simple-vector index) t) clos-slots-ref)) (defun clos-slots-ref (slots index) (svref slots index)) -- ;; Matthew Danish -- user: mrd domain: cmu.edu ;; OpenPGP public key: C24B6010 on keyring.debian.org |
From: mrd <md...@an...> - 2006-08-25 20:21:29
|
As far as I can tell, though I can't seem to find an exact reference for it in AMOP or CLHS, classes don't need to be finalized immediately. I believe the requirement is that they be finalized no later than creation of an instance of said class. Since classes can forward-reference supers, this seems to make sense. If you wish to invoke MOP functionality that requires a finalized class, you may want to precede it with a call to sb-mop:finalize-inheritance. -- ;; Matthew Danish -- user: mrd domain: cmu.edu ;; OpenPGP public key: C24B6010 on keyring.debian.org |
From: <cha...@un...> - 2006-08-25 20:12:46
|
On Fri, Aug 25, 2006 at 09:09:37AM -0700, Sean Champ wrote: > In a most recent build of SBCL, compiled on sources checked-out last night, > something is going wrong about class finalization. > > Notice that the following DEFCLASS call does not result in a finalized > class. [snip] I've read and reread your message but fail to see what is going wrong. Can you point me to the chapter and verse of MOP which is being violated? > One question, by the wayside: What would be an appropriate means by which to > add a check about this issue, into the SBCL tests? Why would we add a check for something which was deliberately introduced in a recent version of SBCL? See http://www.sbcl.org/news.html#0.9.15 . -- Brian Mastenbrook br...@ma... http://brian.mastenbrook.net/ |
From: Yaroslav K. <kav...@tu...> - 2006-08-25 18:01:54
|
Last version for non-ascii c-string's & pathnames (join in one patch) and couple derivative pathces: some changes for win32 and some offers for tests (for larger compatibility with win32). non-ascii & pathnames patch adapt for linux (need test on other platforms). Observations, offers and help are welcome! -- WBR, Yaroslav Kavenchuk. |
From: Sean C. <gi...@gm...> - 2006-08-25 16:10:42
|
In a most recent build of SBCL, compiled on sources checked-out last night, something is going wrong about class finalization. Notice that the following DEFCLASS call does not result in a finalized class. ------------------------------------- * (lisp-implementation-version) "0.9.15.48" * (defclass a () ((b))) #<STANDARD-CLASS A> * (describe 'a) A is an internal symbol in #<PACKAGE "COMMON-LISP-USER">. It names a class #<STANDARD-CLASS A>. #<STANDARD-CLASS A> is a class. It is an instance of STANDARD-CLASS. Its proper name is A. The direct superclasses are: (STANDARD-OBJECT), and the direct subclasses are: (). The class is not finalized; its class precedence list is: (A STANDARD-OBJECT SB-PCL::SLOT-OBJECT T). There are 0 methods specialized for this class. ------------------------------------- The non-finalization behavior can causes problems, in systems operating on class slots. That's how I came to notice it, in SBCL 0.9.15. ------------------------------------- * (sb-mop::class-slots (defclass b () ((c) (d)))) NIL ------------------------------------- It appears that something about the combination of a call to FIND-CLASS and a call to DESCRIBE *might* result in that the class will become finalized. The following demonstrates an instance of such -- but the example after this one does not. ------------------------------------- * (defclass c () ()) #<STANDARD-CLASS C> * (describe 'c) C is an internal symbol in #<PACKAGE "COMMON-LISP-USER">. It names a class #<STANDARD-CLASS C>. #<STANDARD-CLASS C> is a class. It is an instance of STANDARD-CLASS. Its proper name is C. The direct superclasses are: (STANDARD-OBJECT), and the direct subclasses are: (). The class is not finalized; its class precedence list is: (C STANDARD-OBJECT SB-PCL::SLOT-OBJECT T). There are 0 methods specialized for this class. * (find-class 'c) #<STANDARD-CLASS C> * (describe 'c) C is an internal symbol in #<PACKAGE "COMMON-LISP-USER">. It names a class #<STANDARD-CLASS C>. #<STANDARD-CLASS C> is a class. It is an instance of STANDARD-CLASS. Its proper name is C. The direct superclasses are: (STANDARD-OBJECT), and the direct subclasses are: (). The class is finalized; its class precedence list is: (C STANDARD-OBJECT SB-PCL::SLOT-OBJECT T). There are 0 methods specialized for this class. ------------------------------------- Maybe the following would be of any help in figuring out what's going wrong? Notice when the trace routine results in a message output -- during DESCRIBE. Furthermore, the class does not appear to become finalized in the process of this. ------------------------------------- * (trace sb-mop:effective-slot-definition-class) (SB-MOP:EFFECTIVE-SLOT-DEFINITION-CLASS) * (Defclass d () ((a))) #<STANDARD-CLASS D> * (find-class 'd) #<STANDARD-CLASS D> * (sb-mop::class-slots (find-class 'd)) NIL * (describe 'd) D is an internal symbol in #<PACKAGE "COMMON-LISP-USER">. It names a class #<STANDARD-CLASS D>. #<STANDARD-CLASS D> is a class. It is an instance of STANDARD-CLASS. Its proper name is D. 0: (SB-MOP:EFFECTIVE-SLOT-DEFINITION-CLASS #<STANDARD-CLASS D> :NAME A :INITFORM NIL :INITFUNCTION NIL :INITARGS NIL :ALLOCATION :INSTANCE :ALLOCATION-CLASS #<STANDARD-CLASS D> :TYPE T :CLASS #<STANDARD-CLASS D> :DOCUMENTATION NIL) 0: SB-MOP:EFFECTIVE-SLOT-DEFINITION-CLASS returned #<STANDARD-CLASS SB-MOP:STANDARD-EFFECTIVE-SLOT-DEFINITION> The direct superclasses are: (STANDARD-OBJECT), and the direct subclasses are: (). The class is not finalized; its class precedence list is: (D STANDARD-OBJECT SB-PCL::SLOT-OBJECT T). There are 0 methods specialized for this class. ------------------------------------- Calling the following, immediately after that, it then results in that the class becomes finalized: ------------------------------------- * (describe 'd) D is an internal symbol in #<PACKAGE "COMMON-LISP-USER">. It names a class #<STANDARD-CLASS D>. #<STANDARD-CLASS D> is a class. It is an instance of STANDARD-CLASS. Its proper name is D. The direct superclasses are: (STANDARD-OBJECT), and the direct subclasses are: (). The class is finalized; its class precedence list is: (D STANDARD-OBJECT SB-PCL::SLOT-OBJECT T). There are 0 methods specialized for this class. ------------------------------------- I'm not sure what's going wrong. I'm not much familiar with SB-PCL, though I hope to resolve that, in more. Here's one more note, for what it's worth. UPDATE-CLASS is being called, but with a NIL second argument. ------------------------------------- * (trace sb-pcl::update-class) (SB-PCL::UPDATE-CLASS) * (defclass e () ()) 0: (SB-PCL::UPDATE-CLASS #<STANDARD-CLASS E> NIL) 0: SB-PCL::UPDATE-CLASS returned NIL #<STANDARD-CLASS E> * (describe 'e) E is an internal symbol in #<PACKAGE "COMMON-LISP-USER">. It names a class #<STANDARD-CLASS E>. #<STANDARD-CLASS E> is a class. It is an instance of STANDARD-CLASS. Its proper name is E. 0: (SB-PCL::UPDATE-CLASS #<STANDARD-CLASS E> T) 0: SB-PCL::UPDATE-CLASS returned NIL The direct superclasses are: (STANDARD-OBJECT), and the direct subclasses are: (). The class is not finalized; its class precedence list is: (E STANDARD-OBJECT SB-PCL::SLOT-OBJECT T). There are 0 methods specialized for this class. ------------------------------------- I thought that this issue would bear mention. One question, by the wayside: What would be an appropriate means by which to add a check about this issue, into the SBCL tests? -- Sean Champ |
From: <sbc...@ao...> - 2006-08-25 15:06:14
|
<div align="left"><b><font size="5"> Want the degree but can’t find the time?</font></b><BR> <BR> WHAT A GREAT IDEA!<BR> We provide a concept that will allow anyone with sufficient work experience to obtain a fully verifiable University Degree.<BR> Bachelors, Masters or even a Doctorate.<BR> Think of it, within four to six weeks, you too could be a college graduate.<BR> Many people share the same frustration, they are all doing the work of the person that has the degree and the person that has the degree is getting all the money.<BR> Don’t you think that it is time you were paid fair compensation for the level of work you are already doing?<BR> This is your chance to finally make the right move and receive your due benefits.<BR> If you are like most people, you are more than qualified with your experience, but are lacking that prestigious piece of paper known as a diploma that is often the pass port to success.<BR> <b>CALL US TODAY AND GIVE YOUR WORK<BR> EXPERIENCE THE CHANCE TO EARN YOU<BR> THE HIGHER COMPENSATION YOU DESERVE!</b><BR> <font color="#FF0033" size="5">CALL NOW:</font><font color="#FF0033" size="7"><BR> <b>1-815-828-2222</b></font><BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> <BR> of wings like a small gh ost.</div> |
From: Marco M. <ma...@ac...> - 2006-08-25 13:36:10
|
Hello. Doing COMPILE-FILE on the attached file is failing with a "Control stack exhausted" error. I'm using Linux x86-64 with SBCL 0.9.15.14. Cheers, Marco |
From: Nikodemus S. <nik...@ra...> - 2006-08-24 10:20:05
|
Yaroslav Kavenchuk <kav...@je...> writes: > Expected failure: clos.impure.lisp / ((SETQ METHOD-PARAMETER) > SLOT-VALUE) > Unexpected success: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-356) > Unexpected success: debug.impure.lisp / (THROW NO-SUCH-TAG) > Unexpected success: debug.impure.lisp / (BACKTRACE MISC) > Expected failure: external-format.impure.lisp / (CHARACTER-DECODE-LARGE > FORCE-END-OF-FILE) > ok > //apparent success (reached end of run-tests.sh normally) > > It is normal at present? Yes. No-one has gotten around to marking the "Unexpected successes" as not unexpected anymore. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Yaroslav K. <kav...@je...> - 2006-08-24 07:58:41
|
colinux:~/src/sbcl/sbcl# uname -a Linux colinux 2.6.11-co-0.6.3-rc3 #4 Sat Nov 12 17:27:38 UTC 2005 i686 GNU/Linux colinux:~/src/sbcl/sbcl# /root/src/sbcl/sbcl/src/runtime/sbcl --version SBCL 0.9.15.48 colinux:~/src/sbcl/sbcl# cd tests && sh ./run-tests.sh ... Finished running tests. Status: Expected failure: clos.impure.lisp / ((SETQ METHOD-PARAMETER) SLOT-VALUE) Unexpected success: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-356) Unexpected success: debug.impure.lisp / (THROW NO-SUCH-TAG) Unexpected success: debug.impure.lisp / (BACKTRACE MISC) Expected failure: external-format.impure.lisp / (CHARACTER-DECODE-LARGE FORCE-END-OF-FILE) ok //apparent success (reached end of run-tests.sh normally) It is normal at present? Thanks! -- WBR, Yaroslav Kavenchuk. |
From: Juho S. <js...@ik...> - 2006-08-23 01:11:45
|
Shouldn't we be freezing for 0.9.16 at some point? -- Juho Snellman |
From: <me...@ho...> - 2006-08-22 20:07:16
|
The weak hash table patch has been updated. http://retes.hu/~mega/tmp/wht2.diff It is against 0.9.15.41. Changes since the previous one: - non-eq based weak hash tables are supported - ppc/gengc uses the same hash table code as x86/x86-64 [completely untested] - initial port to cheneygc [completely untested, may not even compile] - added some tests that work around conservatism when threads are available - hopefully reduced conservatism a tiny bit by tightening up bounds of loops around preserve_pointer (review this) At this point I'd normally say testers welcome, but since I haven't been able to compile sbcl with cheneygc or ppc/gengc (no luck with sourceforge compile farm) let's include in the welcome the adventerous souls willing to finish things up. Alternatively, if all else fails, get me access to a suitable box where a cheneygc sbcl normally compiles. Gabor |
From: Tim B. <tf...@tf...> - 2006-08-22 19:28:41
|
On 22 Aug 2006, at 10:31, Tim Bradshaw wrote: > I'll have a go at this, either this evening or this weekend. My OSX > development experience is pretty minimal though, so it may be that > someone > else will have much better ideas. Well, I had a poke around with shark and the answer seems to be that it spends an awful lot of time in routines with names like vm_map_region in the kernel. So my guess would be that mmap() sucks in OSX, or possibly that it sucks the way SBCL calls it. Disclaimer: I didn't read the shark manual (this is a Mac, you don't need manuals, right?), so take all this with much salt. --tim |
From: Sidney M. <si...@si...> - 2006-08-22 15:06:51
|
Nikodemus Siivola wrote, On 23/8/06 2:44 AM: > Probably. For stepping it depend on the policy the original function > was compiled with -- if it had a low debug policy, then inlining it > would actually improve the STEP-experience. > > ...but for backtraces and tracing, definitely. I noticed this in the policy section of the manual: "(max 1 speed space compilation-speed) If debug is also at least 2, then the code is partially steppable. If debug is 3, the code is fully steppable. See Single Stepping, for details. Fully steppable code take exponentially longer to compile in some cases, and is significantly larger and slower; for partially steppable code the speed and space penalties are significantly smaller." Notice what it says about exponentially longer compilation for steppable code. It didn't say that for inline code. I tried compiling with (debug 3) (speed 1) (space 2) to see if that would inhibit inlining and speed things up as you said in your previous message, and the compile took almost as long. (debug 3) (speed 1) took 193 seconds on my machine, while adding (space 2) resulted in 189 seconds. Then I tried (debug 2) (speed 1) (space 2) and it took 2.7 seconds. I removed the (space 2) from that and it took 0.97 seconds. Sidney Markowitz http://www.sidney.com |
From: James Y K. <fo...@fu...> - 2006-08-22 14:49:43
|
On Aug 22, 2006, at 10:38 AM, Sidney Markowitz wrote: > Nikodemus Siivola wrote, On 23/8/06 2:12 AM: >> There are some things that we could still do: for example making >> (> debug speed) inhibit inline-expansion might help with this. > > Wouldn't you want that anyway with high debug levels to allow tracing, > stepping, and backtraces to be more useful during debugging? Just in general, I really dislike the way all these things interact with each other. I think I'd prefer for each optimization quality to be pretty much distinct and each level have a well defined meaning. Having everything interdependent makes it really confusing to figure out what the different levels actually do. It makes sense to me that if you want to be able to get precise backtraces/etc, you should set the speed optimization level to a low number. James |
From: Nikodemus S. <nik...@ra...> - 2006-08-22 14:45:06
|
Sidney Markowitz <si...@si...> writes: > Nikodemus Siivola wrote, On 23/8/06 2:12 AM: >> There are some things that we could still do: for example making >> (> debug speed) inhibit inline-expansion might help with this. > > Wouldn't you want that anyway with high debug levels to allow tracing, > stepping, and backtraces to be more useful during debugging? Probably. For stepping it depend on the policy the original function was compiled with -- if it had a low debug policy, then inlining it would actually improve the STEP-experience. ...but for backtraces and tracing, definitely. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Sidney M. <si...@si...> - 2006-08-22 14:39:12
|
Nikodemus Siivola wrote, On 23/8/06 2:12 AM: > There are some things that we could still do: for example making > (> debug speed) inhibit inline-expansion might help with this. Wouldn't you want that anyway with high debug levels to allow tracing, stepping, and backtraces to be more useful during debugging? Sidney Markowitz http://www.sidney.com |
From: <mar...@gm...> - 2006-08-22 14:23:02
|
> > I remember that sbcl compilation was fast with previous versions of > > sbcl and clsql, but cannot check them right now. > > If you could check, that would be helpful. > I checked with sbcl-0.9.15.41 (the oldest sbcl I have) and it is still slow. I can't check with older releases of clsql cause I deleted from disk, and you can download only the latest from the official site. > > Does it happen on linux too? > > Yes. > > > ; compiling (DEFUN FIND-ALL ...) > > The time seems to be spent in this function, which has an optimize > declaration of (debug 3) (speed 1); (debug 3) in SBCL means munging > the code substantially, making it very large -- and the function is > large to begin with -- and there are algorithms in the compiler which > are asymptotically slower than O(n). > > For what it's worth, the compiler seems to spend its time in > SB-C::PROPAGATE-LIVE-TNS called from SB-C::LIFETIME-FLOW-ANALYSIS. I > don't know if this has changed recently, but I don't think it has. > > Christophe > |
From: Nikodemus S. <nik...@ra...> - 2006-08-22 14:13:54
|
Christophe Rhodes <cs...@ca...> writes: > The time seems to be spent in this function, which has an optimize > declaration of (debug 3) (speed 1); (debug 3) in SBCL means munging > the code substantially, making it very large -- and the function is > large to begin with -- and there are algorithms in the compiler which > are asymptotically slower than O(n). > > For what it's worth, the compiler seems to spend its time in > SB-C::PROPAGATE-LIVE-TNS called from SB-C::LIFETIME-FLOW-ANALYSIS. I > don't know if this has changed recently, but I don't think it has. In the sense that earlier (DEBUG 3) killed the ability of the compiler to reason about the code almost totally. Now it can make a better job of high-debug code, but it can obviously still take uncomfortably long. There are some things that we could still do: for example making (> debug speed) inhibit inline-expansion might help with this. Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Christophe R. <cs...@ca...> - 2006-08-22 14:06:28
|
"Marko Koci=E6" <mar...@gm...> writes: > I remember that sbcl compilation was fast with previous versions of > sbcl and clsql, but cannot check them right now. If you could check, that would be helpful. > Does it happen on linux too? Yes. > ; compiling (DEFUN FIND-ALL ...) The time seems to be spent in this function, which has an optimize declaration of (debug 3) (speed 1); (debug 3) in SBCL means munging the code substantially, making it very large -- and the function is large to begin with -- and there are algorithms in the compiler which are asymptotically slower than O(n). For what it's worth, the compiler seems to spend its time in SB-C::PROPAGATE-LIVE-TNS called from SB-C::LIFETIME-FLOW-ANALYSIS. I don't know if this has changed recently, but I don't think it has. Christophe |
From: <mar...@gm...> - 2006-08-22 13:53:43
|
> Indeed, people interested in this should probably speak up. If you're > reading sbcl-devel you're probably already qualified to have an > opinion:-) and if you have much experience using SBCL or other > software in a way which depends on this kind of policy, you're > probably more qualified than me... As a sbcl user, although not "power user" I don't think that fasl compatibility is all that important. As someone pointed out, it's easy for a developer to recompile, while user will not care. Branching to stable and develpment port will make things just worse, since there will be more overhead then now. It make sense only for a feature rich project with huge resources which is under heavy redesign to keep and maintain 2 or more branches. I'd more like to see thread under win32 and improved stability with some more docs then separate stable and devel version and fasl level compatibility. Also, internal api shouldn't be changed just for the sake of change, but pretty much as now, when the need arise. Just my 0.02 CSD Regards, Marko |
From: <mar...@gm...> - 2006-08-22 13:32:08
|
Hi all, I included both mailing list cause I'm not sure where the problem is. When trying to do (asdf:oos 'asdf:load-op :clsql) of clsql-3.6.6 using sbcl-0.9.15-44 on windows -xp it takes verry long time to compile. It seems that problem is in oodml.lisp file which takes 12min to compile. Clisp compiles it instantly. I remember that sbcl compilation was fast with previous versions of sbcl and clsql, but cannot check them right now. Does it happen on linux too? Here's the compilation log: ; file: c:\lisp\lib\clsql-3.6.6\sql\oodml.lisp ; in: DEFMETHOD UPDATE-SLOT-FROM-DB (STANDARD-DB-OBJECT T T) ; (FORMAT NIL CLSQL-SYS::SLOT-READER CLSQL-SYS::VALUE) ; ; note: unable to ; optimize ; due to type uncertainty: ; The second argument is a STRING, not a SIMPLE-STRING. ; (APPLY CLSQL-SYS::SLOT-READER (LIST CLSQL-SYS::VALUE)) ; --> MULTIPLE-VALUE-CALL ; ==> ; (SB-KERNEL:%COERCE-CALLABLE-TO-FUN CLSQL-SYS::SLOT-READER) ; ; note: unable to ; optimize away possible call to FDEFINITION at runtime ; due to type uncertainty: ; The first argument is a (OR FUNCTION SYMBOL), not a FUNCTION. ; compiling (DEFMETHOD KEY-VALUE-FROM-DB ...) ; file: c:\lisp\lib\clsql-3.6.6\sql\oodml.lisp ; in: DEFMETHOD KEY-VALUE-FROM-DB (T T T) ; (FORMAT NIL CLSQL-SYS::SLOT-READER CLSQL-SYS::VALUE) ; ; note: unable to ; optimize ; due to type uncertainty: ; The second argument is a STRING, not a SIMPLE-STRING. ; (APPLY CLSQL-SYS::SLOT-READER (LIST CLSQL-SYS::VALUE)) ; --> MULTIPLE-VALUE-CALL ; ==> ; (SB-KERNEL:%COERCE-CALLABLE-TO-FUN CLSQL-SYS::SLOT-READER) ; ; note: unable to ; optimize away possible call to FDEFINITION at runtime ; due to type uncertainty: ; The first argument is a (OR FUNCTION SYMBOL), not a FUNCTION. ; compiling (DEFUN DB-VALUE-FROM-SLOT ...) ; compiling (DEFUN CHECK-SLOT-TYPE ...) ; compiling (DEFMETHOD GET-SLOT-VALUES-FROM-VIEW ...) ; compiling (DEFMETHOD UPDATE-RECORD-FROM-SLOT ...) ; compiling (DEFMETHOD UPDATE-RECORD-FROM-SLOTS ...) ; compiling (DEFMETHOD UPDATE-RECORDS-FROM-INSTANCE ...) ; compiling (DEFMETHOD DELETE-INSTANCE-RECORDS ...) ; compiling (DEFMETHOD UPDATE-INSTANCE-FROM-RECORDS ...) ; compiling (DEFMETHOD UPDATE-SLOT-FROM-RECORD ...) ; compiling (DEFMETHOD UPDATE-SLOT-WITH-NULL ...) ; compiling (DEFVAR +NO-SLOT-VALUE+ ...) ; compiling (DEFSQL SQL-SLOT-VALUE ...) ; compiling (DEFSQL SQL-VIEW-CLASS ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFTYPE TINYINT ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFTYPE SMALLINT ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFTYPE MEDIUMINT ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFTYPE BIGINT ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFTYPE VARCHAR ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFTYPE UNIVERSAL-TIME ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFTYPE GENERALIZED-BOOLEAN ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-GET-TYPE-SPECIFIER ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD DATABASE-OUTPUT-SQL-AS-TYPE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFMETHOD READ-SQL-VALUE ...) ; compiling (DEFUN FAULT-JOIN-TARGET-SLOT ...) ; compiling (DEFVAR *DEFAULT-UPDATE-OBJECTS-MAX-LEN* ...) ; compiling (DEFUN UPDATE-OBJECTS-JOINS ...) ; compiling (DEFUN FAULT-JOIN-SLOT-RAW ...) ; compiling (DEFUN FAULT-JOIN-SLOT ...) ; compiling (DEFUN JOIN-QUALIFIER ...) ; compiling (DEFUN BUILD-OBJECTS ...) ; compiling (DEFUN FIND-ALL ...) ; compiling (DEFMETHOD INSTANCE-REFRESHED ...) ; compiling (DEFVAR *DEFAULT-CACHING* ...) ; compiling (DEFUN SELECT ...) ; compiling (DEFUN COMPUTE-RECORDS-CACHE-KEY ...) ; compiling (DEFUN RECORDS-CACHE-RESULTS ...) ; compiling (DEFUN (SETF RECORDS-CACHE-RESULTS) ...) ; compiling (DEFUN WRITE-INSTANCE-TO-STREAM ...) ; compiling (DEFUN READ-INSTANCE-FROM-STREAM ...) ; c:\lisp\cache\.fasls\sbcl-win32-x86-0.9.15.44\lisp\lib\clsql-3.6.6\sql\oodml.fasl written ; compilation finished in 0:12:23 Thanks, Marko |
From: Nikodemus S. <nik...@ra...> - 2006-08-22 13:16:26
|
The file at http://random-state.net/tmp/describe-symbol.lisp is a tentative new implementation for DESCRIBE-OBJECT (SYMBOL T), particularly with an eye towards C-c C-d d in Slime. It makes for quite different DESCRIBE output for symbols, but one that I at least find preferable. Objections to merging something along these lines? Examples: (defclass foo () ((bar :initarg :bar :accessor bar-of :documentation "Bar of foo")) (:documentation "Root class for the foo-hierarchy.")) (defvar *foo* (make-instance 'foo)) (setf (documentation (fdefinition 'print-object) t) "Called by the lisp printer.") (defmethod print-object :after ((foo (eql *foo*)) stream) "Saves the stream to *FOO* for no real reason, with multiple lines of documentation." (setf *foo* stream)) (describe 'foo) COMMON-LISP-USER::FOO [a symbol] Standard-Class: Direct superclasses: STANDARD-OBJECT Direct subclasses: FOO2 Direct slots: BAR (instance allocation) Initargs: :BAR Readers: BAR-OF Writers: (SETF BAR-OF) Documentation: Bar of foo Direct methods: Method: (SETF BAR-OF) (T FOO) automatically generated writer method Method: BAR-OF (FOO) automatically generated reader method Documentation: Root class for the foo-hierarchy. (describe 'print-object) COMMON-LISP:PRINT-OBJECT [a symbol] Generic function PRINT-OBJECT: Declared ftype: (FUNCTION (T T) *) Lambda-list: (OBJECT STREAM) Documentation: Called by the lisp printer. Method: :AFTER ((EQL #<FOO {AC8A269}>) T) Saves the stream to *FOO* for no real reason, with multiple lines of documentation. Method: (SWANK::CONNECTION T) Method: (SB-BSD-SOCKETS:SOCKET T) ...snip a ton of methods for posting... Method: (STANDARD-METHOD T) Method: (T T) (describe 'pathname) COMMON-LISP:PATHNAME [a symbol] Function PATHNAME: Declared ftype: (FUNCTION ((OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME FILE-STREAM)) (VALUES PATHNAME &OPTIONAL)) Lambda-list: (PATHSPEC) Documentation: Convert PATHSPEC (a pathname designator) into a pathname. Structure-Class: Direct superclasses: STRUCTURE-OBJECT Direct subclasses: LOGICAL-PATHNAME Direct slots: SB-KERNEL:HOST (instance allocation) SB-IMPL::DEVICE (instance allocation) DIRECTORY (instance allocation) SB-IMPL::NAME (instance allocation) TYPE (instance allocation) SB-IMPL::VERSION (instance allocation) Direct methods: Method: SWANK::MENU-CHOICES-FOR-PRESENTATION (PATHNAME) Method: SWANK-BACKEND:INSPECT-FOR-EMACS (PATHNAME T) Method: PRINT-OBJECT (PATHNAME T) Method: MAKE-LOAD-FORM (PATHNAME) Documentation: Pathname objects (describe 'car) COMMON-LISP:CAR [a symbol] Function CAR: Declared ftype: (FUNCTION (LIST) (VALUES T &OPTIONAL)) Lambda-list: (LIST) Documentation: Return the 1st object in a list. Function (SETF CAR): Defined ftype: (FUNCTION (T LIST) *) Lambda-list: (G35 G36) (describe 'if) COMMON-LISP:IF [a symbol] Special operator IF: Lambda-list: (TEST THEN &OPTIONAL ELSE) Documentation: If Predicate Then [Else] If Predicate evaluates to non-null, evaluate Then and returns its values, otherwise evaluate Else and return its values. Else defaults to NIL. Symbol-plist: SB-WALKER::WALKER-TEMPLATE -> SB-WALKER::WALK-IF Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Tim B. <tf...@tf...> - 2006-08-22 09:31:27
|
On Tue, August 22, 2006 9:50 am, Christophe Rhodes wrote: > > Is it possible to profile the startup, using ktrace and/or shark? I > don't have access to the screen on these macs, nor do I have any particular > privileges, so I can't do that myself. I'll have a go at this, either this evening or this weekend. My OSX development experience is pretty minimal though, so it may be that someone else will have much better ideas. --tim |
From: Christophe R. <cs...@ca...> - 2006-08-22 08:50:39
|
[ context: Tim asks about SBCL startup time on OS X. I've run some superficial tests of my own, and I think there's a question to answer. ] Tim Bradshaw <tf...@tf...> writes: > What I'm trying to do is convince myself that I can dump executables > rather than do some elaborate call-a-server thing. > > What I did (this is very primitive, I just want to demonstrate > possibility): > > ;;;; top-level.lisp > ;;; > > (defun top-level (&rest args) > (declare (ignorable args)) > (format t "~&top level~%") > (sb-unix:unix-exit 0)) > > and then compile & load this, and: > > (sb-ext:save-lisp-and-die "image" :executable t :toplevel #'toplevel > :purify t) > > don't know if purify is needed - it helped CMUCL I remember a long > time ago. I think purify might be part of the problem. It's not needed any more on platforms with the generational garbage collector, which these days includes the PowerPC, as instead there is a special pseudo-static generation (protected by a write barrier) in the generational space. Anyway. Data. Using your recipe, on a dual-code 2.7GHz PPC with 4Gb RAM running Linux, I get times (wall clock, which is in this case the same as user+sys) * with :purify -- 0.09s * without :purify -- 0.02s on a several-year-old PPC 7450 with 1Gb RAM running OS X, I get * with :purify -- 0.34s real 0.036s user 0.051s sys * without :purify -- 0.7s real 0.018s user 0.050s sys Even despite the difference in age and available memory and so on, this is silly. (All times after the disk has had a chance to warm its cache, obviously.) > fowey$ ./image >/dev/null > fowey$ time ./image >/dev/null > > real 0m0.377s > user 0m0.025s > sys 0m0.021s > fowey$ time ./image >/dev/null > > real 0m0.383s > user 0m0.025s > sys 0m0.022s > fowey$ time ./image >/dev/null > > real 0m0.375s > user 0m0.025s > sys 0m0.023s > > This is on a 1.5GHz PPC Mac Mini, with 1GB of memory, with nothing > really eating time and should have free mem. It's disk is something > out of a morris minor but it shouldn't be touching that more than > once, I hope. .3s is OK (it's comparable to java on the same box I > think), but .1 would be better. There's a pattern here: both when you and I do this on OS X, the real time is much, much more than user + system time, and I've verified to my satisfaction that this doesn't happen on Linux. There are real differences between SBCL on these platforms, mostly in the methods we use to ensure that the address spaces that we want to use are free, and in dynamic loading of libraries. I suppose it's possible that one of those is interfering with something that OS X would want to do. Is it possible to profile the startup, using ktrace and/or shark? I don't have access to the screen on these macs, nor do I have any particular privileges, so I can't do that myself. Any other ideas? Cheers, Christophe |