IRC channel logs


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>this doesn't work for example:; the remote tee.txt file is empty
<apteryx>I'm not sure why I get "Bad file descriptor" errors here:
<apteryx>ah, I had reversed the pipe ends
<apteryx>that's better; now it hangs on the tee invocation
<apteryx>OK, I wasn't closing all the duplicated pipe ends
<apteryx>this was useful:
<RhodiumToad>ACTION mutters grumpily about guile-cairo
<RhodiumToad>I need to install it simultaneously for both guile 2.2 and 3.0, and it's not cooperating
<RhodiumToad>my solution is ... ugly
<sneek>Welcome back chrislck
<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
<civodul>or plain pkg-config
<RhodiumToad>that's not quite the problem
<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?
<RhodiumToad>... true
<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>too much work
<RhodiumToad>fortunately there's only about 50 ports to check
<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
<rlb>If the names map easily enough, wonder if debian might give some baseline indications for some of them... i.e. Not sure.
<rlb>And links to the various dists (that's bookworm, so very current), fwiw.
<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
<civodul>ah, (guile), hmm
<civodul>in boot-9.go?
<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>ah, (ice-9 binary-ports) ?
<apteryx>and that's more efficient for binary data than looping read-char?
<RhodiumToad>one would certainly hope so
<apteryx>any clue why this program hangs on get-bytevector-n? there should be data...
<RhodiumToad>how much data?
<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>you probably wanted get-bytevector-some
<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>looking at the code, i was right
<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?
<RhodiumToad>you didn't close the pipe in the parent?
<RhodiumToad>so it's still open
<apteryx>hm. when is it OK to close it in the parent?
<apteryx>so EOF is sent exclusively when closing a port/pipe?
<RhodiumToad>after the fork
<apteryx>after the fork but before the loop?
<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
<apteryx>this works:
<apteryx>refined somewhat:
<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.