loadstring() and loadfile() Lua functions allow loading remote libraries and modules at runtime. As shown in this post it is very simple: How Do I Load Lua Module as a String Instead of a File?
Unfortunately Corona SDK has removed both these function. Here's a list of changes they have.
Is it possible to implement loadstring in lua or load it from a separate module?
They seem to provide a solution here but I don't really understand it and I don't think it will work in Corona cause it requires dofile which is also disabled in Corona
http://lua-users.org/lists/lua-l/2012-04/msg00875.html
loadstring() and dofile() are disabled per Apple's rules for allowing interpreted language apps to work on their devices. Apple will reject any app that has any dynamic programming features.
Related
I've been trying to write Vulkan bindings for a language and I'm a bit confused about how extensions work. On Linux I'm using libdl to load function pointers from libvulkan.so.1, and I've noticed that some extension functions (like those from VK_KHR_swapchain and VK_KHR_Wayland_Surface) can be linked through libdl, but others (like the ones in VK_EXT_debug_utils or VK_EXT_extended_dynamic_state2) can only be found through vkGetInstanceProcAddr or vkGetDeviceProcAddr.
My questions are these:
Why are some Vulkan extensions available through dynamic linking but not others?
Can I rely on these dynamically-linkable extensions always being there? (For example, can I be sure that if the VK_KHR_swapchain extension is available, vkCreateSwapchainKHR will definitly be found by libdl?)
TFM:
Vulkan Direct Exports
The loader library on Windows, Linux, Android, and macOS will export all core Vulkan entry-points and all appropriate Window System Interface (WSI) entry-points. This is done to make it simpler to get started with Vulkan development. When an application links directly to the loader library in this way, the Vulkan calls are simple trampoline functions that jump to the appropriate dispatch table entry for the object they are given.
Specifics: https://github.com/KhronosGroup/Vulkan-Loader/blob/main/docs/LoaderApplicationInterface.md#wsi-extensions
I want to bind a different programming language to the Godot game engine. Is there an instructional document or video on this topic? For example, how was this project done: godot-rust. If I can learn the basics, I can succeed in working in a different language. Thanks.
In this answer I show you the different approaches to add language support in Godot 3.x (the situation will be somewhat different with Godot 4.0 and GDExtension - which replaces GDNative and hopefully means less custom builds), and I mention some languages that are supported by each of these approaches. However, this is not an exhaustive list of the languages.
First of all, Godot has official build-in support for GDScript and Godot's VisualScript (and Godot's shading language and its visual counterpart if those counts for you).
There are a few ways to use C++:
You can use it to create GDNative scripts (which are basically a wrapper around native calls that allow you to use them as scripts in Godot).
Or you can create modules (which are static libraries you can add in a custom Godot build).
And since Godot source is in C++, you don't have to restrict yourself to making modules if you are making custom builds.
In web builds Godot can interface with JavaScript via the JavaScript class. However, this approach does not allow you to add JavaScript scripts to Nodes, and so on.
Then there are languages that can only be added in custom builds of Godot, which is currently the official support for C#.
There are other non-official custom builds that offer language binding for languages such as Lua, Kotlin, TypeScript and JavaScript (this time allowing you to make scripts).
If you need to add a runtime, you would probably do this.
Some language take advantage of the fact that Godot's has official Mono support in order to support C#. This way you can, for example, use F# and Clojure.
They start by adding a C# project and then modify it so it uses another language. This is viable if your language already compiles to .NET.
Some other languages can be added as plugins that implement the PluginScript class via GDNative. This is the case of Python and Lua (again) which you can get from the asset library.
This is the most user friendly way to add language support to Godot, but it is limited to what you can do with PluginScript.
Addendum: Gil Barbosa Reis, author of the aforementioned Lua bindings, has an article series about its implementation stuffed away in the repository (in English and Portugueses): godot-lua-pluginscript/extras/articles/. It is probably the most comprehensive tutorial to date.
Other languages are added by means of taking advantage of GDNative (They basically mimic what you would do with C++). This is the case of Nim, Rust, D, Haskell, Go, Swift…
So that's how godot-rust works: make native libraries using rust and the godot-rust create and add them as if they were made in C++. For any language for which there are the means to make native libraries already, this is a good option.
Finally there is another way to add support for a language: a transpiler from that language to GDScript, which can be automated with an addon that might also be written in GDScript. This is the case of Lisp.
This last approach is mostly used for domain specific languages.
The official docs here provide your answer:
Godot officially supports GDScript, C/C++, C#.
Some 3rd party languages that can be used are: Rust, D, Python, Nim, and Go.
I want to create an Objective-C application which lets you specify a class implementation at runtime.
I want the user to type some code (correctness of the code is out of scope for now).
When the user is done i want to create a class of the typed code and use it in the application.
So i want to dynamically add code in runtime of the application. Is this possible?
If so, how can i achieve this? If not, why not and are there any alternatives to create the same effect which i want to create?
Thanks.
You can dynamically load classes at runtime, but to get there you'd first need to handle distributing a compiler, its compilation dependencies (headers, ...), setup its enviroment, etc.
Usually applications use scripting languages that are painlessly embeddable (Lua, Python, ...) or already available on the platform (JavaScript, AppleScript, ...).
I'd check out F-Script. It's closer to smalltalk than Obj-C, but IMO it's closer to Obj-C than JavaScript or Lua :-)
On iOS devices, this isn't possible. On a Mac you could link against the clang+llvm libraries and use them to generate code into a buffer, then mprotect() the buffer to be executable, I believe.
The issue is that I've written a Safari plug-in (Growler) that allows web applications to send Growl notifications by calling Javascript functions. However, at the moment the way it is written, people need to use <embed> to initialise the plug-in so that Javascript can begin using it (something I picked up from Apple's examples).
I was wondering if there was a way I could define something like window.<pluginName> so that they didn't have to embed it everytime? That'll allow a lot of sites to begin using it without changing any code.
I've looked at a lot of examples and documentation, and two things came up — 'WebView' and 'WebScriptObject'. I'm pretty new to this, so I'm not really sure what to do.
There's no way to write a WebKit plug-in that doesn't handle a content type. That's why so many Safari “plug-ins” or “extensions” (including GrowlSafari) are implemented as input manager hacks.
The way you've done it is the only reliable, safe, supported, and not doomed way to do it.
I have been researching around trying to find the best way to begin developing an application which aims to analyse user's writing styles based on outgoing SMS messages. I have installed Symbian's SDK and Carbide and purchased a book on their specific style of C++ to get started. However, I was told to check out Open C for Symbian as I have some previous C experience. I have installed the plugin from http://www.forum.nokia.com/Resources_and_Information/Explore/Runtime_Platforms/Open_C_and_C++/ and tested a simple Hello, World! application with success.
Although, the initial success would lead me to believe Open C would be a better option for me, I am worried about limitations of using Open C. For example, I need to be able to access native functions of the Symbian OS to capture keystrokes while in the SMS composer. I also need to be able to run my application in the background and have it load on system startup as not to interfere with user's normal activities.
Can someone clarify if Open C can access such functions and fulfil my needs in terms of developing this specific application? Also, what are the limitations to using Oepn C in comparison to the standard Symbian C++?
I'm by no means a Symbian guru but we've used the Open C/C++ plugin for Symbian here. My understanding is that the plugin is simply an extension -- it gives you the standard libraries and lets you deal with familiar functions (in our case, just the simple cstring.h, and stdio.h libraries were what we were looking for).
You can still mix and match the Symbian calls and likely will have to deal with some painful conversions to get your char* into the proper "descriptor". However, you should only have to do these at the interfaces at which you're touching existing Symbian libraries (as they're going to expect descriptors, not char*s).
In our code, we have some places where we're using a remove call to delete files and in the same class, creating the detailed Symbian RFs abd RFile objects.
So yes, while we use C/C++ libraries to do some low-level stuff and a lot of string manipulation, we're also using the Web Browser Control, key input monitoring and all that.
...And yes, we need to clean up our code. :-)
Open C provides a set of standard C libraries for Symbian OS programs i.e. it is a library.
This means you can call Open C code and Symbian native code freely in the same program, just as with any other library, provided you respect the preconditions and assumptions that the libraries require.
This is where the complexity comes in, because the standard Symbian APIs often require things like descriptors and a working active scheduler, whereas the Open C libraries don't. But provided you're careful you can do what you want.