[Bf-committers] Blender roadmap article on code blog

David Jeske davidj at gmail.com
Tue Jun 25 21:14:54 CEST 2013


On Tue, Jun 25, 2013 at 7:19 AM, Campbell Barton <ideasman42 at gmail.com>wrote:

> > 1) Include opt-in usage and automatic crash reporting in *every* blender
>  > build, and a web dashboard to live usage/crash stats to devs and the
> > community.
>


> There is the case where users get crashes and dont report them- so it
> would serve a purpose, but I suspect this would end up being used as
> more of a statistic then something we actually use to fix bugs


My intent is not to create more work for devs, but less work.

Ubiquitious crash reporting is not for devs to crawl through individual
reports, but to create a strategic source of *real* stats about when there
are too many crashes and when things are stable. It's simply applying the
simple mantra of "to improve it, measure it".

For example, my 2.67b crashed 5+ times in <14 hours doing a trivial VFX toy
project. Other than me emailing people, nobody even sees these crash stats.
If I email people, I waste their time with non-reproducable crash
anecdotes. I think an automatic crash report onto a graph would be better
than being blind to the data, or being distracted by the anicdotes.

Also, this kind of tool is incredibly useful when a dev is working on
fixing a bug, because user comments can be searched to see if there is a
pattern. It might also be possible to track the last several operators, or
the time spent in different areas, also to see if there is a pattern.

> 4) Incorporate an extension language which can support Intellisense,
>  > type-checking, and fast execution.
>


> This is really big project and not something a dev is likely to do
> for-fun unless there is a high likely hood its going to be accepted in
> trunk.
>

Agreed. This is why I'm starting with socializing.

Also keep in mind that these new options are really only now becoming
possible. Back when Blender integrated Python, Mono/C# was not great, and
V8 didn't exist. Today Mono is embedded in many notable things, including
Unity. I think TypeScript looks pretty incredible, but it's also very
bleeding edge. (They just released generics/type-parametrics in 0.9 a
couple weeks ago).

We could make the C++ RNA api more generally useful (what cycles is
> currently using),
>

I think I should back up and better explain my motivation. In short, I want
to help more of the blender community turn into blender devs and debuggers.
Setting up a blender build is too big a hurdle. Python isn't used for
enough of blender, and the code which is there is very hard to read,
understand, change because there are no types and there is no compile
typechecking. (though I admit types are not as powerful as tests)

As a result, I'd like to see more blender code written in a
language/environment which is easier to code-in (type-aware-completion),
easier to understand (static typing), unlikely to crash blender
(type-safety), unlikely to do bad things (sandboxing), performs well (fast
execution), and can be debugged/patched without setting up a C blender
build.

These are similar to the motivations which created Open Shading Language,
but that solution is very domain specific.

C++ isn't typesafe and requires setting up the whole blender build to
touch. This is fine for core-development like Cycles or parts of the
blender Core, but not great for rapid development, addons and community
debugging.

Python type-safety is nice, and users can touch it without a blender build
setup. However, not much of blender is written in it!  I don't think this
is mostly because of limitations in the Python API, but because code
without types is fragile and hard to read, and CPython is very very slow
(though PyPy could help).

Really this isn't about providing a language which is more attractive than
Blender Python, but one which is more attractive than Blender-C !

C#/.NET is pretty fantastic in this respect, because it's pretty darn
comfortable for C programmers, moreso even than Java, yet has all the
features above. However, it has some drawbacks, including a fairly large
runtime and "unclear" sandboxing situation.

Google's Javascript V8 engine is small, decently close to Mono performance,
has excellent sandboxing, and with TypeScript can support static typing and
type-aware-completion. I suspect the C-to-V8 data-structure marshaling is
probably slower than C-to-Mono, but it's hard to say for sure.

Since we are already including LLVM it could be interesting to check
> on the status of some LLVM based languages..


Please explain your thinking here. Mono/C# has an LLVM backend. How does a
language targetting LLVM help?

By my view it's the marshalling/API layer which creates the "work" of the
linkage, mapping from dangerous C pointers and datastructures to "typesafe"
APIs and structures.


More information about the Bf-committers mailing list