What’s the best way to send a function through a place? Maybe I don’t need to send the function because the code for the function exists everywhere. I need to tell another place to run a function, so instead of sending the function (which might be hard) I can say, execute function X from module Y. What’s the best way to serialize this?

@pocmatos the usual approach is a vector with a module path and a symbol, and then use dynamic require on the other end

@samth Makes sense, thanks. I will try that.

I have not played much with the graphing capabilities of Racket except to do math plots. Does anyone know how suitable it is to create timelines? (an example of things I am interested: https://github.com/jiahuang/d3-timeline)

https://raw.githubusercontent.com/jiahuang/d3-timeline/master/examples/timeline4.png

Racket complains about: ffi-obj: couldn't get "hello" from #<path:/Users/totz/Desktop/eco-playground/libfuncs.dylib> (dlsym(0x60400033eb40, hello): symbol not found). But compiling/running a main.c that uses the “hello” function works. I am trying out the simplest imaginable wrapper: calling a C-function that prints “hello” in Racket.

Is there a way to just look into the #<ffi-lib> object to see what it is made of?

I am trying to follow this tutorial: https://docs.racket-lang.org/foreign/intro.html#%28part._.Libraries__.C_.Types__and_.Objects%29 . It doesnt complain about missing symbols. But it crashes DrRacket as soon as i call (define win (initscr))

@redwynskaja is main.c being compiled as a library?

oh I see it’s a dylib, did you ensure that hello is being exported by that library?

Hm no i think not. However, I found and example in http://github.com/AutoFFI/racket-autoffi\|github.com/AutoFFI/racket-autoffi

When using clang according to their example, it works now. (Before I used GCc)

So I guess I did it wrong somehow (zero experience). I did not use the Auto ffi tool itself though. Just their library compiling instruction

ok, great! It’s been a while since I used Racket’s ffi, in my experience those type of errors arise due to misconfiguration or missing exports

Not sure why DrRacket crashed when you were following the tutorial, the libcurses might have not been found on your system but didn’t think that would cause DrRacket to crash unless the code in the tutorial was incompatible with the version of libcurses found on your system

that’s the hazard of ffi, you have little protection if something goes awry in that layer

Hm couldn’t there be some kind of „box“ in which foreign code runs and at least some message In case of failure?

not necessarily, there’s not much you can do if the DrRacket process gets corrupted. FFI really is low-level, if there’s memory corruption, all bets are off

Ah, i understnad

I have void hello() { printf("hello\n"); } in my funcs.c file. There seems to be no problem with the FFI except, that calling it in DrRacket REPL doesnt print “hello\n”…

However, int add(int a, int b) { return a + b; } works when typing (add 1 2) it prints 3 just fine.

It would be great If someone just had a “Sundials” wrapper lying around :slightly_smiling_face: … I’d need years to get there xD

printf is a purely side-effect operation, any strings will be written to the C’s standard output as opposed to being returned to the caller. C’s output doesn’t have to correspond to DrRacket’s output, my guess is additional arrangements have to be made to connect the two

try changing printf("hello\n") to return "hello\n" instead

Yes that works. Although it really prints (including " and \n) "hello\n"

@mflatt These two identifiers have the same binding, but the expander complains that one of them is unbound: https://gist.github.com/LeifAndersen/8c0a8c1722faabad5ee0c04221fc7e98

They do seem to have different scope sets, but they ‘seem’ to be resolving to the same identifier.

@mflatt Hmm…looks like its a Racket 7 bug.

(because it works in 6.12)

The example works in v6.12, but only because that expander implements a mapping with a questionable choice of keys.

A variant of the example breaks in v6.12. To get the variant, change the end to (define-syntax (f stx) .... #`(list (quote-syntax #,the-x) (quote-syntax x))) (map eval (f)) which illustrates how the MPI on the-x isn’t really the right one to refer to the enclosing module.

The v6.12 expander allows the original example because it uses a resolved module path in a mapping where it should arguably use the MPI as a key. The variant exposes an inconsistency by delaying the use of the resolved module path to a later point, where the “self” MPI must be really a specific MPI for things to work out.

It’s possible that the right solution is a new syntax function that lets you directly construct a binding for a given MPI and symbol (with a given code inspector).

Ya, that sounds right to me.

(That’s also what @michael.ballantyne was pushing for earlier today.)

So, @mflatt, would that be the sort of thing you could easily write, or should I work it out?

I can take a look tomorrow

Thanks. :slightly_smiling_face:

That would also let TR stop using code that basically looks like that eval