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.
- Learnt to deal with PyBindGen. A nice tool to wrap c++ code for python library.
- Implemented small dummy c and c++ code.
- Couldnot run the automated script because of some issues dont know why they are errupting. Apparently a symbol "config_t" is not available in the module.
File "<input>", line 1, in <module> File "/home/raj/.local/lib/python2.7/site-packages/pybindgen/gccxmlparser.py", line 598, in parse pygen_classifier, gccxml_options) File "/home/raj/.local/lib/python2.7/site-packages/pybindgen/gccxmlparser.py", line 693, in parse_init self.gccxml_config = parser.config_t(**gccxml_options)
AttributeError: 'module' object has no attribute 'config_t' July 24
- Relooked at PyBindGen code. It seems good. I think we can either develop this tool further (if it fails to work as it is currently)
- Also looked at how we can solve this.
- Looked at various dependencies like gccxml and pygccxml and saw there version numbers.
- Apparently the config_t symbol was deperecated.
- Changed this and in the PyBindGen. Reported the bug in thier issue tracker. Personally contacted the author who is traveling and will change it later.
- created a dummy example of the code and it works fine. https://github.com/raj12lnm/TryPyBindGen
Summary : Have the ability to parse a C++ header and create a wrapped library for it. Next I will move to wrapping the Giant .. the OpenNurbsLibrary in Python. :D
- wrote a c++ example in the pybindgen example. Looks like this is working fine.
- Tried parsing C++ header of OpenNurbs using pybindgen.
- looks like there is some issue here.
- The issue currently is as follows.
There are multiple symbols in different headers and gccxml is not able to gather information regarding the ones which depend on each other. For example the paste here http://tny.cz/8008c460 tells us how when parsing a file has given issues.