IRC channel logs

<OriansJ>openprogger: as I understand it, the development is currently taking place on guile with the goal of later sorting out the differences between guile and mes-m2 when it is done. Thus enabling a scheme only bootstrap for guix

<OriansJ>as right now mes-m2 can be bootstrapped from nothing (https://github.com/oriansj/mescc-tools-seed and https://github.com/oriansj/mes-m2)

<OriansJ>since the development work can now be done in a subset of C; it is mostly just a matter of effort to get mes-m2 to support a scheme subset capable of running all of the pieces required.

<fossy>i believe the largest missing piece is modules?

<OriansJ>fossy: actually no, one could add module support in scheme if one just extendeds load-file to support prefixes

<OriansJ>as loading of modules is the exact same thing as load-file otherwise

<OriansJ>the big problem place right now is mes_macro.c

<OriansJ>as I am an idiot and can't get macros quite right

<OriansJ>as macros seem quite hard to do right; not to mention I need someone to point out how I am doing the existing scheme primitives wrong.

<xentrac>the way scheme standardized macros is hard to do right

<OriansJ>and I am just one man, who likes things to work so I don't have to keep fixing something forever

<OriansJ>and the more I work on mes-m2; the more I fear that I'll be tweaking its brokeness forever.

<OriansJ>like fixing one part will break other working parts

<OriansJ>perhaps the most frustrating parts about interpreters

<xentrac>programming is hard

<xentrac>but not impossible

<OriansJ>programming compilers is alot easier and much less work than interpreters

<xentrac>you've said; I don't understand how that can be, but I accept that that is your experience :)

<OriansJ>xentrac: compiler -> a = a + 4; push_address a, load_immediate 4, load a, add r0 r1, pop, store r0 r1 and done. A compiler is just a string state machine

<OriansJ>An interpreter has to do a shitload more to do the same work

<OriansJ>like actually implement all of the desired primitives and in scheme's case garbage collection

<OriansJ>and mind you I have done a FORTH interpreter, lisp interpreter and C compiler in assembly

<OriansJ>and a scheme interpreter and C compiler in C

<OriansJ>So in those languages I must say compilers are simpler and easier

<OriansJ>Now that might not be true in all languages but that is my direct experiences

<OriansJ>perhaps interpreters are easier in interpreted languages were the language you are working in pays most of that complexity for you

<OriansJ>or put in a more numerical form: a Cross-platform C compiler -> 2,332 lines of code; mes-m2 -> 6,582 lines of C code and 1,269 lines of Lisp code and we can't even run a program able to Compile mes-m2 (which M2-Planet certainly can)

<OriansJ>perhaps even my experience is only accurate for minimal interpreters and compilers

<OriansJ>perhaps the initial overhead of interpretation reduces costs later in the implementation cycle relative to adding more features to a Compiler but I just haven't seen it yet.

<OriansJ>but I know assemblers and linkers really take alot of complexity out of the compiler and reduce it to just a string generating state machine.

<mid-kid>Has anyone had any issues getting a bzip2 built with TCC+mes-libc to accept data from stdin?

<mid-kid>Specifically, bzip2 1.0.8 with tcc 0.9.27 and mes 0.22

<mid-kid>Running something like "cat file.bz2 | bzip2 -d" gives me a "PANIC -- internal consistency error: decompress:unexpected error".

<mid-kid>And I just want to know if this is a known thing or because of however I built this toolchain.

<mid-kid>stdin seems to be a null pointer???

<mid-kid>As in, the global "stdin" variable.

<mid-kid>Yeah, removing the "if (f == NULL" (setting it to "if (0") in BZ2_bzReadOpen, causes everything to work correctly. I guess bzip2 never expects the value of "stdin" to be 0.

<mid-kid>Just checked it against glibc and "stdin" isn't 0 there either.

<mid-kid>But I guess mes-libc sets it to 0 for internal reasons.

<janneke>that would be "bzip2-mesboot" in guix

<mid-kid>yeah

<mid-kid>In mes-0.22: include/stdio.h:#define stdin (FILE*)0

<janneke>mid-kid: yes, i see that too bzip2/bunzip2 do not decompress to stdout

<mid-kid>You mean _from_ stdin?

<janneke>mid-kid: yeah, the mes c library works that way

<janneke>ah, /me looks again

<janneke>yeah, that too

<mid-kid>hmm

<mid-kid>decompressing to stdout through "bzip2 -cd file.tar.bz2 | tar x" works fine.

<janneke>mid-kid: there is no FILE* abstraction; stdin (and others) are just file handles

<mid-kid>I see.

<janneke>that seemed neat and minimalist, would be nice to clean that up some time ;-)

<mid-kid>Hehe, well, anything works as long as they're not null pointers :P

<janneke>yeah; note that all other tooling up to the first gcc-core works well with mes lib c

<mid-kid>Yeah I've noticed, it's just that "tar jxf" didn't work without rebuilding bzip2 so I wanted to check it out.

<janneke>note that this give you bzip2 with guix:

<janneke>$(guix build -e '(@@ (gnu packages commencement) bzip2-mesboot)')/bin/bzip2

<janneke>it would be nice if it worked, i agree

IRC channel logs

2020-10-06.log