***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>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? <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>And what's your GUILE_PKG() invocation? <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