[Bf-committers] introduction

[Campbell Barton]

Hi Ian,

* re: compiler warnings, I compile with CMake on linux which uses:
 -Wall -Wno-char-subscripts -Wpointer-arith -Wcast-align
-Wdeclaration-after-statement -Wno-unknown-pragmas
-Wno-char-subscripts

This removes warnings which in my experience can be ignored, a few
times I tried to get blender to build with less warnings (when
omitting some of the flags above), but found it mostly useless.
There are libraries like bullet which is really an external project so
we try not to modify its source, and other cases in the game engine
where there is no easy way to fix the warning.
So even if you get 1000's of warnings (with only -Wall for instance),
I have found its not that easy to simply go in and 'fix' many of them.

I've run blenders code through cppcheck, splint, clangs error checker.
We also had coverity run scans on blenders source though that was on
2.4x a while ago.

nevertheless, fix warnings you find when building blender is a fine
place  to start.

* re: memory management.
We have guarded alloc, which can help track leaks based on a string ID
for each alloc, however it could be interesting to replace the
allocator.
AFAIK the only thing which makes this tricky MEM_allocN_len() which
returns the length of allocated memory. this is only used in a few
places so I think its use could be removed and we could swap out
guarded alloc altogether, for testing/benchmarking.

* re: plugin system. really important to get this right for 2.5, have
discussed with Brecht and Ton a little, research in this area is
useful but not sure its a good first project since we need to consider
how the rna api might fit in with texture, sequencer plugins and
possible compositor and shader plugins too.

Of your suggestions I think parallel code is a good place to start if
you have experience with this in previous projects.
You could take some area of blender which is self contained and
optimize it without having to understand lots of different parts of
blender at once.

I haven't used GIT yet though I'd like to try, however I'm not sure
we're developing at a scale where subversion limits us in the way it
would the linux kernel for eg.

- Campbell

On Thu, Jun 3, 2010 at 4:13 PM, Ian Watkins <watkinsig at gmail.com> wrote:
> Hello all,
>
> I imagine everyone is quite busy, so I'll attempt to be brief.
>
> I recently decided to contribute time to an open source project.  I've
> had a passion for movies and an interest in animation for most of my
> life -- so blender seems like the logical place to spend time.  I'm an
> openGL novice -- I know enough to be dangerous, basically, but I've
> been working as a software engineer for the past 8 years.
>
> I've worked in embedded systems for 5 years, where I've written a
> memory allocator, improved the distributed build system, and worked on
> a number of other projects...  I know c, c++, perl, python, java,
> bash/sh shell scripting, autotools, make, and more.
>
> I've been looking for details on what areas need help in blender
> development, but haven't found many details.
>
> Short term, I plan on reducing/eliminating compiler warnings (if they
> exist) -- mainly to start to get an idea of how things work.
>
> Is there a coding style for blender?
>
> As for features/fixes I'd like to explore the following (assuming 2.5
> hasn't addressed these issues -- this is based off of 30 mins of
> playing with 2.45).
>
> * When collapsing tools, have the entire name of the section rendered
> on the vertical bar.
> * More configurable UI -- essentially, allow an area to be dragged out
> of its doc, and placed in a new window (I have a huge 2 monitor setup,
> and it would be nice to be able to have a full screen view of what is
> being worked on, or have 2 views near full screen).
> * plugin system.  pretty sure there isn't much work here, but I'd like
> to be able to load a new plugin while blender is running (alternately,
> update a plugin).  The plugin should provide menu items, tool tips,
> etc. on load and the UI should be updated accordingly.
> * Memory management tools.  Ability to query the allocator about in
> flight data, who allocated it, etc.
> * parallel code.  I have experience with chromium, MPI, threads, and IPC.
>
> Mainly, though, I'm hoping to learn, and hoping that I'll be able to
> teach a little as well.
>
> Lastly, have you guys used git at all?  With the many branches you've
> made for SOC, and the commit policy, I'd think you guys would love
> distributed source code management -- along with the ability to merge
> less painfully.
>
> And I've failed miserably at being brief.  Apologies.
> --
> --Ian
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell