<ocdtrekkie>
paulproteus: As much as I primarily use Windows, I am not really obsessed with everyone else using Windows. Though I'd much rather they use something intelligent like Linux rather than OS X. ;) - Response to very old comment in here.
<paulproteus>
I have to say, I was using Windows to test vagrant-spk, and it just filled me with a warm loving feeling.
<paulproteus>
Windows 7 (on the kentonv machines) is like interactive nostalgia for high school, given how similar it is to Windows 98 and NT4 and 2000 that I used then.
<paulproteus>
So anyway, there's *my* random hat in the Windows ring.
<paulproteus>
i,i the Windows ring 0
neynah has joined #sandstorm
<ocdtrekkie>
Sorry I've been somewhat light on presence here.
<ocdtrekkie>
New job, trying to be impressive and stuff.
<paulproteus>
(-: ocdtrekkie
<paulproteus>
I'm not sorry. I'm glad you're trying to be impressive and hopeful you're succeeding.
<ocdtrekkie>
Seems like they like me so far.
<paulproteus>
Excellent. Also taking a trip AFK.
jadewang has quit [Remote host closed the connection]
<paulproteus>
larjona: I saw your email; taking a look now, fwiw
jadewang has joined #sandstorm
dwrensha has joined #sandstorm
<larjona>
paulproteus happy Friday!
jadewang has quit [Ping timeout: 250 seconds]
<paulproteus>
(-:
<kentonv>
dwrensha: I would say "OMG I wish I knew about this feature before", except that apparently it doesn't work for any use case I care about as you point out.
<paulproteus>
I do wish Andy would leave more ads for Sandstorm in these CVEs.
dwrensha has quit [Ping timeout: 240 seconds]
dwrensha_ is now known as dwrensha
<XgF>
paulproteus: Yay, with the only side effect being you can't run WINE :-)
<paulproteus>
Fascinating.
NOTevil has joined #sandstorm
<geofft>
huh, I didn't really realize that modify_ldt was still a thing on x86_64
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
<XgF>
geofft: Yes, for WINE :P
<geofft>
oh, is this for like %fs or %gs for thread-local mumble?
<geofft>
or is this for 32-bit apps?
<XgF>
geofft: For 32-bit and 16-bit apps
todayman has quit [Remote host closed the connection]
<jadewang>
just wanted to share this:
<jadewang>
" /\___/\
<jadewang>
( o o )
<jadewang>
/ * \
<jadewang>
\__\_/__/ meow!
<jadewang>
/ \
<jadewang>
/ ___ \
<jadewang>
\/___\/
<jadewang>
"
<paulproteus>
: D
<paulproteus>
I like this text: "Someone has Etherpad open in a tab, suspends their machine, then restores it later. In the meantime, Sandstorm wasn't sending keep-alives, so the server has shut down. Etherpad promptly freaks"
<paulproteus>
BTW larjona did my email help at all?
jadewang has quit [Remote host closed the connection]
<larjona>
Emails always help :) I didn't try out anything yet.
joshbuddy has joined #sandstorm
NOTevil has quit [Quit: ...]
<larjona>
paulproteus your tip worked, I'm facing different issues now, but will find my way. Thanks!
jadewang has joined #sandstorm
<paulproteus>
larjona: Hooray!
neynah has joined #sandstorm
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
<larjona>
Hi everybody! paulproteus do you have some minutes for me?
mort___ has joined #sandstorm
<neynah>
Hello everyone! :)
<paulproteus>
larjona: Ya sup
<geofft>
dwrensha: minor complaint, I keep writing RPC impls and forgetting to do context.done()
<geofft>
I sort of want to make them return a Result<(), String> instead of requiring you do context.done() / context.fail(String)
<maurer>
geofft: What would you suggest be done instead? The context destructor call .done? the context destructor call .fail("Context never finishing") ?
<geofft>
(for bonus points, try! works)
<maurer>
geofft: Returning Result<> is not a good answer because it means you cannot mark the context as done, then do other things
<geofft>
oh, does context.done() let the RPC system start sending a reply message or something?
<maurer>
For example, say that someone sent you a capability to register a callback
<maurer>
geofft: ...yes. context.done() says "Hey RPC system, the result buffer contains the answer"
<geofft>
I'm doing that, but I set up the callback thread before calling done(). I suppose I shouldn't for performance?
<geofft>
but like also it might fail? idk.
<maurer>
I mean, some things should be done before .done()
<maurer>
others might be done afterwards
<geofft>
what about having it return Result but keep the context.done() method?
<kentonv>
presumably this will be completely different once everything switches over to promises...
<geofft>
if the impl method returns without calling done() and returns Ok(()), it's an implied done
<geofft>
(and the type system insists that you return _something_, so you catch this at compile time)
<maurer>
kentonv: I was pretty sure the C++ version still has you calling .done() and .fail() for the same reason?
<maurer>
kentonv: feel free to correct me if I'm misunderstanding
<kentonv>
maurer: Nope, in C++ you return a Promise<void>
<kentonv>
which resolves when the call is done
<maurer>
Oh yeah, that vaguely rings a bell now. Sorry
<kentonv>
you do have to use `context.getResults()` to get the result struct where you fill in the return values, if any
<maurer>
In any case, I like .done() on the rust side because lacking a promise system, it allows me to say "The RPC part is done now, but I've got other internal bookkeeping work to do as a result of your RPC"
<geofft>
yeah, I'm not suggesting returning a Result<actual RPC results, String>, just a Result<(), String>
mort___ has quit [Quit: Leaving.]
<geofft>
I do _appreciate_ how capnp-rpc doesn't look like local methods that are magically remote, even though I hate it :P
<geofft>
(and I'll probably stop hating it when my codebase gets more involved)
<kentonv>
my guess (though dwrensha would know better) is the reason the code doesn't assume done on return is because it expects asynchronous completion to be a common thing.
<kentonv>
the promise approach makes it a lot easier to deal with that
<larjona>
Sorry paulproteus, I was reading the documentation. I got Framadate running. When I select "create a new schedule" (or poll, doesn't matter), I have to fulfill a page with data (name of poll,description etc) and when I click on "next", it seems the app does not "remember" the data I just filled in, because it tells me I didn't fill in the "first section". I suppose I need to do something related to "session", not sure what (I'm reading
<larjona>
I found nothing interesting in the debug log, seems everything is ok
<dwrensha>
kentonv, geofft: you can move the context into a separate thread! That wouldn't be possible in the `return Ok(());` approach.
<maurer>
If we're talking about catching the programming error though, we could always just add an implicit .fail("dropped without completion") to Drop for context
<maurer>
It'd be runtime, but at least you wouldn't be confused about why it was hung