01:00:48 kanru [~kanru@173.243.46.194] has joined #sbcl 01:04:52 -!- prxq [~mommer@mnhm-4d010db1.pool.mediaWays.net] has quit [Ping timeout: 246 seconds] 01:17:45 prxq [~mommer@mnhm-4d013913.pool.mediaWays.net] has joined #sbcl 01:24:49 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 246 seconds] 01:26:50 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 01:50:29 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 245 seconds] 01:51:38 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 02:07:07 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Ping timeout: 264 seconds] 02:18:41 kanru` [~kanru@173.243.46.194] has joined #sbcl 02:20:18 -!- kanru [~kanru@173.243.46.194] has quit [Ping timeout: 243 seconds] 02:38:28 attila_lendvai [~attila_le@92.46.3.216] has joined #sbcl 02:38:28 -!- attila_lendvai [~attila_le@92.46.3.216] has quit [Changing host] 02:38:28 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 02:38:29 -!- christoph4 [~christoph@ppp-188-174-73-213.dynamic.mnet-online.de] has quit [Ping timeout: 248 seconds] 02:52:05 christoph4 [~christoph@ppp-188-174-15-50.dynamic.mnet-online.de] has joined #sbcl 02:55:30 fisxoj [~fisxoj@c-24-12-190-29.hsd1.il.comcast.net] has joined #sbcl 03:01:41 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Connection reset by peer] 03:02:53 attila_lendvai [~attila_le@92.46.3.216] has joined #sbcl 03:02:53 -!- attila_lendvai [~attila_le@92.46.3.216] has quit [Changing host] 03:02:53 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:22:11 -!- drmeister1 [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 03:23:45 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] 03:35:18 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 04:11:48 -!- vi1 [~vi1@93.92.216.186] has quit [Ping timeout: 245 seconds] 04:26:41 -!- fisxoj [~fisxoj@c-24-12-190-29.hsd1.il.comcast.net] has quit [Quit: Ex-Chat] 04:38:20 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 05:00:34 -!- easye [~user@213.33.70.157] has quit [*.net *.split] 05:00:34 -!- asedeno [asedeno@nat/google/x-lvipxuqaubqznmxs] has quit [*.net *.split] 05:00:34 -!- _8david [~user@port-212-202-134-139.static.qsc.de] has quit [*.net *.split] 05:00:34 -!- flip214_ [~marek@86.59.100.100] has quit [*.net *.split] 05:00:34 -!- pkhuong [~pkhuong@modemcable086.239-37-24.mc.videotron.ca] has quit [*.net *.split] 05:03:27 easye [~user@213.33.70.157] has joined #sbcl 05:03:27 asedeno [asedeno@nat/google/x-lvipxuqaubqznmxs] has joined #sbcl 05:03:27 _8david [~user@port-212-202-134-139.static.qsc.de] has joined #sbcl 05:03:27 flip214_ [~marek@86.59.100.100] has joined #sbcl 05:03:27 pkhuong [~pkhuong@modemcable086.239-37-24.mc.videotron.ca] has joined #sbcl 05:03:57 sdemarre [~serge@109.134.154.83] has joined #sbcl 05:08:04 -!- kanru` [~kanru@173.243.46.194] has quit [Ping timeout: 256 seconds] 05:17:34 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 05:21:52 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 05:22:31 -!- sdemarre [~serge@109.134.154.83] has quit [Ping timeout: 256 seconds] 05:29:37 -!- Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has quit [Ping timeout: 248 seconds] 05:42:43 Fare [fare@nat/google/x-nymbaabbfheeyjmm] has joined #sbcl 05:45:34 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 246 seconds] 05:50:41 scymtym [~user@89.31.118.161] has joined #sbcl 06:03:53 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 06:04:10 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 256 seconds] 06:20:17 Strigoides [~owen@114-134-0-26.lightwire.co.nz] has joined #sbcl 06:45:33 -!- Posterdati [~antani@host183-239-dynamic.16-87-r.retail.telecomitalia.it] has quit [Ping timeout: 245 seconds] 06:48:55 Posterdati [~antani@host183-239-dynamic.16-87-r.retail.telecomitalia.it] has joined #sbcl 06:50:17 teggi [~teggi@113.172.36.159] has joined #sbcl 06:53:47 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 06:54:52 -!- Fare [fare@nat/google/x-nymbaabbfheeyjmm] has quit [Ping timeout: 246 seconds] 07:12:20 -!- scymtym [~user@89.31.118.161] has quit [Ping timeout: 252 seconds] 07:24:09 -!- tcr2 [~tcr@77-56-40-229.dclient.hispeed.ch] has quit [Quit: Leaving.] 07:24:34 tcr1 [~tcr@77-56-40-229.dclient.hispeed.ch] has joined #sbcl 07:25:15 -!- ASau` is now known as ASau 07:33:19 rudi [~rudi@1x-193-157-248-28.uio.no] has joined #sbcl 07:34:45 scymtym [~user@89.31.118.161] has joined #sbcl 07:34:52 attila_lendvai [~attila_le@87.247.13.189] has joined #sbcl 07:34:52 -!- attila_lendvai [~attila_le@87.247.13.189] has quit [Changing host] 07:34:52 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:42:04 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:54:22 -!- scymtym [~user@89.31.118.161] has quit [Ping timeout: 246 seconds] 08:10:32 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 08:30:08 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 08:33:29 attila_lendvai [~attila_le@87.247.13.189] has joined #sbcl 08:33:30 -!- attila_lendvai [~attila_le@87.247.13.189] has quit [Changing host] 08:33:30 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 08:37:22 stassats [~stassats@wikipedia/stassats] has joined #sbcl 08:38:46 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 08:41:44 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 245 seconds] 08:42:40 attila_lendvai [~attila_le@87.247.13.189] has joined #sbcl 08:42:42 -!- attila_lendvai [~attila_le@87.247.13.189] has quit [Changing host] 08:42:42 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 09:24:39 scymtym [~user@89.31.118.161] has joined #sbcl 09:40:22 -!- teggi [~teggi@113.172.36.159] has quit [Remote host closed the connection] 09:41:24 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 09:43:24 teggi [~teggi@113.172.36.159] has joined #sbcl 09:51:13 stassats [~stassats@wikipedia/stassats] has joined #sbcl 09:58:12 davazp [~user@92.251.228.86.threembb.ie] has joined #sbcl 10:51:01 -!- jdz [~jdz@85.254.212.34] has quit [Quit: Byebye.] 10:58:30 jdz [~jdz@85.254.212.34] has joined #sbcl 11:03:18 -!- Strigoides [~owen@114-134-0-26.lightwire.co.nz] has quit [Ping timeout: 252 seconds] 11:03:52 kanru [~kanru@173.243.46.194] has joined #sbcl 11:05:09 Strigoides [~owen@114-134-0-111.lightwire.co.nz] has joined #sbcl 11:05:17 -!- Strigoides [~owen@114-134-0-111.lightwire.co.nz] has quit [Client Quit] 11:08:21 -!- davazp [~user@92.251.228.86.threembb.ie] has quit [Ping timeout: 248 seconds] 11:23:31 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: This computer has gone to sleep] 11:33:46 drmeister1 [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 11:54:06 Guest963` [user@nat/google/x-lhvbkylsepwwcaox] has joined #sbcl 11:54:31 -!- Guest96351 [user@nat/google/x-lrlyvxqpvpvkaavw] has quit [Read error: Connection reset by peer] 12:07:33 -!- daimrod [daimrod@sbrk.org] has quit [Remote host closed the connection] 12:25:19 daimrod [daimrod@sbrk.org] has joined #sbcl 12:36:03 -!- drmeister1 [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 12:42:21 vi1 [~vi1@93.92.216.186] has joined #sbcl 12:46:40 -!- daimrod [daimrod@sbrk.org] has quit [Remote host closed the connection] 12:56:38 segv- [~mb@95-91-243-225-dynip.superkabel.de] has joined #sbcl 13:08:15 drmeister1 [~drmeister@166.137.107.157] has joined #sbcl 13:11:04 -!- drmeister1 [~drmeister@166.137.107.157] has quit [Remote host closed the connection] 13:16:44 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 13:22:38 drmeister1 [~drmeister@166.137.107.157] has joined #sbcl 13:22:42 -!- drmeister1 [~drmeister@166.137.107.157] has quit [Remote host closed the connection] 13:23:16 drmeister1 [~drmeister@wirelessNAT188.wireless.temple.edu] has joined #sbcl 13:26:06 davazp [~user@92.251.184.152.threembb.ie] has joined #sbcl 13:27:13 wbooze [~wbooze@xdsl-84-44-179-153.netcologne.de] has joined #sbcl 13:37:43 -!- drmeister1 [~drmeister@wirelessNAT188.wireless.temple.edu] has quit [Read error: Connection reset by peer] 13:39:31 drmeister1 [~drmeister@166.137.107.157] has joined #sbcl 13:40:20 -!- kanru [~kanru@173.243.46.194] has quit [Ping timeout: 256 seconds] 13:44:22 Fare [fare@nat/google/x-xgpkrvgkwbxddlta] has joined #sbcl 13:54:33 -!- drmeister1 [~drmeister@166.137.107.157] has quit [Remote host closed the connection] 13:57:42 kanru [~kanru@66.207.208.98] has joined #sbcl 13:59:30 -!- davazp [~user@92.251.184.152.threembb.ie] has quit [Ping timeout: 264 seconds] 14:37:52 nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has joined #sbcl 14:38:22 G'morning all. 14:38:53 morning nyef. how go the gencgc exploits? 14:38:58 I'm having trouble understanding maybe_adjust_large_object(). How can a large object "shrink"? 14:39:47 heh. you got me. also, saw this on the ML this morning, http://thread.gmane.org/gmane.lisp.steel-bank.devel/17303/focus=17315 14:40:38 nyef: there's one function where we do that 14:40:50 Oh, wow. That wasn't there when I checked last night. 14:41:07 pkhuong: What, allocate more space to an object than it actually needs? 14:41:16 nyef: yeah. and then sb-kernel:%shrink-vector 14:41:30 when we don't know the size of the data ahead of time, but are sure that we have the only reference to the result 14:42:00 Wow, eleven uses of %shrink-vector. 14:42:30 there's also some cases where we use it to help GC (not sure it that actually works) 14:48:23 Okay, this makes more sense now, but still not complete sense... 14:49:50 There's some crazy bit of logic in preserve_pointer() where, having determined that a pointer is to a "valid" lisp object, and that it's in a "large object" page, it calls m_a_l_o(), and then checks to see if the pointer is no longer within the allocated space of the large object page. 14:50:32 But for the pointer to be considered valid in the first place, it has to be a tagged pointer to a lisp object, which means the START of the object, which wouldn't be affected by it shrinking. 14:50:39 right. 14:50:48 well, code objects, but hopefully that never happens 14:51:49 And when do we shrink code objects? 14:52:17 never, I think/hope. 14:52:58 Speaking of which, I was looking at the whole bit with x86 code fixups, and it occurred to me that it might make sense to just have the compiler emit the fixup offsets directly into the code object instead of having an external "fixup vector". 14:53:13 Especially since we no longer purify for gencgc ports. 14:55:19 soverton [~soverton@24.89.41.21] has joined #sbcl 14:59:01 So, rewriting the GC in Lisp... Oddly enough, I've done some thinking about precisely this a while back. 14:59:20 I'm probably going to have to weigh in on that thread. 15:01:56 -!- soverton [~soverton@24.89.41.21] has left #sbcl 15:02:07 drmeister1 [~drmeister@farnsworth.chem.temple.edu] has joined #sbcl 15:02:50 -!- rudi [~rudi@1x-193-157-248-28.uio.no] has quit [Quit: Client exciting.] 15:06:53 nyef: I think jsnell_ was right in thinking that generating the GC (as C code) in lisp would be more robust. 15:08:36 Plausibly, yes. 15:10:53 davazp [~user@178.167.167.177.threembb.ie] has joined #sbcl 15:17:07 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 246 seconds] 15:21:25 -!- scymtym [~user@89.31.118.161] has quit [Ping timeout: 252 seconds] 15:26:20 yacks [~py@180.151.36.168] has joined #sbcl 15:34:47 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 256 seconds] 15:41:26 yacks [~py@180.151.36.168] has joined #sbcl 16:40:59 -!- Labrit is now known as Tribal 16:48:23 If x86 code-objects don't move, they don't need fixup vectors, do they? 17:16:12 Okay, that should give Mr. Lanning something to think about. 17:42:34 -!- Bike [~Glossina@71-222-48-148.ptld.qwest.net] has quit [Ping timeout: 245 seconds] 17:44:25 -!- yacks [~py@180.151.36.168] has quit [Read error: Operation timed out] 17:44:40 Bike [~Glossina@75-175-79-174.ptld.qwest.net] has joined #sbcl 18:13:18 -!- davazp [~user@178.167.167.177.threembb.ie] has quit [Ping timeout: 264 seconds] 18:22:29 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Remote host closed the connection] 18:24:00 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 18:32:27 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 256 seconds] 18:51:32 so... sounds like Lanning wants something like manually-managed pieces of the heap (e.g. malloc/free) that are still scanned for pointers. 18:54:40 of course, if that's a lot of data, you'll want to exploit write barriers, and things get a teensy bit hairier. Still, that's much easier to hack in than a full GC. 18:55:44 Bike_ [~Glossina@174-25-48-1.ptld.qwest.net] has joined #sbcl 18:57:13 is there a point to writing the GC in lisp? 18:57:29 I mean, other than "yay lisp!!!" 18:57:32 foom: not sure. less duplication with objdef.lisp 18:57:49 -!- Bike [~Glossina@75-175-79-174.ptld.qwest.net] has quit [Ping timeout: 240 seconds] 18:57:49 But again, that's more directly fixable by generating C code during genesis 18:58:29 -!- Bike_ is now known as Bike 19:02:48 Allegro's GC is written in CL 19:02:59 fe[nl]ix: cool. 19:15:29 stassats [~stassats@wikipedia/stassats] has joined #sbcl 19:23:50 davazp [~user@178.167.167.177.threembb.ie] has joined #sbcl 19:36:06 -!- Fare [fare@nat/google/x-xgpkrvgkwbxddlta] has quit [Ping timeout: 264 seconds] 19:51:31 Fare [~fare@173-9-65-97-NewEngland.hfc.comcastbusiness.net] has joined #sbcl 19:52:11 -!- teggi [~teggi@113.172.36.159] has quit [Remote host closed the connection] 20:00:55 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [Remote host closed the connection] 20:08:32 ... So, mmap() a chunk of space, have a macro that will arrange that all allocation within its extent goes into said space, and I can do that from Lisp without altering gencgc, if I can use WITHOUT-INTERRUPTS. 20:08:59 lp 1178989 20:08:59 https://bugs.launchpad.net/bugs/1178989 20:08:59 And then arrange some way to have gencgc scavenge external spaces on GC, treating them as pinned pages. 20:09:03 is present not only in SBCL 20:09:44 I have to estimate a GC hack at a weekend again so soon, but... 20:14:30 loop code is... weird 20:15:23 "vintage" 20:15:46 "Classic MIT style"? 20:16:12 just look at estimate-code-size, all it does is (catch 'estimate-code-size (estimate-code-size-1 x env)) 20:16:29 i mean, can't they have just used (block estimate-code-size ...)? 20:16:41 It... might have pre-dated BLOCK? 20:17:24 the comment convention is interesting too, ;;@@@@ ???? (declare (function list-size (list) fixnum)) 20:17:34 ??? self-evaulating??? 20:17:50 żżż is it??? 20:17:58 remember that quite a lot of ye olde lisp code was written by masters students 20:18:43 sdemarre [~serge@109.134.154.83] has joined #sbcl 20:18:53 they were not all Guy Steele 20:19:20 wow, look at *special-code-sizes* 20:20:06 estimate-code-size-1 calls itself recursively, I guess that's why it uses throw instead of return 20:20:20 *stassats* sees rafters going through the dangerous waters of LOOP 20:20:26 (pop rafter) and so on 20:22:49 i guess it's trying to do the same with DUPLICATABLE-CODE-P function, only that it doesn't have the catch tag (anymore) 20:30:33 shoes-off [daimrod@sbrk.org] has joined #sbcl 20:32:07 -!- shoes-off is now known as daimrod 20:33:30 -!- daimrod [daimrod@sbrk.org] has quit [Remote host closed the connection] 20:34:11 daimrod [daimrod@sbrk.org] has joined #sbcl 20:34:35 -!- drmeister1 [~drmeister@farnsworth.chem.temple.edu] has quit [Remote host closed the connection] 20:35:12 -!- daimrod [daimrod@sbrk.org] has quit [Excess Flood] 20:36:21 daimrod [daimrod@sbrk.org] has joined #sbcl 20:38:01 *stassats* just wanted to use LOOP inside LOOP 20:38:12 and it could probably work 20:42:32 so, how about we get rid completely of this code duplication conundrum and duplicate it only if speed > space? 20:43:33 That's on you. My working tree (and project queue) is full of changes to gencgc. (-: 20:43:53 the only place where this *loop-before-loop* and *loop-after-body* can be different is LOOP-HACK-ITERATION 20:46:10 -!- daimrod [daimrod@sbrk.org] has quit [Excess Flood] 20:50:51 In fact, I have to run. 20:50:53 -!- nyef [~nyef@c-50-157-244-41.hsd1.ma.comcast.net] has quit [Quit: G'night all.] 20:52:17 -!- angavrilov [~angavrilo@217.71.227.190] has quit [Ping timeout: 248 seconds] 20:56:48 very weird, it doesn't appear to me that this code-size estimation has any effect 20:57:11 i just can't construct a loop where it's above the threshold 21:02:37 i can now 21:02:37 lurch_ [~lurch_@d54C19336.access.telenet.be] has joined #sbcl 21:03:36 daimrod [daimrod@sbrk.org] has joined #sbcl 21:05:43 Munksgaard [~philip@80-71-135-72.u.parknet.dk] has joined #sbcl 21:05:47 #join #lisp 21:06:01 -.- 21:08:00 so, basically, if it sees (loop for y = (block nil (print 10)) for z = 10 then 20 do (print x)), it thinks the block is too high a cost to duplicate and uses (IF #:LOOP-NOT-FIRST-TIME (SETQ Z 20) (PROGN (SETQ #:LOOP-NOT-FIRST-TIME T) (SETQ Z 10))) to avoid having to repeat initialization and iteration sequence twice 21:09:40 well, it seems like removing this constraint isn't going to cause any problems with existing code, people should put expensive things into functions 21:11:07 -!- davazp [~user@178.167.167.177.threembb.ie] has quit [Ping timeout: 260 seconds] 21:12:05 brave souls can later introduce more robust and meaningful methods of code size estimation, the current one is just bogus 21:13:23 -!- sdemarre [~serge@109.134.154.83] has quit [Ping timeout: 256 seconds] 21:13:39 *stassats* thinks on what to put into NEWS pessimization: loop no longer joins different code in initialization and iterations clauses 21:15:56 -!- Bike [~Glossina@174-25-48-1.ptld.qwest.net] has quit [Ping timeout: 256 seconds] 21:23:28 Bike [~Glossina@174-25-48-1.ptld.qwest.net] has joined #sbcl 21:25:38 davazp [~user@178.167.200.127.threembb.ie] has joined #sbcl 21:39:16 -!- lurch_ [~lurch_@d54C19336.access.telenet.be] has quit [Quit: lurch_] 21:44:57 a possible optimization may be to allow to move constant expressions 21:45:10 but that's probably better handled in another place in the compiler 21:49:43 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl 21:52:29 -!- prxq [~mommer@mnhm-4d013913.pool.mediaWays.net] has quit [Quit: Leaving] 21:59:16 -!- Munksgaard [~philip@80-71-135-72.u.parknet.dk] has quit [Read error: Connection reset by peer] 22:01:41 Munksgaard [~philip@80-71-135-72.u.parknet.dk] has joined #sbcl 22:06:29 -!- Munksgaard [~philip@80-71-135-72.u.parknet.dk] has quit [Ping timeout: 248 seconds] 22:11:52 -!- kanru [~kanru@66.207.208.98] has quit [Ping timeout: 246 seconds] 22:14:55 hm. sb-alien:boolean seems to default to being 64 bits, while the x86-64 ABI says that bool is 8 bits. 22:18:10 -!- segv- [~mb@95-91-243-225-dynip.superkabel.de] has quit [Remote host closed the connection] 22:19:30 foom: it defaults to a word. 22:19:46 That seems wrong, doesn't it? 22:19:59 If you declare a function as returning boolean, you get garbage 22:20:20 (because the ABI only promises anything about the contents of the low 8 bits) 22:21:06 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 22:22:05 it's boolean, not bool. 22:22:20 The last bug report complained it isn't an int, like the runtime does. 22:22:33 huh? 22:23:19 IMO, having something called boolean that doesn't map to the obvious thing, _Bool (C) or bool (C++), is dangerous for users. 22:23:23 There's no obviously right default width that I can see. 22:24:03 The x86-64 psABI defines the width. 22:24:03 what do we do about all the pre-existing code? 22:24:15 Perhaps deprecate it and make a new one called bool? 22:24:51 and unexport boolean 22:24:55 yeah, if we had type named bool, then I'd make it always be 8 bits. 22:25:35 yay, let's break perfectly correct code to punish people who can read instead of only assuming. 22:26:56 Oh great, it's wrong in cffi too. 22:32:19 read? read what, the docs don't say anything about the widths of the types! 22:32:33 it says you can specify it, but not that the default is incorrect. 22:35:17 incorrect assuming that boolean and _Bool are the same type. 22:35:22 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: mental vacuum] 22:35:51 The printed representation is pretty clear: # 22:36:18 Yes, once I looked there, it was completely obvious. 22:42:10 drmeister1 [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 22:43:26 Also, hardcoding 8 is of course wrong, because it's an ABI-dependent value. 22:46:06 parenthetically, there's also that, as a return type, boolean with word width was a nice default: AFAIK, it's only recently that compilers have started leaving garbage in high bits. 22:52:32 ...course, there's another problem that (boolean 8) as a return value doesn't appear to actually work, anyways. 22:53:40 that is, it generates "TEST RAX, RAX" 22:53:54 p_l|omoikane [~pl@81-18-213-39.static.chello.pl] has joined #sbcl 23:04:58 did we sign/zero extend the value before that? 23:05:09 nope. 23:05:15 sigh. 23:05:20 we do if I use char 23:05:36 and then do the (not (zerop val)) myself 23:06:04 then it turns into: 23:06:04 ; 30F: FFD3 CALL RBX 23:06:04 ; 311: 4883C410 ADD RSP, 16 23:06:04 ; 315: 480FBEC0 MOVSX RAX, AL 23:06:04 ; 319: 48D1E0 SHL RAX, 1 23:06:04 ; 31C: 4885C0 TEST RAX, RAX 23:06:06 ; 31F: BA4F001020 MOV EDX, 537919567 23:06:08 ; 324: 41BB17001020 MOV R11D, 537919511 23:06:10 ; 32A: 490F44D3 CMOVEQ RDX, R11 23:06:25 but with (boolean 8), it turns into: 23:06:26 ; F88: FFD3 CALL RBX 23:06:26 ; F8A: 4883C410 ADD RSP, 16 23:06:26 ; F8E: 4885C0 TEST RAX, RAX 23:06:26 ; F91: BA4F001020 MOV EDX, 537919567 23:06:26 ; F96: 41BB17001020 MOV R11D, 537919511 23:06:28 ; F9C: 490F44D3 CMOVEQ RDX, R11 23:09:37 at least it's decent code (: 23:20:14 `(logtest ,alien ,(ldb (byte (alien-boolean-type-bits type) 0) -1)) in code/host-alieneval.lisp:669 seem correct to me. 23:33:06 we also happily accept (boolean 0) as an alien type. 23:50:19 ASau` [~user@p5797EE12.dip0.t-ipconnect.de] has joined #sbcl 23:53:34 -!- ASau [~user@p5797EE5F.dip0.t-ipconnect.de] has quit [Read error: Operation timed out]