***drakonis is now known as drakonis-
***apteryx is now known as Guest40591
***apteryx_ is now known as apteryx
***gagbo___ is now known as gagbo
<str1ngs>leoprikler: my bad I meant <hash-table> though I don't need it any more I can parent a emacsy <hashmap> from the constructor. <RhodiumToad>maybe something like (alist->hash-table (hash-map->list cons myhash)) <str1ngs>RhodiumToad: I think that would work if I need to copy a <hash-table> at some point. <RhodiumToad>or (let ((newhash (make-hash-table))) (hash-for-each (cut hash-set! newhash <> <>) oldhash) newhash) <str1ngs>also why do I have such a hard time groking cut? is that just me and years of procedural programming? <RhodiumToad>mutation loop is kind of ick, but the alist way is a lot of consing... <str1ngs>yeah, actually this mutation issue stems even farther into how (emacsy minibuffer) is designed. I might need to redisgn it sligtly. for example the minibuffer is global binding and it's hard codeed in many places. I'm thinking of making it a fluid or a parameter <cloveistaken>Small question, how do I install gnutls on Debian stable ? <cloveistaken>I have this error message: Throw to key `gnutls-not-available' with args `("(gnutls) module not available")'. <cloveistaken>I downloaded guile-2.2 from repo, not compiled from source <leoprikler>there seems to be a guile-gnutls in bullseye and sid, but not buster <str1ngs>I normally just build gnults to /usr/local with guile support <RhodiumToad>(but the version that fixes nasty bugs in the 32-bit arm support is not released yet) <RhodiumToad>guile 3 unifies a bunch of record and exception types that are annoyingly distinct in guile 2 <RhodiumToad>not sure what other changes would be considered "big" <cloveistaken>guile seems to have new versions like every 3 months or somemthing <erkin>`dynamic-link' seems to ignore symlinks. <erkin>On my machine, `libc.so` does not exist and `libc.so.6` is a symlink to `libc-2.30.so`. I can (dynamic-link "libc-2.30") but I would prefer not to tie my code to a specific glibc version. <RhodiumToad>why would you try and link something that's already loaded? <erkin>Well, it doesn't work for anything else either. ***daviid is now known as Guest14680
<leoprikler>cloveistaken: guile-3 is stable enough for Guix, but you'll have to live with the awkward 3.0.2 vs. 3.0.4 API difference <leoprikler>erkin: does (dynamic-link "/full/path/to/lib") work for you? <leoprikler>if so, then just make "/full/path/to/lib") something that you get from your build-system through parameter or pkg-config <RhodiumToad>the theory of .so filenames is that libfoo.so.4 represents an ABI version, so libfoo.so.3 or libfoo.so.5 might not be compatible with it <erkin>"libc-2.30.so" works both relatively and absolutely. <erkin>I wouldn't mind linking to .so.6 but fixing to glibc v2.30 is a bit overkill. <leoprikler>scheme@(guile-user)> (dynamic-link "/run/current-system/profile/lib/libunistring.so") <leoprikler>$1 = #<dynamic-object "/run/current-system/profile/lib/libunistring.so"> <erkin>This is Guile v2.2 by the way. <erkin>I should've specified it earlier. <leoprikler>could you make another symlink to libc-2.30 in your current directory or /tmp (call it "libd.so") and try to dynamic-link that? <erkin>Should I add cwd to LD_LOAD_PATH? <erkin>It works with full path now. <erkin>Symlinking to test.so works but test.so.6 doesn't. <erkin>The suffix throws it off even with non-symlinked libraries. <RhodiumToad>what part of "just calls libtool's lt_dlopen" wasn't clear? <erkin>I would be surprised, because `ldd' shows clear links to /usr/lib/libc.so.6 <erkin>I whipped together some C code. <erkin>And `dlopen' works with `libc.so.6' <RhodiumToad>when you lt_dlopen some filename, it checks whether it already ends with the system's shared lib extension <cloveistaken>leoprikler: where can i see the 3.0.2 vs 3.0.4 api thingy <erkin>I wish Guile documentation mentioned that. <RhodiumToad>dlopen on the other hand will try the exact filename first, regardless. <RhodiumToad>so basically dynamic-link won't work on file names that don't end in the system's shared lib extension <RhodiumToad>opening libc.so will work if a file (or symlink) of that name exists on the system <erkin>It might be too intrusive to ask the user to make a /usr/lib/libc.so symlink. <RhodiumToad>for the specific case of libc, you can just assume it's already linked in, though? <RhodiumToad>and its symbols will be visible via (dynamic-link) with no filename <erkin>I made a symlink from /usr/lib/libc.so.6 to /usr/lib/libc.so <erkin>And (dynamic-link "libc.so") fails. <erkin>So do (dynamic-link "libc") and (dynamic-link "/usr/lib/libc.so"). <RhodiumToad>it fails for me too but for a completely different reason I think. <erkin>I considered /usr/lib64 but that also has libc.so.6 and libc.so ***Guest14680 is now known as daviid
<str1ngs>for libraries that are already linked to guile you don't need to pass a file argument. IIRC <str1ngs>for example say you want the printf function something like (dynamic-func "printf" (dynamic-link)) should work. <cloveistaken>What is the different between with-input-from-file and call-input-from-file <luis-felipe>The notation to describe what kind of arguments the procedure takes, for example. <rekado>some of the SXML documentation has Haskell-like type annotations <rekado>the stuff after “where” is a grammar <dsmith-work>cloveistaken: One takes a thunk, the other a procedure of one argument. <dsmith-work>cloveistaken: call-with-input-file passes the port to the proc <dsmith-work>cloveistaken: with-input-from-file changes stdin to the file <luis-felipe>The notation after the "where" seems like BNF notation (Backus–Naur form or Backus normal form)...