IRC channel logs

2020-03-15.log

back to list of logs

<rlb>It looks like more or less all the files in guile-3.0-dev are now versions except aclocal/guile.m4. I'm guessing that's intentionally "shared"/cross-version and you'd normally want the newest one, so I should perhaps either put it in a separate guile-X.Y-autotools package, or just handle it via update-alternatives?
<rlb>(Oh, and context here is wrt the debian packages.)
<rlb>The latter approach might be a bit less desirable if we don't want an update-alternatives call to select say 2.2, instead of 3.0, to also downgrade the guile.m4.
<rlb>sneek: later tell civodul any idea if that bug you just fixed might cause the "Aborted" failures we're seeing?
<sneek>Will do.
<daviid>mwette: I don't know a good tutorial about GObject memory layout
<daviid>i confess I don't understnd what you're trying to acheive, but i suggets you speak to str1ngs, wh know better then i how to make things so that they become instrospectable, then, g-golf or any other language can use it ...
***catonano_ is now known as catonano
***jonsger1 is now known as jonsger
<str1ngs>mwette I don't have a backlog here. I just have daviid's comment were you needing to create a custom GObject or something?
<gagbo>Hello, is there a way to append stuff to a vector ? Or should I really create a new vector and allocate it correctly from the start (if I want to (append vec '(lot of stuff))) )
<RhodiumToad>vectors are supposed to be fixed lengths, no?
<RhodiumToad>quoth the manual, "Unlike lists, the length of a vector, once the vector is created, cannot be changed."
<gagbo>fair enough, I wondered if there was some function that created a vector filling the first n spots with a copy of the previous one
<RhodiumToad>srfi-43 has a command to copy one vector to part of another one
<RhodiumToad>(vector-copy oldvec 0 newlen)
<gagbo>I was weirded out because I forgot to evaluate my buffer in emacs once I added (srfi-43). Thanks again for reading the docs better than I do :)
<stis>hej guilers!
<civodul><sneek> civodul, rlb says: any idea if that bug you just fixed might cause the
<civodul> "Aborted" failures we're seeing?
<civodul>rlb: what "Aborted" failures are you talking about?
<rlb>civodul: https://buildd.debian.org/status/fetch.php?pkg=guile-3.0&arch=i386&ver=3.0.0%2B1-6&stamp=1584209247&raw=0
<rlb>I finally got all the archs building, just not at the same time :) i.e. once I fixed the failures that disabling the jit appears to fix, that happened on i386, which had been "fine" for the previous 5 builds of the same version :) https://buildd.debian.org/status/package.php?p=guile-3.0
<rlb>e.g. https://buildd.debian.org/status/logs.php?pkg=guile-3.0&arch=i386
<rlb>civodul: and I didn't realize sneek could only remember one thing at a time... Also previously -- my "clever" plan to make a more efficient pcre2 wrapper might not work out for common cases. So far it doesn't look like pcre2 can be asked to treat an ios-8859-1 byte sequence as a unicode subset, i.e. for byte-width units, it looks like it can only do utf-8 or "not unicode" with somewhat differing behaviors.
<dsmith>rl
<dsmith>rlb: YEah, if you tell the bot to "remember" something more than once, it randomly grabs one of them.
<dsmith>sneek: foo is bar
<sneek>Okay.
<dsmith>sneek: foo is baz
<sneek>Okay.
<dsmith>sneek: foo is zap
<sneek>Understood.
<dsmith>sneek: foo?
<sneek>From what I understand, foo is zap
<dsmith>sneek: foo?
<sneek>I could be wrong, but foo is zap
<dsmith>sneek: foo?
<sneek>Last time I checked foo is baz
<dsmith>sneek: foo?
<sneek>From what I understand, foo is possibly sane
<dsmith>sneek: foo?
<sneek>foo is not sane
<dsmith>sneek: foo?
<sneek>I could be wrong, but foo is possibly sane
<dsmith>sneek: forget foo
<sneek>Okay.
<dsmith>sneek: foo?
<dsmith>But it forgets all.
<dsmith>sneek: foo?
<civodul>rlb: re crashes, you should try 3.0.1 + patch for https://issues.guix.gnu.org/issue/39266
<civodul>we'll probably make a 3.0.2 soonish
<rlb>civodul: hah, right, that's exactly what I was asking.
<rlb>civodul: and for now I ended up disabling the jit on armel, armhf and x32 (basically wherever I saw what looked like the same "Segfault" (not the "Aborted"). Does that sound appropriate for now?
<civodul>rlb: that's an option, but the best one is the one above IMO :-)
<civodul>that's what we did in Guix, and now all arches pass fine (well, it's just: x86_64, i686, armv7, aarch64)
<rlb>Ahh, ok, so your fix might well resolve the same problems that disabling the jit did -- if so that's excellent, and I'll plan to try it soon.
<rlb>(And thanks for the info.)
<rlb>...ok, think I may have figured out the arrangements to allow installing multiple guile-X.Y-dev debs at the same time -- under the assumption that guile.m4 is meant to be "shared", and we'll handle it via update-alternatives (separately from everything else, so that even if you change the guile-config, etc. alternative, it won't affect the m4).
<civodul>rlb: yeah, we were seeing a segfault on ARMv7 with JIT enabled that this patch fixed
<civodul>there's quite a few bugs that were merged if you look at the top of the page
<civodul>always pleasant :-)
<rlb>yeah, I'm finishing up some issues with the 2.2.6 and 3.0.0 debs, and then I'm going to see about merging the new releases.