<daviid>[my (brand new laptop :( kb spacebar only half works ... sorry] <leoprikler>hmmm… #:search-ltdl-library-path?=#t by default, so it ought to work as before <daviid>ok,so i added :$abs_top_builddir/libg-golf/.libs and it fixes the problem, but i think i 'shouldn't have to', no big deal <daviid>leoprikler: in (system foreign-library), it seems it adds .libs, not sure <daviid>(augment-ltdl-library-path path) ... (cons* dir (in-vicinity dir ".libs") ... <leoprikler>maybe that code path is not triggered for some weird reason? <daviid>andinthecomment above, "So as a stopgap solution, we add a ".libs" subdir to the path for each entry in LTDL_LIBRARY_PATH, in case the .so is there instead of alongside the .la file. <daviid>leoprikler: probably not triggered, yes <dsmith>sneek: later tell dsmith-work: just a test <dsmith>sneek: later tell dsmith-work just a test <hugo>Is there a directory-watcher -> live-reloader of guile modules available? <dsmith>Ahh. Some people are using a ":" and that's seen as part of the nick. <daviid>flatwhatson: i pushed a fix, could you (when times allow) pull (the devel branch), and try to build g-golf in guix without 'your fix' ... and let me know ... tx! <dsmith>sneek: later tell dsmith-work, comma test <sneek>Welcome back dsmith, you have 1 message! <dsmith>leoprikler: Working. But not as cleanly as I'd like. <dsmith>If you "later tell nick[:,]", It also is including the "," or ":" in the saved recipient. :( <dsmith>Well any non-whitespace I guess. <sneek>dsmith, you have 2 messages! <sneek>dsmith, leoprikler says: later tell dsmith hi <dsmith>I should probably ensure that remembered nicks are only from the set "][a-zA-Z0-9_{}\`|-" <dsmith>Well. Didn't used to. And the []{}` etc was becuse they are accent chars on some european encoding. <dsmith>rfc1459: "Because of IRC's scandanavian origin, the characters {}| are considered to be the lower case equivalents of the characters []\, respectively." ***dsmith is now known as dsmith^
***dsmith^ is now known as dsmith
<flatwhatson>daviid: yep it fixes the dynamic loading of libg-golf.so, thanks! <daviid>flatwhatson: ok, great, tx as well <flatwhatson>i still need to set LD_LIBRARY_PATH to load libgirepository-1.0.so and libglib-2.0.so, but i think that's a problem unique to guix <flatwhatson>how would you feel about including a guix.scm in the project? <leoprikler>IIRC there exists a g-golf package upstream and it probably uses git as origin <leoprikler>so you can just inherit from that package most of the time <daviid>flatwhatson: yes, to the first sentence, but for the second, i prefer as things are <leoprikler>(I use a similar hack in Tsukundere's guix.scm because I'm too lazy to maintain two separate versions of it.) <flatwhatson>my reasoning is that the project-local guix.scm can evolve with the latest version, as dependencies or packaging might change over time <flatwhatson>at a point when the upstream pkgdef is updated, they can reference the latest one from the project <flatwhatson>it makes it easier for people who want to jump in testing the latest from master, they don't all need to individually work out how to package the latest again (or more likely just give up) <daviid>leoprikler: not in g-golf, but in nomad maybe <daviid>anyway, i'll rely on the guix contributors and the guix g-golf pkg, but tx <leoprikler>flatwhatson agree in principle, perhaps disagree on the specifics, but it's always the package maintainers' choice <flatwhatson>oh totally. i'm still working out what "guix everywhere" development looks like, i understand it's still a bit radical <daviid>leoprikler, flatwhatson how far isguix from having a gtk-4 and deps pack? <flatwhatson>i honestly have no idea, haven't touched gtk packaging before <flatwhatson>tempted to have a go at it so i can run your examples, or failing that maybe trying to port them to gtk3 <daviid>flatwhatson: the search-bar example won't work in gtk-3, the searchentrysignals changed, i think ***terpri is now known as robin
<apteryx>Is Guile able to FFI with C++ shared libraries? <wingo>not really. if you know the symbol mangling and abi mapping you can hack some things <leoprikler>daviid: It's at least one c-u away, though work is still done on wip-gnome <lampilelo>apteryx: swig can create a wrapper of c++ code for guile, i've never tried it with c++ so i don't know how well it works, but may be worth a try <lloda>the schmutz lib that leoprikler linked to looks good <lloda>i'd probably adopt that if i didn't have my own ancient wrappers <apteryx>wingo, lampilelo thanks for the hints <lampilelo>apteryx: maybe they didn't update the page but it works for me fine with guile 3 <apteryx>Seems a high value piece of software if it allows Guile to tap into any C++ library. <sneek>dsmith-work, you have 3 messages! <sneek>dsmith-work, dsmith says: just a test <sneek>dsmith-work, dsmith says: just a test <sneek>dsmith-work, dsmith says: comma test <flatwhatson>thanks raghavgururajan i'll have a crack over the weekend ***xeno__ is now known as xeno
***terpri_ is now known as robin
<manumanumanu>it seems very much like vectors of chars from a performance pov. <dsmith-work>manumanumanu: See the comments in libguile/strings.h <dsmith-work>manumanumanu: Somestimes it's bytes and sometimes it's wide chars, depending. <manumanumanu>I am testing an immutable string library of my own design, and it is about half as fast on narrow strings, and anywhere 2-4x slower on wider ones. But I suspect it is a lot more compact in memory <manumanumanu>random access is of course a lot slower, even though it is technically O(1). <dsmith-work>manumanumanu: Recently rlb was looking into changing string internals. <manumanumanu>(internal representation is utf8 in a bunch of smaller bytevectors). <manumanumanu>dsmith-work: not that one, but I found the one you meant. <dsmith-work>manumanumanu: yey! (the searching of the logs seems a bit wonky) <manumanumanu>rlb: regarding string representation: how about storing strings as chunks of bytes? Any wide string part can be a wide type, whereas any narrow type can be represented as a regular char array. You'd waste less space than with the current "whole-string-is-wide" approach for many western languages.