orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #racket
lockywolf__ has quit [Remote host closed the connection]
lockywolf__ has joined #racket
rnmhdn has quit [Ping timeout: 250 seconds]
orivej has quit [Read error: Connection timed out]
orivej has joined #racket
lockywolf__ has quit [Ping timeout: 246 seconds]
lockywolf_ has joined #racket
dddddd has joined #racket
lockywolf__ has joined #racket
lockywolf__ has quit [Max SendQ exceeded]
lockywolf__ has joined #racket
lockywolf_ has quit [Ping timeout: 246 seconds]
lockywolf__ has quit [Max SendQ exceeded]
lockywolf__ has joined #racket
lockywolf__ has quit [Remote host closed the connection]
lockywolf__ has joined #racket
acarrico has joined #racket
DGASAU has joined #racket
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #racket
orivej has quit [Client Quit]
orivej has joined #racket
buyfn has joined #racket
notzmv has quit [Ping timeout: 250 seconds]
iyzsong has joined #racket
acarrico has quit [Ping timeout: 246 seconds]
notzmv has joined #racket
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #racket
_whitelogger has joined #racket
lockywolf__ has quit [Ping timeout: 246 seconds]
pie__ has joined #racket
pie___ has quit [Remote host closed the connection]
pierpal has quit [Remote host closed the connection]
rnmhdn has joined #racket
DGASAU has quit [Ping timeout: 272 seconds]
buyfn has quit [Quit: buyfn]
iyzsong has quit [Ping timeout: 252 seconds]
lockywolf has joined #racket
FreeFull has joined #racket
lose has joined #racket
orivej has quit [Ping timeout: 245 seconds]
pierpal has joined #racket
orivej has joined #racket
endformationage has joined #racket
buyfn has joined #racket
m1dnight_ has quit [Quit: WeeChat 2.3]
orivej_ has joined #racket
orivej has quit [Ping timeout: 272 seconds]
notzmv has quit [Ping timeout: 250 seconds]
ziyourenxiang has quit [Ping timeout: 240 seconds]
notzmv has joined #racket
pie___ has joined #racket
pie__ has quit [Remote host closed the connection]
buyfn has quit [Quit: buyfn]
acarrico has joined #racket
jao has joined #racket
lockywolf has quit [Ping timeout: 244 seconds]
buyfn has joined #racket
rnmhdn has quit [Ping timeout: 240 seconds]
rnmhdn has joined #racket
juanfra has quit [Quit: juanfra]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
juanfra has joined #racket
m1dnight_ has joined #racket
buyfn has quit [Quit: buyfn]
meepdeew has joined #racket
mzan has left #racket [#racket]
mceier has quit [Ping timeout: 244 seconds]
lose has quit [Ping timeout: 250 seconds]
m1dnight_ has quit [Quit: WeeChat 2.3]
notzmv has quit [Ping timeout: 272 seconds]
notzmv has joined #racket
pie___ has quit [Remote host closed the connection]
pie__ has joined #racket
dustyweb has quit [Remote host closed the connection]
pera has joined #racket
mceier has joined #racket
badkins has joined #racket
dustyweb has joined #racket
acarrico has quit [Ping timeout: 250 seconds]
pera has quit [Ping timeout: 250 seconds]
pierpal has quit [Ping timeout: 240 seconds]
zenspider has quit [Ping timeout: 246 seconds]
zenspider has joined #racket
audriu has joined #racket
audriu has quit [Quit: Leaving]
<lavaflow>
On a fixnum, is exact->inexact isn't free, right? because a flonum requires an allocation?
<lavaflow>
I'm trying to think of the fastest way to divide two fixnums and get a flonum result. casting one or both arguments to flonums first seems like it's two unnecessary allocations to me.
<lavaflow>
well, if given a fixnum and a flonum, / produces a flonum so I would only need to cast one of the arguments. still though
rnmhdn has quit [Ping timeout: 250 seconds]
Shambles_ has joined #racket
Shambles_ has left #racket [#racket]
<jcowan>
Nothing dealing with flonums is free in that sense
<jcowan>
which is why almost all Schemes have terrible flonum performance unless they have trusted type declarations (as opposed to safety type declarations)
<lavaflow>
I expect one allocation for the flonum result, but if I can get away with only that one allocation that'd be ideal I think.
<lavaflow>
doing (apply * flo-lst) is WAY faster than (apply * exact-lst). I don't even see the need to reach for unsafe-fl* here
<lavaflow>
but I think populating that flo-lst is the bigger bottleneck for me atm. I could amortize/memonize the allocation of those flonums, which might be what I end up doing, though it will be a bit invasive.
<jcowan>
(/ (inexact a) b) where a and b are exact should have basically the same performance as (/ (inexact a) (inexact b)) but allocate less
<jcowan>
If you don't need the precision you could use single-floats and save a lot of space
<lavaflow>
yeah I'm considering using single precision. I don't think I actually need anything more and the space savings would probably be worth it
acarrico has joined #racket
evhan has joined #racket
notzmv has quit [Ping timeout: 245 seconds]
notzmv has joined #racket
davidl has quit [Quit: WeeChat 2.1]
mzan has joined #racket
<lavaflow>
time-apply returns three values, CPU time, Real time, and GC time. GC time is included in CPU time. I presume the difference between real time and CPU time is time spent blocked on IO and similar
<lavaflow>
so my question is, when calling into ffi things like sqlite, does that CPU time remain accurate? or is it counting IO time spent in sqlite towards CPU time?
<lf94>
Looking at pi-calculus. Mind is pretty blown right now. It's like next-level lambda calculus. My question: Why do they call the channel inputs/outputs guards?
<lf94>
To me they just seem like...communication actions
<lf94>
or just "actions"
<lf94>
Or I guess calling them "communications" is more accurate
orivej has quit [Ping timeout: 250 seconds]
orivej has joined #racket
JoshS has quit [Ping timeout: 250 seconds]
m1dnight_ has joined #racket
hjek has joined #racket
<winny>
is there a way to get parserack to parse an input-port?
<winny>
i only saw the parse-string feature
<winny>
oh sorry, i was referring to megaparsack
cpup has quit [Quit: Breaking stuff]
cpup has joined #racket
notzmv has quit [Ping timeout: 250 seconds]
<lexi-lambda>
winny: Not at the moment, no, but adding support for streaming input would be useful. Just keep in mind, however, that parsec’s backtracking model means that a lot of the stream often still needs to be kept in memory, since any use of try/p could cause the parser to eventually backtrack.
hjek has quit [Quit: Leaving.]
<winny>
yeah, i was wondering if backtracking/peeking was why it's provided like that
<winny>
i have to say, pretty pleasant experience using megaparsack and the data/* stuff. Clean and concise