2,094 karma · joined August 26, 2008
http://paulcollier.ca/
I wonder how its performance is on dense models.
And near the end, that bubbly euphoric/revelatory ascending arpeggio was a common motif.
Additive inking works pretty well. As long as I am adding black ink to the page, everything is responsive. But if I want to push other updates asynchronously, or (god forbid) erase something, then there is the danger of clobbering the user's inkwork. I don't have any deep insights here, beyond waiting for human confirmation before updating anything.
I wonder if it is possible to detect when the pen tip has "left" the proximity of the page? If I knew this, I'd know when it was safe to update the UI.
I have decided not to use any scrolling at all. I am paginating everything and positioning input areas near the vertical middle of the device for comfort.
Effectively system instructions and server-side prompts are red, whereas user input is normal text.
It would have to be trained from scratch on a meticulous corpus which never crosses the line. I wonder if the resulting model would be easier to guide and less susceptible to prompt injection.
The fan increases air speed at the centre of the rotor, creating a low pressure zone which then sucks in surrounding air. So it helps to place the fan away from the window (roughly far enough that the wind cone "fits" the opening).
But if someone else were to do it for me I would gratefully review the merge request.
For example, if your client-sent request to insert a character fails, do you just retry the request? What if an update arrived in the intervening time? (Edit: they acknowledge this case in the “Client-Side” section, the proposal is to rewind and replay, and a simpler proposal to block until the pending queue is flushed)
From a frontend vantage I feel like there may be a long tail of underspecified UI/UX edge cases, such that CRDT would be simpler overall. And how does the editor feel to use while riding the NYC subway where coverage is spotty?