Nick -
Thanks for your response. Your pointer led me to the code I needed to
redirect the standard output.
Apparently, redirecting the standard output in either 'jirb' or 'irb'
causes some problems. I'm not sure of the root of the problems in
'jirb' or 'irb' but thankfully the code you pointed me
Correct me if I am wrong, but the current compiler output is all technically
legal Java class files, right? In other words, classes/bytecode that can be
natively-compiled, instrumented, profiled, obfuscated, optimized (strip of
symbols, etc.), even decompiled (as much as it may not make sense to)?
FWIW ($0.02??), my feeling is that too many people (or tools) will be
confused if they see a .class file and it isn't really exactly that. At
least a different extension will help to avoid such confusion.
You mentioned plans for a compiler that will generate class files. Will it
translate the outp
String#split raising AIOOB when passed empty string
---
Key: JRUBY-1448
URL: http://jira.codehaus.org/browse/JRUBY-1448
Project: JRuby
Issue Type: Bug
Reporter: Charles Oliver Nutte
Perhaps we can do a /dir/module/foo_rb.class as a way to mark the generated
JRuby classes?
I don't know too much about applet security, but I thought that untrusted
applets cannot use custom classloader, so JRuby falls back to no classloader
for usage in applet? If so, the AOT compiler would be an
Peter K Chan wrote:
Charlie,
So, I see the semantic mismatch, but what is the technical reason for
having a separate extension?
I see some benefits of using the standard .class extension, such as
being able to compile JRuby compiled bytecode into native code (e.g. using the
JET c
Charlie,
So, I see the semantic mismatch, but what is the technical reason for
having a separate extension?
I see some benefits of using the standard .class extension, such as
being able to compile JRuby compiled bytecode into native code (e.g. using the
JET compiler), or to run an
Python uses .pyc, for what it's worth.
Evan
On 10/18/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote:
> So yeah, the compiler's done, it can compile ahead-of-time to binary
> files you can load and run and all that. Currently the extension for
> those files is .class, but that's started to bo
So yeah, the compiler's done, it can compile ahead-of-time to binary
files you can load and run and all that. Currently the extension for
those files is .class, but that's started to bother me a bit.
Here's the deal...it's not "really" a Java class file. You can't load
the class it contains an
Chris Nelson wrote:
Cool, what did you have to change in jruby-debug? Or is already part of
your latest SVN commits? I'd love to try it out, and am downloading the
NB ruby build now.
Yes, already committed. Were just simple unimplemented methods. Those with:
throw new UnsupportedOperation
Cool, what did you have to change in jruby-debug? Or is already part of
your latest SVN commits? I'd love to try it out, and am downloading the NB
ruby build now.
--Chris
On 10/18/07, Martin Krauskopf <[EMAIL PROTECTED]> wrote:
>
> Martin Krauskopf wrote:
> > Then when JRuby interpreter is sele
Setting the priority of a dead thread causes NPE
Key: JRUBY-1447
URL: http://jira.codehaus.org/browse/JRUBY-1447
Project: JRuby
Issue Type: Bug
Reporter: Evan Weaver
As
Ok, couple of things.
Errno::ECONNABORTED doesn't exist on JRuby. This issue was already
known. http://jira.codehaus.org/browse/JRUBY-1393
Setting the priority of a dead thread causes a NPE. On MRI, it sets.
http://jira.codehaus.org/browse/JRUBY-1447
Evan
On 10/18/07, Evan Weaver <[EMAIL PROTE
Martin Krauskopf wrote:
Then when JRuby interpreter is selected in NetBeans jruby-debug is
always used, no matter to what is set in the Options dialog. And what
happens? Debugger does not start up at all - so it's currently useful
only for jruby-debug developers. But that will be false very soon.
Well, not exactly synchronous, but more synchronous, at least.
On 10/18/07, Evan Weaver <[EMAIL PROTECTED]> wrote:
> 1. Ah, I see. Try mongrel trunk again; it's synchronous now. I don't
> really see why it wasn't before, since a server can only have one
> @acceptor anyway.
>
> What kind of system
1. Ah, I see. Try mongrel trunk again; it's synchronous now. I don't
really see why it wasn't before, since a server can only have one
@acceptor anyway.
What kind of system were you getting the error on, since I can't
reproduce it myself?
2. Filed, as you are probably aware.
3 & 4; still working
Dudley Flanders wrote:
> On Oct 18, 2007, at 12:10 AM, Charles Oliver Nutter wrote:
>>> 3. You have my JDK versions already... any more tips on how to debug
>>> this? I'm using a 32bit system, for what it's worth.
>>
>> puts?
>>
>> Debugging this stuff is still a little difficult. Hopefully
>> jru
Chris Nelson wrote:
Yes, at this very moment I'm using rdebug against a Rails application.
I am able to set breakpoints in a controller and inspect variables, but
stepping doesn't appear to work in the Rails controller. However
stepping does work in simple scripts. So I think we're getting c
I was actually thinking more of classic multi-threading problems
(visibility, etc.), but anything to do with threads hasn't gotten much
love as of yet, so yeah, that does sound plausible.
Pete
On 10/18/07, Chris Nelson <[EMAIL PROTECTED]> wrote:
> Hmm, that very well might be related to what I'm
Hmm, that very well might be related to what I'm seeing trying to debug a
rails controller. In my debugging session against the debug code (hows that
for recursive?) it appears to be confused about what frame it is trying to
step into. I'm thinking this may be related to how it manages the debug
Now thats service! You rock :)
--Chris
On 10/18/07, Ola Bini <[EMAIL PROTECTED]> wrote:
>
> Chris Nelson wrote:
> > Yes, at this very moment I'm using rdebug against a Rails
> > application. I am able to set breakpoints in a controller and inspect
> > variables, but stepping doesn't appear to w
One additional caveat -- things have the potential to fall apart
quickly in a multi-threaded environment. (This, along with the th*
family of commands, is the next thing I'm doing to tackle.)
Pete
On 10/18/07, Chris Nelson <[EMAIL PROTECTED]> wrote:
> in simple scripts. So I think we're getting
Chris Nelson wrote:
Yes, at this very moment I'm using rdebug against a Rails
application. I am able to set breakpoints in a controller and inspect
variables, but stepping doesn't appear to work in the Rails
controller. However stepping does work in simple scripts. So I think
we're getting
Yes, at this very moment I'm using rdebug against a Rails application. I am
able to set breakpoints in a controller and inspect variables, but stepping
doesn't appear to work in the Rails controller. However stepping does work
in simple scripts. So I think we're getting closer, and even though i
On Oct 18, 2007, at 12:10 AM, Charles Oliver Nutter wrote:
3. You have my JDK versions already... any more tips on how to debug
this? I'm using a 32bit system, for what it's worth.
puts?
Debugging this stuff is still a little difficult. Hopefully jruby-
debug will come along soon.
For what
We're getting there. I'll have some more time to work on it over the
next few days. My guess is that we're 2-3 weeks from having something
reasonably solid.
Pete
On 10/18/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote:
>
> Debugging this stuff is still a little difficult. Hopefully jruby-d
26 matches
Mail list logo
