| 20 Jul 2022 |
 yorik.sar | By the way, do nixpkgs support netbsd/vax in current state? | 16:17:38 |
| yorik.sar | We should define what we want to support, otherwise we'll have to rely on Bash or something as ubiquitous... | 16:18:13 |
 Gytis Ivaskevicius | something similar may work nicely https://github.com/elsaland/elsa but not well maintained (also gcc can compile go 👁️)
Advantages of typescript:
- Actualy very nice and solid type system
- One of the most popular languages
- Language is flexibible enough to create nice DSL's like https://github.com/google/zx
- Large focus on async
- Inline json
| 16:18:28 |
| yorik.sar |
NetBSD/vax is the port of NetBSD to DEC VAX computers. The first model was announced in 1977 and they were sold until September 30, 2000.
http://wiki.netbsd.org/ports/vax/
Oh, it's one of those...
| 16:18:53 |
| yorik.sar | *
NetBSD/vax is the port of NetBSD to DEC VAX computers. The first model was announced in 1977 and they were sold until September 30, 2000.
http://wiki.netbsd.org/ports/vax/
Oh, it's one of those...
| 16:19:09 |
| Gytis Ivaskevicius | In reply to @kity:kity.wtf
ruby and lua are good options and will work on that platform (and if you can run on netbsd/vax you can run on anything, pretty much) i bet it cant run on redox 😔 | 16:19:15 |
| Gytis Ivaskevicius | ;D | 16:19:17 |
 problems | i don't think defining specific platform support should be in scope for this. we should aim to run on as many platforms as possible, so as to not preclude future platform support. | 16:20:04 |
| Gytis Ivaskevicius | infinisil: might be cool to consult with John Ericson, I am sure he has some unique insights | 16:21:33 |
| Gytis Ivaskevicius | Maybe you could get him to join next call? | 16:21:44 |
| problems | https://github.com/SwadicalRag/wasm2lua | 16:24:48 |
| problems | a bit silly but could be considered for portability if we end up on wasm | 16:25:16 |
|  John Ericson joined the room. | 16:44:56 |
| Gytis Ivaskevicius | 
Download image.png | 16:51:43 |
| Gytis Ivaskevicius | Welp, good news everyone!!
I had a chat with John and he will join us on the next call and if we are lucky may become an advisor/mentor of sorts for this particular issue | 16:51:43 |
| Gytis Ivaskevicius | * Welp, good news everyone!!
I had a chat with John and he will join us on the next call and if we are lucky may become an advisor/mentor for this particular issue | 16:51:59 |
 infinisil | Awesome! Glad to have you John Ericson ! | 16:56:39 |
| John Ericson | glad to be here! | 16:56:56 |
| infinisil | Meanwhile I uploaded the meeting notes to https://github.com/nixpkgs-architecture/meetings/blob/master/2022-07-20.md, which also contains the link to the recording | 16:56:56 |
| John Ericson | lots to talk about, but a shorter term task I hope to get people to help me with is repackaging compiler with upstream yak shaves | 16:57:33 |
| John Ericson | it's hard, but it untangles lots of things which in turn allows other architectural efforts to procede | 16:57:55 |
| infinisil | It's a bit tricky because everybody probably has their own priority of issues, but if it's a dependency for other issues then it might be very worthwhile | 16:59:20 |
| infinisil | Gotta work from the bottom up, can't have a loose foundation | 16:59:37 |
| infinisil | John Ericson: Do you think making stdenv a bit more independent of nixpkgs would be a good idea? This could include things like it having its own repository, its own release cycle, it having its own nixpkgs-independent basic builders, etc. | 17:02:41 |
| infinisil | Own Hydra jobset | 17:02:56 |
| John Ericson | infinisil: I worry more repos will make cross-cutting refactors harder | 17:03:26 |
| John Ericson | I hope we can get types before such experiments | 17:03:38 |
| John Ericson | types would offset that downside a lot | 17:03:44 |
| infinisil | If not a separate repo, it could also live independently in a subtree, a bit like nixpkgs lib | 17:04:12 |
| infinisil | I'm imagining a stricter dependency chain of pkgs depending on stdenv, but not the other way around | 17:04:49 |
