If I was to make a slicer based on Slic3r and Cura and written in python, who would be interested in using the slicer? Would anyone be willing to donate to the cause or help with testing?
Why not contribute it to the Cura project and help enhance the program?
Isn’t the goal of Cura to keep the amount of options low and work mainly for the one company’s printers?
My goal would be to write something with a lot of Slic3r features but closer to Cura speeds and in python. Perl+mono seems to do me no favors.
Cura is an opensource project that works on pretty much every printer. I don’t know what their design philosophy is.
Perl does no one any favors 
@NathanielStenzel Make a good design decision and write it in a compiled language. If you are doing thousands of computations per second a pseudo-compiled language like Python is not the ideal choice. Design the algorithms correctly and you can implement them easily in C or C++ and benefit from higher execution speeds.
Cura’s hard-lifting engine is already C++, while the gui is Python. I think that’s a pretty neat approach.
@NathanielStenzel would you be completely forking Cura or simply implementing a new gui?
@Thomas_Sanladerer It introduces an interface layer between the two languages: Python->C++ and back. An engine written using C++ and e.g. Boost libraries with e.g. a WxWidgets GUI eliminates that layer. All intercommunication is native at C++ level (while still being cross-platform) and more efficient.
Yep, avoid interpreted slicers, we have enough of those 
Any compiled language should be first choice, but seriously look to see if existing projects can be built on.
If I was going to reinvent the slicer, I would do an Open Source equivalent of KissSlicer. Add lots of hooks so people can tailor the output instead of MacGyvering things in firmware!
@bob_cousins JIT compiled slicers would be great though. JIT can occasionally be faster than static compilation because of optimizations that can be made on the fly. Interpretation isn’t the problem I think as much as fixing bad models, etc.
And PyPy is a JIT compiled Python. 
Python is faster than you think. Python often has extensions that are easily installed for different operating systems for those tight loop instances. Alot of games use Python for the logic and most of the design.
There is no doubt that Perl (which is used with Mono in Slic3r) is slower than Python.
@Thomas_Sanladerer I am not sure if I would be writing a fork of Cura or a Python copycat of Slic3r. I would most likely try to make it so that some of the code could be dropped into Cura though, when/if Cura wishes to use those features. I have no problem with sharing my toys and I think it could be mutually beneficial to the two projects.
@NathanielStenzel Check out the clipper library, you’ll be needing it.
@NathanielStenzel I would dispute Python being faster than Perl. Many benchmarks exist to support this e.g. http://benchmarksgame.alioth.debian.org/u64q/perl.php and Python3 performance is significantly poorer than Python2.
Nope, Python is slower than YOU think , look at the benchmarks. I give up on this project already!
@bob_cousins , @Neil_Darlow http://attractivechaos.github.io/plb/ - looks like PyPy is significantly faster than Perl. And CPython about on-par according to github’s benchmarks.
It’s still slower than compiled C++ by a factor of 2 to 20, depending on the task.
@Thomas_Sanladerer and can be faster than compiled C code, also depending on the task. Just saying that the language here basically doesn’t/shouldn’t matter. The optimizations that can be made with most languages (such as offloading tight loops to C compiled libraries) mean that it’s probably best to do it in a language that’s familiar, and then optimize later.
I can guarantee you that I would be 20 times slower writing in C or C++ than writing in python. Python is a lot more flexible than C++ for a lot less effort. I would probably shoot myself before setting up a slicer in C++. I hate linkers too.
Ok, so that settles that. I’ll always prefer having a feature taking some time to process than not having that feature at all.