IRC channel logs


back to list of logs

<alextee[m]>i already found myself writing a 4th scheme program, and i have some common procedures i want to abstract away. what's the recommended way to do this? i tried using (include) but that didn't work very well
<alextee[m]> this is what i'm (include) 'ing
<daviid>alextee[m]: you should put those in a separate module - but look if anyone of us won't have done that already, somewhere, so good to ask her as well ...
<daviid>alextee[m]: indeed, everuthing you may dream of in rlation to manipulate filenames and path is i guix already
<alextee[m]>daviid: can i specify a local path for a module when i do #:use-module? i just want something quick-n-dirty to get the job done for now
<alextee[m]>oh nice i'll look at the guix modules when im done
<daviid>alextee[m]: no, but you may use add-to-load-path ... which is one line of code ...
<daviid>alextee[m]: yes look and snarf, you'll learn quite a lot rading guix code ...
<daviid>i think the module is (guix utils), not sure
<alextee[m]>daviid: awesome, thank you!
<alextee[m]>although this is for build scripts for my program so i don't think i should add any external module dependencies that guile doesn't provide
<daviid>why not? why would a series of scrpts not sharing commo functionalitie ...
<daviid>we all do that, all the time, if i may say so ...
<alextee[m]>because if someone wants to build my program, they would need to go and install all the guile libs
<alextee[m]>some distros might not have them
<alextee[m]>also mac (homebrew), windows (mingw)
<alextee[m]>not sure how popular guix utils is though
<daviid>alextee[m]: here look for file*, dir*, lcation* ... for inspiration, and ask here as well ...
<alextee[m]>daviid: thanks!
<daviid>alextee[m]: if you are that serious about your progam, so as to want it to be avilable cross-platform, with the idea many will grb it, yu should first and above all autotool it, then distro will package it
<daviid>but limiting yourself to what guile has is, limiting 'non sense'
<alextee[m]>daviid: it's this btw
<alextee[m]>not a guile program, im just writing some build helper scripts in guile, hence no need for external libs
<daviid>ah, but is it autotooled?
<alextee[m]>daviid: meson'd
<daviid>ok, then you certainly can spit in modules and make those available ... at build or execute time ...
<alextee[m]>there's no easy way to compile stuff with guile-snarf so writing a wrapper for it atm, and i just call my wrapper to compile a .x file from a .c file
<alextee[m]>yep, trying to do that now. not sure how exactly load-from-path is supposed to work though
<alextee[m]>add-to-load-path* sorry
<alextee[m]>if i do "(add-to-load-path (dirname (current-filename)))" before the (define-module) , it can't find "dirname"
*alextee[m] looks around in the guix code
<daviid>alextee[m]: i autotool, we'd write a .in file that needs substitution for thos cases, then the build phase produces a file that knows where to find the modules, either in the build tre, or in the istalled tree ...
<alextee[m]>daviid: the problem is that there's no way to get the cflags of my project to pass that to guile-snarf
<alextee[m]>meson has "dependency" objects among other things and they don't provide that info
<alextee[m]>so i'm doing some hacky things where i call pkg-config --cflags-only-I in the scheme script im writing
<daviid>alextee[m]: why would you need cflags to write a guile scheme modle?
<alextee[m]>i know the pkg-config names from the meson "dependency" objects
<daviid>alextee[m]: anyway, i was willing to help wrt to guile, but i don't know meson
<alextee[m]>daviid: oh i thought you were talking about guile-snarf sorry. so i would do something like (add-to-load-path @PATH_HERE@)?
<alextee[m]>and replace that before calling the script
<rlb>alextee[m]: sometimes I just create a wrapper like this:
<rlb> #!/usr/bin/env bash
<rlb> export GUILE_LOAD_PATH="${GUILE_LOAD_PATH:+$GUILE_LOAD_PATH:}$(pwd)/mod"
<rlb> export LD_LIBRARY_PATH="${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}$(pwd)/lib/.libs"
<rlb> exec guile-3.0 "$@"
<daviid>meson should build the 'user' file fr you
<rlb>and then invoke it like ./foo ... for doing things in the local tree.
<alextee[m]>daviid: yeah i know how to do that. thanks, let me try
<alextee[m]>rlb: this can work too, except i need to replace guile-3.0 with the correct guile binary again lol
<daviid>rlb: yes, but when that is needed, we generally autotool chain it as well, the 'famus' pre-inst-env script that accompanies almost all our projects ...
<rlb>My "wrapper" is autogenerated from a via automake...
<rlb>i.e. exec guile-@GUILE_EFFECTIVE_VERSION@ "$@"
<rlb>that's in the local ./ I have in one project I mean, i.e. in that project ./foo is ./guile ...
<rlb>daviid: ahh, ok, don't know exactly what you mean, but yeah, also have any number of foo-env scripts that are more general...
<alextee[m]>so this is found at /home/alex/Documents/git/zrythm/scripts/guile_utils.scm :
<RhodiumToad>(add-to-load-path (dirname (current-filename))) ;; I did it that way
<alextee[m]>and this is in the same dir :
<alextee[m]>but when i run it i get "no code for module (zrythm guile-utils)"
<rlb>alextee[m]: your dir tree has to match your module path?
<alextee[m]>it.. does?
<rlb>i.e. if the module is (x y z) then it has to be located in x/y/ somewhere in the GUILE_LOAD_PATH.
<rlb>i.e. the "shape" of your GUILE_LOAD_PATH trees has to match the shapes of your module (x y z) paths.
<rlb>trees -> "filesystem trees"
<rlb>so in my wrapper above, I add ./mod to the GUILE_LOAD_PATH, and then all my project specific modules are in there as ./mod/x/y/z.scm, etc.
<alextee[m]>rlb: i made the module a single value, but i still get the same error
<rlb>And the LD_LIBRARY_PATH augmentation is (kind of a hack for now) so I can load ./lib/ via (load-extension "" "init_foo"). Likely a better way than embedding libtools "secret" path, but it works.
<alextee[m]>(define-module my-guile-utils ....) and then #:usemodule (my-guile-utils)
<rlb>If you have a module named (foo), then it'll have to be foo.scm in one of the dirs in GUILE_LOAD_PATH (or just your %load-path really, which picks up GUILE_LOAD_PATH).
<rlb>module names have to be lists.
<rlb>(I think)
<rlb>i.e. (define-module (foo) ...)
<alextee[m]>heh, that worked
<alextee[m]>thanks rlb i thought the module names were arbitrary but apparently they must match the dirs and the filenames (which is good)
<RhodiumToad>how would it know where to look if they did not match?
<RhodiumToad>using LD_LIBRARY_PATH like that is definitely a hack, kill it with fire
<alextee[m]>i dont know, i thought it would scan .scm files in the path or something
<rlb>alextee[m]: yeah, it's similar to python module names, or jvm classes.
<RhodiumToad>scanning everything in the path would be slow
<alextee[m]>indeed, although a lot of software do things like that
<alextee[m]>matching the filesystem is great
<alextee[m]>ok so i successfully snarfed my C code and have the .x files, is there some kind of tool to extract documentation from them (and even better, create HTML from them) ?
<alextee[m]>i basically want to publish this scripting API somewhere
<rlb>I imagine there's a way to at least get texi since I think guile itself does that?
<rlb>Might look in the guile source tree ...procedures.texi rings a vague bell.
<alextee[m]>oh thanks, i found something in module/scripts/doc-snarf.scm
<seepel>Hi guile! I am feeling a bit daft, but for the life of me I can't figure out how to call scheme from c, and can't seem to find it in the manual. I'm trying to figure out how to load and call exported procedures from a a guile module in c.
<alextee[m]>seepel: i hope this can help
<seepel>alextee[m]: Looking at that code it seems to me like this is c code that defines a guile module?
<alextee[m]>yeah, im not sure how to do the other way around yet though, sorry
<rlb>seepel: if these are functions that have c versions, of course call that, if not then you might want scm_call_??? and friends.
<rlb>And you can find the function you want via scm_module_ref, etc.
<rlb>or scm_c_module_ref
<RhodiumToad>there's also scm_c_eval_string to evaluate an arbitrary string
<rlb>ahh scm_c_module_lookup
<seepel>rlb: I'm going to write the modules. Right now I have written a module exporting a single procedure and I wolud like to call that procedure from c
<rlb>so something like scm_call_2 (scm_c_module_lookup (mod, "foo), scm_from_uint32 (4), scm_from_utf8 ("bar")); etc.
<rlb>And you can find mod via scm_c_resolve_module.
<seepel>Sorry, I fell into the classic trap of explaining what I thought the solution was, rather than explaining my actual problem. I'd like to write a bunch of scheme modules and call them from a c a program.
<seepel>I'd basically like to just write a portion of the program in guile scheme. So compile a bunch of modules and link them into my c program. And of course visa versa to expose some of my c program to guile. Though I think I have found the reference documentation for the latter.
<rlb>I think that unless your needs are fairly simple (such that eval is enough), and assuming you don't want to write your some C wrapper(s) on top of your module(s), then scm_call*, scm_apply*, etc., coupled with scm_c_resolve_module and scm_c_module_lookup might be plausible.
<rlb>Though of course you might well want to cache the resolves and lookups in static SCM vars or something, i.e. only look them up at startup.
<rlb>(or a struct, or whatever)
<seepel>What would writing C wrappers on top of my modules entail?
<rlb>Well if it's C calling scheme, then I'd guess it might mostly be a wrapper hiding the above bits.
<seepel>Got it.
<rlb>i.e. you'd have a some_thing() that internally knew how to find the right SCMs to pass to scm_call, scm_apply, etc.
<seepel>What section of the manual am I looking for to find the details of those bits?
<seepel>Yeah I found fly evaluation and I was thinking, what I'm looking for must be around here somewhere, just couldn't find it for some reason. Thank you!
<rlb>happy to help
<alextee[m]>how can I use doc-snarf.scm? it seems nothing happens when i run it
<rlb>(and of course you'l need the scm_list... related bits for apply and/or any calls with more than 9 args)
<alextee[m]>am i supposed to compile guile to produce a usable version?
<rlb>alextee[m]: noidea -- though I'd guess that if it has a "main" you might need to call that with (program-arguments) or whatever args you want.
<rlb>i.e. the module may not do anything if you just load it.
<rlb>not like python with say __main__...
<alextee[m]>oh found info in the README
<rlb>And looks like there are some docs at the top of the module too.
<alextee[m]>yeah it looks like it does exactly what i want, just need to build it somehow. building guile now
<rlb>alextee[m]: note that building guile from source will take a *lot* longer than from the release archives fwiw (because you won't have the bootstrap files).
<rlb>Where that just means 30-60m on say amd64.
<alextee[m]>how long are we talking? my pc is pretty fast but if we're talking > 5 minutes i'll bail
<alextee[m]>oh god
<rlb>But you'll only have to do that once...
<rlb>well hmm, I wonder if "make clean" clobbers them...
<rlb>I think it's supposed to be a lot faster from the archives, but I'm always building from source.
<alextee[m]>meanwhile i'll try using the module from scheme code as it suggests in the readme
<rlb>sample build times:
<rlb>And of course a tiny machine takes (a *lot*) longer:
<alextee[m]>i see
<alextee[m]>well, ice-9/eval.go is done
<rlb>well they're not all physically tiny I suppose, and there are some fairly small faster systems, but I imagine you know what I mean :)
<alextee[m]>i managed to run it in the guile REPL
<alextee[m]>(use-modules (scripts doc-snarf)) (doc-snarf)
<alextee[m]>didn't work, but i found this:
<alextee[m]>although when i run that it says guild: unknown script "c2doc"
<spk121>alextee: "guild doc-snarf -l c weak-vector.c -o output.txt"
<spk121>replace weak-vector.c with your source file
<alextee[m]>spk121: i did, i get nothing
<spk121>most of the stuff on concerns TTN's unique fork of Guile. He's keeping guile 1.4 alive for his own applications
<spk121>and you have SCM_DEFINE macros in your source file?
<alextee[m]>ah i see, so i guess c2doc is an older version that was merged into doc-snarf
<alextee[m]>i have an SCM_DEFINE at line 41 but it gets ignored
<spk121>lemme try
<alextee[m]>i even ran it on this;a=blob;f=libguile/alist.h;h=7bc86be9f62ffd47a453ae63701eb3e61bec0f27;hb=HEAD
<alextee[m]>and i still get no output
<spk121>what about 'guile-snarf position.c -I /path/to/includes'
<alextee[m]>that makes a 80k line .x file
<spk121>wait, nevermind, that's for making .x files
<spk121>sorry, it has been awhile
<alextee[m]>np thanks for your help :)
<alextee[m]>fwiw doc-snarf works on scheme files, but haven't successfully ran it on any C file yet
<str1ngs>hello daviid. did you get my report about 'gdk-display-get-default ?
<daviid>str1ngs: hello
<daviid>no, wa it per email?
<str1ngs>daviid I left a sneek massage.
<daviid>str1ngs: fwiw, I won't be able to look at it before I finish what I'm doing now, which is related to this boostrap binding 'problem ...
<daviid>str1ngs: not sure what/why you are trying to 'mess-u' with so low level stuff .. :), reaaaaalllly dangerous you know? :)
<str1ngs>daviid: mainly a user report that 'gdk-display-get-default does not work on wayland. for X11 I can import (gi-import "GdkX11") but I'm not sure what to import for wayland. or I'm kinding wondering if I sould need to import these backends at all?
<str1ngs>daviid mess-u? I don't understand
<daviid>I don't know enough about backends to properly answer, but depending on the distro, the backend is now wayland for most of them
<daviid>which is the case for deban, and gdk-display-get-default indeed returns #f (the %null-pointer)
<str1ngs>daviid: right but <gdk-wayland-display> is not found.
<daviid>you'd have to ask the gnome team about this I guess
<daviid>there is no such calss
<str1ngs>daviid: if you use X11 you can import (gi-import "GdkX11")
<str1ngs>but from my use of GTK. importing (gi-import "GdkX11") seems wrong.
<daviid>you prob are on a wayland bacjend
<daviid>but again, what is the final aim of all this?
<str1ngs>the end user uses wayland. and reports that <gdk-wayland-display> is not found.
<daviid>can't gtk provide the ifo the user is looking for?
<str1ngs>I use X11
<daviid>that class does not exists
<str1ngs>in C all you do is use C. you need to specify any backends
<daviid>not sure what they're up to
<str1ngs>what modules does the class exist in to import?
<daviid>str1ngs: i don't understand the question
<daviid>you import namespaces, not module
<str1ngs>what namespace
<daviid>those you want to 'play with' using g-golf :), Gtk, Clutter ...
<daviid>webkit ...
<str1ngs>daviid why most we do this song and dance before you will accept my bug reports.
<str1ngs>'gdk-display-get-default does not work right. IMHO even with the X11 backend.
<str1ngs>and this is not low level. if you want to use clipboard events. I'm not even sure why you would say that.
<str1ngs>it's not working properly.
<daviid>ok, but i can't look at it right no, and didn't get the example to reproduce - not sure why, sneek might be asleep ...
<daviid>gdk is by definiftion, very low stuff
<str1ngs>I send the REPL example via sneek
<daviid>str1ngs: didn't see it
<str1ngs>just import Gdk Gtk gtk_init and then call. (gdk-display-get-default)
<daviid>please paste here again, but again won't look at it right now ...
<str1ngs>this doesnt need an example. just call the functions. easy peasy
<daviid>str1ngs: better, please paste again, asking for a full backtrace
<daviid>,bt #:full? #t
<daviid>str1ngs: then will look into this asap, but not exactly right now, I must finalize what I'm workig on ...
<str1ngs>daviid: no worries
<daviid>,bt #:full? #t #:width 1000
<str1ngs>I can't ,bt right now. I had to switch to wayland to run that REPL code. and I saved the log.
<str1ngs>and I can't switch to wayland right now
<daviid>np, i can't work on it now ... whenever you can ...
<daviid>I'm fighting other g-golf ghosts ... there ar still many ...
<str1ngs>daviid if you use wayland just run the REPL and ,bt. if you can't work on it now that's fine.
<str1ngs>actually the I'll get the end user to ,bt
<daviid>,bt #:full? #t #:width 1000
<daviid>not just ,bt
<guix-vits>str1ngs: the backtrace.
<guix-vits>Hi there.
<str1ngs>guix-vits: thank you
<daviid>ok, thnaks both, will look asap
<str1ngs>no thank you :)
<daviid>fighting a big gohst, wonder if I should call harry potter at rescue :):)
<guix-vits>daviid: better take a Hermione :P
<guix-vits>*no 'a' before names
<str1ngs>anything I can help with daviid?
<daviid>str1ngs: no thanks
<str1ngs>okay, good luck :)
<daviid>str1ngs: i just pushed a patch, a code review/enhancement patch, which shouldn't change things on your side, but if (when you pull/make) ... let me know
<str1ngs>daviid: thanks, will check this out soon.
<str1ngs>daviid (gi-import "Gio") now throws ERROR: In procedure scm-error:
<str1ngs>No variable named <g-type-module> in #<directory (g-golf hl-api gobject) 7f04eeee1e60>
<daviid>str1ngs: ok, tx, will check
<str1ngs>daviid: offtopic, what video driver do you use with bullseye?
<daviid>str1ngs: pushed a fix wrt Gio importing bug above
<daviid>wrt video, not sure, what ever xserver-xorg picks up to manage my intel integrated graphic card of the relatively old laptop I'm using
<str1ngs>daviid will pull and test.
<str1ngs>daviid: looks good. though I need to port the old gdk key events to the new ones.
<daviid>str1ngs: ok, that's quite easy, just need to rename
<daviid>str1ngs: here, the gdk-event example -
<str1ngs>(!state event) should work right?
<str1ngs>daviid ^
***rekado_ is now known as rekado
<str1ngs>strange (!state event) won't work with my 'key-press-event works with your example.
<daviid>hat is strang
<daviid>that is strange
<RhodiumToad>sneek, later tell manumanumanu did you not mention me to oleg, or did he ignore that?
<str1ngs>daviid: it's working. I just think my imports are not right. so looks good to me.
<str1ngs>daviid this is more like my use case . this examples works so I think it's just a import issue.
<str1ngs>aha! WARNING: (g-golf): `!state' imported from both (g-golf gdk events) and (g-golf hl-api gobject)
<str1ngs>even when I don't import Gdk I get. No applicable method for #<<accessor> !state (2)> in call (!state #<<gdk-event> 7f3048a267c0>)
<daviid>i'm away from the kb, bb a bit later
<str1ngs>pretty confident it's a import issue not a g-golf issue. I'll figure it out.
<daviid>str1ngs: i thin it is an import g-golf issue
<str1ngs>wigh g-golf or my imports?
<daviid>g-golf i think
<daviid>be right back
<daviid>half an hour or so
<str1ngs>daviid: these are my imports for this module.
<str1ngs>if it helps
<daviid>str1ngs: i can't reproduce the problem here, but my .gule file has a (use-modules (oop goops) (default-duplicate...) call
<daviid>str1ngs: can you add the (use-modules (oop goops) in the eval-when clause, before to call default-duplicate-binding-handler, then also add (use-modules (g-golf)), just before the (gi-import "Gdk") call and see
<daviid>like this
<str1ngs>daviid: no luck. I's probably another module I'm using
<str1ngs>the trivial examples work fine
<daviid>if you can work on an example that reproduce, i still think it is a g-golf problem ... maybe ...
<str1ngs>I'll try and bisect the modules. it's not as trivial as these examples.
<str1ngs>I've pasted so much to I'm getting do not spam lol
<guix-vits>str1ngs: time to use the CentOs paste until then.
<guix-vits>24hr-keep-only afaik
<alextee[m]>so is doc-snarf supposed to be working for C files? it seems to work for scheme but not for C (i get empty output when I run it on C files containing SCM_DEFINE)
<alextee[m]>well, i guess ill write my own parser lol
<alextee[m]>using libguile/guile-snarf-docs extracts the strings correctly, while doc-snarf doesnt. weird. i reported a bug
<alextee[m]>this was very helpful fwiw
***jao is now known as Guest90002
<brendyyn>How can I translate Python int(binascii.hexlify(x),16) into guile?
<alextee[m]>fedora only has 2.0, even rawhide! jesus
<alextee[m]>oh it's listed as guile22
<guix-vits>alextee[m]: do you use a ?
<alextee[m]>guix-vits: i was searching through this but i was told it's broken, so i guess i'll look at src. from now on
<mwette>alextee[m]: Does your Fedora have /usr/bin/guild2.2? It's missing on my Fedora-31 install, and that has caused problems for me using guile.m4. Ubuntu has /usr/bin/guile-2.2 but not /usr/bin/guild-2.2.
<mwette>alextee[m]: Ah, "dnf install guile-devel" adds it.
<mwette>But "apt install guile-2.2-dev" on Ubuntu does not.
<guix-vits>mwette, alextee[m]: afaik, `dnf` has 'search --provides' or smth alike (if you know what file name is, though).
<mwette>guix-vits: thanks -- this works: dnf provides /usr/bin/guild2.2
<alextee[m]>mwette: will try soon, it's in a CI. but it looks like the specfile does provide a guild{version}
<alextee[m]>oh yeah it's in -devel
<alextee[m]>how can i pass a list to (system* )?
<mwette>lol. On ubuntu the apt man page says "if you are looking for a particular file, try apt-file(1), but apt-file does not exist.
<alextee[m]>im not sure what the difference between `(list x y z)` and `arg1 arg2 arg3...` is
<guix-vits>mwette: and to know which package provides apt-file ... :)
<mwette>alextee[m]: apply: (system a b c) == (apply system (list a b c))
<mwette>guix-vits: "dnf install apt-file" got it
<mwette>guix-vits: oops, "apt install apt-file"
<guix-vits>mwette: it should be updated before use, or it's automatic now?
<alextee[m]>mwette: nice! thanks
<mwette>guix-vits: I got error message "need to update"
<guix-vits>mwette: see the link above, then (debian wiki :)
<mwette>guix-vits: thanks!
<mwette>alextee[m]: and == (apply system a (list b c))
<mwette>though there are small performance hits for using apply: lists must be constructed and de-constructed
<spk121>wingo: I see you've poked a bit at guile-cairo. Do you have future plans for the API?
<alextee[m]>i see
<tohoyn>should GOOPS-style object system be standardized in RnRS?
<alextee[m]>what's the easiest way to read the contents of a file into a string?
<alextee[m]>getting confused with all the port-related procedures
<alextee[m]>i read that racket has file->string
<tohoyn>alextee: use read-char and test when it returns EOF
<alextee[m]>is there no built in way to do that? tohoyn
<alextee[m]>looks like a common thing to do
<tohoyn>alextee: guile has get-string-all
<alextee[m]>oh there it is, thanks
<rotty>tohoyn: given that even R6RS was consider too large of a standard by many, I don't think adding something like goops would be too welcome
<rotty>(that's just my personal impression, of course)
<str1ngs>spk121: did my patch help with guile-gi?
***nckx is now known as SecondChoiceNick
***SecondChoiceNick is now known as nckx
<alextee[m]>has anyone got success with using libguile in mingw?
<alextee[m]>there seems to be a guile-devel package but not a mingw-w64-x86_64-libguile-devel
<alextee[m]>so it doesn't get picked up by pkg-config when configuring
<str1ngs>alextee[m]: does the guile package not have the pc file?
<str1ngs>alextee[m] maybe there is a mingw-w64-x86_64-guile ?
<alextee[m]>i only found guile and libguile-devel
<manumanumanu>RhodiumToad: I told him you found the bug and linked to my patch in the guile mailing list
<sneek>manumanumanu, you have 1 message!
<sneek>manumanumanu, RhodiumToad says: did you not mention me to oleg, or did he ignore that?
<manumanumanu>I did not mention the issue in the mailing list, but since he said he hadn't migrated it from CVS (which became unsupported some time ago), I doubt he is doing much as a maintainer with regards to ssax
<str1ngs>alextee[m]: does msys compiler work?
<alextee[m]>not sure what the msys compiler is supposed to be. i always build just by running meson build && ninja -C build, and the libraries are from mingw-w64-x86_64-* packages
<alextee[m]>and it just works (tm)
<alextee[m]>maybe i should build guile from source instead of using the packages
<alextee[m]>which links to this "long standing issue with the guile package itself"
<manumanumanu>does guile do any funciton special optimizations? Like turn a (remainder n 128) into (logand n 127)?
<manumanumanu>(which doesn't work for negative numbers, but you get what I mean)
<spk121>str1ngs: we're going to definitely need something like that patch. right now we're still pondering how interacting with cairo should work. have to go from guile-cairo smob to pointer to GOOPS subclass of <GBoxed> and back again
<wingo>spk121: hey :) regarding guile-cairo i have no plans. i use it in the software i have to render presentations and i hacked on it recently to attempt to render to svg. ended up not being the right thing for what i was looking for
<spk121>str1ngs: it would not surprise me if, at some point, someone will want to modernize guile-cairo and move from smobs to foreign objects and move from installing in 'lib' to installing in 'guileextensiondir'
<str1ngs>spk121: in guile-gi for the draw event. what does the callback signature look like. for g-golf it's signature is GtkWidget scm pointer. so this patch translates well.
<wingo>spk121: do you have any plans?
<spk121>wingo: need to connect guile-gi to guile-cairo, somehow. right now guile-cairo smob to pointer to guile-gi GOOPS <CairoContext> or whatever
<str1ngs>wingo: hello, I want to propose this patch for guile-cairo. this helps with using guile-cairo with g-golf.
<str1ngs>spk121: smobs to foreign pointer might be a good start.
<wingo>str1ngs: is there a reason you can't use the ffi for that?
<wingo>i.e. call those C functions using the ffi
<spk121>wingo: maybe I'll branch a foreign objects of guile-cairo to see how it feels
<wingo>spk121: that would be interesting!
<wingo>see if foreign objects are any good :P i don't know of any experience reports with them...
<str1ngs>wingo: I think with ffi it would not be easy to do scm_from_cairo. which is need for calling guile-cairo functions. g-golf's cairo_to is a foreign pointer. so this just converts from that.
<str1ngs>if though spk121 is going to do some work port from smobs to foreign this patch might not be needed.
<mwette>str1ngs: hmm ... seems doable offhand
<wingo>str1ngs: pretty sure you can just wrap scm_to_cairo using pointer->procedure, argument of type '* and return type 'scm
<wingo>or how does that work...
<wingo>no it returns '* and then you call pointer->scm on the result
<str1ngs>I don't think scm_to_cairo is exposed but I can try with that.
<wingo>you should be able to get it via dynamic-func from the cairo object
<str1ngs>when I revisit g-golf and cairo I'll try with FFI. I was tring to keep things mostly in scheme. since GI uses it's own FFI in away.
<str1ngs>it's FFI is a little safer IMHO
<wingo>i get what you are saying but ultimately guile-cairo has two stable APIs: one for Scheme and one for C. you want the C one. you can call it from scheme using the FFI. adding scm_cairo_pointer_to_scm doesn't add any safety, because you are already starting with a foreign pointer, so you are already doing FFI things
<wingo>best to call the C API from Scheme using the FFI, IMO
<wingo>or rather, adding cairo-pointer->scm doesn't add safety, is what i mean to say
<wingo>scheme API that takes foreign pointers
<str1ngs>I will see if I can do this with FFI. for my use cases I ended up using instead. but there are other cause I'll need cairo eventually. if spk121 does some work with foreign pointers it might note be needed after all.
<schaeffer>hello! this might be a silly question but how do i use the ioctl syscall in guile? seems like it's not available
<wingo>schaeffer: indeed not available directly. ideally someone should make a package for guile like luajit's ljsyscall. guix has an ioctl wrapper built using the ffi fwiw
<wingo>see guix/build/syscalls.scm
<mwette>While people are on the topic of ffi, does anyone know why libffi is included in the gcc source distribution? Is libffi used by gcc somehow?
<schaeffer>wingo: interesting. maybe another reason for me to finally try guix
<schaeffer>not that i know where to start really...i don't want to trash my main box by doing something wrong
<wingo>well it's just a function to extract from its source and use it
<wingo>i don't know that installing guix makes it more accessible
<wingo>i love guix but this is not a reason to install it :)
<str1ngs>sneek: late tell daviid. seems I can avoid No applicable method for #<<accessor> !state (2)> in call (!state #<<gdk-event> 7f6f67e1bd40>) if I don't compile the module I'm using !state in. does that give any indicator as to why it cant' find the method to you?
<sneek>daviid., str1ngs says: seems I can avoid No applicable method for #<<accessor> !state (2)> in call (!state #<<gdk-event> 7f6f67e1bd40>) if I don't compile the module I'm using !state in. does that give any indicator as to why it cant' find the method to you?
<str1ngs>sneek: later tell daviid. seems I can avoid No applicable method for #<<accessor> !state (2)> in call (!state #<<gdk-event> 7f6f67e1bd40>) if I don't compile the module I'm using !state in. does that give any indicator as to why it cant' find the method to you?
<sneek>Got it.
<alextee[m]> is line 78 the correct way to do `cat myfile.doc | guild snarf-check-and-output-texi > myfile.texi` ?
<alextee[m]>i should probably do this in a shell file and read the results instead
<spk121>wingo: guile-cairo with foreign objects :
<spk121>str1ngs: ^
<spk121>need to update docs, test, etc, but that's the basic outline of it all
<spk121>from here, you can (slot-ref some-cairo-var 'ptr) to get the pointer
<str1ngs>with g-golf I need to go from scm pointer to a guile cairo type. is that feasible?
<str1ngs>spk121: as long as scm_to_cairo is exposed the this should work. I might have to use ffi as wingo mentioned.
<spk121>str1ngs: with regular guile-cairo, or the dirty hack I just did. With regular guile-cairo, you gotta ffi the scm_to_cairo. With the dirty hack, you'd load GOOPS then (define x (make <cairo>)) (slot-set! x 'ptr #x12341234))
<str1ngs>spk121: great that works thank you.
<str1ngs>spk121: out of curiosity how does guile-gi handle closures with cairo_t * arguements?
<spk121>str1ngs: if someone has loaded Gtk or such, it will start loading dependent typelibs, including cairo-1.0.typelib. Now cairo-1.0.typelib is not actually libcairo, but,, which only has GTypes for cairo types, but, no functions or anything like that
<spk121>so we end up with GType GBoxed like <CairoContext> and such, but, no way to use them or look into them
<str1ngs>gotcha I think GObject does some bootstrapping for cairo GTypes hence the need for
<str1ngs>it's kinda a chicken and egg scenario IIRC
<spk121>seems like it
<str1ngs>spk121: 'ptr have an init-keyword. so I could do this maybe. (make <cairo> #:ptr ctx) ?
<spk121>str1ngs: that seems to work. (I've only done like 10 minutes of testing, haha)
<str1ngs>nice good work :)
<str1ngs>spk121: does this look right to you?
<str1ngs>ctx is #<<class> <foreign> 7fe79a61ce10>
<str1ngs>I get Wrong type (expecting exact integer): #<pointer 0x7fe798155450>. I think I'm doing this wrong
<spk121>str1ngs: foreign object's slots are always just raw integers, I think, so
<spk121>dereference-pointer is probably needed
<spk121>(dereference-pointer (scm->pointer obj))
<str1ngs>(make <cairo> #:ptr (pointer-address ctx)) works
<str1ngs>spk121: LGMT! :)
<spk121>str1ngs: note that I haven't thought at all about how GC works here.
<str1ngs>I thought of that as well.
<str1ngs>(make <cairo> #:ptr (pointer-address ctx)) works. as long as that doesn't change. I can look more into this later. I'm not useing much cairo. but I have some C code I can try porting when I have more time.