On Thu, Jun 27, 2013 at 4:20 AM, David Jeske <[email protected]> wrote: > On Wed, Jun 26, 2013 at 4:56 AM, Campbell Barton <[email protected]>wrote: > >> This seems like admitting defeat before identifying the problem, >> as if you say --- "Blender crashes for me therefor you should use a >> new language" >> > > I fear my wordy detail is confusing my message. What I'm trying to say is.. > > "I wish more blender code for UI and new features could have zero delay, > zero work, zero build-setup between a casual user-dev like me seeing a > (small) problem in the UI or a new feature, and doing an > edit/compile/run/patch cycle." > > ....This way, all of the limited time I have to touch blender code could be > spent trying to actually fix code, instead of the current situation of > spending 1-4 hours wrangling the current build just to spend 1-4 hours > making patches to fix a couple bugs. Or not even starting because I know > this is what I'm in for. The more eyeballs fixing bugs the better. > > This is where the slippery slope of my thought began, and it went like > this... > > - I don't think we can make the C build instant to setup and included with > blender... > - so to get there would require more code to be written in an extension > language that blender can compile/run itself (like Python). > - Except I don't think more of blender should be pushed into Python... > because it's slow. and because code with no types is hard to read and > understand, and without compile-time type-checking, harder for non-authors > to change without fear of breaking something. Casual coding in a foreign > codebase without types and type-aware-completion is also much harder. > - So it would be great to have an extension language that didn't have these > problems. Something as fast as possible, that has static types, > type-aware-completion, type-checking, and where the compiler and build > context can be cheaply built right into blender. > > What language systems can do that? Hmm.. well. There is Mono/C#/Boo, and > there is TypeScript/V8. And maybe Google Dalvik/Java, though probably not > the JVM. Hmm.. might be an interesting idea to integrate one of these. The > graph editor, outliner, property panels, movie clip editor, masking and > tracking, video sequence editor -- tons of the UI could be written in one > of these languages without affecting blender performance much, making all > that code more accessible to more devs. The more eyeballs fixing bugs the > better. I wonder what other people might think of this idea. > > I'm not expecting that to necessarily sell you, but I hope it is a clearer > explanation of my thinking. > > >> Read through your other comments, reasonable points but I would want >> to be convinced the errors you hint at _can't_ be fixed first. >> > > Of COURSE they can be fixed! Any code can be fixed, in any language. This > isn't about a magic language. It is about iteration speed for the > setup/edit/compile/run cycle. The faster than cycle is, the more casual > devs can be roped in to help improve blender -- for however much code is > written in that extension environment. > >> > This evening I followed the steps to setup an OSX / XCode build, hoping >> to >> > fix my list of retina bugs. A couple hours later I have a built-binary, >> but >> > it crashes immediately on launch. I'm too unfamiliar with blender to >> have a >> > clue what is causing it. >> >> Crashes immediately is more likely to be some kind of build error (or >> incompatible libs/environment) then a bug in the code. >> > > Ohh it was totally setup user-error on my part. I'm not saying the blender > build is somehow broken. Obviously there are lots of devs working on > blender, including all the new GSOC folks. > > I spent another thirty minutes retracing my steps. Turns out when it said > to toggle to the "install" target, I did the wrong thing because I don't > know XCode enough to have understood the very-nice screenshot in the doc > the first time through. Now I need to figure out how to source debug, since > the XCode run button doesn't seem to launch blender. > > .... which is all sort of my point. The time between when I thought "darn > it, I'm just going to try to fix this", and when I can actually begin to > dig through the code in this case was 2-3 hours of my time, and 12 hours > wall-clock. > > Plus, I'm a software engineer. I'm impatient and hate setting up builds, > but I'm comfortable working in big foreign builds, and C/C++, with > code-generators, and third-party libs. However, I suspect there are also a > lot of amateur coders/scripters who would spend some time reading through > UI/feature code in C# or TypeScript trying to Code-Monkey out a patch.. > > ....my theory is that reducing that setup overhead to just a few minutes > and using an easy language -- for an interesting subset of non-core blender > code -- would mean a lot more eyeballs helping fix bugs and improve > blender. > > Of course the real book you can throw at me is that I spent more time on > this email discussion than I did setting up the build. :) However, I don't > think that invalidates the argument. Even if nobody is on board with me, I > hope it's interesting food for thought. Now I need to go fix some small > bugs and submit some patches before I get written off as a non-contributor! > > Go Blender!
You've made your point quite well and I see where you're coming from. Personally I feel like we have enough big tasks ahead of us and this would be another really big project - not just up-front but maintaining, bug-fixing, and dealing with complaints when the api breaks. Even if some clever person gets mono integrated in a weekend - this still ends up being many months (years?) of work to properly support. At this stage though this probably needs support from the Blender Foundation. aka "convince Ton its a good idea" :) _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
