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
<gkatsev> you?
<ec> boring code
<gkatsev> that's some jsdoc
<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"
<pikajude> i'm starting to get genuinely annoyed
<ljharb> lol