Is this expected:
latest github
C:\dev\ruby\downloads\jruby\bin>gem list
C:\dev\ruby\downloads\jruby\bin\gem:8:in `require’: IO error – rubygems
(LoadError)
from C:\dev\ruby\downloads\jruby\bin\gem:8
thanks.
-r
Hi Roger,
On Sat, Nov 28, 2009 at 1:41 AM, Roger P. [email protected]
wrote:
Is this expected:
latest github
C:\dev\ruby\downloads\jruby\bin>gem list
C:\dev\ruby\downloads\jruby\bin\gem:8:in `require’: IO error – rubygems
(LoadError)
from C:\dev\ruby\downloads\jruby\bin\gem:8
No, this is not expected. And it works just fine here. Just in case,
do you have RUBYOPT set? It shouldn’t be a problem with latest JRuby,
but it caused some unexpected results in the past.
Also, just ‘jruby -rrubygems -e 1’ - this works?
And difference when you try jruby -S gem list?
Thanks,
–Vladimir
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
No, this is not expected. And it works just fine here. Just in case,
do you have RUBYOPT set? It shouldn’t be a problem with latest JRuby,
but it caused some unexpected results in the past.
I traditionally do set RUBYOPT.
Here’s an attempt without it.
C:\dev\digitalarchive_trunk>set RUBYOPT=
C:\dev\digitalarchive_trunk>gem install whichr
c:\dev\ruby\downloads\jruby\bin\gem:8:in `require’: IO error – rubygems
(LoadError)
from c:\dev\ruby\downloads\jruby\bin\gem:8
C:\dev\digitalarchive_trunk>jruby -v
jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2009-11-27 7ccf53f) (Java
HotSpot™ Client VM 1.6.0_13) [x86-java]
C:\dev\digitalarchive_trunk>jruby -rrubygems -e 1
Exception in thread “main” :1: IO error – rubygems (LoadError)
…internal jruby stack elided…
from (unknown).(unknown)(:1)
C:\dev\digitalarchive_trunk>jruby -S gem list
c:/dev/ruby/downloads/jruby/bin/gem:8:in `require’: IO error – rubygems
(LoadError)
from c:/dev/ruby/downloads/jruby/bin/gem:8
Now try it with 1.4.0
C:\dev\ruby\downloads\jruby>jruby -vr./go.rb -rrubygems -e 1
jruby 1.4.0 (ruby 1.8.7 patchlevel 174) (2009-11-02 69fbfa3) (Java
HotSpot™ Client VM 1.6.0_13) [x86-java]
-e:1 warning: Useless use of a literal in void context.
C:\dev\ruby\downloads\jruby>pik jruby 15
C:\dev\ruby\downloads\jruby>jruby -vr./go.rb -rrubygems -e 1
jruby 1.5.0.dev (ruby 1.8.7 patchlevel 174) (2009-11-27 7ccf53f) (Java
HotSpot™ Client VM 1.6.0_13) [x86-java]
c:/dev/ruby/downloads/jruby/lib/ruby/1.8/Win32API.rb:25 warning:
Ambiguous first argument; make sure.
Exception in thread “main” :1: IO error – rubygems (LoadError)
…internal jruby stack elided…
from (unknown).(unknown)(:1)
Hmm.
-r
Hi Roger,
Pretty weird and unexpected.
Could you please run the same examples with:
jruby.exe -Xtrace out.log …
this would put some interesting additional info into out.log file,
maybe something interesting is in there. You could post the out.log
file as well, so I could take a look at it.
Thanks,
–Vladimir
On Mon, Nov 30, 2009 at 8:13 PM, Roger P. [email protected]
wrote:
C:\dev\digitalarchive_trunk>set RUBYOPT=
-r
Posted via http://www.ruby-forum.com/.
To unsubscribe from this list, please visit:
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Roger,
another possibility is to run jruby like that, it will print various
loading info (lots of it), maybe something of interest would be found
there:
jruby -J-Djruby.debug.loadService=true
-J-Djruby.debug.loadService.timing=true -rrubygems -e 1
(Again, you need the very recent JRuby build from master branch for it
to work).
Thanks,
–Vladimir
On Mon, Nov 30, 2009 at 10:46 PM, Vladimir S. [email protected]
wrote:
file as well, so I could take a look at it.
C:\dev\digitalarchive_trunk>jruby -S gem list
-e:1 warning: Useless use of a literal in void context.
Exception in thread “main” :1: IO error – rubygems (LoadError)
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
This looks like a stale build of JRuby, or potentially a bug in the
binding of Array#select (which seems unlikely given the number of
tests we run against Array)… Are you running off a cloned repo? If
so, “ant clean jar” to flush it out.
- Charlie
On Thu, Dec 17, 2009 at 3:36 PM, Roger P. [email protected]
wrote:
java.lang.NoSuchMethodError:
org.jruby.ast.CallNoArgBlockNode.interpret(CallNoArgBlockNode.java:64)
    at
    at org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
    at org.jruby.ast.LocalAsgnNode.interpret(LocalAsgnNode.java:123)
    at
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:309)
org.jruby.runtime.load.LoadService.tryLoadingLibraryOrScript(LoadService.java:671)
    at org.jruby.Main.run(Main.java:206)
    from
To unsubscribe from this list, please visit:
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Could you please run the same examples with:
jruby.exe -Xtrace out.log …
C:\dev\ruby\downloads\jruby\bin>jruby -Xtrace -rubygems -e “puts 3”
3
C:\dev\ruby\downloads\jruby\bin>jruby -d -rubygems -e ‘’
java.lang.NoSuchMethodError:
org.jruby.RubyArray.select(Lorg/jruby/runtime/ThreadContext;Lorg/jruby/runtime/Block;)Lorg/jruby/RubyArray;
at
org.jruby.RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$select.call(org/jruby/RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$select.gen)
at
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:299)
at
org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:117)
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:122)
at
org.jruby.ast.CallNoArgBlockNode.interpret(CallNoArgBlockNode.java:64)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104)
at org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
at
org.jruby.runtime.InterpretedBlock.evalBlockBody(InterpretedBlock.java:317)
at
org.jruby.runtime.InterpretedBlock.yield(InterpretedBlock.java:268)
at org.jruby.runtime.Block.yield(Block.java:194)
at org.jruby.RubyArray.collect(RubyArray.java:2182)
at
org.jruby.RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$collect.call(org/jruby/RubyArray$i_method_0_0$RUBYFRAMEDINVOKER$collect.gen)
at
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:299)
at
org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:117)
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:122)
at
org.jruby.ast.CallNoArgBlockNode.interpret(CallNoArgBlockNode.java:64)
at org.jruby.ast.CallNoArgNode.interpret(CallNoArgNode.java:61)
at org.jruby.ast.LocalAsgnNode.interpret(LocalAsgnNode.java:123)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104)
at org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
at
org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:174)
at
org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:173)
at
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:309)
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:148)
at
org.jruby.ast.CallOneArgNode.interpret(CallOneArgNode.java:57)
at org.jruby.ast.LocalAsgnNode.interpret(LocalAsgnNode.java:123)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104)
at org.jruby.ast.BlockNode.interpret(BlockNode.java:71)
at org.jruby.ast.RootNode.interpret(RootNode.java:129)
at org.jruby.Ruby.loadFile(Ruby.java:2454)
at
org.jruby.runtime.load.ExternalScript.load(ExternalScript.java:64)
at
org.jruby.runtime.load.LoadService.tryLoadingLibraryOrScript(LoadService.java:671)
at
org.jruby.runtime.load.LoadService.smartLoad(LoadService.java:314)
at
org.jruby.runtime.load.LoadService.require(LoadService.java:357)
at
org.jruby.runtime.load.LoadService.lockAndRequire(LoadService.java:289)
at org.jruby.RubyKernel.requireCommon(RubyKernel.java:925)
at org.jruby.RubyKernel.require(RubyKernel.java:908)
at
org.jruby.RubyKernel$s_method_1_0$RUBYFRAMEDINVOKER$require.call(org/jruby/RubyKernel$s_method_1_0$RUBYFRAMEDINVOKER$require.gen)
at
org.jruby.internal.runtime.methods.JavaMethod$JavaMethodOneOrNBlock.call(JavaMethod.java:320)
at
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:309)
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:148)
at
org.jruby.ast.FCallOneArgNode.interpret(FCallOneArgNode.java:36)
at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104)
at org.jruby.ast.RootNode.interpret(RootNode.java:129)
at org.jruby.Ruby.loadFile(Ruby.java:2454)
at
org.jruby.runtime.load.ExternalScript.load(ExternalScript.java:64)
at
org.jruby.runtime.load.LoadService.tryLoadingLibraryOrScript(LoadService.java:671)
at
org.jruby.runtime.load.LoadService.smartLoad(LoadService.java:314)
at
org.jruby.runtime.load.LoadService.require(LoadService.java:357)
at
org.jruby.runtime.load.LoadService.lockAndRequire(LoadService.java:289)
at org.jruby.RubyKernel.requireCommon(RubyKernel.java:925)
at org.jruby.RubyKernel.require(RubyKernel.java:908)
at org.jruby.Ruby.init(Ruby.java:1025)
at org.jruby.Ruby.newInstance(Ruby.java:172)
at org.jruby.Main.run(Main.java:206)
at org.jruby.Main.run(Main.java:117)
at org.jruby.Main.main(Main.java:97)
Exception in thread “main”
C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/1.8/ubygems.rb:10:in
`require’: IO error – rubygems (LoadError)
from
C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/1.8/ubygems.rb:10
from
C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/1.8/ubygems.rb:1
…internal jruby stack elided…
from
Kernel.require(C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/1.8/ubygems.rb:10)
from
(unknown).(unknown)(C:/dev/ruby/downloads/jruby/lib/ruby/site_ruby/1.8/ubygems.rb:1)
from (unknown).(unknown)(:1)
C:\dev\ruby\downloads\jruby\bin>jruby -rrubygems -e 1
Exception in thread “main” :1: IO error – rubygems (LoadError)
…internal jruby stack elided…
from (unknown).(unknown)(:1)
C:\dev\ruby\downloads\jruby\bin>jruby -S gem list
C:/dev/ruby/downloads/jruby/bin/gem:8:in `require’: IO error – rubygems
(LoadError)
from C:/dev/ruby/downloads/jruby/bin/gem:8
Thanks!
-r
On Mon, Dec 21, 2009 at 3:37 PM, Roger P. [email protected]
wrote:
Wow that did it. A bit…trippy that this was necessary, though…
-r
Heh, yeah, this is a small gotcha of our current build, sometimes it
is not smart enough to detect changes and uses stale data from older
builds. So, at the moment, I always recommend to do ‘ant clean’ before
the build, especially if you just follow the state of the main repo
and pull changes from time to time, in big chunks.
This issue has bitten us many times already, at lest I remember 4 or 5
cases like this one. If only we all had 48 hours in a day to fix
everything… 
Thanks,
–Vladimir
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Charles Nutter wrote:
This looks like a stale build of JRuby, or potentially a bug in the
binding of Array#select (which seems unlikely given the number of
tests we run against Array)… Are you running off a cloned repo? If
so, “ant clean jar” to flush it out.
Wow that did it. A bit…trippy that this was necessary, though…
-r