[jruby-dev] [jira] Created: (JRUBY-4426) We should have tags for 1.9 specs

2010-01-07 Thread Ola Bini (JIRA)
We should have tags for 1.9 specs
-

 Key: JRUBY-4426
 URL: http://jira.codehaus.org/browse/JRUBY-4426
 Project: JRuby
  Issue Type: Task
  Components: Ruby 1.9, RubySpec
Reporter: Ola Bini
Assignee: Thomas E Enebo


It would be very good to have the 1.9 specs tagged so that we can start running 
1.9 tests in CI.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email




[jruby-dev] [jira] Created: (JRUBY-4427) RubySpec: 1.9 parser issues preventing some specs from loading

2010-01-07 Thread Charles Oliver Nutter (JIRA)
RubySpec: 1.9 parser issues preventing some specs from loading
--

 Key: JRUBY-4427
 URL: http://jira.codehaus.org/browse/JRUBY-4427
 Project: JRuby
  Issue Type: Bug
  Components: Ruby 1.9, RubySpec
Affects Versions: JRuby 1.5
Reporter: Charles Oliver Nutter
Assignee: Thomas E Enebo


These prevent tagging and may have to be excluded if we can't get them to at 
least parse ok:

{noformat}
8)
An exception occurred during: Module#name ERROR
SyntaxError: 
/Users/headius/projects/jruby/spec/ruby/core/module/fixtures/name.rb:4: 
\303Invalid char `\303' ('#65475;') in expression
/Users/headius/projects/jruby/spec/ruby/core/module/fixtures/name.rb:18
/Users/headius/projects/jruby/spec/ruby/core/module/fixtures/name.rb:18:in 
`require'
/Users/headius/projects/jruby/spec/ruby/core/module/name_spec.rb:18
/Users/headius/projects/jruby/spec/ruby/core/module/name_spec.rb:12
/Users/headius/projects/jruby/spec/ruby/core/module/name_spec.rb:4
/Users/headius/projects/jruby/spec/ruby/core/module/name_spec.rb:55:in `load'

9)
An exception occurred during: loading 
/Users/headius/projects/jruby/spec/ruby/language/symbol_spec.rb
Proc.new with an associated block raises a LocalJumpError when context of the 
block no longer exists ERROR
SyntaxError: 
/Users/headius/projects/jruby/spec/ruby/language/versions/symbol_1.9.rb:3: 
empty symbol literalc = :''
  ^
/Users/headius/projects/jruby/spec/ruby/language/versions/symbol_1.9.rb:23
/Users/headius/projects/jruby/spec/ruby/language/versions/symbol_1.9.rb:23:in 
`require'
/Users/headius/projects/jruby/spec/ruby/language/symbol_spec.rb:74
/Users/headius/projects/jruby/spec/ruby/language/symbol_spec.rb:55:in `load'
{noformat}

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email




[jruby-dev] [jira] Created: (JRUBY-4428) rake test doesn't finish on JDK5 w/o policy files update

2010-01-07 Thread Hiroshi Nakamura (JIRA)
rake test doesn't finish on JDK5 w/o policy files update


 Key: JRUBY-4428
 URL: http://jira.codehaus.org/browse/JRUBY-4428
 Project: JRuby
  Issue Type: Test
  Components: OpenSSL
Affects Versions: JRuby-OpenSSL 0.6
Reporter: Hiroshi Nakamura
Assignee: Hiroshi Nakamura
Priority: Minor


{noformat}
PKCS7.java:774:in `dataDecode': org.jruby.ext.openssl.impl.PKCS7Exception: 
PKCS7[Method: 112,
 Reason: -1, Data: java.security.InvalidKeyException: Illegal key size]
from PKCS7.java:485:in `decrypt'
from PKCS7.java:503:in `decrypt'
from 
org/jruby/ext/openssl/PKCS7$i_method_0_0$RUBYINVOKER$decrypt.gen:-1:in `call'
from JavaMethod.java:635:in `call'
from DynamicMethod.java:194:in `call'
from CachingCallSite.java:329:in `cacheAndCall'
from CachingCallSite.java:188:in `call'
from CallTwoArgNode.java:59:in `interpret'
from FCallTwoArgNode.java:38:in `interpret'
from NewlineNode.java:104:in `interpret'
from BlockNode.java:71:in `interpret'
from InterpretedMethod.java:156:in `call'
from DefaultMethod.java:165:in `call'
from RubyClass.java:430:in `finvoke'
from RubyObject.java:1438:in `send'
from org/jruby/RubyObject$i_method_multi$RUBYINVOKER$send.gen:-1:in 
`call'
from JavaMethod.java:267:in `call'
from CachingCallSite.java:146:in `call'
from FCallOneArgNode.java:36:in `interpret'
from NewlineNode.java:104:in `interpret'
from BlockNode.java:71:in `interpret'
from RescueNode.java:225:in `executeBody'
from RescueNode.java:147:in `interpretWithJavaExceptions'
from RescueNode.java:110:in `interpret'
from EnsureNode.java:96:in `interpret'
from BeginNode.java:83:in `interpret'
from NewlineNode.java:104:in `interpret'
from BlockNode.java:71:in `interpret'
from EnsureNode.java:96:in `interpret'
from BeginNode.java:83:in `interpret'
from NewlineNode.java:104:in `interpret'
from BlockNode.java:71:in `interpret'
from InterpretedMethod.java:193:in `call'
from DefaultMethod.java:181:in `call'
from CachingCallSite.java:155:in `callBlock'
from CachingCallSite.java:162:in `call'
from CallOneArgBlockPassNode.java:60:in `interpret'
from NewlineNode.java:104:in `interpret'
from InterpretedBlock.java:373:in `evalBlockBody'
from InterpretedBlock.java:346:in `yield'
from InterpretedBlock.java:303:in `yield'
from Block.java:194:in `yield'
from RubyArray.java:1614:in `eachCommon'
from RubyArray.java:1621:in `each'
from org/jruby/RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$each.gen:-1:in 
`call'
from CachingCallSite.java:115:in `callBlock'
from CachingCallSite.java:122:in `call'
from CallNoArgBlockNode.java:64:in `interpret'
from NewlineNode.java:104:in `interpret'
from BlockNode.java:71:in `interpret'
from InterpretedMethod.java:193:in `call'
from DefaultMethod.java:181:in `call'
from CachingCallSite.java:319:in `cacheAndCall'
from CachingCallSite.java:157:in `callBlock'
from CachingCallSite.java:162:in `call'
from CallOneArgBlockPassNode.java:60:in `interpret'
from NewlineNode.java:104:in `interpret'
from InterpretedBlock.java:373:in `evalBlockBody'
from InterpretedBlock.java:346:in `yield'
from InterpretedBlock.java:303:in `yield'
from Block.java:194:in `yield'
from RubyArray.java:1614:in `eachCommon'
from RubyArray.java:1621:in `each'
from org/jruby/RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$each.gen:-1:in 
`call'
from CachingCallSite.java:299:in `cacheAndCall'
from CachingCallSite.java:117:in `callBlock'
from CachingCallSite.java:122:in `call'
from CallNoArgBlockNode.java:64:in `interpret'
from NewlineNode.java:104:in `interpret'
from BlockNode.java:71:in `interpret'
from InterpretedMethod.java:193:in `call'
from DefaultMethod.java:181:in `call'
from CachingCallSite.java:319:in `cacheAndCall'
from CachingCallSite.java:157:in `callBlock'
from CachingCallSite.java:162:in `call'
from CallOneArgBlockNode.java:60:in `interpret'
from NewlineNode.java:104:in `interpret'
from BlockNode.java:71:in `interpret'
from InterpretedMethod.java:137:in `call'
from DefaultMethod.java:157:in `call'
from CachingCallSite.java:289:in `cacheAndCall'
from CachingCallSite.java:108:in `call'
from CallNoArgNode.java:61:in `interpret'
from ReturnNode.java:88:in `interpret'
from NewlineNode.java:104:in `interpret'
from 

[jruby-dev] [jira] Created: (JRUBY-4429) Cross volume file moves does results in no target files created

2010-01-07 Thread JIRA
Cross volume file moves does results in no target files created
---

 Key: JRUBY-4429
 URL: http://jira.codehaus.org/browse/JRUBY-4429
 Project: JRuby
  Issue Type: Bug
Affects Versions: JRuby 1.4
 Environment: Mac OSX 10.6.2, 
java version 1.6.0_17
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

Linux gems 2.6.24-24
java version 1.6.0_16
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Client VM (build 14.2-b01, mixed mode, sharing)
Reporter: Tamás Cservenák
Assignee: Thomas E Enebo


I noticed this while using $ gem generate_index command from CLI (from JRuby 
1.4).

My environment is unchanged on both, Mac and Linux, hence the temporary files 
are written to /tmp (on both machines on root volume).

When I want to reindex gems that are _not_ on root volume, the result of 
generate index command is _nil_ (no file is written). The files are created and 
processed in /tmp (I can track those, the repository I reindex is huuge), and 
finally the working directory of Gem::Indexer from /tmp is deleted okay, but 
the files are not moved to their place on non-root volume.

Same happens while using jruby-complete-1.4.jar embedded into application, and 
invoking Gem::Indexer programmatically.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email




[jruby-dev] JRuby 1.5 feature: 10s of thousands of additional gems! (sourced from Maven)

2010-01-07 Thread Charles Oliver Nutter
If this doesn't make you weep tears of joy, then you have no heart:

http://gist.github.com/271764

Thanks to Tamas Cservenak from Sonatype, we will soon have a special
gem server that presents all the world's Java libraries as installable
Ruby Gems!

The format of the gem name is basically using the maven group and
artifact IDs plus the version number. So for this version of Rhino,
the group ID is 'rhino' and the artifact ID is also 'rhino', so the
gem name becomes rhino.rhino-1.5.4.1-java (and the -java part just
indicates this is a gem for jruby).

The resulting gem that installs is basically just a wrapper for the
jar file. Here's the structure of the rhino gem:

~/projects/jruby/lib/ruby/gems/1.8/gems ➔ ls -1 -R rhino.rhino-1.5.4.1-java/
lib

rhino.rhino-1.5.4.1-java//lib:
rhino-1.5R4.1.jar
rhino.rhino.rb

It's really barebones. The rhino.rhino.rb file is generated as well,
and basically just loads the jar for you:

~/projects/jruby/lib/ruby/gems/1.8/gems ➔ cat
rhino.rhino-1.5.4.1-java/lib/rhino.rhino.rb
module Rhino
  VERSION = '1.5.4.1'
  MAVEN_VERSION = '1.5R4.1'
end
begin
  require 'java'
  require File.dirname(__FILE__) + '/rhino-1.5R4.1.jar'
rescue LoadError
  puts 'JAR-based gems require JRuby to load. Please visit www.jruby.org.'
  raise
end

So I have a few questions and thoughts about how to use this newfound power:

* I would like to add the Maven/Gem proxy server to the default list
of gem sources for JRuby 1.5
* You will soon be able to specify these libraries as dependencies in
regular gems, since RubyGems will just use the combination of
gemcutter + sonatype to resolve everything.
* Does the structure of the rhino.rhino.rb file look reasonable?
* Should we also provide some utility methods on the Rhino module for
just retrieving the jar file path?
* Should we require the user to require the jar? I ask because it may
make bundling jar-based gems into an app if we can see what jar files
are physically being loaded.

I'd love to hear any other thoughts you have. I'm really excited about this :)

- Charlie

-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email




[jruby-dev] [jira] Created: (JRUBY-4430) [1.9] Math.gamma(-1.0/0), Math.gamma(1.0/0) and Math.gamma(0.0/0) return incorrect results

2010-01-07 Thread Hiro Asari (JIRA)
[1.9] Math.gamma(-1.0/0), Math.gamma(1.0/0) and Math.gamma(0.0/0) return 
incorrect results
--

 Key: JRUBY-4430
 URL: http://jira.codehaus.org/browse/JRUBY-4430
 Project: JRuby
  Issue Type: Bug
  Components: Core Classes/Modules, Ruby 1.9
Affects Versions: JRuby 1.4
 Environment: github trunk, Java 6, Mac OS X 10.6.2
Reporter: Hiro Asari
 Fix For: JRuby 1.5
 Attachments: 
0001-Align-Math.gamma-behavior-with-that-of-MRI-on-Infini.patch

Note on MRI trunk:
{noformat}
surfboard:~$ ruby1.9 -v -e 'p Math.gamma(-1.0/0)'ruby 1.9.2dev (2010-01-04 
trunk 26238) [x86_64-darwin10.2.0]
-e:1:in `gamma': Numerical argument out of domain - gamma (Errno::EDOM)
from -e:1:in `main'
surfboard:~$ ruby1.9 -v -e 'p Math.gamma(1.0/0); p Math.gamma(0.0/0)'
ruby 1.9.2dev (2010-01-04 trunk 26238) [x86_64-darwin10.2.0]
Infinity
NaN
{noformat}

Specs I added in RubySpec commit 0314628 will trip JRuby.

I attached the patch to fix this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email




[jruby-dev] [jira] Created: (JRUBY-4431) Float::INFINITY and Float::NAN

2010-01-07 Thread Hiro Asari (JIRA)
Float::INFINITY and Float::NAN
--

 Key: JRUBY-4431
 URL: http://jira.codehaus.org/browse/JRUBY-4431
 Project: JRuby
  Issue Type: New Feature
  Components: Core Classes/Modules, Ruby 1.9
Affects Versions: JRuby 1.4
 Environment: github trunk, Java 6, Mac OS X 10.6.2
Reporter: Hiro Asari
Priority: Minor
 Fix For: JRuby 1.5
 Attachments: 0001-MRI-r26197-added-Float-INFINITY-and-Float-NAN.patch

MRI r26197 
(http://redmine.ruby-lang.org/repositories/revision/ruby-19?rev=26197) 
introduced these constants.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira



-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email