IRC channel logs

<oriansj>stikonas: yeah 1MB on the stack seems like a reasonable limit. Also wow gtker really is expanding into a bunch of features needed to build TCC.

<stikonas>yeah, gtker is really doing a lot of nice work

<stikonas>I barely have time to review it all in my evenings

<stikonas>well, we have partial changelog here... https://github.com/oriansj/stage0-posix/blob/master/CHANGELOG.org

<stikonas>I would say it is already longer than most releases

<stikonas>so I'm not sure when we should make a release...

<stikonas>one option is to make it soon and release often...

<stikonas>or we could wait until the new feature flow slows down a bit

<oriansj>well, as gtker is doing the heavy lifting. let them decide when it feels good for them (or they can delegate that to anyone if they so choose)

<stikonas>yeah, I guess that agrees with our principle of who does the work, decides

<stikonas>I guess one advantage of early release though is that later projects (like mes) could gradually port to pointer arithmetic using += and -= operators

<stikonas>since most likely currently all pointer arithmetic is done via + and -

<stikonas>though if we add versioning to __M2__ macro, that would solve the problem as well

<oriansj>well mes did a bunch of work to pull out pointer arithmetic

<oriansj>well GCC does something like this: https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html

<oriansj>so __M2__, __M2_MINOR__ and __M2_PATCHLEVEL__

<oriansj>but also as gtker seems to be more adding features than breaking old behavior; mes might not need to do version specific logic (especially if we tend to the stricter half of the C standard)

<oriansj>have you seen? https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3211.pdf

<stikonas>hmm, not for C

<stikonas>I think I saw somebody was proposing something similar for C++

<stikonas> https://safecpp.org/draft.html

<stikonas>well, we could always try to build C++ with sanitizers...

<stikonas>s/C++/M2-Planet/

<stikonas>and see what happens

<oriansj>it is overkill for bootstrapping but I can imagine we could add the warning bits pretty easily

<oriansj>I might just take a day to see if it is worth the complexity added or if it asks for too much.

<stikonas>well, very early steps are in assembly anyway

<stikonas>so there we need to deal with raw unsafe memory...

<stikonas>only from M2-Planet one can start having memory safety

<oriansj>indeed and having clean and robust C code seems like the cheapest way to save us headaches long term.

<oriansj>(atleast until we have a better option)

<stikonas>I'm sure there will still be headaches...

<stikonas>I still need to figure out unxz crash on riscv...

<stikonas>well, I fixed one crash but that was not enough

<matrix_bridge><gtker> oriansj, stikonas: I don't mind a soon-ish release. I've got a few things I want to see if I can get implemented first, but it shouldn't take too long

<matrix_bridge><gtker> oriansj: Opinions on whether https://github.com/oriansj/M2-Planet/issues/63#issuecomment-2688334670 should be fixed in M2-Planet or in M1-macro?

<oriansj>gtker: yeah, I really should upgrade Knight's M1 to be more standard

<oriansj>but it means I will have to backport that improvement to Knight's M0

<oriansj>So, I'll change Knight's M1 behavior and tests later today and do the M0 backport sometime next week.

<oriansj>as a more consistent M1/M0 is more important than supporting the older knight M0

<oriansj>plus it'll give me an excuse to speed up knight's M0 with proper hashing

<matrix_bridge><gtker> oriansj: Alright. I've already got a fix in M2-Planet ready for PR, should I just remove that again?

IRC channel logs

2025-02-27.log