Newest at the top
| 2024-11-19 21:24:27 +0100 | notzmv | (~daniel@user/notzmv) (Remote host closed the connection) |
| 2024-11-19 21:20:55 +0100 | euleritian | (~euleritia@dynamic-176-003-072-074.176.3.pool.telefonica.de) |
| 2024-11-19 21:20:53 +0100 | notzmv | (~daniel@user/notzmv) notzmv |
| 2024-11-19 21:19:37 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Read error: Connection reset by peer) |
| 2024-11-19 21:19:36 +0100 | lxsameer | (~lxsameer@Serene/lxsameer) (Ping timeout: 246 seconds) |
| 2024-11-19 21:13:58 +0100 | acidjnk_new | (~acidjnk@p200300d6e7283f33ad61be24cfbe8605.dip0.t-ipconnect.de) acidjnk |
| 2024-11-19 21:07:44 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) (Ping timeout: 260 seconds) |
| 2024-11-19 21:06:30 +0100 | notzmv | (~daniel@user/notzmv) (Read error: Connection reset by peer) |
| 2024-11-19 21:06:25 +0100 | mehlon__ | (~mehlon__@user/mehlon) (Remote host closed the connection) |
| 2024-11-19 21:06:09 +0100 | mehlon__ | (~mehlon__@user/mehlon) mehlon |
| 2024-11-19 21:02:39 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) |
| 2024-11-19 21:02:32 +0100 | euleritian | (~euleritia@ip4d16fc9f.dynamic.kabel-deutschland.de) (Ping timeout: 255 seconds) |
| 2024-11-19 21:00:41 +0100 | caconym | (~caconym@user/caconym) caconym |
| 2024-11-19 21:00:03 +0100 | caconym | (~caconym@user/caconym) (Quit: bye) |
| 2024-11-19 20:59:50 +0100 | Alleria | (~Alleria@user/alleria) (Ping timeout: 255 seconds) |
| 2024-11-19 20:59:46 +0100 | guy | (~guy@2a01:4b00:d007:ed00:3c30:fab:460b:9474) (Quit: Client closed) |
| 2024-11-19 20:58:54 +0100 | <guy> | ciao x |
| 2024-11-19 20:58:45 +0100 | <guy> | as a way to dance around the ideas of graphical turing completeness |
| 2024-11-19 20:58:24 +0100 | <guy> | and somehow captures within it the nature of local scoping |
| 2024-11-19 20:58:20 +0100 | Alleria_ | (~Alleria@user/alleria) Alleria |
| 2024-11-19 20:58:01 +0100 | <guy> | functor scheduling adds repeated modification within fmap, unlike traverse which would visit each element once |
| 2024-11-19 20:57:05 +0100 | <guy> | reasigning to the named lookup variable bound into scope upon function definition |
| 2024-11-19 20:56:51 +0100 | <guy> | but also editing. which is what local rescoping is doing on the program graph. reusing like its a memory slot |
| 2024-11-19 20:56:18 +0100 | <guy> | and your not just dealing with the constructor as a deconstructor reconstructor pair on pattern matching |
| 2024-11-19 20:55:47 +0100 | <guy> | additional editing on top of this can break traversal laws about unique visitation |
| 2024-11-19 20:55:12 +0100 | <guy> | traversal itself is built around pattern matching on the constructor |
| 2024-11-19 20:54:20 +0100 | <guy> | "functor scheduling" adds. which can build revisitation into an otherwise suspended traversal amounting with a "total schedule" to an fmap instance, maybe with several modification to one entry |
| 2024-11-19 20:52:34 +0100 | <guy> | this is the kind of statement |
| 2024-11-19 20:52:27 +0100 | <guy> | i like how haskell adds, by supporting local rescoping, nonlinearity, to its graphical turing completeness |
| 2024-11-19 20:51:40 +0100 | <guy> | local rescoping, somehow |
| 2024-11-19 20:51:33 +0100 | <guy> | i think it violates traversable laws about revisitation |
| 2024-11-19 20:51:13 +0100 | <guy> | this amounts to modification on the program graph, asside from just deconstruction and reconstruction to change it to the linear list tape |
| 2024-11-19 20:50:14 +0100 | <guy> | and the concept of (nonlinear) graphical turing completeness, and the local scoping about changing the lookup numbers on the turing tape |
| 2024-11-19 20:49:28 +0100 | haskellbridge | sm did see a wall of "guy>" yes |
| 2024-11-19 20:48:50 +0100 | <guy> | i was trying to talk about stateful functional programming, but before i was talking about local rescoping as nonlinearity in the program graph |
| 2024-11-19 20:48:34 +0100 | weary-traveler | (~user@user/user363627) (Remote host closed the connection) |
| 2024-11-19 20:48:11 +0100 | <guy> | there was this thing i was talking about last time i was on did anyone see? |
| 2024-11-19 20:46:39 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2024-11-19 20:44:44 +0100 | <sm> | oh. That was fast. |
| 2024-11-19 20:42:10 +0100 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) tzh |
| 2024-11-19 20:40:54 +0100 | <sm> | the element X clients are getting good now - fast, with easier crypto UX, and built in next-gen audio/video calls |
| 2024-11-19 20:36:16 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) (Quit: JuanDaugherty) |
| 2024-11-19 20:35:14 +0100 | JuanDaugherty | and no video or substantial change since last check |
| 2024-11-19 20:33:45 +0100 | <JuanDaugherty> | terminating inquiry for now with apparent realization that matrix.org is a peer domain of libera.chat, from whose servers |
| 2024-11-19 20:30:04 +0100 | <JuanDaugherty> | by implication it's not sm's homeserver but having trouble instantiating matrix from the protocal / server implementations |
| 2024-11-19 20:23:41 +0100 | <JuanDaugherty> | or something setup with mattermost since its hs |
| 2024-11-19 20:23:22 +0100 | <JuanDaugherty> | i sorta expected slack actually |
| 2024-11-19 20:23:08 +0100 | <Leary> | sm: Nevermind HLS; you can't even use ghcid with them. Or if you can, it's not an invocation I was able to discover. |
| 2024-11-19 20:22:48 +0100 | misterfish | (~misterfis@84.53.85.146) misterfish |
| 2024-11-19 20:22:30 +0100 | <JuanDaugherty> | has matrix changed functionally, e.g. video or such? I dont think i've looked at it in at least 5-6 years |