00:02:34 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 00:27:06 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 264 seconds] 00:45:26 -!- leoc` [~leoc.git@p57B9ACBF.dip.t-dialin.net] has quit [Ping timeout: 245 seconds] 00:53:07 danlentz_ [~danlentz@2601:c:3680:1c:2898:95af:1110:db9c] has joined #sbcl 00:55:26 danlentz__ [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has joined #sbcl 00:55:48 -!- danlentz [~danlentz@2601:c:3680:1c:a5c4:1635:d62b:c65b] has quit [Ping timeout: 256 seconds] 00:55:48 -!- danlentz__ is now known as danlentz 00:57:31 -!- danlentz_ [~danlentz@2601:c:3680:1c:2898:95af:1110:db9c] has quit [Ping timeout: 245 seconds] 01:59:02 -!- Qworkescence [~quad@unaffiliated/quadrescence] has left #sbcl 02:10:18 yacks [~yacks@180.151.36.169] has joined #sbcl 02:31:41 -!- milanj [~milanj_@82.117.199.26] has quit [Ping timeout: 245 seconds] 02:49:52 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 03:12:29 -!- Thra11 [~thrall@146.90.55.194] has quit [Ping timeout: 255 seconds] 04:12:23 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: mental blackout] 04:25:43 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 04:29:46 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 246 seconds] 05:00:06 -!- wbooze [~wbooze@xdsl-78-35-179-120.netcologne.de] has quit [Ping timeout: 264 seconds] 05:07:50 dioxirane [~user@unaffiliated/dioxirane] has joined #sbcl 05:31:57 -!- yacks [~yacks@180.151.36.169] has quit [Ping timeout: 276 seconds] 05:42:36 yacks [~yacks@180.151.36.169] has joined #sbcl 05:52:58 akovalen` [~user@77.51.0.89] has joined #sbcl 05:54:41 -!- akovalenko [~user@95.72.101.174] has quit [Ping timeout: 248 seconds] 05:54:56 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 06:15:54 Quadrescence [~quad@c-24-6-135-91.hsd1.ca.comcast.net] has joined #sbcl 06:15:54 -!- Quadrescence [~quad@c-24-6-135-91.hsd1.ca.comcast.net] has quit [Changing host] 06:15:54 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 06:26:09 sdemarre [~serge@91.176.241.92] has joined #sbcl 06:38:34 attila_lendvai [~attila_le@87.247.13.125] has joined #sbcl 06:38:34 -!- attila_lendvai [~attila_le@87.247.13.125] has quit [Changing host] 06:38:34 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:41:24 -!- sdemarre [~serge@91.176.241.92] has quit [Ping timeout: 248 seconds] 06:47:28 <|3b|> hmm, "Process inferior-lisp floating point exception (core dumped) 06:47:58 *|3b|* wonders if i did something bad with ffi or something 06:51:14 you monster 06:56:30 I had that too, when trying to use R from SBCL ... 06:56:54 -!- |3b| [foobar@cpe-72-177-66-41.austin.res.rr.com] has quit [Remote host closed the connection] 06:58:00 |3b| [foobar@cpe-72-177-66-41.austin.res.rr.com] has joined #sbcl 06:59:42 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:44:03 prxq [~mommer@mnhm-5f75d07d.pool.mediaWays.net] has joined #sbcl 07:56:34 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving...] 07:58:21 dioxirane_ [~user@unaffiliated/dioxirane] has joined #sbcl 08:02:00 -!- dioxirane [~user@unaffiliated/dioxirane] has quit [Ping timeout: 264 seconds] 08:08:48 -!- kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has quit [Remote host closed the connection] 08:12:53 kanru [~kanru@118-163-10-190.HINET-IP.hinet.net] has joined #sbcl 08:17:48 *|3b|* will assume it was just improperly installed opengl/drivers and ignore it for now... 08:40:22 -!- dioxirane_ [~user@unaffiliated/dioxirane] has quit [Remote host closed the connection] 08:56:10 -!- akovalen` is now known as akovalenko 09:06:34 tcr1 [~tcr@84-72-21-32.dclient.hispeed.ch] has joined #sbcl 10:01:32 -!- jdz [~jdz@85.254.212.34] has quit [Quit: Byebye.] 10:04:12 jdz [~jdz@85.254.212.34] has joined #sbcl 10:05:25 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 10:09:06 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 10:22:21 -!- tcr1 [~tcr@84-72-21-32.dclient.hispeed.ch] has quit [Quit: Leaving.] 10:25:19 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 244 seconds] 10:39:00 attila_lendvai [~attila_le@87.247.56.232] has joined #sbcl 10:39:01 -!- attila_lendvai [~attila_le@87.247.56.232] has quit [Changing host] 10:39:01 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:40:07 dioxirane [~dioxirane@unaffiliated/dioxirane] has joined #sbcl 11:50:41 -!- dioxirane [~dioxirane@unaffiliated/dioxirane] has quit [Quit: Reconnecting] 11:50:57 dioxirane [~dioxirane@unaffiliated/dioxirane] has joined #sbcl 12:04:01 -!- dioxirane [~dioxirane@unaffiliated/dioxirane] has quit [Quit: leaving] 12:13:50 dioxirane [~dioxirane@unaffiliated/dioxirane] has joined #sbcl 12:26:28 hlavaty`` [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 12:28:24 -!- hlavaty` [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 252 seconds] 12:41:43 -!- prxq [~mommer@mnhm-5f75d07d.pool.mediaWays.net] has quit [Ping timeout: 244 seconds] 12:45:12 prxq [~mommer@mnhm-5f75d07d.pool.mediaWays.net] has joined #sbcl 13:09:32 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 13:12:42 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 13:15:30 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:16:03 -!- dioxirane [~dioxirane@unaffiliated/dioxirane] has quit [Quit: Reconnecting] 13:16:19 dioxirane [~dioxirane@unaffiliated/dioxirane] has joined #sbcl 13:16:57 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 13:17:45 wbooze [~wbooze@xdsl-78-35-135-71.netcologne.de] has joined #sbcl 13:17:57 -!- dioxirane [~dioxirane@unaffiliated/dioxirane] has quit [Client Quit] 13:18:09 dioxirane [~dioxirane@unaffiliated/dioxirane] has joined #sbcl 13:18:40 attila_lendvai [~attila_le@87.247.56.232] has joined #sbcl 13:18:40 -!- attila_lendvai [~attila_le@87.247.56.232] has quit [Changing host] 13:18:40 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:19:20 -!- dioxirane [~dioxirane@unaffiliated/dioxirane] has quit [Client Quit] 13:19:32 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 13:22:37 dioxirane [~OXO@unaffiliated/dioxirane] has joined #sbcl 13:33:54 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:49:55 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 14:05:36 -!- dioxirane [~OXO@unaffiliated/dioxirane] has quit [Ping timeout: 264 seconds] 14:12:26 Thra11 [~thrall@146.90.63.207] has joined #sbcl 14:20:18 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:26:19 danlentz_ [~danlentz@2601:c:3680:1c:d9e2:17e1:851f:cd93] has joined #sbcl 14:27:06 -!- danlentz [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has quit [Read error: Connection reset by peer] 14:27:06 -!- danlentz_ is now known as danlentz 14:30:01 -!- Thra11 [~thrall@146.90.63.207] has quit [Ping timeout: 246 seconds] 14:31:24 dioxirane [~OXO@unaffiliated/dioxirane] has joined #sbcl 14:43:39 Thra11 [~thrall@87.114.236.202] has joined #sbcl 14:57:09 Thra11_ [~thrall@152.35.113.87.dyn.plus.net] has joined #sbcl 15:00:12 -!- Thra11 [~thrall@87.114.236.202] has quit [Ping timeout: 264 seconds] 15:01:02 Thra11 [~thrall@87.115.11.15] has joined #sbcl 15:01:40 -!- Thra11_ [~thrall@152.35.113.87.dyn.plus.net] has quit [Ping timeout: 248 seconds] 15:07:19 dioxirane_ [~OXO@unaffiliated/dioxirane] has joined #sbcl 15:09:12 -!- dioxirane [~OXO@unaffiliated/dioxirane] has quit [Ping timeout: 264 seconds] 15:12:48 -!- dioxirane_ [~OXO@unaffiliated/dioxirane] has quit [Ping timeout: 264 seconds] 15:24:40 -!- danlentz [~danlentz@2601:c:3680:1c:d9e2:17e1:851f:cd93] has quit [Read error: Connection reset by peer] 15:24:53 danlentz [~danlentz@2601:c:3680:1c:d9e2:17e1:851f:cd93] has joined #sbcl 15:54:37 leuler [~user@p548FABA9.dip.t-dialin.net] has joined #sbcl 16:01:08 To follow up on my problem running SBCL's tests yesterday: I have rectified the situation for me by deinstalling the system wide old ASDF. I can run the test suite now. I indeed had cl-asdf installed; I believe it came with the clisp package; all of these are from a relatively old Ubuntu version. 16:02:41 ok, but that's quite painful: we can't rely on everyone who uses asdf 2.3x to uninstall package-managed version 16:02:51 some regular users may be unable to 16:04:43 but it's Debian's fault 16:05:18 it's debian's fault that asdf 2.30 tries to upgrade itself to asdf 2.011? 16:06:56 Do newer distributions still provide a package "cl-asdf" that would be useful for someone to have installed? 16:07:35 there's a cl-asdf in ubuntu $recent 16:07:37 12.04 has it 16:07:39 I have no idea if it's useful 16:14:05 I have in the meantime read the ILC 2010 article on ASDF which states that the upgradability feature of ASDF 2 is important but it seems not to speak of doing the upgrade automatically. 16:36:27 -!- akovalenko [~user@77.51.0.89] has quit [Ping timeout: 252 seconds] 16:44:06 if we can provide a way for third party systems to use depends-on :sb-posix or something, then we can make sb-posix not use asdf for loading and compilation 16:45:11 what ASDF does is unpredictable and prone to silent breaking, so it could be beneficial to eliminate it from the build process 16:47:31 though, that still doesn't save users when they're going to use it for their own systems 16:51:13 i guess we're just stuck with asdf 16:55:25 isn't "asdf 2.30 tries to upgrade itself to asdf 2.011" just a bug? 16:56:09 that is, something that won't cause trouble once it is fixed. 17:07:55 I tend to agree to prxq. 17:11:36 Krystof, asdf 2.30 will always try to upgrade to whatever you install in your registry. 17:11:57 having installed an old asdf in /usr/share/ is a bug 17:12:59 leuler, back in 2010, I wasn't doing the upgrade automatically... and it was leading to horrible cases of attempting an upgrade in the middle of a build because some intermediate .asd depended on asdf. 17:14:05 and because a .asd file can contain arbitrary code, you can't in general defer the decision to accept or reject a defsystem until after you've read the defsystem and checked that it's not an older version. 17:14:30 by the time you decide to load the .asd file, it's too late, you've committed to upgrade (or downgrade) 17:15:10 stassats`, I have a plan so sb-posix doesn't need asdf at runtime, only at buildtime 17:15:31 cl-asdf in ubuntu is still too old 17:15:55 to get a good cl-asdf, you need to make debian-package in a recent asdf checkout 17:16:06 I can't do it anymore -- I'm without a usable debian machine to do it. 17:17:32 Fare: Thanks for the explanations. 17:17:42 ideally, the sbcl package for debian should have an incompatibility with old cl-asdf 17:17:57 of course, that won't help if you install sbcl from source 17:18:19 cl-asdf isn't as needed anymore, now that all modern lisps ship with asdf2 17:18:43 it used to be indispensible back in the days of asdf1. 17:19:54 well, why not issue an error when it tried to upgrade itself in the middle of things? 17:20:17 I'll see if I can have downgrades fail with a better error message. 17:21:12 i don't believe that silent magic can solve anything 17:21:45 stassats`, it can be hard to detect -- definitely not detectable BEFORE you put everything in a mess -- but yes, I'll think about that option. 17:22:14 Maybe some kind of "oops, it's all in a mess, let's do a non-local exit and retry" kind of arrangement. 17:22:23 and what system depend on asdf? that seems a little strange 17:22:42 says, poiu, asdf-finalizers, and other things that depend on a recent enough asdf. 17:23:29 asdf extensions. 17:23:47 implicitly, cffi-grovel and other extensions, too. 17:23:57 they do require asdf to be loaded, don't they? 17:24:09 so, the only problem is ensuring the version 17:24:23 "only" 17:24:26 can't it have :minimal-asdf 3.0, or something? 17:24:34 akovalenko [~user@77.51.0.89] has joined #sbcl 17:24:45 I was thinking about that... and it's another can of worm. 17:25:08 how do you know which is the minimal? Your current one? 17:25:56 whichever is required for a particular system to operate 17:26:05 failing that requirement, it shall just refuse to be loaded 17:26:11 Fare: how about you stop making ASDF auto-upgrade ? 17:26:15 auto-anything is bad 17:26:33 Even if the general case is not decidable without loading the .asd file would it be possible to special case asdf itself so that it can determine its version from its .asd file and not downgrade itself but simply continue? 17:26:52 i don't think the user is an imbecile, he can handle an error or two 17:26:55 fe[nl]ix, autoupgrade is the only sane thing... and it finds bad configurations early. finding bugs early is good. 17:27:16 I'll have asdf fail with an explanatory message in case of upgrade 17:27:19 downgrade 17:27:36 why the only sane thing ? 17:27:38 it's sane as long you don't have an asdf lying around, let alone an old one 17:28:32 -!- Thra11 [~thrall@87.115.11.15] has quit [Read error: Operation timed out] 17:29:38 -!- wbooze [~wbooze@xdsl-78-35-135-71.netcologne.de] has quit [Ping timeout: 252 seconds] 17:30:24 If nowadays everybody always uses the asdf version shipped with his lisp implementation, when does auto-upgrade come into play at all? 17:30:41 when you least expect it! 17:30:41 then fixing the bug is removing the old asdf. 17:31:09 leuler, when you need a newer one than shipped with your lisp implementation 17:31:12 what if removing old asdf is not possible? 17:31:13 leuler, happens a lot 17:31:22 remove its path from your source-registry 17:31:25 I see. 17:31:31 that's always possible 17:31:46 or put a newer asdf in front of it in your source-registry -- also always possible. 17:31:47 well, whatever, i can't imagine it will change, so it's just a waste of time 17:32:16 putting an asdf in your source-registry is the way to tell asdf "please upgrade me to that version". 17:32:47 at work, we constantly need a newer asdf than provided by our implementation. 17:33:55 automatically? 17:34:09 i'm not against upgrading, i'm against automatic upgrading 17:36:58 stating that upgrading automatically is the right thing when that has caused problems for actual users right here right now is not inspiring confidence 17:37:07 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 17:37:15 if asdf 3 is so different from asdf 2, could it perhaps be called asdf3? 17:37:34 then it could simply refuse to "upgrade" to asdf 17:37:47 dioxirane [~OXO@unaffiliated/dioxirane] has joined #sbcl 17:39:07 it's just, asdf is not just some tool you use at work, many people are depending on it, and there's no reason to punish them for their inattentiveness for leaving an asdf.lisp lying somewhere around 17:40:00 i can take such punishment, but some people will just walk away from CL, saying "screw this, they can't even handle a simple thing" 17:40:25 What about this error message? 17:40:39 Thra11 [~thrall@31.185.188.80] has joined #sbcl 17:41:09 http://paste.lisp.org/+2WMY 17:41:58 Krystof, if it were called asdf3, it by definition wouldn't be compatible. 17:42:06 and no, it's not "so different". 17:42:49 but yes, if it's not possible to detect a downgrade beforehand in general, I could add some code to detect it in the case of ASDF 17:43:55 and that might be the right thing. 17:44:20 probably is. 17:44:26 *Fare* goes code just that. 17:44:27 wbooze [~wbooze@xdsl-84-44-179-55.netcologne.de] has joined #sbcl 17:46:58 and thanks for the feedback 17:47:13 upgrade is hard, automatic or not 17:51:39 thanks for thinking about it 17:52:59 +1 17:53:00 ok, if I find an old version of ASDF registered in the source-registry (or central-registry, etc.), should it be a WARNING, ERROR, or CERROR ? 17:54:12 and if not ERROR, should it continue by ignoring the registered ASDF, or by loading it? 17:54:21 I say WARNING and ignore. 17:54:23 CERROR with an option to disable automatic upgrading completely 17:55:39 the option would be to also disable upgrading of ASDF altogether, not just automatic upgrading, because upgrading it at any other point is suicide. 17:57:54 i don't see a problem, add an error for upgrading "at any other point" 17:58:15 Fare: regarding the error message: i suggest replacing all instances of "this ASDF" by "the ASDF at ~S" to avoid any potential confusion 17:59:58 I'd like not to need to interact in this situation. That would be: print a warning and continue. 18:03:11 leuler: that was also my intention. display a big WARNing (hopefully on stderr) and continue. 18:03:34 does WARN go to stderr by default? I fear not. 18:04:12 it does 18:08:33 yay 18:11:08 is it good still to rely on WARN returning NIL in a conditional? 18:12:44 clhs warn 18:12:44 http://www.lispworks.com/reference/HyperSpec/Body/f_warn.htm 18:13:00 everything is laid out 18:13:01 yes, but is it good style? 18:13:24 also, should I make it an asdf-message instead of a WARN ? 18:13:27 what's the point? it either returns NIL, or doesn't return at all 18:13:45 probably a WARN. 18:13:54 we want it well visible to users. 18:14:35 -!- yacks [~yacks@180.151.36.169] has quit [Quit: Leaving] 18:26:12 -!- prxq [~mommer@mnhm-5f75d07d.pool.mediaWays.net] has quit [Quit: Leaving] 18:34:54 prxq [~mommer@mnhm-5f75d07d.pool.mediaWays.net] has joined #sbcl 18:35:15 dioxirane_ [~OXO@unaffiliated/dioxirane] has joined #sbcl 18:38:36 -!- dioxirane [~OXO@unaffiliated/dioxirane] has quit [Ping timeout: 264 seconds] 18:38:38 OK, what about this? 18:38:39 http://paste.lisp.org/+2WN0 18:38:55 is it too verbose or not enough? 18:47:10 where should I use :ignore-inherited-configuration? 18:48:51 in your ~/.config/common-lisp/source-registry.conf 18:50:30 -!- dioxirane_ is now known as dioxriane 18:50:38 Fare: ok, that should be in that message, imo. Or perhaps just a link to corresponding docs 18:50:48 ok, added. 18:52:55 http://paste.lisp.org/+2WN0/1 18:57:50 I'm OK with this version. 18:59:49 -!- hlavaty`` [~user@friedrichstrasse.knowledgetools.de] has quit [Remote host closed the connection] 19:01:22 -!- dioxriane [~OXO@unaffiliated/dioxirane] has quit [Quit: no brrain to host] 19:03:48 dioxirane [~OXO@unaffiliated/dioxirane] has joined #sbcl 19:07:58 sdemarre [~serge@91.176.241.92] has joined #sbcl 19:37:47 -!- leuler [~user@p548FABA9.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 19:42:55 -!- wbooze [~wbooze@xdsl-84-44-179-55.netcologne.de] has quit [Remote host closed the connection] 20:18:06 wbooze [~wbooze@xdsl-84-44-179-55.netcologne.de] has joined #sbcl 20:32:27 OK, pushed as 2.30.4 20:40:50 -!- wbooze [~wbooze@xdsl-84-44-179-55.netcologne.de] has quit [Quit: none] 20:41:59 wbooze [~wbooze@xdsl-84-44-179-55.netcologne.de] has joined #sbcl 21:19:54 -!- sdemarre [~serge@91.176.241.92] has quit [Ping timeout: 252 seconds] 21:28:24 -!- dioxirane [~OXO@unaffiliated/dioxirane] has quit [Ping timeout: 264 seconds] 21:34:29 -!- whoops [~whoops@2a01:4f8:161:41e1::2] has quit [Quit: Farewell] 21:36:43 whoops [~whoops@2a01:4f8:161:41e1::2] has joined #sbcl 21:37:34 -!- prxq [~mommer@mnhm-5f75d07d.pool.mediaWays.net] has quit [Quit: Leaving] 21:38:29 zaquest [~zaquest@l49-13-180.cn.ru] has joined #sbcl 21:42:45 -!- zaquest [~zaquest@l49-13-180.cn.ru] has quit [Quit: WeeChat 0.4.0] 21:51:42 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: mental deadlock] 22:00:18 akovalen` [~user@77.51.0.89] has joined #sbcl 22:02:33 -!- akovalenko [~user@77.51.0.89] has quit [Ping timeout: 276 seconds] 22:12:59 blar1 [~nkennedy@opaltech9.theopalgroup.com] has joined #sbcl 22:13:48 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 22:15:40 i'm a bit mystified by CL's package system. as long as i'm in the same REPL session in which i loaded a package via quicklisp, that package is usable. but if i exit that session and restart, the package is no longer accessible. so i don't know if this is a quicklisp or an sbcl question, but - do quicklisp-loaded packages not persist across sessions? and if they do, how do i use them again? 22:16:38 so for example, in session 1: (ql:quickload "drakma); (drakma:http-request "htp://foo.com") - success 22:17:20 but, close session 1, laucnh new repl -> (drakma:http-request "http://foo.com") !! drakma does not exist! 22:18:29 woops; sorry - just read the topic for the channel; sorry, i'm in the wrong place 22:32:08 -!- akovalen` [~user@77.51.0.89] has quit [Read error: Operation timed out] 22:42:08 -!- blar1 [~nkennedy@opaltech9.theopalgroup.com] has quit [Quit: Leaving.] 23:01:27 akovalenko [~user@77.51.0.89] has joined #sbcl 23:02:00 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 23:56:57 danlentz0 [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has joined #sbcl