IRC channel logs

<Irvise_>Hi, one question that hopefully can be answered in this channel. I installed Mes using Guix in my system as I want to play with it.

<Irvise_>However, when I run mes from the shell, it tells me it is missing the file boot-0.scm. Okay, that is not such a problem. I downloaded the src of mes and I can run it if I am on the root folder of the src.

<Irvise_>However, when I write a .scm/.mes file with some code, the REPL gives me issues when I try to load it :/

<janneke>Irvise_: running: "guix shell mes -- mes" works for me?

<Irvise_>Lemme try that

<janneke>also, "guix install mes" works for me

<janneke>did you follow the advice that is subsequently printed?

<janneke>for me that's:

<janneke> GUIX_PROFILE="/home/janneke/.guix-profile"

<janneke> . "$GUIX_PROFILE/etc/profile"

<Irvise_>janneke: the guix shell command did the trick to get mes correctly running without having to be in the src folder :)

<Irvise_>Yes, I have Guix in my profile, I can run other programs installed with it without issues.

<Irvise_>However, loading the file still causes issues.

<janneke>Irvise_: you need to re-source that file after installing mes

<janneke>as advised

<janneke>it sets MES_PREFIX

<janneke>(we removed the prefix from the binary to make it bit-for-bit identical over distributions)

<Irvise_>May I ask what does re-sourcing the file means?

<Irvise_>Just in case, here is a log of the full error https://paste.debian.net/1285292/

<janneke><janneke> GUIX_PROFILE="/home/janneke/.guix-profile"

<janneke><janneke> . "$GUIX_PROFILE/etc/profile"

<Irvise_>Ah! it is in my .profile, it gets loaded every time I log in :)

<Irvise_>(gets sourced as in the shell lingo)

<janneke>yes, but after installing something, you either needs to logout and re-login, OR source it again

<janneke>it says

<janneke>hint: Consider setting the necessary environment variables by running: [..]

<Irvise_>Let me try

<Irvise_>I same issue happens. Mes dies after the (load "reciprocal.ss") sexp is run in the REPL...

<Irvise_>And just in case it was not clear, I had mes already installed from a while ago :) (months)

<Irvise_>I just realised that you are one of the main developers ^^ Hi! o_/

<janneke>ah sorry, i completely misunderstood

<janneke>Irvise_: apparently, load does not work from the repl

<Irvise_>How would one normally load external files in the REPL? Does Mes need an external environment varialble that lets it load files outside of its standard library?

<Irvise_>Or maybe that is not possible and it needs to be loaded with the file directly using the command line. I am aware of how limited (and not so limited) mes is :)

<janneke>it would be nice if load worked from the repl but we'll probably not fix that before we have proper module support

<janneke>it seems that currently your only option is from the command-line, indeed

<janneke>something like

<janneke>guix shell mes -- mes -e '(hello)' hello.scm

<Irvise_>janneke: great! Thanks! It works now ^^

<Irvise_>I had forgotten that mes does integer division :P

<janneke>Irvise_: great, and thanks for your bug report :)

<Irvise_>Now I shall try to do SICP in Mes. I will probably hit some roadblocks, but it will be fun.

<janneke>yeah, no floats or rationals

<janneke>oh fun!

<Irvise_>janneke: btw, does mes or do you have an Emacs mode for it? I can work with it in an terminal buffer, but having a bit more integration with Emacs does help :P

<janneke>Irvise_: no, i'm using emacs shell

<Irvise_>Okay, thanks :)

<janneke>Irvise_: i've made a patch fixing load (and ,use MODULE too)

<janneke> https://git.savannah.gnu.org/cgit/mes.git/tree/mes/module/mes/repl.mes?h=wip

<Irvise_>janneke: thanks :) That was quick ^^

<janneke>Irvise_: yeah, your questions got me thinking

<janneke>it was a long standing bug but i got a new perspective on it

<Irvise_>I am glad my question helped :)

<janneke>ACTION too :) good questions can be powerful

<stikonas>janneke: so I've finally found some time to launch gdb for mes-tcc on x86_64

<stikonas>looks like infinite loop happens due to o(0xe5894855); (which is negative integer when interpreted as 32 bits)

<stikonas>so register is 0xffffffffe5894855

<stikonas>I guess we could patch it out...

<stikonas>though proper fix might be to support 64-bit immediate in mescc

<janneke>stikonas: nice find

<janneke>if we patch it out it would be nice to add a comment, or a note somewhere about this

<janneke>guess we should add it to Mes' ROADMAP in any case

<stikonas>yeah, it would be good to fix it in Mes too

<stikonas>this is something that should be possible to fix and would reduce patchset for tinycc

<janneke>right

<janneke>and increase our odds of moving to a more recent tinycc some time

<stikonas>well, I'll patch it out in tinycc for now and will see if it fixes the issue

<janneke>sure

<stikonas>hmm, partial success

<stikonas>./mes-tcc -c hw.c -o hw.o worked where hw.c is just int main () { return 42; }

<stikonas>but building crt1.c failed...

<stikonas>oh, one moment, I might not have installed it yet into PATH

<stikonas>ok, crt1.o is working too now

<janneke>ooh, nice

<stikonas>there are still issues building more complicated files

<stikonas>it failed to build meslibc (concatenated into a single file)

<janneke>what i did for x86 when it started to work

<stikonas>and also lib/libtcc1.s fails with lib/libtcc1.c:143: error: #error unsupported CPU type

<janneke>(after all the "lotsa debug printing" comparisons with gcc-built tcc

<janneke>was run the mescc test suite

<stikonas>well, this time I think we mostly need to focus on x86_64*.c files...

<janneke>hmm, weird

<stikonas>janneke: that's because we have "#if defined(TCC_TARGET_I386)"

<janneke>yeah could be, otoh mescc's c tests are pretty simple

<janneke>and if tcc fails on some of them, you'd have it pretty narrowed down?

<janneke>ah, hehe -- silly

<stikonas>oh, actually it's fine in wip-riscv branch

<janneke>stikonas: but yeah, possibly it's all new 64bit problems -- could be...

<stikonas>le me check...

<stikonas>anyway, this unsupported stuff is fixed in some other branch

<stikonas>still, I think we are fairly close to have it working...

<janneke>yeah, pretty exciting

<janneke>and esp. good news for riscv!

<stikonas>and there are more issues with 32-bit numbers...

<stikonas>I think I should first go over the source and patch out all of them

<muurkha>death to 32-bit scum!

<ekaitz> https://riscv-programming.org/ <-- did you know this one?

<ekaitz>it might help us in the short term :)

<stikonas[m]>Hmm, maybe it would have been useful for stage0-posix-riscv64...

<stikonas[m]>Probably less so now

<stikonas[m]>But it's probably still a good book for somebody learning assembly

<oriansj>stikonas: if it could be read without javascript or bootstrappable javascript

<stikonas>oriansj: it's just plain html

<stikonas> https://riscv-programming.org/book/riscv-book.html

<stikonas>at least this link opens with noscript enabled

<oriansj>but not netsurf nor elinks

<oriansj>which are html web browsers

<stikonas>hmm, perhaps... let me see source..

<stikonas>looks like it's running some kind of pdf2html thingy

<stikonas>but yes, that's annoying

<stikonas>I can't see how to download it

<oriansj>and if you attempt to print to PDF you only get the first page

IRC channel logs

2023-07-08.log