IRC channel logs
2024-02-15.log
back to list of logs
<daviid>i don't think guile-hall should 'hard' depend on guix, nor should it use any r7rs 'bazar'; (-) it should snarf the guix functionality it 'needs' and keep it in a separate guile module, clearly stating it's from guix, thanks to the guix team ... and just maintain a 'close eye' to update it as upstream guix functionality is itself being updated; (-) also, imo, no guile project should use another module 'bazar' but the (excellent, <daviid>flexible, elegant) guile module system - unless the project's objective is 100% portability (but then they may as well choose another scheme anyway) - my 2c <daviid>apteryx: wrt to the (hall common) paste, imo it also shows a project design 'failure': if 'current' guile-hall depends on guix, it should be checked upon (and clearly be reported when missing) at configure time, not 'as part' of a module definition ... <apteryx>daviid: I'm pondering on this. The original idea was to make Guix an optional dependency, and use #:autoload to load the few definitions needed <apteryx>unfortunately it seems this can cause issues due to the one of the definitions being a macro <daviid>apteryx: then you might consider auto creating the (hall common) module at configure time <apteryx>some complicated scheme I was thinking about: if 1. .go built without guix support but 2. users has guix available and 3. requests guix features, then perhaps the software could detect so and not load the .go files <apteryx>then it would evaluate the modules and the r7rs cond-expand would do the right thing (load the available guix definitions) <daviid>you should avoid r7rs in guile-hall <daviid>to sove a problem that clearly can be solved at configure time, using the autotool chain and guile <apteryx>it would solve it, but in an inflexible way, while what I wrote in my last last message seems like it would provide a means to users of a guile-hall distribution built without guix to use such features (albeit without the .go speed-up, which is not really important for guile-hall) <daviid>and imo, it would probably better to snarf the guix functionality guile-hall wishes to use and make it a guile-hall module ... this way, things are kept nice, clean and simple, and guile-hall may be packaged for other distro, which imo is a major 'criteria' and thing to keep <daviid>i stated my opinion, and stand by then: (a) do not use r7rs in guile-hall; (b) either snarf or make sure things are checked at configure time <apteryx>snarfing is not an option; since it needs to access the packages graph of guix <apteryx>thanks for the suggestions; I'll experiment some more and fall back to a configure-based solution if it's too complicated/doesn't work <daviid>cow_2001: if you are willing to try guile-cv, you need to patch (ice-9 boot-9), as explained in the doc, but you may also 'just' clone a fresh guile repo, then "git cherry-pick 1a919d9", run the ./autogen.sh;./configure [--prefix=...]; make [; make install or use ./pre-inst-env guile] - you still need to configure Guile’s repl-print procedure and apply the final steps of the Configuring Guile’s raised exception <daviid>system, the steps that are exposed below the dox entry "Finally, once the above is completed, add the following lines8 to ..." - let me know if you need help <cow_2001>daviid: it mentions guile-2 in the guide <cow_2001>can i just copy the (ice-9 boot-9) source somewhere and add that path to the GUILE_LOAD_PATH? <daviid>cow_2001: hum, which version are you using <cow_2001>guile 3.0.9 out /gnu/store/1gd9nsy4cps8fnrd1avkc9l01l7ywiai-guile-3.0.9 <cow_2001>even before changing the printing stuff - i cannot import (cv) <daviid>i think guix has an old version of guile-cv <daviid>cow_2001: that's a 'guix problem', i mean it has nothing to do with guile-cv, could you ask for help in #guix please? <apteryx>do we have something that resembles ifdef in Guile? <apteryx>plain 'if' would work at the top level I think... but not for nested forms <cow_2001>daviid: i'm working on it alone right now <cow_2001>daviid: what kind of help should i ask them? <apteryx>daviid: guile-cv needs a patched guile? <cow_2001>apteryx: if you do not patch, the error messages print all of the image vectors <cow_2001>the last commit of this work in progress branch is from 2022-10-13 <cow_2001>what's holding it back from being merged? <apteryx>daviid: even with checking for guix at configure time, how do I generate the right imports that depends on it? I'm not sure how to stitch things together. <apteryx>maybe the whole module would need to be a template, and some magic anchor variable, e.g. %guix-conditional-module-import%, which would be sed' to either hall/guix-support.scm or hall/no-guix-support.scm, which would define some variable that could be used in cond-expand in the hall/common.scm code <apteryx>ACTION tries something along these lines <daviid>apteryx, cow_2001 give me a sec, two successive power failure in the area .. <daviid>cow_2001: you should ask, in #guix, why after 'guix shell -C guile guile-cv -- guile -q', ,use (cv) fails <daviid>apteryx: though in the above last paste, the 'Configuring Guile’s raised exception system' starts by 1st explaining how to 'manually patch' the )(ice-9 boot-9) module, ofc if you apply/cherry pick 1a919d98514f1184b91085a19b55a4c719300149, then you may skip those steps and only take care of the user side config, those steps that follows the 'nearly last §, the one that says Finally, once the above is completed, add the <daviid>following lines to your home ... or init.scm in the so-called Guile global site directory ... <apteryx>the cleanest way to have guile-cv easily usable in Guix if it requires a patched Guile (and if said patch can't be merged in Guile itself for some reason) could be to have a guile-cv Guix channel that'd define a guile variant it uses (which applies the patches needed), such as guile-for-guile-cv <apteryx>the "guile-cv Guix channel" can be the Git repo itself, as done by Shepherd for example <apteryx>(the 'wip' in the branch name above suggests it may not be ready to be merged yet) <cow_2001>daviid: ended up sending a bug report. thank you! <daviid>apteryx: it's a decade+ branch ... the author is here, lloda ... who says it's not clean enough to be merged ... but 'no matter what' they say, it's needed so users may customize the raised-exception printers ... as describe here above and in the guile-cv manual <daviid>cow_2001: you're on debian, i can get you up and working there if you wish - which would be better because i'd get you the latest guile-cv version ... let me know <daviid>cow_2001: do you have sud access on your debian main distro? <cow_2001>yes, but i don't want to install it that way <cow_2001>but it's getting late and i'm getting tired. tomorrow i'll try and patch the latest stable guile for guile-cv in the package definition <daviid>cow_2001: if you can, both have the knowledge and some available free time, please do - be aware i don't use guix, so i am not gona be of any usefull help on that side ... note that this patch was created by lloda not for guile-cv, but because it is just impossible to do advance math (large vector/array/matrix) work in guile without the patch, and ofc the user config as explained in the guile-cv manual ... though i don't mind the name <daviid>guile-for-guile-cv, it actually would help any guix users who work wwith large to very large data structures ... <daviid>apteryx: wrt (hall common), let me try to cook something here ... will let you know when i have a (possible) solution ... <daviid>apteryx: just to make sure i understood correctly, you want to allow guile-hall users to either be able to call 4 guix provided procedures, or either raise a warning if they try one of those, but guix was not available at configure time, is this correct? <daviid>a warning or an error, it seems your macro approach would raise an exception ... <apteryx>(I simply opted to require Guix instead of having it optional, which would pull the "conditionally generate a module" not so fun problem to solve) <daviid>apteryx: oh - ok, but then guile-hall is useless, if it imposes guix, then users may as well package using guix, why would they use hall ... guile-hall was meant, initially a least, to allow guilers with no or little autotool chain knowledge, to package, as in autotool chain, their 'guile (scheme only) app/lib, and guile-hall itself would strictly depend on guile and the autotool chain, so it would be packaged by all distro 'out there' <daviid>... anyway, tx to let me know, i'll move this (not so boring) task (imo) to a lower pos in my stack ... <belzurix>hi, if I embed guile into my C program, can use the low-level FFI to access functions, or do I need to provide wrappers to it? I read the info manual, but it's unclear on this one. (foreign-library-function #f ...) doesn't work for this. <rlb>I believe the ffi will mostly just let you deal with "C types". If that's all you need, and also say if you don't need access to #defines like SOME_FLAG, then the ffi might be adequate. Otherwise, wrappers will of course let you present whatever API you like to the scheme side. <rlb>I also vaguely recall maybe some way to ask guile to hand you a symbol from the executable itself (i.e. not from an external shared lib), but I couldn't find it yesterday via a quick scan of the docs. <lloda>usually if you embed, you write the wrappers in C. You can still use the ffi if your C is exported in a dylib, but i think this is somewhat unnatural, because if you use the ffi there is no reason to embed <rlb>lloda: do you happen to recall anything about loading symbols from the executable itself? I thought one of the functions supported that via special argument or something, but maybe I misremember (and not a big deal either way -- just had a possible use for it). <rlb>...suppose I can always just go check the code :) <belzurix>I see. I wrote a bunch of wrappers, it would just be mostly unnecessary if I could call the functions after doing some scm_pointer_to_procedure, because the C code has the required tests on provided data <belzurix>I'm also providing callbacks written in guile that are right now called via scm_call1, and the info docs said guile could create directly-callable-by-C functions, but the code I wrote based up the docs segfaulted :/ <rlb>By default, if you're having to compile anyway, I'd be inclined to just follow the typical path and include a foo_init function that creates a module and places all your functions in it. But that's not required. And while it's also typical to have at least a small .scm file to load everything via load-extension, I believe you don't have to. <rlb>s/I'd be/I might be/ <rlb>Not sure why you're segfaulting, but sometimes it's because some SCM is being "hidden" from the GC. (Hit that the other day when working on the threading patches -- cleared a SCM in on_thread_exit when I shouldn't have, and...) <rlb>i.e. I cleared it there, and nothing else had a *direct* reference to it, and... <rlb>Though now that I think of it, that could have just been the caller hitting the NULL. Either way, don't do that :) <belzurix>I put a bunch of asserts into the C code for NULL checks and bounds checks <lloda>rlb: i don't know how to do that :-/ <lloda>you don't need to wrap scm_to_long etc. Those will throw if the SCM isn't the expected type <lloda>you can try -DSCM_DEBUG_TYPING_STRICTNESS=2 to flag uses of something else as SCM <lloda>for example the fun argument to scm_call_1 should be SCM, but idk how you're using that <belzurix>it's a void * iirc, because the pointers are stored in another module that shouldn't depend on guile <belzurix>it's only linux-specific because the size is defined by KEY_CNT which comes from a linux-specific header <rlb>belzurix: SCM_PACK/SCM_UNPACK might be relevant -- i.e. for converting C pointer to/from SCM. <rlb>(though the "conversion" may be trivial, depending) <rlb>i.e. likely no actual code on say x86_64 iirc? <rlb>There's also potentially interesting commentary about various bits in scm.h... <belzurix>this means that void* might be smaller than scm_t_bits <belzurix>I borrowed my code from xbindkeys, where they directly stored callbacks in an array of SCM values, because they only supported guile <rlb>belzurix: depends on what you're doing, but note also the scm_pointer api (or did you already)... <rlb>i.e. iirc that'll wrap an arbitrary c pointer in a SCM object with functions to manipulate it on the scheme side. <rlb>Though if you have much on the C side, you may well want to migrate toward smobs. <belzurix>thankfully the guile-specific C side is under 100 lines <mwette>rlb: (foreign-library-pointer (load-foreign-library #f) "printf") <mwette>I'm looking forward to more of whippet! <mwette>To call C functions from a library from C, I'd just use dlopen() and dlsym(). <mwette>The Guile Manual, Section 5.5, Defining Foreign Object Types, may be useful. <old>hmm it is not possible to raise an exception from operand-proc of srfi-37 args-fold <apteryx>daviid: once the build system is generated, guix is not need to build and package the application <apteryx>also, guix is packageable itself on other distributions; it's available as a package on Debian for example, and elsewhere. <apteryx>perhaps an interesting icon/art reference for your GC project <daviid>apteryx: to be really usefull, in the sense and as expressed by its original goal, guile-hall shouldn't depend on guix 'at all' - <janneke>goblins may be happy to collect any (hidden) whippets :) <daviid>cow_2001: i see guile-cv in guix is still 0.2.1 and claims to need guile-2.2, but the latest is 0.4.0 and will run with guile >= 2.0.14, 2.2 and 3.0 (>= 3.0.7) - you might want to update the package as well ... if you're still willing to work on this and whilew 'at it', that should be a lot easier then to patch (ice-9 boot-9) :) <daviid>wingo: congrat for the financial support for your work on wippet! what's the 1st experimental ETA? <apteryx>daviid: not sure why it's a problem to depend on guix for a project whose description mentions "[...] & provides tight coupling to Guix" <daviid>apteryx: that 'tight coupling ...' was, afaict, added as it (guile-hall) became guix dependent, that 'tight coupling' and now hard dependency was not part of its original goal - you (obviously) don't need guix to generate and maintain an autotol chain project structure and files (the 'original' goal) - <daviid>cow_2001: geat, thanks! it will be nice to see that guix has the latest guile-cv <daviid>cow_2001: sure, i'll let you and guix reviewers handle the 'practicle steps' to update guile-cv on guix, please move any quiz related to this on #guix (which i follow, but mostly 'quietly') <epony>Feb15 2218<epony> the disk array on the cluster for FSF/GNU hosted servers is going to fail <epony>Feb15 2218<epony> vote "fire" incompetent sysadmin for FSF "thomzane" on Friday <Arsen>they've been banned from #gnu/#fsf and are now spamming other channels <dthompson>working for the fsf is so thankless even without irc weirdos attacking you