<simpson>
Next step is to figure out how to build messages, I guess. Not sure if I want to go with an incremental builder, since Monte values are immutable by default.
<kentonv>
fundies, I assume you're cross-compiling? You'll need to install capnp on your host machine first, then use ./configure --with-external-capnp
<kentonv>
fundies, alternatively, it is possible to configure wine such that it is used automatically when running a windows executable (I've had success building capnp this way), but I'm not sure I'd recommend that
<kentonv>
something about the wine-binfmt package, but there are configuration steps that I can never remember
<kentonv>
simpson, I struggled a lot with how capnproto should work in Haskell way back when the compiler was written in Haskell. It seems like zero-copy writing is sort of inherently an imperative concept.
<kentonv>
I feel like there's a magic design out there involving lazy evaluation where all the data lands in the message buffer just right with a single copy, but I'm not sure what that design is or whether it would actually be performant
<simpson>
Well, for speed and copy removal, there's the JIT. I'm more thinking about the actual convenience of the API.
<kentonv>
yeah, it seems like the only reasonable answer is that you construct a "native" object tree and then invoke a function that converts it into a capnp message as one step.
<simpson>
Yep, that's about where I am right now.
<simpson>
Hm. An incremental builder could be used to attenuate, if one wanted to build a message by mixing several concerns together. But I'm not sure that that's worthwhile, since one could just write the mixing function in plain Monte without worrying about the Capn packing API.
<kentonv>
is monte functional, or is it imperative with a preference for immutability?
<simpson>
Monte's a member of the E family. There are mutable slots, but collections are immutable by default. My current approach keeps everything immutable for sanity. (I have no idea what "functional" or "imperative" could mean here, sorry.)
<kentonv>
I guess by "functional" I meant "like Haskell". It sounds like Monte is the latter. Good. :)
<kentonv>
so you could provide an incremental builder for people who want it, but suggest most people use the all-at-once serializer
<simpson>
Yes.
<kentonv>
that's probably where C++ is going to end up too, honestly. I've been wanting to support "POCS" for a while -- plain old C++ structs, that can be converted into a message with a single copy.
<kentonv>
because the zero-copy incremental building API is awkward, and you don't always need the performance
<simpson>
I mean, it's not really much different from standard scatter-gather, in the actual movement of data, so it's not the end of the world.
<simpson>
At least we have zero-copy reads right. We don't slice the underlying bytestring until a field access, and we use attenuation to manage access to the bytestring.
pie_ has quit [Remote host closed the connection]
pie_ has joined #sandstorm
xet7 has quit [Quit: Leaving]
xet7 has joined #sandstorm
<fundies>
kentonv, can I got it to cross compile but my program wont build for windows. can i not reuse my capnp files generated on linux?
<kentonv>
fundies, the problem is that you did `#include <windows.h>`, but windows.h #defines VOID, which breaks the Cap'n Proto headers where VOID is used as a constant value. You can fix this by doing "#undef VOID" immediately after you "#include <windows.h>"
pie_ has quit [Ping timeout: 260 seconds]
pie_ has joined #sandstorm
<kentonv>
(the generated code is exactly the same on all platforms, so that's not the problem)
<fundies>
kentonv, i dont include windows.h myself
<fundies>
something i use might
<fundies>
kentonv, shouldnt capnproto handle this undef?
* simpson
reads rpc.capnp and gets excited
<simpson>
I think that maybe we'll just not CapTP and only Capn.
<kentonv>
fundies, put the #undef after the other thing you include but before capnp headers
<kentonv>
or, include capnp headers first, before windows.h (or anything that includes windows.h)
<fundies>
kentonv, why doesnt the capnp headers undef it itself?
<kentonv>
it's not always the right answer. If we silently #undef VOID for you, we might break your code.
<fundies>
kentonv, why cant you just undef it your header only
<kentonv>
there's no way to do that
<fundies>
it wont replace capnp::VOID
<kentonv>
unfortunately windows.h defines lots of macros that have common names like VOID and BOOL and ERROR
<kentonv>
we do use a namespace! but windows doesn't
<kentonv>
yeah it will
<kentonv>
macros don't respect namespaces
<fundies>
or use a namespace
<fundies>
:/
<fundies>
it wont replace capnp_VOID then
<kentonv>
windows.h does: #define VOID void
<kentonv>
so capnp::VOID will become capnp::void
<kentonv>
which doesn't work
Telesight has quit [Remote host closed the connection]
<kentonv>
arguably cap'n proto shouldn't have used all-caps constant names, but it's too late to change that now.
frigginglorious has joined #sandstorm
<kentonv>
simpson, yeah, lately Mark Miller has been telling people to just use Cap'n Proto. :)
<fundies>
bbleh i cant find where to undef
<kentonv>
fundies, try adding `#include <windows.h>` at the top of your source file, followed #undef VOID, followed by all your other includes
<fundies>
kentonv, cant get it to work
<kentonv>
sorry, I don't know what to tell you.
<kentonv>
gotta reboot, back in a bit
kentonv has quit [Quit: Leaving]
kentonv has joined #sandstorm
frigginglorious has quit [Ping timeout: 248 seconds]