The main downside of Jacob for me was that it seemed to run incredibly slowly in comparison to MRI (from what I remember at least an order of magnitude slower). I did implement a simple win32ole shim using JI layer (which obviously slows it down more), but it seemed like the library must be doing something that MRI's extension isn't on every call. Still I suppose something which works is better than nothing at all. Who knows, Jacob may have fixed the speed issue since then....OR....I was using Jacob wrong?
[Aside: I needed access to GDI and User libraries and ended up just binding to them directly using FFI and it worked like a charm] I still like the idea of an FFI version. It might need to screw with 32 + 64 bit bindings for some APIs (maybe?), but it in theory, it could become the implementation for MRI and JRuby (assuming it worked well and MRI decided not to maintain their 3000 lines of C code -- which is true for 1.9 already right?). Since windows is supposed to be binary compatible across versions I think that FFI is in a sweet spot there, so I don't expect many/any struct binding layout issues. Having just said all of this, I have no plans to work on win32ole right now. I am just explaining why I have an opinion on the subject :) -Tom On Wed, Mar 3, 2010 at 6:20 PM, Charles Oliver Nutter <head...@headius.com> wrote: > FWIW, I don't have a strong preference for either FFI or Jacob-based, > though the Jacob-based approach pushes a lot of the native binding > stuff into someone else's court (i.e. if we just use Jacob, we don't > have to monkey with the FFI binding hassles and may be 90% done > already). > > I do have a strong preference to not duplicate work :) If Brian's got > a good solid start using something like Jacob, it would probably be > the best use of time to help him finish it. I could certainly be > convinced otherwise, but depending on someone else's known-working COM > bridge seems like a good thing to do... > > - Charlie > > On Wed, Mar 3, 2010 at 10:23 AM, Brian <brian.p.mcdev...@gmail.com> wrote: >> Hi Joseph, >> Take a look at the win32ole project I started on github.com/bpmcd/win32ole >> This is a similar effort to your proposition. >> >> On 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 >>> >>> >> >> > > --------------------------------------------------------------------- > 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
