Newest at the top
| 2025-09-22 19:23:01 +0200 | kuribas | (~user@2a02-1810-2825-6000-fedd-5dda-6057-f5dc.ip6.access.telenet.be) (Ping timeout: 255 seconds) |
| 2025-09-22 19:22:39 +0200 | ljdarj | (~Thunderbi@user/ljdarj) ljdarj |
| 2025-09-22 19:21:38 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-09-22 19:17:12 +0200 | jmcantrell_ | jmcantrell |
| 2025-09-22 19:17:12 +0200 | jmcantrell_ | (~weechat@user/jmcantrell) jmcantrell |
| 2025-09-22 19:16:16 +0200 | <Franciman> | i see |
| 2025-09-22 19:14:23 +0200 | jmcantrell | (~weechat@user/jmcantrell) (Quit: WeeChat 4.7.1) |
| 2025-09-22 19:14:19 +0200 | <dminuoso> | And its not because the problem domain is complicated: its just that all that fixed point nonsense is very much adhoc. |
| 2025-09-22 19:13:52 +0200 | <dminuoso> | Long story short: One is bad, you should probably use the other, and use a bunch of magic undocumented library functions to make it really extensible. |
| 2025-09-22 19:13:28 +0200 | <dminuoso> | 8 year old issue about haskellPackages.extend and haskellPackages.override |
| 2025-09-22 19:13:19 +0200 | <dminuoso> | https://github.com/NixOS/nixpkgs/issues/26561 |
| 2025-09-22 19:13:17 +0200 | <dminuoso> | The best example is this: |
| 2025-09-22 19:13:13 +0200 | <dminuoso> | But its an absurd abstraction because it leaks implementation at every step of the way |
| 2025-09-22 19:13:00 +0200 | <dminuoso> | At the end its all done to compose things together |
| 2025-09-22 19:12:51 +0200 | <dminuoso> | Sometimes its about attrsets |
| 2025-09-22 19:12:51 +0200 | <Franciman> | i see |
| 2025-09-22 19:12:49 +0200 | <dminuoso> | Sometimes its about config |
| 2025-09-22 19:12:47 +0200 | <dminuoso> | Sometimes its about a singular derivation |
| 2025-09-22 19:12:28 +0200 | <Franciman> | i thought fixpoints was to compute the final derivation |
| 2025-09-22 19:12:20 +0200 | <Franciman> | ahh i see |
| 2025-09-22 19:12:19 +0200 | <dminuoso> | In case of NixOS modules config fixed point, its how modules can talk to each other to figure out whats what |
| 2025-09-22 19:12:16 +0200 | <inline> | on almost every update i saw haskell packages... looks like a fast moving thing |
| 2025-09-22 19:11:59 +0200 | <dminuoso> | In various degrees. |
| 2025-09-22 19:11:55 +0200 | <dminuoso> | Franciman: So the fixed points that occur in nixpkgs allow for composability of "things" |
| 2025-09-22 19:11:54 +0200 | <inline> | and once i installed haskell in there the updates won't ever end.... |
| 2025-09-22 19:11:19 +0200 | <Franciman> | i'm not sure i follow the comment on fixed point logics, wdym dminuoso ? |
| 2025-09-22 19:11:15 +0200 | <inline> | so 1. level flaky, 2. level flaky due to previous or on it's own, 3. level stable |
| 2025-09-22 19:10:43 +0200 | <Franciman> | dminuoso: you think we would need full prolog power or just a datalog dialect? |
| 2025-09-22 19:10:21 +0200 | <inline> | i had 3 levels of encryption, the one via bitlocker (it looses the device from time to time) then i had an encryption level from the VBox, then another of the virtual disk with cryptsetup in the OS |
| 2025-09-22 19:10:21 +0200 | tzh | (~tzh@c-76-115-131-146.hsd1.or.comcast.net) |
| 2025-09-22 19:10:06 +0200 | <dminuoso> | s/define/avoid/ |
| 2025-09-22 19:09:56 +0200 | <dminuoso> | Software developers have been solving these problems for 5 decades. |
| 2025-09-22 19:09:46 +0200 | <dminuoso> | Franciman: All that fixed point logic is just trying very hard to define module/packaging/interface boundaries |
| 2025-09-22 19:09:45 +0200 | <Franciman> | lol |
| 2025-09-22 19:09:00 +0200 | <dminuoso> | Neither usable nor popular, sounds we could torture a PhD student with it. |
| 2025-09-22 19:08:58 +0200 | <Franciman> | prolix sounds good |
| 2025-09-22 19:08:55 +0200 | <inline> | seems like when encryption of devices is the case and windows suddenly looses the device (even though it was initially opened via passphrase and ran 2-3 days) |
| 2025-09-22 19:08:52 +0200 | <Franciman> | maybe we can inject the fixed point shit about making derivation into the classic fixpoint semantics of logic programs? |
| 2025-09-22 19:08:28 +0200 | <dminuoso> | Lets make that a thing. |
| 2025-09-22 19:08:23 +0200 | <dminuoso> | Franciman: Oh prolix! |
| 2025-09-22 19:08:05 +0200 | <Franciman> | davean: i would like to see a declarative language for nix-style stuff using logic programming paradigm |
| 2025-09-22 19:08:00 +0200 | <dminuoso> | Its not as if helps readability. |
| 2025-09-22 19:07:54 +0200 | <dminuoso> | I dont even know why nix people even botter with CR/LF. |
| 2025-09-22 19:07:35 +0200 | <inline> | i now even updated virtualbox |
| 2025-09-22 19:07:30 +0200 | jmcantrell_ | jmcantrell |
| 2025-09-22 19:07:25 +0200 | <inline> | last time it was bookworm of debian, no idea what's going on |
| 2025-09-22 19:07:17 +0200 | <davean> | well at least llvm generated vectorized assembly is easier to read than hand-optimize vectorized assembly |
| 2025-09-22 19:07:14 +0200 | <dminuoso> | Of a single empty line to just group code. |
| 2025-09-22 19:07:07 +0200 | <dminuoso> | All without a single line of comment. |
| 2025-09-22 19:07:01 +0200 | <dminuoso> | Seriously, you get 1700 lines of nix files dealing with fixed point magic, various extend/override tricks, hooking inside out, outside in, double wrapping twisted turning fixed point inversion logic.. |