[Bf-python] Remote IPython & PyCrust Shell for Blender

Thu Mar 27 10:50:45 CET 2008

Hi Stephen,

Thanks for your answer!

On Wed, 2008-03-26 at 07:48 -0400, Stephen Swaney wrote:
> On Wed, Mar 26, 2008 at 03:14:56PM +0900, Dietrich Bollmann wrote:
> 
> > Could you detail what you mean by a "clean patch" ?
> 
> In your own words:
> 
>   "Sorry ... I initially wrote the command port for myself and didn't
>   intend to publish the code.  So some changes and experiments which
>   are not really essential for the command port itself ended up in the
>   code."

Thank you for the citation :)

I wrote this out of a feeling and in order to start with something
friendly because I know how difficult it is to integrate a big
patch...

Before publishing my patch I removed everything which is not used by
the command port but left those things which are nice to have even if
not essential for the core functionality.

So I really would appreciate some more detailed advices about what you
want me to leave and what should be changed or eliminated.

On Wed, 2008-03-26 at 07:48 -0400, Stephen Swaney wrote:
> A patch should deal with a single feature.  No need to re-write
> Blender all at once.

The problem is that every part depends on all the others.  If I remove
one of them, those remaining do not work anymore.

It took me a long time to write the command port and as I am currently
quite busy with other projects I thought it would be wiser to make
changes to the published version only if they really are necessary.

Personally I am happy with the current state of the command port. 
It is therefore difficult for me to understand what you want me to
change and what you would prefer to leave as it is.

A command port is complex and it will always be a huge patch.  That
is why I think that it would be much easier for everybody if it could
be made a subversion branch.  Even when removing the option parsing
code and the debugging functions which are not essential but make the
command port much nicer to use the patch will not be much smaller.

> The comments I made on this patch last August still apply:
> 
>   From a quick glance, it looks like there is a lot going on in
>   this patch:
> 
>   - command arg processing refactor

I did this because I found blenders option parsing code confusing and
felt that it would be easier to implement some better option parsing
functionality than to manipulate the existing blender option parsing
routines.

Here some ideas about how I could proceed:

  - I could write a simple patch which starts to move the blender
    option parsing code to GNU getopt().

    To me this looks like the best way to proceed.  I could first only
    move the help option to GNU getopt() to get your opinion.  This
    would be a small patch.  If people are happy I could write more
    patches moving the existing options one by one to GNU getopt() in
    order to only produce small patches which would be easy to read
    and to test.

  - I could write a patch which only contains my own option parsing code
    which is part of the blender patch.

    I thing GNU getopt() would be a better option as it goes with the
    current "best practise" in the c developer community and would
    make it easy to profit from further development of the GNU
    getopt() library.

    On the other side the option parsing code makes blender
    independent from the getopt library.  This might be seen as
    something good by some people.  I personally prefer to use other
    peoples efforts if they are good and open source.

  - I could just try to use the existing blender option parsing code
    for the command port and leave its refactoring to somebody else
    in the future.

    Sad as others would face the same problem when trying to
    integrate a new option.

>   - a debug facility

The debug facility is only used by the command port functions.
I added them at 

  - source/blender/blenkernel/intern/debug.c
  - source/blender/include/UTL_debug.h

as I thought they might be helpful for others also.

I could:

  - write a patch with only these functions to have a small patch
    which is easy to understand and to integrate.

  - put the functions to some other place like
    source/blender/commandport/utilities/include/debug.h
    source/blender/commandport/utilities/src/debug.c

  - use some uglier options like 
    --debug-bcp      for   -d bcp:1  /  --debug bcp:1
    --debug-bcp-v    for   -d bcp:2  /  --debug bcp:2
    --debug-bcp-vv   for   -d bcp:3  /  --debug bcp:3
    --debug-bcp-vvv  for   -d bcp:4  /  --debug bcp:4

    I do not see why this would be better though.

    The nice thing about my debug option is that it could
    also be used by other modules:
    blender --debug | -d <modA>[:<levelA>],<modB>[:<levelB>],...
    example: blender -d bcp:3,opt,anothermodule:2
    for debugging the commond port on level 3,
    the option parsing code at level 1 (default) and
    `anothermodule' at level 2

>   - the command port

...this part probably shouldn't be removed :)

>   - re-implementation of some standard C functions like isdigit.

> There is no reason to re-implement standard C functions like
> isdigit() even if you give them different names.

four lines out of 12,000.

This was a mistake, sorry.  I am used to switch between about 10
programming languages all the time and don't remember always which
things are implemented in which language.

By the way, the correction of this mistake would take 2 minutes when
using a command port subversion branch and at least 3 hours when I
would have to make it a new patch.

If you could give me a list of the functions you want to have changed
- those which match the sentence "re-implementation of some standard C
functions like isdigit" - I am happy to change them all.

> > Is it possible to create a subversion branch in the blender
repository
> > where I could move the patch to?
> 
> We have been cautious about creating branches except for approved 
> projects.  Whether this is good or bad is a discussion for another
> place.  

In your first review you wrote:

> Something this large might be better done as an svn branch.

and I was happy to hear about this opportunity.

My ideal would be a sandbox where everybody could make his own branch
just for playing around with the sources independent of any concerns of
usefulness.

I recently started to use darcs for my own projects.  Every checked
out copy of a darcs repository becomes a new repository and it is very
easy to make changes, merge them with other versions, generate a patch
to send back after a couple of changes etc.  This makes it very easy
to work in a large distributed group of developers, to allow everybody
to use a personal configured version which can still be updated easily
and to protect the "official" trunk at the same time from changes
which are not appreciated by the main developers.

Subversion on the other side is annoying and demotivating for
everybody who has not the right to commit.

Ok - no further discussion about this topic here, sorry :)

> Right now, best course of action is as  Willian suggested:
> 
> > > Anyway, the main issue now (as usual) is the upcoming events
refactor in 
> > > Blender. It would be wiser to wait a little more before coding
anything 
> > > non trivial, because things will change considerably and we have
chance 
> > > to come up with better / cleaner ways to interface with Blender
data.
> > 
> > > For now I suggest you guys directly interested in scripting
Blender via 
> > > external apps to create a basic plan, detailing what you need to
have, 
> > > preferred methods (sockets, simple signals, etc.). A page in our
bpython 
> > > dev section in the wiki would be ideal for this, but as a start
one of 
> > > you could write something here and the others could add to it,
then we 
> > > put the results in the wiki.

You can find my statement on the page I used to introduce the command
port: http://formgames.org/blender/command-port/

Unfortunately I currently do not have the time to start over from the
beginning again.

I also think that it is much easyer to start with those things already
existing and to integrate peoples whishes than to do everything from
scratch once again.

So please let me know more precisely how to proceed.  I would be most
happy to help to make blender an even nicer tool and would find it
very rewarding to see other people using my contributions :)

So how about starting with something simple like: Write a little patch
which does...  You could start with one of the options mentioned
above.

Thanks for your help, Dietrich