libera/#commonlisp - IRC Chatlog
Search
7:15:23
beach
semz: What does it mean for a declaration to "apply to the bodies of inlined functions"? An inlined function must still follow the semantics consisting of binding the values of forms to its parameters. Inlining it must not change that.
7:16:11
semz
I'm mostly concerned with safety declarations, but these aren't really portable to begin with outside of the safe/unsafe distinction
7:16:13
beach
semz: Put differently, inlining is not done by including source code into the inlining function.
7:17:11
semz
e.g. if foo uses default safety and is inlined into bar, which uses low safety, would the inlined foo be treated as compiled under low safety?
7:17:55
semz
so far it seems like this question is ill-defined as far as standard CL is concerned though
7:23:18
Krystof
I can imagine two implementations of inline: one which substitutes the source code (where you would naturally get low safety in your example) and one which substitutes the compiled code (default safety)
7:24:24
Krystof
if you know you want the first interpretation you can use a compiler macro instead, assuming your implementation does anything with compiler macros
7:25:06
Krystof
if you want the second one, your best chnace is probably something like (declaim (inline foo)) (defun foo (x) (locally (declare default-safety) ...))
7:52:28
ogamita
I had the impression that in general, we want more of a source-code inlining, eg. to allow early type optimizations.
13:55:29
jackdaniel
(the message "truncate can't into ..." is my own showing values I pass to truncate somewhere deep inside a a program, the message below is the actual condition)
13:56:23
jackdaniel
beats me, according to my handler arguments passed to truncate are both ratios (59/8 and 447/16)
13:58:14
jackdaniel
well, I'm printing them in the same dynamic extent as the function truncate is called
14:33:16
jackdaniel
I think that you'd be better off asking the question (instead of probing first whether there is someone who'd potentially might answer)
14:46:03
NotThatRPG
I'm having trouble trying to run the `cl-async` event loop in a thread (started by `bordeaux-threads:make-thread`): according to the cl-async docs, this should be fine. But socket connections that succeed when run in the main thread fail when run in a subsidiary thread.
14:48:58
NotThatRPG
aeth: Interestingly, one of the cl-async tests -- checking a failed socket connection -- fails with a timeout error when run in the subsidiary thread (instead of a socket closed error). I see a timeout error in my threaded version, too.
14:49:54
NotThatRPG
fe[nl]ix: that's a good point. I will see if some of this code (which is riddled with global variables) could be relying on something that is not inherited. I believe that all I have to worry about is dynamic bindings, not top-level/global bindings, right?
14:50:18
NotThatRPG
Unfortunately, the logging in cl-async is not at all adequate to debugging purposes.
14:52:14
NotThatRPG
varjag: Honestly, I don't want to do event loops! It's just that cl-mqtt does, and some people I'm working with want to use MOSQUITTO.
14:58:30
NotThatRPG
Looks like if a socket connection fails with EOF, CL-MQTT doesn't properly notice, and instead just coughs up timeout errors trying to write to the EOFed socket.
14:59:08
NotThatRPG
An example of why I am not loving CL-ASYNC is that its error-handling is deeply cryptic.
14:59:09
_death
I would consider rewriting the client bits to use ordinary blocking code, maybe salvaging some of the encoding/protocol bits