***jao is now known as Guest64080
***Guest64080 is now known as jao`
***jao` is now known as jao
<fnstudio>Hi, if I were looking for something comparable to Python f-strings, where should I start from? <fnstudio>or something comparable to Python's `.format()` <fnstudio>i.e. a way of injecting variables in a string ***ng0_ is now known as ng0
<rlb>And of course it'd be nice if we can track down the failures on the non-release archtectures too... <rlb>Do we expect the build time on non-jit platforms to be about the same as 2.2? <jonsger>rlb: I think the build time on non-jit platforms is longer then on 2.2. That's at least my impression <rlb>Yeah, was asking because it looks like some may have been coming in a 7h vs 3h for mips64el, but there may also be buildd host differences... <rlb>Looks like you saw an illegal instruction where the deb saw a segmentation fault? <jonsger>our armv7l build is in qemu of aarch64 builders. Is "hasse" a native armel build node? <jonsger>maybe I just should setup the little armv7 board I have on my desk :P <rlb>Looked like s390x might not have even made it through configure -- maybe I'll poke at that one first. Had trouble in the past with s390 (though I think that was emacs) because it was a 31-bit arch, but s390x shouldn't have that issue iirc. <rlb>ok, thanks. Sometimes it's also the default debian build options -- we've had to omit some in the past. <rlb>e.g. maybe stack-protector? <rlb>jonsger: ok, thanks again. <jonsger>without HDMI cable, SD card and u-boot image for the board it seems to be pretty hard <drakonis>what's the current guile package manager? <drakonis>is it still guildhall or guix replaced it? <jonsger>drakonis: I think guildhall is not really used anymore, so kind of replaced by guix :) <civodul>rlb: great that guile-3.0 was approved for Debian! <civodul>there's a couple of bugs to address on ARMv7 and AArch64, but yeah, we'll get there <stis>please also the nasty bug#39315 <civodul>dsmith-work: there were talks about things around Guile, but only one on Guile proper i guess <civodul>i find it nice to see all these things being done with Guile! <civodul>in a way we're all shamelessly taking advantage of Guile goodness :-) <dsmith-work>I have *never* gotten anything building, let alone working, with yocto. <jonsger>rlb: did you made progress on armel? <rlb>jonsger: no - haven't had time to mess with it yet, and may not for a bit. <rlb>i.e. might be "days". <jonsger>oke, then I'll just open a bug. As I'm struggling hard to get an armv7l qemu guest running on aarch64... <rlb>when I get around to it, I can test directly on a porterbox, which may or may not help me :) <sneek>.oO( Hours seem like days... ) <rekado>I’m working on the Guix Workflow Language again and the compilation of my modules takes a *very* long time. <rekado>They are not complicated modules at all. <rekado>The modules use GOOPS, so I think that might be why; but is there a way to profile the compiler and figure out what is taking so long? <rekado>the test suite also runs very slowly even though the tests are rather simple. <civodul>rekado: you could try: ,pr (compile-file "...") <civodul>or perhaps ,time to start with (to see if it's a GC issue) <rekado>huh, it takes mere seconds when comping like that. <civodul>oh, could it be that you're evaluating many of your dependencies? <civodul>e.g., because GUILE_LOAD_COMPILED_PATH isn't correct <rekado>I really wanted to attend. I missed the energy, the collaboration, and the joy of meeting fellow Guix hackers. <rekado>I’m looking forward to reports from the Guix Days and FOSDEM <civodul>yes, we'll hopefully send notes soon <MutoShack>Is there a way to output "<!-- -->" HTML comments from sxml->xml ? <RhodiumToad>you can put a procedure in the sxml tree, which will be called with output directed to the appropriate port <MutoShack>Thanks, RhodiumToad. I'm in no hurry, so I'll just put it in my todo list for now!