IRC channel logs
2023-09-07.log
back to list of logs
<rlb>mwette: thanks -- I think I reworked that one a bit ago, may have reworked the correctness right out of it. In any case, I'll take a look, and I'll put improving our tests there on the todo list. <sneek>Welcome back rlb, you have 2 messages! <sneek>rlb, mwette says: maybe check reverse-list->string <sneek>rlb, mwette says: It looks to me like reverse-string->list is broken; it needs to efficiently do '(#\a #\b #\c) => "cba", but currently does => "abc", I think <mirai>rekado: SRFI-171 transducers perhaps? <rlb>mwette: hmm, I'll double-check that I didn't fix it in the handful of unpushed changes I have, but with my current branch it seems to work here? <rlb>scheme@(guile-user)> (reverse-list->string '(#\a #\b #\c)) <mwette>Oh, I get the same! Something else, then. I just looked at the code after seeing my issue w/ glib. My bad. The only calls besides (read-char) were (reverse-list->string) and the output issue was showing reversed strings (e.g., "typedef" was coming out as "fedepyt"). <rlb>No worries. I'd guess it's just something else in the branch. <rlb>The branch does also touch ports.c, i18n.c, and other io-related bits. <rlb>If you're curious: git diff --stat origin/main..utf8 <mwette>my erc dropped out again w/o notification on the modeline :( <rlb>I've had some oddness from long-running emacs --daemon based erc, mostly around the activity indicator in the mode line. I've guessed it might have something to do with it thinking (incorrectly) that I'm still looking at the buffer after a disconnection or something. <rlb>(across ssh disconnects/reconnects using emacsclient -t) <sp1ff>I have a question regarding defining functions in C. scm_c_define_gsubr will define the function and create a binding for it at the top-level. Suppose I want the binding in a module? <RhodiumToad>scm_c_define_gsubr creates the binding at top-level in the current module <sp1ff>Hmmm... how do I set the current module in C code? Oh-- or do I write Scheme setting up the module & then load the C? <RhodiumToad>depends on circumstances; but one common approach is to have a scheme module which calls load-extension to load C, which means the current module is already set <rlb>...or scm_set_current_module if the module already exists. <RhodiumToad>scm_c_define_module will use an existing module if there is one <sp1ff>ACTION looks back at docs... <sp1ff>I guess I'm confused by the `init` parameter to that. What is the intended usage? <sp1ff>Use it to define a bunch of functions? In that module? <RhodiumToad>scm_c_define_module creates a module if it doesn't already exist, makes it current, calls the init function, and restores the previously current module <sp1ff>oic-- call it with a function that includes the snarfed output <sp1ff>Got that-- my question is what sorts of things would one want to do in the init function, but I'm thinking: things like call scm_c_define_gsubr <rlb>I think anything you need to do to set up your module from the C side, and yes, I'd imagine making some definitions might be part of it. <RhodiumToad>make definitions with scm_c_define and scm_c_define_gsubr, and export at least some of them with scm_c_export <daviid>RhodiumToad: fwiw, i am gona ask about the gtk3/goocanvas 'port' to gtk4 quiz, just to see what they have to say ... let's see ... <RhodiumToad>WARNING: (g-golf): `disconnect' imported from both (g-golf hl-api gobject) and (g-golf hl-api signal) <RhodiumToad>daviid: ^ (just noticed that, not sure why I didn't see it before) <mwette>rlb: I emailed you a test file that has odd behavior. Wanted to see if you can reproduce. <apteryx>where does the recursive nature of load happen in Guile? <apteryx>e.g., I load module A, but as part of that unit of work, it then loads D, E, G because of #:use-modules for example <civodul>apteryx: modules are nothing special in Guile <civodul>so ‘define-module’ expands to ‘(process-module …)’, which in turn calls ‘load’ down the road <civodul>modules are little more than a hash table that maps symbols to “variables” <apteryx>I don't see 'process-module' in the Guile source? <apteryx>I'm using a bottom-up approach, currently made it to the 'load' procedure <civodul>apteryx: oops sorry it’s ‘define-module*’ and ‘process-use-modules’, in boot-9.scm <apteryx>process-use-modules only appear to set! metadata (the use-modules list) <RhodiumToad>every module has a uses list. when you use-modules a module, that module's public interface (which is also a module object) is added to that list <apteryx>what are observers in the (ice-9 boot-9) context? or in guile in general? <RhodiumToad>when you look up a variable in a module, it looks it up in the uses list if it's not directly found <apteryx>RhodiumToad: which procedure ends up calling load on the use-modules of a module? <civodul>when i said it’s “little more than a hash table”, it’s in fact an over-engineered hash table <RhodiumToad>resolve-interface calls resolve-module which ends up in try-module-autoload <apteryx>can module loading happen in parallel? <apteryx>interesting that resolve-module is set thrice in boot-9.scm <apteryx>thanks to wingo's 2008 humor, eh :-) <apteryx>the recursion happens in resolve-module <apteryx>";; Try to autoload the module, and recurse." <apteryx>so I cant increment my DEPTH counter there <apteryx>(all this to have a nicer non-flat display for %load-verbosely) <apteryx>does 'primitive' in primite-load-path means it's defined in C? <apteryx>another question: is there a relationship between 'primitive-load-path' and 'load' ? <apteryx>at least the later runs %load-hook as well <apteryx>I'll have to provide my counter to it <apteryx>how are keyword arguments received on the C side? <apteryx>scm_get_keyword seems it could help? <apteryx>there was no point providing a keyword arg to scm_primite_load_path, so that's solved <lilyp>apteryx: on the C side, I think you'd iterate through the rest list on your own, matching against globally defined scm keywords <dsmith>apteryx, I'm curious on what you are working on <apteryx>dsmith: just a nicer output for when %load-verbosely is #t <apteryx>which would show the depth level of a module (the first module loaded being at level 0) <apteryx>I'm trying to understand hairy cycles in Guix and I'm hoping this would help me see more clearly <apteryx>when using SCM_DEFINE, can the argslist look like (SCM arg1, SCM arg2, ...) instead of (SCM args) ? <mwette>apteryx: Are you using `read' to read the files and generate dep's for each module? You could do that and just parse the define-module form and all the define-public and exports at top-level. <mwette>and use-modules forms (and from the define-module, the use-module forms) <apteryx>mwette: no, I'm knitting a 'depth' (optional) argument to pritive-load-path and primitive-load (and their callers) in Guile itself <apteryx>and passing that depth argument to the %load-hook call <apteryx>to change the output caused by setting %load-verbosely to #t <apteryx>it's not too complicated, and it'll allow me to fix some duplicate output at once <apteryx>(caused by invoking %load-hook in both primitive-load-path *and* primitive-load) <apteryx>is it me or C-c < (geiser-xref-callers) never works? <apteryx>always reports "No callers found for X" <apteryx>I think my approach to display the modules load depth level is flawed <apteryx>now I understand that at the end of the define-module call chain is primitive-load, which just evaluates the module as scheme... I'd have to somehow pass my 'depth' value to that environment so that it can reuse it. <apteryx>is there a way to pass some value from the calling environment to that of primitive-load ? <apteryx>mwette: the external parsing approach now seems perhaps the better option, unless the question above has a straightforward answer <apteryx>I wonder if a global Guile parameter that is incremented before calling primitive-load in try-load-module could work <apteryx>it'll reduce a lot of complications by avoiding having to pass depth everywhere too <apteryx>I can instead define %current-module-load-depth, and increment it before calling primitive-load(-path) <rlb>apteryx: I suppose you might be able to set the depth as a parameter (i.e. dynamic, per-thread, and effectively an implicit "argument"). <rlb>Oh, I hadn't quite seen that you may already be trying that. <apteryx>can we access a Guile parameter directly from C? <apteryx>otherwise I'll pass it to primitive-load and primitive-load-path as an extra argument