IRC channel logs
2025-06-23.log
back to list of logs
<veqq>starsabove: $ only seems to work within s exprs, e.g. "$6" by itself won't just print the "var" <starsabove>feels like something like (print-raw) as i made in that paste is missing from the (srfi srfi-9 gnu) module <veqq>After restarting my computer (on linux mint), colorize and readline are gone <veqq>Putting the readline.scm and guile-readline.so in the proper folders leads to weird, weird issues <veqq>colorize just wont install/make <adhoc>what is your ldd config look like ? <veqq>ldd config? ldconfig? It tells me: /sbin/ldconfig.real: /usr/local/lib/libguile-3.0.so.1.7.0-gdb.scm is not an ELF file - it has the wrong magic bytes at the start. <veqq>That seems relevant, but I'd not heard of ldconfig until you asked. <adhoc>yes, my system complains the same way <adhoc>however guile-readline.so should be a library? now a scheme source file? <veqq>I dont really know c, its build systems etc., but built guile from source a few days ago and it was fine until the first restart. After sudo make install, should have persisted the source directory? I've put them back, but still no joy <veqq>If it should be a library, i guess that's why cat /usr/share/guile/3.0/ice-9/readline.scm works, but... how do i find where it's simlinking to? <veqq>Or idk what i should be doing <adhoc>i wonder if the underlying readline library is missing, not the scheme shim ? <adhoc>veqq: I am not sure exactly, but I would start poking your OS to see which readline package is installed. <veqq>linux mint, readline works on shell normally, at least <adhoc>so you could use dpkg to see which readline library is instealled <adhoc>eg; dpkg --get-selections | grep readline <adhoc>do you have a *-dev package ? <veqq>libreadline-dev:amd64 also a version 8, but i dont remember. I was looking up this rabbit hole too <veqq>also readline-common and libreadline8t64:amd64 <rlb>You should have a guile-readline.so.0 in your install tree, and you might want to try running ldd on it to make sure it can find the libreadline it wants. <rlb>(That's what readline.scm loads via load-extension.) <adhoc>rlb: i had this question previously too, how do you turn the .scm file into the .so file that ldd wants ? <veqq>rlb: I had it. ldd gave me a list like libgc.so.1 => /lib/x86_64-linux-gnu/libgc.so.1 (0x000070b03492a000) with nothing which seems like an error <rlb>You don't - they're separate and oyu must have both. <rlb>i.e. you should have an ice-9/readline.scm and that loads your guile-readline.so <rlb>if you don't have a guile-readline.so, then your install is incomplete -- one cause might be a failure to detect readline during ./configure. <rlb>Or, if you're using packages, not having some package that includes it. <rlb>(In debian, it's in guile-3.0-libs along with "everything else".) <adhoc>so if you installed guile 3 package from debian <adhoc>and then try to build a newer version from source, <adhoc>is that going to choose the right one ? <adhoc>i had issues with that in the past <rlb>You'd need to "apt install build-dep guile-3.0" if you want to build guile, or install all the right build-deps manually. <rlb>that'll pull in libreadline-dev, etc. <veqq>In my case, I built it from source. And these things worked until right before this convo <adhoc>is build-dep a package there or an argument to install ? <rlb>"apt build-dep guile-3.0" I meant <adhoc>ah ok, that makes more sense =) <rlb>(And then I will often do a "per-user" build with ./configure --prefix=~/opt/guile-main or something and "make install" that and just use/test/whatever it via ~/opt/guile/main/bin, etc.) <veqq>Why would it say In procedure dlopen: file "guile-readline.so", message "guile-readline.so: cannot open shared object file: No such file or directory" if find /usr -name "guile-readline.so" 2>/dev/null <veqq>/usr/lib/x86_64-linux-gnu/guile/3.0/extensions/guile-readline.so <rlb>Does ldd /usr/lib/x86_64-linux-gnu/guile/3.0/extensions/guile-readline.so "look fine"? <rlb>i.e. does it find "=>" all the libs? <rlb>Then I'd guess that the guile you're running doesn't have that dir in its relevant path(s) -- one way to include it is via LD_LIBRARY_PATH, i.e. "LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/guile/3.0/extensions some-guile". <veqq>But how would that disappear/be undone if it worked before? <veqq>I tried export GUILE_LOAD_PATH="/usr/lib/x86_64-linux-gnu/guile/3.0/extensions:$GUILE_LOAD_PATH" <rlb>I'm not sure GUILE_LOAD_PATH is relevant for shared libs. <rlb>(don't recall the process well offhand) <veqq>how often do such issues occur? <rlb>No idea broadly. (I hope very rarely in debian.) <rlb>Note that you can also just try (load-extension "guile-readline" "scm_init_readline") <rlb>from your guile prompt -- until you have that working, the rest of it doesn't matter. <rlb>And is this the system guile, or one you built? <veqq>I can't. That's... what I've been trying to do :P <rlb>And did you install it to some other --prefix? <veqq>I don't know what that means :D <rlb>./configure --prefix /some/dir <rlb>i.e. where did you install it? <veqq>no, just ./configure by itself <rlb>is it in /usr/local/bin, or /usr/bin, or? <veqq>which -> /usr/local/bin/gile <rlb>And did your configure say it detected readline and built support? (you can probably also find that in config.log) <rlb>i.e. do you have guile-readline.so in your /usr/local/... install dir? <veqq>It worked fine previously. <rlb>(the /usr/lib/ one is irrelevant) <veqq>It stopped working after I restarted my computer <rlb>Does it work if you run /usr/bin/guile explicitly? <rlb>(if you still have that all installed) <rlb>Also do you use bash? <veqq>yes bash. But what syntax would i use to try to it at /usr/bin/guile? <rlb>If so, random guess -- you might have been running /usr/bin/guile until you logged out/in and only then picked up /usr/local/bin/guile, given bash's "caching" of executable lookups. <veqq>I dont think it's in /usr/local/ <rlb>(You can side-step that via hash -r) <veqq>So, with LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/guile/3.0/extensions some-guile where should I put that exactly? <rlb>OK, well if you did build and install guile, i.e. "make install", the first question is where did it install. <veqq>Reading around, I don't understand what it is any I don't have any of the random files stackoverflow says to use it <veqq>It installed to /usr/local/bin/guile didn't we just cover that? <rlb>I thought you just said "I don't think it's in /usr/local" <rlb>Did you just mean guile-readline.so? <veqq>Yes. That's what you asked. <rlb>OK, well then you probably just didn't build your guile with readline support -- you'll need to rebuild it. <rlb>(reconfigure first, and make sure it detects readline) <veqq> run /usr/local/bin/guile doesn't work <rlb>i.e. ./configure again, make sure it detects readline, the make and make install again. <veqq>Do I have to uninstall or something? <veqq>I see from the logs that it detected readline the first time <rlb>well not sure then -- if it did, then you should have a guile-readline in the same "tree" with your bin/guile, i.e. /usr/local/... <veqq>How would guile stuff end up elsewhere if not by design? (this is basically a fresh install) <rlb>If you have /usr/local/bin/guile but 'find /usr/local -name "guile-readline.so*"' doesn't find anything, then something probably went wrong. <rlb>with the build or install <rlb>(assuming I'm remembering all the relevant bits right) <veqq>is there a problem if i sudo make install without undoing it previously? <veqq>idk what "undoing" would be, but some sort of uninstall? <rlb>There is an uninstall, but I don't think you'll be OK without it, and I don't know how reliable it is. <rlb>"I do think you'll be OK without it" <rlb>Also, before you install, you can see if readline works from the build tree. <rlb>If not, no point in installing yet. <rlb>i.e. if readline works when you run "meta/guile". <veqq>ice-9/readline.scm:47:4: readline is not provided in this Guile installation <rlb>Right, so you didn't build readline support. <rlb>(...and I'm guessing that people "sudo make install", but I'm always wary of sudo (for a number of reasons) -- I might favor at least using "-i", so your user envt can't "bleed through", but take that with a big grain of salt, since I don't use sudo.) <rlb>i.e. maybe don't listen to me there :) <rlb>In any case, I have to wander off for a while, but I'll be back later (hours). <veqq>how do you do it without sudo? <rlb>(I always do root operations from a root shell, via say "su -", but my broader arrangement is also more complicated...) <veqq>Thank you for the help. I really appreciate it <veqq>But i dont get what the things like config.status: creating guile-readline/Makefile or checking for rl_getc_function pointer in readline... yes were if it didnt... <veqq>And how did it work until now if it didnt install with readline? <rlb>(Long ago, when I did use sudo, I did always configure it to have no password "grace period" at least, i.e. had to type the password every time.) <veqq>Sorry to, uh, come to no conclusion :( <rlb>I'd try rebuilding if nothing else. <rlb>i.e. reconfigure, make sure it's happy about all the readline-related bits, then rebuild, then try meta/guile. <veqq>how is meta/guiledifferent from guile? <veqq>libtool: warning: relinking 'guile-readline.la' <veqq>it's done building already, it just relinked that <veqq>rlb: I am very sorry for wasting so much time. I had no idea you could just do that again... :D <veqq>I will restart and see what happens <veqq>it works fine. But... does this mean you should generally keep the source code, just in case, to rebuild/relink randomly? <rlb>well, I don't know what happened, but if, for example, your underlying distribution were to drop the libreadline major version you build against "somehow", then guile would break, so in the limiting case, if you're building things yourself, then yes, you might have to rebuild now and then. <rlb>same applies for any other lib, libgc, etc. <rlb>In debian that'd be very unlikely, since the new lib package would just get a new libfooN number, but don't know what every dist does. <veqq>Linux mint should be debian, via ubuntu 22 or such iirc <rlb>Now if you yourself "apt purge libfooN", then yep, you'd break your build. <veqq>idk, kafkaesque! I've managed to stay ignorant of such matters, expect when i tried to do packaging for Jank. <veqq>You said you had to go for a few hours! :DD <rlb>night (or morning/afternoon/...) <wingo>rlb: what do you do for mutation-sharing substrings in the utf8 branch? <wingo>gosh narrow/wide strings are distressing <wingo>rlb: i have to poke some of that code so that i can trace strings, going to try to keep it minimal but everything touches everything :/ <dsmith>veqq, "make; sudo make install" is ok, as it builds everything as your user, and then only the install part is done as root. <dsmith>veqq, If you just "sudo make install" without building it first, all the built files will be owned by root. A bit messy to deal with. <veqq>dsmith: thank you for the advice! <dsmith>veqq, And as always, using strace can really shine a light at mysterious "not finding .so" problems. <dsmith>Also, .so files (file locations?) are cached. The "ldconfig" refreshed that cache. Pretty sure the make install runs ldconfig, but sometimes you need to run it by hand. <lampilelo>dthompson: i'm playing with your bstructs library and i don't see any way to get an offset or a size of a struct element. this would be useful for creating bytevector slices for processing binary data stored inside a struct (e.g. decoding fixed-size byte arrays). as it seems, right now the only way to refer to an array element is by calling bstruct-ref on its elements one by one. is there anything i'm missing? <dthompson>I suspect there's a way to do what you want but not 100% <lampilelo>a hacky way to tell the offset would be bstruct->pointer arithmetic, but have no idea how to get a size of an array stored inside a bstruct <dthompson>lampilelo: you can't get the size. it's static. <lampilelo>dthompson: sure, but if i hardcode it in multiple places in my program, it will be problematic if i want to change the definition of the struct later on. it would be better to have something like (bstruct-field-size <type> (a b)) that would evaluate to a const value at compile time <ttz`>I am currently profiling my HAMT implementation and realized that most of its time is spent copying vectors (since it is purely functional). I am using the Guile procedure `vector-copy` which apparently uses `vector-move-left!` under the hood which in turns calls its equivalent C procedure. After a quick look at the implementation I found out that it was not implemented by a call to `memcpy`. Would anyone know why? <rlb>wingo: I'll have to refresh -- it's been a while, and I tried a few approaches. <rlb>wingo: ...and yeah, the changes on that branch were "notable", and I tried to do them fairly incrementally, hence all the commits, both so I'd have more confidence it was right, and for anyone reviewing it. <rlb>(That also may make a bigger mess if it has to be rebased across a lot of change before we decide about it.) <lampilelo>ttz`: i think it's because vectors can hold arbitrary data you don't know the size of (i.e. maybe allocated on the heap). you should try using typed arrays instead <ttz`>Thanks, lampilelo I was not even aware of this type. My first attempt actually leads to even worse performances, but I may not use it correctly. <lampilelo>ttz`: take my advice with a grain of salt, because i never really messed with typed arrays. based on the code though, if you're copying from a typed array to another typed array, it should copy elements directly (doesn't use memcpy though, it's just a for loop) <ttz`>Then I am not sure this is an improvement... my data should be boxed anyway so I can't benefit from the unboxing allowed by the typed array. <ttz`>And then both implementation use a for loop. <dthompson>lampilelo: maybe idk. if you could send me a small program that demonstrates the issue I can decide if that makes sense. <rlb>Also, I had a note elsewhere about whether we want to keep in-place ascii mutability -- it's still there atm (see scm_i_string_set_x).. <rlb>wingo: utf-8 stringbufs (not ascii-only), I iirc it just atomically swaps in the new one after a change. <lampilelo>ttz`: the only thing i know that uses memcpy for copying data in guile is bytevector <rlb>(and the bit after the highlighted region shows the utf-8 stringbuf layout) <rlb>ACTION would be *very* happy if someone familiar with the domain could figure out what's wrong with the "inter-protocol attack" test <rlb>ERROR: 00-repl-server.test: repl-server: HTTP inter-protocol attack - arguments: ((system-error "fport_write" "~A" ("Broken pipe") (32))) <rlb>it's back to crashing often now here. <mwette>maybe strace can shed some light <veqq>wingo how did you decide to engage with guile backwhen, instead of e.g. jumping into racket or chicken. You seem to have done so much for this community, I'm curious what started it <rlb>wingo: rebased utf8 onto current main