IRC channel logs

<stikonas>siraben: there are a few more cc_*...

<stikonas>and I can't merge https://github.com/oriansj/stage0-posix-armv7l/pull/5#pullrequestreview-4285810917

<stikonas>oriansj: will have to do it

<matrix_bridge><wildwestrom> Andrius Štikonas: Ah, I see. So the assembler is for after the first C compiler ("cc_*").

<matrix_bridge><Andrius Štikonas> well, I think that was the idea

<stikonas>siraben: we have uefi version here: https://codeberg.org/stikonas/stage0-uefi/src/branch/main/amd64/cc_amd64.M1

<stikonas>a few versions here https://github.com/oriansj/stage0/tree/master/stage2

<stikonas>(I guess that's it)

<siraben>I see, thanks

<matrix_bridge><wildwestrom> roconnor

<matrix_bridge> Sorry it took me so long to respond. I don't know anything about lambda calculus beyond some youtube videos about it. I also don't even know what a combinator is in this context. What do you think is the right path toward learning these functional programming concepts?

<roconnor>That's a tough question for me to answer. I started by learning ML in my languages course at university.

<roconnor>I thought it was the best language ever.

<matrix_bridge><wildwestrom> I understand Standard ML's type system is the basis for many languages and proof assistants. Never got around to trying to build something with it. The closest languages I know are Clojure and Rust.

<matrix_bridge><wildwestrom> Also some dabbling in Lean 4.

<roconnor> https://kar.kent.ac.uk/20998/1/ttfp.pdf This is a book that I read after my undergrad

<roconnor>Might be worth a try

<matrix_bridge><wildwestrom> I'll definitely take a look!

<siraben>wildwestrom: https://crypto.stanford.edu/~blynn/compiler/

<siraben>this is what i'm basing my work on

<siraben> https://crypto.stanford.edu/~blynn/lambda/

<siraben>this one is for lambda calculus and combinator stuff without the compiler oriented

<siraben>commentary

<siraben>made a bake tool to be compiled with cc_x86 (before m2_planet) https://github.com/siraben/mescc-tools/commit/fb14165a419eaeff9a8d696b4083eb37f61c523e

<siraben>and this is what it looks like to use bake https://github.com/siraben/mescc-tools-extra/commit/e726e2d65f20d9833d92986dd70613fa4424c551

<siraben>has topological sort, dependency lists per target, grouped targets, variable substitution like kaem

<siraben>looks kind of like M1

<siraben>Removing globbing and only supporting ${VAR} and $@ now

<siraben>Replaced kaem with bake throughout my fork

<siraben> https://github.com/siraben/live-bootstrap-bake

<roconnor>Just for my own understanding, this file https://github.com/oriansj/stage0-posix-riscv64/blob/master/libc-core.M1 is called libc-core is actually more of a c runtime?

<roconnor>I guess I'm not fully aware of the terminology around this.

<xentrac>libc is generally speaking the C runtime

<xentrac>malloc, free, printf, setjmp, longjmp, that kind of thing

<roconnor>what's the crtn and crti files?

<roconnor>crt1

<xentrac>typically those are what runs before main starts and after it returns

<xentrac>assuming that's what they are in stage0 to

<xentrac>*too

<roconnor>that's wht libc-core does.

<xentrac>so it is

<xentrac>generally crt0 and friends are considered part of libc even though they aren't in /lib/x86_64-linux-gnu/libc.so.6

<xentrac>where are the crtn and crti you're asking about?

<roconnor>${MES_PREFIX}/lib/linux/${MES_ARCH}-mes-gcc/crtn.c

<roconnor>${MES_PREFIX}/lib/linux/${MES_ARCH}-mes-gcc/crti.c

<xentrac>I don't have it installed at the moment, sorry

<xentrac>new laptop who dis

<roconnor> https://github.com/gnu-mirror-unofficial/mes/blob/master/lib/linux/x86_64-mes-gcc/crtn.c

<roconnor>lol

<roconnor>and

<roconnor> https://github.com/gnu-mirror-unofficial/mes/blob/master/lib/linux/x86_64-mes-gcc/crti.c

<roconnor>very important copyright

<xentrac>hahaha

<xentrac>SunOS /bin/true was the same way for many year

<xentrac>*s

<xentrac>an empty shell script

<stikonas>both m2libc and meslibc are statically linked

<stikonas>so c library vs c runtime doesn't really make much distinction

<stikonas>all that code ends up in the binary

<stikonas>and yes, meslibc is licensed under GPLv3

<stikonas>so you can only link GPLv3 compatible applications with it

<xentrac>Yay :-)

<xentrac>but crtn.c and crti.c contain no original authorship in which copyright could inhere

<stikonas>no, those files are not needed

<stikonas>there is no code

<stikonas>but the whole meslibchas this license

<siraben>Merged in riscv64 support for blynn-bootstrap

<stikonas>e.g. https://github.com/gnu-mirror-unofficial/mes/blob/master/lib/stdio/vfprintf.c

<siraben>docker run -it ubuntu

<siraben>and then

<siraben>apt update && apt install -y wget patch && cd /tmp && wget -qO- https://github.com/siraben/blynn-bootstrap/archive/refs/heads/portability.tar.gz | tar xz && cd blynn-bootstrap-portability && time M2_ARCH=aarch64 M2_OS=Linux sh scripts/bootstrap-blynn.sh && test -x build/tinycc-boot-hcc/bin/tcc

<siraben>should work and bootstrap all the way to tcc via haskell

<xentrac>yes, that's what happened to SunOS /bin/true as well

<siraben>need to get rid of that patch dep though

<xentrac>you might want to default your docker run to --rm

<xentrac>congratulations on getting that working!

<siraben>stikonas: https://github.com/oriansj/M2-Planet/pull/169

<siraben>xentrac: thanks

<stikonas>might not have time to review it all today

<siraben>no problem

<stikonas>unless others pick it up :)

<siraben>added ternary expressions finally to m2-planet, and some other constructs that we already had parsing infrastructure for

<stikonas>yeah, m2-planet can parse most of the C

<stikonas>the problems are mostly in more complex cases

<stikonas>when you start combining things like dereferences, arrays postfix/prefix and perhaps pointer arithmetic

<stikonas>it gets quite with linear parser

<stikonas>rather than proper syntax tree

IRC channel logs

2026-05-14.log