We in the JRuby project are working to get Rails to work successfully.
However, the array-indexed block parameter is not something currently
supported in JRuby:
x = {}
[1,2].each {|x[:foo]|}
This is not used extensively in the Rails code, but it''s used enough to
cause things to break in JRuby. We have been modifying the above to use a
temporary local variable, but obviously it''s not ideal. I emailed the
Ruby
Core list to ask how this behavior is implemented in C Ruby, and Matz''s
response seems to indicate that it will eventually be unsupported.
So my question is this: Would it not be reasonable to eliminate the few uses
of this unusual block parameter format right now? Of course I have selfish
motives; this behavior is a bit unusual and we would rather not have to
implement it if it will go away in the future. However, we want very much
the ability to run Rails in JRuby, and if we must we must.
Thoughts?
---------- Forwarded message ----------
From: Yukihiro Matsumoto <matz@ruby-lang.org>
Date: Mar 27, 2006 12:07 AM
Subject: Re: Tricky block args
To: ruby-core@ruby-lang.org
Hi,
In message "Re: Tricky block args"
on Mon, 27 Mar 2006 13:54:58 +0900, "Charles O Nutter" <
headius@headius.com> writes:
|We are trying to implement some missing block arg functionality. Could
|someone knowledgable about the more unusual methods of declaring block args
|point us to where in the C code it is implemented? Specifically, the
ability
|to specify an array or hash location as the target for a block param:
|
|x = [0]
|[1,2].each {|x[0]|}
The assignment to x[0] is done in assign() function, especially at the
code after /* array set */ comment. It''s called from rb_yield_0().
FYI, in the future, block parameters will be restricted to local
variables only, so that I don''t recommend using something other than
local variables for the parameters.
matz.
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060327/995d45c9/attachment.html
Charles O Nutter wrote:> We in the JRuby project are working to get Rails to work successfully. > However, the array-indexed block parameter is not something currently > supported in JRuby: > > x = {} > [1,2].each {|x[:foo]|} > > This is not used extensively in the Rails code, but it''s used enough to > cause things to break in JRuby. We have been modifying the above to use > a temporary local variable, but obviously it''s not ideal. I emailed the > Ruby Core list to ask how this behavior is implemented in C Ruby, and > Matz''s response seems to indicate that it will eventually be unsupported. > > So my question is this: Would it not be reasonable to eliminate the few > uses of this unusual block parameter format right now? Of course I have > selfish motives; this behavior is a bit unusual and we would rather not > have to implement it if it will go away in the future. However, we want > very much the ability to run Rails in JRuby, and if we must we must.You might have more luck asking this over on rails-core (if you haven''t already)... This is a bit more in-depth than what us muggles usually deal with :-) Interesting that the syntax is going to be deprecated, though... -- Alex
Thanks for the help...I wasn''t aware of the core list (though I figured something like that would have to exist).. On 3/27/06, Alex Young <alex@blackkettle.org> wrote:> > Charles O Nutter wrote: > > We in the JRuby project are working to get Rails to work successfully. > > However, the array-indexed block parameter is not something currently > > supported in JRuby: > > > > x = {} > > [1,2].each {|x[:foo]|} > > > > This is not used extensively in the Rails code, but it''s used enough to > > cause things to break in JRuby. We have been modifying the above to use > > a temporary local variable, but obviously it''s not ideal. I emailed the > > Ruby Core list to ask how this behavior is implemented in C Ruby, and > > Matz''s response seems to indicate that it will eventually be > unsupported. > > > > So my question is this: Would it not be reasonable to eliminate the few > > uses of this unusual block parameter format right now? Of course I have > > selfish motives; this behavior is a bit unusual and we would rather not > > have to implement it if it will go away in the future. However, we want > > very much the ability to run Rails in JRuby, and if we must we must. > > You might have more luck asking this over on rails-core (if you haven''t > already)... This is a bit more in-depth than what us muggles usually > deal with :-) Interesting that the syntax is going to be deprecated, > though... > > > -- > Alex > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060327/9c8c4fb6/attachment.html
I sent this to the main rails list, but it probably belongs here. I
don''t
think it would be difficult to repair the block params in question, and it
would certainly be better to do it before Matz & Co remove support for the
other syntax.
Thoughts?
---------- Forwarded message ----------
We in the JRuby project are working to get Rails to work successfully.
However, the array-indexed block parameter is not currently supported in
JRuby:
x = {}
[1,2].each {|x[:foo]|}
This is not used extensively in the Rails code, but it''s used enough to
cause things to break in JRuby. We have been modifying the above to use a
temporary local variable, but obviously it''s not ideal. I emailed the
Ruby
Core list to ask how this behavior is implemented in C Ruby, and Matz''s
response (below) seems to indicate that it will eventually be unsupported.
So my question is this: Would it not be reasonable to eliminate the few uses
of this unusual block parameter format right now? Of course I have selfish
motives; this behavior is a bit unusual and we would rather not have to
implement it if it will go away in the future. However, we want very much
the ability to run Rails in JRuby, and if we must we must.
Thoughts?
---------- Forwarded message ----------
From: Yukihiro Matsumoto <matz@ruby-lang.org>
Date: Mar 27, 2006 12:07 AM
Subject: Re: Tricky block args
To: ruby-core@ruby-lang.org
Hi,
In message "Re: Tricky block args"
on Mon, 27 Mar 2006 13:54:58 +0900, "Charles O Nutter" <
headius@headius.com> writes:
|We are trying to implement some missing block arg functionality. Could
|someone knowledgable about the more unusual methods of declaring block args
|point us to where in the C code it is implemented? Specifically, the
ability
|to specify an array or hash location as the target for a block param:
|
|x = [0]
|[1,2].each {|x[0]|}
The assignment to x[0] is done in assign() function, especially at the
code after /* array set */ comment. It''s called from rb_yield_0().
FYI, in the future, block parameters will be restricted to local
variables only, so that I don''t recommend using something other than
local variables for the parameters.
matz.
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
On Mar 27, 2006, at 11:36 AM, Charles O Nutter wrote:> So my question is this: Would it not be reasonable to eliminate the > few uses of this unusual block parameter format right now? Of > course I have selfish motives; this behavior is a bit unusual and > we would rather not have to implement it if it will go away in the > future. However, we want very much the ability to run Rails in > JRuby, and if we must we must.Sounds like a fine idea. I''ve created a ticket for this: http://dev.rubyonrails.org/ticket/4440 Feel free to attach any patches you have that partially or fully eliminate this pattern.
Absolutely, I''ll send what I have. I needed to modify a number of the script/ scripts to get things working. Would you prefer patches against trunk or against one of the release branches? On 3/27/06, Nicholas Seckar <nseckar@gmail.com> wrote:> > > On Mar 27, 2006, at 11:36 AM, Charles O Nutter wrote: > > > So my question is this: Would it not be reasonable to eliminate the > > few uses of this unusual block parameter format right now? Of > > course I have selfish motives; this behavior is a bit unusual and > > we would rather not have to implement it if it will go away in the > > future. However, we want very much the ability to run Rails in > > JRuby, and if we must we must. > > Sounds like a fine idea. I''ve created a ticket for this: > > http://dev.rubyonrails.org/ticket/4440 > > Feel free to attach any patches you have that partially or fully > eliminate this pattern. > > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >-- Charles Oliver Nutter @ headius.blogspot.com JRuby Developer @ jruby.sourceforge.net Application Architect @ www.ventera.com _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
On Mar 27, 2006, at 2:39 PM, Charles O Nutter wrote:> Absolutely, I''ll send what I have. I needed to modify a number of > the script/ scripts to get things working. Would you prefer patches > against trunk or against one of the release branches?Patches against trunk would be best.