Hi,
Just curious to know more about IronRuby and IronPython.
Since both are based on DLR…here are my short questions.
(1) Is the progress same with both the languages.
(2) Will version 1.0 for both will be in the same time frame…
(3) If Rails is the target for declaring IronRuby as 1.0 then…
will django will be the target for declaring IronPython as 1.0
(4) How are the code contributions flowing to IronRuby from other 3rd
party developers when compared to IronRuby…
Thanks
well ironpython 1.0 has already been out for some time. its version 2 (i
think) that they are putting on the DLR, so you could say safely, i
think, that ironpython is more mature. (but of course ruby is cooler)
and further along in full language compatibility. This is just my
perception though. Hopefully somebody who really knows will answer 
IronPython is much further along. All of the details about IronPython
are
readily available online, including how far it is along in cPython’s
compatibility. I would say no languages will progress at the same time
no
matter if they are on the CLR or DLR, language teams are seperate from
platform teams within MS. The polocies for code contributions for both
languages are also very public for you to review yourself.
Below is a table summarizing the extension libraries that are needed by
a number of simple Rails use cases. These libraries are implemented in
Matz’s Ruby Interpreter in C code rather than in Ruby code, so we’ll
need to port or at least wrap them in some way.
Use Case
Win32API
Syck
(YAML)
thread
socket
stringio
zlib
digest
strscan
openssl
sqlite3_api
Setup gems
þ
þ
þ
Gem install rails
þ
þ
þ
þ
þ
þ
Rails create app
þ
þ
þ
þ
þ
Start WEBrick
þ
þ
þ
þ
þ
WEBrick process static html page
þ
þ
þ
þ
þ
WEBrick process dynamic controller page
þ
þ
þ
þ
þ
þ
þ
þ
þ
IIS CGI dispatch
þ
þ
þ
þ
þ
þ
I’d like to start working on some of these libraries, but first want to
check who is already working on what. I understand that John M. is
working on a YAML port and according to the WIKI, Eduardo Flores is
working on stringio and Curt H. is working on strscan. Is this
list correct and complete. Is anyone else already working on any of
these libraries?
To support these simple use cases, typically only a small number of
functions from these libraries is actually needed. If you are going to
work on any of these libraries, I can provide you with a list of the
actual functions and with the exact signature/overrides that are
actually used by these use cases. Obviously, other functions will also
be needed long term, but by implementing these functions first we can
get basic Rails functionality happening sooner.
Note, there are many different web server options that we could persue.
We could for example not worry about WEBrick and go straight to IIS as a
host and so avoid implementing the socket library. Ultimately, I think
we want to be web server agnostic, That is, we should aim to provide a
drop in replacement for “rubyw.exe” that works regardless of which web
server (IIS, Apache, WEBrick, Mongrel, etc) that administrators choose
to adopt. That said, Windows is currently considered a second class
platform for deploying Rails and the setup can be quite complex and
buggy in some configurations. In the longer term we should aim to
improve this situation. For production Rails we’ll want to support IIS
7.0 well on server machines, but for those that just want to try it out,
I believe we should also make sure it can be made to work on desktop
machines such as mine with IIS 5 and XP.
Your thoughts?
Cheers, Wayne.
Hi Wayne,
This is great! More below…
On Sun, 17 Feb 2008 17:29:41 -0700, Wayne K. [email protected]
wrote:
Note, there are many different web server options that we could persue.
We could for example not worry about WEBrick and go straight to IIS as a
host and so avoid implementing the socket library. Ultimately, I think
we want to be web server agnostic, That is, we should aim to provide a
drop in replacement for “rubyw.exe” that works regardless of which web
server (IIS, Apache, WEBrick, Mongrel, etc) that administrators choose
to adopt.
+1. I would suggest we adopt using either XSP or Cassini, both of which
are small and capable. XSP is specifically an HTTP 1.0 server. Not
sure
if Cassini covers 1.1 or not. Anyone know?
That said, Windows is currently considered a second class platform for
deploying Rails and the setup can be quite complex and buggy in some
configurations. In the longer term we should aim to improve this
situation.
Using either XSP or Cassini will help in that if we can get it to run
via
either, then getting it to run via IIS and/or through mod_mono/fastcgi
should be quite a bit easier.
For production Rails we’ll want to support IIS 7.0 well on server
machines, but for those that just want to try it out, I believe we
should also make sure it can be made to work on desktop machines such as
mine with IIS 5 and XP.Your thoughts?
We need to place focus on providing support via FastCGI such that
getting
it to work on lighty, Apache, etc. is simple and straight forward.
Using
Mono’s FastCGI support should make this drop dead simple.
–
/M:D
M. David P.
http://mdavid.name | M. David Peterson |
http://dev.aol.com/blog/3155
Below is a table summarizing the extension libraries that are needed by
a number of simple Rails use cases. These libraries are implemented in
Matz’s Ruby Interpreter in C code rather than in Ruby code, so we’ll
need to port or at least wrap them in some way.
Use Case
Win32API
Syck
(YAML)
thread
socket
stringio
zlib
digest
strscan
openssl
sqlite3_api
Setup gems
þ
þ
þ
Gem install rails
þ
þ
þ
þ
þ
þ
Rails create app
þ
þ
þ
þ
þ
Start WEBrick
þ
þ
þ
þ
þ
WEBrick process static html page
þ
þ
þ
þ
þ
WEBrick process dynamic controller page
þ
þ
þ
þ
þ
þ
þ
þ
þ
IIS CGI dispatch
þ
þ
þ
þ
þ
þ
I’d like to start working on some of these libraries, but first want to
check who is already working on what. I understand that John M. is
working on a YAML port and according to the WIKI, Eduardo Flores is
working on stringio and Curt H. is working on strscan. Is this
list correct and complete. Is anyone else already working on any of
these libraries?
To support these simple use cases, typically only a small number of
functions from these libraries is actually needed. If you are going to
work on any of these libraries, I can provide you with a list of the
actual functions and with the exact signature/overrides that are
actually used by these use cases.
Cheers, Wayne.
Very cool list! This should be put on the wiki at Rubyforge methinks…
There’s still a lot to be done in the ruby core too though… there
may be some dependency there for these things to work “right”.
I’d be interested in doing the zlib port if noone else has done
anything on it yet, I just recently had to dig into zlib a bit so it’s
kind of fresh. Feel free to send me what needs implemented.
On Feb 17, 2008 7:29 PM, Wayne K. [email protected] wrote:
socket
þ
þ
þþ
check who is already working on what. I understand that John M. is
functionality happening sooner.
Rails we’ll want to support IIS 7.0 well on server machines, but for those
–
Michael L.
[Polymath Programmer]
http://michaeldotnet.blogspot.com
I think a “sane subset” of supported web servers is the way to go. For
instance, no one uses webrick anymore (most popular is mongrel for
development and mongrel+apache/lighttpd for production), so supporting
webrick isn’t super-important. I completely agree w/the importance of
being web-server agnostic. Also, webrick is a pure ruby app, so by
definition we’ll want to make it work in the long run.
Btw, this is really cool Wayne =)
~js
From: [email protected]
[mailto:[email protected]] On Behalf Of Wayne K.
Sent: Sunday, February 17, 2008 4:30 PM
To: [email protected]
Subject: [Ironruby-core] Towards Rails on .NET
Below is a table summarizing the extension libraries that are needed by
a number of simple Rails use cases. These libraries are implemented in
Matz’s Ruby Interpreter in C code rather than in Ruby code, so we’ll
need to port or at least wrap them in some way.
Use Case
Win32API
Syck
(YAML)
thread
socket
stringio
zlib
digest
strscan
openssl
sqlite3_api
Setup gems
Gem install rails
Rails create app
Start WEBrick
WEBrick process static html page
WEBrick process dynamic controller page
IIS CGI dispatch
I’d like to start working on some of these libraries, but first want to
check who is already working on what. I understand that John M. is
working on a YAML port and according to the WIKI, Eduardo Flores is
working on stringio and Curt H. is working on strscan. Is this
list correct and complete. Is anyone else already working on any of
these libraries?
To support these simple use cases, typically only a small number of
functions from these libraries is actually needed. If you are going to
work on any of these libraries, I can provide you with a list of the
actual functions and with the exact signature/overrides that are
actually used by these use cases. Obviously, other functions will also
be needed long term, but by implementing these functions first we can
get basic Rails functionality happening sooner.
Note, there are many different web server options that we could persue.
We could for example not worry about WEBrick and go straight to IIS as a
host and so avoid implementing the socket library. Ultimately, I think
we want to be web server agnostic, That is, we should aim to provide a
drop in replacement for “rubyw.exe” that works regardless of which web
server (IIS, Apache, WEBrick, Mongrel, etc) that administrators choose
to adopt. That said, Windows is currently considered a second class
platform for deploying Rails and the setup can be quite complex and
buggy in some configurations. In the longer term we should aim to
improve this situation. For production Rails we’ll want to support IIS
7.0 well on server machines, but for those that just want to try it out,
I believe we should also make sure it can be made to work on desktop
machines such as mine with IIS 5 and XP.
Your thoughts?
Cheers, Wayne.
From: [email protected] [[email protected]] On Behalf Of
Michael L. [[email protected]]
Sent: Monday, 18 February 2008 11:52 PM
To: [email protected]
Subject: Re: [Ironruby-core] Towards Rails on .NETI’d be interested in doing the zlib port if noone else has done
anything on it yet, I just recently had to dig into zlib a bit so it’s
kind of fresh. Feel free to send me what needs implemented.
Sounds good to me, but before we go too far down this path, perhaps we
should discuss the ground
rules for implementing these extension libraries. CRuby implements many
of these libraries as CRuby
specific thin C wrappers around functionality provided by other native
open source libraries. To build
CRuby for Rails from source you need to go to various other open source
projects, download and
compile each of their bits and make sure their binaries are present on
the right path.
What approaches are deemed acceptable within the IronRuby project?
Firstly, is it OK to have dependences on other open source project or do
we need to implement all of these
components from scratch? Secondly, is it OK to have dependences on
native libraries rather than on fully managed
libraries? (note these are two separate issues). Having our own fully
managed implementations would have many
advantages, but would require more work and wouldn’t keep pace with
advances made in those other libraries.
Wrapping the same native libraries as C Ruby will also increase our
compatability. I’m not proposing policy here,
I’m just raising issues and asking for guidence.
The other issue is where to we put these libraries once we start
developing them? It would be nice to have them all
in the same place, even in their early stages of development. Each I
imagine would be a separate library, so they wouldn’t
interfere with one another. I assume they will not become part of the
IronRuby.Libraries project. Perhaps they could be put
into a separate RubyForge project initially that external contributors
could directly upload to, and then if necessary moved
into some kind of official tree as they mature?
Cheers, Wayne.
Zlib had been discussed last year (and also the issue with including
software with different licences). Below is one of the snippets (the
Silverlight issues has since been resolved) from one of the archived
threads.
should give you the other posts on that thread.
And according to
http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=2590,
System.IO.Compression is able to support the Python zlib module. So it
definitely sounds appealing, especially for Silverlight, where it would
avoid reduce the download size of IronRuby apps since it is already
included in Silverlight.
John L. said in
http://rubyforge.org/pipermail/ironruby-core/2007-September/000024.html
After looking a bit more closely at System.IO.Compression, I think it actually gives us most of what we need.
So in order of preference:
System.IO.Compression (we still have to solve the Silverlight problem since I just looked and saw that it doesn't ship in Silverlight).Component ACE zlib.net - I like the BSD style license - it will be easier to make a case for this.
Wayne K.:
What approaches are deemed acceptable within the IronRuby project?
Firstly, is it OK to have dependences on other open source project or
do we need to implement all of these
components from scratch?
I think it would be fine to have a dependency on a managed library (see
below).
Secondly, is it OK to have dependences on
native libraries rather than on fully managed
libraries? (note these are two separate issues).
I’d rather not have dependencies on native libraries. It makes it much
more difficult to ship a single binary across all of our platforms (Mac,
Windows, *nix).
The other issue is where to we put these libraries once we start
developing them? It would be nice to have them all
in the same place, even in their early stages of development. Each I
imagine would be a separate library, so they wouldn’t
interfere with one another. I assume they will not become part of the
IronRuby.Libraries project. Perhaps they could be put
into a separate RubyForge project initially that external contributors
could directly upload to, and then if necessary moved
into some kind of official tree as they mature?
There are a number of things that complicates things now. We don’t
have require ‘foo’ working for compiled Ruby library assemblies, so
everything has to be dumped into IronRuby.Libraries.dll for the time
being. Once we have that working it will make it easier to refactor
libraries into packages.
Thanks,
-John
Wayne K.:
I’d like to start working on some of these libraries, but first want
to check who is already working on what. I understand that John
Messerly is working on a YAML port and according to the WIKI, Eduardo
Flores is working on stringio and Curt H. is working on
strscan. Is this list correct and complete. Is anyone else already
working on any of these libraries?
I think it would be awesome if you could start investigating the openssl
and zlib support. Both of these are on the critical path to getting
Rails to work and don’t have other folks looking at them AFAIK.
I think it is important to look at integration with IIS 7 + fastcgi, and
then looking at back-porting to IIS 6 as a lower priority.
I’m still working on the status app. Wayne has already provided me with
the dynamic method traces of these scenarios. Wayne, if you want feel
free to make those files available to the group (I don’t think the list
will make it easy to do this, so uploading them to a server and
providing a link will likely be the best way to do this).
Thanks,
-John
Michael L.:
That leads to the question of… what can we, as outside contributors,
do /now/ to help. I feel like there’s alot of work going on, that we
just don’t know about… I’d hate to see duplicate efforts wasted.
Thanks for your enthusiasm, Michael!
Let me give an update on what my team here at Microsoft is doing: we’re
working towards MIX08.
Silverlight is its own branch, and we sync up to Silverlight
periodically for big events. So while we were working on the standard
libraries, we weren’t tracking Silverlight (well John M. is, but
that’s a whole other story … :))
Since MIX is right around the corner (March 5-7), we’re working on
getting demos working for MIX and generally looking at how Ruby and
dynamic languages in general fit with the Silverlight development story.
Keep in mind that Silverlight is initially about browser JavaScript
programming (V1) and now .NET based languages programming (V2). Our job
is to make sure that the APIs that they designed for V2 work well with
dynamic languages. And the best way to do that is by writing code
against their APIs.
So we haven’t been spending much time at all working on core libraries
and Ruby features - we’re mostly concerned with getting our demos / labs
working for MIX. This gives us a chance to exercise our .NET interop
story and look for holes in that story (and there are a bunch when it
comes to data binding scenarios). It lets us figure out how much work
there still is to do in our binder.
Once MIX is done, we’ll resume working on libraries and getting the last
few language features implemented.
The best way for you to lay claim (today) to some library is announce
your intentions on this list. There are folks who have claimed stuff on
the wiki, but who haven’t updated us on status. So let’s assume that for
now there aren’t any claims anywhere (with the exception of Wayne K.
looking at OpenSSL and zlib support).
My SL demo app for MIX is writing the web app that will let folks
‘reserve’ a library to work on based on scenarios. This will let us
focus our efforts on places that need it, as well as providing valuable
status reports without resorting to email. I’m still writing the app
since it involves using a bunch of technology that I don’t really use
all that often. So hang in there … it will be done soon!
Thanks,
-John
That leads to the question of… what can we, as outside contributors,
do /now/ to help. I feel like there’s alot of work going on, that we
just don’t know about… I’d hate to see duplicate efforts wasted.
On Feb 19, 2008 11:21 PM, John L. (DLR) [email protected] wrote:
–
Michael L.
[Polymath Programmer]
http://michaeldotnet.blogspot.com
Awesome information, thanks for bringing us all up a bit to speed!
I’m not just referring to libraries though, I’m talking about the core
functionality (this is, after all, Ironruby-core 
)
Some (all?) of the libraries will have dependencies on things that
must be implemented in the core IronRuby code, what still needs to be
done in the core code and what can we do to help there?
My assumption (and it may be wrong) is that once a majority of the
core functionality is in place, and stable, then the libraries will
come quicker.
In other words, the cake is still soft in the middle, we can’t start
putting icing on until it’s done baking. What can we do to help stoke
the oven?
Or is this an unrealistic view?
On Wed, Feb 20, 2008 at 11:14 AM, John L. (DLR) [email protected]
wrote:
[snip]
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
–
Michael L.
[Polymath Programmer]
http://michaeldotnet.blogspot.com
A while back I posted a list of external libraries that we needed to
implement in order to support gems and Rails. The following summarizes
the libraries that I’ve been working on. Could others who are also
working on these libraries please post a status update?
Win32API.so:
syck.so (YAML):
thread.so:
socket.so:
stringio.so:
zlib.so:
digest.so:
strscan.so:
openssl.so:
sqlite3_api.so:
Again, please post a status update if you are working on any of these
libraries.
Cheers, Wayne.
Michael L.:
functionality is in place, and stable, then the libraries will come
quicker.In other words, the cake is still soft in the middle, we can’t start
putting icing on until it’s done baking. What can we do to help stoke
the oven?
There’s a lot of stuff that we still need to work on in the language,
and Wayne’s last mail contains a lot of pointers on things that we still
have to do.
I’m not sure there are any simple tasks that we have in the core
language for folks to hack on. There’s a fairly steep learning curve
there, much more so than in the libs.
The big rocks in core that are left:
Thanks,
-John
Hi
Is there any objection against using a wrapper around zlib.net ?
On Fri, Mar 7, 2008 at 2:27 AM, Michael L.
[email protected]
On Thu, Mar 6, 2008 at 1:29 AM, Wayne K. [email protected] wrote:
A while back I posted a list of external libraries that we needed to
implement in order to support gems and Rails. The following summarizes the
libraries that I’ve been working on. Could others who are also working on
these libraries please post a status update?
[snip]
zlib.so:
- any progress Michael?
[snip]
Again, please post a status update if you are working on any of these
libraries.Cheers, Wayne.
Not yet, I still intend to. Just need to find the time. I’ve been
concentrating on learning ruby a bit more first
–
Michael L.
[Polymath Programmer]
http://blog.prokrams.com
This came up on the list a few months ago. The consensus was that
building
off of System.IO.Compression would be the best, and failing that
wrapping
Zlib.Net should be possible.
You can dig up the old thread for some more details though.
-Eric
On Thu, Mar 6, 2008 at 3:05 PM, Ivan Porto C. [email protected]
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs