IRC channel logs
2023-05-21.log
back to list of logs
<rlb>Is object-documentation a bit broken? i.e. if the item satisfies procedure? and has a 'name property, then it uses any snarfed doc it finds, no matter where/how the item was defined. So if you have a module defining its own assoc via say (define-generic assoc), even if it tries to hide the (guile assoc), it'll still return the scheme assoc's docs, which it presumably should have returned #f. <rlb>s/it'll/object-documentation will/ <rlb>Offhand, I'd imagine we'd need to match on the full scope, i.e. (guile assoc) or (srfi srfi-1 last), but if that's not easy, then I imagine we might at least be able to arrange to detect a non-snarfed object and skip search-documentation-files. <apteryx>how would I go to connect a process output directly to the input port created with Guile-SSH's open-input-port? <apteryx>that's better; now it hangs on the tee invocation <apteryx>OK, I wasn't closing all the duplicated pipe ends <RhodiumToad>I need to install it simultaneously for both guile 2.2 and 3.0, and it's not cooperating <RhodiumToad>anyone know any convenient checks to know what version of guile a C program that links to guile is expecting? <RhodiumToad>e.g. any major changes in C API between 1.8, 2.2, 3.0 <mwette>see include/guile/3.0/libguile/version.h <mwette>after #include <libguile.h>, #if SCM_MAJOR_VERSION == 3 ... <civodul>RhodiumToad: also you can use the GUILE_PKG Autoconf macro to specify which major version you expect <RhodiumToad>I'm looking at a random piece of C source code I've never seen before, and I need to make a good guess as to what guile version it expects <RhodiumToad>obviously the first place I look is any build infrastructure, but sometimes that isn't helpful <RhodiumToad>(I'm trying to do a significant update to freebsd ports, to enable multiple guile versions to properly coexist, and so I have to build and hopefully test everything that depends on guile) <civodul>RhodiumToad: you could made a good guess from the date of that package? <rlb>RhodiumToad: in terms of automating, yeah, possibly look at the NEWS for each Y and hack up something to grep for any notable functions that were added/removed/changed, etc.? But conditional support for more than one version would be harder to detect that way... <rlb>I suppose if you have the resources, could also consider just automating/attempting builds in vms with different default guile versions, but that's mostly helpful if the packages are very well behaved wrt autodetection, and don't have too many external deps that might also need differing versions, I'd imagine. <RhodiumToad>the mechanical parts of the building/testing are easy to automate, fortunately <RhodiumToad>but trying it with multiple guile versions would be a bit more tricky <RhodiumToad>gnucash already had a guile version specified in the freebsd port build so I just kept that <rlb>(be older versions in the broader search) <RhodiumToad>(if it was wrong, that's on the port maintainer and not me) <RhodiumToad>a disappointing number of these seem to rely on guile-config rather than pkg-config <rlb>civodul: any thoughts offhand (or existing ideas) about out doc search? i.e. object-documentation just looks in guile-procedures.txt if the function has a 'name, which it looks like things like (define-generic foo) always set, but that foo might or might not have anything to do with the docs in the file. <rlb>No worries if not -- I was just trying to fix that for lokke, and be just as happy to spend the effort on changes more broadly useful. <rlb>(I could also imagine tying those docs to the particular procedure more tightly, so that any redefinition breaks the link -- via some unique id, or at least module-scoped name, or...) <rlb>...I wonder if in practice, right now at least, that search is only appropriate for bindings provided via (guile). <civodul>rlb: guile-procedures.txt is only for "subrs" (C code) <rlb>civodul: and only (guile)? <civodul>in other cases, docstrings are in an ELF section of the .go file <rlb>If it's only (guile), or a known set, then I could probably make a guard in object-documentation to at least prevent it from returning for the same name in other modules. <rlb>(I already wrote a (find-source-module m var) I needed for other reasons that could handle it... Didn't see any similar existing function.) <rlb>Hmm, also wonder (very vaguely) whether guile-procedures.txt could move to the .so, or if there's some reason (other than the complexity) we wouldn't want that if it's feasible. <rlb>civodul: what did you mean wrt boot-9.go? <civodul>that boot-9.go's .docstr section might have everything <rlb>Oh, I see, and if so, then we don't need the search there anymore? I can investigate. In any case, thanks for the info. In the short-term, I think I'll copy/adapt object-documentation for lokke's (doc x) to skip the final search when the binding comes from somewhere other than (guile). Can drop that hack if/when we rearrange things in guile. <apteryx>can I read binary chunks with guile instead of a char at a time? <apteryx>and that's more efficient for binary data than looping read-char? <RhodiumToad>get-bytevector-n will keep trying to read until it has the specified amount or it gets EOF <apteryx>at least more that a byte, given the process writing to the write end of the pipe should output the "it seems to work" text <RhodiumToad>or get-bytevector-some! will a bytevector you created yourself <apteryx>the doc also says about get-bytevector-n: "If fewer bytes are available, a bytevector smaller than COUNT is returned." <apteryx>i'd expect the 'echo "it seems to work"' child process to return EOF after about 2 bytes of data <apteryx>which is what get-bytevector-n should get return IIUC <RhodiumToad>get-bytevector-n only returns a short count if it hits EOF <RhodiumToad>it uses scm_c_read_bytes under the hood, which explicitly loops <apteryx>shouldn't the echo process return EOF when it's done? <apteryx>hm. when is it OK to close it in the parent? <apteryx>so EOF is sent exclusively when closing a port/pipe? <apteryx>i could close the write end there I guess <apteryx>but I still need the read end for the loop <apteryx>ah, that seems to do it: (close (cdr p)) to close the write end right after the fork (under the (pid ...) match block) <RhodiumToad>in the parent, you close whichever end the child will be writing to; in the child, you close the end the parent will be reading from <apteryx>seems to work; I now reach a Guile-SSH problem when the pipe object (an SSH channel) can't be used as the first argument of put-bytevector; it says: In procedure put-bytevector: Wrong type argument in position 1 (expecting open output port): #<input: channel (open) 7ff612fb0d20> <apteryx>starting the remote pipe with both ends open (OPEN_BOTH) seems to have resolved that <rlb>hmm, it looks like (module-re-export! m names #:replace #t) supports renaming, i.e. where names includes (x . new-name) elements, but define-module #:re-export-and-replace doesn't. Wondered if that might be an oversight. <rlb>nvm, was a different error.