<rlb>does pkgconf not provide a (sensible) way to shadow/override existing config files? i.e. say I have a system (deb) install of guile-3.0, and then I ./configure --prefix=/home/foo/opt/guile-test. It looks like I can't just say PKG_CONFIG_PATH=/home/... because that doesn't override the /usr/lib/... guile-3.0.pc file? <rlb>If not, then wonder if we might want some kind of --with-guile support in GUILE_PKG... <rlb>i.e. so a project using GUILE_PKG can just ./configure --with-guile-pc=/some/specific/guile-foo.pc, perhaps using pkgconf's --with-path option. <rlb>"perhaps implemented using" <sneek>tohoyn, daviid says: I pushed a fix, please pull, clean, and try again, let me know ... <daviid>tohoyn: ok great, let me know how further testing this new 'version' goes, in particular, <gdk-event> instances, signals and proccessing (accessors) ... <tohoyn>daviid: I'll make a new g-golf-debian release first and check that Theme-D-Golf works with that <daviid>tohoyn: make sure you remove the dependency on gtk-3 in the updated debian package <daviid>tohoyn: can't you check theme-g-golf against a local g-golf before to work on the g-golf debian package? <leoprikler>rlb: you'll also have to put a valid package configuration in that path, but other than that it should work <tohoyn>daviid: I'm already building the g-golf-debian package so I'll use that. However, I won't make a g-golf-debian release before I have checked it with theme-d-golf. <leoprikler>how else would GNU Guix be able to use Guile correctly? <tohoyn>daviid: so g-golf shall not have a gtk3 dependency at all? <leoprikler>You could probably make it a suggested dependency, but G-Golf does not depend on Gtk3 in any way. This is somewhat important, as you can now also load Gtk4 with it. <daviid>tohoyn: right, though 'make check' currently uses gtk-3.0 - i hope to update the test-suite to not depend on anything but glib, gobject and gi - but building g-golf does not depend on gtk-3.0 anymore <tohoyn>daviid: so g-golf shall not have any GTK dependency at all? <daviid>right, except, currently, to run 'make check' <tohoyn>daviid: if "make check" needs GTK then the GTK dependency can't be removed <tohoyn>daviid: If I remove the dependency the sbuild environment shall not have any GTK library at all => build fails <daviid>tohoyn: not depending on gtk for the checks is on th todo list <tohoyn>daviid: I suggest that we remove the GTK dependency when make check has been fixed <daviid>the dependency is removed - but commented in configure.ac, if you still need it to build the debian package, till i fix the test-suite, just uncomment the line <tohoyn>daviid: ok. I'll check how the g-golf-debian build works. <tohoyn>daviid: theme-d-golf works with the new g-golf <rlp10>How do I compile to a binary executable file? I think that guild compile -o hello hello.scm gives me a file which still requires guile to run. <rlp10>RhodiumToad: Understood; no wonder I was having difficulties finding how to do it then! <rlp10>That said, the auto-compile feature does seem to conveniently produce pretty fast binaries. <wingo>yeah guile can't produce standalone binaries right now <wingo>the only native code compilation it does is just-in-time <tohoyn>daviid: I was wrong. The g-Golf debian build worked without the GTK dependencies. <manumanumanu>rlp10: So, what currently is going on is that the compiler produces bytecode, which when run in jit-compiled using a template JIT. No fancy-pants tracing jit, but a template JIT which more or less "just" translates the bytecode into native code without using any information at run-time to do optimizations. The obvious benefit is simplicity with the added bonus that generating native code directly at compile <manumanumanu>time becomes a smaller step if the guile maintainers decides that is a good idea. "Native code" still might mean you need guile to run it. Chez scheme, for example, produces very fast native code, but you still need to run it through chez or using a binary that bundles chez in some way. ***apteryx is now known as Guest67518
***apteryx_ is now known as apteryx
***Guest71000 is now known as nalkri
***wxie1 is now known as wxie
<chrislck>any (ice-9 match) gurus here? what's a good example of the set! clause? <civodul>chrislck: not a guru but a happy (ice-9 match) user and... i've never used that clause! <chrislck>I do too, just think it's probably magic for something <chrislck>eg consider (match people (() #f) ((? spouse-name this) . rest) ...)) <chrislck>^ I'm well aware 'this' can be used, but can the spouse-name also be used somehow? <civodul>'=' applies 'spouse-name' to the match object <civodul>whereas '?' matches if the predicate does <chrislck>no: (define (spouse-name person) (and (married? person) (get-name (get-spouse person))))) <chrislck>looking how to use both 'person' and 'spouse-name' in the resulting expression ***rekado_ is now known as rekado
<chrislck>uh this is not relevant to the match query <rekado>I do this often where I use “and” to apply different match queries to the same thing and use all the bindings in the clause <rekado>(and (? get-nato this) (= get-nato nato)) <chrislck>not bad..... still ends up with 2 calls to get-nato *chrislck was looking for a => style trick <chrislck>civodul: uh this is exactly what you were trying to say..... <rekado>ArneBab: I’ve been working a lot with Wisp today and I keep stumbling upon missing leading dots when splitting up expressions over multiple lines. <rekado>this got me thinking: can we avoid the need for a dot before string literals, numbers, and keywords? <rekado>isn’t it obvious at read-time that string literals and numbers will never be applied to anything? <civodul>rekado: at read time there are no semantics <civodul>you can't tell if it's a call or a literal list or something else <rekado>but we have sufficient context to know if a string literal is in applicative position, don’t we? <civodul>or: (define-syntax-rule (kwote (lst ...)) '(lst ...)) (kwote ("s")) <rekado>so… I wonder if GOOPS would let me specify a #:procedure for the <string> class and have that affect string literals. <civodul>i think this would be super evil, if i may <civodul>papering over syntactic issue through run-time tricks, uh! <civodul>that's actually my understanding of what Ruby does, but maybe it's unfair? <rekado>is it really “super evil”? Or is it just icky? <civodul>"super evil" in my book, but YMMV :-) <civodul>leading dot is when splitting a list? like (a b c) and you want "b c)" on the continuation line? <rekado>I guess I’m the text-book example of someone slipping on a slippery slope. <rekado>leading dot is to prevent application <rekado>normally, anything that begins a line is considered application <civodul>dunno if wisp can address it on its side <rekado>my hack would be to assume that you mean (identity "foo") if you just write "foo" on a line by itself. <civodul>since wisp is just surface syntax, i wonder if it can make such assumptions <civodul>probably not, just like 'read' cannot <civodul>dunno, but surely ArneBab will find out :-) <rlp10>manumanumanu: Thanks for your answer earlier regarding compilation of guile programs into binaries. I appreciate your response. <rlb>rlp10: and I suspect this might not be the case, but if you really do need a top-level binary, then you can build that via a likely very small bit of C code. <rlb>(linking against libguile) <mwette>I wonder what is meant by "compile to binary". Does that mean the binary does requires only the guile distribution to run? <lloda>binary is such a meaningless word in that context :-\ <lloda>but i don't see how Guile programs could run independently of Guile since you can call compile at anytime <rekado>I think the GOOPS hack might not work. (make <string> "foo") is different from just "foo". <rekado>I suppose I could implement this in the wisp reader instead. <rlp10>rlb: Interesting. I don't know any C I'm afraid, so I'm not sure I would even know where to begin. The main reason I was interested in having a top level binary was so that I could distribute it without installing guile on the target machines, or worrying about which version they might have installed. <rekado>rlp10: you can use “guix pack -RR” for distributing standalone binaries <rlp10>rekado: So I would need to code a guix package which included by script, right? And then guix would package up guile and anything else I needed along with my script all into a single binary? <rlp10>I'm reading the "Invoking guix pack" page now from the Guix documentation. This seems like clever stuff to me.