Re: [brlcad-devel] Usability notes + BRL-CAD interfaces (java, python ?)

[Csaba N. <nc...@ja...>]

Hi Bryan,

(will only answer partially now, lack of time)

> >  * specify a custom installation directory for the wrapped brl-cad
> > libraries (possibly passed as parameter to the setup script);
> 
> Have you considered virtualenv and virtualenvwrapper? I don't think
> this is inside scope for a BRLCAD wrapper; there are a bunch of
> up-the-chain abstractions in python for package management stuff.

Well I'm kind of ignorant regarding the plethora of python libraries,
but from a quick google I can't really see how virtualenv will help me
to easily tell the setup script that my brl-cad is installed in a
non-standard place in my home directory ? Or, as I have it, not
installed at all but I just use the compiled version directly from the
build directory ?

> >  * add libged to the wrapped library list;
> 
> There are a bunch of dependency issues that I ran into when I added
> libged to the default list of modules to pythonize in the
> bootstrapping script. I am confident that they are solvable, but I
> haven't solved them yet. The post-install script is really gnarly at
> the moment and could use some generic refactoring, like making the
> number of variables for tracking paths to be, uh, less.

Hmm, it's true I only tried to load the libged module and not really use
it, but that worked for me without problems, once I added "ged" to the
list of module names and "bu", "bn", "wdb", "rt" as dependencies...

> >  * add higher level python classes to experiment with a somewhat
> > different approach of building geometry, where structure and positioning
> > are separated as concepts: geometry is described only using structure
> > parameters (lengths, radii, angles - no points in space !) and
> > positioning is described by resolving constraints between objects (or
> > between well defined points on them);
> 
> I agree with everything here, except for the resolving constraints
> aspect; there's a module in brlcad somewhere for constraints and it
> either isn't working or doesn't completely exist. I would definitely
> prefer that constraint solving be delegated to the actual brlcad
> engine stuff.

Sure, that should finally go to C code, but prototyping in python is
much faster as long as you don't know yet what you're exactly looking
for, and that's currently my case, I'm still experimenting.

The constraint code in BRL-CAD is BTW definitely not what I'm looking
for. Once I have something which actually makes (somewhat) sense, I'll
publish it...

> >  * thoughts about writing the python equivalent of mged, where python
> > replaces tcl - in my opinion that would really boost geometry scripting;
> 
> Sounds good to me; but small caveat, it looks like the built libraries
> will still have tcl in them even in the case of a python interpreter
> for scripting up geometry. I think long-term the plan is to remove tcl
> dependencies from the core library but don't quote me on it.

OK, here I would gladly help out removing TCL dependencies from the
libged code. In fact raytrace.h starts with including tcl.h, which means
that's the first place to start ! I had a short search for occurences of
"tcl" in raytrace.h, there are a few places and probably needs some
discussion about how to refactor it.


> git clone https://github.com/kanzure/python-brlcad

OK, cloned, but if I update with my changes, how do I get them to you,
via patches ?


Cheers,
Csaba