IRC channel logs

<apteryx>strange: [1754959.048188] traps: guile[30343] general protection fault ip:7ffff7947500 sp:7fffffffe5f0 error:0 in libc.so.6[7ffff7947000+167000]

<Aurora_v_kosmose>Odd, Guile's dbus libs seem not to be packaged in Guix?

<Aurora_v_kosmose>...nvm, it seems that the search really insisted on that d-bus dash.

<Keele>In G-Golf, how can I use "defines" from gtk? I'd like to compare keyvals against constants such as GDK_KEY_Escape from gdk/gdkkeysyms.h

<RhodiumToad>can you just import them by name?

<RhodiumToad>ACTION guessing

<Keele>by import you mean gi-import-by-name?

<Keele>I've tried a lot of variations, but I can't figure out if something would work.

<Keele>hmmm I haven't tried a C-style import

<Keele>is that possible in Guile?

<RhodiumToad>ACTION finds a way

<RhodiumToad>not sure yet if it's a good way

<RhodiumToad>(gi-import-constant (g-irepository-find-by-name "Gdk" "KEY_Escape")) ;; seems to do what you want

<RhodiumToad>but also, there's a function to get the name of a keyval, which might be more use

<Keele>your first proposal works! but I don't know why, I need some time to understand everything :D

<RhodiumToad>so basically g-golf is built on top of the gobject-inspection mechanism

<RhodiumToad>g-irepository-find-by-name is a gobject-inspection function to find an entry in some API's namespace

<Keele>wow thanks a lot!

<Keele>this is what I cooked up thusfar:

<Keele>(gi-import-function (g-irepository-find-by-name "Gdk" "keyval_from_name"))

<Keele>(define KEY_Escape (gdk-keyval-from-name "Escape"))

<RhodiumToad>that looks kind of backwards :-)

<RhodiumToad>there ought to be a way to get a list of all the KEY_* constants from GI, looking

<Keele>that would be perfect

<Keele>fwiw the documentation of G-Golf says about gi-import-constant "Constants are curently not being automatically imported, though this will probably change in the near future, stay tuned."

<Keele>RhodiumToad: you helped me tremendously! I was already about to give up and hard-code the key values. Now I need to effectively declare every key I want to use, but it's something I can live with.

<RhodiumToad>to iterate, use (g-irepository-get-n-infos "Gdk") to get the number of entries then (g-irepository-get-info "Gdk" i) to get each entry

<RhodiumToad>g-base-info-get-name and g-base-info-get-type can be used to filter the entries for constants starting "KEY_"

<RhodiumToad>the entry from g-irepository-get-info can then be passed to gi-import-constant

<RhodiumToad>in particular this seems to work: https://dpaste.org/kn6np

<Keele>works perfectly!

<Keele>thanks a lot, I need some time to read documentation and digest all the new info

<daviid>RhodiumToad: thanks for helping Keele wrt g-golf ... i think you would prefer, in your snipset, to prefix the constant name using the namespace (by convention, a GIBaseInfo store those names w/t their respective namespace prefix), and you might also pass those to g-name->name, so you'd get. i.e., gdk-key-z instead of KEY_z

<RhodiumToad>in the specific case of KEY_*, I think it actually makes more sense not to

<RhodiumToad>those names are not really from gdk but rather imported from X11

<daviid>RhodiumToad: i think i will provide a gi-import-constants namespace filter &opt versiob ... i'll think about it

<daviid>RhodiumToad: that 'does not matter', so to speak, the important thing is to be consistent, imo, so from a user pov, those are GDK_* constants, whichj in g-golf translate to gdk-* ... only methods receives shorter name [if that option is selected by the user]

<daviid>but no big deal, users may do as they wish - however if i provide an constants importer using a filter predictae, i'll import those following the naming convention ... anyway, thanks again

<RhodiumToad>no problem, at least I wasn't missing something obvious

<haugh>I've got a macro that's supposed to rewrite some of its arguments (all but the first, for example) as the FORMALS of a `lambda*` invocation. Passing a dot as in (macro foo bar . bazzes) throws "no matching pattern." `#:rest` is a workaround, but I want to understand what's going on.

<RhodiumToad>in that case, "bazzes" will be a list

<Keele>daviid: gdk-key-escape etc would be very nice! :)

<RhodiumToad>if you just pass it to another macro like lambda*, it won't behave as you expect; you'll likely have to explicitly splice it with #` #,(

<RhodiumToad>do you have a need to use . bazzes rather than baz ... ?

<RhodiumToad>i.e. do you need to accept the case of an improper list

<RhodiumToad>hm, nope, I was wrong

<RhodiumToad>no need for #` etc.

<haugh>Oh I see, the dot notation changes the list structure which is parsed by the syntax pattern matcher

<haugh>heck

<RhodiumToad>it all seems to work as expected for me, can you give a simple example of what you tried?

<haugh>(define-syntax-rule (macro a b c ...) (lambda* (b c ...) #f))

<haugh>(macro #f foo . bazzes)

<RhodiumToad>ah right

<RhodiumToad>the use of c ... restricts it to matching a proper list, and . bazzes makes an improper list

<haugh>OH

<RhodiumToad>(define-syntax-rule (macro a b . rest) (lambda* (b c . rest) #f))

<RhodiumToad>oops

<RhodiumToad>(define-syntax-rule (macro a b . rest) (lambda* (b . rest) #f))

<haugh>I get it, thanks

<RhodiumToad>the version with . rest should match either a proper or improper list, since proper lists are just the special case where the last cdr is '()

<apteryx>is there support for renameat2 in Guile?

<RhodiumToad>I don't see it in configure for 3.0.9, only renameat

<apteryx>it has support to atomically swap two files, RENAME_EXCHANGE

<apteryx>(via the new RENAME_EXCHANGE flag)

IRC channel logs

2023-05-16.log