unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Taylan Kammer <taylan.kammer@gmail.com>
To: paul <paul@inktvis.org>, guile-user@gnu.org
Subject: Re: Difficulty integrating with Swift/Objective-C
Date: Sun, 5 Sep 2021 10:26:49 +0200	[thread overview]
Message-ID: <f72978b4-1ea4-8a7e-2199-f7608b9e9ac0@gmail.com> (raw)
In-Reply-To: <m2sfyjmudv.fsf@inktvis.org>

On 05.09.2021 08:03, paul wrote:
> 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(&register_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" . #<program 12503b140 124fc10fc>)) #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
> 

Hi Paul,

To narrow down the issue, I'd attempt a few things, in order:

1. Compile only the C code, adding a main() function, just to make sure the OS
   and the chosen Guile version and such are working fine with each other.

2. Compile pure Objective-C code, calling that run_guile() function firstly
   directly from the main() function in main.m of the Objective-C program, and
   commenting out the NSApplicationMain() call that would initialize Apple's
   application framework.

3. See if reactivating the NSApplicationMain() call causes problems.  (It should
   be called *after* the Guile initialization.)

4. See if you can use Guile's C functions from -applicationDidFinishLaunching:
   e.g. by doing: scm_c_eval_string("(begin (display 'HelloWorld) (newline))")

If that works, we now have an Objective-C + Guile application, and want to move
to using Swift instead.  This is where my Apple knowledge hits its limits because
I never used Swift. :-)

But I guess Swift should have something equivalent to the main() function of C and
Objective-C, and calling Guile initialization from there might do the trick.

If you hit a problem in step 3 or 4, then it could mean that Guile and Cocoa are
somehow incompatible as they both want to apply some magic to the C program while
initializing themselves.  I wouldn't know how to approach that issue.

-- 
Taylan



  reply	other threads:[~2021-09-05  8:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-05  6:03 Difficulty integrating with Swift/Objective-C paul
2021-09-05  8:26 ` Taylan Kammer [this message]
2021-09-05  9:35   ` paul
2021-09-06 10:21   ` paul
2021-09-06 13:11     ` Taylan Kammer
2021-09-05 10:56 ` Chris Vine
2021-09-06 10:26   ` paul
2021-09-06 16:28     ` Chris Vine
2021-09-08 23:59 ` paul
2021-09-28 20:22   ` Aleix Conchillo Flaqué

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f72978b4-1ea4-8a7e-2199-f7608b9e9ac0@gmail.com \
    --to=taylan.kammer@gmail.com \
    --cc=guile-user@gnu.org \
    --cc=paul@inktvis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).