***sneek_ is now known as sneek
<daviid>fnstudio: do you have a repo we can look at to help you wrt autool chain quiz we made? <daviid>sneek: later tell tohoyn fwiw, as i mentioned already, 'finding' guile and its files, when multiple guile install, has nothing to do with g-golf <daviid>sneek: later tell tohoyn if you think you found a bug related to guile.m4, please build a foo/bar super tiny project, which uses the latest guile.m4, write a target that prints all guile related variable and report a bug to bug-guile ... <daviid>sneek: later tell tohoyn ' ... nothing to do with g-golf ...' after I fixed am/guile.mk - in aa405f16b42498054f390a32036a11bb67f93a2b (May 2020) that is .. <daviid>fnstudio: fwiw, unlike said above, I would highly recommend you use guile.m4, together with a few other autotools chained project settings, it is the safe route to distribute either a guile lib or a guile app ... i'd be happy to help, if you are interested of course ... <daviid>fnstudio: and use the autotools chain to 'generate' the script that launches your app, if/when your are writin and app, which'd be installed in $prefix/bin (with no auto compile settings) ... that merely start guile then import your modules and calls the 'animate' procedure of your project ... <daviid>rlb: right, i do not have virtualbox installed here, tx for the tips though, i'll seee if i can fix the libvirt/qemu approach first, tx <rlb>Of course you can always just grab the installer, etc. But then you have to run the installer -- with the vagrant images, they just come up with "vagrant ssh" support (same for freebsd). <daviid>rlb: fwiw, I just tried on another (remote) machine I have access to, it runs bullseye (with no additional experimental repo, just 'bullseye') and it fails with the same error then here <daviid>i'll try buster right now (another machine as well ...) <daviid>rlb: not that what I am writing gives us any better info then earlier to debug, but at least it is not just my machine (which I updated to be able to install gtk-4.0, so it could have been the origin of the problem ...) <rlb>And lokke is failing, or just g-golf? <daviid>i only tried g-golf so far, i'd have to install lokke there to *rlb just got a primitive clj defrecord working... <rlb>No worries, just wanted to make sure I understood the situation. <rlb>So this might just be something g-golf specific... <rlb>(defrecord, ->Type, and map->Type -- should help run more existing code) <daviid>maybe, but i doubt - unless something in the libg-golf.c[h] file maybe? don't think so, but ... <rlb>Well, I just mean if lokke and guile build and work fine with the newer libtool, then there's likely "something else" going on with g-golf *somewhere*, either directly or indirectly. <rlb>(For anyone interested: https://clojure.org/reference/datatypes -- in the longer run, we might want something more efficient, and more immutable, but for now I'm just letting a simple goops translation handle the heavy lifting -- and don't have any support for the optional protocol methods yet.) *rlb likely wanders off soon. <daviid>rlb: i'll try lokke on that remote machine, i am now doing the updates, in a few minutes, we'll know <daviid>ah, this guile.m4 related error - you ahould add guile.m4 to lokke, imo <daviid>rlb: ok, lokke also fails on that other 'unmodified' debian bullseye machine <daviid>rlb: could it be that i have to rebuild guile? because the common 'thing' on these machines is it uses a manually com piled installed guile <rlb>I've never tried manually adding anything -- see the lokke readme, for now it's just "./setup && autoreconf -fi && ./configure && make -j5 check". <rlb>Oh, hmm, don't know -- I'm relying on the guile-2.2, guile-2.2-dev and guile-3.0, guile-3.0-dev packages. <daviid>rlb: this guile.m4 problem is 'very common', and is AC_LOCAL related, it almost always fails on users, hence i now (for the last decade or so) always provide guile.m4 in all projects i work on <daviid>providing guile.m4 also make sure the message, if users do not have guile at all, is 'nice', not an unreadable message ... <daviid>now, back to this error, it weas my impression that 'that part', building the c lib, has nothing to do with guile, the error happens far before compiling g-golf, it happens at building the shared lib for libg-golf, liblokke ... but i'll recompile guile and see, will let you know ... <daviid>rlb: it works - with manually installed 2.2, after I uninstalled, pulled, run the danse ... recompiled/installed guile, both lokke and g-golf now build there respéctive shared lib ... and compile till the end :(, and make check pass for both as well - <sneek>Welcome back tohoyn, you have 3 messages! <sneek>tohoyn, daviid says: fwiw, as i mentioned already, 'finding' guile and its files, when multiple guile install, has nothing to do with g-golf <sneek>tohoyn, daviid says: if you think you found a bug related to guile.m4, please build a foo/bar super tiny project, which uses the latest guile.m4, write a target that prints all guile related variable and report a bug to bug-guile ... <sneek>tohoyn, daviid says: ' ... nothing to do with g-golf ...' after I fixed am/guile.mk - in aa405f16b42498054f390a32036a11bb67f93a2b (May 2020) that is .. <tohoyn>daviid: I just did "git pull" for it <daviid>tohoyn: that has nothing to do with g-golf <daviid>you can build a seperate project that just check for guile, it will display the same messages <tohoyn>daviid: so is it a bug in guile.m4? <daviid>i think you have multiple guile installs, but wrong local vars ... nobody on earth can debug but you <daviid>tohoyn: it is a problem on your machine, your config, and/or your distro ... not g-golf or any other projects fwiw - as i said, just generate a foo/bar project, minimal, just configure.ac and what it needs, and see (for yourself) <daviid>tohoyn: maybe there is such a minimal project out there, a 'hello-world' guile based autotool chained minimalist project ... <daviid>tohoyn: yu may also try to purge one of the guile, really aptitude purge, not a manual 'clean or hide' thing <daviid>then re-run ./autogen.sh, then ,/configure ... <tohoyn>daviid: does g-golf configure work for you if you have both guile 2.2 and 3.0 installed? <daviid>i don't use debian guile packages <spk121>tohoyn: and daviid. For my Ubunu Bionic CI builds for some projects, I have to do "GUILD=/usr/bin/guild ./configure ..." because Ubuntu's guild is not named according to the naming scheme expected in Guile-2.2's guile.m4 <daviid>spk121: no idea, but GUILD is set by guile.m4, i mean if you call GUILE_PROGS in your configure of course <tohoyn>spk121: I've got guild, guild-2.2, and guild-3.0 in my Ubuntu <daviid>spk121: i was saying the above thinking that if you call GUILE_PROGS in your configure.ac, would that not erase your 'pre setting' as in "GUILD=/usr/bin/guild ./configure ..." ? don't know <tohoyn>daviid: I just filed a bug to bug-guile@gnu.org <daviid>tohoyn: i would have sent the bug to ubuntu first, but it's ok - <ATuin>hi, i'm trying to convert some lambdas into syntax using datum->syntax but i get this error: unhandled constant (s). s is the parameter to the lambda. Any idea why? <leoprikler>I think it'll be easier if you use raw expressions instead of lambdas. <ATuin>i'm kind of new to macros, so i'm playing with them <leoprikler>Depends on what exactly you're trying to achieve in the end. <ATuin>ok, this is the idea: I'm doing a macro do define enums, it creates som hashmaps between symbols and ints and then defines several functions using define-values <ATuin>the idea is that having an optional #:flags keyword the macro will create an extra function that or the arguments passed to it <leoprikler>Handling optional arguments puts you deep into syntax hell, but you can look at stuff like use-modules for pointers on that. <leoprikler>For a proof of concept it'd probably be easier to do define-enum and define-flags separately <ATuin>without the optinal flag it works <ATuin>since i create the lambdas inside the macro, so no problems <ATuin>i will look at use-modules then <leoprikler>Ehm, do you actually produce the same amount of names and values? <ATuin>just to test that i could get the same identifier at the end <ATuin>there is left to add the new name and value <ATuin>the first paste produces an extra value when running with macroexpand but it fails when compiling the expression <leoprikler>Probably because define-values is itself a macro, which then fails to compile <leoprikler>or maybe not, the number of values is taken from runtime <leoprikler>but to be frank, couldn't you just syntax-quote or syntax-quasiquote those lambdas? <ATuin>instead of using the datum->syntax <ATuin>ok, i will play with that then <leoprikler>you just need to be careful of where to unquote, so that you get the actual hashtables <ATuin>yeah, those should be created at compile time right? <ATuin>i mean i know the symbols at compile time so unless they change in the source they should be always the same <ATuin>it's quite confusing (but fun) this macro thing :D <ATuin> mwette thanks! looking at it <ATuin>`(eq? (syntax->datum #'key) #:use-ffi-module)` ahhh you can have guards in macros also, nice <mwette>they are called `fenders'; for syntax-case, not for syntax-rules <ATuin>i also see that you use the code generated by a syntax-case in the syntax-rule later, nice <ATuin>i think i can learn one or two things with that <ATuin>actually my problem now is that i'm confused when merging the code from one macro into another, since i get symbols that are not resolvable in the final code <mdevos>does someone have a guix environment for building guile from git (for development)? <leoprikler>mdevos iirc it was --ad-hoc autoconf automake pkg-config texinfo, maybe texlive <mdevos>leoprikler: thanks! Will try later