this can occur if tiny_skia decides it doesn't like the path (e.g. circle with negative radius)
i don't really care to render these since they're degenerate cases anyways
my VPS has 8 gigabytes of RAM. it's not exactly out of the question to buy a larger one, and in the future we could just, y'know, not preallocate _all_ the memory, and instead reallocate if a certain threshold is reached
parser events don't take up enough memory to warrant a stricter limit.
I do wonder if this limit is actually reachable with a 65536 character limit though.
for faster load times, and seamless updates.
because for some reason ServeDir can't do it correctly, and it tells the client "yeah hey nothing changed" even if something changed
I hate NaN
I hate NaN
I hate NaN
I hate NaN
I hate NaN
I hate NaN
I hate NaN
can someone put a NaN to good use for once and store a pointer to some helpful metadata in it.
please.
I beg you.
I've been (hotly) debating this with myself today and I _think_ this is the right decision for an app.
note that I'm not changing the font size in the docs; that I think is valuable to have be user-controllable, but I'd really prefer if users would see the app the way _I_ design it to look
previously we'd create (argument_count + let_count) locals, which doesn't make sense.
so now `let`s use their own counter for their own locals, and we only request as many empty locals as there are `let`s.
> #81 Compiling brush doesn't seem to finish correctly sometimes, which causes loss of data
> Sometimes it seems like the client state can get desynced (server render thread dies due to a panic?) and then the server starts dropping all requests for drawing the brush.
> These panics should never happen of course, but we need better logging first to determine the exact cause.
the arity of unary and binary ops is guaranteed by the fact they're, well, unary and binary ops.
right now there's no way to call them with less or more arguments, so we may as well.
liquidex