Nabble - JRuby - Dev

[jira] Created: (JRUBY-4278) Result of 'FOO ||= 2' differs from Ruby MRI

2009-11-26T12:39:55Z

Result of 'FOO ||= 2' differs from Ruby MRI
-------------------------------------------

Key: JRUBY-4278
URL: http://jira.codehaus.org/browse/JRUBY-4278
Project: JRuby
Issue Type: Bug
Affects Versions: JRuby 1.4
Reporter: Gioele Barabucci
Assignee: Thomas E Enebo

This script

#!/usr/bin/ruby -w
FOO = 1
FOO ||= 2
puts "FOO = #{FOO}"

shows "FOO = 1" in MRI (1.8) and "FOO = 2" in JRuby 1.4.

Additionally, JRuby emits this warning: "warning: already initialized constant FOO".

--
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

[jira] Created: (JRUBY-4277) Hash#each_pair behavior with concurrent modification is inconsistent with 1.8.7p174

2009-11-25T20:59:55Z

Hash#each_pair behavior with concurrent modification is inconsistent with 1.8.7p174
-----------------------------------------------------------------------------------

Key: JRUBY-4277
URL: http://jira.codehaus.org/browse/JRUBY-4277
Project: JRuby
Issue Type: Bug
Components: Core Classes/Modules, Ruby 1.8.7
Affects Versions: JRuby 1.4
Environment: MRI 1.8.7p174 (compiled by hand on Ubuntu)
MRI 1.8.6p287 (system package on OS X 10.5)
JRuby 1.4.0 (from macports on OS X 10.5)
Reporter: Rhett Sutphin
Priority: Minor

Hash#each_pair behaves differently when you add new keys to the hash during iteration on JRuby 1.4.0 and MRI 1.8.7p174. This gist contains a short script which illustrates the different behaviors:

http://gist.github.com/243048

JRuby 1.4.0's behavior is the same as Ruby 1.9.0, not 1.8.7.

I don't know how important this difference is -- the 1.8 line's behavior is inconsistent (it seems to be dependent on the iteration order of the pairs), so it would be tricky to be deliberately depending on it. On the other hand, we did run into it in production code: a colleague of mine noticed the problem when executing a method which recursively converted all the keys in a hash to symbols (in place). On MRI 1.8.x, this method would complete, but not on JRuby 1.4.0. (It was trivial to convert this method to a form that would work in both places.)

I attempted to write a RubySpec for this, but since the 1.8 behavior doesn't seem deliberately designed, I wasn't sure how to go about it. I will update this ticket if I make any progress.

--
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

[jira] Created: (JRUBY-4276) Set org.jruby.runtime.load.LoadService.DEBUG_LOAD_TIMINGS at run time

2009-11-25T19:59:55Z

Set org.jruby.runtime.load.LoadService.DEBUG_LOAD_TIMINGS at run time
---------------------------------------------------------------------

Key: JRUBY-4276
URL: http://jira.codehaus.org/browse/JRUBY-4276
Project: JRuby
Issue Type: Improvement
Components: Miscellaneous
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-Set-org.jruby.runtime.load.LoadService.DEBUG_LOAD_TI.patch

As the existing comment suggests, this can be a run time option. Is there a good reason that it isn't?

The attached patch adds a new property {{jruby.debug.loadService.timing}} to set {{org.jruby.runtime.load.LoadService.DEBUG_LOAD_TIMINGS}} at run time.

http://gist.github.com/242782

--
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

Re: Reified classes referring to one another

2009-11-25T07:24:16Z

The first problem is not the annotation, it's the method signature. I need to call add_method_signature for a method whose return type is a class that has not yet been reified.

--Chris

On Tue, Nov 24, 2009 at 4:15 PM, Nick Sieger <nicksieger@...> wrote:

On Tue, Nov 24, 2009 at 10:37 AM, Chris Nelson
<me@...> wrote:
> Charles, Tom, et all,
>
> Was discussing this in IRC just now and thought I'd ask it here too. I'm
> about to start in on adding relationship support to jruby-hibernate and ran
> into the following conundrum. Let's say I have 2 classes, Event and Log,
> and Event has a many-to-one bi-directional relationship with Log. In order
> to model this from Hibernate perspective, Event needs a Log property
> annotated with @ManyToOne and and Log needs a collection of Events annotated
> with a @OneToMany annotation that has a targetEntity of the Event java
> class. The problem seems to be that both will need the java class of the
> other, so whichever one I call become_java! on first won't work. This seems
> to be a problem, but I haven't written any code yet to verify it. Can
> anyone shed any light on whether this is going to work?

The actual annotations don't need a reference to a class, but perhaps
we need to open up a way to refer to a class in an annotation even
though the actual class is not defined yet. Ideas on how we could do
that? Maybe a way to pre-tag a Ruby class with its fully-qualified
java class name and pass a Ruby class in? We could then use that name
when reifying the class, so that we don't have to dump everything in
the "ruby.*" package.

/Nick

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Created: (JRUBY-4275) UNIXSocket#read without argument infinite loops when called on an EOF socket

2009-11-25T02:37:55Z

UNIXSocket#read without argument infinite loops when called on an EOF socket
----------------------------------------------------------------------------

Key: JRUBY-4275
URL: http://jira.codehaus.org/browse/JRUBY-4275
Project: JRuby
Issue Type: Bug
Environment: OS X Snow Leopard
Reporter: Hongli Lai
Assignee: Thomas E Enebo
Attachments: 0002-Fix-a-bug-in-UNIXSocket-read-if-called-without-argum.patch

How to trigger the bug:

a, b = UNIXSocket.pair
a.write("hi")
a.close
puts "reading"
p b.read # Hangs here

This patch solves the problem. http://github.com/rubyspec/rubyspec/commit/e3735d59fd050a565abffa8f22020d4696f2fb07 also triggers the bug.

--
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

[jira] Created: (JRUBY-4274) UNIXSocket#close_read and #close_write are not implemented

2009-11-25T02:32:56Z

UNIXSocket#close_read and #close_write are not implemented
----------------------------------------------------------

Key: JRUBY-4274
URL: http://jira.codehaus.org/browse/JRUBY-4274
Project: JRuby
Issue Type: Bug
Environment: OS X Snow Leopard
Reporter: Hongli Lai
Assignee: Thomas E Enebo
Attachments: 0001-Implement-UNIXSocket-close_read-and-close_write.patch

#close_read and #close_write are implemented for all IO objects but not for UNIXSocket. This patch not only implements UNIXSocket#close_read and #close_write, but also makes #close_read and #close_write raise a NotImplementedError for socket types that do not implement #close_read and #close_write (none at the moment).

Incidentally, while creating this patch, I also discovered that UNIXSocket#read is bugged. I'm filing a separate issue for that. This patch doesn't work until the other issue is solved too.

RubySpec: http://github.com/rubyspec/rubyspec/commit/e3735d59fd050a565abffa8f22020d4696f2fb07

--
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

[jira] Created: (JRUBY-4273) Loading of compiled files is much slower in JRuby than loading in MRI (10x)

2009-11-25T01:17:55Z

Loading of *compiled* files is much slower in JRuby than loading in MRI (10x)
-----------------------------------------------------------------------------

Key: JRUBY-4273
URL: http://jira.codehaus.org/browse/JRUBY-4273
Project: JRuby
Issue Type: Bug
Components: Compiler, Performance
Affects Versions: JRuby 1.4
Reporter: Vladimir Sizikov

I've just updated the bench_load benchmark to include 1K load() calls for a class files compiled from rb files.

Compare the results. Essentially, loading compiled class is 5x-6x slower than loading rb class, which in turn 2x-3x times slower than loading in MRI. So, loading compiled class is 10x-15x slower than loading in MRI! Something is fishy!

JRuby:
{noformat}
D:\work\jruby-dev\jruby>jruby bench\bench_load.rb
user system total real
1 load 'fileutils-like' 0.077000 0.000000 0.077000 ( 0.056000)
1K load 'fileutils-like' 11.206000 0.000000 11.206000 ( 11.206000)
1K load compiled 'fileutils-like' 62.036000 0.000000 62.036000 ( 62.035000)
1K load 'rational' 3.442000 0.000000 3.442000 ( 3.442000)
10K require 'non-existing' 4.759000 0.000000 4.759000 ( 4.759000)
{noformat}

MRI:
{noformat}
ruby bench\bench_load.rb
user system total real
1 load 'fileutils-like' 0.016000 0.000000 0.016000 ( 0.007000)
1K load 'fileutils-like' 6.068000 0.327000 6.395000 ( 6.460370)
1K load 'rational' 1.810000 0.265000 2.075000 ( 2.086119)
10K require 'non-existing' 2.745000 11.014000 13.759000 ( 15.684897)
{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

[jira] Created: (JRUBY-4272) openssl error with quickcert code - unknown algorithm in keypair.export

2009-11-24T14:30:55Z

openssl error with quickcert code - unknown algorithm in keypair.export
------------------------------------------------------------------------

Key: JRUBY-4272
URL: http://jira.codehaus.org/browse/JRUBY-4272
Project: JRuby
Issue Type: Bug
Components: OpenSSL
Affects Versions: JRuby 1.4
Environment: Ubuntu 9.04, JRuby 1.4
Reporter: Paul Fraser
Fix For: JRuby-OpenSSL 0.5.2

http://gist.github.com/242281
checked by Headius and confirmed error in IRC

--
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

[jira] Created: (JRUBY-4271) interfaces on reified classes patch was incomplete and broke instances being passed to java code.

2009-11-24T14:04:55Z

interfaces on reified classes patch was incomplete and broke instances being passed to java code.
-------------------------------------------------------------------------------------------------

Key: JRUBY-4271
URL: http://jira.codehaus.org/browse/JRUBY-4271
Project: JRuby
Issue Type: Bug
Components: Java Integration
Affects Versions: JRuby 1.5
Reporter: Mathijs Kwik
Priority: Trivial
Fix For: JRuby 1.5

jruby 1.4 brought become_java!
however if a ruby class implemented any java interfaces, the reified java class didn't show up as implementing those interfaces.
This was fixed in 19176f8188bef2786b1e3ec49dcff04f408cdee8, but the patch was incomplete and made instances of the reified class turn into null when passed to java code.

example:
http://gist.github.com/242222

fix (thanks to headius):
http://gist.github.com/242260

--
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

[jira] Created: (JRUBY-4270) rdebug 'next' command behaves like the 'step' command

2009-11-24T13:28:55Z

rdebug 'next' command behaves like the 'step' command
-----------------------------------------------------

Key: JRUBY-4270
URL: http://jira.codehaus.org/browse/JRUBY-4270
Project: JRuby
Issue Type: Bug
Affects Versions: JRuby 1.4
Environment: Ubuntu 9.10
Reporter: Jeremy Stephens
Assignee: Thomas E Enebo
Priority: Minor
Fix For: JRuby 1.5
Attachments: test.rb

The 'next' command in ruby-debug in JRuby behaves like the 'step' command. That is, it steps into the next statement rather than skipping over it.

Attached is a test file used with rdebug (jruby -S rdebug test.rb).

The problem goes away when the --debug flag is passed to JRuby. Should rdebug automatically include the --debug option?

--
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

Re: Reified classes referring to one another

2009-11-24T13:15:07Z

On Tue, Nov 24, 2009 at 10:37 AM, Chris Nelson
<me@...> wrote:

> Charles, Tom, et all,
>
> Was discussing this in IRC just now and thought I'd ask it here too. I'm
> about to start in on adding relationship support to jruby-hibernate and ran
> into the following conundrum. Let's say I have 2 classes, Event and Log,
> and Event has a many-to-one bi-directional relationship with Log. In order
> to model this from Hibernate perspective, Event needs a Log property
> annotated with @ManyToOne and and Log needs a collection of Events annotated
> with a @OneToMany annotation that has a targetEntity of the Event java
> class. The problem seems to be that both will need the java class of the
> other, so whichever one I call become_java! on first won't work. This seems
> to be a problem, but I haven't written any code yet to verify it. Can
> anyone shed any light on whether this is going to work?

The actual annotations don't need a reference to a class, but perhaps
we need to open up a way to refer to a class in an annotation even
though the actual class is not defined yet. Ideas on how we could do
that? Maybe a way to pre-tag a Ruby class with its fully-qualified
java class name and pass a Ruby class in? We could then use that name
when reifying the class, so that we don't have to dump everything in
the "ruby.*" package.

/Nick

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

[jira] Created: (JRUBY-4269) option to dump all classes generated at runtime to disk

2009-11-24T11:17:55Z

option to dump all classes generated at runtime to disk
-------------------------------------------------------

Key: JRUBY-4269
URL: http://jira.codehaus.org/browse/JRUBY-4269
Project: JRuby
Issue Type: New Feature
Components: Compiler
Affects Versions: JRuby 1.4
Environment: Restrictive environments
Reporter: John Woodell
Priority: Critical

Create a property 'jruby.jit.cache' where jruby dumps all classes it generates at runtime to disk. Users run all their tests for code coverage. Most likely, we would modify the jit/invoker stuff to have a mode where they also dump to the set location, like ".jruby_classes" via JRUBY_JIT_CACHE. These classes can preverify and then never generate once deployed. Users add that location to classpath searching, and try to search classpath before generating/loading jitted code. We may need another property for this: jruby.compile.mode=CACHE (or some other property)

Users may need to be in charge to deleteing the old cache, but I suppose this could happen on startup. It will also be possible to package these classes into separate jar files, for environments where many-files is bad, but files larger then 10MB are not allowed.

--
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

Reified classes referring to one another

2009-11-24T08:37:18Z

Charles, Tom, et all,

Was discussing this in IRC just now and thought I'd ask it here too. I'm about to start in on adding relationship support to jruby-hibernate and ran into the following conundrum. Let's say I have 2 classes, Event and Log, and Event has a many-to-one bi-directional relationship with Log. In order to model this from Hibernate perspective, Event needs a Log property annotated with @ManyToOne and and Log needs a collection of Events annotated with a @OneToMany annotation that has a targetEntity of the Event java class. The problem seems to be that both will need the java class of the other, so whichever one I call become_java! on first won't work. This seems to be a problem, but I haven't written any code yet to verify it. Can anyone shed any light on whether this is going to work?

--Chris

[jira] Created: (JRUBY-4268) speed-up yaml/yecht loading

2009-11-24T01:14:55Z

speed-up yaml/yecht loading
---------------------------

Key: JRUBY-4268
URL: http://jira.codehaus.org/browse/JRUBY-4268
Project: JRuby
Issue Type: New Feature
Components: Extensions, Performance
Affects Versions: JRuby 1.4
Reporter: Vladimir Sizikov

Now that other low hanging fruits for speeding-up the rubygems loading are eliminated, the yaml/yecht startup is the most significant contributor to slow rubygems loading.

Take a look, simple "require 'yaml'" takes about 300+ms. Entire rubygems startup is 800+, so almost half of that time is spent in yaml.

If only we could eliminate, for example, loading of date (or lazy-load it somehow), that would be a significant boost.

{noformat}
#>jruby -b -e "require 'yaml'"
-> builtin/core_ext/symbol
<- builtin/core_ext/symbol - 41ms
-> enumerator
<- enumerator - 5ms
-> yaml
-> stringio
<- stringio - 9ms
-> yaml/compat
<- yaml/compat - 11ms
-> yaml/error
<- yaml/error - 2ms
-> yaml/yecht
-> yecht
<- yecht - 78ms
-> yaml/basenode
-> yaml/ypath
<- yaml/ypath - 6ms
<- yaml/basenode - 29ms
<- yaml/yecht - 110ms
-> yaml/tag
<- yaml/tag - 6ms
-> yaml/stream
<- yaml/stream - 1ms
-> yaml/constants
<- yaml/constants - 2ms
-> yaml/rubytypes
-> date
-> rational
<- rational - 14ms
-> date/format
-> rational
<- rational - 1ms
<- date/format - 78ms
<- date - 177ms
-> yaml/compat
<- yaml/compat - 0ms
<- yaml/rubytypes - 217ms
-> yaml/types
-> yaml/compat
<- yaml/compat - 0ms
<- yaml/types - 14ms
<- yaml - 400ms
{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

[jira] Created: (JRUBY-4267) speed-up rubygems startup by removing 'java' and 'jruby' libs loading

2009-11-24T00:14:55Z

speed-up rubygems startup by removing 'java' and 'jruby' libs loading
---------------------------------------------------------------------

Key: JRUBY-4267
URL: http://jira.codehaus.org/browse/JRUBY-4267
Project: JRuby
Issue Type: New Feature
Components: Performance
Affects Versions: JRuby 1.4
Reporter: Vladimir Sizikov
Fix For: JRuby 1.5

See http://gist.github.com/240322 for rubygems loading timings, and note that requiring java/jruby consumes 200-250ms.

--
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

[jira] Created: (JRUBY-4266) ClassCastException when launching Rails App on Glassfishv3

2009-11-23T18:33:55Z

ClassCastException when launching Rails App on Glassfishv3
----------------------------------------------------------

Key: JRUBY-4266
URL: http://jira.codehaus.org/browse/JRUBY-4266
Project: JRuby
Issue Type: Bug
Components: Rails WAR Deployment
Affects Versions: JRuby 1.4
Environment: OpenSolaris, Glassfishv3, JRuby-1.4.0, Rails-2.3.4, activerecord-jdbcmysql-adapter-0.9.2, activerecord-jdbc-adapter-0.9.2, jdbc-mysql-5.0.4, rack-1.0.1, Java-1.6, glassfishgem-0.9.5, jruby-oppenssl-0.5.2, warbler-0.9.14
Reporter: Craig Stuber
Priority: Blocker

A simple learning app that reads and displays 2 items from a MySQL database. The app works with the Glassfish gem, but when I create a war file and deploy and launch on Glassfishv3 I get the following error message:

SEVERE: WebModule[/testapp]Application Error
java.lang.ClassCastException: org.jruby.java.proxies.ConcreteJavaProxy cannot be cast to java.sql.Connection
at $Proxy156.newConnection(Unknown Source)
at jdbc_adapter.RubyJdbcConnection.reconnect(RubyJdbcConnection.java:423)
at jdbc_adapter.RubyJdbcConnection.connection(RubyJdbcConnection.java:171)
at jdbc_adapter.RubyJdbcConnection$i_method_0_0$RUBYINVOKER$connection.call(jdbc_adapter/RubyJdbcConnection$i_method_0_0$RUBYINVOKER$connection.gen)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:253)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:72)
at org.jruby.ast.VCallNode.interpret(VCallNode.java:85)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104)
at org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
at org.jruby.ast.RescueNode.executeBody(RescueNode.java:225)
at org.jruby.ast.RescueNode.interpretWithJavaExceptions(RescueNode.java:147)
at org.jruby.ast.RescueNode.interpret(RescueNode.java:110)
at org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:182)
at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:153)
at org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:283)
at org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:121)
at org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:126)
at org.jruby.RubyClass$SpecificArityNew.call(RubyClass.java:554)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:152)
more...

The jdbc connection pool pings successfully.

--
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

[jira] Created: (JRUBY-4265) Using -J (to set a Java option) clobbers the CLASSPATH

2009-11-23T17:44:55Z

Using -J (to set a Java option) clobbers the CLASSPATH
------------------------------------------------------

Key: JRUBY-4265
URL: http://jira.codehaus.org/browse/JRUBY-4265
Project: JRuby
Issue Type: Bug
Affects Versions: JRuby 1.4
Environment: Mac OS 10.5.7 with Java 1.5.0_19-137
Reporter: David Agnew
Assignee: Thomas E Enebo

jruby -e "p ENV['CLASSPATH'].split(/:/).length"
prints 10

jruby -J-Xmx1536m -e "p ENV['CLASSPATH'].split(/:/).length"
prints 0

Got a JDBC driver load error running a program that used to run fine in 1.3.1. The program begins with the line

#!/usr/bin/env jruby -J-Xmx1536m

Further investigation revealed the empty CLASSPATH.

--
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

[jira] Created: (JRUBY-4264) threadContextMap leaks RubyThread on death of adopted thread

2009-11-23T04:22:55Z

threadContextMap leaks RubyThread on death of adopted thread
------------------------------------------------------------

Key: JRUBY-4264
URL: http://jira.codehaus.org/browse/JRUBY-4264
Project: JRuby
Issue Type: Bug
Affects Versions: JRuby 1.4
Environment: Java HotSpot(TM) 64-Bit Server VM, Version 1.6.0_12
Reporter: Chris Andrews
Assignee: Thomas E Enebo
Attachments: Harness.java

We have an app which handles received messages from ActiveMQ in Ruby, as part of a Rails app running inside Glassfish. This means that we have threads started by the ActiveMQ client executing inside JRuby, so they get adopted and then die off some time later having handled a number of messages.

It looks like a RubyThread and its ThreadContext are leaked at the death of an adopted thread, since the cleanup in RubyRunnable isn't called, and despite the use of WeakHashMaps in ThreadService it can't be GC'd:

this.rubyThreadMap = Collections.synchronizedMap(newWeakHashMap<Object, RubyThread>());
this.threadContextMap = Collections.synchronizedMap(newWeakHashMap<RubyThread,ThreadContext>());

When the adopted thread dies, its entry in rubyThreadMap is removed, but the corresponding entry in threadContextMap is not. This seems to be because there's a strong reference from ThreadContext back to RubyThread - the WeakHashMap is only weak towards its keys, and so the entry is leaked.

It helps to forcibly reap these leaked entries based on the fact the RubyThreads no longer have a live Thread, using a daemon thread to regularly iterate the threadContextMap.

I'm attaching a program which demonstrates the issue we're seeing outside of a webapp container.

--
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

[jira] Created: (JRUBY-4263) Loading of rb files is much slower in JRuby than in MRI (2x-5x)

2009-11-22T13:18:55Z

Loading of rb files is much slower in JRuby than in MRI (2x-5x)
---------------------------------------------------------------

Key: JRUBY-4263
URL: http://jira.codehaus.org/browse/JRUBY-4263
Project: JRuby
Issue Type: Bug
Components: Parser, Performance
Environment: latest jruby from master branch
Reporter: Vladimir Sizikov
Assignee: Thomas E Enebo

I've just comitted the bench/bench_load.rb benchmark, and we are 2x-5x slower then MRI (varies a bit between platforms). This is one of those issues identified while trying to make JRuby startup faster.

Essentially, cold load/require is pretty bad in JRuby. Hopefully, this benchmark could help out to narrow some cases.
When just loading/requiring 'fileutils' takes 200ms, that's bad.

{noformat}
#>jruby bench/bench_load.rb
user system total real
1 load 'fileutils-like' 0.186000 0.000000 0.186000 ( 0.157000)
1K load 'fileutils-like' 12.336000 0.000000 12.336000 ( 12.336000)
1K load 'rational' 3.698000 0.000000 3.698000 ( 3.698000)
10K require 'non-existing' 5.024000 0.000000 5.024000 ( 5.024000)

#>ruby bench/bench_load.rb
user system total real
1 load 'fileutils-like' 0.000000 0.020000 0.020000 ( 0.017378)
1K load 'fileutils-like' 1.870000 1.790000 3.660000 ( 3.662594)
1K load 'rational' 0.710000 0.700000 1.410000 ( 1.461065)
10K require 'non-existing' 0.280000 0.610000 0.890000 ( 0.889232)

{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

Re: Running RubySpec on String in 1.9 mode

2009-11-22T11:36:43Z

OK, I've filed the blocker for JRuby 1.5 here:
http://jira.codehaus.org/browse/JRUBY-4262

On Sun, Nov 22, 2009 at 3:54 PM, Hirotsugu Asari <asari.ruby@...> 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

[jira] Created: (JRUBY-4262) Weird Proc tests makes JRuby to skip the rest of the tests completely

2009-11-22T11:35:55Z

Weird Proc tests makes JRuby to skip the rest of the tests completely
---------------------------------------------------------------------

Key: JRUBY-4262
URL: http://jira.codehaus.org/browse/JRUBY-4262
Project: JRuby
Issue Type: Bug
Components: Core Classes/Modules, RubySpec
Affects Versions: JRuby 1.4
Reporter: Vladimir Sizikov
Priority: Blocker
Fix For: JRuby 1.5

This is a blocker.

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!!!

And the spec in question that
breaks JRuby is:

{code}
# 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
{code}

Btw, MRI works just fine here, so it does look like JRuby's 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

Re: Running RubySpec on String in 1.9 mode

2009-11-22T08:11:14Z

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 <asari.ruby@...> 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

[jira] Created: (JRUBY-4261) Validation in Rails: validates_numericality_of :amount, :only_integer => true, :greater_than => -1 doesn't work because of the :only_integer

2009-11-22T07:30:55Z

Validation in Rails: validates_numericality_of :amount, :only_integer => true, :greater_than => -1 doesn't work because of the :only_integer
--------------------------------------------------------------------------------------------------------------------------------------------

Key: JRUBY-4261
URL: http://jira.codehaus.org/browse/JRUBY-4261
Project: JRuby
Issue Type: Bug
Affects Versions: JRuby 1.4
Environment: Mac jruby 1.4.0 (ruby 1.8.7 patchlevel 174) (2009-11-02 69fbfa3) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_15) [x86_64-java]
Reporter: Helmut Juskewycz
Assignee: Thomas E Enebo
Priority: Minor

I am in the middle of switching to JRuby with an application and some tests failed, although, in Ruby not.
The problem is the :only_integer => true validation option. In Ruby the validation works with the option and in JRuby not. When I remove the option, all tests pass in JRuby.

Here is a code snippet from Rails that causes the problem

...
if configuration[:only_integer]
unless raw_value.to_s =~ /\A[+-]?\d+\Z/
record.errors.add(attr_name, :not_a_number, :value => raw_value, :default => configuration[:message])
next
end
raw_value = raw_value.to_i
else
...

--
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

Running RubySpec on String in 1.9 mode

2009-11-22T06:54:50Z

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

[jira] Created: (JRUBY-4260) [1.9] String#each is removed

2009-11-22T06:49:55Z

[1.9] String#each is removed
----------------------------

Key: JRUBY-4260
URL: http://jira.codehaus.org/browse/JRUBY-4260
Project: JRuby
Issue Type: Bug
Components: Core Classes/Modules, Ruby 1.9
Affects Versions: JRuby 1.4, JRuby 1.5
Environment: github trunk, Java 6, Mac OS X 10.6.2
Reporter: Hiro Asari
Fix For: JRuby 1.5
Attachments: 0001-Remove-String-each-in-1.9-mode.patch

{noformat}
surfboard:jruby[git:master]$ jruby spec/mspec/bin/mspec -T--1.9 spec/ruby/core
jruby 1.5.0.dev (ruby 1.9.2dev trunk 24787) (2009-11-22 c034e66) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_15) [x86_64-java]
....
862)
An exception occurred during: String#each FAILED
Expected NoMethodError but no exception was raised
/Users/asari/Development/src/jruby/spec/ruby/core/string/each_spec.rb:11
/Users/asari/Development/src/jruby/spec/ruby/core/string/each_spec.rb:10
/Users/asari/Development/src/jruby/spec/ruby/core/string/each_spec.rb:5
/Users/asari/Development/src/jruby/spec/ruby/core/string/each_spec.rb:55:in `load'
{noformat}

This was removed in rev 10981 (more than 3 years ago). http://svn.ruby-lang.org/cgi-bin/viewvc.cgi/trunk/string.c?r1=10981&r2=10980&pathrev=10981

The patch removes this method.

--
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

[jira] Created: (JRUBY-4259) require 'jruby' should load 'java' library lazily

2009-11-22T05:03:55Z

require 'jruby' should load 'java' library *lazily*
---------------------------------------------------

Key: JRUBY-4259
URL: http://jira.codehaus.org/browse/JRUBY-4259
Project: JRuby
Issue Type: New Feature
Affects Versions: JRuby 1.4
Reporter: Vladimir Sizikov
Assignee: Thomas E Enebo
Fix For: JRuby 1.5

In Rubygems, and in JIRB, we require 'jruby', and that in turns loads the whole 'java' stuff, consuming 200-300ms of time.

In JRuby case, all we need 'jruby' for is to enable object space. In such case, there is no need to load the whole 'java' stuff. Ideally, the 'java' lib should be loaded lazily, only when needed.

In JIRB case, removing this eager loading of 'java' actually saves us QUITE A LOT: the startup time of JRuby IRB goes from 570ms to 340ms!!

See also: http://blog.emptyway.com/2009/11/21/making-sense-out-of-slow-rubygems-startup/ for rubygems related info.

--
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

[jira] Created: (JRUBY-4258) GC rubyspec failures

2009-11-22T02:30:55Z

GC rubyspec failures
--------------------

Key: JRUBY-4258
URL: http://jira.codehaus.org/browse/JRUBY-4258
Project: JRuby
Issue Type: Bug
Components: Core Classes/Modules, Ruby 1.8.7, RubySpec
Affects Versions: JRuby 1.4
Environment: Latest jruby from master
Reporter: Vladimir Sizikov
Assignee: Vladimir Sizikov
Fix For: JRuby 1.5

I've added GC rubyspecs, and now JRuby fails them. Will fix.

{noformat}
D:\work\jruby-dev\rubyspec.git>mspec -t j core/gc
jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2009-11-22 d007d54) (Java HotSpot(TM) Client VM 1.6.0_17) [x86-java]
...F...F........EEE

1)
GC.disable returns true iff the garbage collection was previously disabled FAILED
Expected nil
to equal false

D:/work/jruby-dev/rubyspec.git/core/gc/disable_spec.rb:21
D:/work/jruby-dev/rubyspec.git/core/gc/disable_spec.rb:3
D:/work/jruby-dev/rubyspec.git/core/gc/disable_spec.rb:55:in `load'
D:/work/jruby-dev/mspec.git/bin/mspec-run:8

2)
GC.enable returns true iff the garbage collection was already disabled FAILED
Expected nil
to equal false

D:/work/jruby-dev/rubyspec.git/core/gc/enable_spec.rb:18
D:/work/jruby-dev/rubyspec.git/core/gc/enable_spec.rb:3
D:/work/jruby-dev/rubyspec.git/core/gc/enable_spec.rb:55:in `load'
D:/work/jruby-dev/mspec.git/bin/mspec-run:8

3)
GC.stress returns current status of GC stress mode ERROR
NoMethodError: undefined method `stress' for GC:Module
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:10
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:4
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:3
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:55:in `load'
D:/work/jruby-dev/mspec.git/bin/mspec-run:8

4)
An exception occurred during: after :each
GC.stress returns current status of GC stress mode ERROR
NoMethodError: undefined method `stress=' for GC:Module
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:7
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:4
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:3
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:55:in `load'
D:/work/jruby-dev/mspec.git/bin/mspec-run:8

5)
GC.stress= can be invoked without any exceptions FAILED
Expected to not get Exception
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:23
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:18
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:3
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:55:in `load'
D:/work/jruby-dev/mspec.git/bin/mspec-run:8

6)
An exception occurred during: after :each
GC.stress= can be invoked without any exceptions ERROR
NoMethodError: undefined method `stress=' for GC:Module
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:20
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:18
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:3
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:55:in `load'
D:/work/jruby-dev/mspec.git/bin/mspec-run:8

7)
GC.stress= returns a proper boolean result ERROR
NoMethodError: undefined method `stress=' for GC:Module
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:27
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:18
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:3
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:55:in `load'
D:/work/jruby-dev/mspec.git/bin/mspec-run:8

8)
An exception occurred during: after :each
GC.stress= returns a proper boolean result ERROR
NoMethodError: undefined method `stress=' for GC:Module
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:20
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:18
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:3
D:/work/jruby-dev/rubyspec.git/core/gc/stress_spec.rb:55:in `load'
D:/work/jruby-dev/mspec.git/bin/mspec-run:8

Finished in 0.085000 seconds

5 files, 19 examples, 19 expectations, 3 failures, 5 errors
{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

[jira] Created: (JRUBY-4257) Update maven-metadata.xml to latest JRuby version

2009-11-21T04:40:55Z

Update maven-metadata.xml to latest JRuby version
-------------------------------------------------

Key: JRUBY-4257
URL: http://jira.codehaus.org/browse/JRUBY-4257
Project: JRuby
Issue Type: Bug
Reporter: Gioele Barabucci
Assignee: Thomas E Enebo
Priority: Minor

The Maven metadata file at <http://repository.codehaus.org/org/jruby/jruby-complete/maven-metadata.xml> says that JRuby 1.4.0 is available but the stable version is version 0.9.8 (/metadata/version).

Could you update the Maven metadata file? Isn't it updated automatically by your release scripts?

--
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

[jira] Created: (JRUBY-4256) Expose API to compile a single Ruby file

2009-11-21T04:23:55Z

Expose API to compile a single Ruby file
----------------------------------------

Key: JRUBY-4256
URL: http://jira.codehaus.org/browse/JRUBY-4256
Project: JRuby
Issue Type: Improvement
Affects Versions: JRuby 1.4
Reporter: Gioele Barabucci
Assignee: Thomas E Enebo
Priority: Minor

Could your please adapt the JRubyCompiler API to compile one single source file?

The code to compile a single file is already present in jruby/jruby.rb but is not exposed through the API (that only exposes #compile_files).

--
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

[jira] Created: (JRUBY-4255) [1.9] RubyBignum#, RubyFixnum# and RubyFloat#** should return a RubyComplex if self is negative and raised to a fractional power

2009-11-20T23:53:55Z

[1.9] RubyBignum#**, RubyFixnum#** and RubyFloat#** should return a RubyComplex if self is negative and raised to a fractional power
------------------------------------------------------------------------------------------------------------------------------------

Key: JRUBY-4255
URL: http://jira.codehaus.org/browse/JRUBY-4255
Project: JRuby
Issue Type: Bug
Components: Core Classes/Modules, Ruby 1.9
Affects Versions: JRuby 1.4, JRuby 1.5
Environment: github trunk, Java 6, Mac OS X 10.6.2
Reporter: Hiro Asari
Fix For: JRuby 1.5
Attachments: 0001-RubyBignum-RubyFixnum-and-RubyFloat-should-return-Ru.patch

Current trunk behavior:
{noformat}
surfboard:~$ jruby --1.9 -v -e 'p (-0x8000_0000_0000_0000-47)**(1/3.0)'
jruby 1.5.0.dev (ruby 1.9.2dev trunk 24787) (2009-11-20 5b30070) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_15) [x86_64-java]
-e:1 warning: (...) interpreted as grouped expression
-e:1: NaN (FloatDomainError)
surfboard:jruby[git:master]$ bin/jruby --1.9 -v -e 'p (-5)**(1/3.0)' 2>/dev/null
jruby 1.5.0.dev (ruby 1.9.2dev trunk 24787) (2009-11-20 5b30070) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_15) [x86_64-java]
NaN
surfboard:jruby[git:personal]$ bin/jruby --1.9 -v -e 'p (-1.25)**(1/3.0)' 2>/dev/null
jruby 1.5.0.dev (ruby 1.9.2dev trunk 24787) (2009-11-20 5b30070) (Java HotSpot(TM) 64-Bit Server VM 1.6.0_15) [x86_64-java]
NaN
{noformat}
MRI behavior:
{noformat}
surfboard:~$ ruby1.9 -v -e 'p (-0x8000_0000_0000_0000-47)**(1/3.0)'
ruby 1.9.2dev (2009-11-17 trunk 25805) [x86_64-darwin10.2.0]
-e:1: warning: (...) interpreted as grouped expression
(1048575.9999999994+1816186.9075973416i)
surfboard:jruby[git:master]$ ruby1.9 -v -e 'p (-5)**(1/3.0)' 2>/dev/null
ruby 1.9.2dev (2009-11-17 trunk 25805) [x86_64-darwin10.2.0]
(0.8549879733383486+1.480882609682364i)
surfboard:jruby[git:personal]$ ruby1.9 -v -e 'p (-1.25)**(1/3.0)' 2>/dev/null
ruby 1.9.2dev (2009-11-17 trunk 25805) [x86_64-darwin10.2.0]
(0.5386086725079711+0.932897586181032i)
{noformat}
While investigating JRUBY-4008, I noticed this bug. JRuby returns NaN where MRI returns a Complex.

The attached patch fixes this (and similar issues with RubyNumeric and RubyFloat).

--
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

[jira] Created: (JRUBY-4254) Yecht crashes on weird data

2009-11-20T12:38:56Z

Yecht crashes on weird data
---------------------------

Key: JRUBY-4254
URL: http://jira.codehaus.org/browse/JRUBY-4254
Project: JRuby
Issue Type: Bug
Components: Extensions
Affects Versions: JRuby 1.4
Reporter: Vladimir Sizikov
Assignee: Ola Bini
Attachments: config_yaml_spec.rb

{noformat}
jruby -ryaml -e "p YAML.load_file('config_yaml_spec.rb')"

String.java:397:in `checkBounds': java.lang.StringIndexOutOfBoundsException: String index out of range: -1
from String.java:442:in `<init>'
from RubyErrHandler.java:28:in `handle'
from TokenScanner.java:19:in `error'
from DefaultYAMLParser.java:803:in `yyerror'
from DefaultYAMLParser.java:329:in `yyparse'
from Parser.java:290:in `yechtparse'
from Parser.java:284:in `parse'
from YParser.java:152:in `load'
from org/yecht/ruby/YParser$s_method_0_1$RUBYINVOKER$load.gen:-1:in `call'
from JavaMethod.java:631:in `call'
from DynamicMethod.java:186:in `call'
from CachingCallSite.java:309:in `cacheAndCall'
from CachingCallSite.java:148:in `call'
from CallOneArgNode.java:57:in `interpret'
from LocalAsgnNode.java:123:in `interpret'
from NewlineNode.java:104:in `interpret'
from InterpretedMethod.java:173:in `call'
from DefaultMethod.java:171:in `call'
from CachingCallSite.java:309:in `cacheAndCall'
from CachingCallSite.java:148:in `call'
from FCallOneArgNode.java:36:in `interpret'
from NewlineNode.java:104:in `interpret'
from InterpretedBlock.java:317:in `evalBlockBody'
from InterpretedBlock.java:268:in `yield'
from Block.java:194:in `yield'
from RubyIO.java:1092:in `open'
from org/jruby/RubyIO$s_method_0_2$RUBYFRAMEDINVOKER$open.gen:-1:in `call'
from DynamicMethod.java:190: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 InterpretedMethod.java:173:in `call'
from DefaultMethod.java:171:in `call'
from CachingCallSite.java:309:in `cacheAndCall'
from CachingCallSite.java:148:in `call'
from -e:1:in `__file__'
from -e:-1:in `load'
from Ruby.java:632:in `runScript'
from Ruby.java:550:in `runNormally'
from Ruby.java:396:in `runFromMain'
from Main.java:272:in `run'
from Main.java:117:in `run'
from Main.java:97:in `main'
{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

[jira] Created: (JRUBY-4253) JRuby defaults to "\r\n" newlines on Windows, where MRI 1.8 and 1.9 use just "\n"

2009-11-20T09:47:55Z

JRuby defaults to "\r\n" newlines on Windows, where MRI 1.8 and 1.9 use just "\n"
---------------------------------------------------------------------------------

Key: JRUBY-4253
URL: http://jira.codehaus.org/browse/JRUBY-4253
Project: JRuby
Issue Type: Bug
Components: Parser
Affects Versions: JRuby 1.4
Environment: Windows XP Pro SP3
Reporter: Steve Shreeve
Assignee: Thomas E Enebo
Priority: Minor

On Windows, Ruby scripts are normally saved with the default "\r\n" line endings. When using DATA.gets to read text below the "__END__" tag, however, MRI 1.8 and 1.9 silently remove the "\r" character (leaving just "\n"). This means that the same script performs differently on Windows using MRI 1.8/1.9 versus JRuby 1.4. I can force the file to save with UNIX-style line endings, but it would be convenient if JRuby performed identically to MRI 1.8/1.9.

Here's an example:

=8<===8<===8<===8<===8<===8<===8<===8<===8<==

p "group 1", DATA.gets("\n\n")
p "group 2", DATA.gets("\n\n")
p "group 3", DATA.gets("\n\n")

__END__

This is group number 1
It contains some text here
And a little more text

This is group number 2
It also has some text

Again, we've got group number three
With even a little more text than the others
It sort of rambles on a bit and then, with a poof...
It's done!

=8<===8<===8<===8<===8<===8<===8<===8<===8<==

When I run this in MRI 1.8/1.9, I get the following:

"group 1"
"\nThis is group number 1\nIt contains some text here\nAnd a little more text\n\n"
"group 2"
"This is group number 2\nIt also has some text\n\n"
"group 3"
"Again, we've got group number three\nWith even a little more text than the others\nIt sort of rambles on a bit and then, with a poof...\nIt's done!\n"

When I run this in JRuby 1.4, I get the following:

"group 1"
"\r\nThis is group number 1\r\nIt contains some text here\r\nAnd a little more text\r\n\r\nThis is group number 2\r\nIt also has some text\r\n\r\nAgain, we've got group number three\r\nWith even a little more text than the others\r\nIt sort of rambles on a bit and then, with a poof...\r\nIt's done!\r\n"
"group 2"
nil
"group 3"
nil

This is not a huge deal, but it would be helpful to fix.

--
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

[jira] Created: (JRUBY-4252) [1.9] Class improvements to fix all its failed specs

2009-11-20T02:44:55Z

[1.9] Class improvements to fix all its failed specs
----------------------------------------------------

Key: JRUBY-4252
URL: http://jira.codehaus.org/browse/JRUBY-4252
Project: JRuby
Issue Type: Improvement
Reporter: David Calavera
Assignee: Thomas E Enebo
Fix For: JRuby 1.5
Attachments: 0001-RubyClass-improvements-to-pass-every-spec.patch

There are a few failed specs related with RubyClass:

Ruby1.9:
Class#superclass returns the superclass of self

Ruby1.8:
Class#superclass for a singleton class of an object returns the class of the object
Class#superclass for a singleton class of a class returns the singleton class of its superclass

I include a tiny patch that fixes those specs, everyone passes now :)

--
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

[jira] Created: (JRUBY-4251) Warning: already initialized constant When Multi-threading

2009-11-19T23:04:55Z

Warning: already initialized constant When Multi-threading
----------------------------------------------------------

Key: JRUBY-4251
URL: http://jira.codehaus.org/browse/JRUBY-4251
Project: JRuby
Issue Type: Bug
Environment: OS X 10.5.8
Reporter: Anthony Eden
Assignee: Thomas E Enebo
Fix For: JRuby 1.3

When using threadify to create a multi-threaded script where a class uses the Java/Ruby integration layer and where imports are package imports such as:

import org.apache.http

And that class only gets instantiated inside the thread block, the following warning is displayed at start up for a number of classes that are loaded:

/usr/local/lib/jruby-1.3.0/lib/ruby/site_ruby/1.8/builtin/javasupport/core_ext/module.rb:27 warning: already initialized constant HttpHost

Where HttpHost may be a variety of class names.

I showed this to Charles tonight at RubyConf 2009, and he said he thought it could be fixed inside the JRuby code.

--
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

[jira] Created: (JRUBY-4250) Rails app on Glassfish Gem - Cookie Session Store & Flash

2009-11-19T10:14:55Z

Rails app on Glassfish Gem - Cookie Session Store & Flash
---------------------------------------------------------

Key: JRUBY-4250
URL: http://jira.codehaus.org/browse/JRUBY-4250
Project: JRuby
Issue Type: Bug
Components: Application Error, OpenSSL
Affects Versions: JRuby 1.4
Environment: Jruby 1.4.0, Rails 2.3.4, Glassfish Gem 0.9.5 (Same issue on Windows [Java 1.6.0_16-b01] and Linux [Java 1.6.0_12])
Reporter: Jarred Nicholls

I switched to JRuby and started to experience this issue: I store a very lightweight activerecord object into the flash store sometimes (please hold back the flames, this bug shouldn't occur regardless) when reloading a form after a record fails validation. After the first ActiveRecord object is stored into the flash, I start to receive this error indefinitely (anytime I access the flash):

The error occurred while evaluating nil.[]
C:/jruby-1.4.0/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/flash.rb:111:in sweep' C:/jruby-1.4.0/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/flash.rb:110:ineach'
C:/jruby-1.4.0/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/flash.rb:110:in sweep' C:/jruby-1.4.0/lib/ruby/gems/1.8/gems/actionpack-2.3.4/lib/action_controller/flash.rb:164:inflash'

I looked at that line and it's accessing an instance variable of FlashHash named "@used", which stores all the used flash keys. That instance variable is nil on every request after storing an activerecord object into the flash hash. Now, it might be a session store issue as I am using the cookie store (I haven't tried other stores yet).

I'm thinking maybe JRuby and JRuby-OpenSSL is having problems dealing with serializing and deserializing activerecord objects in the cookie store? Anyone ever ran into this problem? If I delete my session cookie, the problem goes away until the next storage of an activerecord object into the flash. But, I tested a partially filled object and it worked fine, it's only when it's storing a particular makeup of an object. The issue doesn't exist in MRI Ruby, so it's definitely something with JRuby and possibly OpenSSL HMAC digest.

I was very excited to commit to JRuby for true multithreading, but I will go back to trying to make 1.9 SVN work :-P

Thanks,
Jarred

--
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

Nabble - JRuby - Dev

[jira] Created: (JRUBY-4278) Result of 'FOO ||= 2' differs from Ruby MRI

[jira] Created: (JRUBY-4277) Hash#each_pair behavior with concurrent modification is inconsistent with 1.8.7p174

[jira] Created: (JRUBY-4276) Set org.jruby.runtime.load.LoadService.DEBUG_LOAD_TIMINGS at run time

Re: Reified classes referring to one another

[jira] Created: (JRUBY-4275) UNIXSocket#read without argument infinite loops when called on an EOF socket

[jira] Created: (JRUBY-4274) UNIXSocket#close_read and #close_write are not implemented

[jira] Created: (JRUBY-4273) Loading of *compiled* files is much slower in JRuby than loading in MRI (10x)

[jira] Created: (JRUBY-4272) openssl error with quickcert code - unknown algorithm in keypair.export

[jira] Created: (JRUBY-4271) interfaces on reified classes patch was incomplete and broke instances being passed to java code.

[jira] Created: (JRUBY-4270) rdebug 'next' command behaves like the 'step' command

Re: Reified classes referring to one another

[jira] Created: (JRUBY-4269) option to dump all classes generated at runtime to disk

Reified classes referring to one another

[jira] Created: (JRUBY-4268) speed-up yaml/yecht loading

[jira] Created: (JRUBY-4267) speed-up rubygems startup by removing 'java' and 'jruby' libs loading

[jira] Created: (JRUBY-4266) ClassCastException when launching Rails App on Glassfishv3

[jira] Created: (JRUBY-4265) Using -J (to set a Java option) clobbers the CLASSPATH

[jira] Created: (JRUBY-4264) threadContextMap leaks RubyThread on death of adopted thread

[jira] Created: (JRUBY-4263) Loading of rb files is much slower in JRuby than in MRI (2x-5x)

Re: Running RubySpec on String in 1.9 mode

[jira] Created: (JRUBY-4262) Weird Proc tests makes JRuby to skip the rest of the tests completely

Re: Running RubySpec on String in 1.9 mode

[jira] Created: (JRUBY-4261) Validation in Rails: validates_numericality_of :amount, :only_integer => true, :greater_than => -1 doesn't work because of the :only_integer

Running RubySpec on String in 1.9 mode

[jira] Created: (JRUBY-4260) [1.9] String#each is removed

[jira] Created: (JRUBY-4259) require 'jruby' should load 'java' library *lazily*

[jira] Created: (JRUBY-4258) GC rubyspec failures

[jira] Created: (JRUBY-4257) Update maven-metadata.xml to latest JRuby version

[jira] Created: (JRUBY-4256) Expose API to compile a single Ruby file

[jira] Created: (JRUBY-4255) [1.9] RubyBignum#**, RubyFixnum#** and RubyFloat#** should return a RubyComplex if self is negative and raised to a fractional power

[jira] Created: (JRUBY-4254) Yecht crashes on weird data

[jira] Created: (JRUBY-4253) JRuby defaults to "\r\n" newlines on Windows, where MRI 1.8 and 1.9 use just "\n"

[jira] Created: (JRUBY-4252) [1.9] Class improvements to fix all its failed specs

[jira] Created: (JRUBY-4251) Warning: already initialized constant When Multi-threading

[jira] Created: (JRUBY-4250) Rails app on Glassfish Gem - Cookie Session Store & Flash

[jira] Created: (JRUBY-4273) Loading of compiled files is much slower in JRuby than loading in MRI (10x)

[jira] Created: (JRUBY-4259) require 'jruby' should load 'java' library lazily

[jira] Created: (JRUBY-4255) [1.9] RubyBignum#, RubyFixnum# and RubyFloat#** should return a RubyComplex if self is negative and raised to a fractional power