IRC channel logs

***Server sets mode: +cnt

<stikonas>fossy: it was chroot

<stikonas>oriansj: can you remind me what's the status of mes-m2 in stage0-posix

<stikonas>should it be able to run mescc or not yet?

<stikonas>I tried running it but it didn't work for me

<oriansj>stikonas: assuming you have the latest commit, yes it should run the version of mescc included with it

<stikonas>ok, I'll try again some other day

<stikonas>I also saw some extra work needed on porting mescc-tools-extra build scripts

<stikonas>(to M2libc)

<stikonas>actually, we should switch to the version in stage0-posix

<oriansj>stikonas: well I should have it all ready in a nice bundle this weekend

<stikonas>ok, I'll wait for that to land...

<stikonas>then maybe I can try to switch live-bootstrap to new versions...

<oriansj>also for mescc-tools-extra, I am going to make the build universal in a way that live-bootstrap will also be able to leverage. (as will MesCC once I get it to work with M2libc)

<Melg8[m]>oriansj: does M2-planet handle // comments?

<oriansj>Melg8: depends on if one is using --bootstrap-mode or not.

<Melg8[m]>what bootstrap-mode is doing?

<oriansj>Melg8: bootstrap-mode behaves like cc_* and throws error messages, enabling us to ensure on every commit M2-Planet is still buildably by cc_*

<oriansj>and that the result is able to properly self-host

<oriansj>It is also used for cases where M0 (written in hex2) and the hex2 written in hex1 have special needs (say during the inital bootstrap)

<oriansj>Basically it is a legacy mode for applications that can't be built with M2libc yet.

<oriansj>Which is much worse performance simply because every byte written and read is a separate syscall.

<oriansj>M2libc reads the whole file as one syscall and tries to write in large blocks if possible.

<Melg8[m]>oriansj: okay, thanks. I'm just try to evaluate chances of building something like toybox with some parts ripped off by M2-Planet/GNU Mes/tcc (as i can see it need libc at least)

<oriansj>Melg8: the chance is always 100% if one is willing to put in a little effort. As there are only a few special cases in what M2-Planet+M2libc can't do according to the C spec yet.

*Melg8[m] < https://libera.ems.host/_matrix/media/r0/download/libera.chat/6367e517c99261de8fb649f88416662c8162cdfb/message.txt >

<Melg8[m]>note: (i'm using versions of stage0-posix used by live-bootstrap now

<oriansj>well struct toy_list* toy_find(char *name); is no different than struct token_list* read_all_tokens(FILE* a, struct token_list* current, char* filename) in regards to functionality and M2-Planet handles that fine.

<oriansj>char *argv[] vs char** argv

<oriansj>There is a reason why we have this: https://github.com/oriansj/M2-Planet/blob/master/known_issues.org

<Melg8>what im getting is:

<Melg8>M2-Planet --debug --architecture x86 -f ./toys.h -o toybox.M1 git:master*

<Melg8>./toys.h:71:ERROR in create_struct

<Melg8> Missing {

<Melg8>i've removed all // from toys.h example so it could at least go until 71 line

<oriansj>Melg8: struct definitions are supported in the normal form.

<Melg8>and

<Melg8> m2-planet = builtins.fetchGit rec {

<Melg8> name = "M2-Planet";

<Melg8> url = "https://github.com/oriansj/${name}.git";

<Melg8> ref = "refs/heads/master";

<Melg8> rev = "358b6cfb96e1685891a705a0bb31eda499d57974"; # Release 1.7.0

<Melg8> }; - version is used

<oriansj> https://github.com/oriansj/M2-Planet/blob/master/cc.h#L49

<oriansj>as you have to define a struct type before you can use it.

<oriansj>with the minor exception of you can use it as a type inside of the struct definition itself

<Melg8>struct bla * something - uses forward declaration of type bla?

<Melg8>idk why it forward declares this functions in toys.h and before definition of toy_list

<oriansj>Melg8: you need to find where the struct bla is defined and simply put it before the use of struct bla in your code

<Melg8>m2-planet doesn't handle extern keyword?

<oriansj>Melg8: M2-Planet doesn't handle #include (it drops it on the floor)

<Melg8>yes, that i know)

<oriansj>extern is ignored (only used by Gnu Mes)

<oriansj>So extern int foo; just means int foo;

<Melg8>idea was to try to emulate them by hand, but i guess i'll move forward a bit and check with mes, than with tcc - because i don't want to massively refactor toybox source code - at least for now it's just check of capabilities

<oriansj>because all of the source code is read all at once; thus extern literally means nothing.

<Melg8>but if it fail compilation on it, i can't compile code with it)

<oriansj>It doesn't fail on extern. It just skips the word extern as if it isn't there at all.

<Melg8>you talking about latest version? or 1.7.0?

<Melg8>bin/M2-Planet --debug --architecture x86 -f ./toys.h -o toybox.M1

<Melg8>Unknown type extern

<Melg8>./toys.h:70:% toybox ➤ echo $?

<Melg8>git:master*

<Melg8>1

<oriansj>Melg8: janneke added support for extern on commit d223581d4ea0a25c419a669a88015de57c29192f

<oriansj>So it is going to be in the 1.8.0 release this weekend.

<Melg8[m]>than i really need to update)

<Melg8[m]>nice)

<Melg8[m]>see, now you have legacy users xD

<oriansj>Melg8: have had them for about 5 years now, ever since janneke added %lable>label behavior to hex2

<oriansj>Always something new to fix and something old to keep working because someone else came to depend upon it.

<Melg8[m]>yea)

***jackhill is now known as jackhill[m]

***jackhill[m] is now known as jackhill

<Melg8[m]>When i try to view logs: http://logs.guix.gnu.org/bootstrappable/2021-01-04.log - i get error: "Resource not found: http://127.0.0.1:3333/2021-01-04.log"

***ChanServ sets mode: +o janneke

<mitzman>ugh regarding the issue from yesterday (can't find lex because test -w fails, in order to build binutils-mesboot0). test -w fails because bash 2.05b it thinks the euid is -1. otherwise it would work fine. the error is ENOSYS (function not implemented)... which i do find implemented in mes-0.21. and both bash-mesboot0, and tcc-boot0 are using it. hm, i feel stuck/lazy to build mes-boot and see what happens

<mitzman>does it make sense to just reply to the issue and see what happens next?

<xentrac>have a somber Tiananmen Square Day

<mitzman>okay found the problem in my case - it's using a 32-bit asm call fml

<xentrac>heh

<Melg8[m]>Hi, why mes.kaem builds libc-mini? ( # Now for libc-mini.a) is it used anywhere later? where?

<stikonas>Melg8[m]: I think it's not really used...

<stikonas>although, the object files that are used in it are then used for libc.a, so not building libc-mini wouldn't save much

<Melg8[m]>yea, i see, thanks

<stikonas>we might need to rework some stuff once we move to m2-planet with m2libc

<stikonas>so I might look at it then

<stikonas> started some work on moving live-bootstrap to it

<stikonas>but then noticed that the new mescc-tools don't have any kaem file yet

***ChanServ sets mode: +o rekado_

***rekado_ is now known as rekado

<rekado>Melg8[m]: https://logs.guix.gnu.org/bootstrappable/ lists all available logs for #bootstrappable — 2021-01-04.log is not among them.

<rekado>I suppose I should copy something somewhere

<stikonas>well, these are only logs from libera chat, old logs were on freenode

<Melg8>rekado yes, i found that link in google search

<rekado>stikonas: yes, but we still have the old logs

<rekado>I should just copy them, but I’m kinda busy

<rekado>apparently not busy enough to write that I’m busy

<rekado>¯\_(ツ)_/¯

<rekado>copied the freenode logs

<rekado>there are some log files that exist for both networks; haven’t merged those

<Melg8>@rekado thanks, i just used google cached version, but that is nice anyway

IRC channel logs

2021-06-04.log