00:06:49 gbyers [n=gb@c-68-35-15-143.hsd1.nm.comcast.net] has joined #ccl 01:14:10 palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has joined #ccl 01:30:34 milanj [n=milan@212.200.192.111] has joined #ccl 02:04:44 Is there a guide in the source to the register aliases in LAP? 02:05:02 I'm wondering specifically about fn and gs 02:07:30 see ccl:compiler;X86;X8664;x8664-arch.lisp 02:07:52 on x8664, fn is r13 02:09:32 rme: thanks 02:09:39 conceptually, though, what is stored there? 02:09:39 gs is rcontext on most x8664 ports. on win64 and darwin/x8664, rcontext is a gpr---I think r11. 02:09:45 in fn? 02:09:48 yeah 02:09:53 it seems to be a pointer to the start of the current function? 02:09:58 that's the current function, yes. 02:10:21 ok, so the offsets from that can denote constants in the function, or jump targets. thanks. 02:15:08 rme: thanks for pointing out that file, it's a pretty interesting read... I'm learning a lot about my CPU :) 02:19:53 -!- milanj [n=milan@212.200.192.111] has quit ["This computer has gone to sleep"] 03:14:02 palter_ [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has joined #ccl 03:14:02 -!- palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has quit [Read error: 104 (Connection reset by peer)] 03:14:05 -!- palter_ is now known as palter 03:16:25 adlai: if you think that x8664-arch.lisp is "interesting", you're some sort of mutant (and will go far in this business.) 03:17:02 gbyers: I only think it's "interesting" because I'm completely clueless about these things 03:17:13 I'll probably find it much less interesting once I actually understand it 03:18:43 Sadly. That was a quote from an Apple II manual, describing the experience of listening to a cassette tape that had been used for data storage. "If it makes sense to you, you're a mutant and will go far ...". 03:20:16 :( 03:41:12 Adlai` [n=adlai@unaffiliated/adlai] has joined #ccl 03:41:37 -!- Adlai [n=Adlai@unaffiliated/adlai] has quit [Nick collision from services.] 03:41:41 -!- Adlai` is now known as Adlai 03:44:38 lpolzer_ [n=lpolzer@dslb-088-073-199-125.pools.arcor-ip.net] has joined #ccl 04:00:42 -!- lpolzer [n=lpolzer@dslb-088-073-215-161.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)] 04:12:12 -!- rme [n=rme@pool-70-105-92-209.chi.dsl-w.verizon.net] has quit [] 04:14:41 lpolzer [n=lpolzer@88.73.199.65] has joined #ccl 04:30:38 -!- lpolzer_ [n=lpolzer@dslb-088-073-199-125.pools.arcor-ip.net] has quit [Read error: 110 (Connection timed out)] 04:46:43 pem [n=pem@159.226.35.246] has joined #ccl 05:07:14 Adlai pasted "CCL stack-allocating REVERSE" at http://paste.lisp.org/display/89194 05:14:20 I guess that macro is a bit mis-named... maybe it should be do-with-list-reversed, but I like shorter names... 07:17:33 milanj [n=milan@212.200.192.111] has joined #ccl 07:57:10 -!- milanj [n=milan@212.200.192.111] has quit ["This computer has gone to sleep"] 08:00:29 -!- Modius [n=Modius@24.174.112.56] has quit [Read error: 110 (Connection timed out)] 08:07:04 -!- pem [n=pem@159.226.35.246] has quit [Read error: 104 (Connection reset by peer)] 08:11:58 pem [n=pem@159.226.35.246] has joined #ccl 08:26:53 -!- lispm [n=joswig@e177126180.adsl.alicedsl.de] has quit [] 09:13:13 -!- Adlai [n=adlai@unaffiliated/adlai] has quit [Read error: 54 (Connection reset by peer)] 09:13:15 Adlai` [n=Adlai@unaffiliated/adlai] has joined #ccl 09:13:52 -!- Adlai` is now known as Adlai 12:45:43 are there known issues with GENSYM in a multi-threaded environment? 12:53:09 -!- Adlai [n=Adlai@unaffiliated/adlai] has quit ["ERC Version 5.3 (IRC client for Emacs)"] 12:59:00 Adlai [n=Adlai@unaffiliated/adlai] has joined #ccl 13:06:19 lpolzer: I don't think so, but I'm not the expert. Have you run into something? 13:06:55 my threads are creating packages named by the form (gensym "SESSION-PACKAGE-") 13:07:07 this works fine in sbcl 13:07:15 but with ccl I got: Package name "SESSION-PACKAGE-86" is already in use. 13:08:05 so I wondered whether there are problems with ccl's gensym before I go debugging 13:09:25 Are you explicitly creating these packages in separate threads? 13:10:49 yes 13:11:51 Man, the spec definition of GENSYM is overly restrictive. 13:12:25 why? 13:14:53 You can't do something like include a thread-id in the symbol name, and everything needs to synchronize on *gensym-counter*. 13:15:47 yes, but surely it's not that hard to use CAS on that... 13:17:58 or at least a mutex to ensure correctness 13:19:29 Yeah, agreed. Just saying it's restrictive, when the exact form of the symbol from gensym shouldn't matter. 13:20:51 I guess they were bound to a single isotonic integer by existing practice... 13:21:56 Yeah, so it looks like it's not threadsafe. 13:22:39 Maybe try constructing the prefix with the thread name as a workaround. 13:22:54 good idea 13:25:09 process-name isn't guaranteed-unique, though, so you have to make sure they're distinct. 13:27:26 there is ccl::serial-number, which probably is unique 13:28:02 (process-serial-number is the name of the reader) 13:29:20 Ah, right, that was actually what I was thinking GENSYM should use in the first place, if it were allowed by the spec. 13:32:04 -!- sykopomp [n=root@unaffiliated/sykopomp] has quit [Remote closed the connection] 13:32:56 next problem: at some random point I get "exception in foreign context" 13:33:05 I wonder how to properly debug this using gdb 13:33:25 since ccl exits with a SIGSEGV 13:34:15 but SIGSEGV seems to be used as memory allocation signal too... 13:35:17 Yeah, I'm no help there ... maybe gb, rme, or gz will be around at some point. 13:37:49 sykopomp [n=root@unaffiliated/sykopomp] has joined #ccl 15:37:19 -!- mdc_mobile [n=mdc_mobi@32.177.183.204] has quit [Read error: 145 (Connection timed out)] 16:13:05 mdc_mobile [n=mdc_mobi@216.239.45.19] has joined #ccl 16:13:55 anRch [n=markmill@72.170.207.26] has joined #ccl 16:38:14 -!- anRch [n=markmill@72.170.207.26] has quit [] 17:29:28 rme [n=rme@pool-70-105-92-209.chi.dsl-w.verizon.net] has joined #ccl 17:30:58 lpolzer: *gensym-counter* is thread-local 17:34:38 Therefore, using gensym as a shortcut way to generate lisp-wide unique strings (for package names) won't work. 17:36:56 For the question on debugging the "exception in foreign context", http://trac.clozure.com/openmcl/wiki/CclUnderGdb gives a few tips. 17:44:31 rme, thanks. any special reason for having a thread-local gensym counter? 17:51:07 I guess that it simplifies the implementation of GENSYM (or was a way to let the existing implementation of GENSYM continue to work correctly in the presence of multiple threads), but I don't know for sure. 18:32:00 rme, ccl does not enter the kernel debugger, though 18:32:06 it just prints the message I quoted 18:32:13 no addresses or anything either 19:47:37 milanj [n=milan@93.87.181.21] has joined #ccl 20:07:57 -!- palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has quit [] 21:34:45 Getting terminated with SIGSEGV is the OS kernel's way of abruptly terminating the process: it raises the signal but doesn't call any handler for the signal. It usually means that something is very, very wrong. 21:37:32 For example: delivering a signal generally involves pushing a bunch of stuff (context) on a thread's stack and calling a handler. If the stack has overflowed, pushing stuff on that stack (unmapped memory) would fault, so you just die with SIGSEGV. 21:42:17 palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has joined #ccl 22:50:13 -!- palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has quit [] 22:51:42 palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has joined #ccl 23:04:22 -!- palter [n=palter@c-24-128-76-188.hsd1.ma.comcast.net] has quit [] 23:25:04 -!- nyef [n=nyef@pool-71-161-71-17.cncdnh.east.myfairpoint.net] has quit ["Gone for a while."] 23:27:42 -!- milanj [n=milan@93.87.181.21] has quit ["Leaving"]