Newest at the top
2025-03-05 23:44:23 +0100 | Googulator | (~Googulato@2a01-036d-0106-14b2-c443-5a96-b49d-1dd5.pool6.digikabel.hu) |
2025-03-05 23:44:09 +0100 | Googulator | (~Googulato@2a01-036d-0106-14b2-c443-5a96-b49d-1dd5.pool6.digikabel.hu) (Client Quit) |
2025-03-05 23:43:06 +0100 | <monochrom> | Eventually, my solution was to write a short Makefile (or even, short shell script). |
2025-03-05 23:42:14 +0100 | <monochrom> | Actually it was more like "gcc main.c -o main.c', the 2nd ".c" was because tab-completion. |
2025-03-05 23:41:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-03-05 23:41:30 +0100 | <monochrom> | I made the 'gcc -o main.c' mistake once. |
2025-03-05 23:40:14 +0100 | Googulator | (~Googulato@2a01-036d-0106-14b2-c443-5a96-b49d-1dd5.pool6.digikabel.hu) |
2025-03-05 23:39:59 +0100 | Googulator | (~Googulato@2a01-036d-0106-14b2-c443-5a96-b49d-1dd5.pool6.digikabel.hu) (Quit: Client closed) |
2025-03-05 23:31:41 +0100 | chewybread | (~chewybrea@user/chewybread) chewybread |
2025-03-05 23:30:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-03-05 23:30:33 +0100 | <haskellbridge> | <Bowuigi> Implementation-wise it makes sense. Most of those are defined in terms of each other, so it's just abstracting boilerplate |
2025-03-05 23:29:19 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
2025-03-05 23:28:46 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 252 seconds) |
2025-03-05 23:27:05 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
2025-03-05 23:26:42 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Quit: leaving) |
2025-03-05 23:26:23 +0100 | Pozyomka | (~pyon@user/pyon) (Quit: WeeChat 4.5.2) |
2025-03-05 23:24:41 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-03-05 23:24:10 +0100 | visilii | (~visilii@213.24.126.217) (Ping timeout: 265 seconds) |
2025-03-05 23:23:47 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-03-05 23:20:29 +0100 | visilii_ | (~visilii@85.172.77.105) |
2025-03-05 23:19:56 +0100 | fp | (~Thunderbi@89-27-29-68.bb.dnainternet.fi) fp |
2025-03-05 23:15:43 +0100 | mange | (~user@user/mange) mange |
2025-03-05 23:14:08 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 245 seconds) |
2025-03-05 23:13:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-03-05 23:11:49 +0100 | <haskellbridge> | <sm> he probably thought separate main functions for separate use cases was easier to use |
2025-03-05 23:10:48 +0100 | <haskellbridge> | <sm> generally I think haskell frameworks use sum types plenty |
2025-03-05 23:10:06 +0100 | <haskellbridge> | <sm> https://hackage.haskell.org/package/brick-2.8.2/docs/Brick-Main.html#v:defaultMain and friends eh |
2025-03-05 23:09:40 +0100 | <haskellbridge> | <Liamzee> probably my mistake, just thinking about it as a design space |
2025-03-05 23:08:25 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-03-05 23:07:34 +0100 | <haskellbridge> | <Liamzee> erm, App type API |
2025-03-05 23:07:23 +0100 | <haskellbridge> | <Liamzee> erm, multiple ways to call into brick, alterantive is to have one way, but have the variation be contained in the App API |
2025-03-05 23:06:48 +0100 | <haskellbridge> | <Liamzee> there are multiple default mains |
2025-03-05 23:06:06 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
2025-03-05 23:05:37 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) (Remote host closed the connection) |
2025-03-05 23:04:24 +0100 | jespada | (~jespada@r186-48-57-94.dialup.adsl.anteldata.net.uy) (Client Quit) |
2025-03-05 23:04:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-03-05 23:03:28 +0100 | jespada | (~jespada@r186-48-57-94.dialup.adsl.anteldata.net.uy) jespada |
2025-03-05 23:00:28 +0100 | <haskellbridge> | <sm> Liamzee which Brick api could have used a sum type ? |
2025-03-05 22:59:36 +0100 | <haskellbridge> | <Liamzee> tbh at the very least, it'd create an issue with record field exceptions, unfortunately :( |
2025-03-05 22:59:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-03-05 22:58:34 +0100 | <haskellbridge> | <Liamzee> I'm looking at Brick, the interface could have been smoothed out by using a sum type with variants, possibly wrapping subtypes |
2025-03-05 22:57:51 +0100 | <haskellbridge> | <Liamzee> also, just curious, why don't Haskellers building frameworks use sum types more? |
2025-03-05 22:57:40 +0100 | <haskellbridge> | <Liamzee> or rather it was an issue requiring cabal clean, sigh |
2025-03-05 22:53:54 +0100 | <mauke> | worse is when you intend to use -o, but forget the argument: gcc -o *.c |
2025-03-05 22:53:18 +0100 | ljdarj1 | ljdarj |
2025-03-05 22:53:18 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 245 seconds) |
2025-03-05 22:50:48 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
2025-03-05 22:48:23 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-03-05 22:47:42 +0100 | jmcantrell | (~weechat@user/jmcantrell) jmcantrell |
2025-03-05 22:44:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |