IRC channel logs


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>old, I don't think so. I think it needs to be a "feature symbol".
<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>well semi
<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>While compiling expression:
<lloda>In procedure "dlopen": file "", message " 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
<sneek>dsmith: Greetings!!
<dsmith>sneek, botsnack
<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 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
<lloda>why can't we have both
<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 ...
<daviid>going afk, bbl
<dsmith>Hmm. About LD_LIBRARY_PATH. Does *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 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. ./ no longer works.
<dsmith>ACTION sighs
<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>my 2c, it seems we won't agree
<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>The error I get is
<dsmith> case $PKG_CONFIG in
<dsmith> [\\/]* | ?:[\\/]*' is not a valid shell variable name
<dsmith>Full stderr output:
<dsmith>Seems ok if I comment that out,
<mirai>is guile suitable for running in embedded systems like (linux) routers?
<old>mirai: define suitable
<old>like low memory environment?
<mirai>and low (flash) storage
<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>And also make distcheck
<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.
<sneek>Welcome back dsmith :)
<dsmith>sneek, botsnack
<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>is this info on the manual somewhere?
<dsmith>Hmm. Not sure
<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
<haugh>sneek seen count3rmeasure
<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.
<haugh>sneek botsnack
<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
<acdw>oh fancy
<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)