Menu ▾ ▴

#5 Copypaste integration

open
nobody
None
2016-03-13
2016-01-14
Ingwie
No

Hello!

I come from a GitHub mirror where a dev kindly reffered me here. :)

I would like to use Pluma, but have a few question regarding its usage. As a reference, I want to use Pluma in this project: https://github.com/IngwiePhoenix/IceTea

So first off, I would like to know if it is possible to define internal modules. For instance, I would like to have a way with which I could define built-in plugins as well. Currently, if you go to src/, you'll see a few files such as Plugin and PluginStore. Those are my hacky attempts of building this ^^;. But I can tell from far away that this is only a temporary solution... So I would like to know if I could use Pluma to define built-in plugins?

Then, about #include. It seems that even private headers within src/Pluma/ are refferenced with <Pluma/...> paths. This is actually not required, since compilers resolve headers relative to the file. So in fact, it would be nicer to change <Pluma/Dir.hpp> to "Dir.hpp" - and why is it important? Well...

The main goal of my tool is to be so small, that you can build it with a single, simple command. It is a built tool, and it shouldnt be hard to build a build tool - at least, I think so. So currently, on Linux, all you do is g++ src/*.cpp -o icetea and you're good to go. In order for me to use Pluma in this, I would have to add a lot of include flags. Assuming I copied Pluma into my project as-is, the command would change to: g++ src/*.cpp src/Pluma/*.cpp -Isrc -o icetea. So this is a bit off. Not a dramatic problem, but it'd be nice to keep things as simple as it gets. I might actually fork Pluma for that purpose...

Then, how can I include a simple module? The scripting language can be extended to change it's functionality, so I would like to add a function to load a simple shared library/object. In the examples, Pluma seems to search one folder, and one folder only, and always returns a list. How can I do just a single file?

For that, let's assume that the root plugin class is IceTeaPlugin, the extension .nit (Native IceTea) and the script calling like so:

var utils = require "tools/utils"; // ./.IceTea/tools/utils.it
var packageManager require.native "tools/pkm"; // ./.IceTea/tools/pkm.nit

What would my C++ code look like to load a single plugin? I can access the string argument passed to the function as char*.

Would be nice to hear back!

Kind regards,
Ingwie

Discussion

  • Ingwie

    Ingwie - 2016-03-13

    Hey!

    I have done my little bit of re-structureing and alike and implemented a little fix:

    On Mac OS X, "dylib" refers to a library, whilst a "bundle" is treatened as a plugin. Technically they are the same - both are dynamic loadable libraries in the end - but they are built a bit differently, and it also adheres more to the terminology.

    Check out the commits on my fork, when you feel like it.

    Direct mirror: https://github.com/IngwiePhoenix/pluma
    Modified source: https://github.com/IngwiePhoenix/pluma-modified

    The modified sourcetree is oriented towards my use case. I found the "load" function and I like how that one works. Will it let me supply the full path, even if the extension is a different one? For instance if I wanted to use .itn (IceTea Native) for native plugins? I will read more into it, but it'd be nice to know a bit more about what I can do! ^^

    Kind regards,
    Ingwie

     

Log in to post a comment.