IRC channel logs


back to list of logs

<lampilelo>hmmm... setting LD_LIBRARY_PATH from inside the scm file and then calling load-extension doesn't work for me with guile 3.0.6
<lampilelo>it works when i set it from the shell before executing
<lampilelo>why wouldn't it work then?
***sneek_ is now known as sneek
<dustyweb>abralek: yay :)
<mwette>lampilelo: Lately I always use #!/bin/sh / set envs / exec guile $0 "$@" !#
<flatwhatson>Greetings, I've been digging into why test-out-of-memory fails on my system.
<flatwhatson>It seems like lazy creation of the finalizer thread is the culprit. Is there a way to block until the finalizer thread is started before continuing the test?
<flatwhatson>I guess the fact that we can't catch out-of-memory until that thread is running is a genuine bug?
<flatwhatson>Nope, red herring. The problem is mmap(PROT_NONE) failed in GC_unmap.
<flatwhatson>So... building with a libgc with --disable-munmap works, as does this patch:
<flatwhatson>RFC on a patch for libgc which makes a failing GC_unmap non-fatal:
<flatwhatson>This allows test-out-of-memory to pass, without crippling gc's unmapping in non-exhausted scenarios
<rlb>wingo: wondering (again) about whether it'd be worth the complexity to preserve mutable non-ascii strings in a utf-8 implementation, i.e. I think maybe the only time you could take advantage of it is when you know you're making changes that don't shift *any* character offsets, e.g. (string-set x 11 some-char-thats-the-same-length). Otherwise we just derive a new stringbuf.
<rlb>Currently inclining toward thinking it might not be worth the complexity.
<wingo>rlb: hard to say. actually i think maybe in a utf-8 world it can make sense to penalize string-set! in this way
<rlb>...ascii strings are a different matter, i.e. might be a common enough case to be worth it, though I suppose it does create an algorithmic-complexity "cliff" that might be surprising if you don't know about it.
<wingo>mutable strings in scheme are a bug, of course :)
<rlb>heh, would certainly make my hacking easier if we didn't have all the flavors :)
<rlb>(atm I've kept the mutable flag, and have kept mutability in some cases where it was easy for ascii strings...)
<wingo>flatwhatson: why does the mmap(PROT_NONE) fail?
<wingo>rlb: yeah practically speaking we have to support mutable strings
<wingo>to not break user code, and to not break too much with the standards
<rlb>i.e. if you string-map!, it was an incoming ascii string, and the resulting char length is still equal to the byte length, we can just clobber the stringbuf contents...
<wingo>but if you were designing scheme now, you would not include mutable strings :)
<rlb>but to do that for a non-ascii string, we'd also have to check that the char sizes stayed the same, and that seems unlikely, and isn't free like it is for ascii.
<rlb>(of course it *would* be less complex to just ignore the optimization for ascii too)
<flatwhatson>wingo: mmap fails with ENOMEM, which is frustrating as that call should actually *free* some space
<wingo>wow :)
<wingo>i can't think of a situation in which you would want that to be a fatal error fwiw
*rlb wonders if that might be one of the tests he's marked unreliable for the debian buildds, but will have to look later...
<flatwhatson>yeah I'm fairly sure that it is, though I'm not sure how long it's been failing and on what systems
<wingo>flatwhatson: what about seeing if upstream would take a patch that just does s/ABORT/WARN/ if that mmap(PROT_NONE) fails?
<flatwhatson>the problem is it flags that block as unmapped, and tries to remap it later which also aborts
<flatwhatson>hence my patch above which just leaves the block marked as mapped
<flatwhatson>replacing the mmap(PROT_NONE) with an munmap kinda worked, but would also fail later in GC_remap
<flatwhatson>anyway I guess it's pretty clearly an upstream problem, will gather my thoughts and hassle them instead :)
<wingo>flatwhatson: yeah sorry to not be more helpful :) libgc aborting guile is not a great situation!
<rlb>hmm, I suppose a better reason to consider never creating non-ascii mutable stringbufs is that by doing so, you avoid O(n) substring operations, while only giving up some unlikely optimizations...
<rlb>(O(n) when creating a substring of the mutable stringbuf)
<lampilelo>what's going on with geiser on guile 3.0.6? first it writes garbage to dbg buffer:
<lampilelo>While executing meta-command:
<lampilelo>Wrong type to apply: #<unspecified>
<lampilelo>so i thought "let's update geiser" and now it shows it twice but prepending with additional "retort-syntax"
<lampilelo>when i write 'display to a buffer and use C-x C-e it evals it and then some, writing "Wrong number of arguments to #<procedure display (_ #:optional _)>"
<lampilelo>can anyone confirm it's not just my issue?
*wingo is usually breaking his guile so is rarely able to test geiser
<lampilelo>i'm not sure if it broke after updating guile or my system packages
<lampilelo>maybe there was an abi break in one of them or something, i'll recompile to be sure
<lampilelo>yeah, it's still broken
<tohoyn>sneek: botsnack
<flatwhatson>huh, turns out that mprotect(PROT_NONE) works where mmap(PROT_NONE) fails!
<flatwhatson>there's already a code path used on CYGWIN32|AIX|HPUX|HAIKU... almost seems like it should really be the default
<lampilelo>wingo: did something related to repl change between versions? geiser works fine with 3.0.5
<lampilelo>or more specifically to the repl server
<lloda>lampilelo: i've pushed your srfi-64 patch
<lampilelo>lloda: oh, thanks
<lampilelo>that's kinda unexpected since i didn't say anything, but very appreciated
<lampilelo>come to think of it, i did mention it but thought no one read it
<civodul>flatwhatson: those mmap(PROT_NONE) warnings are scary
<civodul>that's a libgc 8.x thing, and it's not clear when/why it happens
***meo is now known as o_o
***o_o is now known as meo
<flatwhatson>civodul: oh, I haven't seen those, I've just been chasing a failing test-out-of-memory, but possibly related? any more details?
<wingo>lampilelo: don't think so
<meo>if I have an array inside an immutable record, should I deep copy it and modify the copy and return it as a part of the derivative record?
<civodul>flatwhatson: not really; it's a thing we've seen occasionally in Guix, but it's not clear to me how to reproduce it
<civodul>it seemed to be a "new feature" of libgc 8.x
<lloda>there's zero source info when an error happens during autocompilation
<lloda>the workaround i have is to compile the file manually with compile-file
<taw10>meo: it depends on what you're doing. It's OK (in theory, at least) to have an immutable record which references mutable things, but it will probably be simpler to consider everything immutable and do what you said.
<meo>taw10: i'm trying, the result is I now have functions that modify values of individual fields and a function that does this for several fields and recurses over a list
<meo>i guess these are the wonders of functional programming
<meo>any reason not to use ice-9 poe?
<lampilelo>took me long enough but i confirmed geiser and guile 3.0.6 don't play well together, tested on a fresh ubuntu docker image
<abralek>dustyweb: In order to make 8sync work for me with fiber I had to CPed janneke's commits from master and also amend few of them. Those commits are for cross-compiling. Do you have any plans to merge the branch or something?
<dustyweb>abralek: hm I could probably do that
<dustyweb>abralek: but probably not today
<dustyweb>abralek: as in, it would be a good idea for me to do that ;)
<abralek>dustyweb: (<- dustyweb 'thanks)
<dustyweb>abralek: which janneke commits from master did you mean btw?
<abralek>1dc3b6a * guix: Use guile-3.0.
<abralek>d06b7be * build: Support cross building.
<abralek>ac631e0 * build: Prepare for guile 3.
<abralek>He did more btw.
<wingo>lloda: is that a change relative to before?
<dsmith-work>UGT Greetings, Guilers
<dustyweb>abralek: where did you get the patches?
<abralek>dustyweb: ah, sorry, this is my amended fiber branch.
<abralek>d41139a * build: Support cross building.
<abralek>e94593c * build: Prepare for guile 3.
<dustyweb>abralek: maybe you could push the branch somewhere?
<abralek>dustyweb: fibers branch
<lloda>wingo: the srfi-64 patch?
<lloda>it was applied upstream
<lloda>oh sorry
<lloda>you mean the lack of source info
<lloda>no I don't think there was ever source info for those errors
<manumanumanu>rlb, wingo : regarding strings: I have thought about something like a persistent vector for strings. Each leaf stores a bytevector of N characters, whereas the rest can use 32-way branching. That could give O(1)-ish string-set, pretty fast iteration, yet OK string-ref - while still being pretty compact.
<manumanumanu>with moderately efficient prepend, and o(1) append with transients. Together with the SRFI for string cursors it might actually not be completely awful as a string representation.
<manumanumanu>but maybe I'm just overthinking it...
<manumanumanu>the downside is that you get not all of the benefits of ropes, but with only some of the downsides.
<manumanumanu>but alas, it is overkill unless you want adjustable length.
<dustyweb>abralek: ty
***DadeBonetti1 is now known as DadeBonetti
<rlb>manumanumanu: ahh, right, I thought about some of that too, though I'd thought we were leaning in favor of wanting the internal representation to be utf-8. If not, then sure, could definitely do even fancier things.
<rlb>(...and I should stop poking at my current mess :) )