WHOA! This is most alarming. These kinds of inter-dependencies between
tests are really bad. Might not be the tests problem even, but
JRuby's.
I tried to figure out what's going on, and the results are scary, to
say the least :)
Essentially, in *both*, 1.8 and 1.9 mode, once JRuby executes
core/proc/new_spec.rb, it doesn't execute anything alse AT ALL, just
pretends :)
Take a look:
mspec -t j core/proc/new_spec.rb core
Here, I execute that evil proc/new_spec first, and then the entire
core specs, and the results are:
1427 files, 1 example, 2 expectations.
*TWO* expectations only. That explains also why you don't see the
String errors when running the whole core set, because proc/new is
before the string, and essentially the string specs are not executed
at all!!!
This is a major blocker, I'd say. And the spec in question that
breaks JRuby is:
# This raises a ThreadError on 1.8 HEAD. Reported as bug #1707
it "raises a LocalJumpError when context of the block no longer exists" do
def some_method
Proc.new { return }
end
res = some_method()
# Using raise_error here causes 1.9 to hang, so we roll our own
# begin/rescue block to verify that the exception is raised.
exception = nil
begin
res.call #### <-------------------- *** Commenting out this
line would allow to run other tests ***********
rescue LocalJumpError => e
exception = e
end
e.should be_an_instance_of(LocalJumpError)
end
Btw, MRI works just fine here, so it does look like JRuby's issue.
Thanks,
--Vladimir
On Sun, Nov 22, 2009 at 3:54 PM, Hirotsugu Asari <[email protected]> wrote:
> If I try running specs only on String, I get an
> .org.jcodings.exception.EncodingException, as shown in
> http://gist.github.com/240585
>
> I don't get this error if I run specs on core, but, obviously, this generates
> more errors than I would like to see.
>
> What might be wrong here?
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
