Difference between revisions of "User:Krajkreddy/GSOC14/summary"

From BRL-CAD
Line 186: Line 186:
 
***mkdir build
 
***mkdir build
 
***python setup build
 
***python setup build
*Currently build will be successful but not correct, some symbols will be mismatched,
+
*Currently build will be successful but not correct, some symbols will be mismatched.
 +
'''''July 29 (Tuesday)
 +
* Continued to work on the error using breakpoints and manual code outputs. But failed to find the part of the header file which is producing this error.

Revision as of 15:41, 29 July 2014

GSOC 14 Summary

Week1

This week I am scheduled to implement the following

  • ARS
  • SUPERELL
  • BINUNIF

May 19th

  • I implemented ARS.
  • Also implemented Ctypes Adapter to handle 2D Array

May 20th

  • Initiated witting test for ARS.
  • Stuck in errors.

May 21th

  • Tried with different approaches to handle the array but with little success.

May 22th

  • Took a break off from ARS and implemented HALF runs properly. (tests also compile).

May 23th

  • 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

May 24th

  • 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

Week2

This week's plan is to come in sync with the time line.

May 26

  • Implemented superell.
  • Also made two patches in accordance with the brlcad C repository(main).

May 27

  • 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.

May 28

  • 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.

May 29

  • Implemented Metaball.
  • Though there was an issue with the fastf_t *verts[5], 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.

May 30

  • Started working on EBM.
  • Learned brlcad image-processing tools. (They are quite good :-))
  • Also getting this strange error "test framework quit unexpectedly"

May 31

  • 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.

Week3

June 2

  • Created EBM primitve.
  • Used Ychar image given in the example.
  • works well

June 3

  • 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.

June 4

  • Was away most of the day.
  • Accommodated changes suggested by Csaba.

June 5

  • 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.

June 6

  • Spent my time figuring out issue with bot.

June 7

  • Added bot primitive.
  • The current version only creates a bot with plate mode.

Week4

June 9

  • 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.

June 10

  • 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.

June 11

  • 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)

Week5

June 17

  • Corrected ARS api to make it python friendly. The changed api only requires curve information.
  • Modified ctypes array2d to make it more robust.

June 18

  • Started implementing pnts.
  • Pnts has different parts, thus implementing them using different classes.
  • Spent my time archetecting the pnts primitive.

June 19

  • 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.

June 20

  • 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.

June 21

  • 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.

Week6

June 23

  • 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.

June 24

  • 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.

June 25

  • Corrected DSP.
  • Also added calloc support to brlcad_new to initialize the allocated memory to 0.

MidTerm Summary

Mid Term Summary is here

Implementation of Brep and OpenNurbs

Quick Summary

  • 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/]

Plan

To wrap the brep/opennurbs code as a python module. And use it in brlcad-python project.

July 21

July 22

  • 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.

July 23

  • 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.

July 25

  • 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

July 26

  • 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.

July 28 (Monday)

  • Found that Pybindgen requires a single header.
  • Instead of automating it, used a frugal way by concating the header files in such a way that the order is topologically sorted in the dependency graph.
  • While Parsing the header using Pybindgen I get an error.
  • There is a bug at which I am stuck http://tny.cz/be8180ca.
  • Since the header file is several lines(>65K) long all, Thus the parsing takes a long time. And the bug is somewhere at the end. All my efforts went in vain today.
  • I have added the repository here https://github.com/raj12lnm/OpenNurbs-Python
  • Currently build will be successful but not correct, some symbols will be mismatched.

July 29 (Tuesday)

  • Continued to work on the error using breakpoints and manual code outputs. But failed to find the part of the header file which is producing this error.