We still need to circle back to the installer question soon, but I
thought of something today...why couldn't we spin an installer that
bundles a build of MLVM, the experimental openjdk branch with full
invokedynamic support?
For folks running JRuby standalone, it would be an easy way to get
them o
Charlie,
Let us discuss this when we meet up sometime later this week.
Subbu.
On Sat, Aug 1, 2009 at 9:46 AM, Charles Oliver Nutter
wrote:
> I tweaked the new IR compiler to support Duby's type declarations last
> night. This is intended for Duby use, but if we ever thought the
> politics of ty
Hey, I got an "IRB" working on Android tonight. It was pretty easy.
The details are on my blog post:
http://blog.headius.com/2009/08/return-of-ruboto.html
This is still just running in interpreted mode, but it's a second
demonstration that JRuby can run well on the phone. The additional
goals I o
No one should be using it, but for the sake of completeness, the
distribution tarballs should be in:
http://dist.codehaus.org/jruby/1.1.5/jruby-*-1.1.5.*
rather than
http://dist.codehaus.org/jruby/jruby-*-1.1.5.*
Hiro
-
To
Does this file exist:
build/classes/jruby/org/jruby/RubyArray$i_method_multi$RUBYINVOKER$pop.class
Do you have a jruby.jar in your system classpath?
I assume your github pull works fine...
- Charlie
On Sat, Aug 1, 2009 at 3:34 PM, Joseph Athman wrote:
> It's still not working for me. Is it a
It's still not working for me. Is it a problem that I have JRuby on my path
in another place and then I'm trying to do a build here? I typically just
follow trunk on github so I just pulled this version from kenai in another
folder and I'm trying to work on this separately from the version of JRu
Hmm...try doing another "ant clean jar". It looks like a build failed
or there's some leftover crud in src_gen from a previous build.
- Charlie
On Sat, Aug 1, 2009 at 10:42 AM, Joseph Athman wrote:
> This is great to have instructions like this, it will help me a lot. I'm
> having one problem th
This is great to have instructions like this, it will help me a lot. I'm
having one problem though, anyone know what this error is? I'm just
following Charlie's instructions here but am stuck with this error during
the build.
_gmc_internal_:
[echo] Generating invokers...
[echo] Compilin
Some of you have asked about 1.8.7 support, and we've decided to just
make it happen for JRuby 1.4. But we could certainly use some help
getting everything in place and testing it.
If you'd like to help, here's a quick howto:
1. Check out repository from kenai.com instead of github (we're not
pus
I tweaked the new IR compiler to support Duby's type declarations last
night. This is intended for Duby use, but if we ever thought the
politics of type hinting/gradual typing allowed it we could certainly
use this to start propagating/enforcing explicit type information.
Subbu, I'd like to talk wi
On Sat, Aug 1, 2009 at 5:51 AM, Thomas E Enebo wrote:
> For clarification (for more general JI audience), I think in theory we
> should consider changing JRuby so:
>
> beanHome = PortableRemoteObject.narrow(home, BeanHome)
>
> I believe this is more or less unambiguous. I really don't think
> a
On Sat, Aug 1, 2009 at 6:03 AM, Thomas E Enebo wrote:
> I may even suggest taking it a step further and isolating the failure
> cases to a synthetic method (sans the invocation to the synthetic
> method). The smaller we generate sections of code the easier things
> will be for hotspot. I guess I
On Sat, Aug 1, 2009 at 7:58 PM, Ola Bini wrote:
> Ola Bini wrote:
>>
>> Hi,
>>
>> In the process of porting to 1.8.7 it has become obvious that most of our
>> remaining tags for specs are based on pieces that are marked as ruby_bug in
>> the specs.
>>
>> I would like to open up the discussion of wh
On Sat, Aug 1, 2009 at 12:20 AM, Charles Oliver
Nutter wrote:
> On Fri, Jul 31, 2009 at 12:20 AM, Subramanya Sastry
> wrote:
>> To see this, it is useful to think of all ruby classes carrying with them a
>> version number. [ Technically, this can be done at a more fine-grained
>> level (i.e. at t
Ola Bini wrote:
Hi,
In the process of porting to 1.8.7 it has become obvious that most of
our remaining tags for specs are based on pieces that are marked as
ruby_bug in the specs.
I would like to open up the discussion of whether JRuby should be
bug-by-bug compliant with a specific version
On Fri, Jul 31, 2009 at 5:31 PM, Mikael
Lammentausta wrote:
> I solved my problem. It was really simple in the end :)
Sorry. I should have given the full snippet. This was what I was
recommending you do :)
For clarification (for more general JI audience), I think in theory we
should consider ch
Hi,
In the process of porting to 1.8.7 it has become obvious that most of
our remaining tags for specs are based on pieces that are marked as
ruby_bug in the specs.
I would like to open up the discussion of whether JRuby should be
bug-by-bug compliant with a specific version, or whether we s
Here's an updated patch that is closer to the Ruby implementation
approach. Now passes the specific rspec tests, but fails on another:
[java] Hash#merge! shouldn't raise spurious RuntimeErrors FAILED
[java] Expected to not get RuntimeError
[java] /Users/gerald/dev/jruby/spec/mspe
18 matches
Mail list logo
