IRC channel logs

<ArneBab>mwette: this is one less papercut for Guile users ⇒ bit by bit cutting down barriers to adoption.

<robin>ArneBab, there's git-series and stgit ("stacked git"), which seem conceptually related to evolve. but they're external extensions, unlikely to be incorporated into core git

<robin>(evolve looks a bit more advanced, just skimming the docs)

<robin>i used git-series for gecko hacking but as a single author, dunno what the collaborative experience would be like

<robin>hg evolve definitely looks more advanced :)

<rlb>...fwiw, if you use emacs and magit and/or git-commit mode, it'll help make sure some of that is "right" -- commit mode highlights any content in second line, etc.

<ArneBab>robin: hg evolve is pretty awesome (it solves the "force push wrecked all repos" problem of rebasing and you can retroactively and tracably edit the shown history), but it’s also not yet in Mercurial core (it’s an extension), though its requirements are, so using it wouldn’t break anyone’s repositories.

<ArneBab>rlb: I used magit to import the patches. I just didn’t spot the long lines.

<x8dcc>Hello, I think there is a typo in the first code block of Section 7.5.3.5

<x8dcc>I think the last `cons' call should have an extra parentheses

<Arsen>I think you're right; but, note that usually info nodes are referenced via the name of the node rather than the numbers because the number can change

<x8dcc>Right, sorry

<Arsen>i.e. when the info viewer says: "-----Info: (guile)SRFI-1 Fold and Map", you'd say (guile)SRFI-1 Fold and Map

<x8dcc>Should I report this somewhere, or do you take care of it?

<Arsen>I can't push - patches and bug reports go to bug-guile@gnu.org

<Arsen>see https://www.gnu.org/software/guile/contribute/

<Arsen>you might get lucky and someone with push rights sees it here, though :)

<x8dcc>I will send a mail anyway. Thanks

<Arsen>thanks! :)

<ekaitz>I replicated my riscv64 lightening port's segfault in guile's codebase

<ekaitz>I need some suggestions to how to investigate this, could someone share some advice?

<ekaitz>I get the segfault in the early beginning of the build process

<ekaitz> BOOTSTRAP(stage0) GUILEC ice-9/eval.go

<mwette>ekaitz: how about meta/gdb-uninstalled-guile

<mwette>I wonder if you can run it at that stage.

<mwette>I would try (use-modules (system base compile)) (compile-file ...)

<ekaitz>hm!

<mwette>no luck?

<ekaitz>i'm trying to understan what we have in meta but I'm not sure about it

<mwette>lemme look

<ekaitz>yeah I can replicate the issue there

<ekaitz>with the guile in meta

<mwette>good

<ekaitz>but the gdb has to be multiarch i think

<rlb>ArneBab: oh, I mostly meant when people are creating the messages. And in truth, I still often just use gitk for "flipping through" changes (got used to it).

<mwette>ekaitz: it's segfaulting in code generated by the JIT?

<ekaitz>mwette: i don't see anything very well because I need to put a gdb on top

<ekaitz>the one you suggested fails in gdb

<ekaitz>and I don't see a proper trace

<mwette>Ok. I'm trying to see if I can get something working.

<ekaitz> http://github.com/ekaitz-zarraga/Guile <-- this is the repo i'm using

<mwette>I don't understand the bootstrap process much.

<ekaitz>I literally just pasted the lightening on top of Guile and enabled JIT on riscv64

<mwette>It works w/o the JIT? You can generate compiled non-JIT modules?

<ekaitz>mwette: i can build if i --disable-jit

<ekaitz>yes

<mwette>Did you try with GUILE_JIT_THRESHOLD=-1 (in configure and make I guess) ? That would compile it in but hopefully not use it for building. Then you could try isolated tests. Just guessing here.

<ekaitz>oh that's a good one

<ekaitz>i'll try that

<ekaitz>i'm also running a build in real hardware right now

<mwette>what hardware? just curious. I have visionfive2 but it's hosed right now.

<mwette>And I have ordered a Microchip PIC64GX1000 eval board

<ekaitz>a visionfive2

<ekaitz>hehe

<ekaitz>it's the one i've been using for the Guix riscv boostrap work

<mwette>OK. With debian? I tried someone's posted Ubuntu instructions and now my networking does not work in uboot.

<ekaitz>yes! debian and Guix as a package manager on the top

<ekaitz>guix needs some funny things but efraim helped me install it

<mwette>sweet

<ekaitz>mwette: are you interested on RISC-V thingies? we are almost boostrapping Guix on it too

<ekaitz>I spent like the last 3 years fixing compilers and stuff for it :)

<lampilelo>i tried installing guix on arch one time and it was a shitshow of binaries loading the wrong libc or programs compiling with wrong libraries and it was kinda impossible for me to maintain a double environment like that

<mwette>You and efraim and janneke ? I have been interested, but recently other things have taken over.

<ekaitz>mwette: and stikonas too, yeah

<ekaitz>lampilelo: yeah sometimes it's hard to deal with, but it's helping make Guile popular so... good things happened thanks to Guix too

<mwette>I am going to try guix foreign again in near future. I have new minipc w/ Ubuntu, which has a guix package (rlb influence?).

<ekaitz>in this very moment i'm in a machine running guix, i started with it as a package manager but shortly after went all in

<rlb>...not wrt guix -- still relatively inexperienced on that front. Though I guess to the extent it needs guile, perhaps a little :)

<ekaitz>the other day i talked with some guix people that we should use guix more like an excuse to help in guile

<ekaitz>because we are too guile dependent, and guile deserves a little bit more of love

<lampilelo>ekaitz: i need to try bare guixsd someday, i really like the idea but it's a pretty big time investment into learning it all and fiddling with it

<ekaitz>lampilelo: only if you like configuring, I hate configuring so I just do it once and don't touch things again :)

<ekaitz>also if anything fails you can rollback hehe

<lampilelo>i always break things because i poke around a lot, i actually stopped using it after it broke so hard that the rollback couldn't complete and i still don't know why

<lampilelo>btw, i think it's cool that you're working on guile being usable on risc-v, it's nice to see guile having some forward momentum

<janneke>ekaitz: talking about PEG, have you seen https://mail.gnu.org/archive/html/guile-devel/2020-05/msg00010.html ?

<janneke>(it's an early version of patches against PEG that we use in dezyne)

<ekaitz>janneke: i didn't but it's cool to see that! did you take a look to my patches?

<ekaitz>probably yours is way better

<ekaitz>you didn't get any feedback that time?

<janneke>only superficially, i think the patch sets do complementary things?

<janneke>ekaitz: the [^...] might come in handy

<janneke>ekaitz: no, that's why regtur didn't sent the broken-up versions, also i believe he made other enhancements later

<ekaitz>i'll try to read it deeply and see if I can enhance mine with it

<ekaitz>and improve it to make it prod-ready

<ekaitz>it's kind of a shame the current status of the PEG parser... it's not even PEG compatible :)

<janneke>ekaitz: in that case i would recommend to look at https://git.savannah.nongnu.org/cgit/dezyne.git/tree/dzn/peg and diff it with your/guile's version

<ekaitz>heh, but if you didn't manage to make it to guile, i don't think I'll be able to do it

<janneke>especially the whitespace skiping and locations were important; they could be separated patches

<janneke>the fallback parser is another orthogonal feature that's used for interactive completion

<janneke>we just never found the time to work on it and it helps if there are other users / interested people

<ekaitz>alright, let's do it then

<ekaitz>tomorrow I'm probably change from being not very busy to being very busy, but I'll see what I can do

<ekaitz>I'm stubborn, that usually helps

<janneke>i'll see if i can dig up the different patches, or possibly recreate them

<ekaitz>oh great, if it is easier, send them to me via email

<ekaitz>oh janneke but this commit is superinteresting! Rutger added error reporting!

<ekaitz>skips and error reporting! this is not overlapping with what i did, and it's certainly very useful

<janneke>ekaitz: yeah

<ekaitz>mwette: cross-compiling let's me use gdb easier!

<ekaitz>uh but i don't see anything in the trace

<ekaitz>damn

<mwette>ekaitz: I could not get a build-phase guile going with gdb.

<ekaitz>:(

<mwette>I keep getting error: "load-thunk-from-memory" "incompatible bytecode version"

<ekaitz>mwette: i'm trying the GUILE_JIT_THRESHOLD=-1 now, but it'll take some time

<mwette>trying it on x86_64 to see if it works. I also added GUILE_JIT_LOG=2 to the make.

<ekaitz>looks like exporting the GUILE_JIT_THRESHOLD is enough, right?

<mwette>so far looks OK

<mwette>I see the jit symbols in libguile.so and don't see any jit log messages coming.

<mwette>nm libguile/.libs/libguile-3.0.so | grep jit

<ekaitz>so if I do that how should I test it afterwards?

<ekaitz>i'm not sure if i understood 100%

<mwette>GUILE_JIT_THRESHOLD=0

<mwette>create a file to compile, meta/gdb-uninstalled-guile, (use (system base compile)) (compile-file "foo.scm" #:to 'bytecode) or something like tht

<ekaitz>oh ok

<ekaitz>we'll see if I have a proper stacktrace there

<ekaitz>mwette: i think i know what's going on, but i don't know why

<ekaitz>it's writing instructions out of the allocated code arena

<ekaitz>ofc segfault

<mwette>Do you mean new code is overwriting allocated code space?

<ekaitz>i mean there is an arena for the JIT result and the JIT is writing instructions passed the end of it

<ekaitz>it's writing outside

<mwette>ahh, that doesn't sound good

<ekaitz> https://gitlab.com/wingo/lightening/-/merge_requests/14#note_2156587809

<ekaitz>that shows the output with GUILE_JIT_LOG=3

<ekaitz>i made the math of the arena addresses and where it was trying to write the latest instruction

<ekaitz>(i'm an engineer so probably i did the math wrong)

<ekaitz>this may explain why the tests of the lib pass and this doesn't

<ekaitz>oh yeah i did the math wrong

<ekaitz>bad copy-paste

IRC channel logs

2024-10-13.log