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
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
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.
introduce a new, more ergonomic syntax for haku
not all features are implemented just yet. still missing:
- custom tags (non-True/False)
- color literals
- lists
error handling shows you the error and offers the ability to reload;
disconnect handling shows you that the page will reload in a few seconds.
it uses exponential backoff with some random sprinkled into it to prevent overwhelming the server once people's clients decide to reconnect.
mainly related to me not knowing how to decode WebP properly (I blame the API design of the webp crate)
turns out it can return RGB images instead of RGBA and so you have to convert it to RGBA first
there were also a couple math bugs with chunk drawing/saving related to some of my refactors of that math
it's probably okay, but it's incredibly easy to read localStorage from the frontend and get a hold of the secret
would be nice (would it?) to have more proper session tokens I guess but we're not doing that right now
I'm not entirely sure if generating the password on the server is legit like this, but it leads to an incredibly frictionless experience and I'd like to keep it. if possible.
I don't really see a difference compared to password managers generating passwords for you and showing them in plaintext
obviously actual passwords are stored within the manager which requires a master password, but like. do we really need that. the secret isn't shown to the user and it's very long.
too bad the browser secure storage API or whatever isn't ready yet
this fixes the case where
(def botsbuildbots (fn () (botsbuildbots))) (botsbuildbots)
would not run properly (return with a "set def index out of bounds" error)
also make exceptions store String instead of &'static str for better error reporting
closes#33
liquidex