Newest at the top
| 2025-12-01 02:55:44 +0100 | <glguy> | Have you seen this already? https://ghc.gitlab.haskell.org/ghc/doc/users_guide/profiling.html |
| 2025-12-01 02:55:01 +0100 | <Guest62> | I'm profiling my haskell functions (pitting them against each other to compare their memory usages). Could someone help me understand how profiling works? I have basically never done this before. |
| 2025-12-01 02:54:18 +0100 | Guest62 | (~Guest62@38.49.92.193) |
| 2025-12-01 02:53:45 +0100 | Pozyomka | (~pyon@user/pyon) (Read error: Connection reset by peer) |
| 2025-12-01 02:52:03 +0100 | <monochrom> | I hadn't thought of it that way until I read both a Turing biography (so there was his team using CRTs and mercury tubes for early computers) and Harper's PFPL in which he pointed out "state comes from self-reference" and exemplified with using recursion to make an RS latch. |
| 2025-12-01 02:51:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-01 02:50:25 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) (Ping timeout: 264 seconds) |
| 2025-12-01 02:45:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-01 02:45:08 +0100 | <monochrom> | (More precisely, there must also be a non-zero time delay between sending output and reading back input. Today, you use logic gates to make flip flops, same difference.) |
| 2025-12-01 02:43:59 +0100 | <monochrom> | (The two popular choices were mercury tube and CRT.) |
| 2025-12-01 02:43:30 +0100 | <monochrom> | (In general, any output device combined with a sensor could be memory: To store 1, output 1 and have the sensor read back that 1, repeat.) |
| 2025-12-01 02:43:30 +0100 | <glguy> | HE SAID: "THE MOST BONKERS WAS WHEN... |
| 2025-12-01 02:43:03 +0100 | <haskellbridge> | <iqubic (she/her)> WHAT?!?!?! |
| 2025-12-01 02:41:59 +0100 | <monochrom> | The most bonkers was when CRT was memory rather than display. >:) |
| 2025-12-01 02:35:55 +0100 | <geekosaur> | degaussing my monitor every month was fun |
| 2025-12-01 02:35:44 +0100 | <geekosaur> | some of us were still using them in the early 2000s |
| 2025-12-01 02:34:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-01 02:30:30 +0100 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2025-12-01 02:30:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-01 02:24:12 +0100 | omidmash3 | omidmash |
| 2025-12-01 02:24:12 +0100 | omidmash | (~omidmash@user/omidmash) (Ping timeout: 244 seconds) |
| 2025-12-01 02:22:08 +0100 | omidmash3 | (~omidmash@user/omidmash) omidmash |
| 2025-12-01 02:19:49 +0100 | <EvanR> | the 1950s when you had like cathode ray tubes and such |
| 2025-12-01 02:19:10 +0100 | <EvanR> | lol |
| 2025-12-01 02:19:10 +0100 | Pozyomka | (~pyon@user/pyon) pyon |
| 2025-12-01 02:18:57 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: brb) |
| 2025-12-01 02:18:55 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 240 seconds) |
| 2025-12-01 02:16:56 +0100 | sindu | (~sindu@2.148.32.207.tmi.telenormobil.no) (Ping timeout: 240 seconds) |
| 2025-12-01 02:14:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-01 02:12:47 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2025-12-01 02:12:07 +0100 | trickard_ | (~trickard@cpe-85-98-47-163.wireline.com.au) |
| 2025-12-01 02:11:53 +0100 | trickard | (~trickard@cpe-85-98-47-163.wireline.com.au) (Read error: Connection reset by peer) |
| 2025-12-01 02:10:27 +0100 | <haskellbridge> | <zoil> monochrom: you cat get back to talking about the 1950's now |
| 2025-12-01 02:05:04 +0100 | <haskellbridge> | <zoil> _le sigh_ |
| 2025-12-01 02:05:00 +0100 | <haskellbridge> | <zoil> so anyway, possibly singlestons help but in a way that ill probably never understand |
| 2025-12-01 02:04:44 +0100 | <haskellbridge> | <zoil> i have to go actually |
| 2025-12-01 02:03:32 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
| 2025-12-01 02:01:31 +0100 | <haskellbridge> | <zoil> https://paste.tomsmeding.com/gHFMMx2t |
| 2025-12-01 02:01:12 +0100 | peterbecich | (~Thunderbi@172.222.148.214) peterbecich |
| 2025-12-01 02:01:00 +0100 | X-Scale | (~ARM@6.67.114.89.rev.vodafone.pt) X-Scale |
| 2025-12-01 02:00:32 +0100 | <haskellbridge> | <zoil> maybe it would be worth trying the length version, thats really common |
| 2025-12-01 01:59:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-12-01 01:58:04 +0100 | <haskellbridge> | <zoil> like, the stateful constraints make sense, but the length constraint is just garbage |
| 2025-12-01 01:57:50 +0100 | <haskellbridge> | <zoil> id rather just be able to read off constraints that arent insane |
| 2025-12-01 01:57:15 +0100 | <haskellbridge> | <zoil> https://kf8nh.com/_heisenbridge/media/matrix.org/hTIHFOzGuFAqswyfkLuIVoBL/yfXyRcmB1_8/image.png |
| 2025-12-01 01:56:49 +0100 | <glguy> | and a mess of complicated error messages and special utility functions to manage it all |
| 2025-12-01 01:56:37 +0100 | <haskellbridge> | <zoil> basically, anything that requires more than one instance, like some kind of recusion matching on the tail or something, and then im in constraints hell |
| 2025-12-01 01:56:28 +0100 | <glguy> | this route leads to brittle programs that are hard to update and refactor |
| 2025-12-01 01:56:07 +0100 | <haskellbridge> | <zoil> id rather do it right at the onset, than have these constraints following me around |
| 2025-12-01 01:55:51 +0100 | <haskellbridge> | <zoil> possible* |
