<kentonv>
btw, note that once the response messages come back, the client will send another set of messages to the server -- but it shouldn't need to wait for any further reply before the promises resolve.
<_habnabit>
okay
<_habnabit>
but so if the client just acted as if it had been disconnected immediately after the server sent the messages, would that be enough?
<kentonv>
yeah
<kentonv>
the last message is the client telling the server "OK, I got your response", at which point the server knows it can free the information it was keeping around to implement pipelining for that call.
<_habnabit>
got it
<kentonv>
(the server will also free those resources if it detects a disconnect)
Isla_de_Muerte has joined #sandstorm
NwS has quit [Ping timeout: 248 seconds]
anthropy has quit [Ping timeout: 258 seconds]
<_habnabit>
hm. i started using capnp decode to read the traffic, and it looks like the server is never sending an answer for the final question in the pipeline
<_habnabit>
the server reads all of those messages from the client, replies with those messages, and then blocks forever
mnutt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<_habnabit>
this is the 'evaluate a literal' calculator demo
<_habnabit>
i don't suppose there's something i missed for making capnp decode show the opaque values
<_habnabit>
oh goddammit i just found it. the client code doesn't pipeline at all >:(
<_habnabit>
it does the get_value in a callback
<_habnabit>
wait maybe i misunderstood this. ugh
<_habnabit>
i have a feeling this is a read/write ordering thing
mnutt has joined #sandstorm
<kentonv>
_habnabit: Yeah there's no good way to make the opaque pointers non-opaque. That would require specific knowledge of this protocol, since the decoder would have to look at interfaceId and methodId to figure out what type to expect. (Especially difficult on the return side.) I should probably write an RPC stream decoder tool at some point.
<_habnabit>
kentonv, more of: i'd like to know what the bytes are so i can reinterpret them myself, since right now if i'm decoding packed messages i don't even know what the unpacked bytes are
<kentonv>
yeah unfortunately there's not great tooling for that at the moment. :/
<kentonv>
it is weird that the server isn't responding to questionId 2
<_habnabit>
i guessi could submit a patch
<_habnabit>
even just a hex dump would be useful here
<kentonv>
I mean your best bet is to write a little program that actually reads the message and prints them however you like...
<_habnabit>
haha i know.....
<_habnabit>
but it seems like it would be generally useful in capnp decode?
<_habnabit>
does capnp encode have a way of encoding opaque pointers?
<kentonv>
it doesn't. capnp eval can do it as of like last week, by defining the value as a separate constant (hence giving it a type), then using that constant where an AnyPointer is desired.
<kentonv>
but at present there's no inline syntax for specifying an AnyPointer value (would require some way to specify the type)
<_habnabit>
ah ok
<kentonv>
anyway presumably you actually know what calls you're making?
<_habnabit>
i mean, i know what the source has in it
<kentonv>
so I'd guess the contents of the params and responses are not actually that interesting
<_habnabit>
sure. i just wanted to verify
<kentonv>
it's .evaluate() and then .read(), right?
<kentonv>
I'd stick a print statement in the implementation of .read() on the server and see if it's being called.
<kentonv>
if it is being called and is returning as expected, there's possibly a bug in the RPC implementation...
<kentonv>
well, if it isn't being called, there's still possibly a bug. :P
<kentonv>
is the server in Rust or is it the C++ sample code?
<kentonv>
oh right, you said you are writing a custom transport so it must be Rust on both ends
<kentonv>
theory: on the server side, when you read right up to the last byte, you're blocking waiting for more bytes even though you don't actually need them. So the last message isn't delivered. (I propose this because it's a bug I've had myself on a number of occasions.)
<_habnabit>
kentonv, thanks for the tips; i'm going to dig into it again now
nonaTure has quit [Ping timeout: 268 seconds]
<_habnabit>
kentonv, but when i was looking over the client/server data again, is the question 2 having sendResultsTo set to caller right? still trying to get a handle on what this all means
<_habnabit>
can you not name an interface's params/results in capnp decode? capnp decode: Calculator.Function.call$Params: no such type
yeehi has quit [Ping timeout: 248 seconds]
yeehi has joined #sandstorm
mnutt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mnutt has joined #sandstorm
yeehi has quit [Ping timeout: 246 seconds]
mnutt has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<kentonv>
_habnabit: yes, sendResultsTo caller is normal.
<kentonv>
_habnabit: Hmm, try Calculator.Function.CallParams. But that might not work either. It might not be possible to name them currently. :/
ecloud is now known as ecloud_wfh
demonimin has quit [Remote host closed the connection]
demonimin has joined #sandstorm
fonfon has joined #sandstorm
anthropy has joined #sandstorm
yeehi has joined #sandstorm
Telesight has joined #sandstorm
nonaTure has joined #sandstorm
Isla_de_Muerte has quit [Quit: See you in Isla de Muerte!]
jemc has joined #sandstorm
dwrensha has joined #sandstorm
afuentes has joined #sandstorm
demonimin has quit [Remote host closed the connection]
* dwrensha
reads scrollback
<dwrensha>
hi _habnabit
demonimin has joined #sandstorm
Lionel_Debroux_ has joined #sandstorm
Lionel_Debroux has quit [Ping timeout: 256 seconds]
newdev has joined #sandstorm
newdev has quit [Client Quit]
newdev876757 has joined #sandstorm
<newdev876757>
Hello, I'm considering Sandstorm for my home server. Is it possible to run apps in Sandstorm without publishing them in the App Market?
<dwrensha>
newdev876757: yep
<dwrensha>
newdev876757: you can SPK upload an APK file through the "Upload app..." button
<newdev876757>
dwrensha
<newdev876757>
newdev876757: thank you! that's great
newdev876757 has left #sandstorm [#sandstorm]
<dwrensha>
err, oops I did not mean to say "APK"
pdurbin has quit [Quit: WeeChat 0.4.2]
pdurbin has joined #sandstorm
mnutt has joined #sandstorm
fonfon has quit [Remote host closed the connection]
<_habnabit>
dwrensha, hi
_iwc has quit [K-Lined]
anthropy has quit [Read error: Connection reset by peer]
anthropy has joined #sandstorm
<_habnabit>
kentonv, yeah, still no: capnp decode: Calculator.Function.CallParams: no such type
nwf has quit [Ping timeout: 245 seconds]
<_habnabit>
dwrensha, i'm wondering if this would be easier to write on the tokio/futures branch
<dwrensha>
most of the test suite passes now
<dwrensha>
but it's using some ugly hacks behind the scenes
<_habnabit>
ah
<dwrensha>
to avoid such hacks, the interface might still need to undergo some changes
<_habnabit>
i'm used to having to change my code for unstable interfaces so i'm not too fussed
<_habnabit>
dwrensha, there's no reason that capnp-rpc-rust wouldn't be usable for single-shot rpc like this, right?
nwf has joined #sandstorm
<dwrensha>
_habnabit: what do you mean by "single-shot"?
<_habnabit>
dwrensha, trying to do capnp rpc over http: record all of the client messages, send that as a request, record all of the server messages, send that as the response
yeehi has quit [Ping timeout: 246 seconds]
<dwrensha>
hm. so multiple capnp messages per http payload
<dwrensha>
I'm not sure how you would decide when to stop "recording" and send off the HTTP request/response
<_habnabit>
dwrensha, the way i've been doing it so far is really bad: wait until the last message has been read out of the queue of recorded messages, make the next read return a Promise::never_done, wait for a full spin of the event loop, and then use all of the recorded messages that were written
<kentonv>
FWIW, in situations where I've needed to use HTTP, I generally prefer to pair it with only the capnp serialization layer, not RPC. Most of the advantages of capnp RPC would be lost anyway.
<_habnabit>
yeah..
<_habnabit>
my rpc use so far hasn't been bidi though
<_habnabit>
it would all fit tidily in an http paradigm, but i didn't want to have to expose the same interface in different ways
<dwrensha>
I wonder if you could somehow encode capnp RPC "connection" state in URLs, and then map capnp messages 1-to-1 onto HTTP payloads
<_habnabit>
ha
<dwrensha>
like, first you POST to /bootstrap, and that returns an export ID in a URL
<dwrensha>
that you then can POST a Call to
<_habnabit>
i'd been thinking about something like that, but i was also hoping to have a stateless API
<dwrensha>
seems like it might be pretty complicated
<_habnabit>
this looks kind of like what i would like to do
<_habnabit>
it's more involved but maps the semantics better
<_habnabit>
also less opaque! which is good
<kentonv>
it will take some work to build, though. The earlier parts of that document I expect to be working on in January but not sure if I'll be getting to the last section.
yeehi has joined #sandstorm
<_habnabit>
really i have to figure out what i actually want instead of just trying to generalize things for fun
<afuentes>
i guess it uses the file in the app. How should i modify this file?
<afuentes>
copy and modify... or modify the app? (that will be erased in the next update...)
<kentonv>
afuentes: unfortunately there isn't a clean way to do this. You could modify the app but as you note your changes will be blown away on next update. Also, the change would apply to all grains on your server (even ones owned by other users).
<kentonv>
possibly the app should be updated to copy config.php into the per-grain storage and symlink it from its current location
<kentonv>
so that it could be modified per-grain
<kentonv>
really, though, what we ideally prefer on Sandstorm is that apps not require users to edit config files ever. All config should be done through the UI...
<kentonv>
out of curiosity, what are you trying to change?
<kentonv>
ttrss seems to have a lot of config options in its UI so I'm surprised editing config.php is needed.
<kentonv>
oh I see, from the thread you linked
<kentonv>
I don't think the Sandstorm ttrss uses curl
<kentonv>
so I suspect this NO_CURL setting won't have any effect anyhow...
<kentonv>
afuentes, are you experiencing problems fetching some feed?
<afuentes>
kentonv, yes
<kentonv>
what sort of problems?
<afuentes>
I fetch it fine on my computer, but it says: Couldn't download the specified URL: false when i try to subscribe from tt-rss
anthropy has quit [Ping timeout: 268 seconds]
<afuentes>
I tried to download from the server with curl and saw that error
<afuentes>
in the logs doesnt seem to be any reference to the feed
<kentonv>
are you comfortable telling us the feed URL? Would be easier for me to look at it directly.
<kentonv>
also, do other feeds work from this same TTRSS instance?
<afuentes>
its been without updating for at least 2 months now on my ttrss instance and wanted to check out why
<afuentes>
yeah, others feed work
<afuentes>
other feeds*
<afuentes>
okay, the "show debug log" in the web interface shows a very small log. If I look at the log file in the grain it does show up
<XgF>
kentonv: WRT Your path parameters & pipelining annotation thing, IIRC the URL spec defines ; to delimit query string style parameters of URL components
<XgF>
So you could maybe do ".capnp/foo/getFoo;a=foo&b=bar/frob;y=baz"?
<kentonv>
XgF: I think I remember hearing recently that that part of the URL spec used to exist but was removed from more-recent specs because no one implemented it correctly.
<kentonv>
XgF: That said I suppose we can do whatever we want.
<XgF>
Modern versions of the spec basically treat the URL as an opaque string
<afuentes>
kentonv, it shows 503 errors in the log for that feed
<XgF>
I'd be tempted to just map the routing of methods to their name automatically by default?
<kentonv>
afuentes: If curl from your server doesn't work then my guess is that there is in fact a connectivity problem between your server and kodi.tv. Switching how TTRSS does the fetching probably won't help. :/
<kentonv>
afuentes: ugh, it looks like you are being CAPTCHA'd
<kentonv>
afuentes: probably by cloudflare
<XgF>
I'd be very tempted to save ".capnp/" for special 'meta actions' e.g. /foo/getBar;a=b&c=d/.capnp/asSturdyRef
<afuentes>
ive got the default fetch interval in tt-rss 4h. Its not like im ddosing anything
<kentonv>
yeah but cloudflare has all kinds of reasons for treating IPs as suspicious. :/
<kentonv>
Possibly you could contact kodi.tv and ask them to reduce their cloudflare security settings for the feed, since this probably breaks a lot of feed-reader services.
<kentonv>
and really there's no reason to apply ddos protection to a feed. It's just static content.
<kentonv>
(I mean, if they're going to respond with a captcha anyway)
<afuentes>
I see. Thanks kentonv!
<afuentes>
I will tell them!
anthropy has joined #sandstorm
Telesight has quit [Quit: Leaving.]
nonaTure has quit [Ping timeout: 258 seconds]
<TimMc>
cloudflare >:-(
nonaTure has joined #sandstorm
nonaTure has quit [Ping timeout: 265 seconds]
aldeka_limechat has quit [Remote host closed the connection]