03:26 <eternaleye> kentonv: To revive a months-old discussion, in which I wondered about ways in which the pointer-chase limit heuristic could be revised to a guarantee-of-termination, I just had a thought - could the forwards/backwards pointers always carry with them an "extent", referring to the space the pointee is allowed to carry pointers into, that must-shrink with each dereference?

03:27 <eternaleye> Would bloat every pointer by possibly 3x, but might be interesting for some use cases

03:43 <kentonv> eternaleye: I think you'd also need to prohibit sibling pointers from having overlapping extents to get meaningful protection, but that would pretty much force the message to be constructed either in pre-order or post-order, whereas currently you can interleave modifications to multiple branches

03:45 <eternaleye> Hm, yeah, I hadn't fully considered the sibling pointers concern - I'd thought that "pointee not in its own extent" being permitted would handle the nonoverlapping case, but now I'm realizing that any tree beyond two levels doesn't quite work with that

03:46 <eternaleye> Hm, although, a more general rule (a pointee carries a "set of extents" that just be a strict subset of its parent's set of extents) may work

03:46 <eternaleye> *must be

03:48 <kentonv> it's probably easiest to require strict pre-order or strict post-order. That's easy to enforce and doesn't require any extra info in the message body.

03:48 <eternaleye> Yeah

03:48 <kentonv> but it means code has to be written in a certain way

03:48 <eternaleye> I wonder if strict pre- or post-order is easier to write. I presume the former means the message must be built "top down" and the latter "bottom up"?

03:48 <kentonv> you'd probably end up with something that looks like SBE, actually

03:49 <kentonv> right

03:49 <eternaleye> Kind of suspect post-order would be very natural for FP languages

03:49 <kentonv> yes, probably

03:49 <kentonv> but I've found pre-order useful many times, too. It depends on the use case.

03:50 <kentonv> either way, though, being forced to order your code according to the order of the fields is likely to be annoying

03:51 <kentonv> in fact it would be a big problem in functional languages where you'd really like to avoid specifying an order in which seemingly-unrelated computations occur

03:52 <kentonv> you'd need to do everything in monads, I suppose

03:52 <kentonv> to be fair, you probably have to do that anyway for Cap'n Proto in the absence of some huge magic

03:52 <eternaleye> Arrows could work, too

03:55 <dullthursday> hello, I have a few n00b questions about developing a sandstorm.io app

03:55 <dullthursday> i'm used to the traditional model of getting the database all together and deploying those scripts that separating from the app itself

03:56 <dullthursday> how do it convert this model into the sandstorm.io model with self deployments without reworking the scripts

03:56 <dullthursday> i'll be doing a php - mysql setup

04:01 <kentonv> Hi dullthursday! On Sandstorm, you would include MySQL as part of your package -- it runs in the container with your web server. There is a tutorial here which uses an nginx-php-mysql arrangement: https://docs.sandstorm.io/en/latest/vagrant-spk/packaging-tutorial/

04:08 <dullthursday> thanks i'll check it out

16:17 <JonTheNiceGuy[m]> Evening ;)

16:18 <asheesh> Random thought: Maybe we should rename "grain" to "activity"

16:18 <asheesh> Except then the list on the sidebar would say "Activities" and maybe that's not great.

16:19 <asheesh> I also mulled over wanting to rename "grain" to "item".

16:19 <JonTheNiceGuy[m]> Or content?

16:19 <asheesh> "Content" is interesting

16:20 <asheesh> "New {{appName}} content" is a little odd though for a default noun phrase for apps

16:21 <asheesh> OTOH "Create {{appName}} content" is maybe OK.

16:21 <asheesh> A little odd still I think.

16:21 <JonTheNiceGuy[m]> Really? "New WordPress content"

16:22 <JonTheNiceGuy[m]> "new etherpad content"?

16:25 <asheesh> "New Rocket.Chat content" is a little weird, but after all, they can pick their own sensible noun phrase (-:

17:06 <theSoenke> what about instance?

17:10 <theSoenke> "New Rocket.Chat instance" sounds good i thing

18:04 <asheesh> Whatever word we switch "grain" to, it should presumably also work as a plural noun on the left side. I think "Instances" as a user-facing navigation item is more technical than I think I want users to be seeing frequently for their Etherpads.

18:12 <Lord> grain is nice

18:13 <Lord> it's not technical. it means something which starts empty then grow with content

20:57 <frew> asheesh: fwiw I agree. Even as a technical user I always get confused about which is which.

20:57 <frew> instance is more clear to me, but I suspect the lay person would think of an app like an app on their phone and that is also an instance

20:58 <frew> asheesh: it might be reasonable to consider making the left bar, if the user has few enough, simply list the instances

21:23 <JonTheNiceGuy[m]> Or at least, your most recent X

21:24 <frew> yeah good idea

21:26 <JonTheNiceGuy[m]> But, it should be configurable. Option to turn off should be key. Imagine you work in HR and you open the screen, and it says "Joe Bloggs Dismissal"....

21:27 <JonTheNiceGuy[m]> Or like Win 7, you list the applications, and there are pop-outs which show your recent grains.

21:28 <frew> lol

21:28 <frew> sure

21:28 <zarvox> the sidebar also acts as a hint to Sandstorm about which grains to keep alive and which ones to kill off in the background to make the appearance of "everything always open" feasible

21:30 <zarvox> in theory, apps should be designed so they can be stopped and started whenever. in practice, unlike on Android/iOS, most apps weren't built that way from the get-go, and will do much better in terms of user experience if they're running for the duration of the user's usage.

21:31 <frew> oh yeah I forget that they are there in the sidebar if they are active

21:31 <zarvox> other way around, but yeah

21:31 <zarvox> (presence in sidebar is sufficient, but not a necessary condition for the grain to be running)

21:32 <zarvox> (could be opened by another user, for an API session, or in a different browser window of your own)

21:32 <frew> right I mean as a user that's what it tells me, not that it causees it to happen

21:32 <frew> could ofc be out of date info etc