05:22 <dsamarin> I've got voice!

05:22 <dsamarin> It's been years

05:31 <Rzrik> hey dsamarin

05:32 <dsamarin> hey Rzrik what's new?

05:32 <Rzrik> Dying

05:32 <Rzrik> I mean, literally

05:32 <Rzrik> My body is self destructing

05:33 <dsamarin> me too!

05:33 <dsamarin> i mean we all have a rate

05:33 <dsamarin> what's going on with your body?

05:33 <Rzrik> Hopefully I get surgery in 2 weeks

05:33 <Rzrik> Chronic pancreatitis

05:34 <dsamarin> sounds painful

05:34 <Rzrik> My pancreas are digesting themselves from the inside

05:40 <ljharb> how many pancrei do you have?

05:44 <Rzrik> 1

11:29 <elliottcable> jfhbrook: who fucking knows lmao

11:30 <elliottcable> gkatsev: lies

11:30 <elliottcable> paws has basically been the same thing for five+ years, lol

11:30 <elliottcable> just slowly rewiring internal bits to make more sense together, a little bit at a time

11:31 <elliottcable> mostly Paws is simple and would be done if I weren't working on it completely alone, exclusively in the ‘programming time’ that my mental-health will allow me :x

11:32 <elliottcable> lol.

11:32 <elliottcable> this is almost certainly not accurate, but Harvest claims I've only spent a total of 69 hours actually writing code against Paws in 2016 and 2017.

11:39 <elliottcable> god, that's depressing, I hadn't looked at that number recently

11:46 <purr\Paws> [Paws.js] ELLIOTTCABLE created squashing-queueless+ (+8 new commits): https://github.com/ELLIOTTCABLE/Paws.js/compare/a11ac31c1d7c^...4161142523fd

11:46 <purr\Paws> Paws.js/squashing-queueless+ 58051f2 ELLIOTTCABLE: (!! del API inc!) Rip out the Mask type entirely...

11:46 <purr\Paws> Paws.js/squashing-queueless+ 4346396 ELLIOTTCABLE: (fix API) Abandon Execution.associates work

11:46 <purr\Paws> Paws.js/squashing-queueless+ a11ac31 ELLIOTTCABLE: (new API) Implement initial Liability plans...

11:46 <elliottcable> yeah wtf

11:46 <elliottcable> oh well bot

11:48 <gkatsev> lies, damn lies, and statistics

13:57 <jfhbrook> 69 hours, elliottcable ?

13:57 <jfhbrook> nice

15:57 <pikajude> holy shit dude

15:58 <pikajude> just spent 10 minutes trying to get this guy to tell me why order matters in our query building DSL

15:58 <pikajude> take(1)->where(...) will cause the optimizer to silently fail

15:58 <pikajude> where(...)->take(1) is fine

15:58 <pikajude> no filtering of actual data is done until you call gen() on the resultant query

15:58 <pikajude> however, you cannot call take before where

15:58 <pikajude> i asked why

15:58 <pikajude> "because order matters"

15:58 <pikajude> "think about the difference between take(1)->where(...) and where(...)->take(1)"

15:59 <pikajude> me: "what is the difference"

15:59 <pikajude> "order matters"

15:59 <pikajude> eventually I asked "why does order matter when adding predicates onto a query AST" and he said "because it does"

18:36 <ljharb> pikajude: i can see it mattering in the sense that `.slice().map()` and `.map().slice()` are different

18:37 <ljharb> pikajude: iow, doing the take first means the "where" is faster

18:37 <ljharb> BUT since it's a DSL, there's no reason it couldn't always do the take before the where

18:37 <pikajude> it's a DSL

18:37 <ljharb> (since "take" is just a number, and doesn't depend on anything the "where" would be filtering)

18:37 <pikajude> that's like saying SELECT ... FROM ... LIMIT ... WHERE ... has a different meaning than SELECT ... FROM ... WHERE ... LIMIT ...

18:40 <ljharb> right, i agree with you there

18:40 <ljharb> but it's only true that they have the same meaning because the "where" has no semantic impact on the "limit" count

18:40 <ljharb> whereas in code, it would - so i understand why they would treat it that way.

18:40 <ljharb> but i agree with you that it's not code, so there's no reason for it to matter

18:59 <pikajude> thanks for agreeing with me :')

22:08 <Cheery> elliottcable: if you've looked into lever, what kind of disgusting things you think there is in it?