<isd>
Yeah, so that's clearly intended, just the docs didn't get updated.
<dwrensha>
isd: I'll submit a PR to update the docs (unless you want to do it)
<isd>
dwrensha: I'd be happy to do it. Probably won't happen until tomorrow.
<dwrensha>
I'll just do it right now
<isd>
fair enough.
<isd>
gotta go. later.
isd has quit [Remote host closed the connection]
Aurelius_Home has joined #sandstorm
simonv3_ has joined #sandstorm
decause_ has joined #sandstorm
<asheesh>
Oh my goodness, I am *so* going to try this Davros SPK.
eternaleye has quit [Ping timeout: 258 seconds]
simonv3 has quit [Ping timeout: 258 seconds]
Guest9791 has quit [Ping timeout: 258 seconds]
fkautz has quit [Ping timeout: 258 seconds]
ckocagil has quit [Ping timeout: 258 seconds]
Aurelius_Home2 has quit [Ping timeout: 258 seconds]
decause has quit [Ping timeout: 258 seconds]
Zertrin has quit [Ping timeout: 258 seconds]
hunterm__ has quit [Ping timeout: 258 seconds]
Zertrin has joined #sandstorm
ckocagil_ has joined #sandstorm
eternaleye has joined #sandstorm
simonv3_ is now known as simonv3
preilly has joined #sandstorm
preilly is now known as Guest53868
<asheesh>
Whoa it totally works.
<asheesh>
docx & doc
hunterm__ has joined #sandstorm
fkautz has joined #sandstorm
dwrensha has quit [Ping timeout: 250 seconds]
dwrensha has joined #sandstorm
<digitalcircuit>
Drat, was going to ask mnutt_ a question about Davros (their connection quit)...
<digitalcircuit>
Seems as if Sandstorm supervisor kills Davros while OwnCloud Client is uploading large files.
<digitalcircuit>
(Similar to the issue with Groovebasin getting killed, except that's streaming/download, not upload)
<digitalcircuit>
I -think- kentonv mentioned something about extending the supervisor to track if there's connections with significant activity (i.e. a minimum Kb/s), and not killing the grain, and/or something with the background API?
* digitalcircuit
will remember this for later and/or file a bug report for mnutt_ since their connection quit :)
<kentonv>
digitalcircuit: you should file the bug against sandstorm, not davros
<kentonv>
this is something davros currently cannot control
<digitalcircuit>
kentonv: Alright, I'll see what I can write up. Thanks for the pointer!
ThePurgingPanda_ has quit [Ping timeout: 264 seconds]
ThePurgingPanda_ has joined #sandstorm
ThePurgingPanda has quit [Ping timeout: 276 seconds]
ThePurgingPanda has joined #sandstorm
ThePurgingPanda_ has quit [Ping timeout: 265 seconds]
afuentes has joined #sandstorm
_whitelogger has joined #sandstorm
<mrdomino>
michael fogleman observes: "we have more sandstorm instances per capita around here than probably most places in the world"
<mrdomino>
(he just set up his own instance)
ThePurgingPanda_ has joined #sandstorm
ThePurgingPanda has quit [Ping timeout: 244 seconds]
mnutt_ has joined #sandstorm
<asheesh>
mrdomino: Hah :)
<asheesh>
digitalcircuit: Wow! That bug report is worth its weight in gold. Or in bitcoin if that's your thing. :D
Lionel_Debroux has quit [Ping timeout: 276 seconds]
ThePurgingPanda has joined #sandstorm
ThePurgingPanda_ has quit [Ping timeout: 244 seconds]
<mrdomino>
async-io question: if i return a Promise<void> that's a result of a write() on an AsyncOutputStream in the local scope, do i need to attach the stream to the promise?
<mrdomino>
i suppose yes since it's an Own<T>
<kentonv>
you need to make sure the stream outlives the promise. One way is to attach it.
aeviator has joined #sandstorm
<mrdomino>
then another more general question: are multiple attach calls at different stages in a promise meaningful? i.e. do earlier attachments go out of scope sooner or does the whole thing carry on until the most dependent promise?
<kentonv>
say you have "foo.then(f).attach(obj).then(g)" -- the object "obj" will go out-of-scope between when f() runs and when g() runs
<mrdomino>
ok, great, thanks
<mrdomino>
really satisfying to be finally getting around to working with this stuff
Lionel_Debroux has joined #sandstorm
frankier has quit [Quit: Leaving]
dlitz has quit [Remote host closed the connection]
dlitz has joined #sandstorm
aeviator has quit [Ping timeout: 240 seconds]
aeviator has joined #sandstorm
afuentes has quit [Ping timeout: 244 seconds]
mnutt_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mnutt_ has joined #sandstorm
geemili has joined #sandstorm
<geemili>
Hello!
<geemili>
Has anybody else been able to connect to Davros from the ownCloud android app?
<geemili>
Because whenever I try, I get an "Unknown Error"
<geemili>
I don't have ssl set up. Could that be the issue?
<asheesh>
I think it's important that we figure out what's going on so we can fix it. We're not there yet, though.
<geemili>
Hmm.
<geemili>
The cirrus app was able to connect
<geemili>
But I can't see any files
<asheesh>
Yeah. I'd have to dig into it to understand why.
<mnutt_>
asheesh: how is the cirrus app, compared to owncloud official?
<asheesh>
BTW is there a chance you're in Rochester, NY? I ask because that's what some service says about your IP address; if so, then I'm here too, and I would totally buy you a drink for your troubles. : )
<geemili>
I actually connected before, was able to upload a file and see that, but nothing that was there previously
<asheesh>
I found that the Cirrus app is great, fwiw.
<mnutt_>
geemili: maybe there is something in the sandstorm grain log that would point to the issue?
<asheesh>
ohai mnutt_
<asheesh>
I didn't see anything in the grain log mnutt_ but I can check my own, too.
<asheesh>
I suspect it has something to do with headers we're eating or something like that, which don't get logged at the moment.
<mnutt_>
issues once you're connected are much easier to address than connection issues, unfortunately
<geemili>
I can upload stuff
<mnutt_>
that's really good, it probably means it's likely just a header issue we're missing
<geemili>
Is it something that I could look into
<geemili>
?
<asheesh>
If you can report the HTTP headers that your server receives from the app, then that would be a big help.
<asheesh>
Doubly so if you can compare that against Cirrus.
<asheesh>
A good place to report that information would be a new bug filed against Davros.
<geemili>
Would I need a separate program to capture the htt
<geemili>
ohh
<asheesh>
I should probably add a note to the Sandstorm docs with that, so that other people can find it : )
<asheesh>
Let me know if that does what you need; if not, then I can try to provide more info!
xet7_ has quit [Read error: Connection reset by peer]
<geemili>
Okay, I got some of the headers
<geemili>
Is it okay if I just post the raw files or should I edit them to remove some data?
<asheesh>
If you're OK with people possibly getting access to that grain via the headers, then it's 100% OK.
<asheesh>
If you can revoke any access tokens you've created, then it's safe to post it as-is.
<geemili>
Okay
<geemili>
However, just looking at the headers myself, it looks like Cirrus is requesting the data in JSON
<geemili>
But Davros is sending back "text/xml"
<asheesh>
That is kinda weird. I wonder if that's related to the problem.
<asheesh>
I wonder if you can test against brand-name owncloud, geemili.
<asheesh>
If not, that's fine; someone else can, based on having the headers that you would provide.
<geemili>
asheesh: brand-name server or brand-name client?
<asheesh>
server, I meant
<geemili>
Trying it out
isd has joined #sandstorm
<ocdtrekkie__>
mnutt_: Re: Mattermost, I saw it and mentionned it here I think before Rocket.Chat became big here. I think a key point right now is that Rocket.Chat supports Sandstorm directly, and someone would have to maintain a Mattermost port, currently. A ton of neat integrations and plugins have been written for it though: https://www.mattermost.org/community-applications/
<mnutt_>
those bots become really interesting once powerbox lands and can start connecting grains
<ocdtrekkie__>
Mhmm.
<ocdtrekkie__>
The idea that they already have code for connecting GitLab and Mattermost is pretty cool, though I'm curious especially how difficult it would be to rework that to work through the Powerbox.
Telesight has quit [Quit: Leaving.]
mnutt_ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mnutt_ has joined #sandstorm
ThePurgingPanda_ has joined #sandstorm
ThePurgingPanda has quit [Ping timeout: 276 seconds]
n8a has quit [Ping timeout: 250 seconds]
n8a has joined #sandstorm
DanC_ has quit [Ping timeout: 252 seconds]
DanC_ has joined #sandstorm
dwrensha has quit [Quit: ChatZilla 0.9.92 [Firefox 48.0.1/20160817112116]]
<geemili>
Getting my machine ready for nodejs development is taking a lot longer than I expected
NhanH has joined #sandstorm
cstrahan has joined #sandstorm
lukexj has quit [Quit: Leaving]
abnd has joined #sandstorm
<abnd>
Hello
<abnd>
I'm trying to get a barebones flask app running with the developer VM
<abnd>
And all I can see is an infinitely loading grain, I used the uwsgi stack
<asheesh>
Hi abnd
<abnd>
What could I be doing wrong?
<asheesh>
abnd: Do you have the "application = app" line?
<asheesh>
You'll probably need that, since the uwsgi stack looks for the WSGI application to be called application, but by default Flask calls it app, iirc.
<asheesh>
And hi! Thanks for stopping by!
<abnd>
No but I have "--callable app" in my uwsgi config
<asheesh>
Oh, interesting, that _should_ do the trick.