New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scripting RFC #1

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@Moxinilian
Copy link
Member

Moxinilian commented Oct 28, 2018

This RFC introduces our scripting proposal.
Rendered

@kabergstrom

@Moxinilian Moxinilian changed the title Create 0001-scripting.md Scripting RFC Oct 28, 2018

@Xaeroxe

This comment has been minimized.

Copy link

Xaeroxe commented Oct 31, 2018

I really like all of this. My only suggestion is a name change, rather than augmented FFI we should call it Automatically Idiomatic Foreign Function Interface. AI-FFI.

@fhaynes

This comment has been minimized.

Copy link
Member

fhaynes commented Oct 31, 2018

The first one is to ban scripts from handling their own threading.

What about languages that use green threads?

@Moxinilian

This comment has been minimized.

Copy link
Member Author

Moxinilian commented Oct 31, 2018

Feel free to use GitHub's review features so we can have threads.
@Xaeroxe Sure, why not, I called it augmented FFI just for the context of the RFC, I wasn't planning on keeping the name.
@fhaynes I think this could fall under the "limited managed threading" kind of deal. But maybe it's been too long since I've read about green threads. I need to look at it again.
But like for example it would be perfectly fine to have Rust have threads, because Rust is smart. The constraints here are language-specific.

@fhaynes

This comment has been minimized.

Copy link
Member

fhaynes commented Oct 31, 2018

Feel free to use GitHub's review features so we can have threads.
@Xaeroxe Sure, why not, I called it augmented FFI just for the context of the RFC, I wasn't planning on keeping the name.
@fhaynes I think this could fall under the "limited managed threading" kind of deal. But maybe it's been too long since I've read about green threads. I need to look at it again.
But like for example it would be perfectly fine to have Rust have threads, because Rust is smart. The constraints here are language-specific.

I mean more like threads that are managed by a language runtime, goroutines or Erlang processes for example, but the OS views as just one OS thread.

@Moxinilian

This comment has been minimized.

Copy link
Member Author

Moxinilian commented Oct 31, 2018

It would depend on specific cases then. I haven't thought about it yet. If you want to make an addition, please write a paragraph and PR it to my fork.

@fhaynes

This comment has been minimized.

Copy link
Member

fhaynes commented Oct 31, 2018

In order to expose that API in an idiomatic way to the language they drive, the drivers are also provided with additional high level metadata, along with the FFI. For example, if a type is an iterator, the language driver will be noticed of this additional information so that it can, for example, do the necessary language-specific work for this iterator to be iterated over in a for loop (see the Lua example for more details).

Something about this bugs me, but I'm not sure what. Will have to think about it more. At a minimum, I think this will need a strict schema. I just have a suspicion that the driver code responsible for the the translation will end up messy. But we won't know until we try it.

Show resolved Hide resolved 0001-scripting.md Outdated
Show resolved Hide resolved 0001-scripting.md
@fhaynes

This comment has been minimized.

Copy link
Member

fhaynes commented Oct 31, 2018

It looks pretty solid to me. I'd vote move forward with a minimal PoC using LuaJIT to get an idea of the difficulties associated with this level of genercism.

@torkleyy
Copy link
Member

torkleyy left a comment

I think this is pretty similar to what was said before. I'm going to go through the details later.


Anyway, keep in mind that what approach is chosen can be different for each language, as different languages give us more or less flexibility (Rust as a scripting language for example already enforces all of this out of the box).

## Hotswapping

This comment has been minimized.

@Marwes

Marwes Nov 5, 2018

Does this mean that script system(s) are run in a separate World(?). I don't remember where I read it but since there is no way to add or remove systems after constructing a World it was recommended to keep dynamic systems in a separate world to avoid needing to reconstruct everything everytime something is reloaded.

https://github.com/Marwes/shred-example

https://github.com/Marwes/shred-example/blob/9f6d6a62f0b4cf7f55c3e5e9ca851c76c8ec9dea/src/gluon_system.rs#L798-L800

This comment has been minimized.

@torkleyy

torkleyy Nov 5, 2018

Member

The architecture Specs will have in the future will differ from the current quite a bit. It's already in design ;)

This comment has been minimized.

@torkleyy

torkleyy Nov 5, 2018

Member

Regarding your comment, I think you're mixing up Dispatcher and World. Both are very likely going to change (the latter one also renamed to SystemGraph which will not need any of those workarounds).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment