00:00:03 yea, all I could see was that the SIGSEGV occurred after the fork and before any fcntl syscall 00:04:32 I'll get you some more info when I get home 00:09:08 I have OpenBSD installed here how can chek this 00:44:01 -!- MrMc [~user@91-65-142-36-dynip.superkabel.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 00:58:18 -!- homie` [~levgue@xdsl-78-35-129-49.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 01:54:41 prxq_ [~mommer@mnhm-590c1a8c.pool.mediaWays.net] has joined #sbcl 01:57:35 -!- prxq [~mommer@mnhm-590c0af9.pool.mediaWays.net] has quit [Ping timeout: 248 seconds] 05:23:08 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 06:37:36 -!- Krystof [~user@81.174.155.115] has quit [Ping timeout: 256 seconds] 06:47:48 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 258 seconds] 07:20:49 sdemarre [~serge@91.176.62.153] has joined #sbcl 07:26:07 chturne [~chturne@2.26.61.222] has joined #sbcl 08:07:52 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 08:15:32 -!- chturne [~chturne@2.26.61.222] has quit [Ping timeout: 260 seconds] 08:52:18 -!- prxq_ is now known as prxq 10:22:42 akovalen` [~anton@95.72.170.186] has joined #sbcl 10:24:24 -!- akovalenko [~anton@95.72.102.59] has quit [Ping timeout: 240 seconds] 10:49:01 tsuru``` [~charlie@adsl-98-87-43-94.bna.bellsouth.net] has joined #sbcl 10:50:23 -!- tsuru`` [~charlie@adsl-74-179-17-157.bna.bellsouth.net] has quit [Ping timeout: 245 seconds] 10:50:26 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 10:50:36 -!- ChanServ has set mode +o nikodemus 11:08:00 -!- cmm [~cmm@bzq-109-67-212-191.red.bezeqint.net] has quit [Remote host closed the connection] 12:21:12 chturne [~chturne@2.26.61.222] has joined #sbcl 12:47:11 -!- chturne [~chturne@2.26.61.222] has quit [Ping timeout: 248 seconds] 12:51:49 homie [~levgue@xdsl-84-44-155-130.netcologne.de] has joined #sbcl 12:55:50 -!- akovalen` is now known as akovalenko 13:34:43 LiamH [~healy@pool-108-45-22-54.washdc.east.verizon.net] has joined #sbcl 15:59:00 nikodemus: did you miss the pkhuong's note on fall-through jump elimination w.r.t bug 883500 ? 16:08:31 i did 16:08:36 miss it, that it 16:08:45 is, even. aargh 16:08:46 fixes bug 883500 for me 16:09:03 * http://github.com/akovalenko/sbcl-win32-threads/commits/5d87a6a6c8341e64a43d8008d8cd2bd6770d68ba 16:09:44 thanks 16:10:54 though it may need a review of someone more qualified -- I've just had to do it myself using the information that pkhuong shared here :) 16:15:35 looks good to me 16:15:47 i'll quibble about the commit message, though :) 16:15:57 that's a changelog entry :) 16:22:19 actually, i need to think about this a bit more 16:27:06 nikodemus: as soon as you see anything semantically wrong (i.e. not a style issue), please document it somewhere if you won't have time for fixing it (one-liner message here will be enough) 16:28:53 i'll note it on the lp if there are issues 16:37:00 ok. i think your fix is /a/ correct fix. another possibility would be to test for drop-thru-p or set it if deciding to delete the jump 16:37:54 okay, I'm prepared to resolve any conflict in favor of the mainline here :) 16:38:26 i'll commit yours with a KLUDGE? pkhuong plz help comment :) 16:47:10 (or (not (ir2-block-%trampoline-label 2block)) (ir2-block-dropped-thru-to 2block)) ; is what i'll commit 16:48:32 Heh, as I have no customers for anything sbcl-based nowadays, I could think more carefully on such bugs :) But a mere though that somewhere, someone can be compiling CL into corrupted code still upsets me much. 16:53:08 yeah 16:53:25 there's a reason i tagged it as high-importance 17:04:00 drdo [~drdo@85.207.54.77.rev.vodafone.pt] has joined #sbcl 17:04:02 akovalenko: i don't see the problem in delete-directory -- it uses TRUENAME to normalize the pathname 17:05:26 Can someone point me in the right direction about how to use sbcl's assembler? 17:06:00 for what purpose? 17:06:20 sb-cga and sb-rotate-byte might do as examples, depending on what you're trying to do 17:06:35 nikodemus: true, I was confused here (all my delete-directory changes seem to be useless). 17:08:45 nikodemus: it would be possible to use truename in delete-file as well, but a new race condition would be introduced this way, and we already have enough of them in filesystem stuff. 17:08:47 nikodemus: I'm looking for just the assembler, instruction args -> integers 17:08:50 nyef [~nyef@64.134.124.204] has joined #sbcl 17:08:56 specifically for x86-64 17:08:59 Hello all. 17:09:44 Hey nyef 17:11:19 Anything interesting going on? 17:14:50 Mostly on bug tracker, probably. Bug 883500 (Marsden's (mod (mod...))) is no hot news, eh? 17:16:09 Heh. Looks like optimizing compilers are tricky things to work on after all. 17:17:28 I've now got a tree in which the build process no longer involves symlinks. 17:17:59 akovalenko: since DELETE-FILE calls TRUENAME /anyways/ i think using it instead of merge-pathnames ends actually being less racy :) 17:18:08 -!- LiamH [~healy@pool-108-45-22-54.washdc.east.verizon.net] has quit [Quit: Leaving.] 17:19:12 drdo: i meant, what do you want to use it for 17:19:46 do you want to use it as a backend of your own compiler? or do you want to write your bottleneck function as assembly? or something else? 17:20:19 Still working on moving all of the build products to somewhere under output/, but it's a good start. 17:20:36 nikodemus: it really, really shouldn't (I've forgotten that I've removed that side-effective truename in my branch) 17:21:22 well, "open should open once" is probably the most important of all FS race reductions, still waiting to be implemented.. 17:21:32 nikodemus: the first one :) 17:23:59 drdo: alien-callback-assembler-wrapper is the closest thing to an example of that, i think 17:24:09 drdo: Hang on, look for something called "sorcery" in http://www.lisphacker.com/temp/ . 17:24:18 in src/compiler//c-call.lisp 17:24:36 akovalenko: true 17:25:03 drdo: The .tgz, I think. 17:25:31 drdo: Uses sb-assem on an x86 host as a basis for spitting out a win32 executable file. 17:30:02 Where can i find the code that generates the instructions? 17:30:57 Generates in what sense? 17:31:10 The actual definitions for the encoding? 17:34:10 The code that takes a (move foo bar) and spits out a bunch of integers 17:34:23 Ah. 17:34:25 the actual assembler 17:34:35 It's a touch sprodden out. 17:35:03 There's some magic in SYS:SRC;COMPILER;ASSEM.LISP, and some in SYS:SRC;COMPILER;TARGET;INSTS.LISP. 17:37:07 And then there's some stuff specifically for MOVE in SYS:SRC;COMPILER;TARGET;MOVE.LISP, and I forget where the stuff that backs that up is... 17:38:31 thanks, i can just go from there, was just trying to find out where to look :) 17:38:43 Okay, good luck. 17:39:10 Oh! The arm-port-log might also mention some stuff about implementing a new backend for the assembler. 17:41:45 And there's something completely stupid related to cross-builds somewhere in this mess. 17:44:55 Ah, found it. In SYS:SRC;COMPILER;X86;INSTS.LISP, function BREAK-CONTROL has a FIXME-comment about BYTE-IMM-CODE. 17:46:55 damn, x86 makes me cry 17:47:10 ... that's from the disassembler, define-instruction-format uses EVAL at expand-time to define the field accessors as macros /on the host only/. 17:47:34 Needless to say, I was horrified when I finally figured out what was going on. 18:01:21 Bwah? SB-EXT:WAIT-FOR? WTF is -this-?!? 18:01:44 I mean, other than a throwback to lispm-style multiprocessing, that is. 18:07:59 ... Has anyone noticed that planet.sbcl doesn't show the two most recent commits on the front page? 18:17:49 throwback is pretty close... 18:20:26 but, it respects deadlines and behaves much better wrt. CPU than two-liner #+sbcl process-wait-for hacks i keep coming across in various projects 18:20:58 Fair enough, I guess. 18:21:53 On the other hand, I think I'd almost rather spawn a thread to sit on an inotify or similar and post to a mailbox when something happens. 18:22:37 but that would be /sane/! 18:22:58 Not quite. You're still involving a thread, which is obnoxiously heavy-weight for us. 18:23:05 well, true 18:23:13 But at least it doesn't involve a damned polling loop. 18:24:09 *nyef* has spent far too much time trying to figure out how to make CLIM (LispM)-style PROCESS-WAIT things work on a modern system. 18:24:30 but if it's meant to work for things like (eq :done (slot-value x 'foo)) ... then you still need a polling loop unless you have a co-operating writer ... in which case you would have written something sane using a semaphore or mailbox in the first place... 18:25:11 Mmm. Slap an :AFTER on the writer for the slot that tweaks a semaphore, surely? 18:25:41 Oh well. 18:25:43 a condition, surely! 18:25:58 Something like that. 18:26:08 you do realize that slot-value was an arbitrary example? people use process-wait for the silliest things. structure slots. closed over variables. whatever 18:26:49 I think the essential message is that if you're using SB-EXT:WAIT-FOR, you're doing something wrong. 18:27:04 mostly yes 18:27:24 unless you're porting something that already does it wrong using process-wait 18:27:50 (I can just see it now... WAIT-FOR signalling a STYLE-WARNING "You're using SB-EXT:WAIT-FOR. You're doing something wrong." 18:28:08 in which case using WAIT-FOR is probably the correct pick in terms of effort spent and progress made 18:28:12 Sure. 18:28:25 But it's still bad style. (-: 18:30:07 attila_lendvai [~attila_le@2.132.32.138] has joined #sbcl 18:30:07 -!- attila_lendvai [~attila_le@2.132.32.138] has quit [Changing host] 18:30:07 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 18:32:14 Okay, time I got going. 18:32:23 -!- nyef [~nyef@64.134.124.204] has quit [Quit: Bye all, I'll be back later.] 18:36:50 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 18:51:00 LiamH [~healy@pool-108-45-22-54.washdc.east.verizon.net] has joined #sbcl 19:18:39 pers [~user@96-25-162-104.gar.clearwire-wmx.net] has joined #sbcl 19:29:23 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 19:29:23 attila_lendvai1 [~attila_le@2.132.32.138] has joined #sbcl 19:29:23 -!- attila_lendvai1 is now known as attila_lendvai 19:29:24 -!- attila_lendvai [~attila_le@2.132.32.138] has quit [Changing host] 19:29:24 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 19:30:25 attila_lendvai1 [~attila_le@2.132.32.138] has joined #sbcl 19:30:36 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 19:31:03 attila_lendvai [~attila_le@2.132.32.138] has joined #sbcl 19:31:03 -!- attila_lendvai [~attila_le@2.132.32.138] has quit [Changing host] 19:31:03 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 19:31:43 homie` [~levgue@xdsl-78-35-164-84.netcologne.de] has joined #sbcl 19:33:12 -!- homie [~levgue@xdsl-84-44-155-130.netcologne.de] has quit [Ping timeout: 240 seconds] 19:33:53 -!- homie` [~levgue@xdsl-78-35-164-84.netcologne.de] has quit [Client Quit] 19:42:05 homie [~levgue@xdsl-78-35-164-84.netcologne.de] has joined #sbcl 20:19:43 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 20:19:52 Hello again all. 20:23:07 lo nyef 20:30:48 -!- attila_lendvai1 [~attila_le@2.132.32.138] has quit [Ping timeout: 240 seconds] 20:31:16 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has left #sbcl 20:34:00 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 260 seconds] 21:00:24 nikodemus [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 21:00:31 Hello nikodemus. 21:00:36 -!- ChanServ has set mode +o nikodemus 21:06:05 hi 21:07:47 *nyef* is trying to get (. output/build-config ; $GNUMAKE -C output/runtime all) to do something useful. 21:09:21 Okay, I have a question. Why do we regenerate sbcl.h so much? 21:11:00 no idea 21:11:25 Ah! sbcl.h being regenerated means I need another -I for the preprocessor. 21:15:57 nyef: dependencies 21:16:28 akovalenko: But we auto-generate dependencies. 21:19:59 Okay, the runtime builds. Time to untangle my working copy and figure out a commit message... 21:20:33 it seems that GNUMakefile doesn't trust autogeneration w.r.t. genesis stuff, forcing sbcl.h: genesis/*.h and everything: sbcl.h.. 21:20:37 which reminds me: does anyone know why we don't build runtime/TAGS by default? 21:21:11 nikodemus: Because... nobody uses it? 21:21:56 am i the only once who likes M-. for C code as well? 21:22:40 i always there was a "it's not good proceduce because of X" type reason 21:22:51 I think it's more that people either don't expect it, or have been badly burned by the limitations on the various tag parsers. 21:23:32 (The system thinks I have 128 functions called "DEFOP" in this file? WTF?) 21:23:42 heh 21:23:54 I use M-., but for Lisp sources it's handled by SLIME :) 21:24:08 it mostly does a pretty good job for our runtime sources 21:24:23 for C runtime, I rely on cedet/semantic stuff most of the time 21:24:54 akovalenko: My usual C style broke the semantic bovinator fairly horribly last time I tried it. 21:27:01 nyef: how does xcode cope? 21:27:17 Honestly? I haven't tried. 21:28:23 if it works better, there's hope that some emacs mode will integrate clang. 21:29:02 Between stupid keyboard problems (somebody switched Ctrl and Fn on me), deranged semi-structured editing (paredit come home, all is forgiven!), and no documented extension interface, I hold out low hopes for it. 21:30:47 ... what is the appropriate name for a path with a ../ segment in it? It's not a "relative" path... 21:34:44 uncanonical 21:35:47 fanpath (: 21:35:57 akovalenko: finally pushed your circular-tree-p fix, thanks 21:36:58 nyef: or even "apocryphal" :) 21:37:28 *akovalenko* has thought of "apocryphal", like a polite wording for "uncanonical" :) 21:38:45 "deuterocanonical path" -- e.g. with no :up's, but with unresolved symlinks :) 21:42:02 I'm thinking to go with "parent-relative path". 21:43:11 I'd take "parent-relative" to mean "../../foo/bar" but not "foo/../bar". 21:43:21 Good enough. 21:43:40 (Specific cases include ../../output/include/, for example.) 21:43:49 that's BAAAD 21:44:00 well, you probably know :) 21:44:22 Well, yes. 21:44:38 Actually, another specific case is ../../output/prefix.def, so there's precedent! 21:45:17 And I'm replacing the ../../ bit with $(BASE_DIR)/, hence needing to know the terms. 21:45:53 "an awful, scary, incorrect kludge" is _the_ term. 21:46:32 I'm not arguing. 21:47:04 The problem came when I needed to include the same makefile fragment from directories at two different depths. 22:03:21 -!- pers [~user@96-25-162-104.gar.clearwire-wmx.net] has quit [Remote host closed the connection] 22:12:30 -!- nikodemus [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 22:14:35 -!- prxq [~mommer@mnhm-590c1a8c.pool.mediaWays.net] has quit [Quit: good night] 22:39:12 -!- sdemarre [~serge@91.176.62.153] has quit [Ping timeout: 240 seconds] 22:59:49 nyef: ISTR you had a plan to hook unwind-protect and NLX with C++ exceptions. How did you get things working for uwps? 23:00:08 I never followed through. 23:00:08 the bit about cleanups not being able to throw exceptions worries me. 23:00:28 Ah, right. That. 23:00:56 Cleanups aren't allowed to UNWIND. 23:01:06 they are in CL, though. 23:01:20 And it turns out that the commonly-used implementations don't prevent it. 23:01:31 (And on WinAPI, they ARE allowed to unwind.) 23:02:06 Yeah, I got nothing. It's as if they write the ABIs for C++ or something. 23:02:12 k. The best I can think of is that cleanups triggered by non-CL exceptions might just cause an abort if it doesn't work. 23:03:07 The thing that really got me was that the non-lisp equivalent to unwind-protect is actually handler-case + re-signal. 23:03:33 yup. 23:03:47 Oh, and you know that we actually have partial integration for this stuff on win32, right? 23:03:56 yes. 23:04:13 I'm doing the usual academic thing and just forking off a subset for now. 23:06:03 There are an awful lot of places in SBCL that refer to src/runtime/sbcl. 23:07:24 nyef: the best thing I can think of is to have catch + resignal for CL NLX, and a cleanup for foreign exceptions. If such a cleanup rethrows and the personality doesn't like it, too bad. 23:07:57 either possibility (it works, or it fails loudly) is better than the current silent failure. 23:08:13 Umm... Somewhat. 23:08:28 I used to know how this had to work. 23:09:03 The UWPs have to catch/re-throw. 23:09:57 but you can't catch everything, can you? 23:10:32 We have to have a personality-routine which checks to see if any lisp handlers can take a C++ exception before the next C frame, and if they can't then don't catch. 23:10:43 Something like that, at least. 23:11:18 And Lisp conditions should properly be reflected through the C++ exception system, too. 23:12:17 really? I figured we could just handle unwinding through the exception system, and do the rest on our own. 23:12:46 Oh, and the ABI typically uses table-based unwinding via DWARF unwind tables. Good luck with that. 23:13:11 LLVM can do that for me ;) 23:22:35 ... Not five feet from the access point, and my wireless connection occasionally goes down to about 50% signal strength. 23:39:30 -!- LiamH [~healy@pool-108-45-22-54.washdc.east.verizon.net] has quit [Quit: Leaving.]