[#10853] Why limit class def to a constant or colon node? — Charles Oliver Nutter <charles.nutter@...>

Is there a historical reason why I can't do something like these:

12 messages 2007/04/03

[#10933] Cannot build with extra library path if previous version already installed — <noreply@...>

Bugs item #10140, was opened at 2007-04-16 17:32

10 messages 2007/04/16
[#10934] Re: [ ruby-Bugs-10140 ] Cannot build with extra library path if previous version already installed — nobu@... 2007/04/16

Hi,

[#10960] Re: [ ruby-Bugs-10140 ] Cannot build with extra library path if previous version already installed — "Michal Suchanek" <hramrach@...> 2007/04/18

On 4/16/07, nobu@ruby-lang.org <nobu@ruby-lang.org> wrote:

[#10967] Re: [ ruby-Bugs-10140 ] Cannot build with extra library path if previous version already installed — Nobuyoshi Nakada <nobu@...> 2007/04/19

Hi,

[#10970] Re: [ ruby-Bugs-10140 ] Cannot build with extra library path if previous version already installed — "Michal Suchanek" <hramrach@...> 2007/04/19

On 4/19/07, Nobuyoshi Nakada <nobu@ruby-lang.org> wrote:> Hi,>> At Wed, 18 Apr 2007 20:21:44 +0900,> Michal Suchanek wrote in [ruby-core:10960]:> > Yes. And this should also apply to extensions. The mkmf tests are now> > fine but the extension is linked with -L/sw/lib before -L../..>> Indeed.>>> Index: configure.in> ===================================================================> --- configure.in (revision 12191)> +++ configure.in (working copy)> @@ -1385,5 +1385,4 @@ if test "$enable_rpath" = yes; then> fi>> -LDFLAGS="-L. $LDFLAGS"> AC_SUBST(ARCHFILE)>This would break the previous fix so I did not even try to apply this ^

[#11003] miniruby loads extensions from already installed ruby — <noreply@...>

Bugs item #10303, was opened at 2007-04-23 10:44

10 messages 2007/04/23

[#11025] gsub with backslash characters in replacement string — "Adam Bozanich" <adam.boz@...>

Hello, spotted this one the other day:

10 messages 2007/04/26

Re: Ruby 1.9/1.8 compatibility: String#lines

From: murphy <murphy@...>
Date: 2007-04-07 16:11:23 UTC
List: ruby-core #10891
> |It seems the most important change in 1.9, in terms of compatibility, is
> |that String isn't Enumerable anymore. It breaks a lot of scripts on my
> |system.
> 
> I put "lines" before calling "each".
Maybe I didn't explain my problem well enough, sorry. If I do this, my
script can run with Ruby 1.9, sure.

But Ruby 1.8 says:

  undefined method `lines' for "Foo\nbar":String (NoMethodError)

so it won't run under both versions.

I feel that many people (me, for a start) will want to make their
libraries available for both versions in the next 2 or 3 years, if not
longer.

So I'm searching for a bullet-proof way to make String enumeration
transparent from 1.8/1.9.

The most simple way that comes to my mind is to add at least String#to_a
to Ruby 1.9, with the Ruby 1.8 behavior. This would still force the
people to adjust their libs, but at least they'll have an easy option
not to break backwards compatibility instead.

I dare to say that otherwise, something like the "dirty fix" from my
previous post is likely to show up in Rails 2.0, or whenever they decide
to go 1.9 ;)

> |I couldn't find an easy way to make scripts running under both 1.8 and 1.9:
> |
> |- String#each_line requires a block in 1.8, and writing each_line{}
> |  isn't really beautiful.
> 
> If you want to iterate on lines in a string, each_line is the best
> name to describe the behavior, I think.  YMMV.
yes, it is, but the problem is that each_line doesn't provide the
functionality of String#lines. it requires a block, and it doesn't
return an enumerator. so using each_line doesn't do the trick either.

by the way: I love the new Enumerators!
[murphy]

In This Thread