<paulproteus>
ocdtrekkie: ^ penny for your thoughts
<kentonv>
XgF: I am totally going to cite that next time someone complains about Cap'n Proto refusing to use the standard library.
<kentonv>
XgF: I believe this means that vector<string> is forced to copy (not move) each string when growing the backing store?
<dwrensha>
whaa
<kentonv>
XgF: or I guess if it only applies to operator= but not the move constructor, maybe not
<kentonv>
still, walking on thin ice there
<XgF>
Also C++17 is adding std::variant which has an additional "null" value because of course you want to put a std::string in a variant and oops we just made its' move assignment operator throw so there is no way to do this without a stupid null value
<kentonv>
I mean to be fair, my opinion is that everything can throw, because everything can have bugs, and the best-case outcome of a bug is throwing (as opposed to corrupting data)
<kentonv>
what I find ridiculous is that vector<X> refuses to move-construct members if X's move constructor can throw, for fear of being in an inconsistent state.
<kentonv>
this is just incredibly pedantic
<XgF>
I disagree; moving should never throw, and something should never be in an inconsistent state (because that makes *cleanup* impossible too)
<kentonv>
it should always be _intended_ that moving does not throw. But having the program abort because a move constructor has a bug is wrong.
<kentonv>
to me, the whole point of exceptions is to be able to do something other than abort when an unexpected condition is reached
<kentonv>
I agree that cleanup should always be possible but I don't think that's generally very hard to accomplish.
<XgF>
throwing move constructors prevents things like the aforementioned example of std::variant
<kentonv>
in the vector case, whatever, just delete the half the vector that was already moved.
<dwrensha>
I think if it's an internal bug, then "abort with debugging information" is sensible.
<kentonv>
not really. Put the variant into a state where any time you try to access it, it throws.
<dwrensha>
If it's dealing with unexpected input, then the program should be able to recover
<XgF>
kentonv: Thats an additional "null" state and is totally undesirable
<kentonv>
XgF: it's a "null" state but not one the app is expected to know about or handle
<kentonv>
dwrensha: that's a nice and popular theory but it really breaks down when you have large, complicated systems handling lots of requests at once.
<XgF>
kentonv: Nope. Any case in which I can think of I'd want a move constructor to throw, something has gone *seriously* wrong and I want to get the hell out of dodge before that becomes a more serious (i.e. security) issue
<dwrensha>
like, there's almost certainly a bug somewhere, and you can't afford to die whenever you hit it?
<kentonv>
dwrensha: At Google, asserts that abort are banned in any server that interacts with live users, because it was found that _in practice_ doing that just produces disasters.
<kentonv>
because yes, there are always bugs, and if you kill the process, then you just magnified the problem
<kentonv>
where it's very likely that if you just errored out the current request, everything would have been OK
<kentonv>
yes, it is _possible_ that a bug will corrupt something in a way that affects other requests and now the server is hosed and should have been aborted. However, in practice, that is almost never what actually happens.
<XgF>
Mostly, any case I can see of where a move constructor would actually want to throw (rather than ridiculous pedanticism like max_size() < size()) something is *so* screwed up that I'm pretty sure the process would be hosed
<kentonv>
In pretty much every observed real-world case, throwing an exception would have been fine
<kentonv>
XgF: I agree, I can't think of any case where a move constructor should rightly throw.
<XgF>
Destructors throwing are a different matter. Dyanmic runtime errors are a different matter (ENOENT, EBADFD, etc). Even "NullPointerException" is a different matter
<kentonv>
but I still say aborting is not the right answer, unless you _know_ that an error has likely hosed the server. For example, if you have a block of code that is modifying shared state, and you know things are likely ruined if it doesn't complete in full, you might wrap it in a try/catch that aborts in the catch. But that's unusual.
<XgF>
But the other reason I'm saying that may be that I've been in the bowels of a (precisely) GC'd system written in C++ lately and if any of the GC invariants go wrong, everything goes to hell *really* quickly so if I detect any of them I want to tear things down *right now*
<kentonv>
I mean, most of the C++ code I write (and I write a lot of it) can be described that way.
<kentonv>
but I don't find it's very hard to make sure that cleanup happens correctly after an exception
<XgF>
(My protip for anyone ever working on a GC: Add a mode in which you do a collect at *every* opportunity, it makes debugging sooo much easier)
<kentonv>
oh I see, you actually mean GC GC
<kentonv>
I interpreted "precisely GC'd" as "deterministic GC", which is essentially what C++ does
<kentonv>
yeah C++ with GC (other than destructors) is scary
<XgF>
I think I'll actually port this to Rust soon since that way I can enforce GC safepoint invariants with borrowck
<XgF>
(Also escape the implosion of the C++ standard library)
<kentonv>
if you want a C++ standard library replacement you can try KJ. :)
<kentonv>
it's not quite a complete replacement yet, but it has non-stupid strings. :)
<kentonv>
(KJ is what Cap'n Proto uses)
<kentonv>
(they are currently shipped together, but have a clear separation in the code)
<XgF>
Yeah, I'm very inclined to redo this in Rust because (A) it's for fun and (B) C++ doesn't have a borrowck :-)
<kentonv>
on one hand I mostly really want to use Rust, on the other hand I think the fact that panics abort the process is not tenable. A seemingly small point that kind of ruins everything for me. :/
<XgF>
panic!s abort the thread, IIRC
<dwrensha>
you can think of Result<T,E> as the "checked exception" monad
<kentonv>
but I don't want a checked exception monad
<kentonv>
because I don't want checked exceptions
<kentonv>
because to me the whole point of exceptions is to be thrown when something unexpected happens, and unexpected things can happen anywhere and I don't know what type they are ahead of time.
<kentonv>
also doing it as a monad is inefficient compared to what C++ does
<dwrensha>
If you don't care about the type, you can use Result<T, Box<Error>>.
<kentonv>
sure sure, but I have to do that _everywhere_. :/
<XgF>
Either its' an error you care about or you can get away with panicing (Which only kills that task, not the process)
<kentonv>
it doesn't help me that it only kills the thread, because threads aren't lightweight anymore so I have to use event loops.
<kentonv>
actually the old lightweight threads might have made this OK for me, but that's gone now.
<kentonv>
in any case, XgF, the thing is, I want to write code that asserts all over the damned place, but I don't want those asserts to kill the whole server
<kentonv>
if my choices are panic -- which kills everything -- or uglifying literally _all_ may APIs with an error monad, then I'm likely to choose a third option which is to not assert in the first place, and just hope bugs don't happen. Or try to paper over them by returning dummy results, etc.
<kentonv>
and that's really a lot worse
<kentonv>
I have been able to iterate on and debug Sandstorm code far faster than Google C++ projects I've worked on because I am able to liberally throw and log exceptions.
<dwrensha>
When you're using an event loop, you're usually in a Promise monad anyway, where everything is in terms of Result<T, E>.
<kentonv>
(among other things)
<kentonv>
dwrensha: it's OK if I'm strictly in code that's directly using promises, but once I call into any utility functions or library code that isn't I/O-related, I can no longer assume the ability to propagate errors...
<XgF>
N.B. Theres the try! macro which propogates the result on error or unwraps it on success, so Result<T, E> is a lot less painful than in, say, C++
<kentonv>
I mean if people make it so that I don't have to laboriously write Result<T, E> everywhere, but can just write T instead, and use macros for try/catch... then great, but why not just implement real exceptions in the first place?
<kentonv>
(also will anyone implement the right optimizations so that working in the Result<T, E> monad has no runtime cost unless an error is actually thrown?)
<XgF>
Result<T, E> is an error, not an exception (i.e. its' not exceptional :-))
<kentonv>
well, is it equivalent to exceptions or is it not? You seem to be arguing both ways. :P
<XgF>
It subsumes both errors and exceptions :-)
<XgF>
(Except for the very exceptional unrecoverable error - e.g. std::bad_alloc)
<kentonv>
although std::bad_alloc almost always means "you had an arithmetic underflow error when computing the size you wanted to allocate", not actually "there's no more memory"
<XgF>
I'm pretty sure that if std::bad_alloc actually meant "you ran out of memory", most of the time libgcc_eh would abort() because it couldn't malloc :P
<kentonv>
actually, no! It pre-allocates some emergency space
<fkautz>
kentonv: was that in response to my report about low memory environment?
<fkautz>
oh wait, more context
<fkautz>
nevermind :p
<fkautz>
i should read up more than 3 lines
<kentonv>
:P
<fkautz>
6 seems to be the magic line reading number for context :p
darius has quit [Remote host closed the connection]
<dwrensha>
oh, maybe everything is failing on oasis right now?
<kentonv>
ehhhh?
<kentonv>
hmm, seems to work for me
<kentonv>
I think it has self-healed at this point, but the logs certainly show some noise
<dwrensha>
still somewhat broken for me
<dwrensha>
I'm here creating new etherpad grains
<dwrensha>
and getting an error each time
<dwrensha>
hm, worked this time
<dwrensha>
didn't work this time
<dwrensha>
(etc.)
<kentonv>
one of the two worker machines was in a weird state that threw an exception on grain startup.
<kentonv>
I think I fixed the weird state, but I'll need to fix the code to make it not happen again
<ocdtrekkie>
paulproteus: Where does the documents on the other packaging tools go? :D
<paulproteus>
ocdtrekkie: I think I need a new section, like, "Raw packaging tools" or something.
<ocdtrekkie>
And then just have like a one-page for each tool?
<paulproteus>
Seems like it could be a thing within "App packaging".
<paulproteus>
I don't want raw spk to be front-and-center in the docs, but documenting it is something I remain +1 on.
<ocdtrekkie>
I would personally be like +1 on "Packaging with Vagrant" and "Other Packaging Tools". I still find it rough to have the Vagrant section (which should lead, I agree) as just "App Packaging".
<paulproteus>
"it was Kenton's idea"
<kentonv>
well
<kentonv>
I mostly didn't like the section being titled "vagrant-spk" because newcomers would have no idea what that is
<kentonv>
I think "app packaging" could use subsections for each tool. Maybe it starts with vagrant-spk but later on it presents other tools as advanced topics.
<ocdtrekkie>
My notion is the headings above both clearly denote that "this is for packaging" and "this is the Vagrant version".
<paulproteus>
I semi-exaggerate by declaring the title is Kenton's fault : P . The point is I'm going to bed and will chat more about it tomorrow. I think having more pages within
<paulproteus>
"App packaging" is a good idea for sure.
<ocdtrekkie>
But if the heading for Vagrant only is "App Packaging", I expect ALL app packaging info to be there.
<ocdtrekkie>
So either all tools should fit under the App Packaging heading, or the App Packaging heading shouldn't sound so all-inclusive.
<ocdtrekkie>
Is my thought.
<ocdtrekkie>
I would like "App Packaging with Vagrant" and "Other Packaging Tools" as headings, so that we do not overload the App Packaging category with too many pages.
<kentonv>
ocdtrekkie: to be fair, the new documentation page currently contains no docs for non-vagrant-spk packaging tools
<ocdtrekkie>
kentonv: No, but my first question was "where do they go?"
<ocdtrekkie>
;)
<kentonv>
well I expect we will have lots more non-development-related docs eventually
<kentonv>
having multiple top-level sections for dev tools might get crowded
<ocdtrekkie>
Can you do subheadings or dividers in the menus?
<kentonv>
hopefully
<kentonv>
(I'm not the one setting this up though)
<ocdtrekkie>
Dev documents might get a little overloaded in one menu though, or even two.
<ocdtrekkie>
Particularly since APIs and stuff will need pages.
<kentonv>
I can imagine APIs being a separate section from packaging tools... but that just again suggests having multiple sections of packaging tools would be a bit much. :)
<ocdtrekkie>
That is true.
<ocdtrekkie>
paulproteus: So, where's my penny?
gopar has quit [Quit: Leaving]
jadewang has quit [Remote host closed the connection]
joshbuddy has quit [Quit: joshbuddy]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 264 seconds]
yeehi has joined #sandstorm
yeehi has quit [Ping timeout: 276 seconds]
yeehi has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 246 seconds]
yeehi has quit [Ping timeout: 264 seconds]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 246 seconds]
keturn has quit [Ping timeout: 256 seconds]
keturn has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 264 seconds]
amyers has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 252 seconds]
decipherstatic has quit [Remote host closed the connection]
amyers has quit [Read error: Connection reset by peer]
amyers has joined #sandstorm
amyers has quit [Read error: Connection reset by peer]
amyers has joined #sandstorm
amyers has quit [Read error: Connection reset by peer]
amyers has joined #sandstorm
amyers has quit [Read error: Connection reset by peer]
amyers has joined #sandstorm
amyers has quit [Read error: Connection reset by peer]
amyers has joined #sandstorm
amyers has quit [Read error: Connection reset by peer]
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
natea has joined #sandstorm
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 265 seconds]
natea has quit [Ping timeout: 264 seconds]
natea has joined #sandstorm
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
amyers has quit [Quit: Leaving]
amyers has joined #sandstorm
jadewang has joined #sandstorm
natea has quit [Ping timeout: 264 seconds]
natea has joined #sandstorm
jadewang has quit [Ping timeout: 250 seconds]
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
natea has quit [Ping timeout: 252 seconds]
natea has joined #sandstorm
natea has quit [Ping timeout: 245 seconds]
natea has joined #sandstorm
jadewang has joined #sandstorm
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
jadewang has quit [Ping timeout: 250 seconds]
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
joshbuddy has joined #sandstorm
dwrensha has quit [Ping timeout: 256 seconds]
nwf has quit [Ping timeout: 264 seconds]
nwf has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 264 seconds]
natea has quit [Ping timeout: 244 seconds]
natea has joined #sandstorm
natea has quit [Quit: natea]
dwrensha has joined #sandstorm
darius has joined #sandstorm
jadewang has joined #sandstorm
nwf has quit [Ping timeout: 244 seconds]
<paulproteus>
Can I just say I'm still excited docs.sandstorm.io is a thing.
<paulproteus>
It does need more docs (in terms of breadth). Right now I'm going to fix up the tutorial to address issues that came up when Jade tested it out.
<zarvox>
I like docs. Docs are nice. I may turn them purple at some point. Because theming.
<paulproteus>
I may experiment with this and submit a patch for things
<paulproteus>
Feel free to beat me to it (-:
<paulproteus>
Also kenton says perhaps vagrant-spk should be renamed sandstorm-sdk
<paulproteus>
Since neither 'vagrant' nor 'spk' obviously relate to Sandstorm.
<paulproteus>
I plan to consider that idea more seriously next week or later, but I thought I'd mention.
nwf has joined #sandstorm
<ocdtrekkie>
Iunno, I think at the point you're packaging apps, you should be able to figure that out.
<ocdtrekkie>
At bare minimum you should know what an SPK is.
nwf has quit [Ping timeout: 265 seconds]
<ocdtrekkie>
Also, one file is not a 'kit'. :)
<paulproteus>
You will know what an SPK is, but you might not yet know.
<paulproteus>
Also once zarvox gets his way and vagrant-spk bundles commands to do cap'n proto RPC, then maybe it starts to be more of a kit.
<paulproteus>
zarvox: Random note: Maybe vagrant-spk (or sandstorm-sdk) should detect if other running Vagrant VMs are vagrant-spk VMs if it finds port 6080 is used, and then provide some useful info on how to stop them. +1 -1 ?
<paulproteus>
i,i what I really need is to look at the github contributors for oss projects I care about, and sort them by social distance to me
<paulproteus>
XgF: BTW, docs.sandstorm.io runs on GitWeb Pages. (-:
<paulproteus>
Hopefully that covers the stuff we were telling you to do manually this week.
<paulproteus>
By all means feel free to scroll around and see that section in context.
<zarvox>
paulproteus: "the virtual machine uses always uses port 6080" - one too many "uses" in there?
<paulproteus>
zarvox: good catch;reload
<paulproteus>
wait nope
<paulproteus>
one sec
<paulproteus>
now reload zarvox !
<paulproteus>
It'd be nice to add screenshots to this at some point.
<paulproteus>
Semi-sad as it would be to make it look longer.
<zarvox>
also I'm going to add "vagrant-spk global-status" which just passes through to "vagrant global-status", because people make mistakes sometimes
<zarvox>
some day perhaps we should parse the output there, or record our own manifests in $HOME/.sandstorm/vm-registry or something, but for now, I think this is a reasonable tradeoff
<paulproteus>
++ re: vagrant-spk global-status; I will then fix the tutorial to never say vanilla `vagrant global-status` since `vagrant-spk global-status` is strictly better. +1 ?
<zarvox>
+1
<paulproteus>
Hilariously (?) this command won't exist for people with an old vagrant-spk.
<paulproteus>
I wonder what if anything we should do about that.
<paulproteus>
Perhaps this is another good reason to have vagrant-spk be bundled with Sandstorm, so it can auto-update.
joshbuddy has quit [Quit: joshbuddy]
<zarvox>
But if it's bundled with Sandstorm, how do we support OSX and Windows users?
<paulproteus>
I... had forgotten about that.
<paulproteus>
Good point.
<paulproteus>
: D
<zarvox>
Perhaps this tool also needs to be able to self-update.
<zarvox>
:/
<paulproteus>
The "good" news is that 'vagrant-spk update' (or something) can "just" cd into the vagrant-spk directory and git pull.
<paulproteus>
Oh, but probably not on Windows.
<zarvox>
that works for OSX
<zarvox>
yeah
<paulproteus>
But possibly, depending how we do it.
<paulproteus>
But yeah.
<zarvox>
...I'd rather not bundle all of msysgit, but if we *have* to...
<paulproteus>
We should probably at least have version numbers, and the docs should list which version added new commands, perhaps.
<paulproteus>
I love the idea of bundling all of msysgit as a last resort, but only in theory. Which is to say, I agree with you.
<zarvox>
Perhaps. Which probably also means that I should get my command line arguments under control; they're a hack that I threw together that one day and never really replaced <_<
<paulproteus>
Yeah. I agree, but I think we're OK for now.
nwf has joined #sandstorm
amyers has quit [Remote host closed the connection]
<paulproteus>
Not really objecting, but it would have been nice to get these a week ago instead so I could have worried less. Oh well.
<zarvox>
Heh.
<paulproteus>
Oh snap I left my nice camera at home, so I should pick it up pre-meetup probably.
<mcpherrin>
should I show up fashionably late to this meetup or what
<mcpherrin>
6pm +- 10 seconds
<paulproteus>
FWIW the food supposedly arrives at 6, so you might as well be on time, I figure.
<paulproteus>
I promised Jack that I'd write up some kind of tour of Sandstorm for people new to the project to work through, and ask questions of e.g. me as they do so.
<paulproteus>
I'm sort of drawing a blank for what that should be like.
natea has quit [Read error: Connection reset by peer]
<paulproteus>
libmimedir allows remote attackers to execute arbitrary code via a VCF file with two NULL bytes at the end of the file, related to "free" function calls in the "lexer's memory clean-up procedure."https://security-tracker.debian.org/tracker/CVE-2015-3205
ripdog has quit [Ping timeout: 256 seconds]
amyers has joined #sandstorm
keturn has quit [Ping timeout: 264 seconds]
nickmeharry has quit [Ping timeout: 264 seconds]
nickmeharry has joined #sandstorm
jadewang has quit [*.net *.split]
saneki has quit [*.net *.split]
simonft has quit [*.net *.split]
isis has quit [*.net *.split]
ripdog has joined #sandstorm
joshbuddy has joined #sandstorm
<paulproteus>
In writing this, I can imagine someone working through the "Learn about Sandstorm" thing being so boring.
<paulproteus>
I wonder if it'd be possible to re-do this as a series of questions.
amyers has quit [Ping timeout: 264 seconds]
<paulproteus>
"Visit the Sandstorm demo, then answer this question. Q. Which of the following is available in Sandstorm: * Etherpad * Airpad * Google Docs"
<zarvox>
That actually sounds kinda fun.
<zarvox>
Answering the questions. 'specially in a group.
<paulproteus>
Oh, interesting.
<paulproteus>
I hadn't thought about doing that in a group1
<paulproteus>
!
<paulproteus>
I must briefly AFK. zarvox also can I possibly sign you up to help Jack Singleton run a table oriented around helping people package things?
<zarvox>
Could also do it as Q/A in the doc.
<paulproteus>
But also/alternatively you could run a table oriented around people learning how to use Sandstorm.
<paulproteus>
I was originally planning to do that myself but have no problem trading roles.
<zarvox>
paulproteus: yes, though I do have to leave a little bit early to make it to the symphony.
<paulproteus>
I'm planning to ship my "Guided tour of Sandstorm" into docs.sandstorm.io before the event, fwiw.
<zarvox>
But I'll have a good while I can help folks before then.
<paulproteus>
i,i https://symfony.com/ is PHP so that should be easy to package w/ vagrant-spk
keturn has joined #sandstorm
<paulproteus>
I think the Q&A in a group idea is splendid.
<paulproteus>
If you feel like owning that, I would mega appreciate it.
<paulproteus>
Now AFK-ing but we can chat more later.