[Ironruby-core] Native Extensions

Jimmy Schementi Jimmy.Schementi at microsoft.com
Thu Oct 15 22:01:10 EDT 2009


Hosting the Ruby standard library on some CDN is definitely a possibility, especially since we'll want to use it that way in Silverlight.

> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> bounces at rubyforge.org] On Behalf Of Nathan Stults
> Sent: Tuesday, October 13, 2009 11:20 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Native Extensions
>
> Maybe Microsoft could host the IronRuby standard library on its new CDN
> (http://weblogs.asp.net/scottgu/archive/2009/09/15/announcing-the-
> micros
> oft-ajax-cdn.aspx) for all to enjoy :) Most of the individual library files seem
> small enough, and if it works for .JS files, it should work for Ruby, no?
> Especially if some local caching were baked in.
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Nathan Stults
> Sent: Tuesday, October 13, 2009 11:15 AM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Native Extensions
>
> I have uploaded the first draft of my work here:
> http://github.com/PlasticLizard/Bracket if anyone is interested. I generalized
> the Rack hosting code from the IronRuby.Rack solution to be easily adaptable
> to other web servers. Included in this first iteration are hosts for
> HttpListener, C# Web Server, Kayak, and the IIS handlers from the original
> project are included for completeness. Unfortunately embedding a Rack
> application in a C# server still requires that the IronRuby libraries are installed
> on the target machine or included with the applications deployment. I'm
> thinking of ways to make that somewhat easier to deal with, possibly
> embedding the standard library in a .dll via resources or doing just in time
> downloads of required files from the web.
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy
> Schementi
> Sent: Thursday, October 08, 2009 12:23 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Native Extensions
>
> There is no problem with you taking any part of anything in the IronRuby
> repo and including it in another library; here are all the licenses IronRuby's
> releases contain:
> http://github.com/ironruby/ironruby/tree/master/Merlin/Main/Languages/
> Ru
> by/Licenses. CJ recently did a good job of mapping each directory in the
> entire IronRuby tree to a license, so I'll let him chime in about where that
> data is.
>
> So, feel free to do you work separately for now. I'd be interested in taking
> back any fixes you have for the rack-specific pieces, so I'll figure out how to
> make that happen on my side when the time comes.
>
> Let me know how things go, and don't hesitate to ask any more questions,
> ~Jimmy ________________________________________
> From: ironruby-core-bounces at rubyforge.org
> [ironruby-core-bounces at rubyforge.org] on behalf of Nathan Stults
> [Nathan_Stults at HSIHealth.com]
> Sent: Thursday, October 08, 2009 12:10 PM
> To: ironruby-core at rubyforge.org
> Subject: Re: [Ironruby-core] Native Extensions
>
> Thank you - I'm new to GitHub, so I didn't notice that branch - I'll get that one
> as a guide instead. On a related note, is there an accepted / preferred /
> traditional path I should follow in regards to re-mixing your code? I presume
> your rack integration stuff is licensed the same as IronRuby? In any case, is
> there any problem with me blending your work into a separate library
> intended to act as a generic adapter between Rack and an embedded .NET
> server and publishing as a separate library (following attribution, licensing
> rules, etc)? That is what I would normally do, but all this forking madness has
> made me second guess. BTW, thanks for your time in answering my endless
> questions. You guys have done an amazing job on all this stuff, very exciting
> possibilities.
>
> -----Original Message-----
> From: ironruby-core-bounces at rubyforge.org
> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy
> Schementi
> Sent: Thursday, October 08, 2009 11:52 AM
> To: <ironruby-core at rubyforge.org>
> Subject: Re: [Ironruby-core] Native Extensions
>
> They are an implementation detail; used to manipulate the request and
> response from ruby (see later on down in the massive handle method).
> In my forks "rackupdate" branch I don't think they exist anymore, as I'm
> refactoring that code a bit.
>
> ~Jimmy
> Sent from my phone
>
> On Oct 8, 2009, at 11:12 AM, "Nathan Stults"
> <Nathan_Stults at HSIHealth.com
>  > wrote:
>
> > Good news, thanks. In the Handle method of the IIS.cs, you are setting
> > two scope variables, __request and __response - are these variables
> > known to Rack, or are those set for the convenience of a IronRuby
> > adapter aware programmer to use from ruby if desired?
> >
> > Thanks,
> >
> > Nathan
> >
> > -----Original Message-----
> > From: ironruby-core-bounces at rubyforge.org
> > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy
> > Schementi
> > Sent: Thursday, October 08, 2009 12:54 AM
> > To: ironruby-core at rubyforge.org
> > Subject: Re: [Ironruby-core] Native Extensions
> >
> > That lock is there because Rails wasn't thread-safe at the time of
> > writing; it has no reflection on whether ScriptEngine is thread- safe.
> > I believe ScriptEngine is thread-safe, as only one ScriptEngine per
> > language can EVER exist when you have only one ScriptRuntime.
> >
> > Rails is much more thread-safe than it used to be, so that lock should
> > be removed; IMO it should have never been there as the Rack adapter
> > shouldn't care about Rails; it should lock if the rack.multithreaded
> > flag is true.
> >
> > ~js
> > ________________________________________
> > From: ironruby-core-bounces at rubyforge.org
> > [ironruby-core-bounces at rubyforge.org] on behalf of Nathan Stults
> > [Nathan_Stults at HSIHealth.com]
> > Sent: Thursday, October 08, 2009 12:26 AM
> > To: ironruby-core at rubyforge.org
> > Subject: Re: [Ironruby-core] Native Extensions
> >
> > Ahh nice clean, brief code. Now this I can handle. I do have a
> > question though about threading - it looks like in your implementation
> > the whole apparatus is essentially single threaded, i.e. there is a
> > single handler maintained by the factory, and the single handler locks
> > itself for the duration of the request - this suggests to me that
> > ScriptEngine (or at least RubyEngine) is not thread-safe? Is that the
> > case, or was the threading designed for simplicity? For instance, if
> > in my implementation I took a lock on the RubyEngine just long enough
> > to obtain a new scope to handle the request, would that do? Or does it
> > pretty much need to be
> > 1 thread = 1 script engine? If the latter is the case, would there be
> > any caveats to maintaining a small pool of engines that could handle a
> > few simultaneous requests? To be honest, this almost certainly won't
> > make a bit of difference to my use case of embedding a web server in
> > an application server, traffic just won't be that high, but mostly I'm
> > just curious about the platform.
> >
> > Thanks,
> >
> > Nathan
> >
> > -----Original Message-----
> > From: ironruby-core-bounces at rubyforge.org
> > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy
> > Schementi
> > Sent: Wednesday, October 07, 2009 5:12 PM
> > To: ironruby-core at rubyforge.org
> > Subject: Re: [Ironruby-core] Native Extensions
> >
> > The HttpHandler is the only piece you'll have to replace, since it's
> > specifically for IIS, and provide your own hookup to the server you
> > choose. You'll have to construct the HttpRequest/Response objects
> > also, but all-in-all it should be pretty straight-forward. Those two
> > look like great .NET web-server projects; "webserver" is like a
> > web-framework too, which is cool. Whatever you do, DON'T use Chiron,
> > as it's not intended to be a real web-server (it doesn't support POST
> > requests, and only listens on localhost).
> >
> > ~js
> >
> >> -----Original Message-----
> >> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-
> >> bounces at rubyforge.org] On Behalf Of Nathan Stults
> >> Sent: Wednesday, October 07, 2009 4:54 PM
> >> To: ironruby-core at rubyforge.org
> >> Subject: Re: [Ironruby-core] Native Extensions
> >>
> >> I spent a day chasing my tail and, upon catching it, realized my
> > DLR/IronRuby
> >> knowledge just isn't up to the challenge. Maybe someday. As an
> > alternative,
> >> I'm going to see if the IronRuby.Rack stuff on Git can teach me what
> >> I
> > need to
> >> wire Rack up to one of these embeddable .NET HTTP servers:
> >> http://www.codeplex.com/webserver,
> >> http://runkayak.com/getstarted, which ought to provide the same
> > benefit,
> >> and possibly perform a little better as well. Is anyone aware of
> >> other embeddable .NET HTTP server projects?
> >>
> >> (http://github.com/jschementi/ironruby/tree/
> >> 92932a672921a03210c8aefe23
> >> ac
> >> 0a7d6996ed2d/Merlin/Main/Hosts/IronRuby.Rack)
> >>
> >>
> >> -----Original Message-----
> >> From: ironruby-core-bounces at rubyforge.org
> >> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Daniele
> >> Alessandri
> >> Sent: Tuesday, October 06, 2009 11:39 PM
> >> To: ironruby-core at rubyforge.org
> >> Subject: Re: [Ironruby-core] Native Extensions
> >>
> >> Hi Nathan,
> >> yes, that's basically what you need to do:
> >>
> >> 1- rewrite the C (or Java) bits of the http parser in C# and let
> >> Ragel
> > generate
> >> the rest
> >> 2- wrap everything up in a layer to expose the needed methods to
> > IronRuby
> >> 3- make sure to require your newly built http11.dll in the ruby part
> > of the
> >> mongrel library
> >> 4- have fun.
> >>
> >> I did the same for hpricot and json (whose parsers are generated
> >> using Ragel), so I guess that should work for Mongrel too :-)
> >>
> >>
> >> On Wed, Oct 7, 2009 at 03:09, Nathan Stults
> > <Nathan_Stults at hsihealth.com>
> >> wrote:
> >>> Thanks for the tip. It looks like the Http Parser is generated via
> >>> Ragel, and it appears there is a Java version of the language file,
> > so
> >>> theoretically all I should have to do is learn Ragel and port that
> >> file
> >>> to C#, piece of cake :) Then I suppose I'd need a patched version of
> >>> mongrel that required the new .NET HTTP parser dll instead of the C
> >>> version? Is that how that would work?
> >>>
> >>> -----Original Message-----
> >>> From: ironruby-core-bounces at rubyforge.org
> >>> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jimmy
> >>> Schementi
> >>> Sent: Tuesday, October 06, 2009 6:00 PM
> >>> To: ironruby-core at rubyforge.org
> >>> Subject: Re: [Ironruby-core] Native Extensions
> >>>
> >>> Native extension support is not on the roadmap for 1.0. Win32OLE
> >> support
> >>> is actually in there now, because of the Dynamic Language Runtime's
> >>> support for dispatching to COM objects. So IronRuby's version of
> >>> win32ole.rb uses IronRuby's OLE support, rather than depending on
> >> native
> >>> code.
> >>>
> >>> The current work-around for libraries which use native code to
> >>> communicate with the OS or Ruby is to rewrite those using .NET so
> >>> IronRuby can use them. Mongrel is actually \mostly Ruby code, as
> > most
> >>> Ruby libraries which use native code; there is usually a very small
> >> part
> >>> of the library which depends on native code. For Mongrel, the HTTP
> > 1.1
> >>> parser is the only native piece; rewriting that in C# would allow
> > you
> >> to
> >>> run Mongrel on .NET.
> >>>
> >>> IMO, after 1.0 would be the time to consider supporting the native
> >> Ruby
> >>> API.
> >>>
> >>> ~Jimmy
> >>> ________________________________________
> >>> From: ironruby-core-bounces at rubyforge.org
> >>> [ironruby-core-bounces at rubyforge.org] on behalf of Nathan Stults
> >>> [lists at ruby-forum.com]
> >>> Sent: Tuesday, October 06, 2009 4:18 PM
> >>> To: ironruby-core at rubyforge.org
> >>> Subject: [Ironruby-core] Native Extensions
> >>>
> >>> I noticed on the road-map this item under .NET Interop:
> >>>
> >>> [P3] COM: for Win32OLE compatibility
> >>>
> >>> Is that the same thing as supporting native extensions? If not, is
> > it
> >> on
> >>> the roadmap to support such a thing? Also, is there a workaround,
> > like
> >>> replacing files in the gem installation with a .NET wrapper? I'd
> > love
> >> to
> >>> use IronRuby to embed Thin or Mongrel in my .NET services, but from
> >> from
> >>> my few experiments it looks like most of the networking libraries
> >> these
> >>> servers use tend to rely on native dll's.
> >>> --
> >>> Posted via http://www.ruby-forum.com/.
> >>> _______________________________________________
> >>> Ironruby-core mailing list
> >>> Ironruby-core at rubyforge.org
> >>> http://rubyforge.org/mailman/listinfo/ironruby-core
> >>>
> >>> _______________________________________________
> >>> Ironruby-core mailing list
> >>> Ironruby-core at rubyforge.org
> >>> http://rubyforge.org/mailman/listinfo/ironruby-core
> >>> _______________________________________________
> >>> Ironruby-core mailing list
> >>> Ironruby-core at rubyforge.org
> >>> http://rubyforge.org/mailman/listinfo/ironruby-core
> >>>
> >>
> >>
> >>
> >> --
> >> Daniele Alessandri
> >> http://www.clorophilla.net/blog/
> >> http://twitter.com/JoL1hAHN
> >> _______________________________________________
> >> Ironruby-core mailing list
> >> Ironruby-core at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/ironruby-core
> >> _______________________________________________
> >> Ironruby-core mailing list
> >> Ironruby-core at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
> >
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core



More information about the Ironruby-core mailing list