Updated README to markdown. Added spec for issue #15

clbustos · Aug 7, 2014 · 5bd70e7 · 5bd70e7
1 parent d4b4ec9
commit 5bd70e7
Show file tree

Hide file tree

Showing 3 changed files with 15 additions and 13 deletions.
diff --git a/README.txt → README.md b/README.txt → README.md
@@ -1,12 +1,12 @@
-= Rubyvis
+# Rubyvis
 
-* http://rubyvis.rubyforge.org/
+* https://github.com/clbustos/rubyvis
 
-== DESCRIPTION:
+## DESCRIPTION:
 
 Ruby port of Protovis[http://vis.stanford.edu/protovis/], a Javascript visualization toolkit.
 
-== FEATURES/PROBLEMS:
+## FEATURES/PROBLEMS:
 
 This library implements almost completely core API of protovis, including all static marks, SVG builder class and data classes. Spec coverage is near 90%
 
@@ -43,7 +43,7 @@ User could use +pv+ freely, cause is defined as a global method which call Rubyv
 
 Nokogiri is used as XML library. If not available, or $rubyvis_no_nokogiri is set to true, REXML is used. Nokogiri is 30%-35% faster that REXML on our test.
 
-== CURRENT PROGRESS
+## CURRENT PROGRESS
 
 * pv.js
 * pv-internals.js
@@ -93,7 +93,7 @@ Nokogiri is used as XML library. If not available, or $rubyvis_no_nokogiri is se
 * text/Format.js (incomplete)
 * text/NumberFormat.js (incomplete)
 
-== SYNOPSIS:
+## SYNOPSIS:
 
 The primary API, based on Gregory Brown's Ruby Best Practices, uses blocks and name of marks as methods
 
@@ -134,22 +134,22 @@ The library allows you to use chain methods API, like original protovis
 
 See examples directory for original protovis examples adaptations and others graphics
 
-== THE MOST FREQUENT QUESTION (MFQ)
+## THE MOST FREQUENT QUESTION (MFQ)
 
 ¿Why use a server-side technology if I can use a client-side, which is faster and more economic for developer?
 
 If you want to present graphs: (a) complex and/or dynamically generated, (b) only on the web and (c) on modern browsers, Protovis[http://vis.stanford.edu/protovis/] is an excellent option. For simpler charts, Protovis is overkill. I recomend jqPlot[http://www.jqplot.com/]
 
 Rubyvis is designed mainly for off-line operation, like batch creation of graphs for use on printed documents (rtf-pdf), with possibility of use easily the script for on-line use.
 
-== REQUIREMENTS:
+## REQUIREMENTS:
 
 Tested on Ruby 1.8.7, 1.9.1, 1.9.2-p0 and ruby-head (future 1.9.3)
 
-== INSTALL:
+## INSTALL:
 
 $ gem install rubyvis
 
-== LICENSE:
+## LICENSE:
 
 BSD 2-Clause (see LICENSE.txt)
diff --git a/lib/rubyvis/scale/quantitative.rb b/lib/rubyvis/scale/quantitative.rb
@@ -270,7 +270,6 @@ def ticks_floor(d,prec) # :nodoc:
     private :ticks_floor
 
     def to_date(d) # :nodoc:
-
       Time.utc(*d)
     end
     # Returns an array of evenly-spaced, suitably-rounded values in the input
@@ -331,7 +330,6 @@ def ticks(m=nil) # :args: (number_of_ticks=nil)
         format = "%S.%Qs";
         increment = lambda {|d|  Time.at(d.to_f+(step/1000.0)) }
       end
-
       @tick_format = Rubyvis.Format.date(format);
       date = Time.at(min.to_f)
       dates = []

diff --git a/spec/scale_linear_datetime_spec.rb b/spec/scale_linear_datetime_spec.rb
@@ -15,6 +15,10 @@ def @y.mock_ticks_floor(d,prec)
       ticks_floor(d,prec)
     end
   end
+  it "should not crash on :week_day precision (bug #15)" do
+    ct=Time.utc(2012,02,01,10,10,10)
+    @y.mock_ticks_floor(ct,:week_day).should==Time.utc(2012,01,01,10,10,10)
+  end
   it "y should be a Scale" do
     @y.should be_a(Rubyvis::Scale::Linear)
   end
@@ -62,6 +66,6 @@ def @y.mock_ticks_floor(d,prec)
   end 
 
   it "should returns correct tick_format"
-
   it "should nice nicely"
+
 end