From: Martin A. <ma...@at...> - 2001-02-14 12:25:01
Attachments:
patches-diff.gz
|
Hi, attached are some bugfixes: - a fix for BUG 34 (concerning byte-comp.lisp) - a fix for accessing a missing slot (slots.lisp) try (defclass a () ()) (setf (slot-value (make-instance 'a) 'b) 1) - when you tweaked the compiler output, the output (lines) became a bit longer, so some messages were not printed out completely [test case: (declaim (ftype (function (t) symbol) f1)) (defun f1 (x) (the integer 1)) ] the fix for this involved setting *compiler-error-print-lines* to a value greater than 5 (set to 7 ...) BTW, what is BUG 80 about? Was it the "info db" thing, that has been fixed by some earlier patches? Cheers, Martin -- Martin Atzmueller <ma...@at...> |
From: larryl <la...@br...> - 2007-10-25 18:50:50
|
Hi, I have a few patches that I would like to have someone saying "scratch 'em" or "polish 'em". The first is just cosmetic changes, that I think are welcome ? http://qqq.no-ip.org/sbcl/kosmetik.patch Apply on cvs checkout (it is based on sbcl-1.0.10.55). The second is an patch that remove all defvar usage in load-fasl-group. The purpose of this patch is that the big-compiler-lock is removed. This patch is still only for x86, in target-load.lisp load-code isn't fixed yet for #!-x86. http://qqq.no-ip.org/sbcl/fasl-load-nodefvar.patch Apply on cvs checkout (it is based on sbcl-1.0.10.55). An example that utilizes the patch above is this parallel fasl-load in sbcl-build patch: http://qqq.no-ip.org/sbcl/multi-fasl-load.patch Apply this patch after applying the fasl-load-nodefvar patch. Also, if you have time for some questions: In current sbcl, If you remove *free-fop-tables*, and just let fasloader always use *current-fop-table*. In that case I cannot produce an test-case that will fail, ie *free-fop-tables* seems to be unused. I see the need for *free-fop-tables* when in an fasl file you are loading another fasl-file, but I can't trigger something to go wrong. An hint for making a test case for this would be welcome. thanks alot, and best regards /larry liimatainen |
From: Juho S. <js...@ik...> - 2007-10-26 01:56:33
|
larryl <la...@br...> writes: > Hi, > I have a few patches that I would like to have someone saying "scratch > 'em" or "polish 'em". > > The first is just cosmetic changes, that I think are welcome ? > http://qqq.no-ip.org/sbcl/kosmetik.patch > Apply on cvs checkout (it is based on sbcl-1.0.10.55). Yeah, that looks mostly good. Though since I just browsed through the diff in less I'm not quite sure of whether the changes to set-up-cold-packages.lisp were indentation only, or whether there were some actual changes in there. In general it's fine to fix funny indentation of code that's being changed, but I would prefer not doing big whitespace-only commits for that many lines. > The second is an patch that remove all defvar usage in > load-fasl-group. The purpose of this patch is that the > big-compiler-lock is removed. This patch is still only for x86, in > target-load.lisp load-code isn't fixed yet for #!-x86. > > http://qqq.no-ip.org/sbcl/fasl-load-nodefvar.patch > Apply on cvs checkout (it is based on sbcl-1.0.10.55). Hmm... It seems to me that the monolihic load-fasl-group isn't exactly a maintenance improvement over the old version. Is there some benefit to this approach over just making sure that all the special variables are thread-locally bound in the loader? It also seems pretty likely that there will be a lot of places where common effects from fasl-loading are thread-unsafe, but where we're currently protected by the big compiler lock (e.g. writes to the infodb). Not really a reason to not make fasl-loading threadsafe, but something to be aware of. > An example that utilizes the patch above is this parallel fasl-load > in sbcl-build patch: > http://qqq.no-ip.org/sbcl/multi-fasl-load.patch > Apply this patch after applying the fasl-load-nodefvar patch. Interesting. Does that actually have any effect on build performance? I would've expected fasl loading to take up a fairly small proportion of the build time. > Also, if you have time for some questions: In current sbcl, If you > remove *free-fop-tables*, and just let fasloader always use > *current-fop-table*. In that case I cannot produce an test-case that > will fail, ie *free-fop-tables* seems to be unused. > > I see the need for *free-fop-tables* when in an fasl file you are > loading another fasl-file, but I can't trigger something to go wrong. > > An hint for making a test case for this would be welcome. ;; a.lisp (when t (catch 'x (load (compile-file "b.lisp")))) ;; b.lisp (throw 'x nil) ;; repl (load (compile-file "a.lisp")) -- Juho Snellman |
From: William H. N. <wil...@ai...> - 2001-02-14 14:24:55
|
On Wed, Feb 14, 2001 at 02:13:13PM +0100, Martin Atzmueller wrote: > attached are some bugfixes: > - a fix for BUG 34 (concerning byte-comp.lisp) > - a fix for accessing a missing slot (slots.lisp) > try > (defclass a () ()) > (setf (slot-value (make-instance 'a) 'b) 1) OK, thank you. I should be able to get to them in the next few days. > - when you tweaked the compiler output, the output (lines) > became a bit longer, so some messages were not printed out > completely > [test case: > (declaim (ftype (function (t) symbol) f1)) > (defun f1 (x) > (the integer 1)) > ] > the fix for this involved setting *compiler-error-print-lines* > to a value greater than 5 (set to 7 ...) OK, but as long as I'm changing the defaults, I'll boost them even higher. I've been using (setf sb-c::*compiler-error-print-level* 5) (setf sb-c::*compiler-error-print-length* 10) (setf sb-c::*compiler-error-print-lines* 12) in my .sbclrc for a while, and this seems to work OK. Since I'd guess that 70+% of users run SBCL under Emacs, and almost all of the rest of the users will have some sort of windowing system which will let them scroll back through output, I think it's better to sometimes produce 200% as much output as people want rather than 50% as much output as people want. I've also been thinking about how to allow users to override these defaults, but I'm not sure what's the best way to do that. > BTW, what is BUG 80 about? Was it the "info db" thing, that has been > fixed by some earlier patches? I'm embarrassed to admit that even though I wrote this only two weeks ago, and even though DTC didn't write many messages on cmucl-imp that day, it's not quite clear to me now what I was thinking about. I think maybe I was disturbed by the way that he said that just flushing the cache would cause bogus values to be exposed. Anyway, yes, the patches you submitted earlier seem to've fixed the problems with updating function INFO data, so I'll delete bug 80 from the file. (And I'll try to make clearer bug writeups in the future..) -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2001-02-18 17:20:57
|
On Wed, Feb 14, 2001 at 08:23:41AM -0600, I wrote: > On Wed, Feb 14, 2001 at 02:13:13PM +0100, Martin Atzmueller wrote: > > attached are some bugfixes: > > - a fix for BUG 34 (concerning byte-comp.lisp) > > - a fix for accessing a missing slot (slots.lisp) > > try > > (defclass a () ()) > > (setf (slot-value (make-instance 'a) 'b) 1) > > OK, thank you. I should be able to get to them in the next few days. They're now in sbcl-0.6.10.18 in CVS. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |