IRC channel logs

2021-06-20.log

back to list of logs

***Wilfred is now known as wilfred
<rlb>wingo: do I recall correctly that you thought that string ports (i.e. open-output-string, etc.) weren't likely to perform all that well (as compared to just gathering a list of strings/chars and reverse joining them)?
<hendursaga>I might finally get back into Guile coding - GNU Dico uses it for extensions
<hendursaga>Can anyone recommend a XML/HTML manipulation library?
<hendursaga>Would something like SXML be my only realistic choice? Basically I'll toying with the idea of a Dico extension that renders HTML dictionary entries into potentially structured text.
<pkill9>haunt uses sxml hendursaga
<pkill9>it lets you produce HTML from s expressions
<hendursaga>huh I had that in my TO-DO list to look into already...
<hendursaga>did the project move or has it really been archived?
<hendursaga>never mind I found it @ https://git.dthompson.us/haunt.git/
<rlb>I'm surprised that ./configure --prefix=/some/where produces a guile-3.0.pc file in /some/where that refers to /usr/local rather than /some/where. Is that a bug?
<rlb>(and as a result /some/where/bin/guile-config compile produces -I/usr/local/... which isn't going to work)
*rlb tries to make sure it wasn't broken make deps after a git tree switch...
<civodul>rlb: you sure? guile-3.0.pc looks good to me
<rlb>civodul: it must have been something in my tree. It worked after a git clean -fdx, though I'd have expected the ./configure --prefix... to have clobbered any previous values.
<rlb>(Looks like maybe it didn't.)
<rlb>civodul: and what's the right way to get our configure macros to pick up that non-system guile? It looks like setting the PATH, PKG_CONFIG_PATH and ACLOCAL_PATH doesn't work. GUILE_PKG still finds /usr/bin/guile-3.0 instead of /some/where/bin/guile, even though the latter is newer (3.0.7 vs 3.0.5) and is first in the path.
<daviid>rlb: you need to define, export (in a my-config file) and source it (in a bash sence, like '. my-config' at least these vars, ACLOCAL_FLAGS, PATH, LD_LIBRARY_PATH and PKG_CONFIG_PATH - well, that's what i do :), it works fine for me
<daviid>rlb: my manually built guile 3.0 and guile-3.0.pc is also correct (it only isstrange wrt version, which says Version: 3.0.6.1-19f38a in the .pcfile, but it actuallyis 3.0.7, no idea why, but guile --version reports the correct version
<rlb>I have that, but I wonder if the problem is that /some/where/guile/bin/guile(-config) is first in the PATH and newer than /usr/bin/guile(-config) or /usr/bin/guile-3.0(-config), but maybe it's not checking .../bin/guile(-config) when you use GUILE_PKG([3.0]). If not, maybe it should?
<rlb>i.e. the system guile was configured with a suffix, but the /some/where guile wasn't.
<rlb>I'd have imagined the autoconf macros might check every guile and suitable guile-X.Y in the path, and take the first one that reports a matching X.Y...
<rlb>Have to see what they actually do, and we should document this better in the info pages. I might see about a patch if I get time (both to figure it out and to write some docs).
<rlb>i.e. does it rely on checking guile-config or guile itself, and what's the selection algorithm.
<daviid>i dothat allthe time, one terminal with theabove vars,then another pointing to2.2 ...
<rlb>But do all your guile /bin/ commands have a suffix?
<rlb>(or all not)
<daviid>none have suffix
<rlb>And what's your GUILE_PKG() invocation?
<daviid> http://git.savannah.gnu.org/cgit/g-golf.git/tree/configure.ac?h=devel
<daviid>GUILE_PKG([3.0 2.2 2.0]) - GUILE3_PROGS([3.0.7]) is only there to make sure, iif it finds guile 3.0, that it is >= 3.0.7
<daviid>rlb: fwiw, no debian guile pkg installed 'here', all guile v are manually installed, in diff tree branches, /opt3, /opt2 and /opt