<anherrera>
Hello everyone, wondering if I can maybe get some help on packaging my app. Ran vagrant-spk dev, everything seems to have come up, see the example app on my local instance, but get a forever-loading screen when I attempt to create a grain. I wasn't totally sure how to access any logs or anything to see what the issue might be. Thanks.
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<zarvox>
anherrera: you'll see the output of launcher.sh if you click the "Show Debug Log" button in the menu bar (the icon that looks like a monitor)
<zarvox>
that failure mode sounds like either 1) your app isn't binding port 8000 in launcher.sh, or 2) is crashing before it can get there
<zarvox>
another possible cause would be if your wildcard DNS isn't working, but I expect that to work if you're using vagrant-spk and http://local.sandstorm.io:6080
jadewang has quit [Remote host closed the connection]
<anherrera>
Cool will take a look! thanks for the quick response
jacksingleton has joined #sandstorm
jadewang has joined #sandstorm
NwS has quit [Ping timeout: 252 seconds]
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
rustyrazorblade has quit [Quit: rustyrazorblade]
<anherrera>
The only thing that jumps out at me is: Meteor requires Node v0.10.41 or later. followed by *** lost connection to grain (probably because it shut down) ***
<anherrera>
If I nodejs -v in the vagrant box, I get 0.10.29. Tried to upgrade to latest, doesn't seem to want to budge.
jadewang has quit [Ping timeout: 244 seconds]
aldeka_limechat has quit [Remote host closed the connection]
rustyrazorblade has joined #sandstorm
<zarvox>
hmmm, are you using the meteor vagrant-spk stack?
<anherrera>
Yes
<anherrera>
Doing a sanity check and just starting over w/ the very very very latest version of vagrant-spk.
rustyrazorblade has quit [Quit: rustyrazorblade]
<zarvox>
make sure your launcher script is calling a binary named "node", not one named "nodejs" - the meteor bundle we provide should have node 0.10.43
<reisi>
hi there! i'd really like to get tiddlywiki5 working on oasis as I'm a bit lazy to deploy it anywhere else; tiddlywiki5 needs only nodejs, npm and uses filesystem for persistence. is "diy" platform stack the correct choice to start with?
sydney_untangle has quit [Ping timeout: 264 seconds]
sydney_untangle has quit [Remote host closed the connection]
sydney_untangle has joined #sandstorm
<reisi>
has the "/var" directory been defined/assumed to be the storage for the grain?
<reisi>
oh it was mentioned in the launcher.sh comments, oki
n8a has quit [Ping timeout: 250 seconds]
jadewang has joined #sandstorm
n8a has joined #sandstorm
jadewang has quit [Ping timeout: 260 seconds]
n8a has quit [Ping timeout: 250 seconds]
n8a has joined #sandstorm
n8a has quit [Ping timeout: 250 seconds]
<reisi>
apparently tiddlywiki (this app I'm hoping to package) relies on the ability to parse the "Etag" response header, which does not seem to get through sandstorm http bridge
<reisi>
looking at the sources i can see some etag handling in src/sandstorm/sandstorm-http-bridge.c++ related to precondition handling but not really the part when etag response header is filtered out
<dwrensha>
etags should work
<dwrensha>
though it's apparently common for apps to use etags that are not surrounded by double quotes that there don't follow the spec
<reisi>
running the app locally (outside of vagrant-spk dev) the header looks like (looks like the requested url plus version 4 and some delimiter ":") Etag: "default/%24%3A%2FStoryList/4:"
<dwrensha>
hm. that looks like it should work
<dwrensha>
what happens when you run the app in sandstorm?
<reisi>
dwrensha: i missed this earlier: this is a PUT request by the javascript app (apparently a sanity check that those work). javascript was downloaded from the server/grain/app. difference in headers is that the PUT response is missing 'Content-Type: text/plain' and 'Etag: "..."' headers when running inside "vagrant-spk dev"
<reisi>
dwrensha: also locally the response headers has curious status line "204 OK", which might be getting transformed by sandstorm-http-bridge here into 204 no content with etag dropped
n8a has quit [Ping timeout: 250 seconds]
<reisi>
dwrensha: s/might be/is/ as "204 No Content" is the status line returned from app running inside "vagrant-spk dev"
<reisi>
using etags with bodyless responses sounds a bit strange. additionally the Content-Length is missing from the response
jadewang has quit [Ping timeout: 260 seconds]
<dwrensha>
so the non-sandstorm version returns a 204 with etags, and the sandstorm version just returns a 204, with no etags?
<reisi>
i'm wondering if this is something sandstorm should support, or should support etags specifically or should support all kinds of headers in NO_CONTENT case
<dwrensha>
it seems like WebSession ought to support this use case
<dwrensha>
I suppose it could return the Response.content variant, with statusCode = 204
<dwrensha>
and body.bytes empty
<dwrensha>
I think it would be not too hard to adjust sandstorm-http-bridge to make that work
<dwrensha>
basically, in the 204 case, check to see if any etags are present, and if so that use the Response.content variant
<reisi>
oki, i'll start by writing up a tiddlywiki issue on this (the app goes strangely defunct if this happens), then write an sandstorm issue about this
<dwrensha>
I'm currently writing up a Sandstorm issue
<reisi>
nevermind, it actually changes the way VagrantFile works so it'd either need more logic or a another vagrantfile
gelnior54 has joined #sandstorm
<afuentes>
i,i sandstorm has been on my radar for over a year... and finally had some time to give it a spin. The more I see, the more I like... Its refreshing when people have a clue of what they are doing
mnutt has joined #sandstorm
jadewang has joined #sandstorm
lukexj has quit [Ping timeout: 240 seconds]
jadewang has quit [Ping timeout: 260 seconds]
frigginglorious has joined #sandstorm
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
lukexj has joined #sandstorm
mnutt has joined #sandstorm
jacksingleton has joined #sandstorm
aldeka_limechat has joined #sandstorm
frigginglorious has quit [Quit: frigginglorious]
Lionel_Debroux has joined #sandstorm
[d__d] has quit [Ping timeout: 264 seconds]
frigginglorious has joined #sandstorm
jadewang has joined #sandstorm
rustyrazorblade has joined #sandstorm
jadewang has quit [Ping timeout: 240 seconds]
[d__d] has joined #sandstorm
frigginglorious has quit [Quit: frigginglorious]
asheesh_ is now known as asheesh
jadewang has joined #sandstorm
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
frigginglorious has joined #sandstorm
Telesight has joined #sandstorm
mnutt has joined #sandstorm
Isla_de_Muerte has joined #sandstorm
frigginglorious has quit [Quit: frigginglorious]
NwS has quit [Ping timeout: 244 seconds]
afuentes has quit [Ping timeout: 260 seconds]
xet7_ has quit [Read error: Connection reset by peer]
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
n8a has quit [Ping timeout: 250 seconds]
n8a has joined #sandstorm
mnutt has joined #sandstorm
jacksingleton has quit [Ping timeout: 240 seconds]
Lionel_Debroux_ has joined #sandstorm
Lionel_Debroux has quit [Ping timeout: 276 seconds]
rustyrazorblade has joined #sandstorm
<zarvox_>
dwrensha: your identity tests are great and you are great
zarvox_ is now known as zarvox
frankier has quit [Ping timeout: 272 seconds]
jemc has quit [Ping timeout: 250 seconds]
<dwrensha>
did they prevent you from introducing bugs?
jadewang has quit [Remote host closed the connection]
Telesight has quit [Quit: Leaving.]
prettyvanilla_ has joined #sandstorm
<zarvox>
Indeed!
bemasc has quit [*.net *.split]
prettyvanilla has quit [*.net *.split]
niek has quit [*.net *.split]
Triplefox has quit [*.net *.split]
preilly_ has quit [*.net *.split]
jemc has joined #sandstorm
<zarvox>
I'm curious - do you think it makes sense for calling the createAccountForIdentity method successfully to also log you in as that account? or do we still need to split it into two separate RPCs? (create account, log in to account)
<zarvox>
I'm not sure if there's Meteor accounts-related state that requires us to initiate the login on the client side, or what. I guess if log in can fail due to user limit, or require 2FA (someday), then maybe it makes sense that they're separably fallible.
<dwrensha>
having separate methods seems cleaner to me
<dwrensha>
but I forget a lot of the context there
<zarvox>
yeah, I just hate having a bunch of roundtrips on the critical path for login/pageload. I guess it'd only save one roundtrip, and only for first-time users.
mnutt has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 252 seconds]
afuentes has joined #sandstorm
afuentes has quit [Remote host closed the connection]
jadewang has joined #sandstorm
rustyrazorblade has quit [Quit: rustyrazorblade]
Isla_de_Muerte has quit [Quit: See you in Isla de Muerte!]