Common Artist layer planning

[v0dro]

@Arafatk and @pgtgrly discuss common Artist layer APIs in this thread.

-- EDIT 20 June 2018

As per discussion between @Arafatk and @pgtgrly , we will implement common scripting layer and differing artist classes.

[v0dro]

I have an idea - you can build the common API by writing rspecs and then using the same specs in your respective GR and rmagick libraries. That way you can maintain consistency across libraries the whole time.

We'll just establish a protocol that you should not change the specs without communicating with the others. The common specs can be kept in this ruby plot repo and both of you can copy paste it in your repos for now.

[arafatkatze]

I mean that's certainly possible when we are using a few common normalization functions on the data because we consider those functions as common for both the libraries. So perhaps it's a good idea to add a common specs folder with common testing functions.
Obviously, all the visual specs for RMagicks and all geometry specs are going to be different.

[translunar]

Yes. This is what I was hoping would happen all along. Sorry for not being clearer. :)

…

On Mon, Jun 18, 2018 at 6:16 AM Sameer Deshmukh ***@***.***> wrote: I have an idea - you can build the common API by writing rspecs and then using the same specs in your respective GR and rmagick libraries. That way you can maintain consistency across libraries the whole time. We'll just establish a protocol that you should not change the specs without communicating with the others. The common specs can be kept in this ruby plot repo and both of you can copy paste it in your repos for now. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKFpNh7qy0Agzaekcn7-hhWDz7i3r-Bks5t96ghgaJpZM4Urqvr> .

[arafatkatze]

If you are referring to the data normalization specs and a few data transformations then yes, we can certainly do that. Pranav and I talked about this a long time ago. Then our projects went totally orthogonal so I only focussed on my own work. My code is very intertwined with RMagick Geometry problem but data transformations steps are still separate for the most part so having that as a common API won't be a problem as mentioned in my previous email. On Mon, Jun 18, 2018 at 8:38 PM Dr. John Woods <notifications@github.com> wrote:

…

Yes. This is what I was hoping would happen all along. Sorry for not being clearer. :) On Mon, Jun 18, 2018 at 6:16 AM Sameer Deshmukh ***@***.***> wrote: > I have an idea - you can build the common API by writing rspecs and then > using the same specs in your respective GR and rmagick libraries. That way > you can maintain consistency across libraries the whole time. > > We'll just establish a protocol that you should not change the specs > without communicating with the others. The common specs can be kept in this > ruby plot repo and both of you can copy paste it in your repos for now. > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#1 (comment)>, or mute > the thread > < https://github.com/notifications/unsubscribe-auth/AAKFpNh7qy0Agzaekcn7-hhWDz7i3r-Bks5t96ghgaJpZM4Urqvr > > . > — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKo3B6s8ws2jIGh-NZVXlNTWxb89xIY5ks5t-A_MgaJpZM4Urqvr> .

[v0dro]

@Arafatk you can write the artist specs here: https://github.com/SciRuby/rubyplot/blob/master/spec/artist_spec.rb

Don't directly push to the repo. Send your commits to a PR so that we can review them first.

[pgtgrly]

@Arafatk and I had a conversation in the noon. We both agreed that classes such as Bar Graph, Line Graph, Lineplot, Scatter plot should be a part Scripting Layer Rather than the Artist Layer. TheReason Arafat has included them in the Artist layer is because they do the plotting at the level rather than calling the Artist functions to do so.
That being said the unified API that we are working towards should be Scripting API, not the Artist API.
The User will have the same API but can choose if they want to use GR backend or Rmagick Backend.

Here is a mock scripting class

class RbPlot
  def initialize #create a new RbPlot figure
    @task_list[]
    @x_range # Range of x axes if it is not user defined then it will be defined mby the program
    @y_range # Range of Y axis same as that of x axis
    @marker_colour # colour of the lines drawn
    @marker_size # size of the lines drawn
    @title = nil # the title of the graph to be given if user defined
    @xlabel
    @ylabel
    @font
    # figures can be broadly be divided into two parts, 
    # 1. Data representatation: like barchart,line PLOT and pie chart
    # 2.Data plotting: like scatter plot and line graph
    # we can add more as we further develop it move on
    @data_represent_flag = false                  
    @data _plot_flag =  false
    # data representation will have charts cannot be multiple over a figure
    # data plotting can be
    # user can either specify what sort of diagram he wants the figure to be
    # in #type or it will be assigned when a plot is initialised

  end

  def Barplot(data)
    if @data _plot_flag
      puts "The Figure is of plot type"
      return
    else
      @data_represent_flag = true
    end
    #in Arafat's case this will instantiate the Bar plot class in Artist layer
    #in Pranav's Case it will directly make the plot using GR function classes

  end  def LineGraph(x_data,y_data)
    if @data _represent_flag
      puts "The Figure is of representation type"
      return
    else
      @data_plot_flag = true
    end
    #in Arafat's case this will instantiate the LineGraph class in Artist layer
    #in Pranav's Case it will directly make the plot using GR function classes
  end

  def savefig(filename)
    #saves_figure
  end

  def display
    #displays_figure
  end

  def clearall
    # reinitialize the object
  end
end

[v0dro]

Ok so if I understand you correctly @Arafatk is going to refactor his artist classes as the scripting layer?

[translunar]

A couple of thoughts:

1. You all still aren't following the Ruby style. Should be clear_all!, not clearall, for example. Please go through this and figure out how to make it look like Ruby code.
2. savefig does not follow the principle of lease surprise. Why not just save?
3. BarPlot, not Barplot.
4. You wrote: "# data representation will have charts cannot be multiple over a figure # data plotting can be". What?
5. You have @marker_colour and @marker_size. What happens if you have two types of marks, e.g. a line plot where the actual data values are marked by an x? I think you need to differentiate between markers and lines.
6. Can you please go back and look at how matplotlib does these things? This is why I want you two to start with a spec before anything else. The spec should include lots and lots of example plots, so you can see exactly what features you need to implement and prevent collisions. Your goal should be to implement, in as few lines of code as possible, as many of the spec'd plots as possible.

cc @Arafatk