Saturday, December 12, 2015

The blog has been moved

I was overwhelmed when I came to know that three totally different services which I love
share none but a common name. It was then I came to know about Ghost. I always wanted to move out from blogger and the main reason for that was my love for Markdown. Ghost looked promising (and it surely is awesome!). Launching a quick instance of Ghost on my server was easy. I now useopenshift for a lots of reasons. I'll surely miss blogger, because it was one of my earliest experiences of blogging. I used to write poetry at that time. And now I write code. That's why I find great future in Ghost. Looking forward to this !
Happy coding !

Update: I use medium as the platform now.

Monday, November 23, 2015

What I do when I'm bored from studying (or not studying) for the exams?

The semester is about to end and I have no clue of what is going in the end semester examinations. I have been studying good amount of ugly Mathematics but that's okay. I usually lose my temper studying my other subjects Environmental Science, Biology and Economics. Really? For how long will I have to study "everything". Sigh.

So, I either eat or surf when I'm not studying. That's pretty much of it. I received an email from the Central Library of my college that a book which I had issued very long time ago (and never read, of course) has been over due and I will have to pay fine in case of further delay. Aargh! I had to do it first thing in the morning! I was wired in to my laptop. I didn't want to get up and set the alarm in my phone or even on Google now. I wanted it right from my terminal. I wasted another half an hour finding such a thing but couldn't find the one I was exactly looking for. (Duh! I could have set the alarm by then.). So, after some research and a lot of motivation, I created a repository on github and started my work. I had no idea how was I going to tackle command line executions, Natural Language Processing or anything but I had to make one thing possible.

 $ ping-me to go to library tomorrow morning  

This one line terminal(English?) command should set the reminder for me on all of my personal devices. Peace! :)

I've shared the code here - https://github.com/OrkoHunter/ping-me

I haven't written the engine write now. I have bookmarked a lot a sites related to NLP. I'll continue with them in December.

My second toy project in the meantime came out to be keep. I usually don't remember shell commands but I need them the most in ssh sessions. I'm also sick of googling for the same code everytime, I needed to store them somewhere in the computer, using the terminal only...And Ta-da! It's working! https://github.com/OrkoHunter/keep

Oh, and yes, I used python for all of the things above.

Happy Coding !

Sunday, July 5, 2015

GSoC '15 : Midterm Report

One milestone is covered, I passed the midterm evaluation!

NetworkX-Metis is all set to be released on pypi. I had some really good time setting up the tests. I realized that many of the repositories are running their tests only on the local code. If there is some detour in the installation process, one should run their tests from the installed directory navigating inside the egg of the package.

It feels good to have a complete package running successfully in a month. Looking forward to write NetworkX-Lemon from scratch. It will involve a deeper understanding of C++ and Cython.

Looking forward to the challenge ahead.

Meanwhile I've found out something about Python 2's lists. They can "leak" local variables into global namespace. Must check this out. I found it very interesting.

Happy Coding!

Saturday, June 20, 2015

GSoC '15 Progress: Second Report

Past couple weeks had been fun! Learnt many new and interesting things about Python.

The modified source code of METIS has got in, followed by its Cython wrappers. Thanks again to Yingchong Situ for all his legacy work. Nevertheless, things were not smooth and there were lots of hiccups and things to learn.

One of the modules in the package was named types which was being imported by absolute import. Unknown of the fact that types is also a built-in module of python, the situation was a mystery for me. Thanks to iPython which told me this
In [2]: types                                                           
Out[2]: <module 'types' from '/usr/lib/python2.7/types.pyc'>            


This alerted me for all the difference, pros and cons of absolute and relative import. Now one may ask (Does anyone read these blog posts?) why didn't I go with the following at the very first place.


In [3]: from . import types


Actually networkx-metis is supposed to be installed as a namespace package in networkx, and the presence of __init__.py is prohibited in a namespace package. Hence from . import types would raise a Relative import from a non-package error.

We are now following the Google's style guide for Python[1].

Being licensed under Apache License Version 2, we also had to issue a file named NOTICE clearly stating the modifications we did to the library networkx-metis is a derivative work of.

Next important items in my TODO list are
  • Finalizing everything according for namespace packaging
  • Setting up Travis CI
  • Hosting docs over readthedocs.org
That's all for now.

Happy Coding!

[1] https://google-styleguide.googlecode.com/svn/trunk/pyguide.html

Tuesday, June 2, 2015

GSoC '15 Progress : First report


We are past the community bonding period and are in the second week of the coding period. My experience has been very good till now!

I started working on building python wrappers around METIS library which is written in C for graph partitioning. It is extremely fast and the feature was not present in NetworkX because of the problem being categorized as NP-hard so, it needs a lot of approximations to make and Python isn't so good at speed either. A big part of this work was already done by my mentor Yingchong Situ last year. However there were some hiccups :

METIS is licensed under Apache License Version 2.0, nevertheless it uses some of the code licensed under GNU Lesser General Public License. NetworkX has a BSD license. And the work is supposed to be hosted under NetworkX umbrella and shipped as an add-on named networkx-metis. So, a big problem was, what should be the appropriate license for this add-on. We had pretty interesting discussions over it with Aric, Dan and other NetworkX developers and finally decided to remove the LGPL dependencies out from the source code and go with Apache. This took up some changes. I had to replace a couple C files which were making use of qsort with a C++ file using std::sort. In this process I came to learn about extern "C" which is a method to export correct ABI to the library using it. So extern "C" makes a function-name in C++ have 'C' linkage so that client C can make use of the function using a C compatible header file that contains just the declaration of the function.
I also came to learn about how good are C macros while writing functions with undetermined data type or such.

I got my first PR merged! Next is with the wrappers. After it and the setup requirements, I think the add-on will be ready to go.

That's all for now.

Happy coding!

Monday, June 1, 2015

Just a blog : A quick guide to git and GitHub (Part 2)

So, now we are going to take a step further. In this post, we'll deal with one of the most important concepts of distributed collaboration, branching. Also, we will learn about contributing to real world open source libraries. Several concepts are involved in it. I'll try to deal with the most relevant ones.

Also this time, I'll try to explain things, in better way.

Branching : There's a mantra, branch early and branch often. Branches are used to develop new features, simultaneously but isolated. Suppose you are at one point of time in your commit history. A new idea came to your mind about your project and you want to implement it. Let's name the new feature feature_x. Now why do we need branching? Why not implement it right through? What's up with the master? What is that?

master is the one branch your project works on when you initialize a git repository. It's by default, the mainstream. Now suppose you start adding your new feature right in the master, and at one point of time your realize you want to implement a new feature feauture_y. Obviously you'll have to stop one of your work to proceed on another. And this new feature might have bugs or you need to add tests. You might also want it to be reviewed. You'll have to wait for the review. At some point you might come to know that this new feature is totally screwed and you want to go back, where you had started. But you'll realize that you've also made some commits on the other feature you were working simultaneously. At any point of time, you could give up on your project! And that is unfortunate because you forgot the mantra. Branch! Branch! and Branch!

Okay, back in time. We have a new feature, feature_x. You do this
 $ git branch feature_x  
 $ git checkout feature_x  
The first command will create a new branch feature_x and the second command will take you away from master. This means that your next commit will not affect your master. Cheers! You've got freedom. That's what git is for.
The above two lines of code can also be combined into one piece.
 $ git checkout -b feature_x  
This creates the branch and moves you to it simultaneously.

You can check which branch you are currently on by
 $ git branch  
 * feature_x  
   master  
* denotes that you are on feature_x. But still, this branch won't be visible on github, unless until you push it by
 $ git push origin feature_x  
Okay now, it's add, commit and push time! The commit you made has taken your feature_x branch one step ahead than master. If you think your new feature is ready, It's time to merge. Checkout to your master and merge your new branch into it.
 $ git checkout master  
 $ git merge feature_x  
You can check the log now (git log) which has been updated with your new feature.

After your work is done, you can delete the branch locally by
 $ git branch -d feature_x  
and over the github repository by
 $ git push origin :feature_x  

Fork : Now we are going to make a contribution to an open source library. I choose networkx. It's a python package for the creation, manipulation and study of the structure, dynamics and functions of complex networks.
Go to https://github.com/networkx/networkx. On the right top, you'll see three buttons, Watch, Star and Fork.
Watch means you'll get notification for all the activities on the repository.
Star is just a feature of Github to Star a project like you upvote an answer on Quora.
Fork lets you own a copy of the code under your username.

So, after you fork the repo, you can see the exact same package over https://github.com/<username>/networkx. Pretty cool huh!

Clone the forked repository over your computer. Make a new feature branch. Add commit. Push the branch over github. DO NOT merge the branch in your master. Because your master should not be controlled by you but should be in sync with the official source code repository.

After you push the changes with git push origin feature_x, over your https://github.com/<username>/networkx you will find an option to 'Compare & Pull Request'













This option lets you compare the changes you are going to make over the original networkx repository. This will create a Pull Request.
























A pull request is a method of submitting your contributions. The PR is reviewed, analyzed, discussed and then can be either merged or closed. So, go on. Choose a project and get your first PR merged. And once again, do not forget to make a branch.

Dealing with upstream: Your local repository often gets outdated because of the active changes in the official repository. There's a method to update it whenever you want. And you must update your master, before you make a new branch!
To add networkx/networkx as an upstream, do
 $ git remote add upstream https://github.com/networkx/networkx  

So now, whenever you have to update your local master branch, do this
 $ git fetch upstream  
 $ git merge upstream/master  
To update your github repo, do
 $ git push origin  

Welcome to the open source world!

Happy coding!

Sunday, May 31, 2015

Just a blog : A quick guide to git and GitHub (Part 1)

There is plethora of git guides over internet, some are really good and some really suck. I here am writing a simple blog for the newbies who have successfully made an account over github and are really excited about it.

GitHub is a web-based Git repository hosting service, which offers all of the distributed revision control and source code management(SCM) functionality of Git as well as adding its own features. Unlike Git, which is strictly a command-line tool, GitHub provides a web-based graphical interface and desktop as well as mobile integration

Or simply

Github connects you with other people who are interested in sharing and creating together.

So there are really two ways to begin with. Here goes the first one.

Create a repository : Repository is what you call the bundle or stuff you are going to upload and work on. Go to https://github.com/new and create a repository. Let's name it hello-world.
Add some description, or you might want to add it later. Initialize it with a Readme. It's a good practice and let's you clone it immediately. (Yeah right, see below)

Clone it : Open your console, move to the directory where you want to work and do this.
 $ git clone https://github.com/username/hello-world.git
This will create a directory in your computer. Now, this isn't a simple directory. It is a 'clone' of the github repository. You can say that the files in it are controlled by the version control system git and tracked with the repository on github.

Do this,
 $ cd hello-world  
 $ git remote -v  
 origin    https://github.com/<username>/hello-world.git (fetch)  
 origin    https://github.com/<username>/hello-world.git (push)  
This shows that the link to repository of yours at github is known by the name origin over here.

Now another way of this is first you create the directory on your computer. Navigate inside it and do
 $ git init  
This will initialize an empty git repository inside it. Later, you can add the link to the repository by the git remote command like this
 $ git remote add origin https://github.com/<username>/hello-world  
You can always use git remote -v command to track the aliases.

Making the first change : Okay now we are in condition of adding some files or code to this repository. I am going to make a python file with hello world program and publish the change over the github repository too.
So make a new file say hello.py inside the directory, open it with your favorite editor and write the one line code to print whatever you want. Why just hello world? (Because dmr did it!) Now write it and save the file.

The first thing you should always do is to see whether you have done any changes or not in the repository. This can be done by
 $ git status  
After the changes you made, you must be getting this after git status
 On branch master   
  Your branch is up-to-date with 'origin/master'.   
  Untracked files:   
  (use "git add <file>..." to include in what will be committed)   
    hello.py   
  nothing added to commit but untracked files present (use "git add" to track)   
Add, Commit, Push! : In your console, do this.
 $ git add .  
This adds all the files in the track which you have changed.
Now it's time to commit that change. By committing, git understands that you want the change to be in record. Every commit is accompanied with a message that appears on the log (git log) Do this
 $ git commit -m "Added hello.py"  
You've made your first commit! But it won't be appearing over github, because you made the changes locally. You need to push it over the web. For that, you use
 $ git push  
Or,
 $ git push origin  
to say git where actually you are pushing it to. Or,
 $ git push origin master  
to say git over what branch on origin you are pushing it to.

That's it! You've published your changes to your GitHub repository.

NOTE : This is a very basic start. There are more concepts to be explored. You can search for specifics. StackOverflow has also great resource. This is one of those posts, which are not intended to bring the dark side of git to the face.

Happy Coding!