freenode/#sbcl - IRC Chatlog
Search
13:30:20
pfdietz
I am seeing a heap corruption error in some varieties of random testing on the SEARCH function. Trying to track it down, but reproducibility is difficult.
17:54:16
stassats
judging by the comments, i did envision that, but " only when searching for "" and :start2 being equal to :end2"
18:06:32
stassats
ok, that's easy, now, why doesn't (position a (the (simple-vector 8) b)) derive that it's below 8
18:20:32
stassats
i should try making a proof of concept, before drowning in duplicate transforms/type derivers
18:22:18
pkhuong
might also be useful to have another kind of note to drive the post-IR1 pattern matching
18:25:53
stassats
will start with type derivation, as i don't have to think about removing dead code
20:52:23
jasom
(disassemble (lambda (x) (declare (optimize (speed 3)) (type (unsigned-byte 16) x)) (sb-rotate-byte:rotate-byte 1 (byte 16 0) x)))
21:02:17
stassats
i'd say sb-rotate-byte:rotate-byte should implement 16/8-bit rotates where possible and perform inline rotations for arbitrary widths
21:17:42
jasom
I just did the following for a 16-bit rotate of X by N: (logior (ldb (byte n (- 16 n)) x) (ash (ldb (byte (- 16 n) 0) x) n))
21:20:16
jasom
can't get a non-word-sized rotate in 1 instruction on PPC , but I think you can do it with 2 instructions rlwinm,rlwimi
21:39:49
stassats
pfdietz: can you produce code which does (eql (function x y) result) and then check if it's correct?
21:40:14
stassats
that'll have an easier job catching bad derivations than accidentally producing conflicting types
21:48:01
stassats
type derivations bugs are hard to catch and produce weird failures because normally nothing acts on that information
23:08:45
sveit
hi. I am interfacing with some code through the first that requires a callback. sbcl has a very nice feature for this, sb-alien::alien-lambda
23:09:29
sveit
the problem I am running into is that it does not seem these lambdas will get garbage collected when they are no longer referenced
23:11:58
sveit
the problem is that I am calling this function many times, so many internal lambdas are created
23:13:26
sveit
I need to pass lisp functions to the C (actually Fortran, but that isn't important) code over and over again to be called in a numerical routine
23:14:34
sveit
for example, if I have a numerical integration routine in C that takes a function pointer, and I want to use it to integrate a huge number of lisp functions
23:15:38
sveit
what I currently do is have a lisp function that takes a lisp function as one of its arguments, then wraps that in a sb-alien::alien-lambda inside the body
23:17:23
sveit
one option I considered is to have a global variable *lisp-function*, then only create a single callback that funcalls the function in that variable, but I do not know how to make that work with many threads
23:21:06
sveit
you mean (let ((*global-var* f)) ... use callback), right? is this "threadsafe" in SBCL?
23:23:05
stassats
(defun make-alien-closure (target) (values (sb-alien::alien-lambda void () (funcall target)) (lambda (new-target) (setf target new-target))))
23:25:48
sveit
oh thanks, I haven't seen that trick before. I guess for each thread I still have to make a new closure, correct?
23:28:12
sveit
I guess if I play with locks (and global variables) I can have just a single callback
23:30:56
sveit
yeah, you're right. I'll think about this some more, thanks a lot for your help. is there any hope to make the alien-lambda "truly" garbage-collectible?
23:32:46
sveit
but I can still free up that memory and use it for other things when it comes to actual objects
23:46:43
sveit
hmm? so even if I invalidate the callback I will still get a new trampoline for every new lambda?
0:00:56
sveit
so how would my own pool solve this? or do you just mean to allocate several closure-style callbacks as you mentioned?
0:03:44
sveit
ok thanks. so to confirm you mean a pool of your "closure"-based callbacks? last question, thanks very much for your insight
0:06:03
sveit
yes, I got that part :) if I have some time someday I've always thought SBCL was incredible, maybe I can try to contribute a modification of the trampoline allocation to make them "freeable"
0:09:27
stassats
then move the argument marshalling code into the actual function - it'll be faster and avoid boxing/unboxing values
0:17:12
sveit
actually, I am looking at the documentation for dynamic bindings with threads, and it seems to say (13.2) that they are correctly thread local