[#32009] merging nokogiri to ext/ — Aaron Patterson <aaron@...>

I would like to merge nokogiri to ext for the 1.9.3 release. I spoke to

82 messages 2010/09/02
[#32010] Re: merging nokogiri to ext/ — "U.Nakamura" <usa@...> 2010/09/02

Hello,

[#32012] Re: merging nokogiri to ext/ — Ryan Davis <ryand-ruby@...> 2010/09/02

[#32030] Re: merging nokogiri to ext/ — "NARUSE, Yui" <naruse@...> 2010/09/03

Hi,

[#32033] Re: merging nokogiri to ext/ — "NARUSE, Yui" <naruse@...> 2010/09/03

2010/9/3 NARUSE, Yui <naruse@airemix.jp>:

[#32155] Re: merging nokogiri to ext/ — Yusuke ENDOH <mame@...> 2010/09/08

Currently, we're discussing three different topics:

[#32189] Re: merging nokogiri to ext/ — Aaron Patterson <aaron@...> 2010/09/09

On Thu, Sep 09, 2010 at 01:40:34AM +0900, Yusuke ENDOH wrote:

[#32056] [Ruby 1.8-Bug#3788][Open] URI cannot parse IPv6 addresses propertly — Adam Majer <redmine@...>

Bug #3788: URI cannot parse IPv6 addresses propertly

16 messages 2010/09/04

[#32110] Ruby 2.0 Wiki/Wish-list? — Joshua Ballanco <jballanc@...>

Hi all,

41 messages 2010/09/07
[#32114] Re: Ruby 2.0 Wiki/Wish-list? — "NARUSE, Yui" <naruse@...> 2010/09/08

2010/9/8 Joshua Ballanco <jballanc@gmail.com>:

[#32117] Re: Ruby 2.0 Wiki/Wish-list? — Joshua Ballanco <jballanc@...> 2010/09/08

On Sep 7, 2010, at 5:21 PM, NARUSE, Yui wrote:

[#32143] Re: Ruby 2.0 Wiki/Wish-list? — Roger Pack <rogerdpack2@...> 2010/09/08

> So, for example, a few things I've wanted for a long time:

[#32135] [Ruby-Bug#3802][Open] freeaddrinfo not found in WS2_32.dll — Thomas Volkmar Worm <redmine@...>

Bug #3802: freeaddrinfo not found in WS2_32.dll

16 messages 2010/09/08

[#32154] Making custom_lambda() work — Magnus Holm <judofyr@...>

A tiny suggestion for how we could make it possible to call lambdas

15 messages 2010/09/08
[#32159] Re: Making custom_lambda() work — Nikolai Weibull <now@...> 2010/09/08

On Wed, Sep 8, 2010 at 18:21, Magnus Holm <judofyr@gmail.com> wrote:

[#32156] Can we convert the standard library to gems? — James Edward Gray II <james@...>

Taken from the bundle Nokogiri thread:

98 messages 2010/09/08
[#32161] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/08

On 2010-09-09 01:45:43 +0900, James Edward Gray II wrote:

[#32166] Re: Can we convert the standard library to gems? — James Edward Gray II <james@...> 2010/09/08

On Sep 8, 2010, at 12:03 PM, Marcus Rueckert wrote:

[#32173] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/08

On 2010-09-09 02:54:26 +0900, James Edward Gray II wrote:

[#32249] Re: Can we convert the standard library to gems? — Aaron Patterson <aaron@...> 2010/09/09

On Thu, Sep 09, 2010 at 05:26:54AM +0900, Marcus Rueckert wrote:

[#32278] Re: Can we convert the standard library to gems? — Lucas Nussbaum <lucas@...> 2010/09/10

On 10/09/10 at 02:41 +0900, Aaron Patterson wrote:

[#32162] Re: Can we convert the standard library to gems? — Yusuke ENDOH <mame@...> 2010/09/08

Hi,

[#32216] Re: Can we convert the standard library to gems? — Ryan Davis <ryand-ruby@...> 2010/09/09

[#32229] Re: Can we convert the standard library to gems? — Yusuke ENDOH <mame@...> 2010/09/09

Hi,

[#32260] Re: Can we convert the standard library to gems? — Ryan Davis <ryand-ruby@...> 2010/09/09

[#32275] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/10

I'm off today so sorry if I missed some mails.

[#32293] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/10

Urabe,

[#32316] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/11

(2010/09/10 23:48), James Cox wrote:

[#32322] Re: Can we convert the standard library to gems? — James Tucker <jftucker@...> 2010/09/11

[#32335] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/12

I'm at an airport back to my home so in short,

[#32343] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/12

On Sun, Sep 12, 2010 at 6:51 AM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#32382] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/14

(2010/09/13 3:54), James Cox wrote:

[#32383] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/14

On Tue, Sep 14, 2010 at 12:37 PM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#32393] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/15

How difficult to make myself understood in English.

[#32396] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/15

On Wed, Sep 15, 2010 at 1:43 AM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#32399] Re: Can we convert the standard library to gems? — Yusuke ENDOH <mame@...> 2010/09/15

Hi,

[#32400] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/15

On Wed, Sep 15, 2010 at 12:07 PM, Yusuke ENDOH <mame@tsg.ne.jp> wrote:

[#32401] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/15

On 2010-09-16 01:42:39 +0900, James Cox wrote:

[#32402] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/15

On Wed, Sep 15, 2010 at 1:35 PM, Marcus Rueckert <darix@opensu.se> wrote:

[#32411] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/15

On 2010-09-16 03:36:56 +0900, James Cox wrote:

[#32412] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/16

On Wednesday, September 15, 2010, Marcus Rueckert <darix@opensu.se> wrote:

[#32414] Re: Can we convert the standard library to gems? — Lucas Nussbaum <lucas@...> 2010/09/16

On 16/09/10 at 11:02 +0900, James Cox wrote:

[#32248] Replacing stdlib Date with C version — Jeremy Evans <code@...>

I've recently been working on a replacement for the stdlib Date class,

15 messages 2010/09/09

[#32290] [Ruby 1.9.2-Backport#3818][Open] Seg fault with ruby tmail and ruby 1.9.2 — Karl Baum <redmine@...>

Backport #3818: Seg fault with ruby tmail and ruby 1.9.2

10 messages 2010/09/10

[#32453] Why doesn’t Enumerable define a #last method? — Nikolai Weibull <now@...>

Hi!

9 messages 2010/09/17

[#32454] [Ruby 1.9-Feature#3845][Open] "in" infix operator — Yusuke Endoh <redmine@...>

Feature #3845: "in" infix operator

20 messages 2010/09/17
[#32489] Re: [Ruby 1.9-Feature#3845][Open] "in" infix operator — Benoit Daloze <eregontp@...> 2010/09/21

On 17 September 2010 12:30, Yusuke Endoh <redmine@ruby-lang.org> wrote:

[#32529] [Ruby 1.9-Bug#3869][Open] Logger#log does not handle or escape new-line characters. — Hal Brodigan <redmine@...>

Bug #3869: Logger#log does not handle or escape new-line characters.

9 messages 2010/09/23

[#32585] Proposal for Optional Static Typing for Ruby — Martin Pilkington <pilky@...>

Hi,

47 messages 2010/09/27
[#32588] Re: Proposal for Optional Static Typing for Ruby — Yukihiro Matsumoto <matz@...> 2010/09/27

Hi,

[#32592] Re: Proposal for Optional Static Typing for Ruby — Martin Pilkington <pilky@...> 2010/09/28

Hi Matz

[#32595] Re: Proposal for Optional Static Typing for Ruby — Asher <asher@...> 2010/09/28

Martin,

[#32611] Re: Proposal for Optional Static Typing for Ruby — Loren Segal <lsegal@...> 2010/09/28

Hi,

[#32628] Re: Proposal for Optional Static Typing for Ruby — Eleanor McHugh <eleanor@...> 2010/09/29

It strikes me that much of the premise behind this thread is misguided as it overlooks the importance of meta-programming in developing any Ruby program of substantive size. Where a Java or C++ programmer might write a factory method to create instances of a class and spend much of their effort enumerating types explicitly, it's not unusual in Ruby to write meta-programs which create a variety of class and method definitions on request to create or repurpose object instances for the task at hand.

[#32634] [Ruby 1.9-Bug#3889][Open] Incorrectly detected i686-w64-mingw32 as x64-mingw — Luis Lavena <redmine@...>

Bug #3889: Incorrectly detected i686-w64-mingw32 as x64-mingw

21 messages 2010/09/29

[ruby-core:32248] Replacing stdlib Date with C version

From: Jeremy Evans <code@...>
Date: 2010-09-09 17:40:58 UTC
List: ruby-core #32248
I've recently been working on a replacement for the stdlib Date class,
called home_run.  It's written in C and is much faster than the stdlib
version.  On 1.9.2, it's about 2-70x faster than the stdlib for common
operations. See http://github.com/jeremyevans/home_run

With speed comes a price, which is that it is not fully compatible, and
it would be difficult to make it fully compatible without greatly
increasing the complexity of the library.  Here are the differences I
know about between the stdlib and home_run:

* Written in C (mostly) instead of ruby. Stores information in a C
structure, and therefore has a range limitation. home_run cannot handle
dates after 5874773-08-15 or before -5877752-05-08 on 32-bit platforms
(with larger limits for 64-bit platforms).
* The Date class does not store fractional days (e.g. hours, minutes),
or offsets. The DateTime class does handle fractional days and offsets.
* The DateTime class stores fractional days as the number of nanoseconds
since midnight, so it cannot deal with differences less than a
nanosecond.
* Neither Date nor DateTime uses rational. Places where the standard
library returns rationals, home_run returns integers or floats.
* Because rational is not used, it is not required. This can break other
libraries that use rational without directly requiring it.
* There is no support for modifying the date of calendar reform, the sg
arguments are ignored and the Gregorian calendar is always used. This
means that julian day 0 is -4173-11-24, instead of -4712-01-01.
* The undocumented Date#strftime format modifiers are not supported.
* The DateTime offset is checked for reasonableness. home_run does not
support offsets with an absolute difference of more than 14 hours from
UTC.
* DateTime offsets are stored in minutes, so it will round offsets with
fractional minutes to the nearest minute.
* All public class and instance methods for both Date and DateTime are
implemented, except that the allocate class method is not available and
on 1.9, _dump and _load are used instead of marshal_dump and
marshal_load.
* Only the public API is compatible, the private methods in the standard
library are not implemented.
* The marshalling format differs from the one used by the standard
library. Note that the 1.8 and 1.9 standard library date marshalling
formats differ from each other.
* Date#step treats the step value as an integer, so it cannot handle
steps of fractional days. DateTime#step can handle fractional day steps,
though.
* When parsing the %Q modifier in _strptime, the hash returned includes
an Integer :seconds value and a Float :sec_fraction value instead of a
single rational :seconds value.
* The string returned by #inspect has a different format, since it
doesn't use rational.
* You can use the Date::Format::STYLE hash to change how to parse
DD/DD/DD and DD.DD.DD date formats, allowing you to get ruby 1.9
behavior on 1.8 or vice-versa. This is probably the only new feature in
that isn't in the standard library.

It's possible to make home_run more compatible with the stdlib, for
example by supporting the date of calendar reform or by supporting the
undocumented strftime modifiers.  Changes such as supporting rational or
fractional nanoseconds would be significantly more involved.

I designed home_run so that it would fully serve the needs of 99% of
rubyists.  For the 1% that need the features that home_run does not
provide, they could either use the current stdlib (either moved
elsewhere in the stdlib or made available as a gem), or Tadayoshi
Funaba's date2 or date4 libraries (http://www.funaba.org/en/ruby.html).

There are a couple possible issues with home_run's implementation that
do not affect backwards compatibility but you may want to consider:

* home_run stores fractional days (nanoseconds since midnight) in a long
long.  So the current version would not work on platforms that don't
support long long.
* home_run uses Ragel to speed up Date._parse for common date formats.
This means that you need Ragel if you want to modify the C parser.  The
Ragel/C parser is only used to speed up parsing, if it doesn't match,
home_run falls back on using a faster version of the current
date/format.rb.

So my questions for ruby-core:

* Is it possible to replace the current stdlib date support with
home_run?
* If so, could it be taken as is, or are changes to increase backwards
compatibility required first?
* If changes are required first, which changes would you like to see?
* If you don't think it is a good idea to replace the current stdlib
with home_run, could you give a short explanation of your reasoning?

Thank you,
Jeremy Evans

In This Thread

Prev Next