| 6 Nov 2024 |
| seapat joined the room. | 13:50:04 |
| 7 Nov 2024 |
| @frumon:matrix.org left the room. | 12:27:19 |
| 12 Nov 2024 |
| pfhuh joined the room. | 05:51:31 |
| 22 Nov 2024 |
Picnoir | Hey!
I'm trying to add a keypress toggle to print the drv path instead of the program pname/version in the output. (to allow me to copy paste drvs to a remote builder when I'm on my slow laptop :P)
I added this "printer state" part to the NOMV1State datatype.
| 14:22:31 |
Picnoir | This approach is a bit annoying, the state updater is pretty pure and only expects the Nix output for now. I tried to bend a bit the updater type but it's rapidly going out of hand diff wise. | 14:23:30 |
Picnoir | I'm thinking about extracting the print state from the nom state and store that in a tmvar easily accessible from processTextStream. | 14:24:11 |
Picnoir | I'll likely have to thread that up until printBuilds, but I think it'd be easier in the end. | 14:25:18 |
Picnoir | Do you have any strong feeling against me doing this maralorn ? | 14:25:33 |
Picnoir | * Do you have any strong feeling against me doing this maralorn (I'd like to upstream this) ? | 14:25:42 |
Picnoir | * I'm thinking about extracting this new print state from the nom state and store that in a tmvar easily accessible from processTextStream. | 14:26:06 |
maralorn | Huh, keypress consumption is kind of a major feature. π | 14:58:34 |
maralorn | Iβd have a lot of ideas for what to do with that. | 14:58:47 |
maralorn | I think I would love to have a trifecta: A well structured collection of config options which can be set via 1) config file/env, 2) cli options 3) keypress menu during run. | 15:00:32 |
maralorn | But let me not bog you down with feature ideas. | 15:01:07 |
maralorn | I am not opposed to what you are proposing. | 15:01:27 |
maralorn | But I am not 100% sure what you wanna do. | 15:01:43 |
maralorn | Generally I think config state and data state should be decoupled. So I donβt think adding it to NOMV1State makes sense. | 15:03:05 |
maralorn | (btw. that is terribly misnomed because it is at this point what I expected NOMV2State to be. π ) | 15:03:30 |
maralorn | * (btw. that is terribly misnamed because it is at this point what I expected NOMV2State to be. π ) | 15:03:42 |
Picnoir | Me neither tbh haha. The plan I was talking about above does not work either. The printer is abstracted out in writeStateToScreen (via OutputFunc, I don't really have way to inject a new tmvar to stateToText through it >< | 15:03:51 |
Picnoir | * I'm not sure what I'm doing either haha.
The plan I was talking about above does not work either. The printer is abstracted out in writeStateToScreen (via OutputFunc, I don't really have way to inject a new tmvar to stateToText through it ><
| 15:04:13 |
maralorn | Yeah, I recently tried to work on this and I think the abstraction design is a bit terrible right now.^^ | 15:04:31 |
Picnoir | :) | 15:04:42 |
Picnoir | It's a bit intense for my limited brain. | 15:04:49 |
Picnoir | But I'm going to figure out a way to do this. We'll make it pretty later. | 15:05:10 |
maralorn | The problem is that annoying Typeclass to support two relatively different modes (json and parsing human-readable stuff). | 15:05:53 |
Picnoir | Right | 15:06:22 |
maralorn | I might have time to work on nom tomorrow so I can look into what we need to improve/what would be the easiest way to inject your change. | 15:06:41 |
Picnoir | Ok. I'll try to get something working by tonight. | 15:08:21 |
Picnoir | (working != pretty :D) | 15:08:34 |