<paulproteus>
But I think I do not understand enough how to use it. I imagine jparyani or dwrensha or kentonv do.
j^_ has joined #sandstorm
aldeka_ has joined #sandstorm
<paulproteus>
I can't find any evidence that we actually use that 'path' property. So I think you might have to serve a redirect on / yourself.
<paulproteus>
If you want, I can be the one to email sandstorm-dev.
<paulproteus>
afk a bit, back in ~3 min
jjb has joined #sandstorm
j^ has quit [*.net *.split]
augustl has quit [*.net *.split]
hunterm has quit [*.net *.split]
ripdog has quit [*.net *.split]
oao has quit [*.net *.split]
aldeka has quit [*.net *.split]
phildini has quit [*.net *.split]
hunterm_ is now known as hunterm
ripdog has joined #sandstorm
augustl has joined #sandstorm
<paulproteus>
ckocagil: I'm going to bed in a sec, will check in shortly & then sleep in ~5 min.
<ckocagil>
paulproteus: thanks for the pointer, I can do the rest of the detective work :-)
<ckocagil>
g'night!
<paulproteus>
Great! Night!
larjona has quit [Quit: Konversation terminated!]
mnutt_ has joined #sandstorm
mnutt_ has quit [Ping timeout: 264 seconds]
xet7 has quit [Quit: Leaving]
decipherstatic has quit [Remote host closed the connection]
larjona has joined #sandstorm
larjona has quit [Quit: Konversation terminated!]
Aric has joined #sandstorm
achernya has quit [Ping timeout: 244 seconds]
achernya has joined #sandstorm
NOTevil has joined #sandstorm
achernya has quit [Read error: Connection reset by peer]
achernya_ has joined #sandstorm
NOTevil has quit [Read error: Connection reset by peer]
NOTevil has joined #sandstorm
rustyrazorblade has joined #sandstorm
zeroish has joined #sandstorm
Aric has quit [Quit: Connection closed for inactivity]
<kentonv>
ckocagil, paulproteus: The user can specify a path in the URL after the grain ID. But if the app itself wants to specify a different default path, you'll need to use a redirect.
<ckocagil>
kentonv: redirect is what I ended up doing
<ckocagil>
kentonv: on another topic, I had to install a local dns server to handle "*.hostname" subdomains. maybe it could be bundled in sandstorm?
<ckocagil>
I didn't use sandcats
<kentonv>
ckocagil: well... if your intent is only to support requests from the local machine, you can use *.localhost. If the intent is to allow other machines to connect, then there's a lot more to it than just installing and configuring the DNS server, since you have to configure the domain to use it, etc.
<ckocagil>
kentonv: *.localhost works out of the box?
<kentonv>
yeah
<kentonv>
this is somewhat recent but I'm told it works basically everywhere now
<ckocagil>
ah, how does that work even? I thought /etc/hosts didn't support wildcards
<kentonv>
it's implemented by the browser
<ckocagil>
oh.
<ckocagil>
hacks upon hacks
<kentonv>
well, it might also be implemented by the DNS library
<kentonv>
but it's specified as never making a network request
<kentonv>
defining localhost in /etc/hosts is apparently obsolete now
<kentonv>
or so I heard from people who should know. I haven't investigated a whole lot.
<ckocagil>
doesn't seem to work with firefox
<kentonv>
(we also have *.local.sandstorm.io which is a hack we built before *.localhost worked everywhere. We should switch over to *.localhost, though.)
<kentonv>
hmm, that's odd
<kentonv>
what OS is running your browser?
<ckocagil>
ubuntu 15.04
<ckocagil>
my firefox might be too old though
<kentonv>
on my Debian Testing box I can ping foo.localhost
<kentonv>
so it's definitely the DNS library implementing it
<ckocagil>
doesn't resolve here. I guess the dns library is too old.
<kentonv>
that's too bad. I guess we'd better stick with *.local.sandstorm.io as our default for dev servers for now.
<kentonv>
(you can use that BTW -- it's a wildcard that maps to 127.0.0.1)
<ckocagil>
yeah I know, that's what the dev environment uses
<ckocagil>
kentonv: another thing; I suspect the shared folders feature of vagrant/virtualbox is too slow. would it be a good idea to tar & untar the app data to /opt/app instead of mounting?
<ckocagil>
this app I'm working on has a startup time of 5 minutes, if not more.
<kentonv>
what tech stack does the app use?
<ckocagil>
kentonv: node.js + redis
<ckocagil>
when I pack and try it with an actual sandstorm installation it takes like 10 seconds
<kentonv>
spk dev slows down file I/O a lot even without a VM
<kentonv>
so I'm not sure how much faster it will get with the shared folder layer removed
<kentonv>
the problem is FUSE is slow.
<ckocagil>
where is FUSE used?
<kentonv>
spk dev uses a FUSE layer to trace what files are being accessed.
<kentonv>
you can try passing -c to spk dev (hopefully vagrant-spk dev passes it through) to enable aggressive caching, which may improve performance but at the expense of definitely requiring killing spk dev and starting over any time you change something.
larjona has joined #sandstorm
bb010g has joined #sandstorm
<paulproteus>
ckocagil: Ouch re: startup time of 5 min
<paulproteus>
There's no reason that spk dev _needs_ to re-run npm install, fwiw, which also hurts, presumably.
<paulproteus>
Though I guess if you did this yourself, maybe your launcher.sh doesn't npm install?
<ckocagil>
paulproteus: it doesn't run npm install
<paulproteus>
Sad
<paulproteus>
I love Makefiles and I love running tests.
<paulproteus>
The sandcats code gives me the chance to do both.
<maurer>
paulproteus: You... love makefiles?
<paulproteus>
Yes! What's not to love! I might be losing trust points here.
<paulproteus>
OK there are some things not to love.
<paulproteus>
But I love that it's dependency-based and that writing a simple Makefile is pretty simple.
<maurer>
paulproteus: My issue with makefiles is that as soon as you scale above a trivial project, you stop having a clean rule based system and start having something that looks more like a bunch of shell scripts
<paulproteus>
Yeah, that's a tragedy.
<maurer>
Also, most Makefiles I find in the wild are racy
<maurer>
but that's not a technical problem, it's a language design problem
xet7_ has quit [Ping timeout: 256 seconds]
<paulproteus>
I am going to use some of this day to set up more aggressive email filtering.
larjona has quit [Ping timeout: 250 seconds]
<gwillen>
paulproteus: do you know the cause of the 'no such grain for ID' messages
<gwillen>
is that something that's fixed in a appropriately-recent version
<gwillen>
it seems to happen after some kind of timeout
<paulproteus>
gwillen: Yeah, Jason Paryani was working on it over the past ~2 weeks after introducing it ~3 weeks ago.
<paulproteus>
It doesn't do the kentonv:sandstorm-accounts thing yet, but luckily this app doesn't seem to have a notion of accounts (?).
<neynah>
presumably
<paulproteus>
afk a bit!
NOTevil has quit [Quit: reboot!]
eternaleye has joined #sandstorm
<gwillen>
paulproteus: awesome, thanks
<gwillen>
glad it's not just us
<paulproteus>
Yeah.
<paulproteus>
BTW is there a good way we could (have) communicate(d) about issues like that?
<paulproteus>
Maybe a Tweet would be good?
<paulproteus>
Maybe an email to sandstorm-dev saying it's a known issue you might run into? Maybe "just" file a bug against ourselves, and hope people see it?
bb010g has quit [Quit: Connection closed for inactivity]
<neynah>
:D
rustyrazorblade has quit [Quit: rustyrazorblade]
<gwillen>
paulproteus: hmm that's a good question
<gwillen>
I'm not sure where you could put that where I might see it... I don't read sandstorm-dev, the bug is good because at least you can point people to it (an active pullreq is just as good but the bug is good if you're not fixing it already)
<gwillen>
probably a good habit to have a bug along with the pullreq anyway, just for completeness
<gwillen>
I probably wouldn't see the tweet
<gwillen>
if it's a major enough issue to be worth it, the only place I'd see it would be a G+ post, but I'm special that way because I actually use G+ ;-)
<gwillen>
more people would see the tweet
<gwillen>
paulproteus: honestly the only reason you're hearing from me is that I know the team, usually with stuff like this I just grumble to myself and work around it. Not sure what lesson to take from that.
<gwillen>
(there's another one I get periodically, and I wish I remembered what exactly it said, but it was a different sort of session loss issue that occasionally happens with long-running tinyrss sessions.)
<gwillen>
(I am also having an issue right now with an Etherpad which contains a sentence in which the cursor will not hold still, and I wish I was making that up)
<gwillen>
(I doubt that's your bug though)
<ckocagil>
anyone willing to take a look at my new port real quick?
aldeka_ has quit [Quit: No Ping reply in 180 seconds.]
aldeka has joined #sandstorm
rustyrazorblade has joined #sandstorm
mnutt_ has joined #sandstorm
<mnutt_>
I’m having trouble getting vagrant-spk working with current sandstorm dev build (0.125) and vagrant-spk master. I see “SANDSTORM SUPERVISOR: Starting up grain.” in the grainlog, but nothing else, even if I change my Command argv to “echo Starting App”. Is there somewhere else I can look for errors?
<mnutt_>
pstree shows spk has a child that is a defunct sandstorm process, which has a child that is `sandstorm start`, and nothing else
<mnutt_>
so the grain has started, but it either hasn’t started any processes or they have died without leaving any output