<aldeka>
zarvox: There was some shade thrown at forwardjs w.r.t. the inline-CSS movement
<aldeka>
fwiw
<aldeka>
I think that there are some use cases where it totally makes sense, but I am wary of people latching onto it who don't have a great grasp of how to write or organize CSS the usual way >.>
<aldeka>
i,i no webcomponent is an island
<aldeka>
Maybe once this thing I'm working on reaches alpha release, I'll refactor the styles some more and see which ones make sense to inline.
<kentonv>
on one hand I like the concept of being able to assign the style of an element from a Javascript variable, thus using a real programming language with sort-of-sane scoping and such. On the other hand it seems like totally the wrong separation of concerns to put style rules anywhere near code.
<kentonv>
basically what I want is to define a style in scss syntax (with nesting) and turn that into a value, which can be plumbed through code like you would any object, eventually finding its way to the target DOM element.
<kentonv>
it seems like the closest thing we have to that today is scss variables / extends
<zarvox>
that does sound nice, although nesting like that makes it harder to split off leaves into their own modules
<aldeka>
...if your nesting is turning into gigantic trees, you got bigger problems :/
<aldeka>
It's considered good Less/SCSS practice to avoid nesting more than four levels deep
<aldeka>
excitingly, I discovered only like a couple weeks ago that you can have nesting in mixins
<aldeka>
so that's neat
<zarvox>
I kinda reject the notion that putting style rules near code is a violation of separation of concerns. In practice, the two wind up being modified together so often (added a new tag? better add a style for it.) and used together everywhere (you don't actually add new stuff to a page without having any styles for it) you actually want to keep them together
<aldeka>
"maybe you already violated separation of concerns sticking your HTML in your code"
<kentonv>
zarvox: if you want to move a nested branch/leaf into a different module, you turn it into a mixin...
<zarvox>
you make a mixin that is used exactly once?
<kentonv>
err, I think I'm actually thinking of @extend. I need to understand the difference.
<kentonv>
but yes, one you possibly use only once
<kentonv>
that's fine
<kentonv>
hmm mixins and extends seem to overlap in what they do?
<zarvox>
I think so
<zarvox>
mixins appear to allow parameters to the mixin
<zarvox>
whereas @extend appears to be strict inheiritance
<paulproteus>
i,i functions and subroutines
<kentonv>
it looks like a mixin defines a macro that gets copied into every use site, whereas with extend, the block appears once and all the elements it targets get dynamically put together into a selector list for that block
<kentonv>
so basically it's a difference in what the output will look like?
<zarvox>
"implementation details"
<kentonv>
I guess prefer extend when it works, otherwise use mixin. One problem I noticed with extend is that you cannot use it inside a media query, presumably because media queries are not normal selectors and so can't be added to the selector list so easily.
<kentonv>
(which is dumb, they should just be another kind of selector...)
<juri_>
paul: CreateVM. it used to be on gitorious.
<juri_>
paulproteus: it's basically a pile of shell scripts, and a multi-image autoinstall script that allow me to install VMs for the purpose of running one specific webapp per VM.
<kentonv>
as for separation of concerns, the problem is that there are multiple dimensions of input on which CSS varies. One is the HTML, which is component-specific. Another is overall site look & feel, which is not specific to any one component. Another is desktop vs. mobile vs. print vs. screen-reader.
<paulproteus>
That's neat juri_ (-:
<juri_>
i just type "createvm drupalserver tearoff fai_dvd-20150715.iso", and i have a new drupal instance.
<aldeka>
Or maybe just the idea of applying something called styles.base every-freaking-where.
<zarvox>
Eh, that's the cost of not having implicit cascading/global scope styling :/
<paurelayproteus>
Off-topic-ish, but: Gotta say, this client looks nice.
<zarvox>
Either you are getting implicit styles from somewhere (and can break if they change) or you're not, and you have to make a nod to the hierarchy explicitly
<aldeka>
Base exists, and will break your ish if it changes, even if it's turned into a variable and repeated on every component in the app.
<zarvox>
but if you're explicit about it, you can apply tooling to track where those dependencies are, or refactor things appropriately
paurelayproteus has quit [Remote host closed the connection]
<kentonv>
does such tooling actually exist or is it theoretical?
<kentonv>
statically tracking anything through Javascript is rather difficult, etc.
<aldeka>
zarvox: Either you want your component to look like the rest of your website, or you don't.
<zarvox>
for specifically tracking style things, I'm not aware of any. For doing typechecking on Javascript, there's Flow, which is pretty nice.
<aldeka>
Having a CSS reset mixin that you selectively apply inline makes far more sense than this example on Radium's site...
jacksingleton has joined #sandstorm
<aldeka>
flexbox rules also probably make sense to inline. Since they're so tied to the HTML layout/basically instantly break if you ever add or remove a wrapper div :P
jacksingleton has quit [Ping timeout: 260 seconds]
jacksingleton has joined #sandstorm
<paulproteus>
rehi jacksingleton
<paulproteus>
Apparently I convinced myself to package Semantic MediaWiki for Sandstorm for someone.
<paulproteus>
I probably was hitting the CSP issue of "App is using a cached old app subdomain", I now realize, but neglected to check the JS console because "this is a backend problem, not a frontend problem".
jacksingleton has quit [Ping timeout: 240 seconds]
<larjona>
Hi everybody!! paulproteus I just sent to you an email with my status update about packaging Framadate. Will upload my last .spk to the repo and send summary mail to the mailing list. I'm around here some more hours (3h or so) but I didn't sleep in the whole night for several reasons, so i cannot promise to stay in front of the computer much more :/
<geofft>
capnp-rpc question: is there a canonical way to do RPC for the web platform / in JS?
<kentonv>
geofft: There is a JS implementation with some limited RPC support -- the one by tim popham -- but I'm not sure what state of usability it's in
<geofft>
I guess, what do y'all do for the Sandstorm web interface itself? is that just Meteor?
<kentonv>
currently, Meteor, yes. We eventually would like to switch, though.
<kentonv>
zarvox: Hmm, half that article seems to be decrying how @extend makes the generated code ugly, while the other half explains that we shouldn't worry about how @mixin makes the generated code ugly because it's generated code so who cares.
bb010g has quit [Quit: Connection closed for inactivity]
gopar has quit [Remote host closed the connection]
jadewang has quit [Remote host closed the connection]
GeorgeHahn has quit [Read error: Connection reset by peer]
jadewang has joined #sandstorm
jadewang has quit [Remote host closed the connection]
larjona has quit [Quit: Konversation terminated!]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 260 seconds]
jeffmendoza has quit [*.net *.split]
snolahc has quit [*.net *.split]
soulshake has quit [*.net *.split]
warren has quit [*.net *.split]
[d__d] has quit [*.net *.split]
maurer has quit [*.net *.split]
jeffmendoza has joined #sandstorm
snolahc has joined #sandstorm
soulshake has joined #sandstorm
[d__d] has joined #sandstorm
warren has joined #sandstorm
maurer has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 264 seconds]
itscassa has joined #sandstorm
GeorgeHahn has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 252 seconds]
itscassa has quit [Ping timeout: 240 seconds]
itscassa|away has joined #sandstorm
itscassa|away is now known as itscassa
dwrensha has quit [Quit: ChatZilla 0.9.91.1 [Firefox 39.0/20150630154324]]
dwrensha has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 244 seconds]
itscassa is now known as itscassa|away
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 260 seconds]
preilly has quit [Ping timeout: 244 seconds]
paulproteus has quit [Remote host closed the connection]
paulproteus has joined #sandstorm
preilly has joined #sandstorm
preilly is now known as Guest97200
Guest97200 has quit [Changing host]
Guest97200 has joined #sandstorm
Guest97200 is now known as preilly
NOTevil has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 265 seconds]
<zarvox>
kentonv: my interpretation of the article's explanation was that @extend produces a ton of selectors and relatively few declarations within those selectors, and @mixin produces a ton of repeated declarations within relatively few selectors. Given that the limited resource is rules/selectors, the latter is more desirable, because it leaves more headroom, and compression deals with the duplicated text.
<zarvox>
it certainly could have been better presented, though :/
<kentonv>
zarvox: sure, an @extend with only one or two attributes is probably wasteful, because the selector may actually take more bytes than the attributes. But that's sort of a degenerate case and the overhead is not huge. As for the 4095 limit, that seems to apply to IE9-.
<maurer>
If I want to ship a description of a capability type to a remote system, is using the schema for the capnp compiler plugin the correct way to do this?
<maurer>
(I'm considering the situation in which A sends a capability to B, then C wants to talk to B and script interactions on that capability, which requires it to know what is/is not on the capability)
<kentonv>
yes, you want to send a bundle of Nodes as defined in schema.capnp
<kentonv>
FWIW, the feature you describe is something we want to build into the RPC protocol eventually
<maurer>
(this is a pattern I keep seeing that is encouraging - "I want to do X, can we do it?" "We're already working on it in the form of the following components, or plan to work on it"
<kentonv>
(well, it is still vaporware... :) )
rustyrazorblade has quit [Quit: rustyrazorblade]
natea has quit [Quit: natea]
* paulproteus
waves.
<warren>
paulproteus: yo
natea has joined #sandstorm
jadewang has quit [Remote host closed the connection]
<paulproteus>
I don't super-duper know what the story is with that pull request, btw!
<paulproteus>
The idea is that if catch_panic() is "stabilized" (?) then it won't need /proc/self/maps (iirc?)?
<dwrensha>
no, this is orthogonal from the /proc thing
<paulproteus>
Oh, okay.
<dwrensha>
this means that an assert failure in GJ doesn't have to bring down an entire thread. It can just error out the appropriate promises and continue.
<paulproteus>
Ah hah, right-o.
<maurer>
Honestly I'm a little worried about rust adding catch_panic. If they add that, they may quickly end up with actualfax exceptions and people will stop using Result<>, and everything will enter the C++/Java horrortown of everything maybe kinda sorta throwing exns
natea has quit [Quit: natea]
<zarvox>
paulproteus: Alex Crichton fixed the /proc/self/maps thing (literally during the Rust in production call after dwrensha mentioned it, I'll add)
<paulproteus>
Ah, OK, great.
<paulproteus>
That's vaguely what I remembered but I wasn't sure.
<kentonv>
maurer: bugs can happen anywhere. There needs to be a useful thing to do when you detect an erroneous state and cannot continue.
<maurer>
kentonv: I agree, I just want it to be explicitly stated which error conditions I need to be able to handle when I call a function.
<maurer>
kentonv: When I call a C++ function, unless I get lucky, and there's a lot of documentation, I could get any old exception fired at my face.
<kentonv>
do you expect every function which uses arrays to explicitly declare that it might throw array-out-of-bounds?
<maurer>
kentonv: It should either be using a checked-access function which returns e.g. Option<foo> and checking it internally, or if using an unchecked one, should know it's doing it right
<kentonv>
I definitely agree people shouldn't write bugs but that doesn't really help. :P
<maurer>
kentonv: Disagree - I am saying that unchecked access is something you should rarely use
<kentonv>
that sounds pretty ugly to me
<maurer>
If you must use unchecked access here, I still don't see how you'd be able to get an exception more efficiently/elegantly than you could use an Either or Result type
<kentonv>
usually you *think* your indexes are in-bounds. Explicitly checking every array access would be a huge pain.
<maurer>
If you are certain it's there, put an assert in saying it's there, and then your program should explode when that turns out to be wrong
<maurer>
because if one invariant has been violated, who knows how many unchecked invariants have secretly been violated along with it
<kentonv>
that's just not realistic
<kentonv>
there will always be bugs and you can't have your multi-user server going down whenever one happens
<maurer>
OK, so how are you going to handle an out-of-bounds exception in a better way than killing the thread it happened in?
<paulproteus>
BTW kentonv I'm curious what drove you to work on passing user profile details to apps over the weekend. Was it a desire to make the Let's Chat package better? Something else?
<kentonv>
panic, catch the patic, fail the request
<paulproteus>
[don't mean to interrupt, answer whenever or never, just curious]
<maurer>
OK, so you're basically thinking of it as a way to corral a sort of virtual thread (e.g. a thing triggered by an event loop)
<maurer>
paulproteus: What we're talking about is probably not actually important, aiui this is a long running ideological debate
<kentonv>
paulproteus: yesterday, not weekend. I think it was because maurer was surprised in IRC yesterday when he used David's built-from-master server and Let's Chat ignored his handle setting. :)
<kentonv>
maurer: yes. I just want to be able to isolate failure to the one request.
<maurer>
Yeah, the way I've done that in general is to place the unit in some kind of lightweight thread
<kentonv>
but lightweight threads were apparently removed
<maurer>
Yeah, I haven't had to write a service in rust that is intended to be reliable yet
<maurer>
so I don't know how I'd handle it there
<paulproteus>
Ah neato kentonv (-:
<maurer>
(my big rust service is a research project, and so for me, right now if an assertion trips, what I want is a stack trace, a core dump, and an offline service :P)
<kentonv>
FWIW there have been huge flamewars inside Google about whether asserts that kill the process should be permitted at all
<paulproteus>
It's fascinating to consider how Debian and Google are similar.
<kentonv>
I used to be on the side of "yes, much better to crash than to run in an inconsistent state", but the people actually tasked with keeping these services observed that assertion failures were a really huge problem in production
<kentonv>
* keeping these services running
<paulproteus>
My friend glyph once remarked (I might be mis-remembering), I used to be really excited about free software. Then I realize Apple has more programmers than the entire free software movement combined.
<paulproteus>
s/I realize/I realized/
<paulproteus>
Which is to say, as I understand it, it's considered Not OK for shared libraries in Debian/GNOME-land to assert().
<kentonv>
things were worse inside Google because exceptions were also disallowed, so the only thing you could do if you were deep in a library function and noticed a problem was log an error and then return some sort of "reasonable default" value
<kentonv>
which is just really awful
<kentonv>
but that's what they made people do
<zarvox>
kentonv: dwrensha: one or both of you should probably reply to that RFC thread with your comments
<kentonv>
exceptions are much better than that, at least
<kentonv>
zarvox: will do
<maurer>
kentonv: I'm not really averse to exceptions being used in that way. The problem is that when they get introduced, they tend to start getting used everywhere
<maurer>
kentonv: And pretty soon you get things like the OCaml standard Map data structure, for which there is no function returning Option<Foo>, because they figured you could always just catch the exception
<maurer>
kentonv: Or parsing libraries that throw a parse exception rather than returning a value indicating a failed parse (haskell elf parser)
<kentonv>
maurer: I don't like "slippery slope" arguments.
<maurer>
I guess what I'm getting at is that as a social construct, exceptions start to get used in places where you don't want exceptional control flow
<maurer>
The usual flaw with slippery slope arguments is that they're describing slippery slopes we haven't been down before
<maurer>
C++, Haskell, and OCaml have all slid down this slope already; I've watched them do it
<zarvox>
some other thoughts: the risk of catch_panic being used where it doesn't belong can be mitigated by 1) documenting appropriate and inappropriate uses of the function and 2) the fact that the standard library and idiomatic Rust code that people learn from already use Result throughout
<maurer>
#2 seems like it could help, and I hope it does, since I suspect catch_panic will be stabilized
<kentonv>
maurer: I don't know about Haskell or OCaml but C++ slid down the slope willfully.
<zarvox>
if nobody writes the examples using catch_panic (which is a library function, and not even a language construct), then people will continue using Result, which has tons of example code all over
<zarvox>
clueful people will read the docs and do what is recommended. less-clueful people will start with example code and modify it, or copy-paste snippets from elsewhere; the vast majority of which use Result.
<zarvox>
Could also propose a lint in the compiler to encourage you not to use catch_panic, or something bubbling up visibility of unsafe or catch_panic on crates.io, or something
achernya has joined #sandstorm
natea has joined #sandstorm
<paulproteus>
I'm curious if http://seclists.org/oss-sec/2015/q3/291 affects Sandstorm. Maybe I should have asked Andy Lutomirski when I ran into him yesterday (-:
<kentonv>
it does not
natea has quit [Ping timeout: 250 seconds]
<kentonv>
our seccomp filter (also written by Andy) blocks the dangerous syscalls
<paulproteus>
I would expect that to be the case but couldn't figure out which syscalls were needed.
* paulproteus
reads the exploit.
<kentonv>
modify_ldt
<kentonv>
Andy always checks Sandstorm first, and then IMs me to tell me he has another exploit that doesn't affect us. :)
<paulproteus>
Ah hah, see it now, yeah.
<paulproteus>
I guess we could add the info about the syscall filter to docs.sandstorm.io, and then have the "Linux CVEs that don't affect us" there on the docs.
<paulproteus>
It's useful to know if that doc explains things well, and/or how it can be improved (like what we can explain more about).
<mrshu>
paulproteus: nah, not sure if I have the capability needed for writing that clearly
<mrshu>
paulproteus: but I can certainly provide feedback
<paulproteus>
Awesome (-:
<mrshu>
paulproteus: looks really good -- I learned tons of new things about sandstorm by reading that
<mrshu>
paulproteus: the best part is "notice that this is far more readable than the HTTP specification."
<kentonv>
:D
<paulproteus>
(-:
<mrshu>
I certainly do agree though
jeffmendoza has quit [Remote host closed the connection]
<mrshu>
it's also just around 450 lines with comments
<kentonv>
I mean to be fair a lot of HTTP is left out.
<mrshu>
that is absolutely true
<mrshu>
if you do not mind me asking, I have a question that is not really related but interests me quite a bit
<kentonv>
go ahead
<mrshu>
suppose ownCloud or something like that will get packed as a sandstorm app -- what URL would be used in the mobile/desktop clients?
<mrshu>
feel free to just point me to a relevant part of the docs
<kentonv>
ideally, the app will go through an OAuth authorization flow with the Sandstorm server which results it in being given an authorization token
<paulproteus>
If it helps, it's useful to know the API key serves as *routing*, as well as access control.
<mrshu>
gotcha, that makes sense, thanks
<paulproteus>
I love when we can answer people's questions.
<mrshu>
paulproteus: do you often face the opposite problem?
<paulproteus>
I theorize many people have Sandstorm questions they haven't bothered to ask us.
<paulproteus>
So I think we fail to answer lots of unasked questions.
<dwrensha>
jparyani: looks like emoji support is broken in Let's Chat
<dwrensha>
:thumbsdown:
* paulproteus
chortles.
<jparyani>
gah, it's all in an "extras" directory that I never hit in `spk dev`
<jparyani>
I'll add it to alwaysInclude
<paulproteus>
BTW, I realized that I want to alwaysInclude /opt/app in vagrant-spk, but
<paulproteus>
I want to exclude /opt/app/.sandstorm .
<paulproteus>
I think there's no way to express that, right?
<kentonv>
I think you can "hide" .sandstorm?
<paulproteus>
(how does that layer with alwaysInclude, I guess is my question?)
<paulproteus>
(which one wins? I can test this anyway.)
<kentonv>
alwaysInclude targets a virtual directory, not a source directory. It says "pretend everything under this was touched".
<kentonv>
as if you had done `find dir | xargs touch` inside the sandbox.
<kentonv>
at least I think that's what it does, but it's been a while
<paulproteus>
+1
thejsj has joined #sandstorm
<thejsj>
Hey anyone here? Quick question: How am I supposed to run ngnix when trying to create my own pakcage? I installed it in `standstrom/setup.sh`, I copied my config in `sandstorm/build.sh`, but I can't run it without `sudo` in `sandstrom/launcher.sh`
<thejsj>
Tried doing `service nginx start`, `sudo service nginx start`, `/etc/init.d/nginx start`... you get it..
<paulproteus>
Hi thejsj !
<paulproteus>
It sounds like you're using vagrant-spk.
<thejsj>
Hey paulproteus :D
<paulproteus>
First question -- did you get all the way through to the end of the "5 minute packaging tutorial"?
<thejsj>
Exactly! Should have pointed that out
<paulproteus>
It's probably worth me spending some time to explain how it all works, and that might help you understand the answer to your questions.
<paulproteus>
Exactly what I was going to link to.
<zarvox>
:)
englishm has joined #sandstorm
<thejsj>
Ok, so what I'm missing is configuring ngnix to not run as sudo and run as the sandstrom user.
<paulproteus>
Ya.
<thejsj>
Cool, that answers my question. I'll look at the 'lemp' stuff and see how much I can get from it.
<zarvox>
or more specifically, "to not try to change userid to www-data, which is something only root can do"
<paulproteus>
zarvox (cc: geofft) : "Obviously" we should use https://debathena.mit.edu/config-packages/ config-package-dev to avoid this problem so nginx is always configured the way we want, by adding this as a sources.list line.
<paulproteus>
Only a 30% serious suggestion right now, but anyway.
<zarvox>
paulproteus: either something like that, or we just drop an nginx conf in .sandstorm/
<paulproteus>
Yeah, and I guess I prefer the latter because it's more easily customizable.
<zarvox>
Ditto. More self-contained too.
<paulproteus>
Plus then it's like the system nginx install isn't a singleton!!??!!!
<thejsj>
paulpretus: Oh, what a coincidence. I'm speaking at that meetup :) haha. I'll be presenting the RethinkDB part and was trying to see if I can get a demo running to present it on Thursday.
<paulproteus>
D'oh, I just misunderstood which person you are (-: I'm Asheesh from emails!
<thejsj>
hahaha Oh, no prob. My handle is confusing. Hi Asheesh! Where does the handle come from? I thought you would be Paul haha