00:16:00 Thra11 [~thrall@146.90.177.167] has joined #sbcl 00:17:30 -!- Thra11_ [~thrall@87.115.116.169] has quit [Ping timeout: 245 seconds] 00:24:35 -!- Thra11 [~thrall@146.90.177.167] has quit [Ping timeout: 245 seconds] 00:36:19 akovalen` [~user@195.18.46.21] has joined #sbcl 00:44:17 -!- akovalenko [~user@195.18.46.21] has quit [*.net *.split] 00:44:17 -!- xymox [lechuck@unaffiliated/contempt] has quit [*.net *.split] 01:55:00 zulu_inuoe [~quassel@184.89.111.53] has joined #sbcl 03:00:52 -!- akovalen` [~user@195.18.46.21] has quit [Ping timeout: 248 seconds] 03:06:59 univyrse [~univyrse@24-179-43-39.dhcp.leds.al.charter.com] has joined #sbcl 03:08:19 does anyone know anything about ARM support in SBCL? will it be happening soon...? 03:08:37 it won't 03:12:01 -!- LiamH [~none@pool-74-96-4-63.washdc.east.verizon.net] has quit [Quit: Leaving.] 03:16:35 oh, thats sad 03:16:48 im not really a hardware guy, is there a reason? 03:17:07 nobody wants to do it 03:17:24 im thinking about building a distributed program for some raspberry pis i have laying around 03:17:39 and arm support is kinda necessary 03:17:55 clozure has it, but i have a lot of sbcl utilities that id prefer not to rewrite 03:54:07 LiamH [~none@pool-74-96-4-63.washdc.east.verizon.net] has joined #sbcl 03:59:10 -!- univyrse [~univyrse@24-179-43-39.dhcp.leds.al.charter.com] has quit [Quit: Leaving] 04:02:39 -!- LiamH [~none@pool-74-96-4-63.washdc.east.verizon.net] has quit [Quit: Leaving.] 04:15:19 -!- christoph1 is now known as christoph_debian 04:40:58 -!- wbooze [~wbooze@xdsl-78-35-138-221.netcologne.de] has quit [Quit: none] 05:15:12 yacks [~yacks@180.151.36.168] has joined #sbcl 05:22:42 attila_lendvai [~attila_le@87.247.13.222] has joined #sbcl 05:22:43 -!- attila_lendvai [~attila_le@87.247.13.222] has quit [Changing host] 05:22:43 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:01:21 sdemarre [~serge@125.162-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 06:18:10 cmm- [~cmm@bzq-79-180-181-12.red.bezeqint.net] has joined #sbcl 06:18:50 -!- Fare [fare@nat/google/x-mxfhqtoiaqznqrnf] has quit [Quit: Leaving] 06:19:59 -!- cmm [~cmm@109.65.178.47] has quit [Ping timeout: 252 seconds] 06:26:23 prxq [~mommer@mnhm-4d0104a1.pool.mediaWays.net] has joined #sbcl 06:32:24 -!- cmm- [~cmm@bzq-79-180-181-12.red.bezeqint.net] has quit [Read error: Operation timed out] 06:32:35 cmm [~cmm@109.65.175.67] has joined #sbcl 06:36:36 -!- sdemarre [~serge@125.162-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 248 seconds] 06:46:15 -!- ASau [~user@46.115.125.174] has quit [Ping timeout: 256 seconds] 07:25:48 xymox [lechuck@unaffiliated/contempt] has joined #sbcl 07:26:06 -!- xymox [lechuck@unaffiliated/contempt] has quit [Max SendQ exceeded] 07:28:21 xymox [lechuck@unaffiliated/contempt] has joined #sbcl 08:18:38 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 08:48:15 akovalenko [~user@195.18.46.21] has joined #sbcl 09:41:37 Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has joined #sbcl 10:03:33 -!- Vivitron [~Vivitron@pool-98-110-213-33.bstnma.fios.verizon.net] has quit [Remote host closed the connection] 10:59:51 dtw [~dtw@pdpc/supporter/active/dtw] has joined #sbcl 11:18:33 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 11:23:29 jarmond [~user@93-96-213-180.zone4.bethere.co.uk] has joined #sbcl 11:33:25 -!- zulu_inuoe [~quassel@184.89.111.53] has quit [Remote host closed the connection] 11:47:20 -!- scymtym_ [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has quit [Remote host closed the connection] 11:48:20 scymtym [~user@2001:638:504:2093:226:b9ff:fe7d:3e1f] has joined #sbcl 12:06:17 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 12:09:40 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds] 12:37:57 hlavaty [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 13:20:20 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 13:56:14 attila_lendvai [~attila_le@92.47.249.96] has joined #sbcl 13:56:14 -!- attila_lendvai [~attila_le@92.47.249.96] has quit [Changing host] 13:56:14 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:00:27 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds] 14:11:20 jarmond` [~user@93-96-213-180.zone4.bethere.co.uk] has joined #sbcl 14:13:53 -!- jarmond [~user@93-96-213-180.zone4.bethere.co.uk] has quit [Ping timeout: 248 seconds] 14:14:13 -!- jarmond` [~user@93-96-213-180.zone4.bethere.co.uk] has quit [Remote host closed the connection] 14:14:28 jarmond` [~user@93-96-213-180.zone4.bethere.co.uk] has joined #sbcl 14:17:00 jarmond`` [~user@93-96-213-180.zone4.bethere.co.uk] has joined #sbcl 14:20:03 -!- jarmond` [~user@93-96-213-180.zone4.bethere.co.uk] has quit [Ping timeout: 276 seconds] 14:26:10 Thra11 [~thrall@117.50.113.87.dyn.plus.net] has joined #sbcl 14:28:50 -!- jarmond`` [~user@93-96-213-180.zone4.bethere.co.uk] has quit [Ping timeout: 250 seconds] 14:30:55 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [*.net *.split] 14:30:55 -!- Guest70432 [user@nat/google/x-bgtkcxiyyeexxwuy] has quit [*.net *.split] 14:30:55 -!- ivan`` [~ivan@unaffiliated/ivan/x-000001] has quit [*.net *.split] 14:31:18 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 14:31:54 Thra11_ [~thrall@146.90.186.250] has joined #sbcl 14:32:00 ivan`` [~ivan@unaffiliated/ivan/x-000001] has joined #sbcl 14:32:14 Guest70432 [user@nat/google/x-bpmdsvslvaxcnbie] has joined #sbcl 14:32:48 jarmond`` [~user@93-96-213-180.zone4.bethere.co.uk] has joined #sbcl 14:33:39 wbooze [~wbooze@xdsl-78-35-128-34.netcologne.de] has joined #sbcl 14:34:04 -!- Thra11 [~thrall@117.50.113.87.dyn.plus.net] has quit [Ping timeout: 240 seconds] 14:34:54 Thra11 [~thrall@46.208.114.72] has joined #sbcl 14:38:00 -!- Thra11_ [~thrall@146.90.186.250] has quit [Ping timeout: 264 seconds] 14:38:35 -!- jarmond`` [~user@93-96-213-180.zone4.bethere.co.uk] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 15:09:55 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 15:47:18 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 15:48:45 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:00:03 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 16:01:09 attila_lendvai [~attila_le@92.47.249.96] has joined #sbcl 16:01:10 -!- attila_lendvai [~attila_le@92.47.249.96] has quit [Changing host] 16:01:10 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:11:44 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 16:16:24 -!- xymox [lechuck@unaffiliated/contempt] has quit [Ping timeout: 264 seconds] 16:22:04 xymox [lechuck@unaffiliated/contempt] has joined #sbcl 16:45:48 Please, could somebody take the offending field into standard SBCL? 16:45:50 The loaded code expects an incompatible layout for class SB-PRETTY:PRETTY-STREAM. 17:02:44 Thra11_ [~thrall@146.90.141.176] has joined #sbcl 17:04:17 flip214: what exactly are you talking about? 17:05:36 -!- Thra11 [~thrall@46.208.114.72] has quit [Ping timeout: 264 seconds] 17:06:00 pkhuong: some library seems to modify the PRETTY-STREAM layout, and depending on FASL load order you might get a FASL that was compiled using the wrong layout. 17:06:16 if that field was just taken into SBCL proper there would be no conflicts. 17:06:39 and no, I'm not sure which library does that; I hade the conflict in CL-PPCRE API loading now. 17:08:05 Thra11 [~thrall@87.115.10.73] has joined #sbcl 17:09:11 -!- Thra11_ [~thrall@146.90.141.176] has quit [Ping timeout: 245 seconds] 17:12:46 Either there was a huge netsplit, or we're really missing context here. 17:13:26 at one point there was a slime module which did something with pretty-streams 17:13:30 I have no idea if it still does 17:13:41 (but yes, we're missing context) 17:14:00 find out why the modification needs to be made, and argue that this is a useful feature 17:37:09 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 17:52:48 sdemarre [~serge@125.162-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 18:08:43 Thra11_ [~thrall@87.112.181.17] has joined #sbcl 18:08:48 ASau [~user@46.115.120.143] has joined #sbcl 18:11:40 -!- Thra11 [~thrall@87.115.10.73] has quit [Ping timeout: 245 seconds] 18:12:22 Thra11 [~thrall@146.90.252.22] has joined #sbcl 18:13:24 -!- Thra11_ [~thrall@87.112.181.17] has quit [Ping timeout: 252 seconds] 18:14:41 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 18:15:26 Qworkescence [~quad@unaffiliated/quadrescence] has joined #sbcl 18:25:50 -!- yacks [~yacks@180.151.36.168] has quit [Quit: Leaving] 18:51:13 slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has joined #sbcl 18:53:24 -!- sdemarre [~serge@125.162-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 272 seconds] 19:07:07 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 19:09:56 sdemarre [~serge@125.162-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 19:41:35 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 255 seconds] 19:47:31 -!- xymox [lechuck@unaffiliated/contempt] has quit [Ping timeout: 245 seconds] 19:52:09 xymox [lechuck@unaffiliated/contempt] has joined #sbcl 19:56:19 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Read error: Operation timed out] 20:02:32 -!- dtw [~dtw@pdpc/supporter/active/dtw] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 20:37:03 psilord [~psilord@75-128-248-116.dhcp.mdsn.wi.charter.com] has joined #sbcl 20:43:44 drewc`` [~drewc@50.7.166.100] has joined #sbcl 20:47:14 -!- drewc [~drewc@50.7.166.100] has quit [Ping timeout: 246 seconds] 20:52:30 Thra11_ [~thrall@67.9.112.87.dyn.plus.net] has joined #sbcl 20:53:03 dioxirane [~OXO@unaffiliated/dioxirane] has joined #sbcl 20:53:38 -!- Thra11 [~thrall@146.90.252.22] has quit [Ping timeout: 252 seconds] 20:53:46 -!- dioxirane [~OXO@unaffiliated/dioxirane] has left #sbcl 21:15:42 prxq_ [~mommer@mnhm-590c2cd8.pool.mediaWays.net] has joined #sbcl 21:18:34 -!- prxq [~mommer@mnhm-4d0104a1.pool.mediaWays.net] has quit [Ping timeout: 252 seconds] 21:53:30 -!- drewc`` is now known as drewc 22:06:01 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 22:11:05 -!- sdemarre [~serge@125.162-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 260 seconds] 22:11:56 -!- Qworkescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 22:22:55 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 22:25:11 lmj` [~lmj`@c-71-234-73-103.hsd1.ct.comcast.net] has joined #sbcl 22:25:46 Is adding a lazily-created lock to CLASSOID too expensive? 22:26:53 That fixes https://bugs.launchpad.net/sbcl/+bug/1153309 but I wonder what the alternatives are 22:27:48 lmj`: lock where? 22:28:31 pkhuong: in (def!struct (classoid ...)) 22:28:53 Initially set to nil, CAS when needed 22:29:20 lmj`: where in the code? What critical section does the lock protect? 22:29:35 one thing to get a sense of the pain is to try measuring the effect on an sbcl rebuild 22:29:58 pkhuong: oh right -- in classoid-typep, around DO 22:30:01 i.e. time building with a host with no lock and a host with locks 22:32:34 nikodemus's comments lets me believe adding a lock would only introduce more subtle deadlocks 22:32:56 but if you wnat to try, spinlocking on a field would be easier than CASing a lock in. 22:33:35 yes, spin lock is better of course 22:33:59 Adding a per-class lock might not be enough -- I could imagine things going wrong if e.g. a superclass is invalidated 22:35:20 the averrance is potentially wrong, though, in the presence of other threads invalidating stuff 22:36:13 what do we really want? We want that "get the layouts" computation to be atomic against changes in the class hierarchy 22:36:58 easy way out: a seqlock. Chane a global version counter whenever we modify the class hierarchy. 22:37:53 Is there already a dirty flag present? 22:38:10 mind you, it's presumably not just the class hierarchy 22:38:36 the code in https://bugs.launchpad.net/sbcl/+bug/1153309 doesn't involve changing anything 22:38:38 Having dirty markers doesn't really help here, though 22:38:57 in fact I don't understand how that code can cause failures in classoid-typep 22:39:31 Krystof: is it likely that applying the eager class finalization patches would fix this? 22:39:58 I don't know, because I don't un oh wait yes 22:40:01 well, doing an initial method call changes lots of stuff. 22:40:13 I think pkhuong is right that it might be lazy finalization 22:40:33 foo2 hasn't been finalized by the time that the method is called 22:41:18 so in order to do typep it (which you need to do to do method dispatch) you have to do finalization. Still a bit mystified but it's worth a try 22:41:24 and I think eager class finalization sucks because the protocol is fundamentally broken and involves traversing the whole inheritance graph.. for each transitive finalization 22:41:28 yes 22:41:37 that's why I uneagerified it in the first place 22:41:37 so it sucks, but only because MOP is broken ;) 22:41:49 well, I think they meant finalization to be lazy 22:42:04 do we lock around finalization? 22:42:17 Krystof: even then, you still get recursive finalizations. 22:43:01 I tried to trigger them eagerly, but process finalization lazily within each finalisation phase. Didn't help with the degenerate cases at all. 22:43:19 hm, yes we lock around finalization. So now I'm back to being mystified as to why we get errors 22:43:20 even if we did lock, we don't lock around classoid-typep, do we? 22:43:48 well no but wouldn't classoid-typep eventually try to finalize in the do loop? 22:43:51 Note that the bug doesn't happen if you don't explicitly call typep; just calling the method on multiple threads wasn't good enough. 22:44:30 the (%ensure-classoid-valid ...) call in src/code/typep.lisp 22:45:01 ends up calling finalize-inheritance 22:45:26 that typep foo 'foo1 should make foo1 finalized, and the make-instance has made foo3 finalized 22:45:32 I hate CLOS. One day, I'll get nyef's genesis-for-arbitrary-programs working, and then work with static clos. 22:45:34 so, what happens next 22:45:47 foo2 not finalized? 22:45:57 foo2 is not finalized by this stage, in the lazy world 22:46:07 so finalizing foo2 breaks foo1, maybe? 22:46:22 foom: definitely. 22:46:32 foo1 is refinalized and all. 22:47:02 so I can see how it can take more than one go-round the loop 22:47:09 (i.e. the aver is wrong) 22:47:16 Why does it only work with method calls, and not defun calls? 22:47:35 I can't really see how it gets 22:47:43 because method calls are hideously complicated 22:47:52 they have to do all sorts of type dispatch internally to know which method to call 22:48:36 oh, wait, the other error is from the shared foo object being updated from multiple threads 22:48:36 22:48:36 -!- prxq_ [~mommer@mnhm-590c2cd8.pool.mediaWays.net] has quit [Quit: Leaving] 22:49:27 if something finalizes foo1 while something else is calling typep, then the typep will give the wrong answer and end up calling HELLO with NIL 22:50:50 so I think eager finalization would make this go away but we'd still be vulnerable in the presence of dynamically defined classes or other updates to the hierarchy (including perhaps user calls to finalize-inheritance in another thread) 22:51:24 so maybe the idea of a seqlock around class/type hierarchy stuff is Right 22:51:36 otoh, explicitly frobbing the class hierarchy conurrently is obviously a borderline idea. 22:51:53 I wonder if it makes sense to go through such lengths to protect the user from himself? 22:52:07 If he's making concurrent redefinitions, god save him. 22:52:34 yeah, well, next time you do C-c C-c in a slime buffer... 22:53:15 I don't usually C-c C-c in a slime buffer, but when I do, it's on a defstruct. 22:53:45 "you can redefine stuff in a running image, as long as by 'running image' you mean 'image in which nothing is running'" 22:54:49 well, redefining two defuns simultaneously may not be as simultaneous as one would expect, for example. 22:56:50 I guess I'm just not totally convinced that eager finalization actually fixes all problems of this kind 22:57:15 It fixes this one, but this is a reduced test case of something complicated. (Not to mention james anderson's similar-looking problem) 22:57:35 It makes them less mysterious (less spooky action at a temporal distance). 23:00:06 1st 23:03:21 I don't want to argue against eager finalization. Just maybe pro a seqlock as well (and maybe the seqlock first so that we can test that it does actually fix this) 23:03:28 but. It is late and I am tired 23:03:49 and it's late and I'm working on something else. 23:04:12 Sorry about the noise. This game was not intended for this channel. 23:16:17 -!- wbooze [~wbooze@xdsl-78-35-128-34.netcologne.de] has quit [Ping timeout: 248 seconds] 23:20:59 -!- psilord [~psilord@75-128-248-116.dhcp.mdsn.wi.charter.com] has quit [Quit: Leaving.] 23:30:25 -!- slyrus [~chatzilla@173-228-44-92.dsl.static.sonic.net] has quit [Ping timeout: 245 seconds]