IRC channel logs

<stikonas>oriansj: hmm, I'm still thinking what to do with mescc global variables. While reworking it might be possible but it might need touching large parts of code...

<stikonas>maybe it's worth adding some other modifier to M1 that just spits out hex2 directly

<stikonas>we do have <1 -> 00 or <4 -> 00000000

<stikonas>but mescc sometimes needs to spit out e.g. 03

<stikonas>say we have a global variable var = 3

<stikonas>then mescc internally prepares the following list (3 0 0 0)

<stikonas>and at the moment converts it to !0x03 !0x00 !0x00 !0x00

<stikonas>oh actually I think M1 might already have this feature...

<stikonas>I completely forgot about it...

<stikonas>yep hello world finally works well with mescc after I switched from !0xhex_byte to weird strings

<stikonas>and it's just 2 line change in mescc

<fossy>rickmasters, stickonas: yeah off disk would still be nice, but im not sure what needs to be done for that to happen - if it is too much im more than happy to drop it from 1.0

<stikonas>well, let's deal with other issues first anyway

<stikonas[m]>It will probably take some time to solve even other issues...

<stikonas[m]>Especially since I'm busy with riscv64 port of mescc

<stikonas[m]>fossy: wasn't this fixed https://github.com/fosslinux/live-bootstrap/issues/291

<fossy>yes i forgot to add the "Fixed" to the comimt description

<emilytrau[m]>janneke: may i send this `mes` patch your way? :3... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/f2e00e1457c52d4d9b1caf06c5158388d4009b01>)

<janneke>emilytrau[m]: sure, thanks

<janneke>stikonas[m]: \o/

<janneke>emilytrau[m]: just out of interest, what are you building that you need it for?

<emilytrau[m]>janneke: sorry should have mentioned that in the first place! it's for gnumake 4.4.1. other than that define it works like a charm :))

<emilytrau[m]>* gnumake 4.4.1 (latest). other

<janneke>ok, nice

<janneke>always bleeding edge, these nix folks ;)

<rickmasters>fossy: Issue 291 was still not fixed for Qemu with Linux.

<rickmasters>fossy: I tracked it down to lib/tmpdir.py:add_disk() needs size="16G" instead of 8G

<rickmasters>fossy: I can submit a PR but I'm traveling and I'm not sure when I'll have time.

<stikonas>rickmasters: I can push the fix then if you think that's it...

<rickmasters>stikonas: yes, please. it worked for me. fossy's fix is only relevant to --external-sources

<stikonas>yeah, we have quite a few different modes

<stikonas>it's easy to mix up different fixes

<rickmasters>stikonas: thanks!

<oriansj>stikonas: wow, I am surprised janneke didn't add that C feature. Usually MesCC is way ahead of M2-planet in regards to C language feature support.

<stikonas>oriansj: which one?

<stikonas>global variable sizes?

<stikonas>mescc had it, but it was doing it byte by byte

<stikonas>i.e. !0x03 !0x00 !0x00 !0x00 (if you had var = 3;)

<oriansj>no "the" "string" "behavior"

<stikonas>well, I've switched it to string behaviour

<stikonas>now, yes...

<stikonas>somehow initially I didn't realize that weird strings are very useful on riscv

<oriansj>as in fputs("hello " "world", stdout); would compile and work correctly

<stikonas>oh that thing...

<stikonas>yeah, I think M2-Planet is ahead here

<stikonas>but mescc has way better macro support

<stikonas>so I could construct required string with macros and syscall number definition in header file

<stikonas>anyway, I'm probably not too far from finishing now

<stikonas>though there might be some problem, a couple of tests in scaffold (global-array and local-static-array) crash...

<oriansj>it is like a 5 line feature in C but in lisp it would be a single line

<stikonas>rickmasters: by the way, are --external-sources expected not to work?

<stikonas>(in kernel bootstrap mode)

<rickmasters>Yes, external sources can't currently work with kernel bootstrap.

<rickmasters>stikonas: there may be a way in the future with another disk or partition.

<stikonas>janneke: I've pushed my wip changes to https://git.stikonas.eu/andrius/mes/src/branch/wip-riscv though at the moment there are still some (unknown) bugs that prevent it from working

<stikonas>some of them might be tricky...

<stikonas>e.g. some files cause mes-m2 to crash

<stikonas>(though guile copes with them)

<stikonas>and final binary also crashes

<stikonas>which is probably expected given that scaffold/global-array.c also crashes

<stikonas>though quite a few other things in scaffold work fine

<stikonas>including read

<stikonas>I think I've tested argv env hello local-array main and read and they worked

<stikonas>and global-array and local-static-array crashed. Haven't tried the others...

<janneke>stikonas: great; i believe that global-array and local-array are known to crash with M2-Planet (they should work with mescc), i'm not sure -- we should check on x86

<stikonas_>janneke: global-array and local array might work with next M2-Planet

<stikonas_>anyway, current crash is clearly codegen bug

<stikonas_>but mescc crash when building some files is probably a separate issue

<stikonas>I'll probably take a look at global-array crash

<stikonas>but you might be more familiar with mes and what might cause mes itself to crash...

<stikonas>there were quite a few C files that caused this

<stikonas>I think the first one was lib/stdio/fwrite.c

<janneke>sure, i'll have a look tomorrow

<stikonas>janneke: actually I think I've found what caused mes to crash on fwrite.c

<stikonas>there was a copy-paste error

<stikonas>and i haven't renamed variable

<stikonas>but like expected global-array, is unrelated, it still crashes

<janneke>stikonas, those are the best but often so hard to find...

<stikonas>well, I was basically going over my diff and doing self-review...

<stikonas>let's see what happens now if I build the whole me...

<stikonas>previously I had to use guile for more complicated files

<stikonas>maybe now it will at least build, though I still expect bin/mes to crash

<stikonas>but we should be getting fairly close now

<janneke>very nice

<janneke>ACTION -> zZzz

IRC channel logs

2023-05-20.log