Feature Request: Gcode processing plugin/language

[lordofhyphens]

I've been thinking about libslic3r and some of the prerequisites that would be necessary to move it completely to C++, as well as some of the pitfalls with currently how post-processing scripts are done.

Presently, the only "universally" available post-processing script interface for Slic3r is Perl (as the interpreter is still necessary for the GUI). What I think may be useful to solve a few related test cases (arithmetic in start/end/toolchange gcode, etc), is to embed a scripting engine into libslic3r.

Ideally, it'd be lightweight and easy to use and wouldn't need to define our own parser (or deal with lex/yacc).

The first language that came to mind was Javascript/ECMAScript. It has several engines that have low/no external dependencies available with compatible licenses, and it's relatively straightforward to learn and use.

We could import the basic engine and provide interfaces to Slic3r's variables.

[a4jp-com]

Thank you for all your work @lordofhyphens

I like the current version because I can compile it myself and make small changes where I want them but if it is easy to compile a C++ version in Windows that's okay with me. ^^

One company I do 3D printing with moved to Simplify3D a year ago as the calculations in Slic3r of small objects didn't work out before for some reason. I'd love to test a few old files on this newer version of Slic3r though. I guess a lot has changed in a year.

[Patola]

Javascript would have some appeal to web developers, but I think nowadays mindset is more geared towards python for these kinds of filters and embedded scripts.

I, for one, am very weary about the weird javascript typing and object system. That's why I usually stay away from it.

[lordofhyphens]

Python is batteries included, which would greatly increase the size of our distribution (more than I think is appropriate). We could leave the external script feature in (it still works with anything in the PATH iirc).

[nathanielhudson]

IMHO Javascript would be very nice.

Lua might also be a viable option without some of the weirdness typically associated with js, and it was specifically designed for this sort of use case. I also feel the Lua standard library is better suited to this sort of thing, and it's relatively simple to hook up to C/C++ programs.

[Patola]

I find lua nice too.

[bubnikv]

I never worked with lua, but people love it for light scripting in games and micro-controllers, so it seems like a good pick.

On Mon, Mar 13, 2017 at 10:09 PM, Patola notifications@github.com wrote:

I find lua nice too.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/3750#issuecomment-286244529, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I3kccn6CTN3bQ43RD1jiFGQpeGzgks5rlbCCgaJpZM4MaGvT .

[gege2b]

I didn't use LUA either but it seems to be a good candidate for this feature, as it is designed to be embeded in applications

[alranel]

Post-processing scripts don't generally use libslic3r, they just parse G-code independently so they can be written in any language. Are you aware of a post-processing script using libslic3r?

By the way, I think we should just provide/encourage bindings for libslic3r from all the most popular languages.

[lordofhyphens]

I mean an internal, lightweight scripting language, baked into our official frontend that is self-contained. We have that with Perl until we drop Perl from our frontend.

Extra requirements: Should also be difficult, if not impossible to do damage to people's systems with this language (earlier comments about perl and eval()).

[ghost]

I agree with the comments about Lua. It can run arbitrary code inside a "sandbox" environment, and the sandbox is fairly easy to create, to remove things such as system calls and other undesirable features for a use case. It's also quite small and fast, so shouldn't get too in the way of real-time slicing.