Very cool. I'll let headius know we are past that hurdle. Thanks everybody!
On Mon, Mar 1, 2010 at 09:23, Daniel Spiewak <[email protected]> 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 < > [email protected]> 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< > >> [email protected]> 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< > >>>>> [email protected]> 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< > >>>>>>> [email protected] > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> 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< > [email protected] > >>>>>>>> > > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Mon, Mar 1, 2010 at 3:00 AM, Pepijn Van Eeckhoudt< > >>>>>>>> > >>>>>>>> > >>>>>>>>> [email protected]> 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 | [email protected] > >>>>>> > >>>>>> 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 | [email protected] > >>> > >>> 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 | [email protected] > > > > LUCIAD - high performance visualization > > Wetenschapspark Arenberg | Gaston Geenslaan 9 > > 3001 Leuven | Belgium | www.luciad.com > > > > > > >
