IRC channel logs


back to list of logs

<rlb>mwette: thanks -- I'll take a look, likely later tonight.
<mwette>rlb: yw
<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
<apteryx>(and retry)
<dsmith>apteryx, arity
<apteryx>what values does it return?
<apteryx>it seems to simply print something
<apteryx>I want to use it programatically
<dsmith>Not sure. Might just print to stdout
<apteryx>hm. so it's geared for interactive use only?
<lloda>time to look at the source
<apteryx>use the source, luke!
<dsmith>It's in ice-9 session
<apteryx>it does a bunch of displays
<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
<apteryx>oh! neat
<dsmith>apteryx, Here is an example of scm_internal_catch:
<dsmith>apteryx, The bot has been using that for about 10 years or so
<dsmith>sneek, botsnack
<sneek>I've been serving for 5 days
<sneek>This system has been up 22 weeks, 5 days, 19 hours, 12 minutes
<dsmith>There's a good little bot
<sneek>ACTION wags
<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>*NEVER* let a SCM be 0 (NULL)
<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>explained in scm.h
<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.
<apteryx>dsmith: why is scm_to_int necessary here:
<dsmith>apteryx, becuse a SCM 3 is not a C 3
<apteryx>oof, thanks
<apteryx>ACTION assumed the simplest scalar types were somehow shared
<dsmith>There are some bits being used for the type.
<lloda>a somewhat recent bug was;a=commitdiff;h=c0004442b7691f59a0e37869ef288eb26382ad9e
<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")))
<mwette>rlb: got it
<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
<lloda>maybe in piped_process
<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
<apteryx>lechner: already reported as #43364
<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
<lechner>lloda / thanks for that pointer!
<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>I doubt so
<apteryx>(at least I don't know of one)
<lechner>did you win the wrestling?
<apteryx>I used an input-pipe to get the child process output; here's the script I was working on at the time:
<apteryx>line 258 is my usage of open-pipe*
<apteryx>the hierarchical %load-verbosely output change i wrote looks like this (untested):
<apteryx>most edits went to load.c
<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>civodul: do you reproduce? ^
<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 ./ resolved it
<civodul>apteryx: we no longer use ltdl, do we?
<civodul>are you on ‘main’?
<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.
<dsmith>sneek, botsnack
<dsmith>sneek, botsnack
<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've modified primitive-load to accept an argument list, but it still fails when being passed 2 arguments:
<apteryx>any clue?
<apteryx>I'm trying to have scm-primitive-load behave the same as scm-primitive-load-path, in terms of arguments processing
<apteryx>(accept a list of them)
<civodul>maybe: scm_primitive_load (scm_list_2 (x, y)); ?
<dsmith>sneek, botsnack
<dsmith>sneek, seen unknown-lamer
<sneek>Not as far as I can remember.
<dsmith>sneek, seen rlb
<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>civodul: yay! it works, thank you
<dsmith>sneek, seen unknown_lamer
<apteryx>eh, 'guild snarf-check-and-output-texi' gives me a segfault
<apteryx>caused by my local changes ^^'
<lechner>lloda / hi, thanks for your help earlier! i mentioned your name in this bug amendment.
<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>hm, I'm still getting a segfault with my changes; struggling to find the source. I pushed the code at
<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>how can I use a file with scm_simple_format (C)? This is the code (depth is a SCM obj):
<apteryx>it says: ("simple-format" "Wrong type argument in position ~A: ~S" (1 #<input: /tmp/test.txt 7>) (#<input: /tmp/test.txt 7>))
<mwette>needs to be an output file
<mwette>so, #<output: "foo"> versus #<input: "bar">