buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spiewak <>
Subject Re: Native Kernel#system on JRuby
Date Fri, 17 Apr 2009 21:18:15 GMT  I just went ahead and
made a separate branch, it was easier than updating the list every time I
changed something.


On Fri, Apr 17, 2009 at 3:38 PM, Daniel Spiewak <> wrote:

> Amendment:
> I forgot that Kernel#system actually needs to return Boolean, not Fixnum.
> Daniel
> On Fri, Apr 17, 2009 at 1:42 PM, Daniel Spiewak <>wrote:
>> I think we should consider this:
>> The reason being that JRuby's Kernel#system method is fundamentally broken
>> (because it is based on java.lang.Runtime.exec).  They've managed to piece
>> things together so that it's rarely an issue, but problems do surface when
>> doing things like the following:
>> system 'scala'
>> If you run this from JRuby, your terminal will freeze and refuse to accept
>> any input (except for escape sequences like Ctrl+C).  This limitation in
>> Kernel#system basically prevents any sort of working REPL support (git://
>> / interactive-shell).  In order to get
>> around this, I propose that Buildr should rewrite the Kernel#system method
>> *when running under JRuby* so that it uses the platform's native `system`
>> function (from the C stdlib).  The commit linked above (51280ab) contains
>> the necessary implementation.  Note that this commit is basically untested,
>> but it seems to work on Mac for everything I've tried so far.
>> Advantages: Buildr's external process dispatch on JRuby will be more
>> predictable and basically in line with what happens on MRI.  This will
>> probably resolve/avoid some bugs and certainly opens up a whole new series
>> of possibilities (like the interactive shell support).
>> Disadvantages: It introduces a new gem dependency on JRuby (ffi-0.3.2) and
>> actually overwrites a core Ruby method.  It's the latter that has me the
>> most concerned.  Kernel#system is quite foundational to Buildr and Ruby in
>> general, so casually monkey-patching in a new implementation is not a step
>> which should be taken lightly.
>> Thoughts?
>> Daniel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message