[#22684] [Bug #1247] YAML::load converts some dates into strings — Matthew Wilson <redmine@...>

Bug #1247: YAML::load converts some dates into strings

10 messages 2009/03/05

[#22725] [Bug #1253] Fix MSVC Build Issues — Charlie Savage <redmine@...>

Bug #1253: Fix MSVC Build Issues

13 messages 2009/03/07

[#22727] Moving ruby 1.9.1 forward on windows — Charlie Savage <cfis@...>

Hi everyone,

14 messages 2009/03/08

[#22731] [Bug #1255] += for large strings egrigiously slow — James Lee <redmine@...>

Bug #1255: += for large strings egrigiously slow

11 messages 2009/03/08

[#22736] Ruby 1.9.1 and tail recursion optimization — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...>

Moin, moin!

13 messages 2009/03/08
[#22739] Re: Ruby 1.9.1 and tail recursion optimization — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...> 2009/03/08

Wolfgang N疆asi-Donner 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

7 messages 2009/03/08

[#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

21 messages 2009/03/10

[#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

8 messages 2009/03/10

[#22892] Ruby Time — valodzka <valodzka@...>

Got tired of current ruby Time limitation, I have written this -

24 messages 2009/03/14
[#22949] Re: Ruby Time — Tanaka Akira <akr@...> 2009/03/19

In article <9e19ed87-9d12-4f98-af3c-bd49a71b0bd4@p11g2000yqe.googlegroups.com>,

[#22974] Re: Ruby Time — valodzka <valodzka@...> 2009/03/20

[#22977] Re: Ruby Time — Urabe Shyouhei <shyouhei@...> 2009/03/20

valodzka wrote:

[#22981] Re: Ruby Time — valodzka <valodzka@...> 2009/03/21

> I bet you'll get tired of updating that database. There's a major difference

[#22893] [Feature #1291] O_CLOEXEC flag missing for Kernel::open — David Martin <redmine@...>

Feature #1291: O_CLOEXEC flag missing for Kernel::open

10 messages 2009/03/15

[#22939] [Bug #1303] A name considered a local variable on RHS of an assignment that defines it — Tomas Matousek <redmine@...>

Bug #1303: A name considered a local variable on RHS of an assignment that defines it

8 messages 2009/03/19

[#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

11 messages 2009/03/30

[#23075] [Bug #1336] Change in string representation of Floats — Brian Ford <redmine@...>

Bug #1336: Change in string representation of Floats

37 messages 2009/03/31
[#23179] [Bug #1336] Change in string representation of Floats — Roger Pack <redmine@...> 2009/04/11

Issue #1336 has been updated by Roger Pack.

[#23181] Re: [Bug #1336] Change in string representation of Floats — Brent Roman <brent@...> 2009/04/11

[#23186] Re: [Bug #1336] Change in string representation of Floats — Yukihiro Matsumoto <matz@...> 2009/04/12

Hi,

[#23187] Re: [Bug #1336] Change in string representation of Floats — Brent Roman <brent@...> 2009/04/13

[#23188] Re: [Bug #1336] Change in string representation of Floats — Yukihiro Matsumoto <matz@...> 2009/04/13

Hi,

[ruby-core:22820] Re: Moving ruby 1.9.1 forward on windows

From: Roger Pack <rogerdpack@...>
Date: 2009-03-10 19:15:57 UTC
List: ruby-core #22820
>> 2) It allows mingw built binaries to interop with VC ones--binaries
>> are much faster if built by gcc [1 #5].
>
> That's an invalid comparison for a couple of reasons. irst you would
> compare VC2008 versus gcc 4.3. xcept you can't, because gcc 4.x is not
> officially released for windows so you're stuck with gcc 3.4.5.

Yeah I think the real comparison currently is VC2008 versus gcc 3.4.5
Here's a rough hack I did of it once [not a great comparison, but it
shows gcc 3.4.5 being still faster than VC2008
http://groups.google.com/group/ruby-benchmark-suite/browse_thread/thread/b30155e85bb77bfe/07623f48138fcf64?lnk=gst&q=windows#07623f48138fcf64
].


> Now, you do bring up an interesting point, which is instead of favoring a
> compiler favor a runtime library (msvcr90 being the obvious choice). n
> other words, VC2008 will always link against that one and you can mingw to
> link against it also. he downside is that you exclude VC2003 or the
> upcoming VC2010.

True it might be worthwhile to "bless" a runtime.  Theoretically this
could work with other compilers, as well, than its default.  I've seen
blog posts of people making VC2005 link against msvcrt.dll [i.e. VC6]
and also, apparently you can link mingw against other versions of
msvcrt.dll [1].


>> Another option would be to release a mingw only OCI linked against
>> msvcr90.dll, then instruct extension developers on how to release
>> binaries that "pretend" to be mingw though they're only "mingw
>> compatible."
>
> There is no pretending here. hose would be mingw binaries linked against
> msvcr90.dll. hat is supported.  have no idea if it works cross-compiling
> though.

I was just thinking that if desired, the current naming scheme could
be used and still fit.  Kind of :)

>> Or perhaps rubygems could be patched to recognize compatible binaries.
>
> Not sure what you mean. y goal is that an extension developer only has o
> release 1 binary for windows per ruby version.

For that one I was meaning rubygems could perhaps note "oh you're on
mingw, well I have a mswin32 binary that you can use even though it's
not your compiler" and install it appropriately.   Some change needs
to happen, not sure though.

Thanks!
-=r
[1] http://www.develer.com/oss/GccWinBinaries at the bottom.

In This Thread

Prev Next