jira.codehaus.org

[JRUBY-4522] [windows] File.join fails one RubySpec test

Fri, 20 Apr 2012 17:03:00 -0500

mspec ci -t j core\file\join_spec.rb
jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2010-01-26 d00b6d6) (Java HotSpot(TM) Client VM 1.6.0_18) [x86-java]
....F..........

1)
File.join joins parts using File::ALT_SEPARATOR on windows FAILED
Expected "C:/windows"
 to equal "C:\\windows"

D:/work/jruby-dev/rubyspec.git/core/file/join_spec.rb:23
D:/work/jruby-dev/rubyspec.git/core/file/join_spec.rb:3
D:/work/jruby-dev/rubyspec.git/core/file/join_spec.rb:55:in `load'
D:/work/jruby-dev/mspec.git/bin/mspec-ci:8

Finished in 0.069000 seconds

1 file, 15 examples, 44 expectations, 1 failure, 0 errors

[JRUBY-3944] [1.9] IO should handle options :binmode and :textmode

Thu, 5 Jan 2012 17:53:18 -0600

Right now the code is commented in RubyIO.java:3524 because I don't know how ruby 1.9 handles these options

[JRUBY-5530] Ant_import doesn't support a URL as an import

Tue, 3 Jan 2012 00:32:44 -0600

I'm trying to use ant_import, and trying to import a ant script located on our perforce server. Instead of mapping a workspace, I just use p4web so I can always get the latest version. So http://perforce:8080/depot/buildscripts/build.xml fails to load because ant_import requires a filename. Currently I stream the file locally, then load it, but it would be much more convenient to accept a URL.

[JRUBY-3539] Cannot run scripts in classpath (but not on filesystem) without using -r and a false -e argument

Mon, 19 Dec 2011 19:15:01 -0600

Since a recent update, using the -r command line switch to require a file will block waiting for input from the console. This appears to be the correct behaviour.

Since this is now happening, the -r switch can no longer be used to run a script from the classpath, unless a 'fake' -e switch is used.

A possible solution would be for jruby to also search for the initial script in the classpath, instead of only looking in the filesystem.

[JRUBY-3137] Update JavaUtil.coerceNumericToType() to coerce numerics to the Java Serializable interface

Sat, 17 Dec 2011 18:34:52 -0600

Currently, if you try to pass a Ruby Fixnum to a Java method whose argument type is Serializable, it fails with a message that it can't coerce a Fixnum to Serializable. Well, I'm not going to accept such a defeatist attitude!!! Yes, we can coerce a Fixnum to Serializable, and this patch proves it.

[JRUBY-4445] FileTest.identical? is wrong

Wed, 14 Sep 2011 20:50:04 -0500

FileTest.identical? is currently implemented in such a way that it only compares stat info of two files, so different files with same stats would be considered equal, which is obviously wrong. This happens more often on Windows, since stat info (dates) are with granularity 1 sec or so. So the two files created quickly one after another would be considered the same!

This leads to rubyspec failures:

D:\work\jruby-dev\rubyspec.git>mspec -t j core\filetest\identical_spec.rb
jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2010-01-10 c3a86fb) (Java HotSpot(TM) Client VM 1.6.0_17) [x86-java]
...F

1)
FileTest.identical? returns true if both named files are identical FAILED
Expected true to be false
D:/work/jruby-dev/rubyspec.git/shared/file/identical.rb:41
D:/work/jruby-dev/rubyspec.git/core/filetest/identical_spec.rb:4
D:/work/jruby-dev/rubyspec.git/core/filetest/identical_spec.rb:55:in `load'
D:/work/jruby-dev/mspec.git/bin/mspec-run:8

MRI compares not only the sizes and stat info, but the file names as well (after proper expanding).

[JRUBY-5458] Add specs for become_java? interface impl, if none exist already

Mon, 7 Feb 2011 11:16:52 -0600

For ~~JRUBY-4271~~, we fixed become_java? working with interfaces properly, but no specs were added. Add them.

[JRUBY-5078] pty.rb should be converted to use posix_spawn()

Fri, 22 Oct 2010 17:14:30 -0500

pty.rb currently uses fork()+exec() via FFI. This could be converted to use posix_spawn() to exec the child process, due to the flakiness of forking the jvm and continuing to run bytecode code in the child.

[JRUBY-3113] First script engine call can incorrectly report error as in a builtin, subsequent identical calls do not

Thu, 25 Feb 2010 14:54:58 -0600

from #jruby:
CaneToad: it seems the first time you invoke the script engine, it can report the error to be in the builtins when it isn't...doesn't happens on subsequent calls to the script engine
headius: hmmm
...
headius: I'd say go ahead and file it

Java code to reproduce:
////////////////////////////////////////////////////////////////////

import javax.script.*;
public class jruby2 {
  public static void run(ScriptEngine engine, String msg) {
    System.err.println(msg);
    try {
      engine.eval("a=Hello");
    } catch(ScriptException e) {
      e.getCause().printStackTrace(System.err);
    }
  }
  public static void main(String [] args) throws Exception {
    ScriptEngineManager manager = new ScriptEngineManager(); 
    ScriptEngine engine = manager.getEngineByName("jruby");
    run(engine, "------------ first");
    run(engine, "------------ second");
  }
}

////////////////////////////////////////////////////////////////////

Here's what it gives:

[dcampbel@clevo ~]$ javac -classpath .:jruby.jar:jruby-engine.jar jruby2.java
[dcampbel@clevo ~]$ java -classpath .:jruby.jar:jruby-engine.jar jruby2
------------ first
/builtin/javasupport.rb:49:in `const_missing': uninitialized constant Hello (NameError)
        from <unknown>:1
        ...internal jruby stack elided...
        from Module.const_missing(<unknown>:1)
        from (unknown).(unknown)(:1)
------------ second
null:1:in `const_missing': uninitialized constant Hello (NameError)
        from <unknown>:1
        ...internal jruby stack elided...
        from Module.const_missing(<unknown>:1)
        from (unknown).(unknown)(:1)

Notice that the first call reports the error in a builtin, while the second identical call does not

[JRUBY-4516] Load a properties file for distribution-presets

Wed, 17 Feb 2010 16:44:19 -0600

Similarly to JFFI-2 issue, it would be nice to have a properties file to create at build time to set in information such as the home path, the lib path, the bin path and so on, so that it does not have to be given/calculated by the launcher script at runtime each time.

[JRUBY-3786] RubyGems tests are not green; fix remaining failures/errors

Thu, 11 Feb 2010 19:24:49 -0600

RubyGems tests do not run green, and I don't think we've ever actually looked into them to get them green. We should do that now.

JRuby limited openssl loaded. gem install jruby-openssl for full support.
http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
Loaded suite RubyGemsTests
Started
.F.FFF..F...F.FF...F.F............FFF.....F..F..........................EEEEEEE..................F.............................F....F....................EE.....FF..F................................E....EE.E.F..EF..EE.........E..E.................EE.FE.EEF..RubyString.java:3893:in `oct': java.lang.ArrayIndexOutOfBoundsException: 8
        from org/jruby/RubyString$i_method_0_0$RUBYINVOKER$oct.gen:-1:in `call'
        from CachingCallSite.java:75:in `call'
        from tar_header.rb:108:in `__file__'
        from JittedMethod.java:145:in `call'
        from DefaultMethod.java:154:in `call'
        from CachingCallSite.java:115:in `call'
        from tar_reader.rb:59:in `block_0$RUBY$__block__'

The crash here is reported in my previous bug (this bug number) minus one and would need to be fixed first to get the tests running.

[JRUBY-4007] Rubyspec failures #hash for Array, Hash, Struct with recursive hashes

Tue, 5 Jan 2010 15:44:26 -0600

[java] 1)
[java] Array#hash returns the same hash for recursive arrays FAILED
[java] Expected 2
[java] to equal 0
[java]
[java] /opt/work/jruby.git/spec/ruby/core/array/hash_spec.rb:27
[java] /opt/work/jruby.git/spec/ruby/core/array/hash_spec.rb:4
[java] /opt/work/jruby.git/spec/ruby/core/array/hash_spec.rb:55:in `load'
[java]
[java] 2)
[java] Array#hash returns the same hash for recursive arrays through hashes FAILED
[java] Expected 995
[java] to equal 993
[java]
[java] /opt/work/jruby.git/spec/ruby/core/array/hash_spec.rb:33
[java] /opt/work/jruby.git/spec/ruby/core/array/hash_spec.rb:4
[java] /opt/work/jruby.git/spec/ruby/core/array/hash_spec.rb:55:in `load'

[java] 5)
[java] Hash#hash returns the same hash for recursive hashes FAILED
[java] Expected 993
[java] to equal 0
[java]
[java] /opt/work/jruby.git/spec/ruby/core/hash/hash_spec.rb:28
[java] /opt/work/jruby.git/spec/ruby/core/hash/hash_spec.rb:9
[java] /opt/work/jruby.git/spec/ruby/core/hash/hash_spec.rb:55:in `load'
[java]
[java] 6)
[java] Hash#hash returns the same hash for recursive hashes through arrays FAILED
[java] Expected 995
[java] to equal 2
[java]
[java] /opt/work/jruby.git/spec/ruby/core/hash/hash_spec.rb:34
[java] /opt/work/jruby.git/spec/ruby/core/hash/hash_spec.rb:9
[java] /opt/work/jruby.git/spec/ruby/core/hash/hash_spec.rb:55:in `load'
[java]

[java] 9)
[java] Struct#hash returns the same hash for recursive structs ERROR
[java] SystemStackError: stack level too deep
[java] /opt/work/jruby.git/spec/ruby/core/struct/hash_spec.rb:26
[java] /opt/work/jruby.git/spec/ruby/core/struct/hash_spec.rb:4
[java] /opt/work/jruby.git/spec/ruby/core/struct/hash_spec.rb:55:in `load'

See "redmine #1852" for the MRI bug.