<mnutt_>
does anyone have any thoughts on how best to use TMPDIR in sandstorm apps? I was using it for storing image thumbnail cache (among other things) but on some really large photo album grains this can actually fill up memory. My initial thought was probably just to keep a fixed number of thumbnails since they're all roughly the same size, but would it be better to put that in grain storage?
<ocdtrekkie>
I usually assume thumbnails are stored. Generating them every time would seem more wasteful.
hammerhead has joined #sandstorm
hammerhead has quit [Client Quit]
<mnutt_>
packing davros v0.31.1, fixes the toggle switch bug and the file view's delete action not working. the thumbnail cache issue needs more detail and I figured I'd go ahead and release a point update
<mnutt_>
re: click-and-drag regions on a calendar, I don't envy whoever has to implement that. dragenter/dragleave can be a real pain, I've been fighting that the last week or so with davros file moving
<griff>
mnutt_: what details do you need?
<mnutt_>
griff: I was wondering if there were a really large number of files in the directory and it happened immediately as soon as you opened davros, or if this was something that accumulated over time while browsing around
<griff>
I can’t open the grain at all
<mnutt_>
are all of your image files in one giant directory?
<griff>
I think so.
<griff>
I am not at home right now and I aparently haven’t setup remote SSH access to the machine so I can’t check this minut
<mnutt_>
my theory at the moment is that as you attempt to load the davros UI, the frontend may make a large number of simultaneous thumbnail requests
<mnutt_>
my recollection was that generally browsers would only make 6 at once, but perhaps there's something else at play
<mnutt_>
using chrome?
<griff>
It crashes at the very first request to the grain
<mnutt_>
some other things to try: see if you can download the grain backup; after you extract it the thumbnails should be data/davros/tmp/file-cache and you can see how much space it takes up
<mnutt_>
and if there's anything in the grain log
<griff>
Backup failed: Internal server error
<mnutt_>
ah shoot, hmm
<mnutt_>
that may be a result of sandstorm struggling to make a backup of an 11GB grain...
<griff>
That grain might just be borked. The backup failed with: No such file or directory; name = zSAmjwux9qfPdF7J8Dnfm3
<isd>
As long as there's disk space, backing up large grains should work fine. I've made snapshots of multi-gigabyte grains before.
<isd>
Re: /tmp, it's only ~16MiB, so if you want more scracth space than that, you'll have to put it under /var somewhere (probably /var/tmp)
<isd>
...and clear it out periodically yourself, if you want to
<mnutt_>
davros stores cachefiles in /var/davros/tmp
<griff>
I think I’ll try and reproduce the problem in a fresh grain
griff_ has joined #sandstorm
griff has quit [Read error: Connection reset by peer]
<TimMc>
I notice that in the app market's experimental=true mode, all the "last updated" dates are around Unix time = 0.
<ocdtrekkie>
Yep, always been like that.
<ocdtrekkie>
Because the updated date is set when the package is approved.
<TimMc>
Is there a way I can upgrade just a single grain?
<ocdtrekkie>
Unfortunately, not within the UI. It's a peeve of mine at present and the reason I want a "change package Id" function as a grain setting.
<ocdtrekkie>
If you create a new grain though, that'll use the new version, without impacting the existing grains.
<isd>
I think "upgrade a single grain" is a coherent feature that probably should exist by itself. Do we already have an issue for that?
<ocdtrekkie>
If it does I probably linked to it in my change packageId issue.
<ocdtrekkie>
As it's one of the use cases I was imagining we could address.
<TimMc>
I imagine it would just be "sugar" over the change-package-ID thing.
<isd>
At some point I still want to have everything available programmatically. At which point anything the UI doesn't provide you could write a script for.
<isd>
As I said on the packageid issue, I don't really object to an equivalent of about:config. But I also feel like filling in things like this with potentially-dangerous features that require some knowledge of sandstorm internals to understand is sortof step 1 on the road to perdition re: usability.
<ocdtrekkie>
My thought would be that it would be a interim capability, to be removed when we had better UI for all of the cases it can cover.
<ocdtrekkie>
But to me, the worst is telling people that the sensible thing they want to do can only be done by writing a Mongo query.
<isd>
Tbh I'm not sure it's meaningfully easier to do the packageId feature than to just do all the things. You'd presumably end up with a meteor method that sets the package id, but then the rest is just banging out some HTML.
<isd>
...maybe as an intermediate step we could just implement that meteor method, and until the UI for these features gets built you could open up the browser console and do meteor.call('setPackageId', {grainId: ..., packageId: ... })
<ocdtrekkie>
I mean, that would definitely be better than sandstorm mongo on the server.
<isd>
I think that's step 1.
<ocdtrekkie>
As non-admins could access that, with all the appropriate checks that a user is authorized to do it and such.
<ocdtrekkie>
My number one irritation with Oasis was encountering seemingly reasonable things that I couldn't do, and having no recourse to do them as a user.
<TimMc>
Browser console sounds fine to me.
<isd>
The feature will have to have a restriction of course: the packageId must be that of an app package the user has installed. Which means that e.g. to downgrade you will have to first separately re-install the old .spk
<isd>
But, given that, I do think this will be reasonably straightforward. Might experiment with it in the next couple days.
mnutt_ has quit [Quit: Leaving...]
mnutt has joined #sandstorm
<ill_logic>
I'm assuming Sandstorm doesn't care about IE anymore right?
<ocdtrekkie>
It does not.
<ill_logic>
I feel like I asked this once, years ago, with the same answer. But I saw a commit from 2016 in the etherpad application with reference to it.
<ill_logic>
Which seems surprisingly recent.
<ocdtrekkie>
Microsoft officially issued the position years ago that IE was solely a compatibility layer for legacy apps, not a web browser for normal use.
<ocdtrekkie>
And Microsoft has begun dropping IE support from many of it's own apps and services.