freenode/lisp - IRC Chatlog
Search
23:00:48
no-defun-allowed
i got a very, very weird error using websocket-driver on heroku: https://pastebin.com/4XjhbYQ4
23:01:15
no-defun-allowed
i think it's cause it uses fast-io, which uses static-vectors, which uses CFFI which doesn't load right for some reason
23:09:48
fortitude
no-defun-allowed: looks like CFFI is using a macro called OS-COND that hasn't been loaded
23:10:37
no-defun-allowed
i honestly don't have a clue, my main priority is getting the buildpack to load a custom hunchentoot acceptor which isn't happening i think
23:12:06
fortitude
no-defun-allowed: maybe try explicitly depending on uiop? that's where OS-COND is from, and the CFFI-TOOLCHAIN system doesn't depend on it
23:12:45
no-defun-allowed
i see, i did force quicklisp to try to update in the deploy script so there could be a problem
23:14:36
no-defun-allowed
what i didn't see was the comment telling me where to put the toplevel function
23:18:11
no-defun-allowed
well, i got the acceptor set up right, but there's still no content on the page
23:23:28
fortitude
is that because hunchentoot's been configured not to do that, or is it because there's some kind of proxy in the middle and you aren't even hitting hunchentoot?
23:53:02
no-defun-allowed
https://github.com/rpav/fast-io/blob/master/fast-io.asd#L15 i suspect this line isn't working right
0:09:14
no-defun-allowed
fucking finally, i just had to make another version of my library and remove anything to do with that client, since even #-server-only wouldn't mask it out
0:30:00
no-defun-allowed
is there an equivalent to with-hash-table-iterator that can be used outside its dynamic extent?
0:33:54
no-defun-allowed
that said, there won't be that many values to store in a list if the hash table fits in memory
0:42:22
aeth
no-defun-allowed: alexandria has a hash-table-keys but it iterates over the whole hash-table and conses up a list of keys
3:27:22
hectorhonn
haskell's reader monad mechanism is basically achieved by common lisp's special variables. yes?
7:38:03
quazimodo
i asked what the strategy is when streaming an audio file, playing & saving it to disc simultaneously. Does the stream go straight to disk & the player just reads from there, or is the data stream multiplexed, one lot into a buffer for audio player consumption and the other lot into a buffer for the disk writer
7:38:24
quazimodo
and if it's the 2nd approach, at what point do you swap from memory buffer from the stream to the disk?
7:45:03
quazimodo
lieven: so some sort of coherent 'write this new stuff from this position x', and 'read this other stuff from this position y' on an open file handle?
7:46:27
quazimodo
and if the network is fast enough, the write's would happen at faster or more of the reads, where you'd check the current write position(x) against the read position(y) to see what can be read, thus putting the actual audio player into a 'pending' state until more info comes in and a read is allowed?