00:03:37 fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has joined #sbcl 00:05:01 pkhuong: still around? 00:12:38 -!- fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has quit [Quit: Leaving.] 00:14:00 fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has joined #sbcl 00:14:45 fjl: ping 00:15:24 i'm the one who is seeing the floating point issue 00:16:02 i was sitting next to fe[nl]ix but didn't have an internet connection so i couldn't join the channel 00:17:13 so, what happens if you mask everything around cocoa calls? 00:18:52 the issue still occurs because cocoa sets the fp mask itself 00:18:59 here's a backtrace: http://paste.lisp.org/display/135666 00:20:04 the sbcl SIGFPE handler is invoked during the foreign call 00:21:04 your earlier comment was really insightful, a C program would crash if it didn't have a SIGFPE handler installed 00:21:43 i probably need to wire up the cocoa SIGFPE handler during foreign calls 00:21:55 this is really strange. trapping inexact is just really really strange. 00:22:42 does sbcl work without its SIGFPE handler installed? 00:23:15 probably. Is that an old OS X? 00:24:09 no, it's a very recent one 00:24:19 there's also https://bugs.launchpad.net/sbcl/+bug/1092993 00:25:51 some other people run into this when using libSDL, probably also due to Cocoa's FP magic 00:27:12 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 00:29:15 my best shot at a solution would be to add a flag to 'struct thread' that makes the fpe handler return immediately. i could then enable this around certain foreign calls. 00:32:01 you could try (sb-sys:ignore-interrupt sb-unix:sigfpe) 00:34:10 fjl: have you tried masking *everything* in with-float-traps-masked? 00:35:40 no, just :inexact 00:37:02 I wouldn't be surprised if darwin manages to misreport the exception, or we fail to read it correctly... Certainly much less surprised than by a legit inexact FP exception. 00:40:16 ok, i have tried now wrapping the foreign calls with 00:40:16 (defmacro without-sigfpe-handler (&body body) 00:40:16 `(unwind-protect 00:40:16 (progn 00:40:16 (sb-sys:ignore-interrupt sb-unix:sigfpe) 00:40:16 ,@body) 00:40:16 (sb-sys:enable-interrupt sb-unix:sigfpe #'sb-vm:sigfpe-handler :synchronous t))) 00:40:17 00:40:39 this makes the cocoa rendering code hang ;) 00:41:14 i'll try masking everything 00:45:05 masking everything works, so the error seems to be sbcl not reading it correctly 00:54:34 this solves my problem for now. would it make sense to investigate further to see what is causing this? 01:07:25 fjl: you could try to bsearch your way into figuring out which exception is actually being triggered. 01:09:11 fjl: the code is read C-side, so there isn't a lot of room for error on SBCL's end ;) 02:42:22 prxq_ [~mommer@mnhm-590c399a.pool.mediaWays.net] has joined #sbcl 02:46:36 -!- prxq [~mommer@mnhm-4d013b27.pool.mediaWays.net] has quit [Ping timeout: 276 seconds] 02:58:42 -!- fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has quit [Quit: Leaving.] 03:00:47 fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has joined #sbcl 03:24:30 -!- Thra11 [~thrall@45.77.125.91.dyn.plus.net] has quit [Quit: kthxbai] 03:33:15 -!- fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has quit [Quit: Leaving.] 03:34:25 fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has joined #sbcl 03:34:32 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 03:44:42 -!- fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has quit [Quit: Leaving.] 03:53:10 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 03:53:37 -!- prxq_ [~mommer@mnhm-590c399a.pool.mediaWays.net] has quit [*.net *.split] 03:53:37 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [*.net *.split] 03:53:37 -!- xymox [~xymox@unaffiliated/contempt] has quit [*.net *.split] 03:53:37 -!- pipping [~pipping@tchaikovsky.exherbo.org] has quit [*.net *.split] 03:53:37 -!- pkhuong [~pkhuong@gravelga.xen.prgmr.com] has quit [*.net *.split] 03:55:43 prxq_ [~mommer@mnhm-590c399a.pool.mediaWays.net] has joined #sbcl 03:55:43 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 03:55:43 xymox [~xymox@unaffiliated/contempt] has joined #sbcl 03:55:43 pipping [~pipping@tchaikovsky.exherbo.org] has joined #sbcl 03:55:43 pkhuong [~pkhuong@gravelga.xen.prgmr.com] has joined #sbcl 03:55:52 -!- xymox [~xymox@unaffiliated/contempt] has quit [Max SendQ exceeded] 03:56:30 xymox [lechuck@unaffiliated/contempt] has joined #sbcl 04:09:21 yacks [~yacks@180.151.36.169] has joined #sbcl 04:32:40 juiko [~user@186.173.198.158] has joined #sbcl 04:36:09 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 04:48:25 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:55:46 huangjs [~huangjs@114.91.233.191] has joined #sbcl 05:22:28 -!- huangjs [~huangjs@114.91.233.191] has quit [Quit: This computer has gone to sleep] 05:27:27 Tribal [tribal@fluttershy.is.best.pony.rcfreak0.com] has joined #sbcl 05:27:54 -!- juiko [~user@186.173.198.158] has quit [Remote host closed the connection] 05:40:51 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 05:55:13 -!- akovalen` [~user@95.73.216.27] has quit [Ping timeout: 248 seconds] 06:25:08 attila_lendvai [~attila_le@87.247.13.15] has joined #sbcl 06:25:08 -!- attila_lendvai [~attila_le@87.247.13.15] has quit [Changing host] 06:25:08 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:25:45 huangjs [~huangjs@199.180.254.36] has joined #sbcl 06:53:35 -!- huangjs [~huangjs@199.180.254.36] has quit [Quit: This computer has gone to sleep] 06:56:04 huangjs [~huangjs@199.180.254.36] has joined #sbcl 07:01:54 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:36:15 -!- prxq_ is now known as prxq 07:52:42 jarmond [~user@93-96-213-180.zone4.bethere.co.uk] has joined #sbcl 07:52:54 -!- yacks [~yacks@180.151.36.169] has quit [Ping timeout: 264 seconds] 07:57:25 yacks [~yacks@180.151.36.169] has joined #sbcl 08:23:00 -!- jarmond [~user@93-96-213-180.zone4.bethere.co.uk] has quit [Ping timeout: 248 seconds] 08:41:08 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 252 seconds] 08:46:47 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Linkinus - http://linkinus.com] 09:00:39 -!- cmm [~cmm@109.65.218.23] has quit [Ping timeout: 260 seconds] 09:01:10 cmm [~cmm@109.65.218.23] has joined #sbcl 09:13:37 -!- jdz [~jdz@85.254.212.34] has quit [Quit: Byebye.] 09:20:57 stassats [~stassats@wikipedia/stassats] has joined #sbcl 09:24:13 jdz [~jdz@85.254.212.34] has joined #sbcl 09:41:16 -!- jdz [~jdz@85.254.212.34] has quit [Quit: Byebye.] 09:45:05 jdz [~jdz@85.254.212.34] has joined #sbcl 09:47:27 -!- jdz [~jdz@85.254.212.34] has quit [Client Quit] 09:57:49 jdz [~jdz@85.254.212.34] has joined #sbcl 10:22:38 -!- pipping [~pipping@tchaikovsky.exherbo.org] has quit [Changing host] 10:22:38 pipping [~pipping@exherbo/developer/pipping] has joined #sbcl 10:25:28 jarmond [~user@host-137-205-183-065.cov.warwick.ac.uk] has joined #sbcl 10:37:55 akovalenko [~user@95.72.42.16] has joined #sbcl 10:39:15 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 10:56:47 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 255 seconds] 11:10:26 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:46:13 fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has joined #sbcl 11:48:16 -!- huangjs [~huangjs@199.180.254.36] has quit [Quit: This computer has gone to sleep] 11:48:55 huangjs [~huangjs@199.180.254.36] has joined #sbcl 11:50:16 -!- jarmond [~user@host-137-205-183-065.cov.warwick.ac.uk] has quit [Read error: Operation timed out] 12:02:08 -!- fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has quit [Quit: Leaving.] 12:02:55 -!- huangjs [~huangjs@199.180.254.36] has quit [Quit: This computer has gone to sleep] 12:08:19 i just spent half an hour chasing around a problem that drops SBCL into LDB 12:08:51 what problem? 12:08:58 turned out i managed to close *error-output* (by misuse of cl-log) 12:09:23 which made SBCL not able to report any errors 12:09:27 in a loop 12:09:48 recursively, that is 12:10:25 ccl did not exhibit this problem, probably because it ignores requests to close *error-output* (have not investigated, yet) 12:11:39 anyway, something probably can be done to make the situation a bit more troubleshoot-friendly 12:12:28 i don't know what can be done, except for preventing *error-output* from being closed 12:12:47 i was just thinking -- what are the cases when it makes sense to close it? 12:14:13 maybe warning when trying to close (and not closing) is the right thing to do? 12:14:18 but then if you bind *error-output* to something bad it'll still happen 12:15:07 yes, good point 12:15:37 but maybe allow to muck with *error-output*, but when an error strikes with it, switch to/open a new one sb-sys:*stderr* 12:22:34 when the trouble strikes with the rebound value 12:22:54 yes 12:23:13 sounds like a plan 12:27:07 hlavaty` [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 12:27:48 huangjs [~huangjs@199.180.254.36] has joined #sbcl 12:28:01 jarmond [~user@host-137-205-183-065.cov.warwick.ac.uk] has joined #sbcl 12:28:25 -!- jarmond [~user@host-137-205-183-065.cov.warwick.ac.uk] has left #sbcl 12:28:33 jarmond [~user@host-137-205-183-065.cov.warwick.ac.uk] has joined #sbcl 12:29:10 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 12:29:57 -!- hlavaty [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 276 seconds] 12:40:06 hlavaty [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 12:40:49 -!- hlavaty` [~user@friedrichstrasse.knowledgetools.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 12:40:53 -!- hlavaty [~user@friedrichstrasse.knowledgetools.de] has quit [Client Quit] 12:41:14 hlavaty [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 12:53:13 I asked yesterday, but it seems nobody was reading at that time, so asking again: any idea what could it mean if the lambda from SB-PCL::DEFAULT-SECONDARY-DISPATCH-FUNCTION shows up in sb-sprof results with a noticeable percentage? 13:00:04 where's the code? 13:00:48 angavrilov: I tried to answer but you'd left. I think it means that you're calling a lot of generic functions for which compute-applicable-methods isn't normal 13:02:29 a refinement: if you have slightly complicated inheritance in your system, for example some subclasses where superclasses are in different orders, then you might get that even if compute-applicable-methods is normal 13:03:06 something like (defclass a () ()) (defclass b () ()) (defclass c (a b) ()) (defclass d (b a) ()) (defmethod foo ((a a)) ...) (defmethod foo ((b b)) ...) 13:03:09 it'd be better to see the code instead of telepathic diagnostics 13:03:23 "the code" could be huge 13:03:48 whereas inspection of default-secondary-dispatch-function and its uses is local and relatively small 13:09:44 the caller: https://github.com/angavrilov/cl-linux-debug/blob/master/xmlisp/XMLisp.lisp#L2078 13:10:13 the types: https://github.com/angavrilov/cl-linux-debug/blob/master/data-info/types.lisp 13:11:17 you could try (setf sb-pcl::make-unordered-methods-emf t) to see a bit more about what might be going on 13:11:23 but print-object is a bit of a special case 13:11:27 profiling data: http://pastebin.com/raw.php?i=K9iWzpZF 13:12:58 there is certainly quite a bit of inheritance going on in the types involved 13:13:11 you mean classes? 13:15:41 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 13:16:17 the question is whether there is the kind of inheritance that can lead to objects which are of types A and B (classes specialized on in generic functions) but some are A first and B second, and some are B first and A second 13:16:25 I'm not going to read your code to discover that 13:16:37 but it would probably be straightforward to write something that introspects your classes 13:16:53 (if that's what is going on, setting the special variable that I failed to spell correctly above there would show up) 13:17:08 (setf sb-pcl::*make-unordered-methods-emf* t) 13:17:19 the case conventions look weird 13:17:36 fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has joined #sbcl 13:17:51 it is quite possible that there are some suboptimal inheritance patterns in those classes in types.lisp - there is a lot of complex multiple inheritance going on there 13:18:34 the XMLisp file is not mine, I just copied it from the original source 13:18:43 congratulations, now it's yours! :) 13:21:55 basically, what calls to default-s-d-f mean is "you defeated our attempts to optimize the clos dispatch protocol" 13:23:17 it is a bit weird that that's showing up on calls to print-object, though; does setting the special reveal anything? 13:24:00 i would imagine it's from XML::PRINT-SLOTS-AS-ATTRIBUTES 13:24:11 but without a call tree, i can't be sure 13:24:18 from the profiling info I'd understand it as calls from print-object 13:24:52 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 248 seconds] 13:25:17 yes, maybe. That's the information setting the special to t might give you 13:30:53 -!- huangjs [~huangjs@199.180.254.36] has quit [Quit: This computer has gone to sleep] 13:31:23 hm, it produced a package lock error when trying to set that, and setting the existing *show-...-calls* to t didn't produce anything (or I didn't look in the right place) 13:33:19 so I put trace on compute-applicable-methods, and it seems it's always (COMPUTE-APPLICABLE-METHODS # (NIL)) 13:34:19 ... with possible specializations on symbol/list/t 13:34:32 huangjs [~huangjs@199.180.254.36] has joined #sbcl 13:39:29 interesting 13:39:36 I wonder if that's nil's fault 13:40:47 yes, it might well be nil 13:41:35 (annoyingly, defining a method on NULL doesn't make it go away) 13:42:06 what about symbol/cons/t? 13:43:01 there are actually more specializations, but all traces seemed to be identical with (nil) args and choices symbol/list/t 13:43:03 give the man a cigar 13:43:25 if your method on LIST can be changed to CONS, dispatch might go faster 13:43:31 ok, must catch a plane. 13:43:33 good luck 13:46:41 hm, how would methods be ordered between list and null in case of nil? 13:46:58 post-specific first 13:47:02 -!- huangjs [~huangjs@199.180.254.36] has quit [Quit: This computer has gone to sleep] 13:54:08 huangjs [~huangjs@199.180.254.36] has joined #sbcl 13:56:03 hm, so I understand that the critical bit here is 'symbol'? 13:56:25 there is also similar XML-PRINTABLE-AS-SUBELEMENT-P with t/null/list, and that one appears to work without problems 13:56:45 (and after changing list to cons so does XML-PRINTABLE-AS-ATTRIBUTE-VALUE-P) 14:07:36 gko [~user@114-34-168-13.HINET-IP.hinet.net] has joined #sbcl 14:14:15 Vivitron [~Vivitron@12.53.196.74] has joined #sbcl 14:21:05 -!- Vivitron [~Vivitron@12.53.196.74] has quit [Ping timeout: 255 seconds] 14:21:58 Vivitron [~Vivitron@12.53.196.74] has joined #sbcl 14:32:19 Krystof, I understand 2.29 was not satisfying for 1.1.5. Will SBCL merge in 2.31? or do you have issues with it? 14:41:01 wbooze [~wbooze@xdsl-78-35-174-115.netcologne.de] has joined #sbcl 14:45:43 -!- yacks [~yacks@180.151.36.169] has quit [Quit: Leaving] 14:48:27 -!- jarmond [~user@host-137-205-183-065.cov.warwick.ac.uk] has quit [Read error: Operation timed out] 15:10:41 -!- huangjs [~huangjs@199.180.254.36] has quit [Quit: This computer has gone to sleep] 15:24:37 huangjs [~huangjs@199.180.254.36] has joined #sbcl 15:24:46 -!- Vivitron [~Vivitron@12.53.196.74] has quit [Quit: trivial-irc-0.0.4] 15:26:40 huangjs_ [~huangjs@114.91.233.191] has joined #sbcl 15:28:52 -!- huangjs [~huangjs@199.180.254.36] has quit [Ping timeout: 248 seconds] 16:27:32 -!- hlavaty [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 255 seconds] 16:27:51 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 16:35:06 hlavaty [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 16:36:20 -!- fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has quit [Quit: Leaving.] 16:42:19 fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has joined #sbcl 16:51:19 nyef [~nyef@c-76-119-183-159.hsd1.ma.comcast.net] has joined #sbcl 17:13:31 -!- huangjs_ [~huangjs@114.91.233.191] has quit [Quit: This computer has gone to sleep] 17:13:43 huangjs_ [~huangjs@199.180.254.36] has joined #sbcl 17:21:15 dioxirane [~OXO@unaffiliated/dioxirane] has joined #sbcl 17:21:50 -!- dioxirane [~OXO@unaffiliated/dioxirane] has left #sbcl 17:31:21 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Read error: Connection reset by peer] 17:57:02 yacks [~yacks@180.151.36.169] has joined #sbcl 18:17:24 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: dead] 18:21:24 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] 18:22:54 -!- fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has quit [Quit: Leaving.] 18:36:44 -!- yacks [~yacks@180.151.36.169] has quit [Quit: Leaving] 18:41:58 attila_lendvai [~attila_le@95.56.121.189] has joined #sbcl 18:41:58 -!- attila_lendvai [~attila_le@95.56.121.189] has quit [Changing host] 18:41:58 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 19:14:10 jarmond [~user@93-96-213-180.zone4.bethere.co.uk] has joined #sbcl 19:15:00 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 248 seconds] 19:31:43 fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has joined #sbcl 19:35:58 psilord [~psilord@23-25-144-218-static.hfc.comcastbusiness.net] has joined #sbcl 19:40:37 Fare [~fare@216.239.55.82] has joined #sbcl 19:46:06 -!- Fare [~fare@216.239.55.82] has quit [Ping timeout: 272 seconds] 19:46:09 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 20:00:19 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [Remote host closed the connection] 20:01:52 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl 20:16:33 -!- akovalenko [~user@95.72.42.16] has quit [Ping timeout: 248 seconds] 20:17:39 -!- jarmond [~user@93-96-213-180.zone4.bethere.co.uk] has quit [Ping timeout: 276 seconds] 20:24:47 -!- ASau [~user@46.115.45.64] has quit [Ping timeout: 260 seconds] 20:25:08 akovalenko [~user@195.18.46.21] has joined #sbcl 20:28:45 ASau [~user@46.115.45.64] has joined #sbcl 21:04:45 -!- whoops [~whoops@2a01:4f8:161:41e1::2] has quit [Quit: Farewell] 21:19:21 whoops [~whoops@2a01:4f8:161:41e1::2] has joined #sbcl 21:33:25 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 21:37:00 -!- prxq [~mommer@mnhm-590c399a.pool.mediaWays.net] has quit [Quit: Leaving] 21:55:16 -!- wbooze [~wbooze@xdsl-78-35-174-115.netcologne.de] has quit [Read error: Operation timed out] 22:03:48 -!- fjl [~fjl@cable-86-56-42-129.cust.telecolumbus.net] has quit [Quit: Leaving.] 22:06:57 -!- huangjs_ [~huangjs@199.180.254.36] has quit [Quit: This computer has gone to sleep] 22:36:14 Fare [~fare@216.239.55.82] has joined #sbcl 22:53:10 -!- nyef [~nyef@c-76-119-183-159.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 23:03:07 -!- stassats` [~stassats@wikipedia/stassats] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 23:16:38 Fare: we will probably test 2.31 and ask for feedback from our users 23:17:05 of course. Thanks a lot. 23:17:14 I am ready to make any desired change 23:17:55 I suppose the main issue is whether to enable or disable deferred-warnings checking by default. 23:18:48 LiamH [~none@vpn219118.nrl.navy.mil] has joined #sbcl 23:19:23 -!- Posterdati [~antani@host160-215-dynamic.11-87-r.retail.telecomitalia.it] has quit [Ping timeout: 240 seconds] 23:20:22 It seems rather poor that a non-portable set of warnings are considered to be fatal to compilation. 23:20:33 (But that's just a comment in general about the state of the world) 23:21:21 that's already true of many, many other warnings. 23:21:26 I know. 23:21:40 also true on gcc -Werror 23:21:47 yes, but that's not default 23:21:56 And don't use that in software you distribute. 23:22:15 I think it has value 23:22:22 -Werror is great for development, and terrible for distribution. 23:23:01 I have lost days (cumulatively) to asdf barfing on warning. 23:23:06 -!- psilord [~psilord@23-25-144-218-static.hfc.comcastbusiness.net] has quit [Quit: Leaving.] 23:23:40 The return value of compile-file is mostly to blame here, I think. 23:23:41 you mean just now, or in general? 23:23:53 in general. 23:23:57 it depends on whether the userbase should get used to software that "just compiles" or software that needs maintenance. I've lost days to barfing on warning, but also days on warnings revealing actual problems and not being fixed 23:24:02 so, maybe I've just lost days to bugs 23:24:26 anyway, I have to open the Teclo stand tomorrow morning, so good night 23:29:08 The big problem is that the set of warnings changes depending on what compiler the user is using. 23:29:46 Having a portable program written to the language spec ceases to be enough to get a working program. 23:30:19 foom: well, ideally a full warning should only be emitted for unportable or portably incorrect code. 23:31:41 Okay. I don't actually know how true that is today across CL implementations. 23:32:28 Fare now has a bunch of results of errors being caught that weren't before breaking compilation though, right? 23:32:39 s/errors/warnings/ 23:32:46 the forward reference to variables is arguably a program non-conformance issue 23:32:51 yes 23:35:21 *Is* it non-conforming to assume that an undefined variable is a global dynamic variable which just happens to be unbound so far? 23:37:42 there was a discussion either here on irc or on sbcl-devel some time (last year?) where it was argued sbcl could issue an error in that case 23:38:05 I don't remember the conclusion of that discussion, though, apart from the fact that this was not implemented 23:39:19 it would definitely break a lot of software that is currently getting warnings with asdf3. 23:40:44 ASau` [~user@46.115.66.67] has joined #sbcl 23:41:17 foom: yes, it is, and, iirc, some implementations assume they are global, non-dynamic, variables. (That would make sense for ACL's multithreaded dynamic binding implementation) 23:41:29 out of maintainers contacted, 17 fixed their issues, 3 said "not maintained anymore", 3 replied and are working on it, 28 didn't reply. 23:44:14 -!- ASau [~user@46.115.45.64] has quit [Ping timeout: 272 seconds] 23:46:58 okay, then, is it non-conforming to have a function which refers to a non-existent variable, even if you never execute that codepath? 23:49:13 That was the issue with my software. ASDF 3 was really telling me about a dead branch I had forgotten to prune. I thought that was a good thing. *shrug* 23:49:38 redline6561: as a *warning*? 23:50:04 pkhuong: (if always-true something *variable-i-deleted*) 23:50:28 Anyways, it *is* a good thing, for you the developer. 23:50:53 It's not a good thing for a user just trying to quickload your software. 23:51:04 Right. 23:53:06 -!- ASau` [~user@46.115.66.67] has quit [Ping timeout: 272 seconds]