On Mon, Dec 23, 2013 at 3:15 PM, Csaba Nagy <[email protected]> wrote: > I played around some with the python-brlcad project, good work !
Thank you. There's still a lot of work to do to get it to the quality that most python users expect of their libraries. There are a bunch of abstractions around CAD modeling that are not present in python-brlcad, mostly because I haven't been able to fathom the correct simplified models yet. There should, at the very least, be generic primitives that have generic intersection/union/other set operations available, and they should probably share the same subclasses that, somehow, resolve to the current symbols that python-brlcad exposes. > I have a few additions and some topics to discuss, I wonder where (what > forum) and in what form would be the best to go ahead ? I prefer this mailing list for discussion (until Christopher kicks us out :-)), and the python-brlcad issue tracker for specific bug reports. > * 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. > * 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. > * 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. > * 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. > I didn't check out yet the git sources, but if that's necessary for > sharing code, I will do - just that I have absolutely no experience with > git, so not sure how this process works. Welp, best way to start is to clone the repository and dive in: git clone https://github.com/kanzure/python-brlcad You might be interested in trying git out here (note that it's an interactive tutorial, and at the top it has instructions for the next command to investigate): http://try.github.io/ - Bryan http://heybryan.org/ 1 512 203 0507 ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
