Giters

Jengamon / ruwren

A Rustified binding for Wren

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How is one supposed to return a lists of foreign objects?

pac85 opened this issue · comments

commented

set_slot_new_foreign overwrites slot 0, calling set_slot_new_list(0) then set_slot_new_foreign on a free slot(say 1) and then set_list_elment(0, idx, 1) causes a sigsev (apparently set_slot_new_foreign writes a class on slot 0 so it makes sense). Now of course I can create and populate the list in another slot but there seems to be no way of copying it to slot 0 to return it.
Handles, could solve the issue but are only available through VMWrapper, a foreign function only gets a "VM" which doesn't expose a way to get and set handles.

commented

I see you've forked the repo and created an explicit scratch slot parameter for set_slot_new_foreign. Let me know how it goes, and if it works, I'll be ready to merge it in.

TBH I didn't really think of this use case when designing set_slot_new_foreign, so this was an oversight on my part. Once this is in, I'll deprecate/remove the original set_slot_new_foreign, and just make the scratch version the default.

commented

2 other alternatives are to:

  • Expose handles on VM instead of VMWrapper
    • The reason why this wasn't the case was that VMWrapper was all that was at one point. And everything was implemented on it (it was called VM at the time iirc), and then eventually I wanted to separate concerns. I might probably prefer this solution.
    • If this is done, access to these members should also be on VMWrapper, as I don't want to make it convoluted to get handles (as VM access from VMWrapper is hidden behind VMWrapper::execute.
  • Create an API for copying around slots.
    • Seems to just be hidden Handles.
commented

I'm currently using it in a project and it works just fine. I think this solution and exposing handles in VM shouldn't be considered mutually exclusive as they serve different purposes, although handles do allow to work around the limitation of not being able to specify a scratch slot it is ultimately just a workaround. If it is OK for you to have both APIs I can add tests and send a pull request for set_slot_new_foreign_scratch, then when I find the time I can try making another PR for exposing handles. As for an API for copying slots it is endeed more limited than exposing handles and would be redundant once handles are exposed so I agree with you that the first solution is the best.

commented

I've added tests to my fork, waiting for confirmation to make the pr

commented

Sounds good!