IRC channel logs
2023-09-08.log
back to list of logs
<rlb>mwette: thanks -- I'll take a look, likely later tonight. <rlb>mwette: yeah, that's almost certainly a bug somewhere. I'll find it. <rlb>mwette: got it. I'll push a fix for you in the next day or so, if not sooner. Bug also revealed a possible simplification and optimization. <apteryx>is there a means to introspect the arity of a procedure? <apteryx>%load-hook being a public API I need to support calling it with either 1 or 2 arguments <apteryx>I'll catch 'wrong-number-of-args exceptions <dsmith>Not sure. Might just print to stdout <apteryx>hm. so it's geared for interactive use only? <apteryx>it'd be nice to have (arity some-proc) => 2 <apteryx>any example of using scm_catch from C side? <lloda>the source uses either (procedure-property f 'arglist) or (procedure-minimum-arity f) <lloda>second one seems to work for some random functions i tried <dsmith>apteryx, The bot has been using that for about 10 years or so <sneek>I've been serving for 5 days <sneek>This system has been up 22 weeks, 5 days, 19 hours, 12 minutes <apteryx>can I pass a procedure around in C? is it just a pointer? <apteryx>the type is SCM, defined with: SCM hook = *scm_loc_load_hook; <apteryx>which is itself: static SCM *scm_loc_load_hook; <lloda>SCM is a scheme object. That can be a function or anything else <lloda>you can certainly pass them around <dsmith>Trust me. Very Bad things will happen <apteryx>I can pass them around but only to SCM_DEFINE'd or SCM_INTERNAL'd procedures, perhaps? <apteryx>not to a plain C procedure, I guess? <lloda>you can pass them to anything that takes a scheme object <lloda>many plain C procs in Guile take SCM <lloda>if you treat SCM as an opaque pointer it should never become 0. But when it does it's almost always bc of crummy C conversions <apteryx>what is SCM_INTERNAL useful for, compared to a plain C proc definition? <apteryx>it's for internal linkage (hiding symbols?) <dsmith>Internal means not for user consumption. API is free to change. Use at your own risk. <apteryx>seems to be used by using SCM_INTERNAL on the signature, and SCM_DEFINE to declare the procedure <lloda>i think SCM_DEBUG_TYPING_STRICTNESS should be 2 and just remove the whole thing in scm.h. There's no way that makes any difference on a compiler from this millenium <apteryx>what if I simply use a normal C declaration for my procedure and only in load.c; will it be visible? <apteryx>it's a common helper to two others SCM_DEFINE'd functions there <lloda>if you only use it in the same source file you can declare it static <lloda>idr if there's a Guile style wrapper for that <lloda>but you can just use static, lots of functions in Guile itself do <apteryx>OK; good. Static means internal in C? (as well as... persistent storage for variables across function calls IIRC) <lloda>those are different meanings of the same word <dsmith>In C, static at file scope is a gloabal not visible outside the object file. static at function scope is a "global" not visible outside the function. <dsmith>That's one way of looking at it. <apteryx>thanks, put that way it seems easier to remember <lloda>the meanings (linkage or storage duration) are really unrelated <lloda>C gets away with this because it's used in different contexts <dsmith>Ya, I think the original meaning of "static" meant (within function scope) an non-changing (static) address, as apposed to an "auto" variable, which got a new address (on the stack) with each function invocation <dsmith>Implemented by being in the data segment (or bss?) but not visible outside the function. <dsmith>apteryx, becuse a SCM 3 is not a C 3 <apteryx>ACTION assumed the simplest scalar types were somehow shared <dsmith>There are some bits being used for the type. <lloda>i think another number wouldn't have gone through, but 0 is special and converts to anything :-\ <apteryx>is there a point to use uint8 or the likes for small numbers in C anymore? <lloda>if you have lots of them, like in arrays <dsmith>I think it usually take more work on the CPU to deal with non-word sized values. (Need to mask off and stuff) <apteryx>OK; otherwise you would simply use uint or even int? <dsmith>So mostly useful for packing data, Structs, arrays. <lechner>Hi, why does with-output-to-port capture stdout from system* here (call-with-output-file "/tmp/test.log" (lambda (port) (with-output-to-port port (lambda () (system* "mktemp" "-d"))))) <lechner>but with-output-to-string does not do so here, please? (with-output-to-string (lambda () (system* "mktemp" "-d"))) <nckx>sneek: later tell vagrantc: It is cached. ‘guix time-machine --commit=abcd…’ should be almost instant after the first invocation, even if the subcommand changes. <nckx>Oops, wrong channel, sorry. <apteryx>are our gnu-c-manual and c-intro-and-ref manuals the same? <nckx>The reference manual is less chatty. <lloda>lechner: looks like a bug to me <apteryx>lechner: I thought I saw something on the bugs tracker fixing that <apteryx>yeah the workaround would be to use a pipe to get the output <mwette>rlb: it would help me if you merge in wingo's fix for the pretty-printer, comit b5bedf7 dated Sep 6 <lloda>if a file port works, then a string port should work just the same <wingo>the pretty-printer still has a bug or two, as you have probably seen <mwette>not yet - but that one caught my attention right away <lloda>lechner: if you look at system* -> piped_process, you see that it handles the redirection itself, but only if current ports are file ports. Idk the reason <lloda>maybe it uses is-file-port? when it means has-been-redirected? or something <lloda>or just that you need a descriptor, and you can only get that from a file port <lloda>i think that's the reason, but the result isn't nice <lloda>i'd def call this a bug either way <lechner>i thought 0, 1, and 2 are standard nowadays <lechner>i'll look at that later today, but that's sure to limit Guile's utility as a scripting language <lechner>i can get stdout via open-pipe* somewhat easily, but they really want me to dup2 for stderr? <lechner>apteryx / thanks for that pointer, too! it's more or less the same thing <lloda>usually you always need pipes to redirect process output. system* is special tho <apteryx>lechner: it's the point of view from the 'treating the system as a blackbox' side, after wrestling with the same problem a few years ago as well ;-) <lechner>is there an easy way to get stderr without using shell redirection in a string exec? <apteryx>to ensure backward compatibility with old %load-hooks <apteryx>the rest is just defining a %current-module-load-depth Guile parameter in boot-9.scm and incrementing by one every time we're about to call try-load-module in resolve-module <apteryx>(and calling primitive-load and primitive-load-path with its value, and adjusting the default %load-hook (%load-announce) to use it <apteryx>ACTION enters 'guix shell', attempts to build Guile from source <apteryx>weird, configure doesn't find libtool <apteryx>configure failed with "conftest.c:580:10: fatal error: ltdl.h: No such file or directory" on a source line: #include <ltdl.h> <apteryx>or anyone else using Guix to hack on Guile <apteryx>our libtool 2.4.7 packages doesn't have such a header <apteryx>nevermind, my configure script must had gone stale; re-running it after ./autogen.sh resolved it <civodul>apteryx: we no longer use ltdl, do we? <civodul>ah sorry, just saw you figured it out <rlb>mwette: I'll rebase onto current main before i push, assuming the patch in there. <apteryx>seems the build system doesn't rebuild snarf data without running configure anew? <apteryx>ah, nevermind, the error is unchanged <apteryx>can I have two signatures for the same function in C? (multiple dispatch) <sneek>I've been serving for 22 seconds <sneek>This system has been up 22 weeks, 5 days, 23 hours, 17 minutes <apteryx>I'm trying to have scm-primitive-load behave the same as scm-primitive-load-path, in terms of arguments processing <civodul>maybe: scm_primitive_load (scm_list_2 (x, y)); ? <sneek>Not as far as I can remember. <sneek>rlb was in #guile 1 hour and 45 minutes ago, saying: mwette: I'll rebase onto current main before i push, assuming the patch in there.. <sneek>I've been serving for 59 seconds <sneek>This system has been up 22 weeks, 5 days, 23 hours, 22 minutes <apteryx>eh, 'guild snarf-check-and-output-texi' gives me a segfault <atuin>hi, is there anyway to get the path for a module, I can see module-filename <dsmith>atuin, Not directly. Need to search through the load-path with the module filename. <apteryx>maybe: Pre-boot error; key: unbound-variable, args: (#f "Unbound variable: ~S" (error) #f) <apteryx>nah, that's just me replacing exec with gdb --args at the to bottom of meta/build-env; that doesn't go well for some reason <apteryx>it says: ("simple-format" "Wrong type argument in position ~A: ~S" (1 #<input: /tmp/test.txt 7>) (#<input: /tmp/test.txt 7>)) <mwette>so, #<output: "foo"> versus #<input: "bar">