00:16:40 jingtao [~jingtaozf@118.186.129.179] has joined #sbcl 00:19:03 -!- milanj [~milanj_@178-223-149-21.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 02:25:59 -!- blumbri [1000@204.152.219.61] has quit [Ping timeout: 240 seconds] 03:30:23 -!- sdemarre [~serge@91.176.28.91] has quit [Ping timeout: 248 seconds] 03:34:15 sdemarre [~serge@91.176.28.91] has joined #sbcl 03:48:04 attila_lendvai [~attila_le@87.247.50.183] has joined #sbcl 03:48:04 -!- attila_lendvai [~attila_le@87.247.50.183] has quit [Changing host] 03:48:04 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:58:41 -!- nyef [~nyef@pool-70-109-144-138.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 04:55:58 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 276 seconds] 05:00:09 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 05:26:25 -!- antgreen [~user@bas3-toronto06-1177890206.dsl.bell.ca] has quit [Ping timeout: 260 seconds] 05:40:07 -!- homie [~levgue@xdsl-78-35-148-239.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 05:40:22 -!- peddie [~peddie@repl.esden.net] has quit [Quit: peace!] 05:43:53 peddie [~peddie@repl.esden.net] has joined #sbcl 06:22:47 -!- ASau [~user@89-178-95-171.broadband.corbina.ru] has quit [Ping timeout: 240 seconds] 07:02:34 hmm. is there some common sbcl-idiom that could be used instead of (let ((*allow-with-interrupts* *interrupts-enabled*)) (without-interrupts ... (with-local-interrupts ...))) ? 07:04:21 the meaning is "I want to write something that would be interruptible in a carefully designated piece of code, but only if interrupts are already enabled during the call." 07:08:02 -!- akovalenko [~akovalenk@95.72.99.130] has quit [Remote host closed the connection] 07:11:57 akovalenko [~akovalenk@95.72.99.130] has joined #sbcl 07:15:35 -!- jingtao [~jingtaozf@118.186.129.179] has quit [Ping timeout: 240 seconds] 07:17:44 jingtao [~jingtaozf@118.186.129.179] has joined #sbcl 08:27:24 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 08:46:20 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 09:03:35 -!- akovalenko [~akovalenk@95.72.99.130] has quit [Ping timeout: 240 seconds] 09:07:31 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 276 seconds] 09:08:49 akovalenko [~akovalenk@77.51.6.233] has joined #sbcl 10:31:20 milanj [~milanj_@178-223-149-21.dynamic.isp.telekom.rs] has joined #sbcl 10:35:59 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 10:35:59 -!- ChanServ has set mode +o nikodemus 11:06:05 -!- milanj [~milanj_@178-223-149-21.dynamic.isp.telekom.rs] has quit [Ping timeout: 252 seconds] 11:11:37 good day everyone 11:16:27 -!- Phoodus [~foo@68.107.217.139] has quit [Ping timeout: 260 seconds] 11:35:25 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 11:37:32 -!- Kryztof [~user@81.174.155.115] has quit [Ping timeout: 245 seconds] 11:39:31 easyE [mBcRsGbFde@panix2.panix.com] has joined #sbcl 11:39:53 So, sbcl-1.0.53 doesn't build threads for Solaris on x86_64? 11:45:29 But surely the 64bit SPARC code has a common abstraction? 11:50:12 Kryztof [~user@81.174.155.115] has joined #sbcl 11:50:12 -!- ChanServ has set mode +o Kryztof 11:56:39 leuler [~user@p54902E49.dip.t-dialin.net] has joined #sbcl 11:59:54 easyE: i don't know what the status of x86-64 threads on Solaris is, but i do know that we build threads by /default/ only on linux 12:02:58 *akovalenko* found threads on FreeBSD good enough, despite their being disabled by default. It seems that adding :sb-thread is generally worth trying, unless it's known to fail on particular platform. 12:07:46 i think almost all x86oids support threads by now 12:08:18 <= three commits that would reduce unhandled SIGNAL overhead (consing, runtime) by some 4-6 times. 12:14:37 nice 12:14:49 ..what's we have to keep in mind during SBCL hacking is that "people don't use $feature, so it's a waste of time to improve its efficiency" leads to circular reasoning frequently. 12:15:02 *s/what's/what/ 12:16:08 milanj [~milanj_@178-223-149-21.dynamic.isp.telekom.rs] has joined #sbcl 12:18:23 question to compiler hackers: any code like (reduce ... (lambda ...)) is trivially transformable to (dx-flet ... (reduce ...)) [many other things could be substituted for reduce here]. Is there anything (like some defknown for reduce) that makes it possible automatically? 12:19:42 akovalenko: not currently, but it's a long-standing "would like to do that" thing 12:19:53 *akovalenko* once had a macro-defining-compiler-macros for such "downward lambdas".. 12:21:45 one reason i haven't implemented is that i'd really like to make it work as (let ((f arg)) (declare (dynamic-extent f)) ...) but since DX doesn't support plain lambda yet... 12:22:43 still, i certainly have no objections merging such a patch 12:22:45 and it's really great that semantics of #'(lambda ...) is never affected by what precedes an evaluation of this form, as long as its lexical environment remains the same. 12:28:01 *akovalenko* still expects some rocket-scientific answer from SBCL hackers for any compiler-related question like "why such-and-such thing is not there". Hearing something on would-like-to-do-that list instead of "it breaks 100 obscure invariants, as you'll understand in 5 years" is an eternal surprise :) 12:29:42 Well, I've got an openindiana-151a machine that doesn't seem to want to build sbcl-1.0.53 with SB-THREAD. 12:31:51 so my vague recollection is that when dx was added to cmucl it did all of this automatic dxing, and turned out to be problematic 12:32:10 easyE: i suggest you send mail to sbcl-devel and ask jim wise about its status 12:33:10 nikodemus: check. Does the gmane interface work for sending, or do I need to subscribe to sbcl-devel? 12:33:12 cmucl never dealt with its %%nip-values problem though I think 12:37:36 sure, not saying it shouldn't be done. rather that I thought it was one reason for why it wasn't initially done in sbcl 12:48:44 nyef [~nyef@pool-70-109-144-138.cncdnh.east.myfairpoint.net] has joined #sbcl 12:49:01 G'morning all. 12:51:41 easyE: not sure 12:52:47 easyE: though if you're already on sbcl-help, you can post there just as well 12:54:58 easyE: gmane interface generally works for sending to open mailing lists (where you can send without being subscribed). I dunno whether sbcl-devel is open.. 13:05:24 ... Why does PCL use a privileged value for unbound slots, and not our existing unbound-marker-widetag? 13:06:28 would it gain something by using unbound-marker-widetag? 13:07:34 it's not uncommon to need an unique unbound-marker in lisp code, and I never had a desire to reuse some other project's (or even module's) unbound-marker. 13:07:52 nyef: quite possibly historical reasons 13:08:13 Hmm. 13:08:59 of course we can probably have 2^24 different unbound markers 13:09:36 Heh. 2^56 on x86-64, surely? 13:11:21 you kids and your wide registers 13:14:02 Mmm. We'll have to keep nikodemus from trying to take advantage of that extra range. 13:14:37 It seems like every week or so, he's done something else that breaks some aspect of the PPC port. 13:14:54 Backend? Whichever. 13:17:39 ..one more thing about "downward lambdas": mainline %handler-bind macro transforms its arguments along these lines, but, apparently, it discriminates against people using #'(lambda ...) (-: 13:39:07 nyef: i'm sorry about the ppc breakage 13:39:22 i'll try to locate a reasonable ppc host to test on in the future 13:39:42 nikodemus: It also looks like you could do with testing non-threaded x86oids every so often. 13:39:51 yeah 13:40:36 I'm considering putting together some sort of assessment of what would be involved in moving x86-64 to a split-stack, partitioned-register-set model. 13:41:04 Notably, as a build-time option. 13:41:11 re. unbound slot marker. we don't want lisp code to be able to ever see unbound symbol marker in normal situations, but we /do/ want lisp code to be able to see and handle the pcl slot unbound marker 13:41:29 Really? 13:41:36 the latter? definitely 13:41:47 they're stored in simple-vectors, after all 13:41:54 and in cons cells, and whatnot 13:42:07 and users using standard-instance-access can see them 13:42:08 What's your assessment of the effect of the unbound-marker in the current implementation of SVIT? 13:42:20 Hum. 13:42:30 It's actually part of our public interface? 13:43:06 FWIW I happen to agree with nikodemus here. PCL is written in Lisp, while code dealing with unbound markers is lispy-assembly generally (with a single exception of SVIT, right) 13:43:58 sb-pcl:+slot-unbound+ is public, yes 13:44:20 Okay, guess messing with that is out... 13:44:29 do you mean re. lisp code comparing slot-unbound-marker in svit? 13:44:59 nikodemus: svit compares with unbound-marker-widetag, iirc 13:45:15 i think that's ok. low-level internals code is low-level internals code 13:46:15 but for user code to get an unexpected unbound marker would be nasty and hard to debug -- (setf *tmp* (standard-instance-access ...)) ; oops, if we share the marker, *tmp* just became unbound... 13:46:17 btw, it's possible to have a representation of thread-local binding where no separate notion of "thread-local unboundness" is needed. 13:46:26 SVIT currently uses SAP-REF-LISPOBJ to grab the slot contents, then uses GET-LISP-OBJ-ADDRESS and compares to a couple of tag values. 13:47:31 akovalenko: This I have to hear, given the existence of MAKUNBOUND. 14:11:22 LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has joined #sbcl 14:16:04 nyef: thank you for taking care of unsigned longs. Btw, initially I did lispobj* => lispobj there, then I asked here and you recommended char*/void*. Then I switched to char* and committed that, then (today) I pulled your code with.. lispobjs. 14:16:45 (unsigned wrong*) ;; <== let every SBCL developer remember... 14:18:37 Not a problem. It was actually something I wanted to do when I moved the code over to gc-common and made it work on (and used on) cheneygc. 14:20:16 now it would be great to know if there's a target where printf doesn't support %zu.. 14:21:34 'cause printf ("we have %"SIZEFMT, ...) seems too ugly, but it's unavoidable if %zu or %tu is unsupported somewhere.. 14:22:17 well, they /are/ unsupported in msvcrt, but fortunately -D__USE_MINGW_ANSI_STDIO is there 14:26:09 patch them early after .54, and see if anything breaks? 14:26:35 will do. 14:27:30 alternatively write a tiny test.c and send it to sbcl-devel, asking people to report if it works 14:50:47 Hrm... So, it looks like a PS3 would be easier to get running (if the firmware is old enough), but the XBox 360 might be the better system overall. Except that the XBox requires patching the hardware and would be slow/unreliable to start up. :-/ 15:05:34 antgreen [~user@bas3-toronto06-1177698358.dsl.bell.ca] has joined #sbcl 16:03:03 Guest3003 [~levgue@xdsl-78-35-136-207.netcologne.de] has joined #sbcl 16:14:09 -!- milanj [~milanj_@178-223-149-21.dynamic.isp.telekom.rs] has quit [Ping timeout: 260 seconds] 16:17:10 -!- Guest3003 is now known as homie` 16:17:36 -!- homie` is now known as homie 16:30:24 cpc26 [~cpc26@fsf/member/cpc26] has joined #sbcl 17:55:11 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 244 seconds] 18:01:05 chp [~chp@c-68-45-180-238.hsd1.nj.comcast.net] has joined #sbcl 18:06:29 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Remote host closed the connection] 18:11:36 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Quit: Leaving.] 18:17:42 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Read error: Operation timed out] 18:28:35 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 19:04:25 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 19:28:14 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 19:28:14 -!- ChanServ has set mode +o nikodemus 19:32:29 LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has joined #sbcl 19:44:23 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 240 seconds] 19:48:43 cpc261 [~cpc26@fsf/member/cpc26] has joined #sbcl 19:49:57 -!- cpc261 [~cpc26@fsf/member/cpc26] has quit [Client Quit] 19:51:11 -!- cpc26 [~cpc26@fsf/member/cpc26] has quit [Ping timeout: 240 seconds] 19:53:56 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 19:53:56 -!- ChanServ has set mode +o nikodemus 19:56:05 -!- homie [~levgue@xdsl-78-35-136-207.netcologne.de] has quit [Read error: Operation timed out] 19:56:54 homie` [~levgue@xdsl-78-35-179-221.netcologne.de] has joined #sbcl 20:00:46 nikodemus: oh, you're back. 20:01:32 Having pretty much written up my answer as an email now, I think I'll just send it anyway. 20:02:20 ok :) 20:03:43 -!- homie` [~levgue@xdsl-78-35-179-221.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 20:05:35 -!- daimrod [~daimrod@sbrk.org] has quit [Quit: leaving] 20:08:42 milanj [~milanj_@178-223-149-21.dynamic.isp.telekom.rs] has joined #sbcl 20:09:49 homie [~levgue@xdsl-78-35-179-221.netcologne.de] has joined #sbcl 20:13:10 ASau [~user@89-178-201-27.broadband.corbina.ru] has joined #sbcl 20:18:12 lichteblau: thanks for the comments 20:18:36 i respond tomorrow when i'm back on a proper computer 20:19:11 not in the mail: comments regarding relocation 20:19:29 1. my fixedp argument to os_validate is stupid; those modes should be two separate functions 20:20:23 2. my relocate.c code uses "long" in a Windows-unsafe fashion; that should be search&replaced with a type that makes sense 20:21:48 i wonder if we could organize a "clean up the types in the runtime" week 20:22:16 in the sense of merging anton's type work? or going beyond that? 20:23:16 i haven't actually looked at his code in a long time, but yes, i did mainly mean long and unsigned long cleanups 20:25:26 hah. sure! I'm really looking forward to merging all of akovalenko's windows stuff, _except_ for this typing diff. If you take care of that, I owe you at least several beers. 20:26:19 ok. i'll touch base with him on it tomorrow 20:34:58 How about adding -Werror to CFLAGS, globally? 20:41:22 daimrod [~daimrod@sbrk.org] has joined #sbcl 20:42:28 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 260 seconds] 20:42:46 -!- daimrod [~daimrod@sbrk.org] has quit [Client Quit] 20:44:51 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 20:44:51 -!- ChanServ has set mode +o nikodemus 20:45:05 daimrod [~daimrod@sbrk.org] has joined #sbcl 20:52:20 -!- milanj [~milanj_@178-223-149-21.dynamic.isp.telekom.rs] has quit [Quit: Leaving] 21:03:59 ..what should I use if I need define-source-transform that lives in peace with other source transforms if they're present? 21:04:50 on the same op? 21:05:09 yep. 21:05:20 fold them into one, or use a deftransform 21:06:12 yuo could also use a compiler macro 21:06:19 I'm not smart enough for deftransform yet, or so it seems. 21:07:57 I want to conduct a quick experiment with "downward lambdas", and I know what to do if I see a /source/ form which has (lambda ..) as an argument. What it should look like when I have deftransform-style lvars?.. 21:10:37 i don't have emacs or sbcl hNdy 21:10:52 aaegh. handy, so answering this gets tricky 21:12:37 but... there's stuff in ir1util.lisp, and looking at eg. member transforms might help 21:12:54 well, the statement that it's *possible* at that stage is useful enough 21:13:42 but i do thing the lambda -> dxflet transfrom does want to either be a source transform, or part of the compiler itself 21:14:07 btw, why aren't macros expanded in arguments before source transforms? (it seems they can't do it correctly by themselves 'cause there's no &environment).. 21:14:36 this way, each source transform can get either #'(lambda ...) or (lambda ...), for example 21:14:47 I'd make it part of the compiler; it's clearly preferable to annotate a couple defknown. 21:14:53 source tramsforms can use *lexenv* 21:16:18 thanks 21:17:20 for now, I just want to give it a try and see what happens, so I use what I know how to use instead of learning new stuff (I would prefer compiler macros if it weren't obviously out-of-style) 21:25:30 compiler macros are fine. the only problem is that we don't have def!compilermacro, so using them inside sbcl is sometimes tricky 21:27:09 gabnet [~gabnet@245.23.67.86.rev.sfr.net] has joined #sbcl 21:47:01 -!- sdemarre [~serge@91.176.28.91] has quit [Ping timeout: 240 seconds] 21:47:39 -!- chp [~chp@c-68-45-180-238.hsd1.nj.comcast.net] has quit [Quit: Lost terminal] 22:04:13 -!- antifuchs [~foobar@care.boinkor.net] has quit [Quit: ZNC - http://znc.sourceforge.net] 22:06:43 antifuchs [~foobar@care.boinkor.net] has joined #sbcl 22:09:46 -!- gabnet [~gabnet@245.23.67.86.rev.sfr.net] has quit [Quit: Quitte] 22:32:45 drdo` [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 22:34:23 -!- drdo [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 22:51:45 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Remote host closed the connection] 23:01:04 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 23:01:04 -!- ChanServ has set mode +o nikodemus 23:13:02 -!- daimrod [~daimrod@sbrk.org] has quit [*.net *.split] 23:13:02 -!- leuler [~user@p54902E49.dip.t-dialin.net] has quit [*.net *.split] 23:13:04 -!- sshirokov [~sshirokov@ghanima.slavasaur.com] has quit [*.net *.split] 23:13:04 -!- drdo` [~drdo@85.207.54.77.rev.vodafone.pt] has quit [*.net *.split] 23:13:05 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [*.net *.split] 23:13:05 -!- lichtblau [~user@port-92-195-21-77.dynamic.qsc.de] has quit [*.net *.split] 23:13:05 -!- dsp_ [~tt@lebesgue.cowpig.ca] has quit [*.net *.split] 23:13:07 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [*.net *.split] 23:13:07 -!- akovalenko [~akovalenk@77.51.6.233] has quit [*.net *.split] 23:13:07 -!- jingtao [~jingtaozf@118.186.129.179] has quit [*.net *.split] 23:13:07 -!- joshe [~joshe@opal.elsasser.org] has quit [*.net *.split] 23:13:08 -!- tsuru` [~charlie@adsl-74-179-25-191.bna.bellsouth.net] has quit [*.net *.split] 23:13:08 -!- cow-orker [~foobar@pogostick.net] has quit [*.net *.split] 23:13:08 -!- blackwol` [~blackwolf@ool-45763eb0.dyn.optonline.net] has quit [*.net *.split] 23:13:09 -!- redline6561 [~redline65@li69-162.members.linode.com] has quit [*.net *.split] 23:13:09 -!- spacebat [~spacebat@ubermonkey.net] has quit [*.net *.split] 23:13:09 -!- jiacobucci [~jiacobucc@gw-asdl.ae.gatech.edu] has quit [*.net *.split] 23:13:09 -!- deepfire [~deepfire@80.92.100.69] has quit [*.net *.split] 23:13:11 -!- antifuchs [~foobar@care.boinkor.net] has quit [*.net *.split] 23:13:11 -!- christoph_debian [~user@oteiza.siccegge.de] has quit [*.net *.split] 23:13:12 -!- reb```` [user@nat/google/x-qurgoiodkpqzlcym] has quit [*.net *.split] 23:13:12 -!- slyrus [~chatzilla@adsl-99-49-14-228.dsl.pltn13.sbcglobal.net] has quit [*.net *.split] 23:13:13 -!- MikeSeth [~me@unaffiliated/mikeseth] has quit [*.net *.split] 23:13:13 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [*.net *.split] 23:13:14 -!- lisppaste2 [~lisppaste@tiger.common-lisp.net] has quit [*.net *.split] 23:13:14 -!- foom [~jknight@ita4fw1.itasoftware.com] has quit [*.net *.split] 23:14:01 drdo` [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 23:14:02 antifuchs [~foobar@care.boinkor.net] has joined #sbcl 23:14:02 LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has joined #sbcl 23:14:02 akovalenko [~akovalenk@77.51.6.233] has joined #sbcl 23:14:02 jingtao [~jingtaozf@118.186.129.179] has joined #sbcl 23:14:02 joshe [~joshe@opal.elsasser.org] has joined #sbcl 23:14:02 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 23:14:02 christoph_debian [~user@oteiza.siccegge.de] has joined #sbcl 23:14:02 tsuru` [~charlie@adsl-74-179-25-191.bna.bellsouth.net] has joined #sbcl 23:14:02 slyrus [~chatzilla@adsl-99-49-14-228.dsl.pltn13.sbcglobal.net] has joined #sbcl 23:14:02 cow-orker [~foobar@pogostick.net] has joined #sbcl 23:14:02 deepfire [~deepfire@80.92.100.69] has joined #sbcl 23:14:02 lichtblau [~user@port-92-195-21-77.dynamic.qsc.de] has joined #sbcl 23:14:02 blackwol` [~blackwolf@ool-45763eb0.dyn.optonline.net] has joined #sbcl 23:14:02 dsp_ [~tt@lebesgue.cowpig.ca] has joined #sbcl 23:14:02 jiacobucci [~jiacobucc@gw-asdl.ae.gatech.edu] has joined #sbcl 23:14:02 spacebat [~spacebat@ubermonkey.net] has joined #sbcl 23:14:02 redline6561 [~redline65@li69-162.members.linode.com] has joined #sbcl 23:14:02 reb```` [user@nat/google/x-qurgoiodkpqzlcym] has joined #sbcl 23:14:02 MikeSeth [~me@unaffiliated/mikeseth] has joined #sbcl 23:15:09 lisppaste2 [~lisppaste@tiger.common-lisp.net] has joined #sbcl 23:15:09 foom [~jknight@ita4fw1.itasoftware.com] has joined #sbcl 23:15:27 daimrod [~daimrod@sbrk.org] has joined #sbcl 23:15:27 leuler [~user@p54902E49.dip.t-dialin.net] has joined #sbcl 23:15:27 sshirokov [~sshirokov@ghanima.slavasaur.com] has joined #sbcl 23:15:32 http://www.sw4me.com/private/sbcl-backtrace-linux-amd64-kernel-3.1.txt 23:16:08 ^^^ really huge backtrace (too big for lisppaste) for a pending handler run during GC (mainline SBCL) 23:17:18 ..kernel version is likely to be important (never seen something like that on 3.0 kernels, seen on two 3.1 kernels on several sbcls, including stock debian's 1.0.53) 23:19:25 ..the constants, 18446744073 and a context sap #X2AAAAAD64DA0, are stable, but otherwise the error happens in random places, usually when SBCL compiles something 23:21:35 ..topmost C address (#x4125CB, above get-internal-run-time) is in low_level_handle_now_handler, according to addr2line. 23:21:47 ..any ideas? 23:24:29 drdo`` [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 23:25:49 -!- drdo` [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 23:25:55 ... Not supposed to be running handlers during GC in the first place, surely? 23:26:14 yeah. not supposed to. 23:27:05 btw, the presence of (get-internal-run-time) in the backtrace is stable as well. 23:28:41 it may be a linux issue as well, but (1) it doesn't mean that linux will be fixed, some new behavior may become an officially right thing instead, and (2) I would like to know what it is anyway, to report a bug against the kernel, maybe 23:30:53 *akovalenko* recalls debugging a problem with experimental (and very young) SBCL/windows on experimental Wine with an experimental patch for weird and experimental FPU exception handling... I noticed that somemites I get a garbage in FPU context. **And that turned out to be a linux kernel issue!** 23:32:27 Mmm... I'm really not up for trying to figure out signal-handling issues right now. 23:36:26 well, relax then. It normally happens after some uptime (from some moment all linux SBCLs start to have problems), so another opportunity to track this down might not happen too soon. That's why I wanted to share this while I'm here with my addr2line... 23:36:45 are we in a freeze yet? 23:38:26 nyef: more accidental workage on x86-64. I think our THREAD_STRUCT_TO_EXCEPTION_PORT is bogus in 64-bit-land 23:38:35 who did this crap in the first place? 23:39:33 slyrus: I'm going to fully disclaim responsibility for any of the OSX stuff. I only got an OSX box a couple of months ago. 23:40:04 yeah, I'm pretty sure it was me :) 23:40:37 Mmm... although I seem to recall having written some of the original thread-context-hacking games. 23:40:46 you did the hard parts :) 23:41:08 I did the trivial monkey-see monkey-do mach stuff 23:41:18 Hah! Monkeying with an interrupt context is easy, the mach stuff is insane. 23:42:21 I'm assuming we're frozen -- after the freeze I'd like to make all these compiler warnings go away on darwin/x86-64 23:42:31 is that g5 working for you? 23:42:47 The g4, you mean? Yeah. 23:42:57 yeah 23:43:06 Problem is, it takes 50 minutes for a build, and nikodemus keeps breaking stuff. 23:43:21 heh 23:43:30 that's better than him not breaking anything, imo 23:44:22 Most recently, he did something with backtrace that broke the unwind-to-frame-and-call tests. Before that, he was surprised to learn that we had PPC threads for a year when I reported random lockups in one of the threads.pure.lisp tests... 23:46:23 We might not be frozen yet, actually, although it's late enough in the cycle that I wouldn't want to commit anything anyway. 23:46:43 (And I do have a stack of PPC changes to go in -- dynamic-extent stuff, primarily.) 23:49:33 my stuff is seemingly trivial, but I'll hold off until next cycle 23:50:57 Oh, and I still have the stack-scrubbing stuff that needs to go in at some point. 23:51:54 (You want works by accident? Let's scrub the C stack from C, taking the address of a local variable in the current stack frame as a starting point...)