Hi


At this point, with version 2.63, how hard would it be to create alternative scripting API's in other languages, besides Python?

I just read these forum posts:

http://www.blender.org/forum/viewtopic.php?p=76112
http://www.blender.org/forum/viewtopic.php?p=83168

Would it really be a matter of replacing (copying and modifying) 38,000 lines of C code?

Before immersing oneself into the "tedium" of translating a myriad of Python objects and methods, there is probably some top-level invocation of an alternative interpreter. Which should probably be a relatively easy thing to do set up (?)

In other words, create a development pre-release, pre-alpha version with an added interpreter redirection ( a drop-down box) that switches from Python to, say, Perl. Which causes your code in the text editor to be interpreted by Perl instead of Python.

This would be the tip-switch of a non-existent iceberg, but then, the developers would start filling in the mass of the iceberg, gradually...

What would it take to set up that initial non-working empty API/wrapper/hollow shell of an alternative language API?

How does one go about setting that up?

Thanks

On a historical note, Perl and Python were the original candidates for Blender's scripting language. The Perl guys failed to make their case.

Embedding an interpreter is fairly trivial. The problem is the work that has to be done to support it. There are two main parts to this:

- generating the language bindings
- writing all the glue code.

For the first one, New Blender has its DNA/RNA system which is used to help generate the Python bindings programmatically. This should make it easier to support other languages.

Writing the glue code is not rocket science, but it is a lot of work. An early post mentioned 38,000 lines of Python. There are a lot more now. Particularly since Python is used for major portions of the User Interface.

The Python UI is new complication for embedding another interpreter. At first glance, it suggests a need to integrate the current Python interpreter with the new one.

This isn't meant to be discouraging, but many software projects have grounded on the shoals of Too Much Work. Personally, I'd love to program Blender in Scheme. As fat old commie Mao Tse Tung said, "Let a thousand scripting languages bloom!"

stiv wrote:

On a historical note, Perl and Python were the original candidates for Blender's scripting language. The Perl guys failed to make their case. Embedding an interpreter is fairly trivial. The problem is the work that has to be done to support it. There are two main parts to this: - generating the language bindings - writing all the glue code. For the first one, New Blender has its DNA/RNA system which is used to help generate the Python bindings programmatically. This should make it easier to support other languages. Writing the glue code is not rocket science, but it is a lot of work. An early post mentioned 38,000 lines of Python. There are a lot more now. Particularly since Python is used for major portions of the User Interface. The Python UI is new complication for embedding another interpreter. At first glance, it suggests a need to integrate the current Python interpreter with the new one. This isn't meant to be discouraging, but many software projects have grounded on the shoals of Too Much Work. Personally, I'd love to program Blender in Scheme. As fat old commie Mao Tse Tung said, "Let a thousand scripting languages bloom!"

Thanks for the explanation.

Still, back to my idea of a "hollow", "empty" API ?

The developer version could have a special little box where the error "unknown binding" would show up in red (or something like that)

At the outset, when the iceberg is still hollow, most calls would trigger that error.

Then, gradually, as developers do the conversions and fill in the empty space, fewer and fewer such errors will occur.

How much of the "writing the glue code" that you mention and say is "a lot of work" -- how much of that is the tedium of command by command translation, and how much of it is the initial setup of an empty API shell, where script interpretation is attempted (but mostly fails, at first)?