GSOC 14 Summary
This week I am scheduled to implement the following
- I implemented ARS.
- Also implemented Ctypes Adapter to handle 2D Array
- Initiated witting test for ARS.
- Stuck in errors.
- Tried with different approaches to handle the array but with little success.
- Took a break off from ARS and implemented HALF runs properly. (tests also compile).
- Relooked at ARS, dug the C code, found some error and the way ars data should be sent.
- But the error still persists. although corrected my approach for sending data to mk_as
- Corrected the error after a call with Csaba, The error was related to freeing the memory from brlcad-C code and also python code. Hopefully this experience helps me solve future problems
This week's plan is to come in sync with the time line.
- Implemented superell.
- Also made two patches in accordance with the brlcad C repository(main).
- Sent a pull request for the code to be merged.
- Also worked on metaball. Metaball has some internal functions which are to be modified. thus figuring out a way to do it.
- Looked a Pipe primitive of brlcad and its implementation in python. Metaball has similar traits but there are further challenges. The data in metaball doesn't have number of points. Therefore this is tricky.
- Implemented Metaball.
- Though there was an issue with the fastf_t *verts, and I keep getting a very funny error :: expected LP_c_double_Array_5 instance instead of LP_c_double_Array_5
- Therefore for now my implementation works with fastf_t **verts.
- Started working on EBM.
- Learned brlcad image-processing tools. (They are quite good :-))
- Also getting this strange error "test framework quit unexpectedly"
- Some strange behavior with my set-up.
- Re-set up everything.
- finally it turned out that all my executables in the brlcad C repo where 0 sized.
- Created EBM primitve.
- Used Ychar image given in the example.
- works well
- Found a tricky error in BRLCAD C repository. The last argument in mk_metaball()
- Submitted patches #278 on the sf site to correct that.
- Also corrected the metaball implementation and found a better way to terminate the list argument.
- Was away most of the day.
- Accommodated changes suggested by Csaba.
- Implemented Grip.
- Explored Bot and Constraint,
- Constraint need not be implemented for now because its api is not mature.
- Bot is an interesting primitive. Chalked out a way for it.
- Spent my time figuring out issue with bot.
- Added bot primitive.
- The current version only creates a bot with plate mode.
- Started working on a new primitive.
- Apparently found an error in submodel primitive.
- Reported it to the core developers team
- Worked on modularizing the bot primitive.
- Contd. working on BOT.
- Tried different approaches.
- Modularizing a complex primitive as BOT has turned out to be tricky.
- Finally created a module wherein facility of adding faces in a bot is different
- Also each method has a different stub altogether.
- Cleaned the Bot code.
- Wrote few tests cases of different methods. This will also serve as examples
- Also finished working on submodel primitive.
- Created a different file in the resource directory for the tests.
June 12,13,14, 15
- Traveling (informed Csaba)
- Corrected ARS api to make it python friendly. The changed api only requires curve information.
- Modified ctypes array2d to make it more robust.
- Started implementing pnts.
- Pnts has different parts, thus implementing them using different classes.
- Spent my time archetecting the pnts primitive.
- Bryan merged my code and indicated an error in metaball tests
- Halting pnts implementation and focusing on correcting metaball.
- Found a strategy to work such the mk_metaball is not required.
- Also I dont know why BU_LIST_INIT is not wrapped automatically! (Thus implemented it seperately as a ctypes adaptor)
- Now this doesnt require usage of mk_metaball function. Tests run on the current version of brlcad c-repository.
- There are 3 primitives which are left to be wrapped PNTS, BINUNIF and DSP.
- Today I tried to understand the requirements of all three.
- Went through the c code in libwdb (dsp,binunif) and typein(all three).
- I am sure by the end of next week till which the stipulated time finishes I will have finished these primitives.
- Worked on DSP primitive created dsp followed dsp tutorial.
- Got accumulated to the process of dsp creation.
- Understood the v5 method of creation in typein.
- Implemented DSP primitive.
- Used a different approach, because the mk_dsp doesn't have the required parameters
- But it creates a issue while freeing it.
- Tried resolving it but with no success.
- Re-looked at the issue of DSP.
- Used GDB to get the backtrace. Pasted it in the channel. Waiting for reply.
- Also committed the code in a different branch in dsp_primitive.
- Also resolved issues notified by Csaba in the code.
- Corrected DSP.
- Also added calloc support to brlcad_new to initialize the allocated memory to 0.
- Mid Term Summary is here
Implementation of Brep and OpenNurbs
- python-brlcad uses ctypes. Since ctypes can only talk to C functions, We need to provide declaring classes with extern "C". This requires a lot of changes to main repository brlcad. making it clumsy.
- Other options which I have explored to wrap c/c++ code in python are boost library, swig and sip.
- Bryan (kanzure) has done an experiment with swig code for python wrappers. His code is available [here|http://diyhpl.us/~bryan/irc/opennurbs/brlcad-opennurbs2.zip]. This misses some brlcad and doesn't work appropriately.
- Boost library provides a wonderful seamless wrapping. But it requires change in c++ code. It uses a special python header in the c++ code with different wrapping schemes.
- sip is one of the better tool I found to wrap python code. details can be found [here|http://pyqt.sourceforge.net/Docs/sip4/index.html].
- other tool which can parse c++ automatically is clang find the details [here|eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang/]
To wrap the brep/opennurbs code as a python module. And use it in brlcad-python project.
- Played with PyBindGen. This tool is promising in wrapping with C++ code which has inner classes. http://pybindgen.readthedocs.org/en/latest/apiref/
- Since most tools which wrap c++ code doesn't have a automatic parsing of c++ headers like ctype-gencore.
- today I found a parser for c++ headers. https://pypi.python.org/pypi/CppHeaderParser/2.4.3
- With in this week I am planning to write code which generates automatic config files using the c++ headers.