IRC channel logs
2023-03-21.log
back to list of logs
<old>how would one use cond-expand to define a `spawn' procedure if < 3.0.9 ? <old>I don't expect distro like Ubuntu to have support for 3.0.9 soon so I would like to have compat for 3.0.7 <old>I guess somethine like (unless (defined? 'spawn) (define (spawn ...) ...))) could work? <dsmith>The list of available features is %cond-expand-features in boot-9.scm <old>dsmith: I don't see spawn in *features* :-/ <old>eeeeh I can't do a `(unless (defined? 'spawn) (define (spawn ...) ...))' <old>can't do a define at that level <daviid>old: i would define a module, and ask users to import if ... to keep things simple - and by the time you have users - iiuc you are still defineing and working on the lib - maybe that version you require will have made it to most distros ... <daviid>you could also 'always' define and distrib the modules, and import it yourself if ... <old>It's all internal to a project <old>Part of the build system actually <old>rn the defined? approach seems to work and I re-export the binding if not defined <daviid>ok, i thought you were still looking for a solution, it seems you found your way ... great <old>On system where spawn is not available, I have to do serial building because fork and threads are not working great together <old>I emulate spawn by using primitive-fork + dup2 <old>Maybe I could try with open-pipe instead <daviid>old: 'the all thing is too complicated already' :) - i'll let you find the best solution then ... i just thought you wanted to define spawn and import it, for older (but not that old) guile versions ... <daviid>lloda, dsmith I justed posted a mail to guile-user, with an attached guile-cairo patch that fixzes both make check and make distcheck ... please double check, try ... and let me know ... tx <jpoiret>old: open-pipe has the same problems as system and friends <jpoiret>it internaly uses the same C procedure <lloda>daviid: if i apply your patch check & distcheck all work fine but when i (import (cairo)) elsewhere i get scheme@(guile-user)> (import (cairo)) <lloda>In procedure "dlopen": file "libguile-cairo.so", message "libguile-cairo.so: cannot open shared object file: No such file or directory" <lloda>since you've removed *cairo-lib-path* <lloda>this is using --prefix=/only-for-guile-cairo so you can't rely on the .so being in the libpath. The use of *cairo-lib-path* was able to handle that <daviid>lloda, this is expected, you (users) need to set/augment LD_LIBRARY_PATH if your lib is not in the 'usual' location(s) <lloda>but with how it was written before, i didn't need to do that. You only needed to give the path to guile-cairo once. Now you need to do it in two different places, and it becomes possible for libguile-cairo.so and the scheme files to be mismatched. <lloda>so i think it's better if the older mechanism is kept <daviid>but you complained make check did not work ... (hence i tried to help) and make [check]distcheck fail is a disaster afaic - so, you can't have it both <daviid>so i think the new approach is much much better, fwiw <daviid>because, as explained in the log, you'd need to install to run make check, and make distcheck would never ever work, since it 'isolates' the build ... <dsmith>Hmm. About LD_LIBRARY_PATH. Does libguile-cairo.so *ever* need to be loaded by anything other than guile-cairo? <dsmith>If so, then yeah it needs to be on the LD_LIBRARY_PATH <daviid>dsmith: all lib that produce a lib, guile-cv, g-golf ... to name 2 <dsmith>The guile-sqlite interface that sneek uses has the .so installed under extensions, and is not named lib*.so <dsmith>Bah! I can't remember where the git repo is! <lloda>idk this still looks like a regression to me. Imo the fact that only guile-cairo uses libguile-cairo.so is a reason to keep the libpath private to guile-cairo and not the other way around <daviid>i am sorry i lost my time on this then - 2 days, make distcheck had a few problems .. - and imo, having to install to check is 'heresy' [and dangerous], you destroy the already instgalled version .. <dsmith>Hmm. Well it seems things have bitrotted for me. ./autogen.sh no longer works. <daviid>so the current situation is totally wrong afaic, and the new respects all gnu standard, can't call that a regression :) - as you can't call 'it handled the situation' if it breaks mak check and make distcheck ... <daviid>i should never tried to fix this, i lost 2 days <lloda>you've fixed something that was broken before, that doesn't seem like a waste of time <lloda>i think it's just not ideal, even if it's better overall <lloda>i'll reply to the list and let's give it a few days <dsmith>Calling all auto* tools wizards: what's wrong with this: <dsmith>AC_SUBST(GUILE_SITE_DIR, `${PKG_CONFIG} --variable=sitedir guile-3.0`) <dsmith> [\\/]* | ?:[\\/]*' is not a valid shell variable name <mirai>is guile suitable for running in embedded systems like (linux) routers? <old>mirai: define suitable <old>like low memory environment? <old>I've never experience Guile on embedded system, but I would like to have the answer also <old>There's probably a way to have a bare-minimal version of Guile that is lighweight <dsmith>The Makefile code or the env code that runs during make check should be able to add the build dir to LD_LIBRARY_PATH as needed. <dsmith>Guile seems to be able to run make check with no problems.. <dsmith>mirai, Are you familiar with buildroot? There is a buildroot package for Guile. So someone is probably using it for embedded somewhere. <mirai>I didn't see it packaged in openwrt so I was curious if it was due to lack of interest or if there were technical reasons behind <dsmith>Used to use buildroot a *LOT* on previous $DAYJOBs, but never had an opportunity to use Guile there <dsmith>If you have a RO filesytem, need to pre-compile all your .go files. <euandreh>is Guile bytecode the same on different architectures? <euandreh>as in: if I compile something for x86_64, the .go file is loadable in a aarch64 system <dsmith>There are a total of 4 different .go "archs", {big,little}-endian and {32,64}-bit <euandreh>I couldn't find it, and I started grepping the source tree before asking here <dsmith>If you run `file` on a .go, it will show you something like: ELF 64-bit LSB shared object <acdw>hi guilers! are there any resources for how to get started with medium- to large-size projects in r7rs using guile? i'd like to try using akku as well ---- if not no worries, i can figure it out <sneek>I last saw count3rmeasure in #guile one day and 3 hours ago, saying: haugh: perfectly understand, good luck. <haugh>sneek later tell count3rmeasure so the other day you mentioned interest in using guile-json with the GNU extensions to srfi-9 and I just wanted to let you know that they're fully compatible; you just have to use set-field/set-fields with the json record getters. Lmk if you want to chat more about it, it's pretty sweet. <dsmith>Well!, That problem I had above with AC_SUBST(GUILE_SITE_DIR, ...) went away after I removed packaged guile-2.2* from my system. <acdw>haugh: wait what you talkin bout? I use guile-json, sounds cool <haugh>acdw, if you're unfamiliar, check out the "functional setters" index in the manual (under SRFI-9 Records) for the GNU extensions. They return new records using shared memory for unchanged fields. I was under the false impression that, because guile-json doesn't let you define setter procedures, I would have to map those records over to separate srfi-9 records with setters, but I can just use set-fields with the getters created by define-json-type or <haugh>There's also set-record-type-printer! which is just obscenely fun to use with guile-json records because it massively improves the readability of API output (my usecase)