foreign objects and the garbage collector
I was looking at writing something to interact with gpsd. There is a shared memory interface, and a Unix socket interface. The protocol spoken by gpsd is JSON, so I figured that I would just open up a socket and start talking ... however ... really early on in the man page, it says "it is a bad idea for clients to speak the protocol directly" ( https://gpsd.gitlab.io/gpsd/gpsd_json.html) presumably since the protocol was likely to change? They didn't elaborate ... There is a C interface described at (https://gpsd.gitlab.io/gpsd/libgps.html), which has the familiar "open-and-get-opaque-thing" and "close-opaque-thing-when-done" design. I'd rather not compile anything in C, and just use the tools in Guile to interact with libgps. Is there a way to get Guile's garbage collector to call "gps_close" on the opaque structure returned by "gps_open"? Or is this something that would be more handily implemented in a C extension? Right now, because I'm just not concerned about sloppiness, I've just been speaking the wire protocol, but I do feel bad about being sloppy and wanted to clean it up for others to use perhaps.
Re: foreign objects and the garbage collector
Hello, Le samedi 04 septembre 2021 à 07:41 -0500, Tim Meehan a écrit : > I'd rather not compile anything in C, and just use the tools in Guile to > interact with libgps. Is there a way to get Guile's garbage collector to > call "gps_close" on the opaque structure returned by "gps_open"? I think it would be best to do it yourself. Maybe the garbage collector will not run immediately (if at all), and if each creation uses "precious" resources (such as file descriptors), you might run into a shortage before the garbage collector is triggered. This is not considered by people writing the C API of course, because they assume you would close the thing as soon as possible. (Also, if calling the close function is mandatory, for instance to run code that’s not just freeing resources, and the garbage collector does not have a chance to run, then it’s another problem. However, I doubt your library does something like that). If you want to avoid the problem, you should explicitely bind and call the gps-close function and not rely on the garbage collector to do it for you. You can use dynamic-wind to open and close resources as needed. That being said, make-pointer (from (system foreign-library)) is probably what you are expecting. It should work with gps_close. Best regards, Vivien
macro syntax-error works in prefix but not curly-infix
hi,
i have this macro:
(define-syntax <+
(syntax-rules ()
((_ var expr) (define var expr))
((_ err ...) (syntax-error "Bad <- form")) ;; does not work in infix !
))
why my syntax-error pattern never reach in infix:
scheme@(guile-user)> {x <+ 7 8}
While compiling expression:
Syntax error:
unknown file:3:3: source expression failed to match any pattern in form <+
but ok in prefix:
scheme@(guile-user)> (<+ x 9 10)
While compiling expression:
Syntax error:
unknown location: <+: Bad <- form in form (<+ x 9 10)
why?
Regards,
Damien
Re: foreign objects and the garbage collector
Thanks Vivien, I had not considered dynamic-wind. I'll look into that a bit more. Cheers, Tim On Sat, Sep 4, 2021 at 8:35 AM Vivien Kraus wrote: > Hello, > > Le samedi 04 septembre 2021 à 07:41 -0500, Tim Meehan a écrit : > > I'd rather not compile anything in C, and just use the tools in Guile to > > interact with libgps. Is there a way to get Guile's garbage collector to > > call "gps_close" on the opaque structure returned by "gps_open"? > I think it would be best to do it yourself. Maybe the garbage collector > will not run immediately (if at all), and if each creation uses "precious" > resources (such as file descriptors), you might run > into a shortage before the garbage collector is triggered. This is not > considered by people writing the C API of course, because they assume you > would close the thing as soon as possible. (Also, if > calling the close function is mandatory, for instance to run code that’s > not just freeing resources, and the garbage collector does not have a > chance to run, then it’s another problem. However, I > doubt your library does something like that). > > If you want to avoid the problem, you should explicitely bind and call the > gps-close function and not rely on the garbage collector to do it for you. > You can use dynamic-wind to open and close > resources as needed. > > That being said, make-pointer (from (system foreign-library)) is probably > what you are expecting. It should work with gps_close. > > Best regards, > > Vivien > >
Difficulty integrating with Swift/Objective-C
Good day,
I have an existing app which is written in Swift and runs on macOS
10.15. I would like to provide users a way of customising the app
(initially just simple things like modifying keybindings for
example, later hopefully more) and as a keen Emacs user, i'm
inspired by the idea of providing a Schemey/Lispy interface for
such extensions. Guile looks like it'd be great for this. If i
understand correctly, it'd be best if i could bundle the Guile
runtime as a static library with the app, and call out to it to
evaluate user-provided code. I haven't thought deeply about this
interface yet; i thought i'd get a proof-of-concept working first.
I wonder if i might humbly ask for some guidance on how to get it
working, because after a couple of days i seem to have failed.
I'm no C/threads/low-level guru, so my apologies if i'm doing
something very dumb.
I had some difficulty getting my app to compile against Guile, but
i eventually managed to link against a version of Guile installed
with Homebrew (guile: stable 3.0.7 (bottled)), however when trying
to boot it up i seemed to run into the same issue described by
Jeffrey Walton [1]. My app would boot, and as soon as it hit the
Guile initialisation calls, it would error with "allocating JIT
code buffer failed: Permission denied, jit.c:5804: fatal:
assertion failed". While that person seems to imply the problem
is with Apple's M1 silicon, i'm actually running an older machine
(2.9 GHz Dual-Core Intel Core i5, macOS 11.5.2). I then managed
to get further by downloading the Guile release tarball version
3.0.7 and and building with `./configure --enable-jit=no`; this
got me a bit further, however it still didn't work: i think it is
because some assumption Guile has about the thread it runs on, or
when it's invoked, is violated.. but i'm unsure how to find out.
What i currently have, is this snippet. It's being called from
Swift land, in the `applicationDidFinishLaunching(_ aNotification:
Notification)` function. As far as i can tell, that _is_ the main
thread.
```
#include "libguile.h"
static void* register_functions (void* data)
{
SCM test = scm_c_eval_string("(+ 3 5)");
int foo = scm_to_int(test);
printf("foo = %d\n", foo);
return NULL;
}
void run_guile() {
printf("hello from C, before Guile\n");
scm_init_guile();
//scm_with_guile(®ister_functions, NULL); // i've tried
only having this line uncommented, too, but that also causes
immediate crashes
//scm_shell(0, NULL);
}
```
This compiles fine, and i see the "hello from C" line printed, but
then it crashes. The error seems to vary, here are some i've
seen:
1. "Thread 1: EXC_BAD_ACCESS (code=1, address=0x0)" at line 182 of
pairs.h,
2. "Pre-boot error; key: misc-error, args: ("%search-path" "path
is not a proper list: ~a" (("/usr/local/share/guile/3.0"
"/usr/local/share/guile/site/3.0" "/usr/local/share/guile/site"
. #)) #f)", "Thread 1: signal
SIGABRT", line 260 of throw.c
3. "Thread 1: EXC_BAD_ACCESS (code=1, address=0x9)", at line 585
of weak-set.c.
4. I've also sometimes seen this one,
https://lists.gnu.org/archive/html/emacs-bug-tracker/2020-01/msg00365.html,
although perhaps that's indeed related to closed stdout.
Because these errors are different all the time i guess it's some
race condition or threading issue? I wonder if someone knows an
avenue i can attempt to use to debug what's going on? 🙏
All the best,
paul
1. https://mail.gnu.org/archive/html/bug-guile/2021-03/msg00012.html
