freenode/lisp - IRC Chatlog
Search
20:29:17
aeth
I get a setf not defined error, so that means incf follows from setf being defined? Or is that just SBCL?
20:30:13
aeth
(defun rotation (x) (aref x 1)) (defun (setf rotation) (new-value x) (setf (aref x 1) new-value)) (let ((foo #(0 1))) (incf (rotation foo)) foo) => #(0 2)
20:32:32
aeth
so much of what I am doing is just incf on a much more complicated data structure than my array example
20:33:59
nyef
aeth: Typically, a macro name ending in "F" indicates that the macro takes a "place". "Places" are defined in terms of SETF.
20:35:27
nyef
Largely because SETF was the first thing developed that took a "place", and then it was extended all over the place.
20:40:19
aeth
only somewhat related, but I wonder if CL would be able to handle without a performance cost the addition of a general index accessor, e.g. (access hash-table :foo) (access plist :foo) (access alist :foo) (access multidimensional-array '(0 1 2)) (access sequence 2)
20:41:35
aeth
In fact, slot-value could be considered one of those, but it would probably be better to go through CLOS accessors
20:43:50
Bike
i mean you're either defining an access method or a setf expander, and they presumably look about the same
20:45:36
aeth
the equivalent of that access would be (aref (gethash :from-another-hash-table (svref (gethash :some-simple-vector hash-table) 3)) 0 1 2 3)
20:45:40
nyef
... Not getting what you're driving at. It seems like you want some sort of place semantic for GETHASH?
20:46:59
aeth
nyef: What I mean is, combine aref, gethash, getf, assoc-value, and elt into one super-accessor
20:47:52
aeth
because if it's all one accessor, then you can from left to right chain accesses like . and/or [] in some languages
20:49:58
aeth
This would be especially helpful because some functions (like gethash) put the index on the left, which makes the flow a lot less clear.
20:51:30
aeth
To use a simpler example... (access hash-table :foo) is equivalent with (gethash :foo hash-table) but (access hash-table :foo 0) would be equivalent with (elt (gethash :foo hash-table) 0) where the latter is a lot less clear imo
20:54:03
aeth
More concretely, this is how it is now: (defvar *hash-table* (make-hash-table)) (setf (gethash :foo *hash-table*) #(0 1 2 3 4 5)) (setf (elt (gethash :foo *hash-table*) 0) 1)
20:56:47
aeth
I don't think CL can do that efficiently, though, because access won't know if *hash-table* is a hash-table, an alist, or a plist... and it won't know if the second part is an integer-keyed hash-table or a sequence.
21:03:56
jackdaniel
if you are into this kind of stuff, check https://github.com/rongarret/ergolib (ref operator)
21:10:22
aeth
It looks like ref* does what I suggested, but I don't think it's possible to have a general accessor like that work in CL efficiently.
21:49:49
mrottenkolber
So I am in search of a nice bounded multi producer single consumer queue, that can be implemented on top of CAS? Slightly OT but hey maybe somebody has a favorite.
21:51:43
varjag
since you can implement a linked list with arbitrary insert on top of cas, it should be possible
22:26:40
mrottenkolber
varjag: I have already implemented a variant vyukov’s MPSC queue which is roughly what you describe, but I am stuck on how to adapt it to be bounded
22:27:30
mrottenkolber
i.e. if there is an obvious way to turn an unbounded queue into a bounded one it eludes me
0:37:03
mrottenkolber
by the way, in case I do want to do C-esque modulus addition, is there an alternative to (mod (+ x y) d)?
0:39:20
nyef
Note that using LOGAND and constraining the result to a "natural" width means that SBCL can be somewhat intelligent about optimizing the computation.
0:44:30
mrottenkolber
so what’s the difference between (logand max (+ x y)) and (mod (+ x y) (1+ max)) then?
0:47:09
nyef
The logand version only works for a power-of-two-minus-one, but is also far, far more likely to trigger compiler optimizations.
0:47:42
nyef
... And LOGAND operates in terms of integers, while MOD operates in terms of non-complex ("real") numbers.
0:51:06
mrottenkolber
porting CAS based queue algorithms to CCL for experimenting with Erlangen, possibly to find out that ccl::conditional-store has issues, then trying to work on that?
1:18:29
aeth
(defun foo (x y) (declare (integer x y)) (mod (+ x y) (1+ 255))) (defun foo* (x y) (declare (integer x y)) (logand #xff (+ x y)))
1:19:16
nyef
SBCL probably has an integer-division-by-power-of-2-strength-reduction transform, and from there the modular arithmetic optimizations would kick in.
1:21:19
aeth
SBCL actually doesn't have all the clever little micro-optimizations that can be done with parts of the CL language. It's fast but CL can definitely be made to be much faster.
1:22:18
nyef
Mmm. I've added some cleverness to SBCL myself, and I know of a couple of places where it isn't particularly excellent in terms of optimization.
1:24:25
aeth
Well, one thing that was talked about a few weeks ago is (remove-if-not #'foo ...) vs. (remove-if (complement #'foo) ...) being different, rather than having the equivalent disassembly that many assume. I'm not sure if that's possible, though.
1:25:48
nyef
For them to be fully equivalent in terms of code generated, I'd expect remove-if-not and complement to be open-coded, and I don't know that they are.
1:26:17
aeth
I suppose it would have to be done in all possible foo-not functions that are deprecated (or is only remove-if-not deprecated?)
1:26:21
mrottenkolber
does anyone have a copy of "Efficient Hardware Arithmetic in Common Lisp", http://jcsu.jesus.cam.ac.uk/~csr21/papers/modular/modular.pdf seems down
1:28:15
aeth
I think all the foo-if-not functions are deprecated. It looks like there are twelve of them: http://l1sp.org/search?q=%2Dif%2Dnot
2:53:41
loke
aeth: Yeah, that'll never happen. :-) And even if it did, there is no way the *-if-not functions would be removed.
3:48:37
edgar-rft
loke: what exactly is the difference between "no new standard coming ever" and "infinite time between CL standards"? To me both seems to be the same.
4:04:34
Bike
but time is continuous. but quantum mechanics says it isn't. but special relativity says the concept of a time between events is difficult. but bla bla bla
4:35:56
nyef
... Which some quick digging shows to be a bullshit concept not associated with anything "real".
4:41:01
Bike
i never had quantum and i barely had relativity in school, so i'm basically chopra level
5:36:16
drmeister
So I ran into a fundamental flaw in Linux and OS X wrt integrating C++ and Common Lisp.
5:36:45
drmeister
It doesn't appear to be possible to integrate unix signal handlers with C++ exception handling.
5:38:47
drmeister
When interrupting a thread - there are times when it needs to unwind the stack from the interrupt hander up to a level outside of the interrupt handler.
5:40:12
White_Flame
I presume unwinds when Clasp conditions are raised are implemented with C++ exceptions?
5:40:37
White_Flame
I remember back in my C++ days, exceptions were very brittle when it comes to OS integration
5:40:43
drmeister
Yes, all unwinds are C++ exceptions. It's the only way to work with RAII and call destructors properly.
5:45:02
drmeister
That was a bad timedwait calculation. I fixed that and then had a 75% CPU usage because of inefficiencies in Clasp and Slime.
5:45:31
drmeister
stassats "fixed" Slime so that it doesn't poll a condition-variable every 0.2 seconds and I fixed some stuff in Clasp.
5:46:36
drmeister
Sadly though C-c C-c and M-C-x stopped working because Clasp doesn't do interrupt-process properly because I stalled in implementing it when I realized that signal handlers and C++ exceptions were incompatible.
5:47:49
drmeister
Thinking about it though. If an error happens in Clasp, sldb will come up and that doesn't involve interrupting the thread. In that case there is no problem with restarts or unwinding the stack.
5:52:47
drmeister
Control-c could interrupt a loop and bring up sldb - but I can't unwind the stack out of the interrupt handler.
5:54:11
drmeister
I could set a thread local flag that says 'Control-c was hit' and insert a poll in every loop that I want to Control-c out of. That will be tedious - but I don't see any other way.
5:55:43
drmeister
Yes - but calling destructors properly between the interrupt handler and wherever I want to return to is the thing I can't do.
5:58:13
drmeister
I'm tossing this out there in case anyone else has any ideas. I'd love to hear them.
6:09:14
jackdaniel
drmeister: you may have signal servicing thread which handles signals scheduled by an actual handler (which returns as fast as it can)
6:09:44
jackdaniel
in that case you are not in this very sensitive context and exceptions shouldn't interfer too much