[Ironruby-core] Native Extensions

Jimmy Schementi Jimmy.Schementi at microsoft.com
Thu Oct 8 15:22:55 EDT 2009


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/Ruby/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



More information about the Ironruby-core mailing list