IRC channel 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

<apteryx>(and retry)

<dsmith>apteryx, arity

<apteryx>neat!

<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: https://gitlab.com/dalepsmith/guile-sqlite/-/blob/master/sqlite.c?ref_type=heads#L133

<dsmith>apteryx, The bot has been using that for about 10 years or so

<dsmith>sneek, botsnack

<sneek>:)

<dsmith>!uptime

<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>:-)

<apteryx>thanks

<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

<apteryx>OK

<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: https://gitlab.com/dalepsmith/guile-sqlite/-/blob/master/sqlite.c?ref_type=heads#L154

<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 https://git.savannah.gnu.org/gitweb/?p=guile.git;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.

<sneek>Okay.

<nckx>Oops, wrong channel, sorry.

<apteryx>are our gnu-c-manual and c-intro-and-ref manuals the same?

<nckx>No.

<apteryx>great

<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: https://notabug.org/apteryx/fiasco/src/master/fiasco/finder.scm

<apteryx>line 258 is my usage of open-pipe*

<apteryx>the hierarchical %load-verbosely output change i wrote looks like this (untested): https://paste.debian.net/1291357/

<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 ./autogen.sh 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

<sneek>:)

<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)

<dsmith>No

<dsmith>!uptime

<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: https://paste.debian.net/1291368/

<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

<sneek>:)

<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..

<dsmith>!uptime

<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

<sneek>Nope.

<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. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=43364#11

<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 https://notabug.org/apteryx/guile/src/load-verbosely-show-depth

<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): https://paste.debian.net/1291384/

<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">

<apteryx>thanks

IRC channel logs

2023-09-08.log