Commit graph

9 commits

Author SHA1 Message Date
640cc0e493 Reordering things a bit
I currently have meson 0.52.1 and the default_library=static
option has no effect for me, but I'm leaving it there in case
this changes in the future.
2020-05-01 00:14:55 +02:00
a3dcb583d7 Attach licence 2020-04-30 23:33:54 +02:00
0f0d149ad2 Move public headers to a separate directory, make a library 2020-04-30 22:50:46 +02:00
b1c1ae40f5 Add call() overload that takes a string literal as wren's function name.
Only the function name needs to be passed in and not the full
signature. The implementation will append the appropriate
(_,_,...) part making it at build time.
2020-04-30 21:18:29 +02:00
df52fe0fba Add support for calling wren methods from c++ using call() 2020-04-30 19:58:09 +02:00
2755371792 Refactoring.
VM now aims to only wrap Wren's c functions as closely as
possible. All the fun stuff should be put into vm_fun.hpp.
2020-04-30 19:54:51 +02:00
16c4b8cbe5 Allow foreign_method_fn() in the configuration object.
Wren expects this function to return a pointer to a function
that takes a WrenVM*. This is bad news because that type is
wrapped inside wren::VM and client code doesn't know about it.
It would be better for client code to return a pointer to a
function that takes a VM* instead. In order to do the VM* to
WrenVM* translation I make a "handmade" closure, that is I
generate a function at runtime that contains the VM* hardcoded
into it. The same function also contains the hardcoded
address of the callback function client code wanted to use.
By doing this I can pass a different function pointer to Wren
for each foreign method, and that function knows how to forward
the call to the real client callback.
Currently only implemented for amd64 gnu/linux.
2020-04-26 17:20:12 +02:00
3142e4c4ce Start working on a c++ interface. 2020-04-25 20:45:59 +02:00
257513e72a Sample code that prints a message from wren 2020-04-25 01:49:46 +02:00