Newest at the top
2025-04-24 13:05:46 +0200 | kmein | (~weechat@user/kmein) kmein |
2025-04-24 13:03:41 +0200 | kmein | (~weechat@user/kmein) (Quit: ciao kakao) |
2025-04-24 13:02:11 +0200 | caconym | (~caconym@user/caconym) caconym |
2025-04-24 13:02:01 +0200 | jespada | (~jespada@r190-133-28-49.dialup.adsl.anteldata.net.uy) jespada |
2025-04-24 13:01:06 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f80ed65b51df1ecdd42.dip0.t-ipconnect.de) acidjnk |
2025-04-24 13:00:04 +0200 | caconym | (~caconym@user/caconym) (Quit: bye) |
2025-04-24 12:59:01 +0200 | xff0x | (~xff0x@2405:6580:b080:900:9b42:d2bd:373e:abf7) |
2025-04-24 12:53:34 +0200 | __monty__ | (~toonn@user/toonn) toonn |
2025-04-24 12:32:29 +0200 | mari-estel | (~mari-este@user/mari-estel) (Ping timeout: 245 seconds) |
2025-04-24 12:30:20 +0200 | mari82815 | (~mari-este@user/mari-estel) mari-estel |
2025-04-24 12:21:30 +0200 | sand-witch | (~m-mzmz6l@vmi833741.contaboserver.net) |
2025-04-24 12:20:41 +0200 | sand-witch | (~m-mzmz6l@vmi833741.contaboserver.net) (Remote host closed the connection) |
2025-04-24 12:15:49 +0200 | acidjnk_new | (~acidjnk@p200300d6e71c4f80ed65b51df1ecdd42.dip0.t-ipconnect.de) (Ping timeout: 245 seconds) |
2025-04-24 12:11:10 +0200 | sus0 | (zero@user/zeromomentum) zeromomentum |
2025-04-24 12:09:45 +0200 | end | (~end@user/end/x-0094621) end^ |
2025-04-24 12:08:32 +0200 | fp | (~Thunderbi@2001:708:150:10::1d80) fp |
2025-04-24 11:58:27 +0200 | bcksl | (~bcksl@user/bcksl) bcksl |
2025-04-24 11:54:40 +0200 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds) |
2025-04-24 11:42:45 +0200 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 276 seconds) |
2025-04-24 11:41:24 +0200 | j1n37- | (~j1n37@user/j1n37) j1n37 |
2025-04-24 11:37:44 +0200 | jacopovalanzano | (~jacopoval@cpc151911-cove17-2-0-cust105.3-1.cable.virginm.net) |
2025-04-24 11:35:06 +0200 | jcarpenter2 | (~lol@96.78.87.197) |
2025-04-24 11:33:33 +0200 | jcarpenter2 | (~lol@96.78.87.197) (Ping timeout: 244 seconds) |
2025-04-24 11:28:01 +0200 | sus0 | (zero@user/zeromomentum) (Ping timeout: 252 seconds) |
2025-04-24 11:27:34 +0200 | end | (~end@user/end/x-0094621) (Ping timeout: 260 seconds) |
2025-04-24 11:27:10 +0200 | bcksl | (~bcksl@user/bcksl) (Ping timeout: 260 seconds) |
2025-04-24 11:11:05 +0200 | <haskellbridge> | <Liamzee> https://hackage.haskell.org/package/resourcet |
2025-04-24 11:11:03 +0200 | <haskellbridge> | <Liamzee> and that idea essentially points to ResourceT |
2025-04-24 11:10:25 +0200 | <tomsmeding> | it depends on whether the operations you want to perform on that resource are anything like those that are natural on a mutable reference |
2025-04-24 11:09:49 +0200 | <haskellbridge> | <Liamzee> beyond, say, the base case of shared memory, does representing network, database, or even file resources as a reference have any advantages at all? |
2025-04-24 11:09:18 +0200 | <haskellbridge> | <Liamzee> like, fooRef implies an immutable pointer to a mutable object |
2025-04-24 11:08:44 +0200 | <haskellbridge> | <Liamzee> i'm actually wondering if PGRef would offer any advantages over existing systems |
2025-04-24 11:04:18 +0200 | chele | (~chele@user/chele) chele |
2025-04-24 11:03:59 +0200 | dhil | (~dhil@5.151.29.137) dhil |
2025-04-24 11:03:20 +0200 | <tomsmeding> | I'm not sure how that would be more natural using something like a PGRef |
2025-04-24 11:03:06 +0200 | <tomsmeding> | Liamzee: core to the API of databases is queries spanning multiple tables and transactions spanning multiple queries |
2025-04-24 11:02:54 +0200 | alecs | (~alecs@nat16.software.imdea.org) (Ping timeout: 240 seconds) |
2025-04-24 11:00:39 +0200 | <mari-estel> | main drawback i can think of, you lose abstraction over the database engine |
2025-04-24 10:59:28 +0200 | <haskellbridge> | <Liamzee> i'm just wondering if PGRef would be a better way to do it than existing systems |
2025-04-24 10:59:11 +0200 | <haskellbridge> | <Liamzee> i am |
2025-04-24 10:57:49 +0200 | <mari-estel> | are you not using a library Liamzee? |
2025-04-24 10:56:29 +0200 | <haskellbridge> | <Liamzee> I mean, afaik, the ecosystem around postgres is relatively mature, but is there a benefit to having a PGRef type? |
2025-04-24 10:55:53 +0200 | <haskellbridge> | <Liamzee> that's to say, a Postgres table is described as an immutable reference to a mutable Postgres table in some database |
2025-04-24 10:55:10 +0200 | <haskellbridge> | <Liamzee> what are the pros and cons of having a PGRef type? Wherein PG refers to Postgres? |
2025-04-24 10:48:01 +0200 | todi | (~todi@p57803331.dip0.t-ipconnect.de) todi |
2025-04-24 10:45:24 +0200 | zmt01 | (~zmt00@user/zmt00) (Ping timeout: 245 seconds) |
2025-04-24 10:42:15 +0200 | swamp_ | (~zmt00@user/zmt00) zmt00 |
2025-04-24 10:40:06 +0200 | econo_ | (uid147250@id-147250.tinside.irccloud.com) (Quit: Connection closed for inactivity) |
2025-04-24 10:37:21 +0200 | Square2 | (~Square4@user/square) Square |
2025-04-24 10:34:39 +0200 | fp | (~Thunderbi@wireless-86-50-140-117.open.aalto.fi) (Ping timeout: 244 seconds) |