Hi Vishnu,
About the question for writing your graph lib ether in full Ruby or in C++,
I think it would be more effective to write a wrapper around an existing
well maintained graph library.
Last year I suggested for GSOC to write a wrapper around the Lemon graph
library (
http://lemon.cs.elte.hu/pub/tutorial/index.html).
Here is some extract:
2014-02-07 Maurice Diamantini <
maurice.d...@ensta-paristech.fr>:
> The Lemon C++ graph library is a good candidat as a target library test
> because it has a clean c++ interface, it is a référence Graph library
> and it provide a general MIP (Mixte Linear Programming) independant
> interface to various other solver (CPLEX, glpk, ...).
> It is well maintained and is integration int the COIN-OR set of
> tools is a gage of quality.
> Such a binding would be a great advanced for the Operation Research
> and Combinatorial Optimization Ruby community.
The main difference between the Lemon graph library et the BGL is that
Lemon is (now) part of the COIN-OR meta-project while BGL is (now) part
of the BOOST C++ meta-project.
Difference between BOOST and COIN-OR??
--------------------------------------
Note: this opinion is from someone that doesn't know very much about c++
(although I've written some basic tools for, or code with it).
So you can guess that I am a little biased!
- BOOST is a Library designed for c++ programmers.
There is a cleverlibrary for smartpointer, a cleverlibrary for regexp
(well, ok it's now in the c++-std), and probably a cleverlibrary for writing
loop, closures,... (Vishnu, do you want to spend your GSOC to learn how to cleanly
write a loop in boost to be able to write a clean BGL wrapper? ;-)
It append that there are c++ programmers that also have some more time to do
science. So BOOST also contains some library useful for scientific (with c++
with programming) BGL is one of them.
- COIN-OR is a collection of optimization libraries (written in c++).
There is in particular CLP/CBC mixte linear programming solver and
the Lemon graph library.
A Ruby binding for the Lemon library could open the COIN world to the Ruby
community.
In a first step you could ignore the Linear Programming Interface from Lemon
to be sure to finish the graph binding.
Note that I don't think that a BGL binding would be a bad idea, but I think it
is not a Ruby GSOC project, but more a full Boost permanent user project.
Even if you get this GSOC about a new graph library and even if it success,
it is quite possible that 4 years later, somebody ask "why not making a graph
Library?".
Why not to build your one full Ruby graph library?
--------------------------------------------------
Think to the "Yet Another Javascript Plotting Library" symptom.
To avoid that, a true, well maintained gnuplot (or other) library (as the
current proposal) would be a must to have.
A little Graph library is easy to do. A good graph library is not a simple task.
But a good reference durable graph Library need reflexion.
An old full Ruby Graph Library (Rgl) seems to be reborn as:
https://github.com/monora/rgl
But it has not even been mentionned in this thread (I think).
So if you want to do a durable Graph Library, either get all the full ruby graphs
library, and group (or copy) them together somewhere as sub projects under
`
https://github.com/SciRuby/graphs` directory. So you can try to build some union of
there functionality's;
or you can start a new project based on some reference c++ library (then I whould vote
for lemon instead of BGL).
One a binding with the c++ graph library is finished, it is alway possible to
make a more rubyish shell above, without loss of performance. It will be also
possible to add conversion between other graphical gem if needed (graphiz, ...).
regard,
-- Maurice