Thanks for the clarifications subbu...This all makes sense.
More generically I consider ANY variable which a block you potentially
access/manipulate as captured by the block/closure. If you eval in
that block the eval can potentially access any variable it can reach
from the blocks scope. Since
> >
> > Consider this:
> >
> > o.m1(..)
> > o.m2(..)
> >
> > Since type of o hasn't changed between the 2 calls, you can skip the
> method
> > table load for the second call.Anyway, I need to understand the call
> > protocol in greater detail to comment more.
>
> This is an interesting use-case
On Wed, Jul 22, 2009 at 2:11 PM, Subramanya Sastry wrote:
>
>
>> Obviously the IR already captures whether a closure accesses its own
>> variables or captured variables, right?
>
> Implicitly yes. This information will become explicit after reaching defs /
> live variable analysis is done to know
Hi Asiri,
On Thu, Jul 23, 2009 at 5:08 AM, Asiri
Rathnayake wrote:
> Hi,
>
> I'm have ported JSR223-JRuby Engine to work with JRuby 1.3.0 version (few
> minor adjustments only). However when using this engine with JRuby 1.3.0 I
> get an annoying error log which says:
>
> "Error, could not compile;
Hi,
I'm have ported JSR223-JRuby Engine to work with JRuby 1.3.0 version (few
minor adjustments only). However when using this engine with JRuby 1.3.0 I
get an annoying error log which says:
"Error, could not compile; pass -d or -J-Djruby.jit.logging.verbose=true for
more details"
Following is t
