WEEK 2&3 : UNPRODUCTIVITY

Okay that meme was exaggerating. But seriously I have been really busy with my work at Hackerrank which went into production this week. I have been a really bad web developer, much worse at managing my time.

Like I said there is not much work that has been done for GSoC, but I still have to keep posting to push myself to work harder and motivate myself. So this is how it went:

The testing framework that I had mentioned in my previous post took off quite well and my corresponding PR is merged. It has only the tests for basic getters and setters. We just plug in values and try to query them. Not a big deal !

No the agenda thereafter(Week 3) is to extend this testing practice for other functions as well. So an example functions that I could test is:

In the C file

If you see, the problem is that it doesn't return anything for us to test. Now the thing here is we send in a Radiation Packet and its storage model, it make modifications and returns nothing. We'd have to check if the parameters of the Packet changed correctly. Now that is a lot of work, I have opened a PR testing just one such function and lets see where it goes.

WEEK 1: ESTABLISHING A TESTING FRAMEWORK !

Okay I accidentally labelled my previous post to be the work of week 1&2 which was supposed to be the community bonding.

SUMMARY(for you lazy fucks out there :P)

• Zeroed to one testing framework which is super awesome - "ctypes". Smooth and sexy.
• Way ahead(by 2 weeks) of timeline. Take a look at my proposal.
• Looking forward to completing the main project in 3 weeks from now and then help with the plasma project and the fitting project.

LONG STORY

As I had mentioned in my previous blogpost I have restructured the C files and the mentor liked it. Early of this week it got merged. Now the task was to test the C files so that the can be called from the root of TARDIS with python setup.py test.

So basically the idea was to be able to call the C functions in python and test them. This isn't a good idea because it involves rewriting all the functions with wrappers in cython or some such glue and then again test. OVERKILL !

OR we could write the tests in C and then write wrappers for them in python. This is okay, because you have a standalone C library for Montecarlo and also callable from python.

But I ended up doing something much better. I found this amazing library in python called ctypes. I knew it earlier but just din't realise how powerful it was until I incorporated it in this amazing way. Checkout my pull request.

What it lets you do is, you can basically use any compiled C library(.so files and etc) as DLLs into python and use their modules. All this with one single line.

from ctypes import CDLL

tests = CDLL(test_path)

tests.test_rpacket_get_nu(double_value)

So this will run the function test_rpacket_get_nu in a C file(library) located at the test path.
The C function look somewhat like this:

bool test_rpacket_get_nu(double value){ rpacket_t * rp = (rpacket_t *) malloc(sizeof(rpacket_t)); rpacket_set_nu(rp, value); if( value != rpacket_get_nu(rp) ){ return false; } return true; }

So I have written the tests for Montecarlo as I would have written for any C library and then called all those functions from python.

In this PR I tested several simple getters and setters using this method. I hope to get my pull request merged in a day or two(if I stop blogging and start coding :P) and then work on with other functions which are not so easy to test(even in pure C) All in all Montecarlo testing should be done in a week and a half or so.