IRC channel logs

2024-08-14.log

back to list of logs

<aggi>just tried it, and yes, they're transpiling c-to-shell; tested $pnut-sh cp.c cp.sh, and the emitted script works with oksh interpreter
<aggi>don't know which gap this was filling for bootstrapping
<aggi>or why anyone would want to transpile c-to-shell
<nimaje>as I understand it, it is a for fun project
<fossy>pabs3: that's really nice, i would love to see more of that :D
<matrix_bridge><Andrius Štikonas> well, at the very least that make dist would have a list of pregenerated files
<matrix_bridge><cosinusoidally> pnut is interesting as it also has a self hosted i386 backend. It's possible to go pnut.sh -> pnut.exe -> pnut1.exe and have pnut.exe and pnut1.exe be identical. Note the have an exe extension, but they are just statically linked elf binaries. pnut.exe does not needs any external assemblers or linkers, plus they ship their own libc.
<matrix_bridge><cosinusoidally> If it can also compile tcc then that would be very useful. I suspect the reference in the readme to compiling tcc may currently be aspirational, but hopefully they just need to publish the correct commands to build it. It may also eventually be possible to do cc_x86 -> (maybe M2) -> pnut -> tcc
<pabs3>fossy: personally I think autotools `make dist` should do that by default. could also shunt the autocruft into a second tarball for those who actually need it, ie they are on a platform with no autotools yet
<andydude>huh
<andydude>There are plenty of systems out there with a shell and no C compiler, for example, macos without devtools
<andydude>Also, my understanding of autotools is increasing by the day
<oriansj>well if someone finds it fun; I am sure something interesting will come of it. If not oh well.
<oriansj>andydude: good
<andydude>So far I've at least made stub files for all of automake
<andydude>Now I just need to write it :P
<andydude>I'm a little torn about the file wrapper, its entire purpose seems to be to replace \r with \n
<andydude>Always when I'm writing C I wish I had started the project in Python
<oriansj>andydude: you can always redo it in C after you figure out the details
<oriansj>also you might find this interesting: https://github.com/leahneukirchen/redo-c
<fossy>pabs3: i largely agree
<fossy>the paradigm i'm most opposed to is the inclusion of autogenerated files in git repositories (or whatever your "development source" is)
<fossy>and a second is non-existent documentation on what those autogenerated files might be
<fossy>often the second is a consequence of the first though
<pabs3>yeah, that first one shits me too https://wiki.debian.org/AutoGeneratedFiles
<pabs3>what kind of documentation are you thinking of? just .gitignore or something more human-oriented?
<fossy>really - anything
<fossy>as long as it can be reasonably interpreted without excessive difficulty
<fossy>honestly a list of pregenerated files and the command/process to regenerate it is fine in my opinion
<fossy>but even a list of pregenerated files with processes somewhere else
<andydude>fossy: I was considering making a github repo about bios and uefi on intel and amd, but it seemed to be too big of a project, I never knew where to start
<andydude>to clarify, a repo with only docs, no code
<pabs3>fossy: ugh, postgres are committing the generated ./configure https://news.ycombinator.com/item?id=41232621#41239118
<fossy>andydude: sorry, what specifically about bios and uefi?
<fossy>eek, pabs3
<joostvb>but also https://peter.eisentraut.org/blog/2024/08/13/the-new-postgresql-17-make-dist : not all is bad @ postgres build system
<nimaje>but why didn't they remove that auto-generated file from the repo with that change?
<joostvb>good question
<joostvb>nimaje: i'd guess you've found a bug
<nimaje>well, it was cryptonector on hn (and probably others too), I just checked that it really still exist in the repo
<joostvb>a, i c
<nimaje>should have read that comment shared by pabs3 better, they have no intent to remove that configure script from the repo