[Bf-committers] Blender roadmap article on code blog

[Jürgen Herrmann]

Crash reporting might be useful but integrating this in a manner that makes sense might be very intensive work.

You're not really trying to lure us into coding integral parts of blender in python, c# or mono, are you?
A new/additional scripting language might be cool and is definitely something we should think about.

There is a reason why coders always fall back to c/c++, that reason is speed.
Imho Type safety in c++ is not as critical as you present it here.

Ok you could replace some parts of blender with scripted code, but I don't agree with your arguments at all.

/Jürgen

Am 25.06.2013 um 21:14 schrieb David Jeske <davidj at gmail.com>:

> 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.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers