Fork me on GitHub
#clojure-dev
<
2020-06-20
>
mpenet14:06:56

is that a bug? (reduce (fn [ ] (reduced true) [])

dominicm14:06:16

The docstring covers this

mpenet14:06:56

yeah just saw that, tend to forget about it

mpenet15:06:04

it's not a bug I meant 😛

👍 1
gfredericks15:06:24

I just "fixed" a memory leak by converting (concat ws xs ys zs) to (concat (concat ws xs) (concat ys zs)) ; I can't quite convince myself by staring at the definition of concat why this would be the case; but is it a known issue/phenomenon?

devn08:06:07

Without knowing any of the specifics of your problem, https://stuartsierra.com/2015/04/26/clojure-donts-concat came to mind.

gfredericks12:06:43

yeah, I'm familiar with concat bombs; I don't think that can apply here; the symptom is OOM, not stack overflow, and the reason there's an OOM is the same reason I need to use laziness, I can't just make everything eager like he suggests

gfredericks15:06:56

(the seqs in question are lazy, of course, and are presumably somehow being overrealized or head-held when they needn't be)

hiredman22:06:40

Try lazy-cat

hiredman22:06:57

(I think that still exists)

hiredman22:06:22

Concat is a function, arguments evaluated, lazy-cat is a macro and does some extra thunkifying

gfredericks22:06:47

I don't see how it would be a problem that the args are merely evaluated

gfredericks22:06:59

as long as the whole lazy seqs aren't realized with a held head

hiredman22:06:00

I vaguely recall at some point something about concat not being as lazy as it could be, maybe it calls seq on all it's arguments or something (realizing the first element before it is strictly required).

gfredericks23:06:15

you might be recalling a mapcat ticket I made ages and ages ago