What about the hooks? We still end up having to thunk everything that is currently thunked with lua. Also we need to be very careful about versioning. You really need to ensure every plugin uses the exact same MCServer.dll.
You're not even considering this, are you? :p
The plugin code would create an instance of a class that inherits cPlugin, needs no special code to get hooks to work. We used to have squirrel script also working alongside Lua, the hooks were abstracted enough back then.
MCServer versions is not an issue, because the plugins are always compiled specifically for the version of MCServer you're currently running
Come on, I've only heard bad things so far
cPlugin would still need to be thunked to the C coding convention for calls to MCServer if plugins are compiled client side. Otherwise we have to ship a compiler to ensure the layouts, calling convention, and name mangling are the same. Also what is to stop people using methods that arn't part of the API? For lua and squirrel we handled this by not doing binding code for those methods. For C++ we either need wrapper classes for every class or to expose every virtual method and every field.
(10-26-2014, 06:24 AM)worktycho Wrote: [ -> ]cPlugin would still need to be thunked to the C coding convention for calls to MCServer if plugins are compiled client side. Otherwise we have to ship a compiler to ensure the layouts, calling convention, and name mangling are the same.
Yes, in the first post I suggested shipping a compiler with MCServer... did you read it?
As for Linux, different versions of gcc should be compatible right? Otherwise how can commercial libraries supply their binaries to Linux if programs can only be compiled with the exact same compiler these libraries were compiled with?
(10-26-2014, 06:24 AM)worktycho Wrote: [ -> ]Also what is to stop people using methods that arn't part of the API? For lua and squirrel we handled this by not doing binding code for those methods. For C++ we either need wrapper classes for every class or to expose every virtual method and every field.
Why would you want to stop people from accessing parts that aren't part of the API? This is actually a good thing in my opinion.
Shipping a compilier is an interesting idea, but c++ compilers are big. As for how linux handles compatibility is either C interfaces, or compile everything with the distros specified compiler. Unfortunately specifying a particular compiler tends not to work across multiple distress/versions of a distro.
The reason you want to stop people using parts that aren't part of the API is because otherwise people complain when their plugin broke because you refactored something. Or changed the contract of a method.
(10-27-2014, 08:31 AM)worktycho Wrote: [ -> ]Shipping a compilier is an interesting idea, but c++ compilers are big.
Yes it's not the best idea
(10-27-2014, 08:31 AM)worktycho Wrote: [ -> ]As for how linux handles compatibility is either C interfaces, or compile everything with the distros specified compiler. Unfortunately specifying a particular compiler tends not to work across multiple distress/versions of a distro.
How does the NVIDIA PhysX SDK do this then? It only has a C++ interface in the headers without function pointers, just classes with virtual functions and it supplies precompiled .a and .so files.
(10-27-2014, 08:31 AM)worktycho Wrote: [ -> ]The reason you want to stop people using parts that aren't part of the API is because otherwise people complain when their plugin broke because you refactored something. Or changed the contract of a method.
Well that's the risk plugin developers take when not sticking to the plugin API...
(10-27-2014, 08:04 PM)FakeTruth Wrote: [ -> ]How does the NVIDIA PhysX SDK do this then? It only has a C++ interface in the headers without function pointers, just classes with virtual functions and it supplies precompiled .a and .so files.
They just risk breakage and hope that the compilers don't break compatibility in a way that breaks them
(10-27-2014, 08:04 PM)FakeTruth Wrote: [ -> ] (10-27-2014, 08:31 AM)worktycho Wrote: [ -> ]The reason you want to stop people using parts that aren't part of the API is because otherwise people complain when their plugin broke because you refactored something. Or changed the contract of a method.
Well that's the risk plugin developers take when not sticking to the plugin API...
That never stops the plugins users complaining when a plugin breaks
(10-27-2014, 09:19 PM)worktycho Wrote: [ -> ] (10-27-2014, 08:04 PM)FakeTruth Wrote: [ -> ]How does the NVIDIA PhysX SDK do this then? It only has a C++ interface in the headers without function pointers, just classes with virtual functions and it supplies precompiled .a and .so files.
They just risk breakage and hope that the compilers don't break compatibility in a way that breaks them
So if a commercial project dares to take that risk, I'd say we can too
(10-27-2014, 09:19 PM)worktycho Wrote: [ -> ] (10-27-2014, 08:04 PM)FakeTruth Wrote: [ -> ] (10-27-2014, 08:31 AM)worktycho Wrote: [ -> ]The reason you want to stop people using parts that aren't part of the API is because otherwise people complain when their plugin broke because you refactored something. Or changed the contract of a method.
Well that's the risk plugin developers take when not sticking to the plugin API...
That never stops the plugins users complaining when a plugin breaks
Let's just agree that there will always be complaining then, whatever we do
I just came across
this compiler and it reminded me of this thread.
I also thought about maybe using LLVM IR.
However I don't know / don't think it will work well with different platforms without an insane amount of work to be done.
I don't know how relevant it is for the IR to be generated for a certain platform / what gcc or clang really tweaks for optimization.
Google has done something similar by declaring their own ABI for use with their VM:
https://developer.chrome.com/native-client
If we had something like this people could use whatever language they like as soon as there is a compiler that can generate LLVM IR (for our ABI), afaik (I didn't dig deep enough into that, so I can't guarantee anything).
This would however require to run a VM (and somewhat defeats the purpose) however we'd have increased security by sandboxing (so unlike native code this could not also load other stuff that is not part of Cuberite) and I think using a custom ABI and VM object passing shouldn't be a problem either.
EDIT: See here:
http://stackoverflow.com/questions/14258...s-platform
EDIT2: Also if someone really would have enough spare time and will he could probably force generation of portable LLVM IR or bytecode for an own VM using sdcc which uses newlib to provide necessary functions. But this would enable only C and not C++.
EDIT3: I think the best way to distribute plugins is by letting people build them from source in a unified way, similar to source packages in Linux distros, where you can just do a rebuild of the plugin for the architecture you want. So I think distributing packages which include the source code together with build and install scripts is the best solution.