ec changed the topic of #elliottcable to: a π―ππ ππ π―πππππππππ π―ππππππ slash sΝΜuΝΝpΝΝeΜΜΊrΜΌΜ¦iΜΌΜoΜΜ¬rΜΜ cΜΝα»₯Μ§ΝαΈ·Μ‘ΝΕ£ΝΜ || #ELLIOTTCABLE is not about ELLIOTTCABLE
<ec>
hmmmmm
<ec>
well, I'm still alive
<gkatsev>
that's good
<ec>
gkatsev: hello gkatsev β @gkatsev
<gkatsev>
hi
<ec>
watch upto
<gkatsev>
watching a video about magic and jazz, looking up meteor showers and total and partial solar eclipses, and looking up yoga stuff
<ec>
is 300 lines of documentation a lot of documentation? Β―\_(γ)_/Β―
<ec>
I obsessively over-document, tbh
<gkatsev>
it is when it's in a jsdoc
<ec>
although to be fair, that's really documenting *two* functions that share some setup and are usually evaluated together
<ec>
and that's also the README
<ec>
I'm a big believer in convergent documentation and testing
<ec>
either generating your documentation from your tests, or your tests from your documentation, or some combination/subset thereof
<ec>
inline Markdown example code in your documentation should be evaluated as tests (so that it can never become out-of-date); and there should be a single source-of-documentation-truth (preferably adjacent to the code itself, i.e. JSdoc-style), which should generate any other (HTML, README, API, coverage) documentation automatically
<gkatsev>
having the docs in two places just means that either or both places would end up outdated
<ec>
exactly.
<ec>
hahah I'm laughing at my own writing from like a week ago
<ec>
Β« I'm 1. generating 2. stringly-typed code for 3. one of the world's [most notoriously fragile languages][1] based on 4. direct user-input in 5. a knocked-off-in-a-week-ish (I hope? ... ask me in a week.) library written by 6. one dude 7. in his free time ...
<ec>
... **This is not secure. This will not be secure. Do not use this for things that need to be secure.** Β»
<ec>
also, I didn't finish it in a week, week-ago-me π
<ec>
got a good goddamn way tho
<joepie91>
ec: I cannot see anything that might go wrong there. nope, nothing at all.
<joepie91>
:P
mylesborins has quit [Quit: farewell for now]
mylesborins has joined #elliottcable
Sgeo has quit [Ping timeout: 268 seconds]
Sgeo has joined #elliottcable
Sgeo_ has joined #elliottcable
Sgeo has quit [Ping timeout: 246 seconds]
devyn has quit [Ping timeout: 255 seconds]
devyn has joined #elliottcable
<pikajude>
okay so
<pikajude>
i'm starting to get really annoyed by people that leave comments on PRs that are marked [WIP] that say things like "why are you using echo here? nobody will read that"
<pikajude>
thanks, genius
<ljharb>
tbh tho why make a PR if it's WIP
<jfhbrook>
github's diffing kinda sucks without a PR
<jfhbrook>
I create PRs early so I can more easily view diffs
<jfhbrook>
and then I mark the PR as "ready for review" when it's actually done
<pikajude>
ljharb: well
<pikajude>
i just started here
<pikajude>
and this is like a 1200 line diff
<pikajude>
because it's a lot of new code
<pikajude>
and i like it when people look at my code and say "ok, this is all completely wrong" *before* it's completely done
<pikajude>
rather than after
<jfhbrook>
I'll do that too ^^ but I'll usually PM and be like, hey does this look reasonable, rather than quietly tagging someone for a review C:
<pikajude>
but the point remains that you should probably be able to tell that an echo statement is unlikely to make it to the final product
<ljharb>
jfhbrook: yes but if you go to the "create a PR" page you get that diff already
<ljharb>
ie you don't actually have to create the PR, usually
<jfhbrook>
yeah but the ergonomics of that workflow frankly suck
<ljharb>
true
<ljharb>
but yeah i guess the main issue i have with it is that people who put up WIP PRs get upset sometimes when it gets reviewed
<jfhbrook>
a PR operates as a bookmark
<ljharb>
(see above)
<ljharb>
and also, there's no good way to block a WIP PR that got approved while being WIP
<pikajude>
right
<pikajude>
but
<pikajude>
if you're going to review a WIP PR
<pikajude>
and a line says // @nocommit
<pikajude>
and there's an echo statement
<pikajude>
why bother commenting on it
<ljharb>
iow i want a way to mark a PR as "wip" that prevents it from being merged under any circumstances, and when it's unmarked as wip, all reviews should be invalidaed
<pikajude>
yeah
<ljharb>
pikajude: yeah true
<pikajude>
at FB, if you put // @nocommit anywhere in the source
<pikajude>
your diff cannot be landed
<pikajude>
until that's gone
<pikajude>
so i just use that
<ljharb>
is this an fb pr?
<pikajude>
it could be
<pikajude>
yes it is
<ljharb>
lol what i mean is, that convention is meaningless unless it's in a repo where it's enforced
<pikajude>
oh
<ljharb>
if it is in a repo where it's enforced, then the person who commented on it is stupid
<pikajude>
ok but the idea is
<pikajude>
ok
<pikajude>
yeah that's the answer i wanted
<pikajude>
thx
<ljharb>
:-D
<ljharb>
<3
<pikajude>
me: "why the fuck does gzcompress() return a mixed value"
<pikajude>
me: "oh, because it returns false if there was an error"
<pikajude>
what the fuck
<pikajude>
how can gzcompress even fail
<swart>
no software should be allowed to fail
<pikajude>
ljharb: he responded to my comment saying "this is for testing purposes" with "that's not how this should be tested"