00:29 <bb010g> Guessing you need both 6080 (Sandstorm) and 6081 (MongoDB) opened for proper functionality?

00:32 <bb010g> I've got both open, but the http://bb010g.sandcats.io:6080/admin/settings/$ADMIN_TOKEN won't load. FX 39.0 on Arch Linux. Server on Azure instance with Ubuntu 14.04 LTS.

00:38 <bb010g> (Well, it loads, but it's stuck on "Loading...")

00:46 <bb010g> http://bb010g.sandcats.io:6080/ seems to work fine. I tried to open the admin auth page in surf (Webkit based), and I get the same result "Loading...".

00:48 <bb010g> Chrome too. So it's not the browser.

01:09 <bb010g> Wrapped a sudo around it, and it works now.

01:48 <bb010g> How do you delete an account? I'm not seeing anything from the admin panel.

02:01 <bb010g> Or rather, can you change the message? I tried poking around the MongoDB shell, but I couldn't find anything.

02:45 <bb010g> Is there even a way to change your Name?

02:53 <bb010g> It seems odd that there's no real account management capabilities.

04:10 <bb010g> I found and manually updated names in `sandstorm mongo`, but someone shouldn't have to do that to fix a name.

07:18 <paulproteus> bb010g: Thanks for poking around, and yeah, user management is going to be important to get right, and we know it's missing that. I'm going to bed, but hope you'll continue to stick around here.

14:40 <jinnko> hey folks. is there a way to get the tt-rss subscribe link to work from firefox? if figured out how to use the webkey to the app via curl with the auth header to submit new links for subscription, but can't think of how that could applied to the subscribe button in firefox. any ideas?

14:56 <jinnko> i've found a way to do it, but suspect it won't persist to work. inspecting the "firefox integration" button i found the window.navigator.registerContentHandler() code. editing that inline to replace the http://localhost:32533/ with the URL in the browser to access my tt-rss instance didn't work, but then pasting that line of JS into the console did the job

19:44 <erikoeurch> hello sandstormers

19:44 <erikoeurch> nice to see the storage used / storage quota in Sandstorm now

19:45 <erikoeurch> It would also be useful to see how much storage every grain is using

19:47 <erikoeurch> and what type a certain grain is, like when viewing My Files it's sometimes hard to know what exactly a certain grain is, because you can only see the "Title" and "Last Used". Would be super to have two additional rows in the table: "Size" and "App" or something along those lines

19:48 <zarvox> I agree!

19:49 <zarvox> A thing I would like to see would be apps providing some sort of app icon, and then the shell additionally showing that icon in the UI anywhere it'd show a grain's title.

19:50 <zarvox> Also I suspect that per-grain size information is mostly a matter of plumbing the information up to the UI; I'm pretty sure we track the per-grain storage used.

19:51 <erikoeurch> zarvox: yes, an app icon would definitely be helpful too (it even looks like they've reserved space for that in the sidebar... :) )

19:53 <erikoeurch> zarvox, the source code for Oasis is not available, right?

19:53 <zarvox> erikoeurch: That's correct.

19:53 <erikoeurch> publicly, I mean

19:53 <erikoeurch> ah, ok

19:55 <erikoeurch> But what about the basic UI, is that part of Sandstorm?

19:55 <dwrensha> erikoeurch: the frontend code is all open source

19:55 <dwrensha> Oasis has a different implementation of the Backend interface: https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/backend.capnp

19:55 <erikoeurch> oh, well that's what I was interested in really

19:56 <erikoeurch> but where is the frontend code? I was looking around in the repos and didn't see anything looking like it

19:56 <zarvox> under shell/

19:56 <zarvox> in sandstorm-io/sandstorm

19:57 <zarvox> https://github.com/sandstorm-io/sandstorm/tree/master/shell

19:57 <erikoeurch> got it, thanks zarvox

19:57 <erikoeurch> I didn't think of shell like that when I first saw it...

20:05 <zarvox> It looks like at the moment we don't expose the size of individual grains from the backend, so we might have to do a bit more work for that than I originally guessed

20:06 <erikoeurch> well, it's not a big deal but it's probably something that will be needed when people start reaching their quotas

20:07 <erikoeurch> hehe, excessively over quota === quota * 1.2; seems like a fairly small difference :D

20:07 <zarvox> Makes sense, and I agree that it'd be useful for people to be able to figure out which apps/grains are costing them the most.

20:08 <zarvox> do you normally have >20% soft-cap on your storage quota?

20:09 <erikoeurch> what about the app name? I see that appId is available in each grain doc, but perhaps making a mongodb call for every grain in a user's list is a bit excessive. I've started with Meteor development recently I stumbled on that kind of issue a few times, ended up denormalizing a lot of data...

20:11 <zarvox> Yeah, mongo generally encourages denormalization of data, since you can't do joins efficiently

20:11 <erikoeurch> zarvox, well frankly I don't know what the normal is regarding soft-caps, just thought the wording was a bit funny, but on further thought excessive should be just that...

20:11 <zarvox> my first reaction to app name is that it seems like it could wind up consuming a lot of screen space

20:12 <zarvox> I'd be totally for making hovertext/alttext on the icon be the app name.

20:13 <erikoeurch> true, if the app icon was showing in the grain list that would probably be enough to clearly grasp what each grain is

20:14 <zarvox> yeah, and you could make the icon link to that app's view on the left, if you wanted to look at just that app's grains

20:15 <erikoeurch> perhaps that would a slight bit of confusion, if clicking anywhere else on the row opens the grain?

20:18 <erikoeurch> If I keep the shell home screen open, does it eat into my memory-time quota?

20:18 <zarvox> Good point, that does seem like it could risk confusion. User study required. :)

20:19 <zarvox> I don't believe so. My understanding is that if you navigate away from a grain, we close the iframe, which lets the autoshutdown machinery kill it after a brief while.

20:19 <erikoeurch> yes, the effects of small UI changes are often tricky to predict

20:20 <erikoeurch> great

20:21 <erikoeurch> it's kind of convenient to just keep the grain open instead of having to wait 20 seconds for it to spin up every time, but keeping the home screen open is a better alternative I guess, to save resources

20:21 <zarvox> 20 seconds for a grain to spin up? Yikes. Which app is that?

20:22 <zarvox> The ideal solution there is "grain startup shouldn't be so slow" and we've got some ideas for speeding things up there

20:23 <zarvox> some are things the platform can do automatically, and others might be things that apps can opt into, and others are just helping improve apps that are doing non-optimal things

20:24 <erikoeurch> Gitlab, checked again now it clocked in at just short of 17 seconds

20:25 <erikoeurch> (The grain is just 3 MB)

20:27 <erikoeurch> I feel silly complaining about those seconds, but it makes a difference to the feeling of convenience of opening up a Sandstorm app and I'm sure it'll be great to have a bit more speed at startup

20:27 <zarvox> Right, ruby does an amazing job of being quadratic when loading modules: http://accidentallyquadratic.tumblr.com/post/113407169892/ruby-application-startup

20:27 <erikoeurch> Are the disks SSDs?

20:27 <erikoeurch> oh, haha

20:32 <zarvox> The disks are ultimately GCE storage, but there's network round-trips in there which probably add up when you do thousands of stat()s looking for modules

20:33 <zarvox> I'd say Gitlab is one of the more pathological apps in this regard at present, but I agree that 17 seconds is pretty painful.

20:36 <erikoeurch> That thing about being quadratic in loading modules shouldn't be an issue here, if that linked article is right, since Ruby 2.1.5 seems to be used according to the log

20:38 <erikoeurch> anyway, I'll live with the loading time, things could be worse. It's a pretty useful app anyway!

20:38 <zarvox> Touché, it's actually the PATH-searching issue. You have n places to look for a particular .rb file, so you stat() all the possible paths in order, and most of them don't exist

20:39 <erikoeurch> right

20:39 <zarvox> so there's a bunch of round-trips to the FS and back, so adding a network round-trip to all those going-to-fail reads is painful.

20:40 <zarvox> Maybe we could teach Ruby to scan the paths eagerly instead and do the path search in-process rather than asking the kernel a bunch, since we guarantee that the parts of the FS that aren't /tmp or /var are readonly

20:41 <zarvox> That costs RAM and code complexity instead, but probably not *that* much RAM.

20:43 <erikoeurch> sounds like it could be a decent trade-off if it works

20:47 <erikoeurch> does Sandstorm encourage code contributions/pull requests from outside people?

20:49 <zarvox> absolutely!

20:51 <erikoeurch> I may be able to use some of my working time for contributions to open source projects, so I'm thinking Sandstorm would be a good first candidate

20:51 <erikoeurch> and I've been working on Meteor apps for a while, so perhaps I could help out a little with those parts

20:52 <zarvox> That's fantastic! What parts do you find most interesting? Backend C++? Frontend JS/CSS/etc.? Packaging your favorite app?

20:52 <erikoeurch> Probably frontend and possibly packaging some app

20:54 <zarvox> We've got a decent number of ways the frontend could be improved in our issues list: https://github.com/sandstorm-io/sandstorm/issues

20:56 <zarvox> For packaging apps, I think the best place to start is probably https://docs.sandstorm.io/en/latest/developing/

20:58 <zarvox> Asheesh is in the process of moving a bunch of docs from the wiki to docs.sandstorm.io, so there may be some linking back and forth at the moment, but if you're confused, feel free to ping me with any questions you may have :)

20:58 <erikoeurch> great

20:59 <zarvox> Also I'm always interested to know what things you thought were easy and which things didn't go perfectly according to plan, so we can make those better in the future.

20:59 <erikoeurch> Though it'll still probably be a while before I dig in, plenty of things to do until summer's over, and I don't have a dev Sandstorm environment set up so I'm guessing it would require a bit effort before getting started

21:01 <erikoeurch> will keep that in mind when I start setting up!

21:01 <zarvox> great!