<tdfischer_>
paulproteus: you still bumming around osbridge? I have some sandstorm progress and questions.
<tdfischer_>
oh patrickod is here too
<patrickod>
hallo
<zarvox>
XgF: mmmm, perhaps. Maybe then you'd want each bug to be a separate document/grain. But maybe then you're moving complexity from the database into the interconnect, and the number of bugs might be unmanageably large.
<zarvox>
I imagine individual bug threads generally don't need to support thousands of concurrent workers. But organizing/searching them might get messy.
<paulproteus>
tdfischer_: yes
<paulproteus>
I'm in the speaker lounge
<tdfischer_>
ah cool
<paulproteus>
Maybe I should go to hacker lounge, hmm
<tdfischer_>
for those who want to see a really awful package that includes a pile of broken files that shouldn't be included in it :)
<kentonv>
honestly if you are comfortable using raw spk then there's no problem with doing that.
<kentonv>
vagrant-spk is mostly about supporting non-Linux users and avoiding pitfalls
<dwrensha>
"ImportError: cannot import name urllib_parse"
<kentonv>
yeah I'm getting that too
<tdfischer_>
huh
<tdfischer_>
weird
posix4e has left #sandstorm ["WeeChat 0.4.2"]
<kentonv>
did you try installing from the spk or did you only test in dev mode? Sometimes there are weird differences, sadly.
<tdfischer_>
only dev mode
<kentonv>
one common reason for differences is if there are files that get stat()ed only to test if they exist, and then behavior is triggered on that. We don't consider a stat() to mean the file is used, since often it just means that the code was scanning a directory.
<tdfischer_>
right
<tdfischer_>
hmm
<kentonv>
but we try to work around common cases of this, so I'd be curious what is happening here so we can fix it
<tdfischer_>
sure
<tdfischer_>
I'll look into it more
<tdfischer_>
I might've just undid something in my launch.sh before packaging :E
ArcTanSusan has joined #sandstorm
ArcTanSusan has quit [Client Quit]
husanu5 has joined #sandstorm
ArcTanSusan has joined #sandstorm
jadewang has joined #sandstorm
husanu5 has quit [Remote host closed the connection]
jadewang has quit [Ping timeout: 246 seconds]
jadewang has joined #sandstorm
jadewang has quit [Remote host closed the connection]
<paulproteus>
But... how is it supposed to do that?
<paulproteus>
(Is Sandstorm supposed to intercept these redirects and mutate them?)
<XgF>
paulproteus: One option would be to use a domain-relative redirect
<kentonv>
XgF: Everything on the demo server gets deleted within an hour, and doesn't share storage with any non-demo server. I think it has like 100GB available. So don't worry too much.
<XgF>
i.e. Location: /foo/bar
<dwrensha>
ideal case: it's easy to switch the app over to relative url
<kentonv>
XgF: Eventually (on Blackrock / Oasis) we'll have per-user storage quota enforcement
<paulproteus>
I'd prefer if sandstorm-http-bridge were to be configured to mutate the redirect's Location header, fwiw.
<XgF>
(Which technically violates HTTP1 IIRC but what the spec says and what everyone implements have never been remotely connected)
<XgF>
paulproteus: There are lots of other URLs to handle...
<XgF>
If its generating absolute URLs like that for redirects, it probably will elsewhere...
<paulproteus>
Oh fascinating, yeah.
<XgF>
kentonv: Good. Should probably still stop me from consuming allegedly 4GB of RAM (thats how much Gimp clained)
<kentonv>
paulproteus: Either the app needs to generate its absolute URLs based on the "Host" header, or it needs to generate relative URLs.
<dwrensha>
another option: read the session URL from X-Sandstorm-Base-Path
<dwrensha>
or Host? maybe I'm forgetting how these things work
<kentonv>
XgF: Yes, we'll have RAM quotas as well. Demo server has like 113GB, though. :)
<kentonv>
XgF: demo server is provisioned to not go down when it's on the front of hacker news and 100 people are using it. :)
<paulproteus>
++ looks like I can maybe get this to work with HTTP_HOST
<XgF>
kentonv: What about if I open a 150,000x100,000 32bytes-per-pixel image in The Gimp? :P
<kentonv>
paulproteus: also check X-Forwarded-Proto (I think) for HTTP vs. HTTPS, or use X-Sandstorm-Base-Path which includes both proto and host in one.
<XgF>
(Actually I suspect that Linux will OOMkill it, because thats 1.1TB of RAM :P)
<kentonv>
XgF: Yeah presumably your process will be the first to go when the OOM killer kicks in, so meh.
<XgF>
It did :p
<XgF>
Its actually kinda difficult to consume oodles of disk space with The Gimp because the keyboard doesn't work so I can only make 3 .bmp files :p
<kentonv>
btw that spk was built by Alexander Larsson
<kentonv>
he just randomly sent it to me
<XgF>
Also, bug report: The Gimp doesn't respect the HiDPI nature of my monitor (:P)
yozlet has joined #sandstorm
<paulproteus>
Howdy yozlet
<yozlet>
ULLO LOVELY SANDPEOPLE
<paulproteus>
Also what kentonv is there a GIMP SPK?!
<kentonv>
it takes like 10-15 seconds to start up for me, in Chrome
<paulproteus>
kentonv: did it come with an offer for complete and corresponding source code?
<paulproteus>
omg it worked.
<zarvox>
paulproteus: sorry, wasn't looking at IRC. PHP app. Absolute redirects. Ideally the PHP app would use the Host: header from sandstorm-http-bridge as the hostname. Are we failing to pass on the Host: header correctly in nginx or something?
<paulproteus>
Host header, rather than X-Sandstorm-Base-Path?
<paulproteus>
That's my question I guess.
<zarvox>
X-Sandstorm-Base-Path is sandstorm-specific; Host is more widely supported and should work out-of-the-box
<zarvox>
at least Host: + X-Forwarded-Proto
<kentonv>
Host + X-Forwarded-Proto is something you could potentially upstream
<kentonv>
so I guess that's the argument for that over X-Sandstorm-Base-Path
<paulproteus>
Today I prefer X-Sandstorm-Base-Path and figured out what I needed!
<zarvox>
kk
<paulproteus>
I forgot HTTP_ in HTTP_X_SANDSTORM_BASE_PATH
<paulproteus>
go go gadget PHP
<dwrensha>
I'm sad that we have `UiView.getViewInfo()` method rather than a `Package.Manifest.viewInfo` field.
<dwrensha>
I suppose the reasoning is that having it as a method makes more sense if we ever want to implement sub-UiViews
<dwrensha>
?
yozlet has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<XgF>
dwrensha: Id guess so
<zarvox>
Is there viewInfo that isn't under bridgeConfig, rather than manifest?
<dwrensha>
viewInfo is under bridgeConfig, so that sandstorm-http-bridge can implement getViewInfo()
<zarvox>
and we'd rather have it in the manifest, and have sandstorm-http-bridge read the manifest instead?
decipherstatic has joined #sandstorm
<dwrensha>
hm. Good point -- I suppose that sandstorm-http-bridge needs the data in any case.
<kentonv>
dwrensha: yeah the problem with the manifest is that it's a singleton.
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
<paulproteus>
Just demo'd GIMP on Sandstorm to bkuhn fwiw
<zarvox>
nice :)
<zarvox>
I'm curious to know what changes were required, beyond using the HTML5 backend for GTK+
<zarvox>
I guess I could unpack the spk and see for myself what it looks like on disk
jadewang has quit [Remote host closed the connection]
<kentonv>
presumably very little, I don't think alex spent any significant time on it
<kentonv>
I mean, he claimed to have just played with it today
<kentonv>
and that includes installing Sandstorm and learning how spk works. :)
<dwrensha>
kentonv: ViewInfo is allowed to change when a grain moves from one package to another (aka package upgrade). Is it allowed to change at any other time? What if the UiView is not associated with a package, as would be the case for "sub-UiViews"?
<kentonv>
dwrensha: sub-UiViews are still associated with a grain and therefore a package, they just aren't the main view. So I think the same rules apply.
<paulproteus>
This GIMP thing is cool but I still need some PTYs
<kentonv>
dwrensha: I am not sure what the rules should be about when the info can change. It'd be good to enumerate exactly what optimizations we can implement based on various rules, in order to choose something appropriate.
<kentonv>
dwrensha: Ideally, we'd support UiViews that actually aren't associated with any grain, because they are external Cap'n Proto capabilities.
sasattack has joined #sandstorm
yozlet has joined #sandstorm
sasattack has quit [Ping timeout: 246 seconds]
wat_ has joined #sandstorm
ArcTanSusan has joined #sandstorm
jadewang has joined #sandstorm
wat has quit [Ping timeout: 250 seconds]
jadewang has quit [Read error: No route to host]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 252 seconds]
jadewang has joined #sandstorm
yozlet has quit [Read error: Connection reset by peer]
yozlet has joined #sandstorm
sasattack has joined #sandstorm
NwS has quit [Quit: See you in Isla de Muerte!]
ArcTanSusan has quit [Quit: ArcTanSusan]
erikoeurch has quit [Ping timeout: 256 seconds]
yozlet has quit [Read error: Connection reset by peer]
yozlet has joined #sandstorm
yozlet has quit [Read error: Connection reset by peer]
<patrickod>
when you use GitHub authentication w/ sandstorm (as I have done for my admin user) is it possible to stop guest access?
jadewang has quit [Remote host closed the connection]
<patrickod>
or is it the intention that anyone with your *.sandcats.io URL would then be able to sign up for your particular instance of sandstorm?
<tdfischer_>
my understanding is that you can just not give those sorts of people permissions
<patrickod>
ok. so they'll create "guest" accounts w/o perms
<tdfischer_>
maybe? I'm not entirely sure tbh :D
<tdfischer_>
I'm just pooping out frankenpackages of my stuff
yozlet has joined #sandstorm
ArcTanSusan has joined #sandstorm
<zarvox>
At present, it is designed such that anyone can sign in, but signing in does not automatically allow you to create new grains.