<evdubs>
i am building racket from source and i am wondering if there's a way to `make clean` and get rid of stuff i previously compiled
<evdubs>
`make clean` isn't a valid target, it seems
<evdubs>
anyone have ideas?
ZombieChicken has joined #racket
endobson has joined #racket
keep_learning_M has joined #racket
FreeFull has quit []
acarrico has quit [Ping timeout: 258 seconds]
<remexre>
is there a (TODO "...") macro in todo-list outside of demo.rkt?
ZombieChicken has quit [Quit: WeeChat 2.5]
ZombieChicken has joined #racket
_whitelogger has joined #racket
cantstanya has quit [Ping timeout: 260 seconds]
cantstanya has joined #racket
efm has joined #racket
endobson_ has joined #racket
endobson has quit [Ping timeout: 244 seconds]
lispmacs has joined #racket
<lispmacs>
Does `read-bytes!' simply write the bytes directly into the bytestring, or does it allocate its own byte string first?
<endobson_>
lispmacs: Whats the observable difference?
<lispmacs>
endobson_: well, I trying to troubleshoot a perforance issue in a Racket app that processes a live stream. I was using read-bytes to pull data from the stream and then write it to another stream with write-bytes. I thought I would see a performance improvement (next page)
<lispmacs>
if I used a buffer byte string in conjunction with read-bytes! but I didn't
<lispmacs>
I was trying to avoid a bunch of memory allocation
<endobson_>
So I would expect it would read it directly into the bytestring, and do no allocation
<endobson_>
Have you confirmed that allocation is what is causing the slowness?
endobson_ is now known as endobson
<lispmacs>
endobson_: I'm not sure yet, no. My problem is I'm not pulling data from the stream fast enough. Looking at the code, seems like it most likely has to do either with the reading and writing on the Racket end, or something to do with the way the threads are working. (Maybe thread not running often enough...)
keep_learning_M has quit [Quit: This computer has gone to sleep]
<endobson>
By fast enough do you mean latency or throughput
<lispmacs>
seem to be losing about 1/8th of my stream
<lispmacs>
endobson: throughput. So, I've got a C programming pulling data from an SDR and 8 msps, and my racket app pulls that stream from a pipe and saves it to a file. But I only seem to be able to get 7 to 7.5 msps saved to the file
<lispmacs>
but If I skip the racket app, and pull directly from the pipe with `cat' utility, I can get 8 msps no problem
<lispmacs>
this missing data shows up as skips in the radio stream, when I process it later
Arcaelyx has quit [Ping timeout: 245 seconds]
<lispmacs>
skips or garble
<endobson>
Why is it missing versus just buffering somewhere?
<endobson>
rudybot: init racket
<rudybot>
endobson: your sandbox is ready
<endobson>
rudybot: init copy-port
<rudybot>
endobson: error: standard-module-name-resolver: collection not found <NEWLINE> for module path: copy-port <NEWLINE> collection: "copy-port" <NEWLINE> in collection directories: <NEWLINE> /mnt2/racket-6.9/collects <NEWLINE> ... [159 additional linked and package directories]
<lispmacs>
endobson: it might be buffering in the pipe, but that doesn't really help me because I'm trying to process a live stream
<endobson>
rudybot: doc copy-port
<rudybot>
endobson: error: standard-module-name-resolver: collection not found <NEWLINE> for module path: copy-port <NEWLINE> collection: "copy-port" <NEWLINE> in collection directories: <NEWLINE> /mnt2/racket-6.9/collects <NEWLINE> ... [159 additional linked and package directories]
<endobson>
If it is not using copy port, is it because you didn't know about it, or because it isn't appropriate for some reason
<lispmacs>
"copy port"?
<endobson>
see the link above
<endobson>
from rudybot
<endobson>
rudybot: say hi
<rudybot>
endobson: I could swing by the Collabora place to say hi, maybe.
<lispmacs>
endobson: no, I hadn't heard of that. That sounds useful. I don't know if it would help me long term, since i eventually wanted to do some things with the stream other than just save it
<endobson>
ok, so what does your copy code look like
<endobson>
What size buffer are you using?
<lispmacs>
git://lavender.qlfiles.net/pub/git/hackrf-rkt.git, sp-to-file function. (Not sure where to paste the code...)
<lispmacs>
let me see if I can pastebin or something...
<endobson>
there is pastrack.org, see the topic
<endobson>
pasterack.org
<lispmacs>
see topic? In the html documenation...?
<endobson>
the channel's topic
<endobson>
Not sure where your IRC client shows it
<lispmacs>
endobson: okay, there is the URL, should I past the whole file, or just the two functions...?
<endobson>
Just do the two functions
<lispmacs>
I seemed to have caused an exception in pasterack, still working on it
<endobson>
pastebin.com or gist.github.com also work if it is having issues
<lispmacs>
buffer size set initially to 100000 bytes, but can expand if incoming libhackrf buffer is larger, which I don't think it ever is
<lispmacs>
there are a few sanity check string processing functions that happen in between incoming large chunks of data, but hopefully that wouldn't cost that much
<endobson>
so you probably want to look at the output of read-bytes!
<endobson>
since it may not read all the data if the eof comes first
liberiga has joined #racket
<lispmacs>
endobson: oh, so maybe read-bytes! is overrunning the stream?
<endobson>
I don't know how the file you are reading from works
<endobson>
it is a regular file or special device
<lispmacs>
endobson: Gnu/Linux operating system pipe file. C program pulls data from SDR (radio) over USB, streams it to pipe file, Racket program pulls from Pipe file
<lispmacs>
I tried to skip the Pipe file using FFI programming, but ran into to many other problems, so am using IPC through fifo pipe file
<endobson>
The pipe file is likely going to be causing some issues
<endobson>
I'm not sure exactly how eof works with them
<endobson>
when does the the c program stop writing data to the pipe
<lispmacs>
endobson: C program sends pipe a "prefix" string telling how many bytes are coming down the pipe (as reported by the radio itself through libusb) and then dumps those bytes into pipe from a memory buffer
<endobson>
what is the second argument in the prefix that you are ignoring?
ephemera_ has quit [Ping timeout: 272 seconds]
<lispmacs>
endobson: that is the radio device (as a memory pointer). might possibly remove that argument
<lispmacs>
memory pointer to it's interface in the C program
<lispmacs>
well, to check your theory, I could just see if number of bytes read by read-bytes matches what I was expecting. easy enough
<endobson>
Try checking the output of read-bytes!, I don't know how much fifo's buffer by default but I don't think it is 100k
<endobson>
thats for when you want one armed ifs in imperative code
<lispmacs>
endobson: thanks
<lispmacs>
endobson: okay, I think I have to get ready for bed, but I'm going to look into than man page later, and check the read-bytes output too. Thanks for the help
<rudybot>
greghendershott: I asked `MemoServ' to forward the message to zipper.
ubLIX has quit [Quit: ubLIX]
sagax has quit [Ping timeout: 244 seconds]
davidl has joined #racket
sagax has joined #racket
endobson has joined #racket
orivej has quit [Ping timeout: 245 seconds]
miklos1 has joined #racket
endobson has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
endobson has joined #racket
endobson has quit [Client Quit]
endobson has joined #racket
endobson has quit [Client Quit]
endobson has joined #racket
endobson has quit [Client Quit]
endobson has joined #racket
endobson has quit [Client Quit]
endobson has joined #racket
endobson has quit [Client Quit]
endobson has joined #racket
endobson has quit [Client Quit]
miklos1 has quit [Remote host closed the connection]
iyzsong has quit [Ping timeout: 250 seconds]
mason is now known as BadHobbit
BadHobbit is now known as mason
lavaflow has joined #racket
davidl has quit [Ping timeout: 248 seconds]
efm has quit [Ping timeout: 245 seconds]
soegaard has quit [Quit: soegaard]
Arcaelyx has quit [Ping timeout: 244 seconds]
englishm has joined #racket
Lowl3v3l has joined #racket
vraid has quit [Quit: Leaving]
ziyourenxiang_ has quit [Ping timeout: 248 seconds]
q9929t has joined #racket
Sgeo_ has joined #racket
juanfra has quit [Ping timeout: 246 seconds]
Sgeo has quit [Ping timeout: 248 seconds]
euhmeuh has left #racket [#racket]
juanfra has joined #racket
q9929t has quit [Quit: q9929t]
juanfra has quit [Quit: juanfra]
ubLIX has joined #racket
juanfra has joined #racket
manualcrank has joined #racket
juanfra has quit [Client Quit]
juanfra has joined #racket
Sgeo__ has joined #racket
Sgeo_ has quit [Ping timeout: 245 seconds]
ubLIX has quit [Ping timeout: 248 seconds]
orivej has joined #racket
Sgeo_ has joined #racket
Sgeo__ has quit [Ping timeout: 268 seconds]
Arcaelyx has joined #racket
casaca has quit [Ping timeout: 268 seconds]
casaca has joined #racket
davidl has joined #racket
ng0 has joined #racket
zipper has joined #racket
englishm has quit [Excess Flood]
englishm has joined #racket
casaca has quit [Ping timeout: 268 seconds]
casaca has joined #racket
englishm has quit [Excess Flood]
englishm has joined #racket
casaca has quit [Ping timeout: 246 seconds]
casaca has joined #racket
davidl has quit [Quit: WeeChat 2.1]
ubLIX has joined #racket
davidl has joined #racket
Sgeo__ has joined #racket
Sgeo_ has quit [Ping timeout: 272 seconds]
casaca has quit [Ping timeout: 272 seconds]
FreeFull has joined #racket
casaca has joined #racket
zipper has quit [Ping timeout: 248 seconds]
sauvin has quit [Ping timeout: 248 seconds]
sauvin has joined #racket
sauvin has quit [Max SendQ exceeded]
sauvin has joined #racket
sauvin has quit [Max SendQ exceeded]
sauvin has joined #racket
selimcan has joined #racket
sauvin has quit [Read error: Connection reset by peer]
casaca has quit [Ping timeout: 245 seconds]
casaca has joined #racket
enderby has joined #racket
casaca has quit [Ping timeout: 245 seconds]
casaca has joined #racket
efm has joined #racket
Lowl3v3l has quit [Quit: Leaving.]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #racket
efm has quit [Quit: Konversation terminated!]
orivej has quit [Ping timeout: 245 seconds]
<badkins>
Wow, I didn't realize I could ask rudybot to notify someone when they login again - very handy!
<badkins>
rudybot help
<badkins>
hmm....
<badkins>
rudybot: what commands do you understand?
<rudybot>
badkins: if i understand what you are saying, you are finding that C-u seems to negate some commands. you may find more precise clarification by using C-h f to describe a command, and there may be mention of what the C-u prefix will do. indeed, for some commands, the C-u argument will give an opposite action. for example, indent topic in Gnus Group buffer, C-u TAB will unindent. (but so will M-TAB.)