IRC channel logs


back to list of logs

<PurpleSym>It looks like Guile creates an empty, globally available module when the load procedure fails to eval the body of a module. Can I prevent that somehow?
<civodul>PurpleSym: the define-module form leads to the creation of a module
<civodul>if what comes next causes an exception, then you may not have all the bindings available in that module
<PurpleSym>My problem is that the importer sometimes creates invalid packages (missing dependencies, broken descriptions, …) and I have to filter those out.
<PurpleSym>Yeah, that’s exactly what I’m seeing, civodul.
<PurpleSym>And there does not seem to be a way to load a module without affecting the global module namespace.
<civodul>so the importer create syntactically invalid modules?
<civodul>i mean, things that throw an exception when you load them?
<PurpleSym>Yes, for some CRAN modules. Sometimes the Texinfo markup is broken, sometimes a dependency does not exist and a variable is not resolved.
<PurpleSym>(Technically I’m creating one module per imported package.)
<civodul>can we fix the broken-Texinfo problem?
<civodul>unbound variables should not be an issue, because those references are in thunked fields like 'inputs'
<civodul>so that won't prevent Guile from loading the module
<civodul>broken Texinfo can be an issue if you enable compile-time Texinfo validation (that's the case when using ./pre-inst-env)
<rekado_>PurpleSym: when you generate countless CRAN packages for a channel do you really care about descriptions and the like?
<rekado_>or is this for something else?
<rekado_>the importer doesn’t create texinfo markup by itself, or does it?
<PurpleSym>No, the importer does not create texinfo, but some description contain unescaped @ symbols, which are interpreted as markup.
<PurpleSym>civodul: You’re right, it’s not the variables itself, but me importing the corresponding module (i.e. r-foobar from (guix-cran packages r-foobar)).
<PurpleSym>I guess I’ll have to shell out to avoid the namespace pollution.
<rekado_>PurpleSym: ah, I see. We should update beautify-description then to escape @.
<rekado_>PurpleSym: have you compared your variable references with specification->package?
<rekado_>(in terms of performance)
<PurpleSym>rekado_: No, I haven’t benchmarked that yet.
<rekado_>if you have a package that exhibits an unescaped @ please tell me and I’ll add a test case and fix it in beautify-description.
<PurpleSym>rekado_: r-analysispipelines, r-bwgs, r-dief, r-psychmeta, r-recometrics, r-survtrunc, r-syllabifyr, r-tgs, r-tribe, r-trophicposition
<PurpleSym>All of them fail due to texinfo markup issues.
<rekado_>I’m rewriting beautify-description right now and extend it with a few more features.
<PurpleSym>Thanks 🙂