IRC channel logs

2022-01-23.log

back to list of logs

<stis>Tjenixen guilers!
<civodul>o/
<mwette>hi all
<drakonis>eyyy
<lampilelo>is there a way of silencing "possibly unbound variable" warnings for stuff defined in an external library? i know i can (define foo #f) before loading the library but is there a better solution?
<lampilelo>hm, test
<lilyp>hum, are you sure you're handling that external library correctly?
<lilyp>typically you should put the use-modules clause first
<lampilelo>i mean the shared library is a part of a module i'm defining and loaded by load-extension
<rlb>Is it possible to precompile a #! script? i.e. given ./test/something, can I compile test/something.go (or similar) in advance and get invocations of test/something to use it instead of compiling to ~/.cache/guile/...?
<tohoyn>lampilelo: you should a eval-when clause to load the extension
<mwette>I see that all the time when I use load-extension
<mwette>I usually end up putting it in a scm-coded module for that extension so I only see it once.
<rlb>lampilelo: I've just been pre-defining the bindings to #f.
<rlb>fwiw
<lampilelo>tohoyn: ah, yes, that works, thanks
<mwette>rlb: if in a module you'd have to make it #declarative? #f, right?
<rlb>hmm, maybe I'm not doing that anymore -- can't find where I had it. But yeah, wrt declarative, certainly semantically, if the extension's going to mess with the binding.
*rlb comes across his note to discuss adding a way to provide a superclass to make-foreign-object-type while looking for that... https://git.sr.ht/~rlb/lokke/tree/main/item/mod/lokke/scm/foreign-object.scm#L18-23
<rlb>(Though not sure when I'll get a chance to pursue it.)
<rlb>btw, the question about pre-compiling #! scripts was in the context of executable #!...guile tests, i.e. test/something test/something-else in a project.
<lampilelo>what do you mean by a #! script? can't you compile with guild?
<lilyp>rlb: you can, but you need to be careful where to put it
<rlb>lampilelo: I can, but need guile to actually find it when the script is run later.
<lilyp>if you name you module foo.scm and the corresponding script foo, then there might be some overlap
<rlb>hmm, there's no module.
<lampilelo>what if you add the directory to %load-compiled-path?
<rlb>This is just a guile #! script
<lampilelo>ah, hm
<rlb>And I can see via strace that guile doesn't look anywhere for it.
<rlb>(well, actually, need to double-check that)
<lilyp>then it ought to work with foo → foo.go
<rlb>It doesn't seem to -- just seems to check for ~/.cache/... and then give up and compile to there, even if I set GUILE_LOAD_COMPILED_PATH -- doesn't look in there at all.
<rlb>There are of course workarounds, i.e. I could just move the bulk of the code to an indirect file that I can compile, or if there's a way to ask guile to execute a .go file, I could have stubs (or makefile patterns) that do that, but either is a bit awkward.
<linas>clojure for guile. the mind boggles.
<drakonis>does it?
***iridium.libera.chat sets mode: +o ChanServ
<drakonis>geiser with guile doesnt support cooperative repl servers, right?
<morganw>If something is running the repl you can just connect using geiser-connect, it prompts for the host and port number as part of that.
<sneek>Welcome back morganw, you have 3 messages!
<sneek>morganw, lilyp says: there's save and load, but it's more or less re-executing everything until then. You can be clever and save some hefty computations by using inner scripts, which only do the first line. You can add custom state and load hooks to save variables that Tsukundere itself doesn't manage
<sneek>morganw, lilyp says: this might probably be too hefty for a generic game engine, but for visual novels – especially small ones – it's no big deal at all
<sneek>morganw, lilyp says: pull requests welcome if you want it to change, though :)
<drakonis>i see.
<drakonis>interesting.
<drakonis>any fosdem talk spoilers?
<rlb>civodul: removed the git build dep and got make distcheck working, so lokke might be easier for you now wrt guix.
<lampilelo>rlb: seems like it's a bug if it doesn't check the stuff in GUILE_LOAD_COMPILED_PATH
<lilyp>I think the mapping is a different one exactly because of the potential collision
<lilyp>You could try checking whether symlinking it to an .scm file with the same name and compiling that makes a difference
<rlb>Not sure, and haven't had time to look at the code yet. For now, I'll likely just ignore the autocompilation for the tests. One reason I'd wanted to precompile was that explicit compilation had found a bug that didn't show up otherwise.
<rlb>(but that was complicated, and was just the thing that got me motivated to try it)
<rlb>lilyp: not sure what you mean by mapping - guile doesn't look *anywhere* for the .go file except ~/.cache (checked via strace).
<rlb>(doesn't look when running via #!)
<lilyp>you do know there's an sh exec hack that you can also try, right?
<rlb>Or maybe you just mean that it might not look anywhere else if the path doesn't end in a known extension...
<rlb>which one?
<civodul>rlb: ah neat, i'll give it a try then!
<rlb>(i.e. not sue if I do know about it)
<rlb>civodul: might well still be some rough edges :)
<rlb>(well much of it is still rough edges, I suppose)
<lilyp>#!/bin/sh\nexec guile -e main "$0" "$@"\n!#
<civodul>rlb: i'll make sure to let you know ;-)
<rlb>lilyp: ahh, right -- I wondered if something like that might get it to find a foo.go for foo...
<rlb>I suppose in the longer run, having #!...guile respect the compiled load path would be good. If I get time, I might go see what's going on there.
<rlb>guile.m4 should probably set GUILE_SNARF too?