IRC channel logs

2018-03-19.log

back to list of logs

<spk121>ArneBab: nice
<mwette>ArneBab: no -- I may be wrong. I have done this sort of thing in C many years ago, but not looking easy in guile. And the documentation is not clear on all items.
<ArneBab>it looks really easy but I don’t understand the bug — I don’t understand where it comes from and why it should even be possible
<ArneBab>but I firstoff need to go to bed now
<ArneBab>cu -- and happy hacking!
<mwette>sleep well
<Apteryx>how can I refer to another Guile module which is in the same directory?
<Apteryx>Without having the strict define-modules and load-path set right?
<spk121>Apteryx: you can include the file using (include ...). It is not a reference, but, more like #include <> in c
<Apteryx>spk121: I need to use the absolute path in this case?
<spk121>I think if file 1 includes file 2, it searches for it in file 1's directory
<Apteryx>cool!
<spk121>But I'm going from memory. I could be wrong.
<Apteryx>works! I've used load though :)
<Apteryx>thanks
<rekado_>I’ve hit some odd errors when modules mutually use record accessors from one another.
<rekado_>the error messages are not very helpful, for example: In procedure module-lookup: Unbound variable: <tile>
<rekado_>there is no use of “<tile>” anywhere; it’s a record name. I do use one of its accessors on an instance of that record, though.
<rekado_>Another variants of this error: “ERROR: Wrong type to apply: #<syntax-transformer player-name>”
<rekado_>“player-name” is an accessor for the <player> record type.
<daviid>rekado_: I would try to reproduce on a tiny example, 2 modules, 2 records, each having 1 accessor, import both ... and paste
<rekado_>I already found the module(s) that I may not import, but this error and its message are disappointing.
<amz3>o/
<OrangeShark>hi amz3
<daviid>rekado_: what do you mean you may not import?
<rekado_>daviid: I mean: when I add a use-modules clause for that module the error appears. When I don’t import it, there is no such error.
<rekado_>There’s nothing wrong with the module itself; I suspect it’s because of mutually recursive dependencies.
<daviid>rekado_: afaict guile handles mutually recursive module dependencies, at least in the past I did have that 'situation'. I asked because maybe it is so that you have diff modules with diff record names (as expected if you export), but then same accessor names ... just curious
<rekado_>no, the accessor names are all prefixed with the name of the records.
<rekado_>I’ll continue to play with this later; maybe there’s a smaller test case I could present.
<daviid>rekado_: but you have accessors bearing the same names in the first place right? it would be interesting to post a tiny but complete self reproducible example yes: then maintainers could debug it ... I'm personnally asking, not that I will be able to debug and patch, but because I would be interested to reproduce 'your case' using goops ...
<spk121>Heya. I'm writing an terrible interactive fiction game in Guile, and the process is making me very happy.
<manumanumanu>so, I want to do the following: I have written a complete binding for libsodium 1.0.14, and I want to future-proof the library. If the library I find on the system is 1.0.15, I want to provide all the bindings from 1.0.14, and some additional ones. How would I best do that? Some sort of cond-expand trickery or using version numbers of libraries (and how would that work? Docs are sparse)
<daviid>manumanumanu: is your project autool chained?
<manumanumanu>daviid: preferrably I want it to be a directory you just copy to the site-dir or wherever you want to have it
<daviid>because that is where you would implement such diff
<daviid>your answer means that the user does not run any check then? he/she copy, but there is no garantee libsodium is installed ...
<manumanumanu>then it of course fails spectacularly, but yes: it should be a self-contained module that I can just copy without any configure, make and make-install thingies
<daviid>manumanumanu: if your are serious about your binding, I would autotool chain, but you can surely play games, like use (system "pkg-config --modversion libsodium"), grab the result and include or not a file if ...
<davexunit>+1 for autotools
<manumanumanu>the coolest thing would be if the person could du (use-modules (libsodium hashing (1 0 15))) and it exports everything from 1 0 14 plus any additions of 1.0.15
<davexunit>I'd find that odd
<davexunit>no other guile bindings work that way
<daviid>but that 'tricky approach' will fail, one day or another, to 'fullfill the bill', imo
<davexunit>a cond-expand equivalent that worked on the version of the library detected by a configure script would be sufficient, I think
<daviid>manumanumanu: yeah, you should autotool chain, really worth it
<davexunit>though I've made many library bindings and have not needed such things
<daviid>manumanumanu: agree with davexunit here, we don't do that, rather we bind a lib version, then another version means a new release, users grab the release they need, but the latest binds a specific lib version ... and this copy will lead to problem, no doubt in the long run, like hw to uninstall, install a new version ... you are ready for hell path :)
<daviid>manumanumanu: that is exactly why autotool exists, so why not using it?
<davexunit>if I wanted to gracefully handle a function that may or may not exist, the 2 options would be 1) don't compile it at all (macro) or 2) catch the exception from the ffi when you try to bind it and use a stub procedure instead (runtime)
<daviid>manumanumanu: with autotool you will have good support fr doc build, test suite ... distro can rely on your work ...
<manumanumanu>where would I go to learn this magic autotool?
<manumanumanu>ah. found it
<daviid>manumanumanu: grab a simple projects of one of us, then read a tutorial ... I can paste a link if you wish
<davexunit>manumanumanu: I would recommend grabbing the configure.ac and Makefile.am files out of another Guile project
<davexunit>and then you have a good base to work from
<daviid>someone wrote a template somewhere, davexunit do you remember?
<daviid>I think it is OrangeShark , but i might be wrong
<davexunit>oh yeah!
<davexunit>manumanumanu: https://erikedrosa.com/2017/10/29/guile-projects-with-autotools.html
<daviid>right, thanks davexunit
<davexunit>this should be really helpful
<manumanumanu>Thanks.
<daviid>manumanumanu: the above template is a very good start, it lacks a doc and a test suite example, which you can complete your project with later on, looking at one example ... davexunit's projects use srfi-64 for tests, I use guile-lib test suite, for info