<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 <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]>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 <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]>not a guile program, im just writing some build helper scripts in guile, hence no need for external libs <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]>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@)? <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 guile.in via automake... <rlb>i.e. exec guile-@GUILE_EFFECTIVE_VERSION@ "$@" <rlb>that's in the local ./guile.in 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... <RhodiumToad>(add-to-load-path (dirname (current-filename))) ;; I did it that way <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? <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/libfoo.so via (load-extension "libfoo.so" "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.e. (define-module (foo) ...) <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. <alextee[m]>indeed, although a lot of software do things like that <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. <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. <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. <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! <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__... <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 <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>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]>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 <spk121>most of the stuff on gnuvola.org 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>what about 'guile-snarf position.c -I /path/to/includes' <spk121>wait, nevermind, that's for making .x files <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: 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? <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 <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>in C all you do is use C. you need to specify any backends <str1ngs>what modules does the class exist in to import? <daviid>str1ngs: i don't understand the question <daviid>you import namespaces, not module <daviid>those you want to 'play with' using g-golf :), Gtk, Clutter ... <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. <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>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>str1ngs: then will look into this asap, but not exactly right now, I must finalize what I'm workig on ... <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>fighting a big gohst, wonder if I should call harry potter at rescue :):) <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> <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: 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 ***rekado_ is now known as rekado
<str1ngs>strange (!state event) won't work with my 'key-press-event works with your example. <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>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 <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 <str1ngs>daviid: no luck. I's probably another module I'm using <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. <guix-vits>str1ngs: time to use the CentOs paste until then. <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]>using libguile/guile-snarf-docs extracts the strings correctly, while doc-snarf doesnt. weird. i reported a bug ***jao is now known as Guest90002
<brendyyn>How can I translate Python int(binascii.hexlify(x),16) into guile? <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} <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? <mwette>guix-vits: I got error message "need to update" <guix-vits>mwette: see the link above, then (debian wiki :) <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? <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 <tohoyn>alextee: use read-char and test when it returns EOF <tohoyn>alextee: guile has get-string-all <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 ? <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]>maybe i should build guile from source instead of using the packages <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>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>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. <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 libgv_guile.so 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 <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? <alextee[m]>i should probably do this in a shell file and read the results instead <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: 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, libcairo-gobject.so, 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 libcairo-gobject.so. <str1ngs>it's kinda a chicken and egg scenario IIRC <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>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 <spk121>str1ngs: note that I haven't thought at all about how GC works here. <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.