2025-02-19 00:00:39 +0100 | mange | (~user@user/mange) mange |
2025-02-19 00:03:48 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
2025-02-19 00:04:11 +0100 | weary-traveler | (~user@user/user363627) user363627 |
2025-02-19 00:05:38 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 00:09:42 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
2025-02-19 00:12:04 +0100 | ljdarj1 | (~Thunderbi@user/ljdarj) ljdarj |
2025-02-19 00:12:26 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-02-19 00:16:11 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 265 seconds) |
2025-02-19 00:16:12 +0100 | ljdarj1 | ljdarj |
2025-02-19 00:17:26 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 00:22:02 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
2025-02-19 00:23:41 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 00:27:00 +0100 | remexre | (~remexre@user/remexre) remexre |
2025-02-19 00:30:23 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
2025-02-19 00:31:19 +0100 | remexre | (~remexre@user/remexre) (Ping timeout: 260 seconds) |
2025-02-19 00:40:19 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
2025-02-19 00:40:41 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) stiell |
2025-02-19 00:40:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 00:45:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-02-19 00:49:22 +0100 | remexre | (~remexre@user/remexre) remexre |
2025-02-19 00:52:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 00:54:03 +0100 | Googulator | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Quit: Client closed) |
2025-02-19 00:54:26 +0100 | Googulator | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) |
2025-02-19 00:56:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-02-19 01:03:29 +0100 | ec | (~ec@gateway/tor-sasl/ec) ec |
2025-02-19 01:05:11 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 01:07:24 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 01:09:32 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) ec |
2025-02-19 01:10:10 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
2025-02-19 01:12:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
2025-02-19 01:12:12 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 264 seconds) |
2025-02-19 01:18:24 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) (Ping timeout: 260 seconds) |
2025-02-19 01:19:24 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 264 seconds) |
2025-02-19 01:22:12 +0100 | ec | (~ec@gateway/tor-sasl/ec) ec |
2025-02-19 01:22:47 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 01:27:01 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-02-19 01:27:53 +0100 | forell | (~forell@user/forell) (Ping timeout: 245 seconds) |
2025-02-19 01:29:00 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 264 seconds) |
2025-02-19 01:29:41 +0100 | L29Ah | (~L29Ah@wikipedia/L29Ah) L29Ah |
2025-02-19 01:30:31 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
2025-02-19 01:30:58 +0100 | ec | (~ec@gateway/tor-sasl/ec) ec |
2025-02-19 01:34:11 +0100 | yegorc | (~yegorc@user/yegorc) yegorc |
2025-02-19 01:38:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 01:38:47 +0100 | tremon | (~tremon@83.80.159.219) (Quit: getting boxed in) |
2025-02-19 01:38:56 +0100 | sprotte24 | (~sprotte24@p200300d16f0680009d71da3872d3d25e.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
2025-02-19 01:41:21 +0100 | acidjnk | (~acidjnk@p200300d6e7283f20718e6a656831e8a3.dip0.t-ipconnect.de) (Ping timeout: 248 seconds) |
2025-02-19 01:42:53 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 245 seconds) |
2025-02-19 01:47:27 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) ec |
2025-02-19 01:47:36 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Ping timeout: 264 seconds) |
2025-02-19 01:52:36 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 01:53:42 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 01:54:03 +0100 | ec | (~ec@gateway/tor-sasl/ec) ec |
2025-02-19 01:54:48 +0100 | ec_ | (~ec@gateway/tor-sasl/ec) (Ping timeout: 264 seconds) |
2025-02-19 01:56:56 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
2025-02-19 01:58:56 +0100 | Eoco | (~ian@128.101.131.218) (Ping timeout: 272 seconds) |
2025-02-19 02:00:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-02-19 02:02:35 +0100 | j1n37- | (~j1n37@user/j1n37) j1n37 |
2025-02-19 02:02:54 +0100 | Googulator13 | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) |
2025-02-19 02:03:19 +0100 | xff0x | (~xff0x@2405:6580:b080:900:4548:6ab4:269:a170) (Ping timeout: 260 seconds) |
2025-02-19 02:04:04 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 260 seconds) |
2025-02-19 02:06:40 +0100 | Googulator | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Ping timeout: 240 seconds) |
2025-02-19 02:07:50 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) (Remote host closed the connection) |
2025-02-19 02:07:50 +0100 | Eoco | (~ian@128.101.131.218) Eoco |
2025-02-19 02:08:34 +0100 | stiell | (~stiell@gateway/tor-sasl/stiell) stiell |
2025-02-19 02:11:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 02:13:22 +0100 | Eoco | (~ian@128.101.131.218) (Ping timeout: 268 seconds) |
2025-02-19 02:16:40 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
2025-02-19 02:19:41 +0100 | hattckory | (~hattckory@67.71.152.102) (Read error: Connection reset by peer) |
2025-02-19 02:19:56 +0100 | hattckory | (~hattckory@149.102.242.103) |
2025-02-19 02:23:51 +0100 | ezzieyguywuf | (~Unknown@user/ezzieyguywuf) ezzieyguywuf |
2025-02-19 02:27:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 02:27:36 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 02:31:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-02-19 02:32:13 +0100 | califax | (~califax@user/califx) (Remote host closed the connection) |
2025-02-19 02:33:27 +0100 | califax | (~califax@user/califx) califx |
2025-02-19 02:34:08 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 245 seconds) |
2025-02-19 02:35:10 +0100 | zungi | (~tory@user/andrewchawk) andrewchawk |
2025-02-19 02:35:25 +0100 | bilegeek | (~bilegeek@2600:1008:b0a4:c6d5:66f:6873:2abc:50c5) (Quit: Leaving) |
2025-02-19 02:38:46 +0100 | bilegeek | (~bilegeek@2600:1008:b0a4:c6d5:66f:6873:2abc:50c5) bilegeek |
2025-02-19 02:41:36 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Ping timeout: 264 seconds) |
2025-02-19 02:42:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 02:45:00 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 02:46:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-02-19 02:49:22 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
2025-02-19 02:52:53 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
2025-02-19 02:54:08 +0100 | Googulator13 | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Quit: Client closed) |
2025-02-19 02:54:25 +0100 | Googulator13 | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) |
2025-02-19 02:55:34 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) |
2025-02-19 02:57:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 02:59:58 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) (Ping timeout: 245 seconds) |
2025-02-19 03:00:45 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 244 seconds) |
2025-02-19 03:02:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-02-19 03:03:01 +0100 | Square | (~Square@user/square) (Ping timeout: 248 seconds) |
2025-02-19 03:10:52 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.) |
2025-02-19 03:13:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 03:19:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-02-19 03:30:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 03:33:04 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 03:34:34 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
2025-02-19 03:36:41 +0100 | weary-traveler | (~user@user/user363627) user363627 |
2025-02-19 03:37:14 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
2025-02-19 03:37:51 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
2025-02-19 03:48:04 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 03:52:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
2025-02-19 03:57:39 +0100 | vanishingideal | (~vanishing@user/vanishingideal) (Ping timeout: 260 seconds) |
2025-02-19 03:59:03 +0100 | vanishingideal | (~vanishing@user/vanishingideal) vanishingideal |
2025-02-19 04:03:28 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 04:03:47 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 244 seconds) |
2025-02-19 04:07:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-02-19 04:10:02 +0100 | byorgey | (~byorgey@user/byorgey) (Ping timeout: 252 seconds) |
2025-02-19 04:10:20 +0100 | byorgey | (~byorgey@user/byorgey) byorgey |
2025-02-19 04:18:49 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 04:20:49 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 04:23:58 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
2025-02-19 04:25:20 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 268 seconds) |
2025-02-19 04:28:46 +0100 | <simon1> | I want to make a function that yields a deterministically shuffled list. So I'm trying to use this signature `RandomGen gen => [a] -> gen -> IO [a]`, but when try to use the function `next` I get the warning `Deprecated: "No longer used"`. What replaces `next` and `RandomGen` then? |
2025-02-19 04:28:51 +0100 | simon1 | sim590 |
2025-02-19 04:32:34 +0100 | <geekosaur> | RandomGen is still used, but next has been deprecated since random-1.1. https://hackage.haskell.org/package/random-1.3.0/docs/System-Random.html#v:next explains and provides references and alternatives |
2025-02-19 04:32:35 +0100 | <sim590> | Ah. I guess I wanna use `random` instead. |
2025-02-19 04:32:43 +0100 | <sim590> | Right? |
2025-02-19 04:33:53 +0100 | <geekosaur> | you should use an operation specialized for your target type (next always converted to/from Integer) |
2025-02-19 04:34:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 04:34:19 +0100 | <sim590> | I mean the function `random` as in `random :: RandomGen gen => gen -> (a, gen)` ? |
2025-02-19 04:34:38 +0100 | <sim590> | Instead of using `next`. |
2025-02-19 04:34:45 +0100 | <monochrom> | For shuffling, use randomR for Int. |
2025-02-19 04:35:21 +0100 | <monochrom> | or even randomRs if your gen won't be used elsewhere. |
2025-02-19 04:35:47 +0100 | <monochrom> | On a different note, given gen, I don't see why you still need IO. |
2025-02-19 04:36:35 +0100 | <sim590> | monochrom: actually, I'm writing a network application. All nodes have the same seed and they have to generate a random state from that seed. So I need to initialize a generator with the same seed on all nodes. |
2025-02-19 04:37:18 +0100 | <monochrom> | Huh that comes across as https://xkcd.com/221/ |
2025-02-19 04:39:08 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
2025-02-19 04:42:42 +0100 | <sim590> | ? All my nodes are gonna have a list of elements and they need to generate the same shuffled list. This is because my application is a game where every node has been given the player list, but now we have to know which player starts first, so then I shuffle the list according to a hexdigit code. Yes, this is not "random", but that is not what I need. I need a deterministicly shuffled list. |
2025-02-19 04:44:13 +0100 | <monochrom> | Is there anything wrong with generating the list just once and passing it to all nodes? |
2025-02-19 04:44:51 +0100 | <monochrom> | But either version still doesn't need IO. |
2025-02-19 04:46:30 +0100 | <sim590> | No, I don't need IO, it's true. I actually just generalized my code to something that doesn't need IO, but my first iteration did need IO because the function I evolved from did actual randomness for shuffling. But, now I don't. It's becasue I'm evolving the code of the game from single player to multiplayer now. |
2025-02-19 04:48:45 +0100 | <monochrom> | Even for actual PRNG I would still go for either gen -> ([a], gen) or gen -> [a] or the new-fangled StatefulGen monads, and avoid committing to IO. |
2025-02-19 04:49:35 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 04:52:37 +0100 | <monochrom> | Actually I ended up using s/StatefulGen/RandomGenM/ because it has nicer functions eg randomRM. |
2025-02-19 04:52:49 +0100 | <sim590> | as for shuffling the list before sending it over, yes, it's true I could do that. But, since every node already have the seed from the start (the game code given by the user), I prefer just sorting the list first, then shuffling it according to the code because then other nodes don't rely on the host so much. They can generate this themselves. There is no server. It's all taking place ontop of a |
2025-02-19 04:52:51 +0100 | <sim590> | distributed hash table. |
2025-02-19 04:53:56 +0100 | yegorc | (~yegorc@user/yegorc) (Leaving) |
2025-02-19 04:54:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-02-19 04:57:11 +0100 | <jackdk> | What are your plans for when a new node comes online and needs to acquire the same random state, or if there is a bug in your code and nodes call a randomisation function a different number of times or use the results in a different order? |
2025-02-19 04:58:11 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 04:59:15 +0100 | <monochrom> | I don't normally worry about a bug that affects one node but not others. All nodes run the same code because programmers are too lazy to write two versions. Therefore all nodes run the same bug anyway. |
2025-02-19 05:00:49 +0100 | <monochrom> | BTW it's also why our university discourages anyone except the top authority from talking about exam timetables and venues. Because if there is to be a mistake, it is better for everyone to make the same mistake (sourced from one single source) than inconsistency hell. |
2025-02-19 05:01:18 +0100 | <jackdk> | How do you update things to a new version without downtime? |
2025-02-19 05:01:45 +0100 | <monochrom> | Perhaps don't make new versions? >:) |
2025-02-19 05:01:56 +0100 | tavare | (~tavare@user/tavare) tavare |
2025-02-19 05:02:00 +0100 | <jackdk> | Perfect. |
2025-02-19 05:02:28 +0100 | <monochrom> | The serious and honest answer is I don't know. |
2025-02-19 05:02:29 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 248 seconds) |
2025-02-19 05:04:18 +0100 | <monochrom> | The aternative is to accept that you now have the Byzantine Generals problem and you still taking distributed algorithms seriously, i.e., there is a voting system, there is cryptographical hashes, there is a Lamport partially-ordered clock system, ... |
2025-02-19 05:04:35 +0100 | <monochrom> | s/still/start/ |
2025-02-19 05:04:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 05:06:09 +0100 | <monochrom> | or in other words, if there is going to be a non-shared bug, then both "send a seed" and "send a list" are vulnerable to their respective non-shared bugs, e.g., "what if one node has a bug that uses the list wrongly?" |
2025-02-19 05:06:12 +0100 | <sim590> | jackdk: there's a connection stage where we wait for everyone before the game starts. The list is not gonna be shuffled before we end that stage and everybody is connected (i.e. the "host" knows about them). |
2025-02-19 05:07:00 +0100 | <sim590> | Yeah, and for now I assume that every nodes run the same code of course. |
2025-02-19 05:07:03 +0100 | <jackdk> | And then you're doing synchronous lockstep simulation across nodes? |
2025-02-19 05:07:41 +0100 | <jackdk> | s/across nodes/across all nodes at once/ |
2025-02-19 05:07:54 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 05:09:47 +0100 | <sim590> | The game code is going to be the initial seed for everything. Everyone is gonna have that seed. The game is a turn base game so every player will just be able to repeat the exact same operations by listening to packets containing the player's turn info. It will be some data that modifies the state. They use that packet to update they're state. Every player turn is going to also change the current |
2025-02-19 05:09:49 +0100 | <sim590> | "seed" identifying where players are in the chain of turns. |
2025-02-19 05:10:06 +0100 | <monochrom> | I'm OK with "the list is 5GB so sending a 32-bit seed over the network is better". |
2025-02-19 05:10:45 +0100 | <monochrom> | But if it is "this is a legacy system, that's why" then it's just sad. |
2025-02-19 05:12:02 +0100 | <monochrom> | Well, I still find joy in it with https://www.vex.net/~trebla/humour/pessimisms.html #2. Gotta make the best of what you have. |
2025-02-19 05:12:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
2025-02-19 05:12:22 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
2025-02-19 05:13:22 +0100 | <sim590> | Regarding the byzantine general problem, I don't think that this applies for me because this game is turn based, so there's no concurrency issues. |
2025-02-19 05:13:40 +0100 | <sim590> | Everybody is going to evolve at the same rate waiting for the player to make his turn. |
2025-02-19 05:13:51 +0100 | <sim590> | current* player |
2025-02-19 05:18:23 +0100 | <jackdk> | I am curious as to why you need a DHT - this sounds like a small enough network where DHTs would mostly be useful as an exercise. |
2025-02-19 05:18:56 +0100 | <monochrom> | Speaking of which, the distributed algorithm course I took was taught by two profs together, one from Greece, another of Egyptian ethnicity (like, he is a French citizen but his parent came from Egypt). |
2025-02-19 05:18:57 +0100 | <sim590> | I don't "need" a DHT. I just wanna make a multiplayer code without making server code. |
2025-02-19 05:19:14 +0100 | <sim590> | multiplayer game* |
2025-02-19 05:19:22 +0100 | <monochrom> | It took 5 years to dawn on me "wait, Byzantine generals you say? and two of them?" |
2025-02-19 05:20:04 +0100 | <sim590> | hmmmm :) |
2025-02-19 05:20:09 +0100 | <jackdk> | sim590: Yeah that's fair. I'd just look at making the gamestate a left fold of events, some of which are generated by other players. And then you can hold the same state at each node |
2025-02-19 05:22:10 +0100 | sim590 | (~simon@209-15-185-101.resi.cgocable.ca) (WeeChat 4.5.1) |
2025-02-19 05:22:22 +0100 | sim590 | (~simon@209-15-185-101.resi.cgocable.ca) sim590 |
2025-02-19 05:23:00 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 05:24:34 +0100 | <sim590> | jackdk: also I did help develop the DHT over here: https://github.com/savoirfairelinux/opendht/ during 2015-2017. So I've become quite familiar with Kademlia and quite found of it also. When I decided to make a game and also think about making it multiplayer, that is the first thing I thought about doing. But I like Haskell and OpenDHT is in C++, so I had to write the bindings! |
2025-02-19 05:24:36 +0100 | <sim590> | https://github.com/sim590/opendht-hs/. All of that was a fun experience, so that's pretty much because of all these reasons. |
2025-02-19 05:24:54 +0100 | <jackdk> | Having fun is a pretty good reason |
2025-02-19 05:24:58 +0100 | <sim590> | Yup |
2025-02-19 05:25:08 +0100 | <jackdk> | sim590: https://github.com/ESWAT/john-carmack-plan-archive/blob/master/by_day/johnc_plan_19981014.txt Carmack doesn't use these words, but it really sounds like he made the state a strict left fold over an event stream. |
2025-02-19 05:26:08 +0100 | <sim590> | I've made this nice project also in the past: https://github.com/sim590/dpaste/. A pastebin running on the DHT (IRC folks should like that). I still have to work on it because I need to expand the file limit size by spreading the values in multiple packets. I'll do that after I finish my game I guess or when I feel like id... :-) |
2025-02-19 05:27:30 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-02-19 05:29:08 +0100 | <sim590> | jackdk: Hmmmmm.... Who's Carmack ?? |
2025-02-19 05:30:27 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 05:30:46 +0100 | aforemny_ | (~aforemny@2001:9e8:6ce5:a900:aaac:d53d:16e5:71d8) aforemny |
2025-02-19 05:31:13 +0100 | <jackdk> | wrote Commander Keen, Wolf3D, Doom, Quake, etc. |
2025-02-19 05:31:41 +0100 | <sim590> | Oh. I see. A big name in gaming. |
2025-02-19 05:32:18 +0100 | <sim590> | Oh I think I just got what you hinted at with the folding thing. Was that a joke about the lines not being folded in his file? lol |
2025-02-19 05:32:22 +0100 | aforemny | (~aforemny@i59F4C483.versanet.de) (Ping timeout: 272 seconds) |
2025-02-19 05:33:22 +0100 | <monochrom> | Oh haha the irony. |
2025-02-19 05:34:33 +0100 | <jackdk> | No, as in it sounds like he got a lot of portability and other architectural benefits from building Q3 around (morally) a function `State -> Event -> State` and having all the event sources produce onto a queue that is consumed by the game engine, a lot like the `Data.List.foldl'` function. |
2025-02-19 05:34:54 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 272 seconds) |
2025-02-19 05:36:14 +0100 | forell | (~forell@user/forell) forell |
2025-02-19 05:38:21 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 05:42:48 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-02-19 05:43:49 +0100 | michalz | (~michalz@185.246.207.203) |
2025-02-19 05:44:22 +0100 | <haskellbridge> | <Liamzee> are there any suggestions on improving this code? It feels hacky, and there's probably too much IO coupling |
2025-02-19 05:44:26 +0100 | <haskellbridge> | <Liamzee> https://paste.tomsmeding.com/gTV1Ck0j |
2025-02-19 05:44:30 +0100 | <sim590> | jackdk:sounds like a logical approach. |
2025-02-19 05:45:56 +0100 | Inst | (~Inst@user/Inst) Inst |
2025-02-19 05:46:05 +0100 | <haskellbridge> | <Liamzee> hmmm |
2025-02-19 05:46:49 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
2025-02-19 05:50:59 +0100 | <sim590> | Liamzee: that is actually funny that you send that piece of code because I'm trying to teach Haskell to someone. And that someone asked me if it would be easy to make the snake game in Haskell... :) |
2025-02-19 05:52:32 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
2025-02-19 05:53:43 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 05:54:19 +0100 | <sim590> | Liamzee: by the way, if you're looking to experiment around with this, you might be interested in Brick https://github.com/jtdaugherty/brick. It is a library that helps making TUIs and it seems like your game is text based. It actually takes care of alot of stuff for you like key press and stuff. |
2025-02-19 05:56:18 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 05:57:28 +0100 | <sim590> | Liamzee, I don't see how you could not use IO wherever you do use it. It seems like everywhere you use it is where you need to handle the screen or user input. That seems fine to me. But, I'm far from being a Haskell guru :) |
2025-02-19 05:58:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-02-19 06:00:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
2025-02-19 06:04:17 +0100 | rvalue | (~rvalue@user/rvalue) (Read error: Connection reset by peer) |
2025-02-19 06:04:48 +0100 | rvalue | (~rvalue@user/rvalue) rvalue |
2025-02-19 06:08:52 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 06:09:07 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 06:13:32 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 272 seconds) |
2025-02-19 06:13:44 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-02-19 06:14:05 +0100 | ephilalethes | (~noumenon@2001:d08:1a00:bc0:aa7e:eaff:fede:ff94) noumenon |
2025-02-19 06:17:59 +0100 | alp | (~alp@2001:861:8ca0:4940:e4d1:8a6d:1936:4535) (Ping timeout: 252 seconds) |
2025-02-19 06:24:31 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 06:28:50 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-02-19 06:39:19 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) (Remote host closed the connection) |
2025-02-19 06:40:28 +0100 | ZLima12 | (~zlima12@user/meow/ZLima12) ZLima12 |
2025-02-19 06:40:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 06:41:50 +0100 | <haskellbridge> | <Liamzee> sim590: Claude, DeepSeek R1 can all produce fairly decent Haskell code that mainly needs stylistic correction for these types of micro-programs. Also, if you're focusing on IO, you need to prioritize concurrency, which is why I'm wondering if the usage of MVar is correct here (IORef would actually provide better functionality for what I'm trying to do). |
2025-02-19 06:43:10 +0100 | <haskellbridge> | <Liamzee> I was originally planning to upgrade to Brick, but I spent two days pushing this out (mainly hamstrung by lack of confidence in concurrency features), so I'm more likely to move to my primary project, which would be a Rust-based API caller for claim verification in social media. |
2025-02-19 06:44:02 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 06:45:56 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 268 seconds) |
2025-02-19 06:48:34 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 260 seconds) |
2025-02-19 06:49:28 +0100 | lisbeths | (uid135845@id-135845.lymington.irccloud.com) lisbeths |
2025-02-19 06:51:25 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
2025-02-19 06:54:09 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) (Remote host closed the connection) |
2025-02-19 06:54:24 +0100 | chexum | (~quassel@gateway/tor-sasl/chexum) chexum |
2025-02-19 06:56:11 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 07:00:47 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-02-19 07:01:43 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Remote host closed the connection) |
2025-02-19 07:01:55 +0100 | Guest52 | (~Guest52@host-64-178-152-151.public.eastlink.ca) |
2025-02-19 07:02:06 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) bitdex |
2025-02-19 07:08:12 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 07:12:34 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
2025-02-19 07:17:50 +0100 | takuan | (~takuan@d8D86B601.access.telenet.be) |
2025-02-19 07:19:28 +0100 | CiaoSen | (~Jura@ip-037-201-240-075.um10.pools.vodafone-ip.de) CiaoSen |
2025-02-19 07:21:12 +0100 | monochrom | (trebla@216.138.220.146) (Quit: ZNC 1.9.1+deb1 - https://znc.in) |
2025-02-19 07:21:53 +0100 | akegalj | (~akegalj@89-172-194-52.adsl.net.t-com.hr) akegalj |
2025-02-19 07:23:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 07:24:58 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 245 seconds) |
2025-02-19 07:27:03 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 07:29:16 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 265 seconds) |
2025-02-19 07:31:07 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 07:35:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 265 seconds) |
2025-02-19 07:38:25 +0100 | monochrom | (trebla@216.138.220.146) |
2025-02-19 07:39:39 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 07:40:52 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 265 seconds) |
2025-02-19 07:44:09 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
2025-02-19 07:49:37 +0100 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) (Remote host closed the connection) |
2025-02-19 07:55:02 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 07:59:02 +0100 | ft | (~ft@p4fc2a610.dip0.t-ipconnect.de) (Quit: leaving) |
2025-02-19 08:01:45 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-02-19 08:09:15 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 08:13:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 252 seconds) |
2025-02-19 08:17:13 +0100 | tccq | (~user@user/tccq) tccq |
2025-02-19 08:18:31 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 08:23:01 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
2025-02-19 08:24:37 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 08:29:17 +0100 | internatetional | (~nate@2001:448a:20a3:c2e5:9ba2:a48e:b934:7d97) internatetional |
2025-02-19 08:32:52 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
2025-02-19 08:41:59 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 08:43:36 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
2025-02-19 08:45:36 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
2025-02-19 08:46:17 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Client Quit) |
2025-02-19 08:46:52 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
2025-02-19 08:47:57 +0100 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 244 seconds) |
2025-02-19 08:50:25 +0100 | alp | (~alp@2001:861:8ca0:4940:d9b9:1143:525c:6490) |
2025-02-19 08:55:19 +0100 | alp | (~alp@2001:861:8ca0:4940:d9b9:1143:525c:6490) (Ping timeout: 260 seconds) |
2025-02-19 08:57:01 +0100 | ec | (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
2025-02-19 08:57:26 +0100 | ec | (~ec@gateway/tor-sasl/ec) ec |
2025-02-19 08:57:27 +0100 | alp | (~alp@2001:861:8ca0:4940:8f29:5e1f:1daa:6400) |
2025-02-19 08:58:10 +0100 | internatetional | (~nate@2001:448a:20a3:c2e5:9ba2:a48e:b934:7d97) (Quit: WeeChat 4.5.1) |
2025-02-19 08:58:57 +0100 | Guest52 | (~Guest52@host-64-178-152-151.public.eastlink.ca) (Quit: Client closed) |
2025-02-19 09:00:00 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
2025-02-19 09:00:12 +0100 | tromp | (~textual@2a02:a210:cba:8500:593d:9801:ba8:3982) |
2025-02-19 09:01:00 +0100 | caconym | (~caconym@user/caconym) caconym |
2025-02-19 09:06:35 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 09:11:30 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
2025-02-19 09:12:02 +0100 | ephilalethes | (~noumenon@2001:d08:1a00:bc0:aa7e:eaff:fede:ff94) (Quit: Leaving) |
2025-02-19 09:16:05 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 265 seconds) |
2025-02-19 09:27:07 +0100 | acidjnk | (~acidjnk@p200300d6e7283f64718e6a656831e8a3.dip0.t-ipconnect.de) acidjnk |
2025-02-19 09:33:59 +0100 | Sgeo | (~Sgeo@user/sgeo) (Read error: Connection reset by peer) |
2025-02-19 09:36:03 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 09:36:13 +0100 | forell | (~forell@user/forell) (Ping timeout: 245 seconds) |
2025-02-19 09:36:33 +0100 | forell | (~forell@user/forell) forell |
2025-02-19 09:36:53 +0100 | sord937 | (~sord937@gateway/tor-sasl/sord937) sord937 |
2025-02-19 09:37:26 +0100 | <Athas> | Is 'ad' the best AD package for Haskell these days? |
2025-02-19 09:37:47 +0100 | <Athas> | (For relatively simple uses.) |
2025-02-19 09:41:13 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 245 seconds) |
2025-02-19 09:41:20 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
2025-02-19 09:46:25 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 09:50:30 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-02-19 09:51:49 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 09:53:17 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 265 seconds) |
2025-02-19 09:54:19 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 09:55:40 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
2025-02-19 09:55:56 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) (Ping timeout: 244 seconds) |
2025-02-19 09:56:04 +0100 | machinedgod | (~machinedg@d108-173-18-100.abhsia.telus.net) machinedgod |
2025-02-19 09:57:22 +0100 | rubin55 | (uid666177@id-666177.lymington.irccloud.com) rubin55 |
2025-02-19 09:58:37 +0100 | rubin55 | (uid666177@id-666177.lymington.irccloud.com) (Client Quit) |
2025-02-19 09:58:44 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
2025-02-19 10:05:21 +0100 | alp | (~alp@2001:861:8ca0:4940:8f29:5e1f:1daa:6400) (Ping timeout: 248 seconds) |
2025-02-19 10:06:58 +0100 | ljdarj | (~Thunderbi@user/ljdarj) (Ping timeout: 268 seconds) |
2025-02-19 10:07:54 +0100 | remedan | (~remedan@ip-62-245-108-153.bb.vodafone.cz) remedan |
2025-02-19 10:10:00 +0100 | AlexNoo_ | (~AlexNoo@178.34.161.111) |
2025-02-19 10:10:21 +0100 | <tomsmeding> | Athas: if you find any better ones, please enlighten me :p |
2025-02-19 10:10:36 +0100 | <tomsmeding> | monochrom: thanks! |
2025-02-19 10:11:12 +0100 | <tomsmeding> | oh you have already sent me this once |
2025-02-19 10:12:09 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 10:12:18 +0100 | AlexZenon | (~alzenon@178.34.150.53) (Ping timeout: 252 seconds) |
2025-02-19 10:13:21 +0100 | AlexNoo | (~AlexNoo@178.34.150.53) (Ping timeout: 248 seconds) |
2025-02-19 10:13:46 +0100 | Digitteknohippie | (~user@user/digit) Digit |
2025-02-19 10:14:52 +0100 | Digit | (~user@user/digit) (Ping timeout: 252 seconds) |
2025-02-19 10:16:37 +0100 | AlexZenon | (~alzenon@178.34.161.111) |
2025-02-19 10:16:42 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 252 seconds) |
2025-02-19 10:22:44 +0100 | j1n37- | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
2025-02-19 10:23:27 +0100 | <tomsmeding> | Athas: if you're okay with writing your code in a TH quote, and various related crappiness-of-API issues, ad-dualrev-th is approximately 2x as fast |
2025-02-19 10:23:42 +0100 | <tomsmeding> | but really, just use Futhark? ;) |
2025-02-19 10:25:21 +0100 | <Athas> | I don't need the objective performance. I just want to contribute a Haskell implementation to gradbench. |
2025-02-19 10:25:30 +0100 | pikajude | (~jude@149.28.207.64) (Ping timeout: 252 seconds) |
2025-02-19 10:25:43 +0100 | <Athas> | 'ad' looks pretty simple. |
2025-02-19 10:25:50 +0100 | pikajude | (~jude@149.28.207.64) pikajude |
2025-02-19 10:26:04 +0100 | <tomsmeding> | it's certainly simple to use and well-established |
2025-02-19 10:26:20 +0100 | <Athas> | What do people use it for in practice? |
2025-02-19 10:26:26 +0100 | <tomsmeding> | not performance |
2025-02-19 10:26:35 +0100 | tremon | (~tremon@83.80.159.219) tremon |
2025-02-19 10:26:42 +0100 | <Athas> | But what kinds of Haskell applications need AD? |
2025-02-19 10:27:20 +0100 | igemnace | (~igemnace@user/igemnace) (Ping timeout: 252 seconds) |
2025-02-19 10:27:23 +0100 | igemnace_ | (~igemnace@user/igemnace) igemnace |
2025-02-19 10:27:41 +0100 | <tomsmeding> | I honestly don't know. I think there's a chicken-egg problem here: there are no good & fast AD tools in Haskell, so if you want to write something that needs such things, you use a different language |
2025-02-19 10:28:34 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-02-19 10:28:58 +0100 | igemnace_ | igemnace |
2025-02-19 10:29:22 +0100 | alp | (~alp@2001:861:8ca0:4940:bb72:dec1:2682:160e) |
2025-02-19 10:31:08 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
2025-02-19 10:32:06 +0100 | <Athas> | 'ad' seems pretty comprehensive, so it must be useful to someone. |
2025-02-19 10:33:04 +0100 | <tomsmeding> | I heard from someone recently that they used it as a placeholder implementation of AD for a probabilistic programming language they were working on, where they cared more about the clever PPL things than actual performance just yet |
2025-02-19 10:33:21 +0100 | eL_Bart0 | (eL_Bart0@dietunichtguten.org) (Ping timeout: 244 seconds) |
2025-02-19 10:35:11 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-02-19 10:35:41 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
2025-02-19 10:35:54 +0100 | __monty__ | (~toonn@user/toonn) toonn |
2025-02-19 10:36:02 +0100 | <tomsmeding> | Athas: why do the eval Dockerfiles install torch? |
2025-02-19 10:36:02 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
2025-02-19 10:36:57 +0100 | <Athas> | Ugh. Because pytorch was until a few hours ago the reference implementation used for validation. |
2025-02-19 10:37:03 +0100 | <Athas> | And I forgot to cleanse the Dockerfiles. |
2025-02-19 10:37:10 +0100 | <tomsmeding> | I suspected so :) |
2025-02-19 10:37:14 +0100 | <tomsmeding> | or something like it |
2025-02-19 10:39:35 +0100 | <tomsmeding> | Athas: this looks cute. If you do add 'ad', a suggestion: get a diff of precisely what was necessary to implement, say, two of the evals with this new tool. (2 instead of 1 to capture what's necessary for a new tool, as well as what's necessary for just a new tool-eval combination.) That will be nice for someone else who wants to contribute a new tool :) |
2025-02-19 10:40:14 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-02-19 10:40:18 +0100 | <Athas> | A 'diff' in what sense? Each eval will be a single Haskell module. |
2025-02-19 10:40:35 +0100 | <tomsmeding> | there's currently no haskell tools in there yet, right? |
2025-02-19 10:40:37 +0100 | <Athas> | It's actually not so difficult; I'm working on it now. I spend more time figuring out how to get Haskell in a Dockerfile than I do actually writing Haskell code. |
2025-02-19 10:40:53 +0100 | <tomsmeding> | it's precisely the Dockerfile stuff that I'm most interested in ;) |
2025-02-19 10:40:56 +0100 | <tomsmeding> | I know how to write haskell too. |
2025-02-19 10:41:34 +0100 | <tomsmeding> | "I want to contribute a Tool to gradbench written in my spiffy language CoolLang; what do I do?" |
2025-02-19 10:41:43 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 10:42:36 +0100 | <Athas> | I'm afraid the difficult part is the ad-hoc trouble of setting up Docker for CoolLang. |
2025-02-19 10:42:54 +0100 | <tomsmeding> | assume I can handle that part :) |
2025-02-19 10:43:00 +0100 | <tomsmeding> | I see that I should probably just read CONTRIBUTING.md |
2025-02-19 10:43:25 +0100 | <tomsmeding> | still, having a single commit that adds a tool is nice as a reference, perhaps |
2025-02-19 10:43:34 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 265 seconds) |
2025-02-19 10:43:34 +0100 | <Athas> | You also have to implement the (JSON-based) protocol for every language. It's really surprisingly easy. |
2025-02-19 10:43:38 +0100 | <Athas> | A lot easier than ADBench. |
2025-02-19 10:43:43 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 10:43:57 +0100 | <tomsmeding> | yeah I think I like the JSON protocol |
2025-02-19 10:44:18 +0100 | <tomsmeding> | from the benchmark names it looks rather like this is intended to be a successor to ADBench, too :) |
2025-02-19 10:45:13 +0100 | <Athas> | Yes. I'm not the one who came up with GradBench, but I have contributed some things. It was a loss when ADBench died. |
2025-02-19 10:45:13 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
2025-02-19 10:46:02 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 252 seconds) |
2025-02-19 10:46:59 +0100 | <Athas> | Oh lovely, there are official Haskell Docker images. |
2025-02-19 10:47:13 +0100 | <Athas> | The cabal-install in the Debian and Ubuntu images was too old. |
2025-02-19 10:48:30 +0100 | <tomsmeding> | to say nothing of the GHC in those images, probably |
2025-02-19 10:49:12 +0100 | kuribas | (~user@ip-188-118-57-242.reverse.destiny.be) kuribas |
2025-02-19 10:50:50 +0100 | <Athas> | I must admit that I find Haskell very enjoyable when you're just putting around reading and writing JSON formats, and doing other simple computer things. |
2025-02-19 10:51:00 +0100 | <Athas> | I spend too much time solving complicated problems with Haskell. |
2025-02-19 10:53:41 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-02-19 10:53:48 +0100 | chele | (~chele@user/chele) chele |
2025-02-19 10:54:26 +0100 | <kuribas> | I find haskell very enjoyable when I am doing simple things in clojure. |
2025-02-19 10:54:27 +0100 | CiaoSen | (~Jura@ip-037-201-240-075.um10.pools.vodafone-ip.de) (Ping timeout: 268 seconds) |
2025-02-19 10:54:32 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) (Quit: zzz) |
2025-02-19 10:56:40 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 252 seconds) |
2025-02-19 11:04:50 +0100 | Inst | (~Inst@user/Inst) Inst |
2025-02-19 11:06:09 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) (Remote host closed the connection) |
2025-02-19 11:06:26 +0100 | tcard | (~tcard@2400:4051:5801:7500:cf17:befc:ff82:5303) tcard |
2025-02-19 11:06:55 +0100 | xff0x | (~xff0x@fsb6a9491c.tkyc517.ap.nuro.jp) (Ping timeout: 252 seconds) |
2025-02-19 11:07:05 +0100 | <Athas> | tomsmeding: since you expressed interest: https://github.com/gradbench/gradbench/pull/272 |
2025-02-19 11:07:12 +0100 | bilegeek | (~bilegeek@2600:1008:b0a4:c6d5:66f:6873:2abc:50c5) (Quit: Leaving) |
2025-02-19 11:07:41 +0100 | <Athas> | I'm wondering if I can adapt your Accelerate implementations into pure Haskell. |
2025-02-19 11:08:34 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-02-19 11:09:14 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
2025-02-19 11:10:17 +0100 | <Inst> | TINO warp/wai, right? |
2025-02-19 11:11:24 +0100 | <Inst> | erm, there's no alternative to wai, specifically? |
2025-02-19 11:12:32 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-02-19 11:13:34 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
2025-02-19 11:14:14 +0100 | <Inst> | snap runs on neither warp nor wai |
2025-02-19 11:17:08 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-02-19 11:17:58 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
2025-02-19 11:19:54 +0100 | <tomsmeding> | Athas: that shouldn't be too difficult, actually |
2025-02-19 11:20:05 +0100 | <tomsmeding> | also, thanks! |
2025-02-19 11:20:25 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 11:21:06 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-02-19 11:21:09 +0100 | <tomsmeding> | Athas: you forgot to update the [futhark] link in the readme |
2025-02-19 11:21:48 +0100 | <Athas> | So I did. Thanks for noticing. |
2025-02-19 11:23:47 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
2025-02-19 11:23:47 +0100 | tnt2 | tnt1 |
2025-02-19 11:26:27 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 11:29:27 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 11:31:27 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 268 seconds) |
2025-02-19 11:32:16 +0100 | drdo | (~drdo@bl9-110-63.dsl.telepac.pt) (Quit: Ping timeout (120 seconds)) |
2025-02-19 11:32:53 +0100 | drdo | (~drdo@bl9-110-63.dsl.telepac.pt) drdo |
2025-02-19 11:33:53 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
2025-02-19 11:34:17 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
2025-02-19 11:35:28 +0100 | Googulator13 | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Quit: Client closed) |
2025-02-19 11:35:52 +0100 | Googulator13 | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) |
2025-02-19 11:38:06 +0100 | Inst | (~Inst@user/Inst) Inst |
2025-02-19 11:38:45 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
2025-02-19 11:42:32 +0100 | j1n37 | (~j1n37@user/j1n37) (Ping timeout: 265 seconds) |
2025-02-19 11:42:55 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-02-19 11:43:16 +0100 | Googulator13 | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Quit: Client closed) |
2025-02-19 11:43:30 +0100 | Googulator13 | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) |
2025-02-19 11:49:57 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-02-19 11:52:09 +0100 | tessier | (~tessier@ec2-184-72-149-67.compute-1.amazonaws.com) (Ping timeout: 246 seconds) |
2025-02-19 11:52:30 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 11:52:36 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
2025-02-19 11:56:38 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 245 seconds) |
2025-02-19 11:56:58 +0100 | Square2 | (~Square4@user/square) Square |
2025-02-19 12:02:38 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 12:04:06 +0100 | tessier | (~tessier@ec2-184-72-149-67.compute-1.amazonaws.com) tessier |
2025-02-19 12:06:44 +0100 | xff0x | (~xff0x@2405:6580:b080:900:4e6:728d:8693:dc86) |
2025-02-19 12:07:34 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 272 seconds) |
2025-02-19 12:08:39 +0100 | lol_ | (~lol@2603:3016:1e01:b9c0:f149:9d53:5672:9d16) |
2025-02-19 12:08:40 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
2025-02-19 12:09:29 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 12:09:58 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 245 seconds) |
2025-02-19 12:09:59 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
2025-02-19 12:09:59 +0100 | tnt2 | tnt1 |
2025-02-19 12:11:52 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-02-19 12:13:30 +0100 | jcarpenter2 | (~lol@2603:3016:1e01:b9c0:dd5c:182b:d497:5a90) (Ping timeout: 276 seconds) |
2025-02-19 12:17:31 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 12:20:09 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 12:22:08 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 272 seconds) |
2025-02-19 12:22:08 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 272 seconds) |
2025-02-19 12:22:48 +0100 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
2025-02-19 12:23:47 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-02-19 12:24:55 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 12:25:18 +0100 | tnt2 | (~Thunderbi@user/tnt1) (Ping timeout: 272 seconds) |
2025-02-19 12:30:34 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 260 seconds) |
2025-02-19 12:33:03 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-02-19 12:37:20 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 12:37:20 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 272 seconds) |
2025-02-19 12:37:20 +0100 | xff0x | (~xff0x@2405:6580:b080:900:4e6:728d:8693:dc86) (Ping timeout: 272 seconds) |
2025-02-19 12:37:21 +0100 | tnt2 | tnt1 |
2025-02-19 12:38:18 +0100 | Inst | (~Inst@user/Inst) Inst |
2025-02-19 12:40:15 +0100 | Googulator13 | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) (Quit: Client closed) |
2025-02-19 12:40:46 +0100 | Googulator13 | (~Googulato@2a01-036d-0106-4074-e4c1-4d2b-93a1-bece.pool6.digikabel.hu) |
2025-02-19 12:41:18 +0100 | j1n37 | (~j1n37@user/j1n37) (Read error: Connection reset by peer) |
2025-02-19 12:42:50 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 12:44:06 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
2025-02-19 12:44:11 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 12:44:52 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
2025-02-19 12:46:11 +0100 | j1n37 | (~j1n37@user/j1n37) j1n37 |
2025-02-19 12:46:37 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 12:47:28 +0100 | tnt2 | (~Thunderbi@user/tnt1) (Ping timeout: 272 seconds) |
2025-02-19 12:50:33 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 12:51:12 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: praxis.meansofproduction.biz (juan@acm.org)) |
2025-02-19 12:51:24 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 260 seconds) |
2025-02-19 12:51:36 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 244 seconds) |
2025-02-19 12:52:39 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) ash3en |
2025-02-19 12:53:29 +0100 | ash3en | (~Thunderbi@2a03:7846:b6eb:101:93ac:a90a:da67:f207) (Client Quit) |
2025-02-19 12:53:30 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 12:54:33 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 12:55:24 +0100 | Inst | (~Inst@user/Inst) Inst |
2025-02-19 12:55:29 +0100 | tnt2 | (~Thunderbi@user/tnt1) (Ping timeout: 260 seconds) |
2025-02-19 12:57:23 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 12:58:24 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 260 seconds) |
2025-02-19 12:58:24 +0100 | tnt2 | tnt1 |
2025-02-19 12:59:05 +0100 | CiaoSen | (~Jura@ip-037-201-240-075.um10.pools.vodafone-ip.de) CiaoSen |
2025-02-19 12:59:17 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 248 seconds) |
2025-02-19 13:00:27 +0100 | cheater_ | (~Username@user/cheater) cheater |
2025-02-19 13:01:53 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 13:02:50 +0100 | Digitteknohippie | Digit |
2025-02-19 13:02:54 +0100 | cheater | (~Username@user/cheater) (Ping timeout: 276 seconds) |
2025-02-19 13:03:03 +0100 | cheater_ | cheater |
2025-02-19 13:05:16 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 13:05:40 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 265 seconds) |
2025-02-19 13:05:44 +0100 | comerijn | (~merijn@77.242.116.146) merijn |
2025-02-19 13:06:08 +0100 | ubert | (~Thunderbi@2a02:8109:ab8a:5a00:fee4:2960:1510:cb37) ubert |
2025-02-19 13:06:52 +0100 | tnt1 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 13:07:28 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
2025-02-19 13:08:17 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 248 seconds) |
2025-02-19 13:09:02 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
2025-02-19 13:09:33 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 245 seconds) |
2025-02-19 13:12:20 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 252 seconds) |
2025-02-19 13:12:40 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 13:13:06 +0100 | <ski> | tomsmeding,dminuoso : "it's rather that let evaluates them concurrently" -- not concurrently, but collaterally (it's the same in Scheme, Common Lisp). e.g. `(let ((a b) (b (+ a b))) ..a..b..)' amounts basically to `do (a,b) <- pure (b,a + b); ..a..b..', or `(\(a,b) -> ..a..b..) (b,a + b)' if you prefer |
2025-02-19 13:13:22 +0100 | <ski> | while `(let* ((a b) (b (+ a b))) ..a..b..)' would amount to `do a <- pure b; b <- pure (a + b); ..a..b..' or `(\a -> (\b -> ..a..b..) (a + b)) b', sequential binding |
2025-02-19 13:13:26 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 252 seconds) |
2025-02-19 13:13:26 +0100 | tnt2 | tnt1 |
2025-02-19 13:13:38 +0100 | <ski> | iirc, Scheme has unspecified evaluation order of the operator and operands in a combination ("function call"), even allowing concurrent evaluation, as long as it is serializable |
2025-02-19 13:13:49 +0100 | <ski> | (see e.g. "Concurrent and serializable computations - and the evaluation order for function's arguments and the body" by Oleg at <https://okmij.org/ftp/Computation/serialization.html>,"4.1.3 Procedure Calls" in the R⁵RS at <https://conservatory.scheme.org/schemers/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html#%_sec_4.1.3>) |
2025-02-19 13:13:55 +0100 | <ski> | so .. the collateral (vs. sequential) here refers to scoping, not to concurrency |
2025-02-19 13:14:08 +0100 | <ski> | "lisp is way more symbolic in the sense that `x` is not a reference to a particular thing","It's more like in lambda calculus where `x` is just `x`." -- no, not really. quoting, for staged programming, meta-programming, macros, is a different thing. obviously you can implement "symbolic evaluators" (partial evaluators, program specializers), just like you can, in Haskell |
2025-02-19 13:14:15 +0100 | <ski> | oh, and dynamic scoping vs. static/lexical scoping is yet another thing entirely |
2025-02-19 13:14:20 +0100 | <ski> | "What Im saying is, is there a big meaningful difference between (+ 5 x) and '(+ 5 x) ?" -- the latter is just a data structure, involving a symbol (not any variable at all) |
2025-02-19 13:14:40 +0100 | jespada | (~jespada@2800:a4:22b9:6800:90a2:b8c6:2c24:d97d) jespada |
2025-02-19 13:15:10 +0100 | <tomsmeding> | ski: that makes sense! |
2025-02-19 13:15:43 +0100 | <tomsmeding> | so let vs let* is about scoping, not about evaluation? And any differences in evaluation are just corollary effects from evaluation order of unsequenced things being unspecified in general anyway? |
2025-02-19 13:16:25 +0100 | tnt2 | (~Thunderbi@user/tnt1) tnt1 |
2025-02-19 13:17:02 +0100 | <ski> | well, `let*' also specifies sequential evaluation |
2025-02-19 13:17:18 +0100 | <ski> | (because of expanding into nested lambda applications) |
2025-02-19 13:17:38 +0100 | <tomsmeding> | as in, it would not be allowed to postpone evaluation until the variable `a' is used in the right-hand side of `b', for example? |
2025-02-19 13:17:47 +0100 | <ski> | but otherwise, yes |
2025-02-19 13:17:53 +0100 | tnt1 | (~Thunderbi@user/tnt1) (Ping timeout: 245 seconds) |
2025-02-19 13:17:55 +0100 | <tomsmeding> | because of the scoping, I don't see what other way you could _not_ have sequential evaluation there |
2025-02-19 13:18:10 +0100 | <ski> | not in Scheme, Common Lisp, no |
2025-02-19 13:18:20 +0100 | <tomsmeding> | they are all strict languages, right? |
2025-02-19 13:18:34 +0100 | <ski> | for a non-standard non-strict Scheme variant, yes |
2025-02-19 13:18:41 +0100 | <ski> | yes |
2025-02-19 13:18:46 +0100 | <tomsmeding> | right |
2025-02-19 13:19:10 +0100 | <tomsmeding> | yeah you can always interpret existing syntax differently if you want, but then you get a different programming languaeg |
2025-02-19 13:19:28 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 13:19:40 +0100 | <ski> | (some texts that play around with implementing Scheme or Lisp interpreters, meta-circularly, does have a non-strict version as a variant) |
2025-02-19 13:20:42 +0100 | <ski> | Lazy ML was a lazy version of the usual strict ML. iirc, HBC (first Haskell compiler) was implemented in it |
2025-02-19 13:20:48 +0100 | <tomsmeding> | but even in a non-strict variant, you can still separate that from the scoping difference of let vs let*, and the evaluation strategy + the scoping is together sufficient to determine what happens, I think |
2025-02-19 13:20:58 +0100 | <ski> | (where is augustss/lennart when you need him !?) |
2025-02-19 13:21:19 +0100 | tnt2 | (~Thunderbi@user/tnt1) (Ping timeout: 260 seconds) |
2025-02-19 13:22:02 +0100 | <tomsmeding> | i.e. "well, `let*' also specifies sequential evaluation" is redundant if you have the scoping property together with the overall strict evaluation strategy |
2025-02-19 13:22:47 +0100 | <ski> | yes. i meant that that "specified sequential evaluation" is a derived consequence of the latter |
2025-02-19 13:22:54 +0100 | <tomsmeding> | right |
2025-02-19 13:23:10 +0100 | <tomsmeding> | cool, the magic level decreased even further |
2025-02-19 13:25:35 +0100 | <ski> | `let' and `let*' (and a bunch of other special forms) are specified as "derived forms" (macros), in the R⁵RS, <https://conservatory.scheme.org/schemers/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html#%_sec_4.2>,<https://conservatory.scheme.org/schemers/Documents/Standards/R5RS/HTML/r5rs-Z-H-10.html#%_sec_7.3> |
2025-02-19 13:28:19 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 260 seconds) |
2025-02-19 13:31:30 +0100 | <ski> | HBC : <https://wiki.haskell.org/Implementations#HBI_and_HBC.2C_Chalmers.27_Haskell_Interpreter_and_Compiler>,<http://web.archive.org/web/20090815181116/http://www.cs.chalmers.se/~augustss/hbc/hbc.html>,<https://web.archive.org/web/20100526120524/http://www.cs.chalmers.se/pub/users/hallgren/Alfa/Haske…>,<https://archive.org/details/haskell-b-compiler> |
2025-02-19 13:32:00 +0100 | <ski> | `hbc-library' <https://www.altocumulus.org/~hallgren/untested/Source_code/old/>,`hbcmake' <https://cth.altocumulus.org/~hallgren/software.html> |
2025-02-19 13:33:44 +0100 | __monty__ | (~toonn@user/toonn) toonn |
2025-02-19 13:34:33 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 13:34:38 +0100 | JeremyB99 | (~JeremyB99@2607:ac80:407:7:87ef:122c:2b31:8cb8) |
2025-02-19 13:34:39 +0100 | JeremyB99 | (~JeremyB99@2607:ac80:407:7:87ef:122c:2b31:8cb8) (Read error: Connection reset by peer) |
2025-02-19 13:34:58 +0100 | Inst | (~Inst@user/Inst) Inst |
2025-02-19 13:36:10 +0100 | <Inst> | also, the reason we use monads instead of monadoids is because pure / return is still a useful end to a monad block, no? left identity might have niche uses, but right identity remains eminently useful |
2025-02-19 13:37:10 +0100 | __monty__ | (~toonn@user/toonn) (Client Quit) |
2025-02-19 13:39:00 +0100 | __monty__ | (~toonn@user/toonn) toonn |
2025-02-19 13:39:08 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 244 seconds) |
2025-02-19 13:39:12 +0100 | <Inst> | there probably is a case wherein left identity is highly useful, though; ugh |
2025-02-19 13:41:32 +0100 | xff0x | (~xff0x@2405:6580:b080:900:a030:6365:43f5:43dc) |
2025-02-19 13:42:34 +0100 | random-jellyfish | (~developer@user/random-jellyfish) random-jellyfish |
2025-02-19 13:42:54 +0100 | <ski> | left identity is used when refactoring |
2025-02-19 13:45:41 +0100 | <Inst> | are there cases where foo <- pure bar is better than let foo = bar? |
2025-02-19 13:45:44 +0100 | <ski> | you have `foo x y z = do ...; return (...)', and you want to inline that into `do ...; t <- foo a b c; ...'. to do that, in the obvious way, you need the associative law, and the left identify law, getting `do ...; let {x = a,; y = b; z = c}; ...; let {t = ...}; ...; ' (assuming any variable clashes have been dealt with, by renaming beforehand) |
2025-02-19 13:46:30 +0100 | <ski> | when `foo' is a refutable pattern, and you want to implicitly invoke `fail' in `MonadFail' |
2025-02-19 13:46:40 +0100 | <Inst> | yeah, that was brought up last time |
2025-02-19 13:46:43 +0100 | <ski> | or when `foo' shadows some variables in `bar' |
2025-02-19 13:47:03 +0100 | comerijn | (~merijn@77.242.116.146) (Ping timeout: 245 seconds) |
2025-02-19 13:47:10 +0100 | <ski> | the former also forces `foo' to be monomorphic |
2025-02-19 13:47:11 +0100 | <haskellbridge> | <Morj> Re foo <- pure bar: this way you can actually shadow variables instead of creating recursive bindings. Similar to ocaml/rust style of doing "let a = expr b in let a = other a in ..." |
2025-02-19 13:47:25 +0100 | <Inst> | you can do that with let as well |
2025-02-19 13:47:30 +0100 | <ski> | no |
2025-02-19 13:47:36 +0100 | <ski> | `let' creates recursive bindings |
2025-02-19 13:47:49 +0100 | <Inst> | ah, yes, you'd need an intermediary |
2025-02-19 13:47:50 +0100 | <ski> | > let x = 1 in let x = x + 1 in x |
2025-02-19 13:47:52 +0100 | <lambdabot> | *Exception: <<loop>> |
2025-02-19 13:48:11 +0100 | <ski> | > do x <- pure 1; x <- pure (x + 1); [x] |
2025-02-19 13:48:12 +0100 | <lambdabot> | [2] |
2025-02-19 13:48:23 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-02-19 13:48:54 +0100 | <ski> | > [x | x <- [1],x <- [x + 1]] |
2025-02-19 13:48:55 +0100 | <Inst> | > let foo = 1 in let bar = foo in let foo = bar + 1 in foo |
2025-02-19 13:48:55 +0100 | <lambdabot> | [2] |
2025-02-19 13:48:56 +0100 | <lambdabot> | 2 |
2025-02-19 13:49:04 +0100 | <ski> | yes |
2025-02-19 13:49:10 +0100 | <Inst> | that works, but is way, way uglier |
2025-02-19 13:49:17 +0100 | <haskellbridge> | <Morj> Holy hell, I didn't know you can do it in list comprehensions |
2025-02-19 13:49:38 +0100 | <Inst> | but iirc shadowing is idiomatic in rust, not in haskell |
2025-02-19 13:49:43 +0100 | <ski> | it's rather obvious, from the list comprehension expansion transformations |
2025-02-19 13:49:46 +0100 | <Inst> | Morj: also implies -XMonadComprehensions ;) |
2025-02-19 13:50:17 +0100 | JeremyB99 | (~JeremyB99@2607:ac80:407:7:87ef:122c:2b31:8cb8) |
2025-02-19 13:50:21 +0100 | <haskellbridge> | <Morj> Sometimes I wish it were idiomatic here. I have a lot of code like "let a = ...; a' = ... a; a'' = ... a' etc" |
2025-02-19 13:52:12 +0100 | JeremyB99 | (~JeremyB99@2607:ac80:407:7:87ef:122c:2b31:8cb8) (Read error: Connection reset by peer) |
2025-02-19 13:53:41 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-19 13:54:45 +0100 | <Inst> | thanks re ski |
2025-02-19 13:54:52 +0100 | <Inst> | and Morj |
2025-02-19 13:55:42 +0100 | <ski> | in SML, `let val a = b and b = a + b in ..a..b.. end' is collateral binding (cf. `let' vs. `let*' above), while `let val a = b; val b = a + b in ..a..b.. end' is sequential binding. recursive binding (corresponding to `letrec' in Lisps) is `let val rec f = ... and g = ... in ..f..g.. end' |
2025-02-19 13:56:45 +0100 | <ski> | (the bodies of `f' and `g' here must be syntactically values, lambda abstractions basically) |
2025-02-19 13:57:02 +0100 | <tomsmeding> | for the `let rec' case? |
2025-02-19 13:57:08 +0100 | <ski> | yes |
2025-02-19 13:57:54 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 248 seconds) |
2025-02-19 13:58:35 +0100 | <ski> | some Scheme systems also have a `letrec*' that guarantees sequential order of evaluation (but recursive scoping) of the definientia |
2025-02-19 13:59:27 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 14:01:18 +0100 | akegalj | (~akegalj@89-172-194-52.adsl.net.t-com.hr) (Ping timeout: 268 seconds) |
2025-02-19 14:01:47 +0100 | <ski> | Mercury has a "State variable" notation, where you can type `foo(...,!X),bar(!X,...),baz(...,!X...)', meaning `foo(...,!.X,!:X),bar(!.X,!:X,...),baz(...,!.X,!:X,...)', which basically amounts to `foo(...,X0,X1),bar(X1,X2,...),baz(...,X2,X3,...)', where `X0' is the initial value of `!X', and `X3' is the final value of `!X'. see |
2025-02-19 14:01:52 +0100 | <ski> | <https://www.mercurylang.org/information/doc-latest/mercury_ref/Clauses.html#State-variables> |
2025-02-19 14:02:24 +0100 | <ski> | (so it generates a sequence of variables for you, basically) |
2025-02-19 14:03:06 +0100 | <haskellbridge> | <Morj> That's a cool feature |
2025-02-19 14:04:19 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) (Ping timeout: 260 seconds) |
2025-02-19 14:05:06 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
2025-02-19 14:05:32 +0100 | AlexNoo_ | AlexNoo |
2025-02-19 14:06:17 +0100 | atwm | (~andrew@19-193-28-81.ftth.cust.kwaoo.net) atwm |
2025-02-19 14:09:18 +0100 | ski | idly wonders what could be a reasonable concrete syntax for sequential vs. collateral binding, in Haskell |
2025-02-19 14:11:12 +0100 | <ski> | there already is `do rec {x <- ..y..; y <- ..x..}; ..x..y..' |
2025-02-19 14:14:14 +0100 | Inst | (~Inst@user/Inst) Inst |
2025-02-19 14:15:01 +0100 | ski | notes that `rec' doesn't work in list comprehensions, even with `MonadComprehensions' enabled |
2025-02-19 14:16:32 +0100 | <ski> | .. i guess one could imagine `seq {...}' and `par {...}', although that'd snarf the names of those standard functions |
2025-02-19 14:16:45 +0100 | <Inst> | is this explanation of why monads instead of monadoids in the moggi papers? |
2025-02-19 14:17:09 +0100 | <ski> | `let par {a = b; b = a + b} in ..a..b..' vs. `let seq {a = b; b = a + b} in ..a..b..' |
2025-02-19 14:17:11 +0100 | <haskellbridge> | <Morj> Does using var` lead to any ambiguities? To get "let a` = foo; a` = bar a`; a` = qux a` in ..." - mercury-style state variables |
2025-02-19 14:17:30 +0100 | <ski> | which, Inst ? |
2025-02-19 14:17:38 +0100 | <haskellbridge> | <Morj> I like that it's similar to using a front-tick which is already idiomatic |
2025-02-19 14:18:12 +0100 | <Inst> | the one for left identity, at least, and implicitly the right identity to permit a return through a neutral element |
2025-02-19 14:18:43 +0100 | sawilagar | (~sawilagar@user/sawilagar) sawilagar |
2025-02-19 14:18:45 +0100 | ski | 's forgotten what "monadoids" refer to |
2025-02-19 14:18:55 +0100 | cstslrdg^ | (~cstslrdg@108.192.66.114) |
2025-02-19 14:19:15 +0100 | <Inst> | i've forgotten if i used the term correctly |
2025-02-19 14:19:24 +0100 | <ski> | right identity is for getting "monadic tail invokation" |
2025-02-19 14:20:52 +0100 | <Inst> | i mean associative law of functor join without identity laws of pure/eta |
2025-02-19 14:22:27 +0100 | mange | (~user@user/mange) (Quit: Zzz...) |
2025-02-19 14:22:32 +0100 | <Inst> | although tbh you CAN avoid right identity to some extent, simply by using the last monadic element, then <$ the returned element into it |
2025-02-19 14:22:45 +0100 | <Inst> | *returned value |
2025-02-19 14:24:56 +0100 | Inst | (~Inst@user/Inst) (Remote host closed the connection) |
2025-02-19 14:25:34 +0100 | bitdex | (~bitdex@gateway/tor-sasl/bitdex) (Quit: = "") |
2025-02-19 14:27:48 +0100 | akegalj | (~akegalj@141-136-246-173.dsl.iskon.hr) |