IRC channel logs

<mwette>ekaitz: that j instruction looks really weird, the argument doensn't make any sense to me: "j" should have bits 11:7=0 and an address can only have 20bits, right?

<mwette>or is the disassembler doing some soft interpretation?

<mwette>never mind. I see those are addresses, and the jump is relative

<mwette>Can you display the machine word there? Maybe the relative address is being computed incorrrectly.

<dsmith>mwette, Says that parts fixed now.

<dsmith>Current issue is (not?) using a temp register or something like that.

<lechner->Hi, is the constant TIOCSCTTY from <asm/termbits.h> available in Guile?

<ArneBab>sneek: later tell dthompson: I think Guile should never change in a way that breaks flagship projects. Lilypond is one of these: it is the only Guile using project that is the top of the crop of its domain (music engraving). That doesn’t mean that Guile cannot change, but before release of such changes, Lilypond would have to be changed so it does not break.

<sneek>Will do.

<ArneBab>sneek: botsnack

<sneek>:)

<ArneBab>sneek: later tell dthompson: a deeper reason is that flagship projects usually cannot adapt easily, because they have to use every trick in the bag to achieve the needed performance. So they can be closely coupled to Guile, and that pretty deep in their core.

<sneek>Okay.

<ane>my wife is a professional musician, she knows someone who does note engraving professionally using LilyPond (she is not sure, but she said "the application looks like shit but the notatino produced by it are amazing")

<ane>and it can do custom tricks you can't do with commercial scorewriters like Finale/Sibelius apparently

<ekaitz>wingo: today i managed to pass all the Guile tests with GUILE_JIT_THRESHOLD=0

<ekaitz>except one that is also failing without the JIT

<ekaitz>also i found that the net-db.test fails in my RISC-V machine

<dsmith>ekaitz, Did you figure out your register usage problem?

<ekaitz>dsmith: i think so, there's still one test failing in lightening, but I'll figure that out

<ekaitz>it's a superspecific issue

<ekaitz>does anyone have riscv hardware to try to replicate the test failure that I found? the net-db.test fails

<ekaitz>maybe it's a configuration problem in my setup?

<dsmith>Can qemu be used?

<ekaitz>yes but I'm not sure if that's going to trigger the problem

<ekaitz>we could try

<ekaitz>i'm configuring --with-mini-gmp

<ekaitz>that's the only option I'm adding

<rlb>If it's not too hard to test, and still broken, I might be able to test on a porterbox later.

<rlb>i.e. if https://db.debian.org/machines.cgi?host=ricci is suitable

<ekaitz>i'm rebuilding now but I'll let you know what the error is

<ekaitz>i'm building on top of c0bfa3219

<ekaitz>but i don't see anything in main that suggests that the issue was fixed

<ekaitz>maybe it's just me

<ekaitz>i reproduced the failure

<ekaitz>i think it's on my side

<ekaitz>FAIL: net-db.test: getaddrinfo: no name <--- that's not a guile problem i think

<rlb>might check /etc/hosts, etc.

<mwette>ekaitz. I have a microchip PIC64GX board running Ubuntu but it only has 1GB mem. I think it will choke on a guile build. Let me think about trying. (I'd wan to copy the SD card.)

<ekaitz>mwette: don't worry i think rbl is right, it's the host configuration that is not well done

<ekaitz>it doesn't feel like a guile issue but a system misconfiguration

<ekaitz>it's so satisfying to see all the green PASS's

<ekaitz>hmmm the "no name" test is the only one that fails

<ekaitz>unexpected error code: -11 "System error"

<ekaitz>it's not returning throwing the exception

<ekaitz>but a system error

<ekaitz>hmmmmmm

<rlb>In debian, I'd generically guess "network disabled" on the buildds for that kind of thing, but if you're running it locally, and/or not in a container or other restricted network namespace, etc., then dunno.

<ekaitz>yeah... idk but system error feels weird

<ekaitz>libguile/net_db.c says system errors can happen due to some uncontrolled conditions so it might be that

<ekaitz>in any case, it happens with the JIT disabled so that's not my fault

<ekaitz>in summary: we have a JIT working in RISC-V

<rlb>excellent

<mwette>thanks, ekaitz

<ekaitz>:)

<ekaitz>thank you for the support! now i need to upstream this

<dsmith>Woo

<ekaitz>btw, i sent this patch #74269 because it's very useful when trying to debug the JIT, and it wasn't documented... maybe someone can commit or review it?

<old>anyone made display-backtrace works with the highlights parameter?

IRC channel logs

2024-11-15.log