Thanks, this has been helpful.  What would be a good class to look at for
how FFI works in JRuby?  Also, does it matter that none of the win32 stuff
should work on a non-windows platform?  Does that impact the decision to use
FFI or not?  It seems like with MRI you can't even require it, so it must
not be distributed with MRI on non-windows platforms.

Joe

On Wed, Mar 3, 2010 at 12:30 PM, Thomas E Enebo <tom.en...@gmail.com> wrote:

> Joseph,  the Jira issue is pretty old and it actually predates ffi as
> a technology.  If you don't start helping Brian in his impl, then
> consider trying to do it all via ffi.
>
> perhaps moot now...
>
> In answer to your original question,  ThreadContext should be put as
> the first parameter to any JRubyMethod annotated method.  It saves
> having to retrieve it and as a result it is cheaper to provide it.  We
> did not originally support this, so some older annotations do not have
> a threadcontext parameter on them.
>
> -Tom
>
> On Wed, Mar 3, 2010 at 9:47 AM, Joseph Athman <jjath...@gmail.com> wrote:
> > I really didn't have a major reason for trying to implement this, I just
> > figured it is something JRuby should have since MRI has it.  I'm also
> forced
> > to use windows on a regular basis so I have access to a machine to do the
> > developing on.
> >
> > In this JIRA ticket (http://jira.codehaus.org/browse/JRUBY-191) it talks
> > about using the Jacob library to implement this.  I don't know enough
> about
> > FFI to say whether that would work or not.  If using FFI would be better
> I
> > would be more than happy to try and learn how to use it.  It seems like
> the
> > lack of WIN32OLE support has not really held anyone back so I figure it
> > would be a good place to learn since it obviously isn't a high priority.
> >
> > Joe
> >
> > On Wed, Mar 3, 2010 at 9:39 AM, Vladimir Sizikov <vsizi...@gmail.com>
> wrote:
> >>
> >> Hi Joseph,
> >>
> >> I might be *totally* off the base, so don't pay too much attention to
> >> what I'm going to say ;)
> >>
> >> Now that JRuby has great FFI support, my understanding is that one
> >> might implement WIN32OLE purely in ruby.
> >> Like, for example, we implement Win32API.rb (lib\ruby\1.8\Win32API.rb).
> >>
> >> Is there particular reason you're going to implement WIN32OLE in Java?
> >>
> >> Thanks,
> >>  --Vladimir
> >>
> >> On Wed, Mar 3, 2010 at 4:34 PM, Joseph Athman <jjath...@gmail.com>
> wrote:
> >> > I've always wanted to contribute something to JRuby so I was looking
> >> > through
> >> > JIRA and noticed that JRuby still does not have the WIN32OLE api, I
> >> > thought
> >> > maybe that is something I could try and implement.  I quickly
> discovered
> >> > that I'm not totally sure how to go about this though.  I was trying
> to
> >> > look
> >> > at some of the other ruby standard lib classes that have been created,
> >> > but
> >> > I'm hoping I could get a little help here.  My two main questions are
> >> > about
> >> > the @JRubyMethod annotation and the actual method parameters.  It
> seems
> >> > like
> >> > some methods take a ThreadContext object while some don't.  Take for
> >> > example
> >> > this method from the WIN32OLE class:
> >> >
> >> > WIN32OLE.connect('Excel.Application') # => WIN32OLE object which
> >> > represents
> >> > running Excel.
> >> >
> >> > What would the method signature for that look like?  I'm guessing this
> >> > would
> >> > be a static Java method, but I'm not sure.  Would there just be one
> >> > parameter in the Java code?  Would it be an IRubyObject or would be be
> a
> >> > RubyString?  I looked on the JRuby wiki but I didn't really see
> anything
> >> > about this.  If there is more information out there you can just point
> >> > me in
> >> > that direction.  Thanks for any help.
> >> >
> >> > Joe
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this list, please visit:
> >>
> >>    http://xircles.codehaus.org/manage_email
> >>
> >>
> >
> >
>
>
>
> --
> blog: http://blog.enebo.com       twitter: tom_enebo
> mail: tom.en...@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

Reply via email to