Scripting Brainstorming

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Scripting Brainstorming

xnakos
I chose to start a new thread than to revive one from the dead. I find the scripting element very important and missing from LibreCAD.

First of all, I took a look at the current scripting code (whose state I am not sure of, I didn't really try to use it). It is using Boost Python. I was not familiar with Boost Python, though it seemed really good. I played around just to make the sample plugin interact with some Python code to see that it could be able to provide a solution. It needs time, though, to get around and a lot of stuff must be done manually, even to get the slightest thing working. Plus, it is just Python that works with that and could extend LibreCAD (although Python is the bomb, at least for me). I took some time to look into some more stuff and came across SWIG. SWIG provides wrappers with great ease to facilitate extending an application with scripting. Python is just one language that can be used as a scripting language. Lisp, Lua, even Java and shit can be used. SWIG seems very actively developed (GSOC had five slots for SWIG during last summer) plus the license is permissive (application and generated code). The important thing to do is to design a concrete (and complete) interface to be exported. This interface must be implemented in C++, just having in mind that it will be used externally (alternatively, the desired external usage drives the implementation). Then exporting a selected set of API functions is done automatically using SWIG, for the target scripting language.

I also looked into a scenario that SWIG was used in. The Ogre graphics engine had some first initial bindings using Boost Python. But after a couple of developers could not continue maintaining the code, the new developers had a terrible time supporting this feature as it was. They gave up and provided a new solution using SWIG. They were very pleased with the result. In the end, SWIG was dropped from the project, though, because performance-wise it was inferior compared to a well-tuned implementation using Boost Python (the new Boost implementation was developed along the lifetime of the SWIG implementation). But this is understandable for a graphics engine, where performance is a feature of great importance. SWIG provides an automated mapping, correct but not greatly efficient, compared to a manual mapping. For extending an application like LibreCAD, it seems amazingly suitable (and I really don't believe that a few milliseconds drops in performance are an issue, someone should remember that it was once used for a graphics engine, not that it was dropped in favour of something with better performance but that also took a shitload of more time to implement). Plus the possibility of being able to use multiple scripting languages (with most of the code base being the same) seems very attractive.

Any views on the above (since my hands-on experience was extremely limited)? Rallaz, if you can at some point, could you provide some info on the current plugin API? Could you all provide some scenarios that you would want a hypothetical script of yours to be able to perform?
Reply | Threaded
Open this post in threaded view
|

Re: Scripting Brainstorming

dxli

hi,

first, all drawing methods, like draw line, circle

second, should be able to refer emtities: like, trim line 2 by line 1

third printing out

fouth, loop, conditional to create patterns

On Oct 19, 2012 9:40 AM, "xnakos [via LibreCAD]" <[hidden email]> wrote:
I chose to start a new thread than to revive one from the dead. I find the scripting element very important and missing from LibreCAD.

First of all, I took a look at the current scripting code (whose state I am not sure of, I didn't really try to use it). It is using Boost Python. I was not familiar with Boost Python, though it seemed really good. I played around just to make the sample plugin interact with some Python code to see that it could be able to provide a solution. It needs time, though, to get around and a lot of stuff must be done manually, even to get the slightest thing working. Plus, it is just Python that works with that and could extend LibreCAD (although Python is the bomb, at least for me). I took some time to look into some more stuff and came across SWIG. SWIG provides wrappers with great ease to facilitate extending an application with scripting. Python is just one language that can be used as a scripting language. Lisp, Lua, even Java and shit can be used. SWIG seems very actively developed (GSOC had five slots for SWIG during last summer) plus the license is permissive (application and generated code). The important thing to do is to design a concrete (and complete) interface to be exported. This interface must be implemented in C++, just having in mind that it will be used externally (alternatively, the desired external usage drives the implementation). Then exporting a selected set of API functions is done automatically using SWIG, for the target scripting language.

I also looked into a scenario that SWIG was used in. The Ogre graphics engine had some first initial bindings using Boost Python. But after a couple of developers could not continue maintaining the code, the new developers had a terrible time supporting this feature as it was. They gave up and provided a new solution using SWIG. They were very pleased with the result. In the end, SWIG was dropped from the project, though, because performance-wise it was inferior compared to a well-tuned implementation using Boost Python (the new Boost implementation was developed along the lifetime of the SWIG implementation). But this is understandable for a graphics engine, where performance is a feature of great importance. SWIG provides an automated mapping, correct but not greatly efficient, compared to a manual mapping. For extending an application like LibreCAD, it seems amazingly suitable (and I really don't believe that a few milliseconds drops in performance are an issue, someone should remember that it was once used for a graphics engine, not that it was dropped in favour of something with better performance but that also took a shitload of more time to implement). Plus the possibility of being able to use multiple scripting languages (with most of the code base being the same) seems very attractive.

Any views on the above (since my hands-on experience was extremely limited)? Rallaz, if you can at some point, could you provide some info on the current plugin API? Could you all provide some scenarios that you would want a hypothetical script of yours to be able to perform?


If you reply to this email, your message will be added to the discussion below:
http://forum.librecad.org/Scripting-Brainstorming-tp5707168.html
To start a new topic under LibreCAD-dev, email [hidden email]
To unsubscribe from LibreCAD-dev, click here.
NAML
Reply | Threaded
Open this post in threaded view
|

Re: Scripting Brainstorming

xnakos
Hi! Thanks for the info! I have some very basic quesions now. First of all, I tried using SWIG in an extend-and-embed fashion, i.e. create Python wrappers for c++ functions that could be used in Python scripts (extend) and call these scripts from inside LibreCAD (embed). I tried this as a proof of concept and had some initial success. But I need a lot of information to go on. The sample script I ran was this:

import script
p1 = (8,2)
p2 = (180,238)
print script.line(p1, p2)
print script.line((20, 20), (130, 180))
print script.line((0, 20), (70, 120))

"print " was used just to debug. Omit "print " and you have a script that draws three lines when you run it.

I tried to build this on top of the plugin system, working on the sample plugin of LibreCAD. This had a few caveats but I will get to that. First of all, I used simple 2-tuples to represent points as a demonstration of using SWIG's typemaps. I created the "line" C++ function that takes as arguments double p1[2] and double p2[2], that is arrays of length 2. Using a typemap I told SWIG that 2-tuples are to be converted to arrays of length 2. This is just an example. "line" used the code of the sample plugin to create the line. "script" is the Python module that is created by SWIG, the one which contains all wrapper functions.

One little problem was this: The function of the plugin that runs the code takes the doc as a parameter, but I also needed to have access to the doc through the "line" function. To achieve that I used a global variable gdoc that was initialized to doc when the plugin code started to run. This gdoc was used in the "line" function. What if I wanted to select another document through the script? Or to create a new one rather than work on the current one. Furthermore, how can I get a hold of the document entities through the plugin API? How can I get all polylines, for instance? Is the plugin API the way to go? Are there entity ids in LibreCAD that can be used in scripts, as in "trim entity 1 by entity 2"?
Reply | Threaded
Open this post in threaded view
|

Re: Scripting Brainstorming

dxli
entity ID is defined in rs_entity.h

 unsigned long int getId() const {
        return id;
    }

On Thu, Oct 25, 2012 at 11:31 AM, xnakos [via LibreCAD] <[hidden email]> wrote:
Hi! Thanks for the info! I have some very basic quesions now. First of all, I tried using SWIG in an extend-and-embed fashion, i.e. create Python wrappers for c++ functions that could be used in Python scripts (extend) and call these scripts from inside LibreCAD (embed). I tried this as a proof of concept and had some initial success. But I need a lot of information to go on. The sample script I ran was this:

import script
p1 = (8,2)
p2 = (180,238)
print script.line(p1, p2)
print script.line((20, 20), (130, 180))
print script.line((0, 20), (70, 120))

"print " was used just to debug. Omit "print " and you have a script that draws three lines when you run it.

I tried to build this on top of the plugin system, working on the sample plugin of LibreCAD. This had a few caveats but I will get to that. First of all, I used simple 2-tuples to represent points as a demonstration of using SWIG's typemaps. I created the "line" C++ function that takes as arguments double p1[2] and double p2[2], that is arrays of length 2. Using a typemap I told SWIG that 2-tuples are to be converted to arrays of length 2. This is just an example. "line" used the code of the sample plugin to create the line. "script" is the Python module that is created by SWIG, the one which contains all wrapper functions.

One little problem was this: The function of the plugin that runs the code takes the doc as a parameter, but I also needed to have access to the doc through the "line" function. To achieve that I used a global variable gdoc that was initialized to doc when the plugin code started to run. This gdoc was used in the "line" function. What if I wanted to select another document through the script? Or to create a new one rather than work on the current one. Furthermore, how can I get a hold of the document entities through the plugin API? How can I get all polylines, for instance? Is the plugin API the way to go? Are there entity ids in LibreCAD that can be used in scripts, as in "trim entity 1 by entity 2"?


If you reply to this email, your message will be added to the discussion below:
http://forum.librecad.org/Scripting-Brainstorming-tp5707168p5707178.html
To start a new topic under LibreCAD-dev, email [hidden email]
To unsubscribe from LibreCAD-dev, click here.
NAML



--
Dongxu Li, Ph.D.
www.librecad.org

Reply | Threaded
Open this post in threaded view
|

Re: Scripting Brainstorming

Valber
In reply to this post by xnakos
Very interesting topic!)

Give a link on your repo, if you get connected LibreCAD and SWIG


P.S. LibreCAD-dev  Need more news in LibreCAD blog)))
Reply | Threaded
Open this post in threaded view
|

Re: Scripting Brainstorming

dxli
scripting was planned for 2.0, we hope we will get it ready in 2.1 now