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