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/.
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
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
Presumably that workflow would work. An alternative is to write a thin Ruby or C# wrapper that wraps the native HTTP parser using either FFI (http://www.igvita.com/2009/01/15/bridging-mri-jruby-rubinius-with-ffi/ or http://www.javaworld.com/community/?q=node/1722), or pinvokes. IronRuby supports neither FFI nor Ruby/dl. So you would have to use pinvokes from C# for now. FWIW, another alternative is implementing something like IronClad (http://code.google.com/p/ironclad/) which would allow native extensions to work as is, but this is a large feature. -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Nathan Stults Sent: Tuesday, October 06, 2009 6:10 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Native Extensions 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
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 supports neither FFI nor Ruby/dl. So you would have to use pinvokes from C# for now.just wondering: is there a remotely vague intention of having FFI support at some point for IronRuby ? just curious if someone actually thought about implementing this, -- Thibaut
Great, I''ll study your code to give me a head start. If I run into trouble I''ll be sure to bug you :) I had never heard of Ragel until I started looking into Ruby the last couple of weeks - is it just a parser generator like any other? -----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 thatfile> 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. Win32OLEsupport> 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 onnative> 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 smallpart> 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 youto> run Mongrel on .NET. > > IMO, after 1.0 would be the time to consider supporting the nativeRuby> 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 iton> 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 loveto> use IronRuby to embed Thin or Mongrel in my .NET services, but fromfrom> my few experiments it looks like most of the networking librariesthese> 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
It''s is a large workitem, so it would be post 1.0. Tomas thinks some of the code can be reused from the IronPython equivalent (the ctypes library), but it would still be a fair amount of work. I think Win32API is a weak equivalent, and someone could start playing with it for accessing native extension. There would be work on the native extensions to expose the functionality as dllexports, and this can be pushed on right now without waiting for IronRuby to support FFI... -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re Sent: Wednesday, October 07, 2009 5:16 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Native Extensions> IronRuby supports neither FFI nor Ruby/dl. So you would have to use pinvokes from C# for now.just wondering: is there a remotely vague intention of having FFI support at some point for IronRuby ? just curious if someone actually thought about implementing this, -- Thibaut _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
On the other hand, using a native extension is worse than using a pure C#/Ruby equivalent. Native interop doesn''t work in partial trust (Silverlight, web servers, etc) and supporting more platforms (Windows, Linux, MacOS, etc) would need more work. So if there is some useful Ruby native extension with stable API it makes sense to implement it in Ruby with .NET interop or directly in C#. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde Sent: Wednesday, October 07, 2009 11:11 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Native Extensions It''s is a large workitem, so it would be post 1.0. Tomas thinks some of the code can be reused from the IronPython equivalent (the ctypes library), but it would still be a fair amount of work. I think Win32API is a weak equivalent, and someone could start playing with it for accessing native extension. There would be work on the native extensions to expose the functionality as dllexports, and this can be pushed on right now without waiting for IronRuby to support FFI... -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re Sent: Wednesday, October 07, 2009 5:16 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Native Extensions> IronRuby supports neither FFI nor Ruby/dl. So you would have to use pinvokes from C# for now.just wondering: is there a remotely vague intention of having FFI support at some point for IronRuby ? just curious if someone actually thought about implementing this, -- Thibaut _______________________________________________ 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
+1 for CLR/C# extensions --- Met vriendelijke groeten - Best regards - Salutations Ivan Porto Carrero Blog: http://flanders.co.nz Twitter: http://twitter.com/casualjim Author of IronRuby in Action (http://manning.com/carrero) On Wed, Oct 7, 2009 at 8:36 PM, Tomas Matousek <Tomas.Matousek at microsoft.com> wrote:> On the other hand, using a native extension is worse than using a pure > C#/Ruby equivalent. Native interop doesn''t work in partial trust > (Silverlight, web servers, etc) and supporting more platforms (Windows, > Linux, MacOS, etc) would need more work. So if there is some useful Ruby > native extension with stable API it makes sense to implement it in Ruby with > .NET interop or directly in C#. > > Tomas > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde > Sent: Wednesday, October 07, 2009 11:11 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Native Extensions > > It''s is a large workitem, so it would be post 1.0. Tomas thinks some of the > code can be reused from the IronPython equivalent (the ctypes library), but > it would still be a fair amount of work. > > I think Win32API is a weak equivalent, and someone could start playing with > it for accessing native extension. There would be work on the native > extensions to expose the functionality as dllexports, and this can be pushed > on right now without waiting for IronRuby to support FFI... > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re > Sent: Wednesday, October 07, 2009 5:16 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Native Extensions > > > IronRuby supports neither FFI nor Ruby/dl. So you would have to use > pinvokes from C# for now. > > just wondering: is there a remotely vague intention of having FFI support > at some point for IronRuby ? > > just curious if someone actually thought about implementing this, > > -- Thibaut > _______________________________________________ > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20091007/759eeddd/attachment.html>
Yup, we will need a mix of both approaches. Reimplementing in C# gives more flexibility in being able to run on any CLR, but is also expensive. Being able to use FFI can give access to more extensions quickly and cheaply, but will not have the same reach as a managed reimplementation. -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Tomas Matousek Sent: Wednesday, October 07, 2009 11:37 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Native Extensions On the other hand, using a native extension is worse than using a pure C#/Ruby equivalent. Native interop doesn''t work in partial trust (Silverlight, web servers, etc) and supporting more platforms (Windows, Linux, MacOS, etc) would need more work. So if there is some useful Ruby native extension with stable API it makes sense to implement it in Ruby with .NET interop or directly in C#. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Shri Borde Sent: Wednesday, October 07, 2009 11:11 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Native Extensions It''s is a large workitem, so it would be post 1.0. Tomas thinks some of the code can be reused from the IronPython equivalent (the ctypes library), but it would still be a fair amount of work. I think Win32API is a weak equivalent, and someone could start playing with it for accessing native extension. There would be work on the native extensions to expose the functionality as dllexports, and this can be pushed on right now without waiting for IronRuby to support FFI... -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Thibaut Barr?re Sent: Wednesday, October 07, 2009 5:16 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Native Extensions> IronRuby supports neither FFI nor Ruby/dl. So you would have to use pinvokes from C# for now.just wondering: is there a remotely vague intention of having FFI support at some point for IronRuby ? just curious if someone actually thought about implementing this, -- Thibaut _______________________________________________ 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
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/92932a672921a03210c8aefe23ac 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 thatfile> 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. Win32OLEsupport> 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 onnative> 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 smallpart> 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 youto> run Mongrel on .NET. > > IMO, after 1.0 would be the time to consider supporting the nativeRuby> 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 iton> 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 loveto> use IronRuby to embed Thin or Mongrel in my .NET services, but fromfrom> my few experiments it looks like most of the networking librariesthese> 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
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
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 myDLR/IronRuby> knowledge just isn''t up to the challenge. Maybe someday. As analternative,> I''m going to see if the IronRuby.Rack stuff on Git can teach me what Ineed 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 samebenefit,> 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 Ragelgenerate> the rest > 2- wrap everything up in a layer to expose the needed methods toIronRuby> 3- make sure to require your newly built http11.dll in the ruby partof 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, asmost> > Ruby libraries which use native code; there is usually a very small > part > > of the library which depends on native code. For Mongrel, the HTTP1.1> > parser is the only native piece; rewriting that in C# would allowyou> 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, isit> 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''dlove> 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
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 myDLR/IronRuby> knowledge just isn''t up to the challenge. Maybe someday. As analternative,> I''m going to see if the IronRuby.Rack stuff on Git can teach me what Ineed 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 samebenefit,> 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 Ragelgenerate> the rest > 2- wrap everything up in a layer to expose the needed methods toIronRuby> 3- make sure to require your newly built http11.dll in the ruby partof 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, asmost> > Ruby libraries which use native code; there is usually a very small > part > > of the library which depends on native code. For Mongrel, the HTTP1.1> > parser is the only native piece; rewriting that in C# would allowyou> 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, isit> 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''dlove> 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
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 myDLR/IronRuby> knowledge just isn''t up to the challenge. Maybe someday. As analternative,> I''m going to see if the IronRuby.Rack stuff on Git can teach me what Ineed 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 samebenefit,> 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 Ragelgenerate> the rest > 2- wrap everything up in a layer to expose the needed methods toIronRuby> 3- make sure to require your newly built http11.dll in the ruby partof 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, asmost> > Ruby libraries which use native code; there is usually a very small > part > > of the library which depends on native code. For Mongrel, the HTTP1.1> > parser is the only native piece; rewriting that in C# would allowyou> 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, isit> 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''dlove> 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
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 >
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
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
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
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
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