Newest at the top
| 2026-03-29 23:23:39 +0200 | raincomplex | (~rain@user/raincomplex) (Ping timeout: 268 seconds) |
| 2026-03-29 23:23:19 +0200 | <tomsmeding> | not Date, If-Modified-Since apparently |
| 2026-03-29 23:23:13 +0200 | arandombit | (~arandombi@user/arandombit) arandombit |
| 2026-03-29 23:23:13 +0200 | arandombit | (~arandombi@2a02:2455:8656:7100:4dba:7f3:232c:4f01) (Changing host) |
| 2026-03-29 23:23:13 +0200 | arandombit | (~arandombi@2a02:2455:8656:7100:4dba:7f3:232c:4f01) |
| 2026-03-29 23:23:09 +0200 | <tomsmeding> | https://github.com/snapframework/snap-core/pull/305 |
| 2026-03-29 23:23:03 +0200 | raincomplex_ | (~rain@user/raincomplex) raincomplex |
| 2026-03-29 23:21:57 +0200 | <EvanR> | OOF |
| 2026-03-29 23:21:20 +0200 | <tomsmeding> | e.g. snap segfaulted when a request had an invalid Date: header because their C code didn't check errors (I fixed that) |
| 2026-03-29 23:20:45 +0200 | <tomsmeding> | snap is the closest that I've found, but this time I wanted to try something different because snap is a bit weird sometimes |
| 2026-03-29 23:20:23 +0200 | <EvanR> | e.g. a thing that parses HTTP, but not necessarily every content type that exists |
| 2026-03-29 23:20:21 +0200 | <tomsmeding> | I've been looking for a haskell http server that is small and does simple stuff for ages |
| 2026-03-29 23:20:01 +0200 | <EvanR> | this story suggests smaller more targeted libraries with fewer dependencies might be warranted |
| 2026-03-29 23:19:13 +0200 | <EvanR> | premature optimization! |
| 2026-03-29 23:18:58 +0200 | <tomsmeding> | so just nuking chronos helps naught |
| 2026-03-29 23:18:44 +0200 | <tomsmeding> | but then I still have aeson from mustache |
| 2026-03-29 23:18:34 +0200 | <tomsmeding> | yes |
| 2026-03-29 23:18:29 +0200 | <EvanR> | date <-> day-number ought to be not much copy pasta |
| 2026-03-29 23:17:14 +0200 | <EvanR> | breaking ToJSON FromJSON instances that aren't actually used in a library into a separate library, orphans I guess, sounds better in light of this |
| 2026-03-29 23:17:12 +0200 | <tomsmeding> | and nuke like 95% of my deps |
| 2026-03-29 23:17:07 +0200 | <tomsmeding> | tempted to reimplement date <-> day-number handling from chronos, and simple GET-only HTTP/1.1 handling from scratch instead of warp |
| 2026-03-29 23:16:31 +0200 | koala_man | (~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 264 seconds) |
| 2026-03-29 23:16:26 +0200 | <tomsmeding> | I need none of this |
| 2026-03-29 23:16:21 +0200 | <tomsmeding> | mustache the inverse, i.e. it has some functions taking ToJSON for convenience |
| 2026-03-29 23:15:28 +0200 | <tomsmeding> | chronos I think only for ToJSON/FromJSON instances |
| 2026-03-29 23:15:10 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
| 2026-03-29 23:15:06 +0200 | michalz | (~michalz@185.246.207.203) (Remote host closed the connection) |
| 2026-03-29 23:14:53 +0200 | <EvanR> | why does chronos or mustache even use aeson |
| 2026-03-29 23:13:40 +0200 | <tomsmeding> | and then I have a server that crashes and burns when I spam it with requests because warp decided that limiting accepts is not necessary |
| 2026-03-29 23:12:36 +0200 | <tomsmeding> | I don't use aeson or json in any way, and I only need HTTP/1.1 so crypton and http2 are useless |
| 2026-03-29 23:12:15 +0200 | <tomsmeding> | can we talk about dependencies? I have a simple app that uses chronos (not even all that much), mustache, warp, and some negligible other stuff. Chronos and mustache pull in aeson, and warp pulls in crypton and http2, and suddenly I have tons of transitive dependencies that take ages to build |
| 2026-03-29 23:10:11 +0200 | <glguy> | I also worked in a movie theater back when people still lined up to see movies on the big screen and lines could get quite long |
| 2026-03-29 23:09:42 +0200 | <EvanR> | yeah just assume the customer is baseline evil and you won't be disappointed |
| 2026-03-29 23:09:23 +0200 | koala_man | (~vidar@157.146.251.23.bc.googleusercontent.com) koala_man |
| 2026-03-29 23:08:58 +0200 | <tomsmeding> | (my supermarket cashier experience is from when I was like 15 and didn't know shit) |
| 2026-03-29 23:08:57 +0200 | <glguy> | I worked at a computer store in the age of mail in rebates. Every sunday lines went to the back of the store as people can in to get their free-after-rebate stuff |
| 2026-03-29 23:08:43 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-29 23:08:27 +0200 | <glguy> | When I worked people who'd been waiting in a long line behaved at least a little differently from those who hadn't been waiting long |
| 2026-03-29 23:08:17 +0200 | <monochrom> | Pretty sure the capitalist supermarket managers have found the sweet spot of the right queue length pressure to balance between "motivation to work" and error rate. :) |
| 2026-03-29 23:07:37 +0200 | koala_man | (~vidar@157.146.251.23.bc.googleusercontent.com) (Ping timeout: 268 seconds) |
| 2026-03-29 23:07:14 +0200 | <EvanR> | having worked black friday, from my perspective it wasn't particularly different from a normal busy day, since I can't tell the diff between 5 people in my line vs 500 |
| 2026-03-29 23:06:06 +0200 | <EvanR> | standing there with nothing to do is the worst though |
| 2026-03-29 23:05:34 +0200 | <tomsmeding> | putting pressure on cashier workers is indirectly also a bit mean to the supermarket, as it results in more mistakes and more missed (i.e. stolen) products, but likely the effect on the cashiers is bigger, yes |
| 2026-03-29 23:04:18 +0200 | <monochrom> | And now that I think about it, even those reasons are intended to be mean (to customers in the 1st case, employees in the 2nd case). |
| 2026-03-29 23:01:39 +0200 | Guest96 | (~Guest62@p200300ca8f23fa0023c431aeeea1b74f.dip0.t-ipconnect.de) (Quit: Client closed) |
| 2026-03-29 22:59:29 +0200 | <monochrom> | In the brick-and-mortor retail world, there are only two reasons to do that (long customer queue). One is to create hype ("oh look at how many people are dying to buy our product!"). The other is in supermarkets putting pressure on cashier workers. |
| 2026-03-29 22:57:51 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) (Ping timeout: 246 seconds) |
| 2026-03-29 22:57:20 +0200 | <monochrom> | listen(a number in the order of thousands) is simply mean. |
| 2026-03-29 22:53:22 +0200 | merijn | (~merijn@host-cl.cgnat-g.v4.dfn.nl) merijn |
| 2026-03-29 22:42:57 +0200 | merijn | (~merijn@62.45.136.136) (Ping timeout: 269 seconds) |