03:00:48kentonvwell I'm excited that someone is working at that level! We don't get much feedback about the raw API. And you can actually plausibly create an IRC bot at that level right now, since you'll have no problem using the Cap'n Proto interfaces for networking rather than the standard sockets API.
03:33:56kentonvprobably getting the binary down to ~150 bytes is not essential for a Sandstorm app. :)
03:34:47kentonvDavid's Acronymy is an example of a Sandstorm app written in Cap'n Proto. Although Cap'n Proto Rust has been in flux lately so that code is probably horribly outdated.
04:01:34paulproteusXgF: Perhaps sandstorm-http-bridge or something should link to sandstorm-rawapi-example in the comments, or something, to have helped you find it sooner?
07:06:56dcbdwrensha: is there a recommended way to go from MallocMessageBuilder to some kind of MessageReader? I used to use SegmentArrayMessageReader, but its ctor needs to be changed to take an OutputSegments to continue doing that, which may break other users
07:07:49dcbI guess I could just do a serialization round trip, I'm only doing this in tests
07:41:25kentonvdcb: You can do getRoot<Whatever>().getReader() to get a reader for the root object.
07:42:04kentonvdcb: If you need a full MessageReader, then SegmentArrayMessageReader is the easiest way. I don't think you should have had to change anything. Can you describe what went wrong?
07:43:10kentonvSegmentArrayMessageReader reader(builder.getSegmentsForOutput()) should work
07:43:18Guest1kentonv: dwrensha pushed a change this morning that tweaks how MessageBuilder lends out it's segments, and as a result it's now not possible to create a SegmentArrayMessageReader from a MessageBuilder
07:43:49kentonvGuest1: Oh, I guess you're talking about rust?
08:10:49dcbbut it's impossible to make a method that takes a &MallocMessageBuilder and returns a SegmentArrayMessageReader, which was what I was trying
08:22:14dwrenshadcb: what does into_reader() accomplish that you couldn't do with get_root() and as_reader()?
08:23:05dwrensha(I think you meant `fn into_reader(message: &MallocMessageBuilder) -> SegmentArrayMessageReader` above)
08:23:55dcbdwrensha: I have a state machine that takes OwnedSpaceMessageReaders and returns MallocMessageBuilders (meant to be applied to another state machine). To test this I have to do the conversion
08:24:19dcbbut basically the actual message unpacking is done behind the interface I'm testing
08:26:54dwrenshaLol, I just accidentally typed a "~" when I meant "Box<>". Old habits die hard.
08:27:32dcbMaybe it's simpler to think of it as testing a networked objects, locally. So I have n object A that sends messages to object B. So A outputs MessageBuilders and B takes in MessageReaders. Normally the conversion is done on the network bits, but I want to test without the network
08:30:16dwrenshaI can definitely do `pub fn get(self) -> Box<[&'a [Word]]>`
08:41:32dcbProbably easiest to just make a new MessageReader type that takes ownership of an OutputSegments
08:49:01dwrenshahm. I guess into_boxed_slice() doesn't actually solve your problem unless there's a way to construct a message reader that takes ownership of the Box<[&[Word]]>
09:04:02dwrenshadcb: since you only need this for testing, would be a big deal just to copy the message to convert from a builder to a reader?
09:04:29dcbdwrensha: that's what I'm doing, serializing to a Vec and then back. It will be fine for that use case
09:05:03dcbI can write an OutputSegmentsMessageReader if I need it
09:13:29dwrenshakentonv: in case you're curious, the change we made today in capnproto-rust would translate back to c++ as changing the signature of `writeMessage` to be `void writeMessage(OutputStream& output, const MessageBuilder& builder)`
09:13:47dwrensha(at least I think that's where the const-qualifier would go)
12:07:48ocdtrekkieIt looks just like the alpha server, just without all my :stuff:
12:07:49kentonvnote that at this time I estimate 95% chance it will crash at some point and I won't notice for a day, and maybe 50% chance all data is randomly deleted at some point. (That should go down quickly over the next few days though.)
12:08:39kentonvI mean I am kenton, and I built in on megaman, so I don't know what you want. :P
12:09:47kentonvit's funny, if you crack the frontend and run arbitrary code, you won't be able to tell it isn't sandstorm, except that /var/sandstorm is eerily empty.
12:10:25zarvoxI mean, normally that's a major.minor, not a "[$user@$host $date]"
12:11:00kentonvzarvox: if you build sandstorm from source without pushing a release you normally see that kind of build stamp.
12:12:02kentonvtestrock will get non-official buildstamps. The actual hosting service, when it goes live, will get normal buildstamps.
12:12:27zarvoxAhhh, I guess I've mostly spent time with vagrant-spk, which uses packaged releases, so I never noticed that!
12:12:59kentonvso basically no one will be able to tell that they're not on Sandstorm. Not that I'm trying to hide it, I just like the symmetry.
12:16:06kentonvmaybe it'll throw off some competitors too. :)
12:25:48ocdtrekkieI had kinda figured Blackrock was "a thing that ran Sandstorms" as opposed to an entirely separate backend.
12:36:24zarvoxocdtrekkie: There's a bunch of APIs that are decently well-defined in Sandstorm! Which API did you expect that Blackrock would provide an alternate implementation of?
12:37:36ocdtrekkieI just mean like, the way I visualized Sandstorm and Blackrock in my head were like... ESXi and vSphere. ESXi is free, and you can run apps and stuff on it, but vSphere allows you to do a lot more things with your ESXis, including cluster management and stuff.
12:42:10ocdtrekkiekentonv: Wouldn't your About page be "About Blackrock" and "Blackrock Server" and such?
14:47:16kentonvocdtrekkie: it's effectively equivalent to a thing that runs Sandstorms, but a few orders of magnitude more efficient than literally running a Sandstorm VM for every user. Since most users aren't using their resources most of the time, we can distributed them far more effectively with a few tricks.
14:50:42kentonvso basically we can give you the equivalent of a $50/mo private VM for $6/mo.
14:51:33ocdtrekkieWell, I didn't suppose it was making a whole VM for each user.
14:52:34kentonvthen it's pretty much what you expect. FWIW, pretty much all of the open source Sandstorm code is used by Blackrock. There's just some added plumbing to distribute nicely over a cluster of machines.
14:53:08ocdtrekkieI mean that when you use vSphere, you're still using the same ESXi. My analogy was that I didn't think Blackrock would actually run a different build of Sandstorm. Just more something telling which Sandstorm to run which grain and such.
14:54:20ocdtrekkieBut then, ESXi is closed source, so I assume they can easily put the "enterprise" code in there, and just disable it, moreso than one can do with an open source free program.
14:57:36ocdtrekkieI'm pretty excited though, Blackrock working + Etherpad looking a lot more professional with the plugins really makes everything feel a lot closer to 'done'.
14:59:29kentonvBlackrock is only kind of working, but yeah. :)
15:00:02kentonvbackup/restore and web publishing are still not working. The former obviously being pretty important for beta users, the latter a little less but still important.
15:00:28kentonvhopefully will get that figured out this week then start the beta
15:04:16ocdtrekkieSome sort of meta-backup of "all your stuff" would probably be helpful too.
15:04:55ocdtrekkieI try to back up my halfway-decently-valuable grains on occasion, but if I could script a download of it every day, I'd probably do it every day.
15:05:24kentonvmy plan is to make an API so you can have "backup apps"
15:06:19kentonvand we'll actually back up Blackrock's data that way, but also you'll be able to back up your self-hosted data to Blackrock (encrypted)
15:06:38kentonvbut perhaps someone will write an app for dropbox, etc.
15:06:56zarvoxspeaking of dropbox, I'm still eagerly awaiting the day that the hackpad source gets released
15:07:42kentonvme too, though having discovered etherpad plugins reduces that pain quite a bit
15:08:26kentonvI feel like it's actually reasonably close to Hackpad now, just needs some design work and polish