[GSOC] Pranav Garg

[Pranav Garg]

Greetings Everyone!

I hope you all are going great. I would like to thank you all for giving me the opportunity to work under the guidance of experienced developers in SciRuby to create something which can be very beneficial to the scientific computing community.

I am Pranav Garg, currently a third year Electronics Engineering undergraduate student from BITS Pilani, Goa, India. I love exploring Machine Learning & Neuroscience (Theoretical and cognitive) and I hope to integrate them for creation of Neural inspired strong Ai.

As per Adithya's suggestion, I have created this thread so that my progress can be easily tracked by the community. During the summers I will be working on the creation of a Language independent plotting library along with Arafat Khan. I am currently discussing the details for the same with my mentors and I will update everyone soon with a blog post. I hope to be an active developer to the library even after the end of GSoC.

Speaking of blog posts, Here is my first post for the summer . Please let me know your thoughts about the same.

Regards

Pranav Garg

[Prasun Anand]

Great post!

I am reading the discourse discussion thread.
Will add my inputs soon :) .

Prasun

> --
> You received this message because you are subscribed to the Google Groups
> "SciRuby Development" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sciruby-dev...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Sameer Deshmukh]

Thank you for your post, Pranav. Can you also send this post to the sciruby blog?

[Pranav Garg]

Greetings Again!

My Examinations ended today :P !! Although I haven't posted much. I have been constantly in touch with Arafat over the last week about the Architecture of the libraries and we came up with a way to create two independent libraries, that can later be coalesced together as discussed in the Matplotlib thread.

To abstract my aspect of the project in a small paragraph (Will write it in detail in the upcoming blog post):

I will be creating a Library that creates static plots which are saved as images.For which I will be creating the Back-end Layer in GR Framework written in C++ and bridge it to Ruby (will be probably using Swig for it). Then I will create An Artist Layer in Ruby that will consist of all the Important detailed classes.

  I am shifting rooms on 13th and traveling on 14th and 15th. I will start my work on 16th. During the first week of work I will be familiarizing myself GR Framework, Ruby [Why's guide , learn Ruby the hard way and Ruby Under a Microscope (Already Started)], Swig and Matplotlib code-base, while trying to implement the back-end renderer functions. Once I get a better idea about it , I will devise a detailed and updated timeline.

Regards

PG

[Pranav Garg]

Greetings Everyone!

This is the report for 16 May 2018. Today Arafat and I updated the timeline and had discussions over the API. I also began looking into the Candidate for C++ Back-end :The GR Framework. But here is the thing about GR Framework,it is not a Graphics rendering library, rather it is a plotting library(working on an abstraction analogous to  Artist layer in Matplotlib), I tried creating a lineplot similar to the one that I created in Cairograph.

Using GR Framework for a backend would be equivalent to using Matplotlib as a backend. Also since it is in its Beta release, it is missing a lot of important documentation and examples. What can be done however is creation of a Ruby binding to it with the help of its creator, I am mailing him to discuss about about the possibility of the very same.

I am now looking at Cairo to serve as the backend for the static plotting library. Cairo also contains a Ruby Binding (RCairo), but I will be creating the Renderer backend in C++ and create a binding via Swig (To better implement the language independent library in future).

The Code to GR Framework Line graph can be found at https://github.com/pgtgrly/GSOC2018-Sandbox/tree/master/16-05-18

Regards
Pranav Garg

[Prasun Anand]

Pranav, In my opinion, creating a Ruby Wrapper for GR would be the
right way to come up
with an excellent plotting library for the summers. You can write
documentation for GR along the way.
So, please don't explore Cairo.

Sameer, I don't think we should be still be deciding whether to use
CAIRO or GR. Lets pick one for
the summer and stick to it. I vote for GR.


Regards,
Prasun

[Maurice Diamantini]

I also vote for GR!

Regards,
-- Maurice

[Pranav Garg]

Hello Again!

This is the daily broadcast bringing you the GSoC report for 17 May 2018. Today I worked on the following:

1. I Further looked into the GR Framework documentation and source code, The amount of documentation and online resources for the C++ API is proving to be a big hurdle

2. Refreshed my concepts on the Cairo Architecture

3. Created a basic implementation of the Backend Renderer and Figure Canvas in Cairo (https://github.com/pgtgrly/static-rubyplot/commit/85122dec94defb5e49576ebd8b43d778ca879e6d)

The most important aspect in accordance to me, while creating the backend layer was to create functions which are generalized enough that they can be implemented in any plotting library but at the same time provide flexibility. Instead of replicating the MatPlotlib Architecture, I decided to use that as a reference and build upon the same.

On Prasun's suggestion, I wrote a mail to the developer of the GR Framework regarding the possibility of bridging it to Ruby as GR Framework provides an excellent 2D and 3D Plotting Library and is the cross language library that I wanted to implement. GR Framework is already bridged to Julia and Python .Although an excellent suggestion, it would only be feasible if the developer of the GR Framework are able to provide mentor-ship for the same as it is still in development.

Tomorrow I will be Reading up on various methods to create bindings to Ruby as well as create a SWIG binding to the basic Backend that I created today. If time permits I will try to implement a basic Artist layer in Ruby coupled with the bindings. Currently I, Prasun, Sameer and Josef Heinen (The Developer of GR Framework ) are discussing the possibility of bridging GR Framework to Ruby. Which would require me to create a lot of bindings,I will keep the thread updated on the progress.

Regards

Pranav Garg

[Pjotr Prins]

On Thu, May 17, 2018 at 08:18:45PM +0530, Pranav Garg wrote:
> Tomorrow I will be Reading up on various methods to create bindings to
> Ruby as well as create a SWIG binding to the basic Backend that I
> created today. If time permits I will try to implement a basic Artist
> layer in Ruby coupled with the bindings. Currently I, Prasun, Sameer
> and Josef Heinen (The Developer of GR Framework ) are discussing the
> possibility of bridging GR Framework to Ruby. Which would require me to
> create a lot of bindings,I will keep the thread updated on the
> progress.

SWIG is a royal pain, unless you want to share binding code between
languages. Better opt for FFI. Much easier!

Pj.

[Sameer Deshmukh]

I thought Cairo had been removed from the picture a long time ago? Why are you still considering it?

Is GR in so much of a nascent stage that it is unusable even for a 3 month long project? I think it will develop as rubyplot develops and they get a better reason to put more effort into their library. Also what exactly do you mean by "create lot of bindings" for GR? At this point of time you need to start working on your code. The research phase is past for now.

We have already decided the libraries that we'll be using for backend. Also SWIG is a terrible idea. It does not scale to a large library and is very hard to maintain. Most people think of it as pure evil. Also the SWIG ruby bindings are not as advanced as the python bindings are. A simple C wrapper/ FFI is enough for most cases. Maybe we can use Rubex sometime down the line.

Regards,

Sameer Deshmukh

[John Woods]

I agree with Sameer.

[Prasun Anand]

I vote yes.

Pranav, you have not even tried binding your code to Ruby which is where the pain starts. GR would be far more easy to work with, than Cairo.

This project is challenging and we don't want you to go the wrong way :).

Prasun

[Pranav Garg]

Hey Sameer,

The idea was to create a C++ Backend bridged to Ruby with GR Framework as our prime candidate. However , looking into GR Framework made me realize that it lacked a lot of documentation and examples that are needed for creation of Renderer and Figure Canvas. For example I am not able to figure out how to specify the FigureCanvas in the same (I have sent a mail to the developer about the same).

Since I did not want to waste development time I have started working on the code that uses Cairo instead which can be used in the library that we decided.

With "create a lot of bindings" for GR Framework I am talking about Prasun's idea of Bridging GR Framework to Ruby instead of creating a separate plotting library since GR Framework itself is primarily a plotting library. I would really appreciate it if you and Prasun can talk about it once, I think there has been a bit bit of lapse in communication here.

I will look into FFI and C wrapper thank you (and Pjotr) for the suggestion.

Regards

Pranav Garg

[Prasun Anand]

Hi all,

I just explained to Pranav (on a phonecall) regarding why GR is the right way to go and staying focussed on the task.

I think Pranav will agree to the advice from me and other mentors :) .

Cairo should be out of picture now.

Do you agree, Pranav ?

Prasun

[Pranav Garg]

Hey Prasun,

I agree.

So to reiterate, I will be working on porting the GR framework to ruby using C extensions. In that case I will start working on C extensions from tomorrow.

Regards

Pranav Garg

[Arafat Khan]

Hi Everyone,

I had been having a great time exploring things. Just a few observations 

1. Pranav and Sameer, I am really sorry, I should have chimed in a bit earlier.

Perhaps Pranav was facing a few issues with Gr that made outputting a file to Png/Jpg a bit difficult as the documentation wasn't 100% clear on it. You might not remember it right now, but a few days ago, I had told you that Gr could output to quite a few formats back then I had the example code for it. These examples and the beautiful graphs with the prebuilt axis, Titles, and other abilities was 100% the reason I went with Gr. I have updated the example code for it. Personally, I would hate to work with another binding project because I need to learn new things but I think for Pranav it would be a great experience. 

As for SWIG, I would say that one of the main reasons I used it for tensorflow.rb was because I had to deal with a ton of C++ code and pure C++ STL features like Vectors and Maps inside ruby which are very tightly coupled with Tensorflow.rb codebase but for a C library all these are not a necessity.  So in a case like that SWIG is not a good idea for us but FFI would be.

2. Gtk is pretty rad. 

What we need is a simple small GUI window with additional buttons for zoom in, zoom out, save as etc. These can be easily done in Gtk. I tried it out and it works well. 

Basically, the idea is that you have some sort of trigger buttons so on pressing these buttons some function is called which can do the work in the background. Still now sure about how to do zoom-in though.  Save as and close seems intuitive.

Take a look at this poorly made image showing an example of a quit button and an image.

3. I will push updates on my repo by tomorrow. You guys will soon be able to find all the updates on my repository -> https://github.com/Arafatk/magick-rubyplot

4. I am playing RMagick and I thinks its an amazing software. I am deciding a solution for myself which is how to draw clean layouts on images that make the plots look good?  

Using draw features to individually draw lines makes it all kinda easy but this whole process has to be standardized for 2d graphs in general, so that's a really decent problem with a lot of thought process behind it. Good thing that Pranav won't have to worry about this at all because he can use Gr.  Overall the problem is that if you were to draw a plot by itself on RMagick then that would be easy but drawing plots for say a standard Ruby array would involve using normalizing functions and overall making sure that the image dimensions for all the plots regardless of their numerical variation are identical.

Regards,

Arafat

On Fri, May 18, 2018 at 1:19 AM, Arafat Khan <arafat....@gmail.com> wrote:

[Arafat Khan]

​

Sorry, the image wasn't clear so here it is.

[Pranav Garg]

Daily Report 18 May 2018,

I have began the work on porting GR Framework to Ruby. To do so I have read Julia bindings for the same, which have been easily called using the ccall function in Julia. To create Bindings to
Ruby I am currently using a Ruby Standard library "Fiddle". Following the example at http://blog.honeybadger.io/use-any-c-library-from-ruby-via-fiddle-the-ruby-standard-librarys-best-kept-secret/. I tried importing GR Framework snd was successfully able to render the following figure in Ruby using just the code here(https://github.com/pgtgrly/GSOC2018-Sandbox/commit/5e3c6cc9c9ce380d49267c58f570d60721237e63).
I have been facing some issues regarding passing array pointers and parsing certain functions, because of which I am getting the following error:

/usr/lib/ruby/2.3.0/fiddle/cparser.rb:92:in `parse_signature': can't parse the function prototype: gr_surface(int,int,double*,double*,double*,int) (RuntimeError)
    from /usr/lib/ruby/2.3.0/fiddle/import.rb:163:in `extern'
    from alphatest.rb:20:in `<module:GR>'
    from alphatest.rb:6:in `<main>'

I have found the potential solution to the prior (https://stackoverflow.com/questions/19744000/how-to-deal-with-array-pointers-in-ruby-fiddle , https://ruby-doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle/Pointer.html) while I am looking into the python bridge of GR as a reference for the latter(Will probably work with the the importer module in Fiddle). I am also reading up on C Extensions from the Link that Prasun sent me in case Fiddle does not work out.

Regards
Pranav Garg

[Sameer Deshmukh]

Ok. Just make sure you don't waste time in writing wrappers for features you dont need for this project. I recommend first making a public list, maybe on the issue tracker on GitHub and then proceeding one by one. The best approach would be to first decide a feature to make in rubyplot, and then work your way backwards and decide exactly which C wrappers you need to implement the feature and work on only those.

[John Woods]

I like that you're using something that is part of the Ruby standard library. One rule I've learned over the years is try not to introduce too many new dependencies. I suspect we'll have at least a few for this project, but then it's all the more important to try to use standard library features.

On Fri, May 18, 2018 at 5:56 AM Pranav Garg <prana...@gmail.com> wrote:

Daily Report 18 May 2018,

I have began the work on porting GR Framework to Ruby. To do so I have read Julia bindings for the same, which have been easily called using the ccall function in Julia. To create Bindings to
Ruby I am currently using a Ruby Standard library "Fiddle". Following the example at http://blog.honeybadger.io/use-any-c-library-from-ruby-via-fiddle-the-ruby-standard-librarys-best-kept-secret/. I tried importing GR Framework snd was successfully able to render the following figure in Ruby using just the code here(https://github.com/pgtgrly/GSOC2018-Sandbox/commit/5e3c6cc9c9ce380d49267c58f570d60721237e63).
I have been facing some issues regarding passing array pointers and parsing certain functions, because of which I am getting the following error:

/usr/lib/ruby/2.3.0/fiddle/cparser.rb:92:in `parse_signature': can't parse the function prototype: gr_surface(int,int,double*,double*,double*,int) (RuntimeError)
    from /usr/lib/ruby/2.3.0/fiddle/import.rb:163:in `extern'
    from alphatest.rb:20:in `<module:GR>'
    from alphatest.rb:6:in `<main>'

I have found the potential solution to the prior (https://stackoverflow.com/questions/19744000/how-to-deal-with-array-pointers-in-ruby-fiddle , https://ruby-doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle/Pointer.html) while I am looking into the python bridge of GR as a reference for the latter(Will probably work with the the importer module in Fiddle). I am also reading up on C Extensions from the Link that Prasun sent me in case Fiddle does not work out.

Regards
Pranav Garg

[Arafat Khan]

Hi Everyone,

Firstly, Pranav- I think Sameer is 100% on point with this. I truly think that you need bindings for just a few functions and you can think of these functions as basic building blocks. You can build much more "evolved" functions super easily in Ruby by combining these functions and adding your own features.

GTK
The following good features easily available from Gtk.
1. Show images -> Present a fixed size for all the images from MagickPlot so that
we don't have any issues with the size of the Gtk Window.
2. Button -> We can make calls to anything internally in the library just be pressing buttons.
It's also incredibly easy to adjust the positions of a lot of buttons on the screen to make
multiple calls of different types.

3. Window -> We can create a Window like this where the window will show the image and the rest of the buttons perform operations.

4. CheckButton -> Buttons with boolean features(on/off) like say show title or not.

5. Combo Text Widget-> Showing a dropdown list of options.

6. Menu Bar-> With the option to save files in a particular format. Although, I am not exactly sure how I am going to make a pop up inside this for saving etc.

7. Error Message dialog boxes

8. Refresh and iterate between images. So this way we could say zoom in and zoom out with a button.

For now, I would say that this is more than enough and quite possibly all the features we need for Ruby-Plot. I will be using a small subset of these for my needs. Certainly, it is possible to have a few more features but given the time constraints focussing on more things would not only be frivolous but will also take a ton of time and we can't afford to do that. 

Regards,

Arafat

On Sat, May 19, 2018 at 7:41 AM, Arafat Khan <arafat....@gmail.com> wrote:

[John Woods]

Okay, this is good research, and I think you've shown GTK is sufficient for your goals. Though you alluded to it, I want to emphasize the need to keep the GUI relatively simple — simple means less potential for bugs. Features should probably be limited, at least initially to:

• 2D: zoom in / zoom out by drag-select (this will be the trickiest, since you have to reverse the transformation from the mouse clicking onto the plot)
• 3D: dragging in different ways rotates the plot (maybe not relative for magick), and scroll wheel zooms
• save as
• resizing the window redraws the plot

Can't think of much else; can anyone else? I know matplotlib has some other features in its GUI but does anyone ever use them? Let's not worry about them right now.

I don't think you want to confirm quit. Closing plots is such a common occurrence that confirmation will drive users nuts.

Maybe for now you can come up with a simple workaround for the save dialog — just push 's' key and the image gets saved in some default format (preferably a scalable one like PDF or EPS or SVG, since these can be converted to PNG or other) and default file location.

John

[Arafat Khan]

Hi Everyone, 

Firstly, John the idea of zoom-in, zoom-out that you are mentioning is something that Pranav told me too. I believe the idea you are asking for stems from the default Grapher app in Macbook. I think that accomplishing those is going to be super tricky. I will certainly have to contact experts on that. For now, I am focussing on more immediate problems as mentioned in the timeline.

The past whole week has been super amazing. I have been solving this cool problem to help design generalized graphs in Rubyplot with RMagick and it's been going great. I do think that this kind of design is certainly going to take a lot of iterations to make it work out. My concerns primarily come, not just from the attempt at trying my own problem but also being able to make a design that helps Pranav with his own tasks. To be honest, my current priority is to only focus on my own problem and then later I will change the design so as to make it work well for Pranav too.

Here are a few things I am doing   ->  https://github.com/Arafatk/magick-rubyplot

1. Adding methods to array class to help out with simple statistics operations

2. Added a modest Backend example that's not of much use now but does follow a generalized approach of making a graph with a proper axis, labels, legends, and titles. These have many methods that overload/add to the existing draw features of RMagick.

3. Adding additional math methods to the transformation layer.

4. Added a ton of beautification features to the artist class, like font size, font colors, data types, colors and lots more.

5. The fundamental problem here which is the ability to make sure that the geometry of the graph in such a way that no overlap occurs between Legends, titles, axis lines etc so that is why I am taking so much time to make the code modular and I have many other graph formats in mind. Let's see how this turns out.

6. Now that axis and making lines etc is out of the way, I think it will probably be easy to make other graphs too.

Right now, I have a ton of code mostly in the form of long program functions etc but the code is mostly spaghetti code and I have added no specs as of now. I would ask you guys to take a look but not today and hopefully, I will ask for review and recommendations by next week. I would also like opinions about aesthetics later.

​

This would be an example graph made from the code, the colors, and everything is a bit messed up right now but it will be okay. I just need some time.

Another thing, that I learned while experimenting with Matplotlib is that. It has too many features and the level of development accomplished by the codebase is astonishing.

While I am having trouble adding a few lines to make good axis. They have many files just to make a whole axis class itself.  Since I have my own limitations given the timeline what I am doing right now is that I am trying to make this sort of vertical pipeline where we will have the basic features in a modular form and then let's say that somebody else was to come in later then they can extend the features horizontally. My tasks are to make my own proof of concepts first and lay a sort of ROADMAP for future development for others.

Regards,

Arafat

On Sat, May 26, 2018 at 11:15 AM, Arafat Khan <arafat....@gmail.com> wrote:

[Prasun Anand]

Nice work! , Arafat.

I will try running your code today. I can't wait to read your blog post about your work.

Regards,

Prasun

To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev+unsubscribe@googlegroups.com.

[Pranav Garg]

Hey Guys,

Here is the blog post about my GSoC Adventure so far. Make sure that you click on the hyperlink at the end (Leads to the second half of the post).

Regards

[Arafat Khan]

Hi Pranav,

That's a really nice blog post. I would certainly use your code as a reference for working with C bindings in future.

Thanks

Regards,

Arafat

[Pranav Garg]

Thank you very much Arafat, I am humbled :). Really excited to see the plotting library that you have created. The examples look pretty cool.

Regards

Pranav

[John Woods]

Nice blog post.

On Mon, May 28, 2018 at 11:34 AM Pranav Garg <prana...@gmail.com> wrote:

Hey Guys,

Here is the blog post about my GSoC Adventure so far. Make sure that you click on the hyperlink at the end (Leads to the second half of the post).

Regards

On Sat, May 26, 2018 at 2:29 PM, Prasun Anand <prasunan...@gmail.com> wrote:

Nice work! , Arafat.

I will try running your code today. I can't wait to read your blog post about your work.

Regards,

Prasun

On Sat, May 26, 2018 at 11:23 AM, Arafat Khan <arafat....@gmail.com> wrote:

Hi Everyone, 

Firstly, John the idea of zoom-in, zoom-out that you are mentioning is something that Pranav told me too. I believe the idea you are asking for stems from the default Grapher app in Macbook. I think that accomplishing those is going to be super tricky. I will certainly have to contact experts on that. For now, I am focussing on more immediate problems as mentioned in the timeline.

The past whole week has been super amazing. I have been solving this cool problem to help design generalized graphs in Rubyplot with RMagick and it's been going great. I do think that this kind of design is certainly going to take a lot of iterations to make it work out. My concerns primarily come, not just from the attempt at trying my own problem but also being able to make a design that helps Pranav with his own tasks. To be honest, my current priority is to only focus on my own problem and then later I will change the design so as to make it work well for Pranav too.

Here are a few things I am doing   ->  https://github.com/Arafatk/magick-rubyplot

1. Adding methods to array class to help out with simple statistics operations

2. Added a modest Backend example that's not of much use now but does follow a generalized approach of making a graph with a proper axis, labels, legends, and titles. These have many methods that overload/add to the existing draw features of RMagick.

3. Adding additional math methods to the transformation layer.

4. Added a ton of beautification features to the artist class, like font size, font colors, data types, colors and lots more.

5. The fundamental problem here which is the ability to make sure that the geometry of the graph in such a way that no overlap occurs between Legends, titles, axis lines etc so that is why I am taking so much time to make the code modular and I have many other graph formats in mind. Let's see how this turns out.

6. Now that axis and making lines etc is out of the way, I think it will probably be easy to make other graphs too.

Right now, I have a ton of code mostly in the form of long program functions etc but the code is mostly spaghetti code and I have added no specs as of now. I would ask you guys to take a look but not today and hopefully, I will ask for review and recommendations by next week. I would also like opinions about aesthetics later.

4. CheckButton -> Buttons with boolean features(on/off) like say show title or not.

5. Combo Text Widget-> Showing a dropdown list of options.

6. Menu Bar-> With the option to save files in a particular format. Although, I am not exactly sure how I am going to make a pop up inside this for saving etc.

7. Error Message dialog boxes

8. Refresh and iterate between images. So this way we could say zoom in and zoom out with a button.

For now, I would say that this is more than enough and quite possibly all the features we need for Ruby-Plot. I will be using a small subset of these for my needs. Certainly, it is possible to have a few more features but given the time constraints focussing on more things would not only be frivolous but will also take a ton of time and we can't afford to do that. 

Regards,

Arafat

On Sat, May 19, 2018 at 7:41 AM, Arafat Khan <arafat....@gmail.com> wrote:

On Saturday, May 19, 2018 at 5:44:10 AM UTC+5:30, John Woods wrote:

I like that you're using something that is part of the Ruby standard library. One rule I've learned over the years is try not to introduce too many new dependencies. I suspect we'll have at least a few for this project, but then it's all the more important to try to use standard library features.

On Fri, May 18, 2018 at 5:56 AM Pranav Garg <prana...@gmail.com> wrote:

Daily Report 18 May 2018,

I have began the work on porting GR Framework to Ruby. To do so I have read Julia bindings for the same, which have been easily called using the ccall function in Julia. To create Bindings to
Ruby I am currently using a Ruby Standard library "Fiddle". Following the example at http://blog.honeybadger.io/use-any-c-library-from-ruby-via-fiddle-the-ruby-standard-librarys-best-kept-secret/. I tried importing GR Framework snd was successfully able to render the following figure in Ruby using just the code here(https://github.com/pgtgrly/GSOC2018-Sandbox/commit/5e3c6cc9c9ce380d49267c58f570d60721237e63).
I have been facing some issues regarding passing array pointers and parsing certain functions, because of which I am getting the following error:

/usr/lib/ruby/2.3.0/fiddle/cparser.rb:92:in `parse_signature': can't parse the function prototype: gr_surface(int,int,double*,double*,double*,int) (RuntimeError)
    from /usr/lib/ruby/2.3.0/fiddle/import.rb:163:in `extern'
    from alphatest.rb:20:in `<module:GR>'
    from alphatest.rb:6:in `<main>'

I have found the potential solution to the prior (https://stackoverflow.com/questions/19744000/how-to-deal-with-array-pointers-in-ruby-fiddle , https://ruby-doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle/Pointer.html) while I am looking into the python bridge of GR as a reference for the latter(Will probably work with the the importer module in Fiddle). I am also reading up on C Extensions from the Link that Prasun sent me in case Fiddle does not work out.

Regards
Pranav Garg

[John Woods]

I don't think Mac's Grapher app originated this feature. It's been in Matplotlib for ages.

I posted a few comments on your commits. Lemme know when you're ready for more. ;)

John

On Sat, May 26, 2018 at 12:54 AM Arafat Khan <arafat....@gmail.com> wrote:

Hi Everyone, 

Firstly, John the idea of zoom-in, zoom-out that you are mentioning is something that Pranav told me too. I believe the idea you are asking for stems from the default Grapher app in Macbook. I think that accomplishing those is going to be super tricky. I will certainly have to contact experts on that. For now, I am focussing on more immediate problems as mentioned in the timeline.

The past whole week has been super amazing. I have been solving this cool problem to help design generalized graphs in Rubyplot with RMagick and it's been going great. I do think that this kind of design is certainly going to take a lot of iterations to make it work out. My concerns primarily come, not just from the attempt at trying my own problem but also being able to make a design that helps Pranav with his own tasks. To be honest, my current priority is to only focus on my own problem and then later I will change the design so as to make it work well for Pranav too.

Here are a few things I am doing   ->  https://github.com/Arafatk/magick-rubyplot

1. Adding methods to array class to help out with simple statistics operations

2. Added a modest Backend example that's not of much use now but does follow a generalized approach of making a graph with a proper axis, labels, legends, and titles. These have many methods that overload/add to the existing draw features of RMagick.

3. Adding additional math methods to the transformation layer.

4. Added a ton of beautification features to the artist class, like font size, font colors, data types, colors and lots more.

5. The fundamental problem here which is the ability to make sure that the geometry of the graph in such a way that no overlap occurs between Legends, titles, axis lines etc so that is why I am taking so much time to make the code modular and I have many other graph formats in mind. Let's see how this turns out.

6. Now that axis and making lines etc is out of the way, I think it will probably be easy to make other graphs too.

Right now, I have a ton of code mostly in the form of long program functions etc but the code is mostly spaghetti code and I have added no specs as of now. I would ask you guys to take a look but not today and hopefully, I will ask for review and recommendations by next week. I would also like opinions about aesthetics later.

​

4. CheckButton -> Buttons with boolean features(on/off) like say show title or not.

5. Combo Text Widget-> Showing a dropdown list of options.

6. Menu Bar-> With the option to save files in a particular format. Although, I am not exactly sure how I am going to make a pop up inside this for saving etc.

7. Error Message dialog boxes

8. Refresh and iterate between images. So this way we could say zoom in and zoom out with a button.

For now, I would say that this is more than enough and quite possibly all the features we need for Ruby-Plot. I will be using a small subset of these for my needs. Certainly, it is possible to have a few more features but given the time constraints focussing on more things would not only be frivolous but will also take a ton of time and we can't afford to do that. 

Regards,

Arafat

On Sat, May 19, 2018 at 7:41 AM, Arafat Khan <arafat....@gmail.com> wrote:

On Saturday, May 19, 2018 at 5:44:10 AM UTC+5:30, John Woods wrote:

I like that you're using something that is part of the Ruby standard library. One rule I've learned over the years is try not to introduce too many new dependencies. I suspect we'll have at least a few for this project, but then it's all the more important to try to use standard library features.

On Fri, May 18, 2018 at 5:56 AM Pranav Garg <prana...@gmail.com> wrote:

Daily Report 18 May 2018,

I have began the work on porting GR Framework to Ruby. To do so I have read Julia bindings for the same, which have been easily called using the ccall function in Julia. To create Bindings to
Ruby I am currently using a Ruby Standard library "Fiddle". Following the example at http://blog.honeybadger.io/use-any-c-library-from-ruby-via-fiddle-the-ruby-standard-librarys-best-kept-secret/. I tried importing GR Framework snd was successfully able to render the following figure in Ruby using just the code here(https://github.com/pgtgrly/GSOC2018-Sandbox/commit/5e3c6cc9c9ce380d49267c58f570d60721237e63).
I have been facing some issues regarding passing array pointers and parsing certain functions, because of which I am getting the following error:

/usr/lib/ruby/2.3.0/fiddle/cparser.rb:92:in `parse_signature': can't parse the function prototype: gr_surface(int,int,double*,double*,double*,int) (RuntimeError)
    from /usr/lib/ruby/2.3.0/fiddle/import.rb:163:in `extern'
    from alphatest.rb:20:in `<module:GR>'
    from alphatest.rb:6:in `<main>'

I have found the potential solution to the prior (https://stackoverflow.com/questions/19744000/how-to-deal-with-array-pointers-in-ruby-fiddle , https://ruby-doc.org/stdlib-2.0.0/libdoc/fiddle/rdoc/Fiddle/Pointer.html) while I am looking into the python bridge of GR as a reference for the latter(Will probably work with the the importer module in Fiddle). I am also reading up on C Extensions from the Link that Prasun sent me in case Fiddle does not work out.

Regards
Pranav Garg

[Arafat Khan]

Hi Everyone,
The progress has been good this week but I haven't been able to work since last night
because I got a bit sick. I am suffering from fever due to fast temperature changes in my region.

As for the API development, I believe that at this stage I am able to develop
good parallels with the actual Matplotlib API. The original API has Artist
superclass with draw, axis, labels, ticks etc and I have adopted identical
naming for the magickplot API in case anyone comes after me to develop this
further, they do have a solid reference point to pick up from.

Coming back to this week's work, in particular, I have been focussing on
developing the API for line graph and adding many new helper methods.
This is super nice with the ability to make a one-dimensional line graph
but it also has the ability to make y only and x-y plots.

For now, I am not adding many tests but I will add a lot of them
later to be able to show all the various ways to manipulate and design graphs.
Another good thing is that I do have many ideas to make the graphs aesthetically
pleasing so adding those to the existing API would be pretty easy given that I
have spent a ton of time making the code modular.

As for the transformation API, I think that since I and Pranav have a very
different codebase we aren't going to have a common API for now. For my own use,
I am focused on making some relatively simple math functions that I use
for doing small computations for normalizing, scaling, pixel location adjustment
etc. Later when the time comes, perhaps we will make a common set of math
functions for both the libraries when the time comes.

Also, thanks to John for all the comments, I have to admit that I didn't really
follow the proper ruby naming conventions or made the code truly ruby-like
because I was a bit busy with getting the ideas working so comments in that
regard are very welcome. As for now, I am good with you guys making any comments about
the ruby code but comments relating to the aesthetics of the graphs wouldn't be a
good idea. I am just experimenting with the line colors/widths and then hardcoding
default values for those. I will handle the aesthetics and small design/color details
for all the plot types together at the end these will include custom themes for
plots.

Have a great day everyone.
Regards,

Arafat

On Sun, Jun 3, 2018 at 7:50 AM, Arafat Khan <arafat....@gmail.com> wrote:

[John Woods]

Could you explain what you mean by transformation API a bit more, please? :)

[Pranav Garg]

Hey John,

Arafat and I just had a discussion about the transform layer.

Please find the details about the transform layer in this doc: 

https://docs.google.com/document/d/1J2fDsMYtdZCRcTvfUg11wK3w_38Et9Z8IJBPqA4wzY8/edit?usp=drivesdk

Regards

PG

[John Woods]

Okay, so you're not using a common API because right now you're only doing really simple transformations and it'll be easy to change later, is your thinking?

[Arafat Khan]

Yes, that is the reason for me not implementing the transformations. 

Personally, I am just doing simple operations on the data first to be able to make simple plots first.  

If this works out well then I could consider adding more features(transformations).

My code is very modular so adding that shouldn't be an issue.

Regards,

Arafat

To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciRuby Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciRuby Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev+unsubscribe@googlegroups.com.

[Arafat Khan]

Hi Everyone,
I am really sorry for the super delayed update.  I have been super sick
this week. I haven't been able to do much work in the past few days as
I had a high fever. I have however tried my best to move forward. I added the
API to make scatter plots and that looks pretty cool. I will have to test it
a bit more but it's still some good plotting idea and I think that I will be able to easily

add a lot more plotting types as I am getting the gist of all these things very well

so building up on my previous ideas will be super easy and fun.

Overall, I would say that the work till now has been good and
I have been able to add quite a few useful functionalities as well as being
able to stress test a few of the past work. I have a much clearer idea of what I need to do

for the future of this project and how I will go about it.

As for the blog posts, I would say that  I have written a few blog posts before for introducing my

software and to communicate with Ruby and Golang community. The reason

I am not writing a blog post right now is because if I wanted to communicate about my work

then I can very well do that by emailing you guys and other developers involved

with plotting and visualizations.

In future, I will be writing 2-3 very elaborate blog posts and share
them with the community later on Reddit or hackernews and see how people react
to be able to take the feedback to add more features. I will do that later once
I have had some reasonable progress.

Please do let me know if you need to know anything else or have any questions

about the work.

Regards,
Arafat

To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciRuby Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "SciRuby Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sciruby-dev...@googlegroups.com.

[John Woods]

Sounds good. Thanks for the update, Arafat. Glad you're feeling better.