ephemera_ has quit [Quit: No Ping reply in 180 seconds.]
k_sze has quit [Client Quit]
ephemera_ has joined #racket
k_sze has joined #racket
badkins has joined #racket
vraid has quit [Read error: Connection reset by peer]
elioat has quit [Quit: WeeChat 1.9.1]
badkins has quit [Remote host closed the connection]
<lavaflow>
what is the point of read-bytes! relative to read-bytes ? is that meant to be more performant? or does that exist for some other reason?
cartwright has joined #racket
lockywolf_ has joined #racket
lockywolf_ has quit [Remote host closed the connection]
lockywolf has quit [Ping timeout: 246 seconds]
pilne has quit [Quit: I cna ytpe 300 wrods pre mniuet!!!]
sword865 has joined #racket
gebrek has quit [Ping timeout: 255 seconds]
badkins has joined #racket
badkins has quit [Ping timeout: 246 seconds]
orivej has joined #racket
orivej has quit [Ping timeout: 246 seconds]
FreeFull has quit []
Lowl3v3l has joined #racket
endformationage has quit [Ping timeout: 250 seconds]
narimiran has joined #racket
sauvin has joined #racket
orivej has joined #racket
orivej has quit [Ping timeout: 256 seconds]
xensky has quit [Read error: Connection reset by peer]
cartwright has quit [Remote host closed the connection]
cartwright has joined #racket
dddddd has quit [Ping timeout: 246 seconds]
rmnull has joined #racket
rmnull has left #racket [#racket]
<evdubs>
lavaflow, probably to avoid constant allocations if you just need one byte buffer?
<evdubs>
i'd imagine that'd be more performant if there's some read-bytes workflow that puts pressure on the GC?
even4void has joined #racket
even4void has quit [Remote host closed the connection]
even4void has joined #racket
even4void has quit [Remote host closed the connection]
even4void has joined #racket
even4void has quit [Remote host closed the connection]
nullcone has quit [Quit: Connection closed for inactivity]
sudden has quit [Ping timeout: 258 seconds]
even4void has joined #racket
even4void has quit [Client Quit]
_whitelogger has joined #racket
sudden has joined #racket
even4void has joined #racket
badkins has joined #racket
rmnull has joined #racket
rmnull has quit [Client Quit]
badkins has quit [Ping timeout: 250 seconds]
orivej has joined #racket
eMBee has quit [Ping timeout: 245 seconds]
nullman has quit [Ping timeout: 258 seconds]
nullman has joined #racket
orivej has quit [Ping timeout: 250 seconds]
iyzsong has joined #racket
<bremner>
is there a paper / book chapter I should read about optimizing allocation of continuations / closures? it seems like a naive strategy of just GCing everything would be pretty slow?
rmnull has joined #racket
even4void has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
libertyprime has joined #racket
MustardCheese has joined #racket
vraid has joined #racket
cartwright has quit [Ping timeout: 240 seconds]
cartwright has joined #racket
sword865 has quit [Quit: Connection closed for inactivity]
jboy has joined #racket
elioat has joined #racket
libertyprime has quit [Quit: Lost terminal]
<samth>
bremner: there's a lot of literature on that
<samth>
also those are two pretty separate topics
<samth>
a good initial read on continuations is Kent Dybvig's thesis
<bremner>
samth: thanks for the reference. It looks like that covers the main issues I was thinking about (from the point of view of teaching continuation based interpreters, and wondering how this would work in practice)
<bremner>
a more practical question: is there a nice way to watch top-level variables (mutated identifiers) in the DrRacket debugger? or some other way of tracing changes to top level variables?
<bremner>
I know they are not very idiomatic in racket, but at the moment that's what I have.
even4void has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samth>
bremner: i don't think so (the debugger doesn't have very many features)
<greghendershott>
bremner: Not that I know of, exactly. But lately I have some half-formed ideas about making it easier to (sort of) compose loggers with racket/trace, and make it easier to toggle the latter without changing source.
<greghendershott>
I don't think racket/trace covers set!, so maybe also something like that.
even4void has joined #racket
<greghendershott>
I think step debuggers are great, but when concurrency is involved, I think sometimes just "logging" is more practical
<greghendershott>
Also logging seems to be a more common mindset these days, what with web apps and distributed systems
efm has joined #racket
<bremner>
sure. No concurrency for me though, just lots of set!