IRC channel logs
2017-12-10.log
back to list of logs
<daviid>hum. on debian buster after today's libunistring-dev:amd64 (0.9.8-1) update, guile refuses to work: guile: error while loading shared libraries: libunistring.so.0: cannot open shared object file: No such file or directory <daviid>there is one .so file, in that libunistring-dev, but no .so.0 I wonder why guile is trying to load the .so.0 <daviid>david@capac:~ 2 $ dpkg -L libunistring-dev <daviid>/usr/lib/x86_64-linux-gnu/libunistring.so <ft>The suffixed file is part of the non-dev packacke. <daviid>/usr/lib/x86_64-linux-gnu/libunistring.so.2.1.0 <daviid>i guess i have to recompile guile <ft>I bet it's an ABI change in the new version. <ft>Relink should be enough, I think. <daviid>yes, that worked fine, thanks ft <rekado_>I don’t want to patch Guile just for guile-cv. Could this be avoided? <spk121>rekado_ FWIW, I had to write a custom printer when I implemented SRFI-14 back in the day to avoid blowing up the REPL. You can do that on the C side. But if you want to do it clean and modern, I think you've got to patch upstream Guile. <daviid>rekado_: not that I am aware of. note that the patch is the most inoffensive patch ever, it import another guile module (so it is written and maintained by our maintainers), and change one line, calling a procedure that is als developed and maintained ... this was suggested by andy himself ... the only thing we could do to make it better is to define a variable, or a parameter, so users could still choose between the 2 way of repling <daviid>... right now, anyone of us (I am not the only, by far) working on large lists, arrays, srfi-4 bytevectors are bitten by this problem <rekado_>daviid: wouldn’t it be better to get this into Guile itself instead of expecting users to patch it themselves? Is there a bug report for Guile? <daviid>rekado_: yes of course the 'patch' should land in GUile itself, I've no idea why it didn't yet <daviid>no bug report, we've been talking about this here a couple of times in moreless 2 years, and there is a branch by lloda for raised exception (right now we can not 'patch' that aspect, ice-9 boot needs to be 'prepared' to allow raised exceptions that would not try to print large structures ... <daviid>rekado_: if you have guile-cv packaged, just 'cd doc/images', fire a repl, and ',use (cv)' 'im-load "gnu.png") and bang ... see what happens in your terminal (don't try this in emacs, it will kill your emacs <daviid>rekado_: this an emergency measure, inoffensive, then we can talk and submit a bug or jst convince one of our maintainers to 'do something' about this and the raised exception 'system' <daviid>all guix guile users will thank you for this :), <daviid>rekado_: a user who needs a full write can always call (write val) him/herself in the repl ... but nobody ever wants this on large lists, arrays and bytevectors, in this case, the user will prefer to write a custom procedure (that write n a file or 'filter' what they need ...