http://permalink.gmane.org/gmane.lisp.steel-bank.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16752 <pre>Hi, * (lisp-implementation-version) "1.0.57.15-35f68f4" * (defun foo (x) (declare (optimize (space 2)) (type (integer 12417236377505266230 12417274239874990070) x)) (logand 8459622733968096971 x)) FOO * (foo 12417237222845306758) 11836165733894624898 ;; &lt;-- incorrect * (logand 8459622733968096971 12417237222845306758) 2612793697039849090 * (defun bar (x) (declare (type (integer 22965360520649903105 22965361070405717069) x)) (lognand 6936474818856893141 x)) BAR * (bar 22965361070405716988) #&lt;unknown immediate object, lowtag=#b1, widetag=#x41 {FFFFFFEFFD4D3D41}&gt; (More random-integer testing.) </pre> Eric Marsden 2012-05-23T12:01:08 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16751 <pre> ...stuff... Amusingly, it turned out that the TYPEP consing came from NLX value cells as well. Rudimentary escape analysis is enough to sort this out. I already committed the SIGNAL improvements, but would much appreciate it if someone could find the time to review this one before I commit it. I keep having the feeling I'm missing something obvious. Non-loadable patch attached, apply on top of 9bc5da72887b15eb83500e16f05c3e42835476a3 or later. With that setup, the example above should run without consing. Cheers,  -- Nikodemus ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Sbcl-devel mailing list Sbcl-devel&lt; at &gt;lis</pre> Nikodemus Siivola 2012-05-22T19:43:14 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16750 <pre> There appears to be no cc in your path. Only sb-concurrency should fail the tests build. </pre> Stas Boukarev 2012-05-22T14:59:11 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16749 <pre>Sorry for not catching this earlier, but there seem to be build issues on Windows in this release. The build concludes with some failed contribs (notably bsd-sockets and posix), but I haven't had time to bisect or track down the root cause yet. The complete build log is here: https://elliottslaughter.com/files/build-sbcl-1.0.57.txt If I get time, I'll try to look into this more later. On Sun, May 13, 2012 at 7:02 PM, Juho Snellman &lt;jsnell&lt; at &gt;iki.fi&gt; wrote: </pre> Elliott Slaughter 2012-05-22T07:19:19 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16748 <pre> ERROR was actually already smart about this -- it didn't do till it knew it had to invoke the debugger, which was actually the reason I ended up doing this change: I wanted to have the hint available when doing (handler-bind ((error #'invoke-debugger)) ...) Anyways, I was too optimistic. It's still pretty consy: - Value cell for the nlx (GO :AGAIN) is heap allocated. Should be safe to elide for exists from DX lambdas, though, and that one is a DX lambda... - SIGNAL conses a lot -- most of it needlessly when *BREAK-ON-SIGNALS* is NIL. Conditionalizing the RESTART-CASE on that helps. After those (TYPEP CONDITION (CAR HANDLER)) seems to be the last source of consing in SIGNAL, aside from the &amp;REST list allocation which doesn't matter here. Attached loadable patch does these things. Not non-consing yet, but a lot better: Evaluation took: 0.247 seconds of real time 0.244681 seconds of total run time (0.243418 user, 0.001263 system) [ Run times consist of 0.007 seconds GC time, and 0.238 seco</pre> Nikodemus Siivola 2012-05-21T20:16:44 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16747 <pre> Still in my "queue", which looks more like a spread every day... What's the pull-url? I'll try to get at least some of these in this month. Cheers, -- nikodemus ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Nikodemus Siivola 2012-05-21T18:49:41 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16746 <pre>I would expect so, yes. ...let me know if it doesn't. Ns Sent from my phone - apologies for substandard spelling and formatting. On May 21, 2012 4:49 PM, "Tobias C Rittweiler" &lt;tcr&lt; at &gt;freebits.de&gt; wrote: ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________ Sbcl-devel mailing list Sbcl-devel&lt; at &gt;lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sbcl-devel </pre> Nikodemus Siivola 2012-05-21T16:00:24 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16745 <pre>Nikodemus, any news on this? i used to keep on rebasing my changes but it starts to feel as wasted time... the most recent version, modulo the last conflicts, is available here: http://dwim.hu/gitweb/gitweb.cgi?p=sbcl;a=summary </pre> Attila Lendvai 2012-05-21T15:57:34 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16744 <pre>In article &lt;E1SWLPN-0000Yo-Kv&lt; at &gt;sfs-ml-1.v29.ch3.sourceforge.com&gt;, "Nikodemus Siivola" &lt;demoss&lt; at &gt;users.sourceforge.net&gt; wrote: Thank you! Does it mean that (define-condition once-again () ()) (prog ((+once-again+ (make-condition 'once-again)) (n 1000000)) :again (handler-bind ((once-again #'(lambda (c) (declare (ignore c)) (go :again)))) (unless (zerop (decf n)) (error +once-again+)))) now runs in nearly constant space? T ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Tobias C Rittweiler 2012-05-21T13:44:19 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16743 <pre> +1 Cheers, -- nikodemus ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Nikodemus Siivola 2012-05-17T07:19:23 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16742 <pre> I'm always annoyed by messages like: Implicitly creating new generic function FOO. scrolling by in my slime window. WTF is FOO? Well, the problem is that FOO is usually in the then-current package and so the package identifier isn't printed out. The following patch causes the package name to be printed in the STYLE-WARNING. Any objections to seeing this in the tree post-freeze? thanks, Cyrus diff --git a/src/code/condition.lisp b/src/code/condition.lisp index 3e7e84e..d0b7013 100644 --- a/src/code/condition.lisp +++ b/src/code/condition.lisp &lt; at &gt;&lt; at &gt; -1004,8 +1004,9 &lt; at &gt;&lt; at &gt; (define-condition implicit-generic-function-warning (style-warning) ((name :initarg :name :reader implicit-generic-function-name)) (:report (lambda (condition stream) - (format stream "~&lt; at &gt;&lt;Implicitly creating new generic function ~S.~:&lt; at &gt;&gt;" - (implicit-generic-function-name condition))))) + (let ((*package* (find-package :keyword))) + (format stream "~&lt; at &gt;&lt;Implicitly creating new generic function ~S.~:&lt; at &gt;&gt;" + </pre> Cyrus Harmon 2012-05-17T04:34:10 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16741 <pre> For me, SBCL warns me when it removes unreachable code. This usually turns up bugs in my typing or logic or paren-grouping. I guess I was expecting to see some indication that dead code was removed, too. If I have dead code, why would I want I there? And, if I do want it there, I'd like to know if it isn't. But, maybe I'm being too optimistic. Maybe everything would be warning me everywhere... like the "else" clause of an IF when expanded from an WHEN macro. </pre> Patrick Stein 2012-05-16T12:23:46 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16740 <pre>[...] [...] [...] In both cases, the code depends on undefined behaviour (I can only imagine that you had functions that simply read variables without using their value in an attempt to trigger unbound variable conditions). CL's default level for all optimization levels is 1; for SBCL, that level means that we don't crash on undefined behaviour, and instead signal conditions. In these cases, the potential error has been optimised away: there's no crash to replace with a condition anymore. I, and many other users I suppose, would be peeved it SBCL disabled simple optimisations like dead code elimination just to consistently signal a condition in the face of undefined behaviour. Optimisations in SBCL guarantee that you'll get the result and side effects your code defines, and, when safety isn't 0, conditions instead of random behaviour if runtime errors would happen. There aren't many potential optimisations one can perform if they wish to signal exactly the same conditions as a naïve interpreter. Paul Khu</pre> Paul Khuong 2012-05-16T07:37:33 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16739 <pre> I see what you mean by using the return of the result. I stand corrected. A while ago I was writing an assembler for an embedded architecture where common lisp read the opcodes in the form of sexps (as actual common lisp). If I used symbols (in the assembler's DSL, but also in the lisp variable namespace) that weren't defined, I'd handle the unbound-variable conditions and poke them into a symbol table for later assignment to addresses when the opcodes were actually assembled. It simplified not having to write more structure around the opcode list to predefine the variables or walk over the opcode list try and pick out the symbols that were variables in the assembly DSL (which was hard). I'm not claiming that I chose a good way to do that project, but it was a place where I had to modify SBCL's safety to 3 to get the right behavior. Up until then, it didn't even occurr to me that SBCL's safety wasn't already 3. Later, -pete ------------------------------------------------------------------------</pre> Peter Keller 2012-05-16T04:27:14 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16738 <pre> If you were to sped up the computation that would imply that you care about the result. And handler-bind would only slow things down. (defun does-not-absorb () (let ((ret 'no-error)) (list (handler-case (let ((y 0)) (/ y)) (division-by-zero (c) (setf ret c))) ret))) By return the result, the division is not elided and the error is signalled. I can't even contrive any reasons for this to ever be useful. safety 1 in SBCL is very reasonable, unless your code is contorted. </pre> Stas Boukarev 2012-05-16T03:43:01 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16737 <pre> If one were writing a video game where one didn't want to check for a division by zero to speed up the computation (just handling the condition in a handler-bind when it happens) that would be a plenty good reason to want the divide-by-zero condition. I've often been surprised by the times that SBCL's default safety settings don't cause certain conditions, like unbound-variable conditions and such, to be signaled at the appropriate times. I know now to set saftey to 3 to get safe code, but it was a surprising road to find that out. I figured I would just get safe code by default. Thank you. -pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ __________________</pre> Peter Keller 2012-05-16T03:35:45 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16736 <pre> It doesn't have side-effects, except for the error, which i don't think anyone would desire. If you want to check everything, run with (safety 3), which is the definition of safe code by CLHS. </pre> Stas Boukarev 2012-05-16T03:02:49 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16735 <pre> So, there's no accounting for the fact that this division might have side-effects? … Patrick On May 15, 2012, at 9:52 PM, Stas Boukarev wrote: ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ </pre> Patrick Stein 2012-05-16T03:00:06 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16734 <pre> Yes, this is intended, the compiler elides division operations when the result is not used, and when safety is not high enough, even if it's divided by zero. Add (declare (optimize safety )) to get the error. </pre> Stas Boukarev 2012-05-16T02:52:26 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16733 <pre> In looking over the errors generated by a cl-test-grid run, I looked into the trivial-backtrace test that was failing. [1] I think that I've uncovered a subtle bug in the SBCL compiler. [1] http://cl-test-grid.appspot.com/blob?key=100025 I'm using almost-the-latest SBCL (1.0.55.0-abb03f9-dirty) compiled for 64-bit with threading on MacOSX Lion (10.7.3). This is the simplest I can seem to get the same problem to arise is this: (defun absorbs () (let ((ret 'no-error)) (handler-case (let ((y 0)) (/ y)) (division-by-zero (c) (setf ret c))) ret)) When that compiles, it gives no warnings. When invoked, it returns NO-ERROR. This, on the other hand, gives me a warning at compile time and returns an instance of the division-by-zero error when invoked. (defun throws () (let ((ret 'no-error)) (handler-case (let* ((y 0) (z (/ y))) z) (division-by-zero (c) (setf ret c))) </pre> Patrick Stein 2012-05-16T00:59:42 http://permalink.gmane.org/gmane.lisp.steel-bank.devel/16732 <pre>Forgot to CC the list. ---------- Forwarded message ---------- From: Nikodemus Siivola &lt;nikodemus&lt; at &gt;random-state.net&gt; Date: 14 May 2012 20:07 Subject: Re: [Sbcl-devel] Less world-locking in PCL To: Paul Khuong &lt;pvk&lt; at &gt;pvk.ca&gt; On 27 March 2012 11:22, Nikodemus Siivola &lt;nikodemus&lt; at &gt;random-state.net&gt; wrote: Well, it is part of my threading work now. :)  https://github.com/nikodemus/SBCL/tree/wip-clos-sans-compiler Above is current the work in progress tree -- not much there yet, but enough to show the basic idea. (Could not find my old tree, so this is what I've hacked up today -- hence not very far yet, and virtually untested.) Cheers,  -- nikodemus </pre> Nikodemus Siivola 2012-05-14T17:08:16 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.lisp.steel-bank.devel