I got code::blocks as my C/C++ compiler along with C++ for dummies, but my only problem is with a obscure scripting language that I have never heard of before; "Squirrel". Is it possible to change the scripting language of code::blocks to something more familiar to me, like lua?
It seems doable in theory. Whether it is doable in practice, hard to say. Here is what you would need to do:
create a folder src/sdk/scripting/lua in which you put the Lua interpreter (+ Lua libraries like io, math etc) source code and create project file for it
create a folder in src/sdk/scripting/lua_bindings where you put your Lua bindings: the C++ files that allow Lua scripts access to the host application. I recommend you use a tool like SWIG to generate them (codeblocks uses SqPlus). This involves determining what code-blocks functions/classes you want to export, creating one or more .i files, running SWIG on them, put the generated files going into "lua_bindings"; create a DLL project for the bindings
Create a src/lua_scripts in which you put the Lua equivalent of scripts found in src/scripts; or rather, a subset of those scripts, because it is unlikely you will want to export to Lua everything that is available via Squirrel if you're just following examples from a book
Find where Squirrel interpreter is instantiated in codeblocks and where RegisterBindings is called; replace it with instantiation of a Lua interpreter and call your luaopen_codeblocks which you will have created via SWIG (no need for a RegisterLuaBindings if you use SWIG, it does that for you)
Find where the various scripts are called by codeblocks (see http://wiki.codeblocks.org/index.php?title=Scripting_Code::Blocks). Call the equivalent Lua scripts (which are in lua_scripts -- you'll surely have to copy this to the installation folder for code-blocks). For example the startup.script, which is the Squirrel script that codeblocks automatically looks for at startup, is run by the following code in src/src/app.cpp:
// run startup script
try
{
wxString startup = ConfigManager::LocateDataFile(_T("startup.script"), sdScriptsUser | sdScriptsGlobal);
if (!startup.IsEmpty())
Manager::Get()->GetScriptingManager()->LoadScript(startup);
}
catch (SquirrelError& exception)
{
Manager::Get()->GetScriptingManager()->DisplayErrors(&exception);
}
I think that's about it.
Naturally based on how extensive your scripting is, you may cut some corners, but as you can see, this is not for the faint of heart!
Related
So, hi!
I am very new to Coding outside of a Game-Creation Program that automatically creates executable files for me, and from Create Your Frisk and other projects, I know a decent chunk of the basics in LUA. but how do I make a program out of it?
Like, How do I make an executable?(I'm using visual studio to code)
You need a Lua interpreter that runs your Lua code.
Either you use a standalone Lua interpreter, a little executable that can only run Lua scripts, or you embedd a Lua interpreter into your own application.
See http://www.lua.org/start.html
I'm using lua inside another (Windows) application that provides a lua scripting interface. Is there a way for me to know which lua executable is being used? I know the version, but I would like to know where is the lua.exe that is running.
Lua is an embedded scripting language; that is the design of the thing. Lua is designed and intended to be incorporated into other programs. Lua.exe is essentially just a tiny shim over the Lua runtime, Lua being incorporated into a small console application. This is useful for using Lua as a console scripting language, but Lua.exe is in no way required to use Lua.
Lua scripts are not expected to know or care about the environment in which they run, except for in exactly the ways that this environment provides for them to detect. Lua as a language therefore has no mechanism to detect anything about the nature of the environment. If an embedded Lua environment wants you to be able to query such things, it will provide a mechanism for you to do so.
In perl5 it was easy to link in libperl.so, set some variables and run some code, with callbacks. Is there a story for doing this in perl6?
I think you can find the state of the art in that respect at https://metacpan.org/pod/Inline::Perl6 , which embeds Rakudo in Perl 5.
Besides what #elizabeth-mattijsen has commented, no, there's no such thing. While the perl interpreter was a monolithic thing which might be relatively easily turned into a .so library and then linked with some API endpoints, Perl 6 is two big things: a virtual machine, either Java or MoarVM, plus the interpreter, Rakudo. There could be an scenario in which you wouldn't need to embed Java or MoarVM, because both languages would be running in the same VM. Think Perl 6 embedded in Clojure, for instance. Or Perl6 embedded in 007, both running in MoarVM. That would be kind of easy, and you would be targeting a VM with the same capabilities. But C++, C and Perl6 have a very different abstract virtual machine as a target; think about the Unicode handling, or the concurrent interface. Embedding Perl6 in C would be basically running Perl6 programs from C, instead of running them from the command line.
It is possible that, in the same way Perl regexes ended all over the place, some Perl 6 capabilities, like Unicode handling or grammars, could end up ported or embedded in other languages. But I don't see a clear use case for embedding Perl in C or C++, right now, and devoting some effort for that kind of thing would be, thus, better employed in something completely different.
This isn't an answer, but suppose I've got an already existing C program which is designed to use plugins which are .dlls or .sos, and they get loaded via dlopen or LoadLibrary, an API entry point is found using dlsym or GetProcAddress, then that entry point is called with some sort of handle for the plugin to make calls back into the main process.
Now, suppose I want my plugin (inside of this .dll or .so) to load moarvm, and then run some perl6 script, which in turn uses NativeCall to call back into the main process. How would I go about doing this?
Alternatively, suppose I want my plugin (inside of this .dll or .so) to load the jvm, then run some perl6 script, etc. How would I go about doing this?
Loading perl5 just to load perl6 seems like a silly solution. It might work, but...
I'm currently using the rust-lua53 crate to embed Lua into a Rust project. rust-lua53 downloads and builds the Lua tarball during "cargo build" (in its build.rs).
I'd like to make other Lua libraries (written in C) available to Lua code in my application, eg LPeg or LFS, but it's not obvious to me how to do it.
My ideas so far are:
Build the libraries against a stock Lua and hope I get away with it (or have to check it matches every subsequent rust-lua53 release)
Somehow expose the relevant headers from rust-lua53 (can a crate include extra files like that?)
Change to a different Rust/Lua binding which somehow makes this easier.
Fork rust-lua53 and make it embed the extra libraries I want as well as the plain Lua interpreter.
Implement the functionality in Rust instead of relying on C libraries. Plausible for LFS in my application, but re-implementing LPeg is beyond what I want to do right now!
I'd really like to be able to run some Rascal's program from outside the REPL (e.g. as part of a script, or called from another program). What I'm using Rascal for is and intermediate stage in a larger framework so I am wondering what the best way to go about integrating executing the Rascal code from another program.
Right now the best way is to package your code together with the Rascal shell executable jar. There is a convenience class JavaToRascal for calling into Rascal code. Sometimes it requires some thinking to add your own modules to the Rascal search path using IRascalSearchPathContributors, but if you include a RASCAL.MF file with the right properties it all should go automatically.
If you are thinking of an Eclipse plugin, then the best way is to let your plugin depend on the rascal-eclipse plugin and use ProjectEvaluatorFactory to get access to the interpreter.
Caveat: since we are moving to a compiled system, the code you write for this kind of integration will change. This is the reason we haven't documented the API for calling Rascal from Java yet.
As I was pondering the same question, this is the (maybe trivial) answer I came up with:
java -jar /path/to/rascal-shell-stable.jar path/to/myProgram.rsc
You have to be aware that Rascal calculates module names from the current directory (don't know if it supports something like Java's CLASS_PATH), so in the above example myProgram.rsc should have a module declaration of module path::to::myProgram. Calculated and declared module name have to match.