You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@buildr.apache.org by Pepijn Van Eeckhoudt <pe...@luciad.com> on 2010/03/01 12:00:10 UTC
Re: Next release
It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
planning on using buildr as internally running on jruby 1.4. Right now
this issue means I will either have to maintain a custom buildr build or
have every developer patch the buildr installation by hand.
Any idea on the root cause of this problem? Does commenting out that one
line have any other side effects?
Regards,
Pepijn
On 28/2/2010 00:05, Alex Boisvert wrote:
> Builders far and wide,
>
> We've got a decent amount of improvements and bug fixes done since October /
> Buildr 1.3.5 so I'd like to propose a release in the March timeframe.
>
> More specifically, I'd like to do a release candidate around March 13/14th
> and hopefully a final release March 27/28th.
>
> This should leave us enough time to round up a few more issues, some time to
> vote and update the site with an updated tagline (I dropped the ball on that
> since December) and deal with some updates/changes on the release side
> (gemcutter).
>
> How does that sound? Are we ready to call the next release 1.4.0?
>
> alex
>
>
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
Re: Next release
Posted by Antoine Toulme <an...@lunar-ocean.com>.
Very cool. I'll let headius know we are past that hurdle. Thanks everybody!
On Mon, Mar 1, 2010 at 09:23, Daniel Spiewak <dj...@gmail.com> wrote:
> Just give it a shot with your stuff. Run a `build` (compile + test) and
> then try to open a shell (preferably JIRB or Scala). If both of those
> work,
> then we can have fairly high confidence that things are sorted.
>
> Daniel
>
> On Mon, Mar 1, 2010 at 11:21 AM, Pepijn Van Eeckhoudt <
> pepijn.vaneeckhoudt@luciad.com> wrote:
>
> > Any ideas on how to test this thoroughly? I can't imagine this causing a
> > regression as the debugger now shows system is being loaded from msvcrt
> > which is exactly the method you want to load.
> >
> > Pepijn
> >
> >
> > On 1/3/2010 18:17, Daniel Spiewak wrote:
> >
> >> Fix committed in r917597. Note that this only applies when
> >> Buildr::Util::win_os? is true.
> >>
> >> Daniel
> >>
> >> On Mon, Mar 1, 2010 at 11:13 AM, Pepijn Van Eeckhoudt<
> >> pepijn.vaneeckhoudt@luciad.com> wrote:
> >>
> >>
> >>
> >>> Or better yet just use LIBC directly instead :)
> >>> So ffi_lib FFI::Platform::LIBC
> >>>
> >>> I'll add this as a comment to BUILDR-348
> >>>
> >>> Pepijn
> >>>
> >>>
> >>> On 1/3/2010 18:05, Pepijn Van Eeckhoudt wrote:
> >>>
> >>>
> >>>
> >>>> Aha, that confirms what I suspected. I was about to check the JRuby
> >>>> source
> >>>> code, so thanks for saving me some digging :)
> >>>>
> >>>> Adding
> >>>> ffi_lib "c"
> >>>> before the attach_function does the trick. map_library_name maps this
> to
> >>>> Platform::LIBC and then the attach works correctly.
> >>>>
> >>>> Pepijn
> >>>>
> >>>> On 1/3/2010 17:50, Antoine Toulme wrote:
> >>>>
> >>>>
> >>>>
> >>>>> See my comment on BUILDR-348.
> >>>>>
> >>>>> On Mon, Mar 1, 2010 at 08:49, Pepijn Van Eeckhoudt<
> >>>>> pepijn.vaneeckhoudt@luciad.com> wrote:
> >>>>>
> >>>>> Just tested that; nothing happens. I don't see the vim output and
> jirb
> >>>>>
> >>>>>
> >>>>>> is
> >>>>>> no longer responding to input.
> >>>>>>
> >>>>>> Pepijn
> >>>>>>
> >>>>>>
> >>>>>> On 1/3/2010 17:37, Alex Boisvert wrote:
> >>>>>>
> >>>>>> They may have fixed system() such that using FFI directly wouldn't
> be
> >>>>>>
> >>>>>>
> >>>>>>> necessary anymore. A simple test such as "system 'vim'" from jirb
> on
> >>>>>>> Windows would confirm.
> >>>>>>>
> >>>>>>> alex
> >>>>>>>
> >>>>>>> On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulme<
> >>>>>>> antoine@lunar-ocean.com
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> I can contact the jruby folks and see if a jruby update would help
> -
> >>>>>>>
> >>>>>>>
> >>>>>>>> JFFI
> >>>>>>>> is
> >>>>>>>> now 1.0 btw, while it was 0.4 in 1.4.0.
> >>>>>>>>
> >>>>>>>> On Mon, Mar 1, 2010 at 08:12, Alex Boisvert<
> alex.boisvert@gmail.com
> >>>>>>>> >
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt<
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> pepijn.vaneeckhoudt@luciad.com> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> It would be nice if BUILDR-348 could be resolved for 1.4.0. We
> are
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> planning
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> on using buildr as internally running on jruby 1.4. Right now
> this
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> issue
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> means I will either have to maintain a custom buildr build or
> have
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> every
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> developer patch the buildr installation by hand.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Any idea on the root cause of this problem? Does commenting out
> >>>>>>>>>> that
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> one
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> line have any other side effects?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> The issue is that JRuby use{s,d} the JVM's System.exec() call
> to
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> spawn
> >>>>>>>>> external processes, which isn't 100% equivalent to Unix system()
> >>>>>>>>> call.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> For
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> instance, if you spawned a process like 'vim' or a language shell
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> like
> >>>>>>>>> 'scala' or 'irb', then you wouldn't be able to interact with the
> >>>>>>>>> sub-process
> >>>>>>>>> correctly due to incomplete redirection of all terminal
> >>>>>>>>> capabilities.
> >>>>>>>>>
> >>>>>>>>> To solve this, we override the system() call to circumvent the
> >>>>>>>>> JRuby's
> >>>>>>>>> system call and directly call the native system() using FFI.
> >>>>>>>>>
> >>>>>>>>> I don't know what's the state of things on JRuby 1.4.0 + Windows
> >>>>>>>>> but
> >>>>>>>>> some
> >>>>>>>>> internals seem to have changed which is why we're getting the
> error
> >>>>>>>>> described in BUILDR-348. Somebody needs to investigate what
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> works/doesn't
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> work on Windows -- the workaround I provided on BUILDR-348 simply
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> reverts
> >>>>>>>>> to
> >>>>>>>>> using the standard system() implementation, which works for most
> >>>>>>>>> things
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> but
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> not shelling out to interactive apps.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> alex
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> --
> >>>>>> Pepijn Van Eeckhoudt - Project Leader
> >>>>>> T +32 16 23 95 91
> >>>>>> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
> >>>>>>
> >>>>>> LUCIAD - high performance visualization
> >>>>>> Wetenschapspark Arenberg | Gaston Geenslaan 9
> >>>>>> 3001 Leuven | Belgium | www.luciad.com
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>> --
> >>> Pepijn Van Eeckhoudt - Project Leader
> >>> T +32 16 23 95 91
> >>> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
> >>>
> >>> LUCIAD - high performance visualization
> >>> Wetenschapspark Arenberg | Gaston Geenslaan 9
> >>> 3001 Leuven | Belgium | www.luciad.com
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> > --
> > Pepijn Van Eeckhoudt - Project Leader
> > T +32 16 23 95 91
> > F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
> >
> > LUCIAD - high performance visualization
> > Wetenschapspark Arenberg | Gaston Geenslaan 9
> > 3001 Leuven | Belgium | www.luciad.com
> >
> >
> >
>
Re: Next release
Posted by Daniel Spiewak <dj...@gmail.com>.
Just give it a shot with your stuff. Run a `build` (compile + test) and
then try to open a shell (preferably JIRB or Scala). If both of those work,
then we can have fairly high confidence that things are sorted.
Daniel
On Mon, Mar 1, 2010 at 11:21 AM, Pepijn Van Eeckhoudt <
pepijn.vaneeckhoudt@luciad.com> wrote:
> Any ideas on how to test this thoroughly? I can't imagine this causing a
> regression as the debugger now shows system is being loaded from msvcrt
> which is exactly the method you want to load.
>
> Pepijn
>
>
> On 1/3/2010 18:17, Daniel Spiewak wrote:
>
>> Fix committed in r917597. Note that this only applies when
>> Buildr::Util::win_os? is true.
>>
>> Daniel
>>
>> On Mon, Mar 1, 2010 at 11:13 AM, Pepijn Van Eeckhoudt<
>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>
>>
>>
>>> Or better yet just use LIBC directly instead :)
>>> So ffi_lib FFI::Platform::LIBC
>>>
>>> I'll add this as a comment to BUILDR-348
>>>
>>> Pepijn
>>>
>>>
>>> On 1/3/2010 18:05, Pepijn Van Eeckhoudt wrote:
>>>
>>>
>>>
>>>> Aha, that confirms what I suspected. I was about to check the JRuby
>>>> source
>>>> code, so thanks for saving me some digging :)
>>>>
>>>> Adding
>>>> ffi_lib "c"
>>>> before the attach_function does the trick. map_library_name maps this to
>>>> Platform::LIBC and then the attach works correctly.
>>>>
>>>> Pepijn
>>>>
>>>> On 1/3/2010 17:50, Antoine Toulme wrote:
>>>>
>>>>
>>>>
>>>>> See my comment on BUILDR-348.
>>>>>
>>>>> On Mon, Mar 1, 2010 at 08:49, Pepijn Van Eeckhoudt<
>>>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>>>
>>>>> Just tested that; nothing happens. I don't see the vim output and jirb
>>>>>
>>>>>
>>>>>> is
>>>>>> no longer responding to input.
>>>>>>
>>>>>> Pepijn
>>>>>>
>>>>>>
>>>>>> On 1/3/2010 17:37, Alex Boisvert wrote:
>>>>>>
>>>>>> They may have fixed system() such that using FFI directly wouldn't be
>>>>>>
>>>>>>
>>>>>>> necessary anymore. A simple test such as "system 'vim'" from jirb on
>>>>>>> Windows would confirm.
>>>>>>>
>>>>>>> alex
>>>>>>>
>>>>>>> On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulme<
>>>>>>> antoine@lunar-ocean.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> I can contact the jruby folks and see if a jruby update would help -
>>>>>>>
>>>>>>>
>>>>>>>> JFFI
>>>>>>>> is
>>>>>>>> now 1.0 btw, while it was 0.4 in 1.4.0.
>>>>>>>>
>>>>>>>> On Mon, Mar 1, 2010 at 08:12, Alex Boisvert<alex.boisvert@gmail.com
>>>>>>>> >
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt<
>>>>>>>>
>>>>>>>>
>>>>>>>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> planning
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> on using buildr as internally running on jruby 1.4. Right now this
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> issue
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> means I will either have to maintain a custom buildr build or have
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> every
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> developer patch the buildr installation by hand.
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Any idea on the root cause of this problem? Does commenting out
>>>>>>>>>> that
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> one
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> line have any other side effects?
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The issue is that JRuby use{s,d} the JVM's System.exec() call to
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> spawn
>>>>>>>>> external processes, which isn't 100% equivalent to Unix system()
>>>>>>>>> call.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> instance, if you spawned a process like 'vim' or a language shell
>>>>>>>>
>>>>>>>>
>>>>>>>>> like
>>>>>>>>> 'scala' or 'irb', then you wouldn't be able to interact with the
>>>>>>>>> sub-process
>>>>>>>>> correctly due to incomplete redirection of all terminal
>>>>>>>>> capabilities.
>>>>>>>>>
>>>>>>>>> To solve this, we override the system() call to circumvent the
>>>>>>>>> JRuby's
>>>>>>>>> system call and directly call the native system() using FFI.
>>>>>>>>>
>>>>>>>>> I don't know what's the state of things on JRuby 1.4.0 + Windows
>>>>>>>>> but
>>>>>>>>> some
>>>>>>>>> internals seem to have changed which is why we're getting the error
>>>>>>>>> described in BUILDR-348. Somebody needs to investigate what
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> works/doesn't
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> work on Windows -- the workaround I provided on BUILDR-348 simply
>>>>>>>>
>>>>>>>>
>>>>>>>>> reverts
>>>>>>>>> to
>>>>>>>>> using the standard system() implementation, which works for most
>>>>>>>>> things
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> but
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> not shelling out to interactive apps.
>>>>>>>>
>>>>>>>>
>>>>>>>>> alex
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Pepijn Van Eeckhoudt - Project Leader
>>>>>> T +32 16 23 95 91
>>>>>> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
>>>>>>
>>>>>> LUCIAD - high performance visualization
>>>>>> Wetenschapspark Arenberg | Gaston Geenslaan 9
>>>>>> 3001 Leuven | Belgium | www.luciad.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>> --
>>> Pepijn Van Eeckhoudt - Project Leader
>>> T +32 16 23 95 91
>>> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
>>>
>>> LUCIAD - high performance visualization
>>> Wetenschapspark Arenberg | Gaston Geenslaan 9
>>> 3001 Leuven | Belgium | www.luciad.com
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
> --
> Pepijn Van Eeckhoudt - Project Leader
> T +32 16 23 95 91
> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
>
> LUCIAD - high performance visualization
> Wetenschapspark Arenberg | Gaston Geenslaan 9
> 3001 Leuven | Belgium | www.luciad.com
>
>
>
Re: Next release
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
Any ideas on how to test this thoroughly? I can't imagine this causing a
regression as the debugger now shows system is being loaded from msvcrt
which is exactly the method you want to load.
Pepijn
On 1/3/2010 18:17, Daniel Spiewak wrote:
> Fix committed in r917597. Note that this only applies when
> Buildr::Util::win_os? is true.
>
> Daniel
>
> On Mon, Mar 1, 2010 at 11:13 AM, Pepijn Van Eeckhoudt<
> pepijn.vaneeckhoudt@luciad.com> wrote:
>
>
>> Or better yet just use LIBC directly instead :)
>> So ffi_lib FFI::Platform::LIBC
>>
>> I'll add this as a comment to BUILDR-348
>>
>> Pepijn
>>
>>
>> On 1/3/2010 18:05, Pepijn Van Eeckhoudt wrote:
>>
>>
>>> Aha, that confirms what I suspected. I was about to check the JRuby source
>>> code, so thanks for saving me some digging :)
>>>
>>> Adding
>>> ffi_lib "c"
>>> before the attach_function does the trick. map_library_name maps this to
>>> Platform::LIBC and then the attach works correctly.
>>>
>>> Pepijn
>>>
>>> On 1/3/2010 17:50, Antoine Toulme wrote:
>>>
>>>
>>>> See my comment on BUILDR-348.
>>>>
>>>> On Mon, Mar 1, 2010 at 08:49, Pepijn Van Eeckhoudt<
>>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>>
>>>> Just tested that; nothing happens. I don't see the vim output and jirb
>>>>
>>>>> is
>>>>> no longer responding to input.
>>>>>
>>>>> Pepijn
>>>>>
>>>>>
>>>>> On 1/3/2010 17:37, Alex Boisvert wrote:
>>>>>
>>>>> They may have fixed system() such that using FFI directly wouldn't be
>>>>>
>>>>>> necessary anymore. A simple test such as "system 'vim'" from jirb on
>>>>>> Windows would confirm.
>>>>>>
>>>>>> alex
>>>>>>
>>>>>> On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulme<antoine@lunar-ocean.com
>>>>>>
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> I can contact the jruby folks and see if a jruby update would help -
>>>>>>
>>>>>>> JFFI
>>>>>>> is
>>>>>>> now 1.0 btw, while it was 0.4 in 1.4.0.
>>>>>>>
>>>>>>> On Mon, Mar 1, 2010 at 08:12, Alex Boisvert<al...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt<
>>>>>>>
>>>>>>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
>>>>>>>>
>>>>>>>>>
>>>>>>>>> planning
>>>>>>>>>
>>>>>>>>
>>>>>>>> on using buildr as internally running on jruby 1.4. Right now this
>>>>>>>>
>>>>>>>>>
>>>>>>>>> issue
>>>>>>>>>
>>>>>>>>
>>>>>>> means I will either have to maintain a custom buildr build or have
>>>>>>>
>>>>>>>>
>>>>>>>>> every
>>>>>>>>>
>>>>>>>>
>>>>>>> developer patch the buildr installation by hand.
>>>>>>>
>>>>>>>>
>>>>>>>>> Any idea on the root cause of this problem? Does commenting out that
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> one
>>>>>>>>>
>>>>>>>>
>>>>>>> line have any other side effects?
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The issue is that JRuby use{s,d} the JVM's System.exec() call to
>>>>>>>>>
>>>>>>>> spawn
>>>>>>>> external processes, which isn't 100% equivalent to Unix system()
>>>>>>>> call.
>>>>>>>>
>>>>>>>>
>>>>>>>> For
>>>>>>>>
>>>>>>>
>>>>>>> instance, if you spawned a process like 'vim' or a language shell
>>>>>>>
>>>>>>>> like
>>>>>>>> 'scala' or 'irb', then you wouldn't be able to interact with the
>>>>>>>> sub-process
>>>>>>>> correctly due to incomplete redirection of all terminal capabilities.
>>>>>>>>
>>>>>>>> To solve this, we override the system() call to circumvent the
>>>>>>>> JRuby's
>>>>>>>> system call and directly call the native system() using FFI.
>>>>>>>>
>>>>>>>> I don't know what's the state of things on JRuby 1.4.0 + Windows but
>>>>>>>> some
>>>>>>>> internals seem to have changed which is why we're getting the error
>>>>>>>> described in BUILDR-348. Somebody needs to investigate what
>>>>>>>>
>>>>>>>>
>>>>>>>> works/doesn't
>>>>>>>>
>>>>>>>
>>>>>>> work on Windows -- the workaround I provided on BUILDR-348 simply
>>>>>>>
>>>>>>>> reverts
>>>>>>>> to
>>>>>>>> using the standard system() implementation, which works for most
>>>>>>>> things
>>>>>>>>
>>>>>>>>
>>>>>>>> but
>>>>>>>>
>>>>>>>
>>>>>>> not shelling out to interactive apps.
>>>>>>>
>>>>>>>> alex
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>> --
>>>>> Pepijn Van Eeckhoudt - Project Leader
>>>>> T +32 16 23 95 91
>>>>> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
>>>>>
>>>>> LUCIAD - high performance visualization
>>>>> Wetenschapspark Arenberg | Gaston Geenslaan 9
>>>>> 3001 Leuven | Belgium | www.luciad.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>> --
>> Pepijn Van Eeckhoudt - Project Leader
>> T +32 16 23 95 91
>> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
>>
>> LUCIAD - high performance visualization
>> Wetenschapspark Arenberg | Gaston Geenslaan 9
>> 3001 Leuven | Belgium | www.luciad.com
>>
>>
>>
>>
>
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
Re: Next release
Posted by Daniel Spiewak <dj...@gmail.com>.
Fix committed in r917597. Note that this only applies when
Buildr::Util::win_os? is true.
Daniel
On Mon, Mar 1, 2010 at 11:13 AM, Pepijn Van Eeckhoudt <
pepijn.vaneeckhoudt@luciad.com> wrote:
> Or better yet just use LIBC directly instead :)
> So ffi_lib FFI::Platform::LIBC
>
> I'll add this as a comment to BUILDR-348
>
> Pepijn
>
>
> On 1/3/2010 18:05, Pepijn Van Eeckhoudt wrote:
>
>> Aha, that confirms what I suspected. I was about to check the JRuby source
>> code, so thanks for saving me some digging :)
>>
>> Adding
>> ffi_lib "c"
>> before the attach_function does the trick. map_library_name maps this to
>> Platform::LIBC and then the attach works correctly.
>>
>> Pepijn
>>
>> On 1/3/2010 17:50, Antoine Toulme wrote:
>>
>>> See my comment on BUILDR-348.
>>>
>>> On Mon, Mar 1, 2010 at 08:49, Pepijn Van Eeckhoudt<
>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>
>>> Just tested that; nothing happens. I don't see the vim output and jirb
>>>> is
>>>> no longer responding to input.
>>>>
>>>> Pepijn
>>>>
>>>>
>>>> On 1/3/2010 17:37, Alex Boisvert wrote:
>>>>
>>>> They may have fixed system() such that using FFI directly wouldn't be
>>>>> necessary anymore. A simple test such as "system 'vim'" from jirb on
>>>>> Windows would confirm.
>>>>>
>>>>> alex
>>>>>
>>>>> On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulme<antoine@lunar-ocean.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>
>>>>>
>>>>> I can contact the jruby folks and see if a jruby update would help -
>>>>>> JFFI
>>>>>> is
>>>>>> now 1.0 btw, while it was 0.4 in 1.4.0.
>>>>>>
>>>>>> On Mon, Mar 1, 2010 at 08:12, Alex Boisvert<al...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt<
>>>>>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
>>>>>>>>
>>>>>>>>
>>>>>>>> planning
>>>>>>>
>>>>>>>
>>>>>>> on using buildr as internally running on jruby 1.4. Right now this
>>>>>>>>
>>>>>>>>
>>>>>>>> issue
>>>>>>>
>>>>>>
>>>>>> means I will either have to maintain a custom buildr build or have
>>>>>>>
>>>>>>>>
>>>>>>>> every
>>>>>>>
>>>>>>
>>>>>> developer patch the buildr installation by hand.
>>>>>>>
>>>>>>>> Any idea on the root cause of this problem? Does commenting out that
>>>>>>>>
>>>>>>>>
>>>>>>>> one
>>>>>>>
>>>>>>
>>>>>> line have any other side effects?
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> The issue is that JRuby use{s,d} the JVM's System.exec() call to
>>>>>>> spawn
>>>>>>> external processes, which isn't 100% equivalent to Unix system()
>>>>>>> call.
>>>>>>>
>>>>>>>
>>>>>>> For
>>>>>>
>>>>>>
>>>>>> instance, if you spawned a process like 'vim' or a language shell
>>>>>>> like
>>>>>>> 'scala' or 'irb', then you wouldn't be able to interact with the
>>>>>>> sub-process
>>>>>>> correctly due to incomplete redirection of all terminal capabilities.
>>>>>>>
>>>>>>> To solve this, we override the system() call to circumvent the
>>>>>>> JRuby's
>>>>>>> system call and directly call the native system() using FFI.
>>>>>>>
>>>>>>> I don't know what's the state of things on JRuby 1.4.0 + Windows but
>>>>>>> some
>>>>>>> internals seem to have changed which is why we're getting the error
>>>>>>> described in BUILDR-348. Somebody needs to investigate what
>>>>>>>
>>>>>>>
>>>>>>> works/doesn't
>>>>>>
>>>>>>
>>>>>> work on Windows -- the workaround I provided on BUILDR-348 simply
>>>>>>> reverts
>>>>>>> to
>>>>>>> using the standard system() implementation, which works for most
>>>>>>> things
>>>>>>>
>>>>>>>
>>>>>>> but
>>>>>>
>>>>>>
>>>>>> not shelling out to interactive apps.
>>>>>>>
>>>>>>> alex
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> --
>>>> Pepijn Van Eeckhoudt - Project Leader
>>>> T +32 16 23 95 91
>>>> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
>>>>
>>>> LUCIAD - high performance visualization
>>>> Wetenschapspark Arenberg | Gaston Geenslaan 9
>>>> 3001 Leuven | Belgium | www.luciad.com
>>>>
>>>>
>>>>
>>>>
>>
>>
>
> --
> Pepijn Van Eeckhoudt - Project Leader
> T +32 16 23 95 91
> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
>
> LUCIAD - high performance visualization
> Wetenschapspark Arenberg | Gaston Geenslaan 9
> 3001 Leuven | Belgium | www.luciad.com
>
>
>
Re: Next release
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
Or better yet just use LIBC directly instead :)
So ffi_lib FFI::Platform::LIBC
I'll add this as a comment to BUILDR-348
Pepijn
On 1/3/2010 18:05, Pepijn Van Eeckhoudt wrote:
> Aha, that confirms what I suspected. I was about to check the JRuby
> source code, so thanks for saving me some digging :)
>
> Adding
> ffi_lib "c"
> before the attach_function does the trick. map_library_name maps this
> to Platform::LIBC and then the attach works correctly.
>
> Pepijn
>
> On 1/3/2010 17:50, Antoine Toulme wrote:
>> See my comment on BUILDR-348.
>>
>> On Mon, Mar 1, 2010 at 08:49, Pepijn Van Eeckhoudt<
>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>
>>> Just tested that; nothing happens. I don't see the vim output and
>>> jirb is
>>> no longer responding to input.
>>>
>>> Pepijn
>>>
>>>
>>> On 1/3/2010 17:37, Alex Boisvert wrote:
>>>
>>>> They may have fixed system() such that using FFI directly wouldn't be
>>>> necessary anymore. A simple test such as "system 'vim'" from jirb on
>>>> Windows would confirm.
>>>>
>>>> alex
>>>>
>>>> On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulme<antoine@lunar-ocean.com
>>>>> wrote:
>>>>
>>>>
>>>>> I can contact the jruby folks and see if a jruby update would help
>>>>> - JFFI
>>>>> is
>>>>> now 1.0 btw, while it was 0.4 in 1.4.0.
>>>>>
>>>>> On Mon, Mar 1, 2010 at 08:12, Alex Boisvert<al...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt<
>>>>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
>>>>>>>
>>>>>>>
>>>>>> planning
>>>>>>
>>>>>>
>>>>>>> on using buildr as internally running on jruby 1.4. Right now this
>>>>>>>
>>>>>>>
>>>>>> issue
>>>>>
>>>>>> means I will either have to maintain a custom buildr build or have
>>>>>>>
>>>>>> every
>>>>>
>>>>>> developer patch the buildr installation by hand.
>>>>>>> Any idea on the root cause of this problem? Does commenting out
>>>>>>> that
>>>>>>>
>>>>>>>
>>>>>> one
>>>>>
>>>>>> line have any other side effects?
>>>>>>>
>>>>>>>
>>>>>> The issue is that JRuby use{s,d} the JVM's System.exec() call to
>>>>>> spawn
>>>>>> external processes, which isn't 100% equivalent to Unix system()
>>>>>> call.
>>>>>>
>>>>>>
>>>>> For
>>>>>
>>>>>
>>>>>> instance, if you spawned a process like 'vim' or a language shell
>>>>>> like
>>>>>> 'scala' or 'irb', then you wouldn't be able to interact with the
>>>>>> sub-process
>>>>>> correctly due to incomplete redirection of all terminal
>>>>>> capabilities.
>>>>>>
>>>>>> To solve this, we override the system() call to circumvent the
>>>>>> JRuby's
>>>>>> system call and directly call the native system() using FFI.
>>>>>>
>>>>>> I don't know what's the state of things on JRuby 1.4.0 + Windows but
>>>>>> some
>>>>>> internals seem to have changed which is why we're getting the error
>>>>>> described in BUILDR-348. Somebody needs to investigate what
>>>>>>
>>>>>>
>>>>> works/doesn't
>>>>>
>>>>>
>>>>>> work on Windows -- the workaround I provided on BUILDR-348 simply
>>>>>> reverts
>>>>>> to
>>>>>> using the standard system() implementation, which works for most
>>>>>> things
>>>>>>
>>>>>>
>>>>> but
>>>>>
>>>>>
>>>>>> not shelling out to interactive apps.
>>>>>>
>>>>>> alex
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Pepijn Van Eeckhoudt - Project Leader
>>> T +32 16 23 95 91
>>> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
>>>
>>> LUCIAD - high performance visualization
>>> Wetenschapspark Arenberg | Gaston Geenslaan 9
>>> 3001 Leuven | Belgium | www.luciad.com
>>>
>>>
>>>
>
>
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
Re: Next release
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
Aha, that confirms what I suspected. I was about to check the JRuby
source code, so thanks for saving me some digging :)
Adding
ffi_lib "c"
before the attach_function does the trick. map_library_name maps this to
Platform::LIBC and then the attach works correctly.
Pepijn
On 1/3/2010 17:50, Antoine Toulme wrote:
> See my comment on BUILDR-348.
>
> On Mon, Mar 1, 2010 at 08:49, Pepijn Van Eeckhoudt<
> pepijn.vaneeckhoudt@luciad.com> wrote:
>
>
>> Just tested that; nothing happens. I don't see the vim output and jirb is
>> no longer responding to input.
>>
>> Pepijn
>>
>>
>> On 1/3/2010 17:37, Alex Boisvert wrote:
>>
>>
>>> They may have fixed system() such that using FFI directly wouldn't be
>>> necessary anymore. A simple test such as "system 'vim'" from jirb on
>>> Windows would confirm.
>>>
>>> alex
>>>
>>> On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulme<antoine@lunar-ocean.com
>>>
>>>> wrote:
>>>>
>>>
>>>
>>>
>>>> I can contact the jruby folks and see if a jruby update would help - JFFI
>>>> is
>>>> now 1.0 btw, while it was 0.4 in 1.4.0.
>>>>
>>>> On Mon, Mar 1, 2010 at 08:12, Alex Boisvert<al...@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt<
>>>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
>>>>>>
>>>>>>
>>>>>>
>>>>> planning
>>>>>
>>>>>
>>>>>
>>>>>> on using buildr as internally running on jruby 1.4. Right now this
>>>>>>
>>>>>>
>>>>>>
>>>>> issue
>>>>>
>>>>
>>>>
>>>>> means I will either have to maintain a custom buildr build or have
>>>>>
>>>>>>
>>>>>>
>>>>> every
>>>>>
>>>>
>>>>
>>>>> developer patch the buildr installation by hand.
>>>>>
>>>>>> Any idea on the root cause of this problem? Does commenting out that
>>>>>>
>>>>>>
>>>>>>
>>>>> one
>>>>>
>>>>
>>>>
>>>>> line have any other side effects?
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> The issue is that JRuby use{s,d} the JVM's System.exec() call to spawn
>>>>> external processes, which isn't 100% equivalent to Unix system() call.
>>>>>
>>>>>
>>>>>
>>>> For
>>>>
>>>>
>>>>
>>>>> instance, if you spawned a process like 'vim' or a language shell like
>>>>> 'scala' or 'irb', then you wouldn't be able to interact with the
>>>>> sub-process
>>>>> correctly due to incomplete redirection of all terminal capabilities.
>>>>>
>>>>> To solve this, we override the system() call to circumvent the JRuby's
>>>>> system call and directly call the native system() using FFI.
>>>>>
>>>>> I don't know what's the state of things on JRuby 1.4.0 + Windows but
>>>>> some
>>>>> internals seem to have changed which is why we're getting the error
>>>>> described in BUILDR-348. Somebody needs to investigate what
>>>>>
>>>>>
>>>>>
>>>> works/doesn't
>>>>
>>>>
>>>>
>>>>> work on Windows -- the workaround I provided on BUILDR-348 simply
>>>>> reverts
>>>>> to
>>>>> using the standard system() implementation, which works for most things
>>>>>
>>>>>
>>>>>
>>>> but
>>>>
>>>>
>>>>
>>>>> not shelling out to interactive apps.
>>>>>
>>>>> alex
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Pepijn Van Eeckhoudt - Project Leader
>> T +32 16 23 95 91
>> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
>>
>> LUCIAD - high performance visualization
>> Wetenschapspark Arenberg | Gaston Geenslaan 9
>> 3001 Leuven | Belgium | www.luciad.com
>>
>>
>>
>>
>
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
Re: Next release
Posted by Antoine Toulme <an...@lunar-ocean.com>.
See my comment on BUILDR-348.
On Mon, Mar 1, 2010 at 08:49, Pepijn Van Eeckhoudt <
pepijn.vaneeckhoudt@luciad.com> wrote:
> Just tested that; nothing happens. I don't see the vim output and jirb is
> no longer responding to input.
>
> Pepijn
>
>
> On 1/3/2010 17:37, Alex Boisvert wrote:
>
>> They may have fixed system() such that using FFI directly wouldn't be
>> necessary anymore. A simple test such as "system 'vim'" from jirb on
>> Windows would confirm.
>>
>> alex
>>
>> On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulme<antoine@lunar-ocean.com
>> >wrote:
>>
>>
>>
>>> I can contact the jruby folks and see if a jruby update would help - JFFI
>>> is
>>> now 1.0 btw, while it was 0.4 in 1.4.0.
>>>
>>> On Mon, Mar 1, 2010 at 08:12, Alex Boisvert<al...@gmail.com>
>>> wrote:
>>>
>>>
>>>
>>>> On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt<
>>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>>
>>>>
>>>>
>>>>> It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
>>>>>
>>>>>
>>>> planning
>>>>
>>>>
>>>>> on using buildr as internally running on jruby 1.4. Right now this
>>>>>
>>>>>
>>>> issue
>>>
>>>
>>>> means I will either have to maintain a custom buildr build or have
>>>>>
>>>>>
>>>> every
>>>
>>>
>>>> developer patch the buildr installation by hand.
>>>>>
>>>>> Any idea on the root cause of this problem? Does commenting out that
>>>>>
>>>>>
>>>> one
>>>
>>>
>>>> line have any other side effects?
>>>>>
>>>>>
>>>>>
>>>> The issue is that JRuby use{s,d} the JVM's System.exec() call to spawn
>>>> external processes, which isn't 100% equivalent to Unix system() call.
>>>>
>>>>
>>> For
>>>
>>>
>>>> instance, if you spawned a process like 'vim' or a language shell like
>>>> 'scala' or 'irb', then you wouldn't be able to interact with the
>>>> sub-process
>>>> correctly due to incomplete redirection of all terminal capabilities.
>>>>
>>>> To solve this, we override the system() call to circumvent the JRuby's
>>>> system call and directly call the native system() using FFI.
>>>>
>>>> I don't know what's the state of things on JRuby 1.4.0 + Windows but
>>>> some
>>>> internals seem to have changed which is why we're getting the error
>>>> described in BUILDR-348. Somebody needs to investigate what
>>>>
>>>>
>>> works/doesn't
>>>
>>>
>>>> work on Windows -- the workaround I provided on BUILDR-348 simply
>>>> reverts
>>>> to
>>>> using the standard system() implementation, which works for most things
>>>>
>>>>
>>> but
>>>
>>>
>>>> not shelling out to interactive apps.
>>>>
>>>> alex
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
> --
> Pepijn Van Eeckhoudt - Project Leader
> T +32 16 23 95 91
> F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
>
> LUCIAD - high performance visualization
> Wetenschapspark Arenberg | Gaston Geenslaan 9
> 3001 Leuven | Belgium | www.luciad.com
>
>
>
Re: Next release
Posted by Pepijn Van Eeckhoudt <pe...@luciad.com>.
Just tested that; nothing happens. I don't see the vim output and jirb
is no longer responding to input.
Pepijn
On 1/3/2010 17:37, Alex Boisvert wrote:
> They may have fixed system() such that using FFI directly wouldn't be
> necessary anymore. A simple test such as "system 'vim'" from jirb on
> Windows would confirm.
>
> alex
>
> On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulme<an...@lunar-ocean.com>wrote:
>
>
>> I can contact the jruby folks and see if a jruby update would help - JFFI
>> is
>> now 1.0 btw, while it was 0.4 in 1.4.0.
>>
>> On Mon, Mar 1, 2010 at 08:12, Alex Boisvert<al...@gmail.com>
>> wrote:
>>
>>
>>> On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt<
>>> pepijn.vaneeckhoudt@luciad.com> wrote:
>>>
>>>
>>>> It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
>>>>
>>> planning
>>>
>>>> on using buildr as internally running on jruby 1.4. Right now this
>>>>
>> issue
>>
>>>> means I will either have to maintain a custom buildr build or have
>>>>
>> every
>>
>>>> developer patch the buildr installation by hand.
>>>>
>>>> Any idea on the root cause of this problem? Does commenting out that
>>>>
>> one
>>
>>>> line have any other side effects?
>>>>
>>>>
>>> The issue is that JRuby use{s,d} the JVM's System.exec() call to spawn
>>> external processes, which isn't 100% equivalent to Unix system() call.
>>>
>> For
>>
>>> instance, if you spawned a process like 'vim' or a language shell like
>>> 'scala' or 'irb', then you wouldn't be able to interact with the
>>> sub-process
>>> correctly due to incomplete redirection of all terminal capabilities.
>>>
>>> To solve this, we override the system() call to circumvent the JRuby's
>>> system call and directly call the native system() using FFI.
>>>
>>> I don't know what's the state of things on JRuby 1.4.0 + Windows but some
>>> internals seem to have changed which is why we're getting the error
>>> described in BUILDR-348. Somebody needs to investigate what
>>>
>> works/doesn't
>>
>>> work on Windows -- the workaround I provided on BUILDR-348 simply reverts
>>> to
>>> using the standard system() implementation, which works for most things
>>>
>> but
>>
>>> not shelling out to interactive apps.
>>>
>>> alex
>>>
>>>
>>
>
--
Pepijn Van Eeckhoudt - Project Leader
T +32 16 23 95 91
F +32 16 29 34 22 | pepijn.vaneeckhoudt@luciad.com
LUCIAD - high performance visualization
Wetenschapspark Arenberg | Gaston Geenslaan 9
3001 Leuven | Belgium | www.luciad.com
Re: Next release
Posted by Alex Boisvert <al...@gmail.com>.
They may have fixed system() such that using FFI directly wouldn't be
necessary anymore. A simple test such as "system 'vim'" from jirb on
Windows would confirm.
alex
On Mon, Mar 1, 2010 at 8:16 AM, Antoine Toulme <an...@lunar-ocean.com>wrote:
> I can contact the jruby folks and see if a jruby update would help - JFFI
> is
> now 1.0 btw, while it was 0.4 in 1.4.0.
>
> On Mon, Mar 1, 2010 at 08:12, Alex Boisvert <al...@gmail.com>
> wrote:
>
> > On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt <
> > pepijn.vaneeckhoudt@luciad.com> wrote:
> >
> > > It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
> > planning
> > > on using buildr as internally running on jruby 1.4. Right now this
> issue
> > > means I will either have to maintain a custom buildr build or have
> every
> > > developer patch the buildr installation by hand.
> > >
> > > Any idea on the root cause of this problem? Does commenting out that
> one
> > > line have any other side effects?
> > >
> >
> > The issue is that JRuby use{s,d} the JVM's System.exec() call to spawn
> > external processes, which isn't 100% equivalent to Unix system() call.
> For
> > instance, if you spawned a process like 'vim' or a language shell like
> > 'scala' or 'irb', then you wouldn't be able to interact with the
> > sub-process
> > correctly due to incomplete redirection of all terminal capabilities.
> >
> > To solve this, we override the system() call to circumvent the JRuby's
> > system call and directly call the native system() using FFI.
> >
> > I don't know what's the state of things on JRuby 1.4.0 + Windows but some
> > internals seem to have changed which is why we're getting the error
> > described in BUILDR-348. Somebody needs to investigate what
> works/doesn't
> > work on Windows -- the workaround I provided on BUILDR-348 simply reverts
> > to
> > using the standard system() implementation, which works for most things
> but
> > not shelling out to interactive apps.
> >
> > alex
> >
>
Re: Next release
Posted by Antoine Toulme <an...@lunar-ocean.com>.
I can contact the jruby folks and see if a jruby update would help - JFFI is
now 1.0 btw, while it was 0.4 in 1.4.0.
On Mon, Mar 1, 2010 at 08:12, Alex Boisvert <al...@gmail.com> wrote:
> On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt <
> pepijn.vaneeckhoudt@luciad.com> wrote:
>
> > It would be nice if BUILDR-348 could be resolved for 1.4.0. We are
> planning
> > on using buildr as internally running on jruby 1.4. Right now this issue
> > means I will either have to maintain a custom buildr build or have every
> > developer patch the buildr installation by hand.
> >
> > Any idea on the root cause of this problem? Does commenting out that one
> > line have any other side effects?
> >
>
> The issue is that JRuby use{s,d} the JVM's System.exec() call to spawn
> external processes, which isn't 100% equivalent to Unix system() call. For
> instance, if you spawned a process like 'vim' or a language shell like
> 'scala' or 'irb', then you wouldn't be able to interact with the
> sub-process
> correctly due to incomplete redirection of all terminal capabilities.
>
> To solve this, we override the system() call to circumvent the JRuby's
> system call and directly call the native system() using FFI.
>
> I don't know what's the state of things on JRuby 1.4.0 + Windows but some
> internals seem to have changed which is why we're getting the error
> described in BUILDR-348. Somebody needs to investigate what works/doesn't
> work on Windows -- the workaround I provided on BUILDR-348 simply reverts
> to
> using the standard system() implementation, which works for most things but
> not shelling out to interactive apps.
>
> alex
>
Re: Next release
Posted by Alex Boisvert <al...@gmail.com>.
On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt <
pepijn.vaneeckhoudt@luciad.com> wrote:
> It would be nice if BUILDR-348 could be resolved for 1.4.0. We are planning
> on using buildr as internally running on jruby 1.4. Right now this issue
> means I will either have to maintain a custom buildr build or have every
> developer patch the buildr installation by hand.
>
> Any idea on the root cause of this problem? Does commenting out that one
> line have any other side effects?
>
The issue is that JRuby use{s,d} the JVM's System.exec() call to spawn
external processes, which isn't 100% equivalent to Unix system() call. For
instance, if you spawned a process like 'vim' or a language shell like
'scala' or 'irb', then you wouldn't be able to interact with the sub-process
correctly due to incomplete redirection of all terminal capabilities.
To solve this, we override the system() call to circumvent the JRuby's
system call and directly call the native system() using FFI.
I don't know what's the state of things on JRuby 1.4.0 + Windows but some
internals seem to have changed which is why we're getting the error
described in BUILDR-348. Somebody needs to investigate what works/doesn't
work on Windows -- the workaround I provided on BUILDR-348 simply reverts to
using the standard system() implementation, which works for most things but
not shelling out to interactive apps.
alex