| 17 May 2024 |
 jade_ | you should plausibly have access to just edit those issues to fix the links tho? | 04:10:32 |
 julia | oh I seem to don't I | 04:58:41 |
| julia | In reply to @jade_:matrix.org
can't do much about that nginx redirect 😂 | 04:59:04 |
| julia | In reply to @jade_:matrix.org
can't do much about that * nginx redirect 😛 | 05:15:32 |
|  iFreilicht joined the room. | 08:01:16 |
 Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) | I'm still waiting for the forgejo federation stuff to be useable | 08:15:04 |
|  Owen Shepherd joined the room. | 20:22:16 |
| Owen Shepherd | 👋 Hello,
Nice to meet you all!
I'm Owen, I write compilers and things, with a focus on compile-time performance.
Let me preface this by saying I know there's a feature freeze, and I'm happy if what I'm working on remains a personal project until that changes :)
Aaaanyway, I'm working on adding bytecode-interpreter to nix/lix (whichever project(s) want to upstream it).
The plan for MVP, is leave everything as-is upto lixexpr, and add a writeBytecode function to Expr.
This will write out bytecode as C-abi POD, and then... well there will be a bytecode interpreter :)
I'm gonna write that in C, probably, but because it's C POD, there's nothing stopping the interpreter being in rust, or any other language...
Bytecode mode will enabled by some kind of command-line flag, or maybe a config value in nix.conf.
This might end up being slower than the current tree-walk evaluator, in which case... experiment complete.
Anything else I should keep in mind, assuming I want to maximise my changes of upstreaming this?
Any thoughts in general?
| 20:46:50 |
| Owen Shepherd | * 👋 Hello,
Nice to meet you all!
I'm Owen, I write compilers and things, with a focus on compile-time performance.
Let me preface this by saying I know there's a feature freeze, and I'm happy if what I'm working on remains a personal project until that changes :)
Aaaanyway, I'm working on adding a bytecode-interpreter to nix/lix (whichever project(s) want to upstream it).
The plan for MVP, is leave everything as-is upto lixexpr, and add a writeBytecode function to Expr.
This will write out bytecode as C-abi POD, and then... well there will be a bytecode interpreter :)
I'm gonna write that in C, probably, but because it's C POD, there's nothing stopping the interpreter being in rust, or any other language...
Bytecode mode will enabled by some kind of command-line flag, or maybe a config value in nix.conf.
This might end up being slower than the current tree-walk evaluator, in which case... experiment complete.
Anything else I should keep in mind, assuming I want to maximise my changes of upstreaming this?
Any thoughts in general?
| 20:47:14 |
 Lunaphied | So, I think this is planned and something @pennae (who seems to not be in here?) is working on as part of evaluator/parser rewrites | 21:02:34 |
| Lunaphied | In general Lix is focused right now on cleaning up a lot of the foundational code we inherited from Nix and therefore large new features like that aren't really on the table at the moment. | 21:07:55 |
| Lunaphied | I'd personally recommend waiting and seeing how existing plans go before committing yourself to a project like that given that it's already on our timeline | 21:08:36 |
 raitobezarius (DECT: 7248) | Alternatively, Owen Shepherd I would recommend heading over to the Tvix project which already has a bytecode interpreter and where you could implement more advanced features, if you are comfortable with the TVL folks. | 21:13:46 |
| Owen Shepherd | Yes, I've had a look already. I was looking to improve a nix implementation I can actually use now, which has an ecosystem, rather than hack on tvix, which (I assume) isn't going to be usable for a while. | 21:16:44 |
| Owen Shepherd | Do you know if @pennae has any code or plan I can look at, to see what the direction is? | 21:19:21 |
| jade_ | it's not feasible to do that until we fix the io model (wip), which is blocking the parser rewrite (done but needs them to backport), which is blocking fixing more of the evaluator | 21:25:04 |
| raitobezarius (DECT: 7248) | In reply to @414owen:matrix.org
Yes, I've had a look already. I was looking to improve a nix implementation I can actually use now, which has an ecosystem, rather than hack on tvix, which (I assume) isn't going to be usable for a while. Well, making Tvix usable now is potentially in the same range of efforts than carving a bytecode interpreter in CppNix right now. | 21:34:15 |
| jade_ | i would also say that it is probably a more worthwhile use of time, because i think it is highly unlikely we would accept this approach | 21:46:15 |
| Lunaphied changed their display name from Lunaphied to lunaphied. | 21:47:32 |
| Owen Shepherd | Sure, what would you change about the approach? I was looking for that kind of feedback. | 21:51:17 |
 John Ericson | In reply to @jade_:matrix.org
it's not feasible to do that until we fix the io model (wip), which is blocking the parser rewrite (done but needs them to backport), which is blocking fixing more of the evaluator oh it is neat to see the dependency graph | 21:52:07 |
| John Ericson | I wanna rename *::Recursive in Nix to *::NixArchive | 21:53:22 |
| John Ericson | because recursive is a terrible name | 21:53:29 |
| John Ericson | and it would be cool if you all could do the same sed | 21:53:35 |
| John Ericson | so it isn't a needless cherry-picking stumbling block | 21:53:45 |
| jade_ | In reply to @Ericson2314:matrix.org
so it isn't a needless cherry-picking stumbling block hahahahaha wanna fix our includes to use lib* across both projects, | 22:00:32 |
| jade_ | i have a clang-tidy pass for it | 22:00:44 |
| John Ericson | lib*? | 22:06:39 |
| John Ericson | it would be neat if we supported the same C APIs | 22:07:02 |
| John Ericson | but that could be hard | 22:07:09 |
