On Tue, Jun 25, 2013 at 7:19 AM, Campbell Barton <[email protected]>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 [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
