<daviid>dsmith-work: if you don't mind, we should close bug#43025 - the bug msg is inadequate, and the answers gives the impressinon it is a 'problem', instead of a high severity bug, a regression imo, related to a guile core supported functionality that somewhere somehow, got 'broken' susequently to module and/or compiler changes - i'd re-open it with a proper message and the above snipset to reproduce ... wdyt? <rlb>sneek: later tell civodul guile-3.0 3.0.5-3 is in debian unstable now, with the gmp fix -- thanks again <akira121>Hello, how can I split my code in multiple files? I've been trying to `define-module` and `use-modules` but it says `no code for module (prefix)`. <flatwhatson>Problem is, I'm still seeing the corruption occurring with the latest guile from git. Likewise if I build 3.0.5 patched with scm_install_gmp_memory_functions = 0 <flatwhatson>Running with guile 3.0.0, everything works correctly. So I'm not sure the current fix is sufficient? <wingo>flatwhatson: what about guile 3.0.4 ? <wingo>i don't really know how to isolate this issue without bisecting <wingo>unless you want to record in RR, set a hardware watchpoint on the bad address, and then run backwards <flatwhatson>Ah sure, I can test against other release builds, I'll get back in a few hours. <flatwhatson>I don't understand "record in RR", happy to try to pin things down in gdb but I'll need some hand holding. <ArneBab>daviid: ah, it’s been reported already — sorry. <civodul>rlb: thanks for the Debian upload with the GMP fix! <wingo>ArneBab: not a bug -- gperf is only used if you are building from git <wingo>the output of gperf is included in tarballs <wingo>in the same way we don't have a way to check for e.g. autoconf <wingo>so, if you build from git, you'll need gperf, is all <ArneBab>wingo: would a patch be accepted that checks in configure whether we are building from git? <ArneBab>the shortest version: we need at least one of .tarball-version and gperf <wingo>i would not add a check in configure, fwiw <civodul>perhaps we can use AM_MISSING_PROG or whatever it's called for gperf ***chrislck_ is now known as chrislck
<wingo>but it's not needed when configure is run <wingo>or does that make autoconf itself check for gperf? <wingo>anyway to me is a non-problem <RhodiumToad>for comparison, what postgres does for bison/flex is check for them in autoconf, but if they're not found, it just gives a warning about how you only need them if building from git or modifying the grammar <civodul>wingo: yeah i agree it's a non-issue <civodul>AM_MISSING_PROG is just to display a nice message in case the thing is not found <lloda>now in Guile every error gets reported as <lloda>"ice-9/boot-9.scm":1686:16: In procedure raise-exception: <lloda>i don't remember when the change happened, I think 3.0? but it was different before <lloda>it would tell you where the error actually happened <civodul>lloda: the backtrace should have more info though, no? <lloda>sure, but before you'd know where the error happened without needing to look at the bt <lloda>i mean that line is always the same boot-9.scm point <lloda>it doesn't say anything useful <flatwhatson>re: gnutls, i've confirmed that 3.0.1 and 3.0.4 are also showing the bug <flatwhatson>was struggling to reproduce, but remembered i'd turned off gnutls debug logging <flatwhatson>all the extra garbage from printing gnutls logs makes that error apper much sooner <lloda>i've lost track a bit of the different kinds of exceptions there are now tbh <RhodiumToad>in 3.x there's only one kind of exception now, iirc? <lloda>i need to do some reading then <lloda>i'm used to just throwing symbols <lloda>if throw/catch are out and raise-exception/with-exception-handler are in, i'd say we've lost something in quality of naming <lloda>the manual seems clear, i just never looked at this section before <lloda>i'd say there's some redundancy? if you were doing this from scratch, you probably wouldn't have so many functions <tohoyn>lloda: there is also the guard form you can use instead of with-exception-handler <flatwhatson>replay fails with "Assertion `ticks_now == trace_ticks' failed to hold. ticks mismatch for 'SYSCALL: mmap'" ***janneke_ is now known as janneke`
<wingo>flatwhatson: when i have used it it works for me fwiw <wingo>flatwhatson: are you on amd, perhaps? <wingo>i assume you're on amd64 but wondering if you are on intel or amd hardware <wingo>lloda: yeah the exception situation is a bit of a mess <wingo>maybe that can be part of 3.0.7, to improve a number of specific errors, and possibly to switch more things to structured exceptions <wingo>while still guaranteeing throw/catch compat <wingo>but still the source location should be fixed, i agree <wingo>flatwhatson: if you run with GUILE_JIT_THRESHOLD=-1, does the problem still show up? ***janneke` is now known as janneke
<flatwhatson>wingo: i'm on intel, using guix environments for testing <flatwhatson>"Tracee is using the syscallbuf signal (SIGPWR)" "Try recording with --syscall-buffer-sig=<UNUSED SIGNAL>" <wingo>could be i haven't used rr in a while <wingo>in that case yeah you might have to choose another signal, as libgc is using SIGPWR i think ***taw10_ is now known as taw10
<flatwhatson>seems there have been a few similar-looking issues on rr, i probably just need to report it <wingo>sounds like a frustrating experience <civodul>flatwhatson: FWIW i have to pass -n to "rr record" <flatwhatson>on the bisection front, 3.0.0 works and 3.0.1 doesn't <flatwhatson>patching 3.0.1 with scm_install_gmp_memory_functions = 0 doesn't work <flatwhatson>looks like scm_install_gmp_memory_functions actually only controls installation of a finalizer, and not installation of the custom gmp allocation routines <flatwhatson>oh, derp, it does control installation of those routines... <wingo>but probably if !scm_install_gmp_memory_functions, we should allocate pointerless data... <wingo>i wonder if scm_i_clonebig needs a scm_remember_upto_here_1 ***aweinsto1k is now known as aweinstock
<flatwhatson>also tried 3.0.0 with scm_install_gmp_memory_functions = 0 and that *does* work <flatwhatson>struggling to see what the difference between that and the patch i linked would be... <wingo>flatwhatson: the problem exhibits itself with stock gnutls ? <wingo>i.e. just with guile-gnutls? <wingo>flatwhatson: regarding scm_install_gmp_memory_functions = 0 or not, perhaps try using scm_gc_malloc_pointerless instead of scm_gc_malloc if !scm_install_gmp_memory_functions <wingo>i thought you tried adding scm_remember_upto_here_1 (src_big) to scm_i_clonebig <flatwhatson>and yes, I get the problem running under guix environment --pure guile gnutls guile-fibers <flatwhatson>that's since evolved into a manifest with various versions & patches of guile <flatwhatson>civodul: that works!! rr record --no-syscall-buffer --syscall-buffer-sig=12 guile path/to/script.scm ... <daviid>dsmith-work: ok, could you close it then, then i'll re-open a 'more specific' bug report, tx! <dsmith-work>daviid: If you open a more-specifc report first, I could reference that. <daviid>dsmith-work: ah ok, let's do that indeed, will ping you, have to go afk for 1h or so ... bbl ***sneek_ is now known as sneek
<mdevos>Why are directory streams called "directory port" in filesys.h <mdevos> (SCM_VALIDATE_DIR) even though they aren't ports? (port? (opendir <wingo>ahaahahahahahahahaha gnutls.scm ends with ";;; arch-tag: 3394732c-d9fa-48dd-a093-9fba3a325b8b" <wingo>imagine ";; this file ends here", but including the name of the file to "help" your version control system <spk121>dude. I remember arch. That was crazy <wingo>what is the largest .c file in guile, if you had to guess? *wingo looked fwiw, but maybe people want to guess <manumanumanu>I don't know C, but that doesn't seem completely unreasonable <wingo>in terms of bytes, it's numbers.c, almost twice as big as jit.c <Noisytoot>wingo: What's ";;; arch-tag: 3394732c-d9fa-48dd-a093-9fba3a325b8b" for? <wingo>lots of different kinds of numbers, a bit of combinator explosion of interactions <wingo>the right thing for bignums is really the MPN API and inline digits; but it's distressing to think about implementing <wingo>i had a hand in causing some fun security bugs in firefox implementing similar things there <wingo>i am missing a kind of prioritization effort for guile i think. like where are we going. lots of fun things to do, lots of unglamorous maintenance, dunno what next tho <spk121>wingo: next could a proper ci/cd over GNU/Linux/BSD and the various configure flags. Unglamourous, as you say <spk121>but of course, srfi-14 in scheme would be a fun project for someone <wingo>scope sets, new garbage collector, AOT compilation, register allocation, fixing the compilation-time cliff when you have more than fixnum bits of live locals, mpn, identifying ways to be closer to racket <wingo>inline caches for top-level calls, perhaps <spk121>maybe there is some sort of wishlist ranking webform someone could whip up <RhodiumToad>what's the deal with the module issue that daviid is always complaining about? <spk121>High on my wishlist would be linking the core *.go files into single *.a file to improve embeddability <wingo>the re-export-modules thing? need to look at that i guess <wingo>spk121: yeah that would be fun <wingo>dunno how much to double down on system-specific linkers, or whether to implement a multi-.go packer in scheme <wingo>with corresponding loader changes too <wingo>or what. luajit seems to manage to get their bytecode into .a files portably, so perhaps there is a simple option <wingo>... converting exceptions to structured exceptions... <wingo>optimizations to prompts so you can contify them away <spk121>I apologize in advance for the libpath commit I'm about to make. If anyone knows a better way, please fix it <wingo>dsmith-work: yeah that would be good. regexp literals also. and struct literals <wingo>having some kind of interface in a running guile process that can allow you to profile as you go <wingo>like generating timelines in the format that chrome's devtools can read <dsmith-work>So sexp regex and working with scheme strings (instead of C strings) <wingo>RhodiumToad: no, which one? :) <wingo>if you would like to help getting obvious patches in, it would be very welcome :) <wingo>needs an eye for detail which i think you have <dsmith-work>I don't know what's involved: Adding the debugging features needed to allow geiser to be as awesome as slime. Or just be able to do slime with Guile. <RhodiumToad>ssax author did post a new version on their site but iirc no changelog or announcement, so now I can't find it at all <RhodiumToad>that has links to guile-devel post and also to upstream version <wingo>first bug in ssax in a decade or so! *RhodiumToad is good at finding ancient bugs <RhodiumToad>most people probably wouldn't notice corruption of > inside cdata <RhodiumToad>I think the oldest bug I found is one in the BSD pom(6) program from the '80s <manumanumanu>dsmith-work: there is a pretty nifty SRFI for scheme regular expressions. That, and srfi-166 <manumanumanu>with the goal of making the subset of srfi-166 that implements the features of ice-9 format as fast as ice-9 format. <manumanumanu>I was making good progress, but I lost some steam when my drive became charcoal. <manumanumanu>srfi-115 is easily portable. Getting something like the reference implementation of srfi-166 to work means implementing something like 5 other SRFIs. <ArneBab>wingo: for me the gperf thing is a problem, because it just costed someone half an hour to figure out who tried to test whether there are regressions for Lilypond. If there hadn’t been a quick reply on the mailing list, that could have well ended that check. And if that happened once where I saw it, we can be sure that it already happened many times where I did not see it. <ArneBab>wingo, civodul: What I would like to do is to check at configure time whether the things in the tarball are available, and only to check for gperf if they are not. <civodul>ArneBab: typically "configure" does things when building from a tarball <civodul>when building from a checkout, it's expected that there are additional dependencies <civodul>we should document it, but it's not something "configure" should check for <civodul>since forever you also need Flex when building from a checkout, and Autoconf, etc. <ArneBab>I didn’t expect that the configure generated from git doesn’t do the checks needed to build <ArneBab>I need autoreconf, and it tells me what else I need <ArneBab>and the person who tried to check whether there are regressions from guile 3.0.6 for lilypond didn’t expect it either.