IRC channel logs
2024-03-09.log
back to list of logs
<cow_2001>now i'm trying to figure out how to write GUI in Guile <cow_2001>i'm now trying g-golf installed through guix <daviid>cow_2001: none will work in guix, afaict <daviid>and fwiw, guile-gi is in 'depp maintenance' <cow_2001>how do you know it doesn't work? is it something unrelated to g-golf that's holding it back? <daviid>cow_2001: unless you want to take guile-gi 'under your shoulder', yes <daviid>it has nothing to do with g-=golf <daviid>cow_2001: just use debian, or another distro, i forgot what's your main distro <daviid>i know, i checked on a pureos simulator a long time ago ... <cow_2001>i guess i first should make it work by regular means <daviid>cow_2001: sure, just ask for help in #guix - <daviid>cow_2001: g-golf is in debiuan testing, so you ahould even be able to just intall it on pureos <daviid>debian has 3 pakages - g-golf, g-golf-gtk-4-examples and g-golf-adw-1-examples <cow_2001>master right now is pointing at the same commit as tag v0.8.0-rc-2 <daviid>you're missing something, obviously, the package is in debian ... there is a debian command to make sure the dependencies are installed, i forgot which ... <rlb>apt build-dep g-golf might do it <rlb>Also, offhand, I'd guess it might be: apt install pkgconf <rlb>And of course you'll need guile-3.0-dev too <rlb>(which I bet pulls in pkgconf) <daviid>better run apt build-dep g-golf ... obviousdly <cow_2001>pkg-conf does everything pkgconf does, no? <rlb>I *think* it's the replacement. <mwette>Does anyone have an example of C-implemented procedure that takes keyword args? <rlb>mwette: maybe open-file or scm_spawn_process? <rlb>civodul, wingo: ...not high priority, but one possibly ill-advised idea I was pondering wrt handling "binary" strings (i.e. user/group names, paths, etc.) is to add a new string-ish type that is effectively a string *and* the original locale (that was used when decoding it), making it possible to manipulate it as a string (split, join, ...), *and* to reproduce the original bytes correctly when needed (i.e. to pass back to the OS). <rlb>I think that might also allow for the values to retain maximum "readability" in many/most cases. But it'd perhaps also require us to adopt something like python's "byte smuggling" for any unencodable sequences. <rlb>And it may raise a bunch of related questions we'd have to answer about the relationship to "normal" strings. So really just musing atm... <rlb>(presumably operations like (getpwnam ...) would return that type) <rlb>Oh, and operations like open-file would accept either a normal string, or one of these, and in the former case, you'd get the current "just use the locale" behavior. <rlb>But you have a way to "get it right" if you want to. <mwette>rlb: thanks, needs scm_bind_keyword_arguments