[#22637] [Bug #1240] parser bug in 1.8.7 and 1.9.1p0 — Thomer Gil <redmine@...>
Bug #1240: parser bug in 1.8.7 and 1.9.1p0
Issue #1240 has been updated by Yusuke Endoh.
[#22640] [Bug #1241] Segfault with Nokogiri 1.2.1 on Ruby 1.9.1p0 — Raven Ex <redmine@...>
Bug #1241: Segfault with Nokogiri 1.2.1 on Ruby 1.9.1p0
[#22646] [Bug #1243] 1 is prime — Yuki Sonoda <redmine@...>
Bug #1243: 1 is prime
Issue #1243 has been updated by Dave B.
[#22684] [Bug #1247] YAML::load converts some dates into strings — Matthew Wilson <redmine@...>
Bug #1247: YAML::load converts some dates into strings
Issue #1247 has been updated by Yusuke Endoh.
On Thu, Apr 08, 2010 at 10:22:57PM +0900, Yusuke Endoh wrote:
On 4/8/10, Aaron Patterson <aaron@tenderlovemaking.com> wrote:
Hi,
[#22685] 1.9 conditional wait has no timeout support — Nasir Khan <rubylearner@...>
In ruby 1.8 we could use -
[#22687] [Bug #1248] e.exception(e) returns self — Tomas Matousek <redmine@...>
Bug #1248: e.exception(e) returns self
Hi,
Well the reason is that arg is supposed to be a message, right? A message can be an arbitrary object. So if I pass e as a message, why it doesn't become a value of the message property?
Hi,
[#22715] [Bug #1251] gsub problem — Alexander Pettelkau <redmine@...>
Bug #1251: gsub problem
[#22725] [Bug #1253] Fix MSVC Build Issues — Charlie Savage <redmine@...>
Bug #1253: Fix MSVC Build Issues
[#22727] Moving ruby 1.9.1 forward on windows — Charlie Savage <cfis@...>
Hi everyone,
On Sat, Mar 7, 2009 at 7:01 PM, Charlie Savage <cfis@savagexi.com> wrote:
> This works until you start linking third-party upstream source that
On Sun, Mar 8, 2009 at 3:45 PM, Charlie Savage <cfis@savagexi.com> wrote:
Hi Austin,
On Sun, Mar 8, 2009 at 4:26 PM, Charlie Savage <cfis@savagexi.com> wrote:
[#22731] [Bug #1255] += for large strings egrigiously slow — James Lee <redmine@...>
Bug #1255: += for large strings egrigiously slow
[#22736] Ruby 1.9.1 and tail recursion optimization — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...>
Moin, moin!
Wolfgang N疆asi-Donner schrieb:
Hi,
>
On Sun, Mar 8, 2009 at 16:57, James Coglan <jcoglan@googlemail.com> wrote:
2009/3/8 Nikolai Weibull <now@bitwi.se>
James Coglan wrote:
daz schrieb:
Wolfgang N叩dasi-Donner wrote:
Charles Oliver Nutter schrieb:
[#22748] [Feature #1256] Add constant TAILRECURSION to let a program recognize if tail recursion optimization is implemented — Wolfgang Nádasi-Donner <redmine@...>
Feature #1256: Add constant TAILRECURSION to let a program recognize if tail recursion optimization is implemented
Hi,
[#22803] Relegate 1.8.6 to Engine Yard, part II — Urabe Shyouhei <shyouhei@...>
Hello and sorry for my being slow for this issue. It's OK now for me to pass
Ryan Davis wrote:
Urabe Shyouhei wrote:
Hi,
Nobuyoshi Nakada wrote:
Urabe Shyouhei wrote:
[#22812] [Bug #1261] cross-compiling Ruby extensions using mkmf doesn't fully respect DESTDIR — Daniel Golle <redmine@...>
Bug #1261: cross-compiling Ruby extensions using mkmf doesn't fully respect DESTDIR
[#22859] [Bug #1277] Incorrect passing of file handle between runtime libraries in OpenSSL extension — Charlie Savage <redmine@...>
Bug #1277: Incorrect passing of file handle between runtime libraries in OpenSSL extension
[#22892] Ruby Time — valodzka <valodzka@...>
Got tired of current ruby Time limitation, I have written this -
In article <9e19ed87-9d12-4f98-af3c-bd49a71b0bd4@p11g2000yqe.googlegroups.com>,
valodzka wrote:
> I bet you'll get tired of updating that database. There's a major difference
valodzka wrote:
In article <b5d0a489-4613-4b63-9664-8627358b2dd9@g19g2000yql.googlegroups.com>,
> I found a discussion in PHP.
In article <deab6882-12ac-4aa1-a901-681795ed863b@z9g2000yqi.googlegroups.com>,
[#22893] [Feature #1291] O_CLOEXEC flag missing for Kernel::open — David Martin <redmine@...>
Feature #1291: O_CLOEXEC flag missing for Kernel::open
Issue #1291 has been updated by Motohiro KOSAKI.
[#22894] [Bug #1292] 1.8 compile time error with mingw gcc 4.3 — Roger Pack <redmine@...>
Bug #1292: 1.8 compile time error with mingw gcc 4.3
Hi,
[#22916] [Bug #1296] [trunk/22981] 64-bit issues on trunk in ext/zlib — Ollivier Robert <redmine@...>
Bug #1296: [trunk/22981] 64-bit issues on trunk in ext/zlib
[#22927] [Bug #1301] Poor RegExp Matching Performance — Andreas Grau <redmine@...>
Bug #1301: Poor RegExp Matching Performance
[#22935] 1.8.6 rdoc breaks when rdoc'ing 1.9 — James Britt <james.britt@...>
I'm running ruby 1.8.6 (2009-03-10 patchlevel 362) [i686-linux] and
[#22937] Ruby not to be a part of Google's 2009 Summer of Code? — Rocky Bernstein <rocky.bernstein@...>
The list of participating organizations for Google's 2009 Summer of Code has
[#22978] Ruby 1.9 bloc parameters — Vincent Isambart <vincent.isambart@...>
Hi,
[#22979] Ruby 1.9 bloc parameters — Vincent Isambart <vincent.isambart@...>
Hi,
[#22990] [Bug #1309] dl tests — Charlie Savage <redmine@...>
Bug #1309: dl tests
[#23026] [Bug #1317] Creating a range with strings — Ian Bailey <redmine@...>
Bug #1317: Creating a range with strings
[#23050] [Bug #1322] define_method scope bug — "coderrr ." <redmine@...>
Bug #1322: define_method scope bug
[#23051] [Bug #1323] Sockets broken on windows — Charlie Savage <redmine@...>
Bug #1323: Sockets broken on windows
[#23053] [Bug #1325] fiber tests kill windows — Charlie Savage <redmine@...>
Bug #1325: fiber tests kill windows
[#23054] [Bug #1326] Failing unit tests on windows — Charlie Savage <redmine@...>
Bug #1326: Failing unit tests on windows
[#23060] [Bug #1327] CSV unit test failures on windows — Charlie Savage <redmine@...>
Bug #1327: CSV unit test failures on windows
[#23063] [Bug #1332] Reading file on Windows is 500x slower then with previous Ruby version — Damjan Rems <redmine@...>
Bug #1332: Reading file on Windows is 500x slower then with previous Ruby version
Issue #1332 has been updated by Roger Pack.
Hello,
[#23075] [Bug #1336] Change in string representation of Floats — Brian Ford <redmine@...>
Bug #1336: Change in string representation of Floats
Issue #1336 has been updated by Roger Pack.
On Fri, Apr 3, 2009 at 11:49 PM, Roger Pack <redmine@ruby-lang.org> wrote:
Issue #1336 has been updated by Roger Pack.
Hi,
Hi,
Hi,
Gary Wright wrote:
[#23082] [Bug #1341] pthread_cond_timedwait failing in 1.9.1-p0 thread tests — Graham Agnew <redmine@...>
Bug #1341: pthread_cond_timedwait failing in 1.9.1-p0 thread tests
[ruby-core:23035] Re: Ruby Time
> It solves the maintainance problem. Good. > > However, it needs a configuration for $__tz_path. > No configuration is much better. > > I don't think all Ruby user configure it. This can be autoconfigured of course. > Also, if time2 supports out of time_t, the timezone db in OS > is not useful. Olson tz database uses 64 bit representation independently from time_t size. > So you may wish time2 installs it's own > timezone db. But it causes the maintainance problem again. > It seems you have a plan for that. Unfortunatly I haven't, and this is the biggest problem. > There is no such problem if we store a time offset (not > timezone) in Time object, even if we extend Time to support > out of time_t. > > I found marshal forget the timezone in time2: > > % ../bin/ruby -Ilib -rtime2 -e ' > p TimeZone.local > t = Time.local(2000).localtime(TimeZone["US/Pacific"]) > p t > p Marshal.load(Marshal.dump(t)) > ' > #<TimeZone: Japan> > 1999-12-31 07:00:00 -0800 > 2000-01-01 00:00:00 +0900 > > It seems time2's Marshal.load uses the local time. > > Basically, marshal preserves the object. > So someone may request to preserve the timezone by marshal. > > But it is a difficult problem. > > If timezone name is marshaled with the time, the timezone > may not exist at Marshal.load because timezone database is > OS dependent. (using $__tz_path is assumed.) > For example, some OS (GNU/Linux) provieds "Japan" > timezone but some other OS (FreeBSD) don't provide it. > > If timezone data itself is marshaled, it may be obsoleted > between Marshal.dump and Marshal.load due to DST rule change > and leap second determination. It is possible if the > marshaled data is stored in a file/DB. It is difficult to > update the marshaled timezones in a file/DB. > > There is no such problem if we store a time offset (not > timezone) in Time object because a time offset is easily > marshalled as a number and it will not be obsoleted. This can be solved by marshaling both, time zone name and offset. If we have problem with time zone name - we can use offset. > > As the previous example, time2 find "Japan" timezone as > #<TimeZone: Japan> in my environment. This is interesting > because it is difficult to know the current timezone name. > > It seems that time2 scans the timezone directory. It needs > many open system call. It makes Ruby slow. > > % time ../bin/ruby -Ilib -rtime2 -e 'Time.now' > ../bin/ruby -Ilib -rtime2 -e 'Time.now' 0.14s user 0.06s system 99% cpu 0.202 total > % time ../bin/ruby -Ilib -rtime2 -e 'Time.now' > ../bin/ruby -Ilib -rtime2 -e 'Time.now' 0.14s user 0.06s system 98% cpu 0.199 total > % time ../bin/ruby -Ilib -rtime2 -e 'Time.now' > ../bin/ruby -Ilib -rtime2 -e 'Time.now' 0.13s user 0.06s system 98% cpu 0.199 total > > % time ruby -e 'Time.now' > ruby -e 'Time.now' 0.02s user 0.00s system 95% cpu 0.021 total > % time ruby -e 'Time.now' > ruby -e 'Time.now' 0.02s user 0.00s system 91% cpu 0.022 total > % time ruby -e 'Time.now' > ruby -e 'Time.now' 0.02s user 0.00s system 94% cpu 0.021 total > > time2 has ~0.18 sec overhead. I doubt if 0.18 second per process is a big problem. And this can be avoided by setting TZ enviroment variable. > Also, even if a timezone is found, it is possible that it is > not exactly same as the system timezone. For example, time2 > can't use the system timezone directly on a OS which don't > use Olson time zone database. If the timezone with time2 is > different from the system timezone, Ruby behaves > inconsistently to all other programs (except PHP and > PostgreSQL?) on the OS. I can imagine it, but it will be possible only with exotic systems. > There is no such problem if we store a time offset (not > timezone) in Time object because it doesn't need timezones > other than the system timezone. > > I think multiple timezone support should be separated as > external library. > > I guess it will be used to personalize a date in web > applications. If so, timezone library can be used at > constructing a web page. I don't see a necessity that Time > object refer a timezone. There are one main problem with offset: it isn't fixed for fixed place (example with new york and manaus here http://groups.google.com/group/ruby-core-google/msg/f00c55f56482fc73), and I don't known how to solve it.