IRC channel logs


back to list of logs

<thomassgn>I need some way of using inotify or similar, are there any libraries for this? or where can I search for modules? my searches turn up very little
<dsmith>thomassgn: No idea how good this is, but did you see this?
<dsmith>5 years old
<dsmith>thomassgn: And then there is this ffi thread from 2 years ago:
<thomassgn>dsmith: nice, thanks. Does guile have some sort of 'package' db or standard way of installing modules/libraries?
<dsmith>thomassgn: It's been attempted several times. I think the current vogue is to use guix.
<davexunit>paroneayea: neat!
<davexunit>cool that you got to interview them :)
<dsmith>thomassgn: Which is
<thomassgn>dsmith: allright, that's the reason I'm investing in guile now, am slowly migrating to guixsd :)
<dsmith>I really should look into guix. But old habits die hard.
<OrangeShark>thomassgn: someone maintains a pretty good list of various guile projects at
<davexunit>ACTION unboxed f64 comparison patch sent to guile-devel
<lloda>wingo: ok to push (gc msg deadlock fix) and (workaround for bug #24908, or at least the test)
<sneek>Welcome back lloda, you have 1 message.
<sneek>lloda, efraim says: should we switch gcc-boot0 from gmp-6.0.0a to gmp-6.1.0?
<lloda>efraim: I can't tell what this is about :-/ maybe you mean it for someone else?
<wingo>lloda: first patch LGTM, in the future please put full sentences in comments starting with capital letter and finishing with period; also scm_fluid_ref() only *might* take the alloc lock fwiw but that's not an important correction to make
<wingo>scm_fluid_ref might have taken the alloc lock in the past too i think but it was much less likely
<lloda>I can fix the commit np
<wingo>lloda: second one probably is not the right thing, can you add a test instead and i can fix the compiler or disable the pass that caused it to start failing?
<wingo>compiler bugs are important to fix because you are lucky when you find them :)
<lloda>there's a test included, I can commit the test only or just wait
<wingo>well, let me take a look at it
<efraim>lloda: sorry it was supposed to go to civodul
<lloda>ah, np :)
<lloda>pushed the gc message patch
<wingo>great tx
<lloda>thank you!
<wingo>lloda: the test passes for me without patches
<wingo>i wonder why that is
<wingo>lloda: the test is simple (string=? "10." (format #f "~2f" 9.9)) right?
<wingo>having used (ice-9 format)
<lloda>yes :-O
<lloda>daviid confirmed it a while back :-|
<wingo>lloda: you are on x86-64 i assume
<lloda>Nov 5, according to the log
<lloda>yes I am
<wingo>what if you revert your patch, does the bug still reproduce for you
<lloda>I'll try again now
<lloda>yup, fails w/o the patch
<lloda>scheme@(guile-user)> (string=? "10." (format #f "~2f" 9.9))
<lloda>ice-9/format.scm:1525:37: In procedure format:fn-round:
<lloda>ice-9/format.scm:1525:37: In procedure string-ref: Value out of range: 18446744073709551615
<wingo>strange, it succeeds here
<wingo>ah maybe i need to recompile format.scm
<wingo>fails here too
<wingo>now to reduce the test case
<lloda>the error went away if I did (pk (- i 1)) instead of (- i 1) in the 1st (do ...) clause. There are lots of globals, when I tried to make it fail outside, I could not.
<lloda>I mean in format:fn-round
<wingo>the function is a bit too big to analyze the bytecode, i need to pare it down
<wingo>format is ridiculously big
<thomassgn>OrangeShark: Awesome, thanks.
<lloda>is there a way to throw away the $nn arguments in the repl, to free memory?
<taylan>lloda: found it: (info "(guile) Value History")
<taylan>(I knew it exists but had forgotten how)
<taylan>(needs ,use (ice-9 history))
<lloda>oh thank you! you saved my session
<lloda>ACTION sticks a postit
<dsmith>{appropriate time} Greetings, Guilers
<wingo>lloda: i know more or less what the problem is now, tx for the report
<wingo>forthe format thing
<davexunit>wingo: good morning. I sent the f64 comparison patch to guile-devel.
<davexunit>I forgot to add docs the first time, so check out the second patch in the thread for that.
<davexunit>wingo: I couldn't find a place where I would add tests for this stuff. let me know if there is something I should do in that regard.
<davexunit>oh, and FSF already has my copyright assignment papers for guile so no blocker there. ;)
<civodul>wingo, mark_weaver: i'm highly tempted to apply mark_weaver's patch with janneke's adjustments for
<sneek>civodul, you have 1 message.
<sneek>civodul, ng0 says: adding to my last sentence, yes I will try to get to some constructive solutions if possible.
<civodul>wingo, mark_weaver: thoughts?
<civodul>the patch looks reasonable and we can always do further testing
<wingo>sgtm in general
<wingo>ACTION does not want to block it :)
<janneke>civodul: yay...note that it now looks almost deterministic, we're not there yet
<civodul>janneke: yeah i've noticed your comments
<janneke>great that you pick this up!
<civodul>we'll fix the other issues afterwards, one thing at a time :-)
<civodul>i guess each one of us was thinking that someone else would do it ;-)
<lloda>wingo: thank you for looking into it, it did cause me a bit of trouble
<civodul>wingo: the patch adds a field to the module record type; could that be a problem?
<wingo>civodul: for 2.0? i think not, if the field was added at the end
<wingo>civodul: will you port the patch to 2.2 as well please? :-)
<civodul>yeah for 2.0, and yes it's added at the end
<wingo>tx :-)
<civodul>mark_weaver: you explicitly wrote that "you're not confident in its correctness", but you haven't replied to janneke etc.
<civodul>it seems correct to me and i'd like to leave you as the author
<civodul>please speak up if you don't want to!
<wingo>lloda: just pushed a fix
<wingo>tx again for the report
<janneke>ACTION needs to run
<paroneayea>huh, nice
<paroneayea>looks like I might have fixed the bug I mentioned with the "fretting to death" stack limit issue in 8sync
<paroneayea>with a different refactoring step
<paroneayea>two in one!
<paroneayea>I feel good about that.
<paroneayea>I removed the sleep timer on the character's loop and it's been running for 5 minutes
<paroneayea>no memory growth
<paroneayea>well nothing that doesn't get GC'ed back away that is :)
<janneke>yay! for fixing bugs by refactoring
***profan is now known as profernicus
***profernicus is now known as profan
<amz3>I am the only one to be unable to call (setlocale LC_ALL "") on guile 2.1.4 ?
<amz3>(using guix)
<amz3>What's the difference between #vu8 and #u8?
<amz3>I have a program that returns #u8 under guile 2.0.11 and #vu8 in guile 2.1.4
<amz3>from ffi call
<amz3>oops! forget the last question I was relying on bug on my side
<amz3>still what's the difference between #vu8 and #u8?
<amz3>both return #t with bytevector? from (rnrs bytevectors)
<ft>The "Array Syntax" part of the manual states that #u8() is a uniform array and "In addition, bytevectors are also arrays, but use a different syntax". Which sounds like they are pretty much the same.