Hi, I was just referring a blog from Charles Nutter about his thinking on IronRuby and future implementations for Rails. Here's the link.. http://headius.blogspot.com/2008/04/promise-and-peril-for-alternative-ruby.html Just wondering, how true it sounds... I do not agree on many points. Looking forward to read more comments on this. Thanks
on 28.04.2008 06:37
on 28.04.2008 07:34
2008/4/28 Rahil Kantharia <lists@ruby-forum.com>: > http://headius.blogspot.com/2008/04/promise-and-peril-for-alternative-ruby.html > > Just wondering, how true it sounds... I do not agree on many points. > Looking forward to read more comments on this. It seems to be a rather good overview of the status to me. I mostly agree, except for the accusation that "Microsoft would never back an OSS web framework like Rails in preference to its own".
on 28.04.2008 16:07
Sanghyeon Seo: > It seems to be a rather good overview of the status to me. I mostly > agree, except for the accusation that "Microsoft would never back an > OSS web framework like Rails in preference to its own". He also gets a number of important technical details wrong about IronRuby, I'll respond later today. Thanks, -John
on 28.04.2008 16:51
On Sun, 27 Apr 2008 23:31:21 -0600, Sanghyeon Seo <sanxiyn@gmail.com> wrote: >> Just wondering, how true it sounds... I do not agree on many points. >> Looking forward to read more comments on this. > It seems to be a rather good overview of the status to me. I mostly > agree, except for the accusation that "Microsoft would never back an > OSS web framework like Rails in preference to its own". Hmmm... I think that's a pretty fair statement from Charlie. If I'm understanding his point correctly, Microsoft will never turn away from ASP.NET in favor or Rails, and instead will continue to push ASP.NET in the various directions necessary to keep up with the trends (e.g. ASP.NET MVC Framework.) They'll certainly put the money into providing support for Rails, whether that be through IronRuby, or directly through MRI via the IIS7 FastCGI layer. But it will never become the King@DEV.MSFT. Nor should it. ASP.NET is a kick a$$ web application framework. And regardless of the popularity of Rails in the OSS communities of the world, it will be a *VERY* long time -- if ever -- before the installed Rails developer base surpasses the installed ASP.NET developer base. Plus, the installed ASP.NET developer base is actually willing to spend money on development tools and related products, something the installed Rails-base is only partially willing to do (e.g. TextMate). And, in the end, it's the products that find ways to generate revenue that continue to both survive and thrive. That's not to suggest Rails isn't going to survive and/or thrive. The free-as-in-speech Rails project is funded by the profit making 37 Signals and its various not-free-as-in-gasoline products in the same way the free-as-in-beer .NET/ASP.NET/etc. projects are funded by the profit making Microsoft and its various not-free-as-in-gasoline products. And when you throw the free-as-in-speech IronPython/IronRuby/DLR/ASP.NET MVC/etc. projects into the mix, it's tough to criticize MSFT's intentions and contributions to the OSS ecosystem. Of course the Mono Project -- which in and of itself provides not only the web framework support that Rails represents, but the entire language and platform that MRI represents (and then some!) -- represents a *MASSIVE* OSS community that the Rails community pales in comparison to. So it's tough to take on any type of stance that suggests that .NET/ASP.NET and related frameworks are the wrong overall direction for us developer types to be placing focus on, regardless of our preference towards OSS and proprietary platforms. That said, I most definitely agree with Charlie's thoughts regarding the overall community collaboration and contributions as it relates to the IronRuby project. But I'm less inclined to put the blame entirely on MSFT's shoulders. The door has certainly been open for the community to contribute, and several folks have taken advantage of that. And John and company have certainly proven a willingness to rapidly inject the various contributions into the source tree as soon as these same contributions seem viable enough to be injected into the source tree. I don't want to put the burden entirely on the communities shoulders, but there certainly needs to be at least some recognition to the fact that this is a completely different situation than was JRuby when it came into the good graces of Sun. JRuby was a living, breathing, viable open source implementation of the Ruby language with a living, breathing, and active OSS community backing it up long before Sun came into the picture. On the other hand, IronRuby was a resuscitated proof-of-concept project that I'm not even sure really ever saw the light of the OSS-day before being brought into the MSFT fold. So while Charlie is correct: The IronRuby project needs to become more community oriented, that community orientation needs to come from not only MSFT's direction, but the communities direction as well. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 16:53
On Mon, 28 Apr 2008 08:05:02 -0600, John Lam (IRONRUBY) <jflam@microsoft.com> wrote: > He also gets a number of important technical details wrong about > IronRuby, I'll respond later today. I can point out at least one: "IronRuby really has its roots in the Ruby.NET project from Queensland University of Technology" is incorrect. The IronRuby parser/scanner was bootstrapped by the Ruby.NET parser/scanner, but has since removed all signs of the Ruby.NET parser/scanner in favor of a from-the-ground-up implementation written entirely by -- I believe -- Tomas Matousek. Of course, as Charlie points out somewhat correctly in his opening paragraph, > IronRuby was still Wilco Bauer's IronRuby, a doomed codebase and project > name eventually to be adopted by Microsoft's later Ruby implementation > effort. ... which is at least partially correct, if not a bit misleading given that for all intents and purposes the IronRuby project of today is a from-the-ground-up implementation of the Ruby language and runtime based on top of the from-the-ground-up Dynamic Language Runtime code base and architecture. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 17:01
Well to be fair, IronRuby /does/ have it's roots in Ruby.NET in that it was the first Microsoft supported CLR implementation. And I believe Charles is referring to the /name/ of Bauer's IronRuby being adopted by Microsoft, not the codebase. On Mon, Apr 28, 2008 at 10:52 AM, M. David Peterson <m.david@xmlhacker.com> wrote: > IronRuby parser/scanner was bootstrapped by the Ruby.NET parser/scanner, but > > Co-Founder & Chief Architect, 3rd&Urban, LLC > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com
on 28.04.2008 17:03
M. David Peterson wrote: > That said, I most definitely agree with Charlie's thoughts regarding the > overall community collaboration and contributions as it relates to the > IronRuby project. But I'm less inclined to put the blame entirely on > MSFT's shoulders. The door has certainly been open for the community to > contribute, and several folks have taken advantage of that. And John > and company have certainly proven a willingness to rapidly inject the > various contributions into the source tree as soon as these same > contributions seem viable enough to be injected into the source tree. I disagree, and you need look no further than this mailing list to see the truth. Of the perhaps 40 threads I see started since Apr 3, I see only 8 that were started by folks from Microsoft...all John Lam...two of those SVN update emails. So perhaps 6 substantive threads where the initiator is someone from the IronRuby team. In order for an OSS project to work, any core team needs to be having conversations in the open. Since this is clearly not happening, it would be the first thing to change. I don't know if it's Microsoft policy or just an oversight by the IronRuby team. And obviously not tossing SVN bundles over the wall would help foster a bit more dynamic community. It's far more difficult (maybe impossible) to run an OSS project well if the community members can't update their working copies to exactly what the core team sees day-to-day. This one is most likely an MS issue. - Charlie
on 28.04.2008 17:09
On Mon, 28 Apr 2008 09:00:04 -0600, Michael Letterle <michael.letterle@gmail.com> wrote: > Well to be fair, IronRuby /does/ have it's roots in Ruby.NET in that > it was the first Microsoft supported CLR implementation. Fair enough. > And I > believe Charles is referring to the /name/ of Bauer's IronRuby being > adopted by Microsoft, not the codebase. That would make sense. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 17:29
On Mon, 28 Apr 2008 09:02:56 -0600, Charles Oliver Nutter <charles.nutter@sun.com> wrote: > I disagree, and you need look no further than this mailing list to see > the truth. Of the perhaps 40 threads I see started since Apr 3, I see > only 8 that were started by folks from Microsoft...all John Lam...two of > those SVN update emails. So perhaps 6 substantive threads where the > initiator is someone from the IronRuby team. Oh, I don't disagree with this, just that I don't see any physical obstacles keeping the community from becoming more involved. Mental obstacles, for sure... And maybe that's really where the focus needs to be: Finding ways to remove the mental obstacles that keep people from contributing more aggressively. I know how you guys have done it and are continuing to do it. But putting yourself in IronRuby's Red Slippers for a moment, how would you do it if you were starting from scratch (or as close to scratch as you can get w/o literally starting from scratch) and had to find ways to first, sell the overall idea to the community to then get that same community to actively participate in the process while at the same time making attempt to convince that the once proprietary-only giant really is committed to building OSS into their overall software ecosystem? > In order for an OSS project to work, any core team needs to be having > conversations in the open. Since this is clearly not happening, it would > be the first thing to change. I don't know if it's Microsoft policy or > just an oversight by the IronRuby team. I can't say I really know the answer, but I do agree with your point. From my own perspective I would suggest it's a combination of the internal culture at MSFT attempting to change how they go about the business of courting the developer coupled with the size of the internal IronRuby team that still have to meet deadlines and expectations that are unrelated to IronRuby (e.g. integration with the DLR team, MIX and other high profile events, typical corporate culture stuff such as performance reviews, etc.) That's not an attempt to provide an excuse as to why they can't be more open. Just an attempt at understanding there are more forces involved than are immediately obvious from the outside looking in. > And obviously not tossing SVN bundles over the wall would help foster a > bit more dynamic community. Absolutely 100% agree. One of things I was curious to see when John first announced that IronRuby would be hosted on RubyForge was whether or not he could actually pull it off. From what I assume is both of our perspectives, thus far it hasn't worked out as well as it both could and should have. > It's far more difficult (maybe impossible) to run an OSS project well if > the community members can't update their working copies to exactly what > the core team sees day-to-day. This one is most likely an MS issue. It's absolutely 100% an internal MSFT issue. Can it be fixed? -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 17:36
M. David Peterson: > > It's far more difficult (maybe impossible) to run an OSS project well > > if the community members can't update their working copies to exactly > > what the core team sees day-to-day. This one is most likely an MS > issue. > > It's absolutely 100% an internal MSFT issue. Can it be fixed? While meta-level discussions are interesting, they generally don't offer much in the way of concrete guidance. So let me ask this question to the larger community: Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution? Thanks, -John
on 28.04.2008 17:43
On Mon, 28 Apr 2008 09:27:53 -0600, M. David Peterson <m.david@xmlhacker.com> wrote: > But putting yourself in IronRuby's Red Slippers for a moment, To put this another way, JRuby was a successful OSS project *FIRST* which -- because of this fact -- attracted Sun to bring the project and its two core contributors (at that time -- if not mistaken, didn't Ola really begin his core involvement after the acquisition?) in house. The community didn't have to be convinced of the overall JRuby idea. That had already happened long before Corporate America began it's lust -> love fest with the project, gaining not only the already successful OSS JRuby project, but access to the best and the brightest minds/talent the Java development community had to offer as a result. MSFT, on the other, went out and found the best and brightest minds/talent the .NET development community had to offer -- at least as far as experience with the Ruby language was concerned -- and then tasked them with building not only an OSS Ruby implementation for the .NET platform, but in building an OSS community as well > Both -- for all intents and purposes -- from scratch. Two different situations. Two different scenarios. You've done it successfully from the outside in. How would you do it -- again successfully -- from the inside out? -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 17:44
On Mon, Apr 28, 2008 at 8:35 AM, John Lam (IRONRUBY)
<jflam@microsoft.com> wrote:
> Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution?
I have a large block of code that is based on the long-ago RubyCLR
bridge John implemented. I am very excited to get that onto native
.NET. My impression is that IronRuby is not far enough along to
support much of my codebase, but it's a moot point. I cannot access
RubyForge's SVN repository from behind my employer's ISA firewall (it
blocks certain HTTP headers SVN uses). I did manage to spider the
latest release at one point using WGET but it wasn't an effort I'd
repeat regularly. Another method for getting the codebase would make
it easier for me to see what IronRuby is capable of so far.
Justin
on 28.04.2008 17:44
On Mon, 28 Apr 2008 09:35:24 -0600, John Lam (IRONRUBY) <jflam@microsoft.com> wrote: > Has working on the SVN sources (with the attendant delays in propagating > to / from our version of 'the truth') blocked you from working on a > contribution? No. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 17:46
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles Oliver Nutter wrote: > > And obviously not tossing SVN bundles over the wall would help foster a > bit more dynamic community. It's far more difficult (maybe impossible) > to run an OSS project well if the community members can't update their > working copies to exactly what the core team sees day-to-day. This one > is most likely an MS issue. I don't usually like to criticize open source projects but I must say that I wholeheartedly agree with you on this point. The development process behind JRuby and Rubinius is very open, while IronRuby's one is not nearly enough so. The end result is that JRuby and Rubinius appear to be improving really fast, while IronRuby seems to proceed at a glacial pace. Behind the scenes, this may not be the case, but by looking at the repository this is the impression that one gets. According to ohloh, IronRuby has 2 contributors who made commits, JRuby has 22 and Rubinius 152. JRuby and Rubinius get several commits on a daily basis, while IronRuby's commits are rare and 1 year after its announcement there still hasn't been a single release, the trunk is at version 96 and x = 2 in interactive mode is still broken. While granted IronRuby may appeal to less people than Rubinius or JRuby, I still feel that the development process could benefit a lot from incremental/daily commits, more transparency and a greater deal of control handed to the community. As Charlie mentioned somewhere else, JRuby is not Sun's, it belongs to the community. That statement is entirely backed up by facts, but I'm afraid that, at this stage, it isn' possible to claim the same for IronRuby. This, coupled with the fact that ASP.NET and languages like C# are clearly Microsoft's main interest, lead me to believe that IronRuby is not living up to its full potential. Microsoft has the resources and brilliant minds (e.g. John Lam) to seriously reconsider its approach to this project, in order to really let it take off. Just my 2 cents, Antonio - -- http://antoniocangiano.com - Zen and the Art of Programming http://stacktrace.it - Aperiodico di resistenza informatica http://math-blog.com - Math Blog: Mathematics is wonderful! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgV8PIACgkQqCqsu0qUj9SOrgCgww8tFRi03AQG0nnj6iE2MCuo KboAn0hzVO97RQgJIALx07e1j4px1iOl =Y1aM -----END PGP SIGNATURE-----
on 28.04.2008 17:47
John Lam (IRONRUBY) wrote: > > Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution? And answer carefully, friends, because you could help correct this policy. Don't give an answer you think John wants to hear, because a little community pressure could go a long way toward improving the situation. I'm sure John would agree with me there... - Charlie
on 28.04.2008 17:50
On Mon, 28 Apr 2008 09:43:29 -0600, Justin Bailey <jgbailey@gmail.com> wrote: > Another method for getting the codebase would make > it easier for me to see what IronRuby is capable of so far. Like? Is there another SCC/wire protocol that would work? If yes, there are plenty of bridges out there that are 1-to-1 compatible (meaning they retain 100% of the meta-data and related versioning/check-in info) with SVN both forwards and backwards. Tailor comes to mind. I know there are others. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 17:56
Hi, All I can say is... The Progress is slow. Refer to this thread in this forum only. One of the community member shouts, since there is no beta around even after one year. Here's the link.. http://www.ruby-forum.com/topic/144090#new All I can say clearly is...There is Lots of Delay in the progress. Thanks
on 28.04.2008 17:56
I have not personally been affected by the long time periods between the code drops. I doubt it has had a serious impact on many other contributors. Although there have certainly been a few issues highlighted in the mailing list around the hosting API and some other internal chunks of code that have delayed people trying to work on top of IR - the SaphireSteel guys come to mind, I still believe this has not really been a problem, since even in a totally open environment, people would need to wait on the core team to deliver API's anyway, no? I think the main problem with the current wall-tossing arrangement is that it creates a feeling of, "this is a their (Microsoft) project" rather than "this is our (community) project". Contributors feel no ownership of the code they contribute, let alone the project as a whole. What gets people excited, and encouraged to contribute, to a project is the feeling that they own some part of it or have some responsibility in the direction and decision making. Bug fixing patches and fleshing out code stubs is very important but not too exciting for many developers. It would have been an interesting exercise to break off self-standing components of the Iron Ruby libraries and set them up as independent OSS projects of their own that are primarily stored in SVN and imported into MS Team repositories on occasion rather than the other way around. Obvious candidates are the YAML processor, the Regex engine, and any other components that require substantial C# code to be written, and design decisions to be made. It is not too late to implement something like this. If a bit of work could be done on loading external IR libraries then projects could begin to be setup independently. This would have the multiple benefit of getting people to work on interesting and challenging projects, potentially creating alternative options to the IR community but also those people working on the projects are more likely to pickup bugs and add in the smaller patches to the core that are not getting people excited at the moment. My two pennies. Pete
on 28.04.2008 17:59
On Mon, 28 Apr 2008 09:45:46 -0600, Charles Oliver Nutter <charles.nutter@sun.com> wrote: > And answer carefully, friends, because you could help correct this > policy. I answered honestly. No, it's not getting in the way. But that doesn't mean I believe that process isn't broken. It is without a doubt. I'm just not 100% sure -- taking in all considerations to the challenge at hand -- how to "fix" it from a truly ideal OSS community perspective. > Don't give an answer you think John wants to hear, because a little > community pressure could go a long way toward improving the situation. > I'm sure John would agree with me there... I dom't know if he will agree or not, but whether he does or doesn't, the fact of the matter is that there are two options, - Do nothing and wait for something to happen on its own. - Do something and see what happens as a result. I'm 100% the notion of applying pressure. Where's the best place to start? -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 18:05
On Mon, 28 Apr 2008 09:44:50 -0600, Antonio Cangiano <acangiano@gmail.com> wrote: > As Charlie mentioned somewhere else, JRuby is not Sun's, it belongs to > the community. That statement is entirely backed up by facts, but I'm > afraid that, at this stage, it isn' possible to claim the same for > IronRuby. This, coupled with the fact that ASP.NET and languages like C# > are clearly Microsoft's main interest, lead me to believe that IronRuby > is not living up to its full potential. Nicely stated! Of course, as per my previous argument, I do believe consideration needs to be made as to the difference between the outside > in approach that JRuby represents and the inside > out approach represented by IronRuby. None-the-less, there needs to be some faith building exercises coming from the direction of MSFT that help bring a better sense of community ownership to the project, that's without a doubt! > Microsoft has the resources and brilliant minds (e.g. John Lam) to > seriously reconsider its approach to this project, in order to really > let it take off. Absolutely! -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 18:05
2008/4/29 John Lam (IRONRUBY) <jflam@microsoft.com>:
> Has working on the SVN sources (with the attendant delays in propagating to / from our version of 'the truth') blocked you from working on a contribution?
Blocked? No. Discouraged? Hell sure.
(The same applies to IronPython, but IronPython is much more stable
than IronRuby, so it changes less frequently, which makes keeping up
to date easier.)
on 28.04.2008 18:07
Peter Bacon Darwin wrote: > I have not personally been affected by the long time periods between the > code drops. I doubt it has had a serious impact on many other contributors. > Although there have certainly been a few issues highlighted in the mailing > list around the hosting API and some other internal chunks of code that have > delayed people trying to work on top of IR - the SaphireSteel guys come to > mind, I still believe this has not really been a problem, since even in a > totally open environment, people would need to wait on the core team to > deliver API's anyway, no? In general the problem I see most often goes like this: 1. Contributor tries to run IronRuby from RubyForge trunk. 2. Contributor finds a bug. 3. Contributor emails the list, asking if this bug has been fixed, and often volunteering to fix it. 4. IronRuby Team Member replies, saying the bug is fixed and will be in the next drop. 5. Contributor waits, maybe moving on to other IronRuby work or maybe walking away from the project until the next drop. And this seems to happen again and again. Not only does it slow the process of fixing bugs, it makes it impossible for people to want to help fix them. If you can never know you're running against the latest sources, the process of finding a bug, emailing to see if it's fixed already, and probably waiting for that fix to arrive is extremely discouraging. - Charlie
on 28.04.2008 18:09
On Mon, 28 Apr 2008 10:03:49 -0600, Sanghyeon Seo <sanxiyn@gmail.com> wrote: > Blocked? No. Discouraged? Hell sure. I can't think of a better way to accurately portray the reality of the situation. Nicely stated, Seo! -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 18:29
On Mon, 28 Apr 2008 10:05:43 -0600, Charles Oliver Nutter <charles.nutter@sun.com> wrote: > And this seems to happen again and again. Not only does it slow the > process of fixing bugs, it makes it impossible for people to want to > help fix them. If you can never know you're running against the latest > sources, the process of finding a bug, emailing to see if it's fixed > already, and probably waiting for that fix to arrive is extremely > discouraging. I agree. If I am remembering correctly, one of the primary reasons behind the dual-repository approach is the need to run a myriad of internal tests from a test suite that reaches farther and deeper than just IronRuby, and therefore can not see the light of day outside the MSFT firewall. John, is this an accurate assessment? If yes, while I certainly recognize the need to run the code against internal test suites, couldn't it be looked at from the opposite perspective?That of: We, the community, tell you, the big bad corporate firewall, when you get to gain access to *our* code to run your tests. We will continue on our way checking it whatever we want whenever we want, and you can use repository revisions as a marker to determine what can be viewed as "blessed" and what can not as far as releases are concerned. If it really is an issue with intellectual property et. al, you can keep those results locked up in a bit locker that guarantees they'll never experience life outside their darkened dungeon. We, the community, are not interested in the results of internal tests, and we certainly would understand that, regardless of the results of our external tests, there are certain check boxes that need to be checked by powers unknown to us before an officially blessed release can be made. All we care about is passing the spec, something which is, quite obviously, controlled outside the grasp of Redmond's barbed [fire]wire-trimmed walls. If it takes a few extra weeks to take a particular revision of the repository through the internal ringer before getting the official rubber stamp, then so be it. It wouldn't be getting in the way of development progress, and if not mistaken, this is really the core of the argument as to why the process is currently broken. Food for thought... -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 18:43
"but since removed all signs of the Ruby.NET parser/scanner in favor of a from-the-ground-up implementation written entirely by -- I believe -- Tomas Matousek" More precisely, I've heavily refactored the tokenizer (and it's still not finished) and rewrote semantic actions in the grammar to create IronRuby AST - which I wrote from scratch. The grammar rules themselves are more or less as they was in Ruby.NET. With some renames and minor changes. Tomas
on 28.04.2008 18:55
On Mon, 28 Apr 2008 10:42:01 -0600, Tomas Matousek <Tomas.Matousek@microsoft.com> wrote: > More precisely, I've heavily refactored the tokenizer (and it's still > not finished) and rewrote semantic actions in the grammar to create > IronRuby AST - which I wrote from scratch. The grammar rules themselves > are more or less as they was in Ruby.NET. With some renames and minor > changes. Thanks for the clarification, Tomas! -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 28.04.2008 19:05
I can't say that the delay has stopped me from working on a contribution since I've just recently started investigating where I may be able to lend a hand. However, I can say that I'm much more reluctant to jump in and start working on something since I don't want to work on a implementing or fixing something that has already been addressed. I think it would be great to have a more open environment where the community knows what the members of the IronRuby team are working on and what they're currently thinking about, as well as what things they aren't able to get to yet but are higher priority. This would help the community understand what they should stay away from, as well as what would be a good place to contribute. In order to foster a community around IronRuby I believe there needs to be something that can rally the community around a cause. Right now, most of the people I've spoken to are in a wait and see mode with IronRuby. It would be great if we could do something to get people in a "what can I do to contribute value to the project" mode. This is coming from someone who has just recently "joined" the IronRuby community, so I may not be looking in the right places. Cheers, Steve On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY) <jflam@microsoft.com>
on 29.04.2008 01:01
So, one of the "details" that are wrong is that we don't support
multiple isolated engines in a single process.
It's actually quite simple to do so via DLR Hosting API. The main
concept here is ScriptRuntime. This class represents the world for a
dynamic language. The class holds on loaded assemblies, .NET namespace
references, etc. Each language could also associate its own global state
with the runtime. IronRuby has all Ruby global state there: global
variables table, class hierarchy etc. So, unless you use CLR interop,
there is no way how the script could get outside this sandbox. If you
want to isolate the runtimes even more (for CLR interop) you can always
create a ScriptRuntime inside a separate app-domain.
Let's show some example (a self-contained C# source code of a simple
IronRuby host follows):
using System.IO;
using Microsoft.Scripting.Hosting;
class RubyHostingExample {
public static void Main() {
const string write = @"C:\Temp\write.rb";
const string read = @"C:\Temp\read.rb";
File.WriteAllText(write, @"
$x = 'Hello from runtime #1!'
C = 'some constant'
module Kernel
def say_bye
puts 'bye'
end
end
");
File.WriteAllText(read, @"
puts $x
if defined? C
puts C
else
puts 'C not defined'
end
say_bye rescue puts $!
puts
");
ScriptRuntime runtime1 = ScriptRuntime.Create();
ScriptRuntime runtime2 = ScriptRuntime.Create();
runtime1.ExecuteFile(write);
runtime2.ExecuteFile(read);
runtime1.ExecuteFile(read);
}
}
---
Let's compile and run it:
C:\IronRuby\Bin\Debug>csc /r:Microsoft.Scripting.dll
/r:Microsoft.Scripting.Core.dll /r:IronRuby.dll rt.cs
Microsoft (R) Visual C# 2008 Compiler version 3.5.21022.8
for Microsoft (R) .NET Framework version 3.5
Copyright (C) Microsoft Corporation. All rights reserved.
C:\IronRuby\Bin\Debug>rt.exe
nil
C not defined
undefined local variable or method `say_bye' for main:Object
Hello from runtime #1!
some constant
bye
---
And if you want app-domain isolation, just do
ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")).
That was easy, wasn't it?
Tomas
on 29.04.2008 01:21
Tomas Matousek wrote: > [snip...] > > And if you want app-domain isolation, just do ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")). > > Does this actually work? No one has been able to post working code on creating an IronPython engine in another app domain on the IronPython mailing list. Can you use this to place restrictions on the app domain - like restrict which assemblies can be loaded and control network / filesystem access? A working example would be a wonderful thing... The reason I am dubious is that it seems that the code generation used by the DLR requires pretty much full trust in .NET 2, so *any* restrictions (which is usually the point of running in another app domain) blow up. I would dearly love to be proved wrong on this of course. Michael Foord
on 29.04.2008 01:52
Here's a working example (no partial trust) in Python:
import clr
clr.AddReference('Microsoft.Scripting.Core')
import System
from Microsoft.Scripting import SourceCodeKind
from Microsoft.Scripting.Hosting import ScriptRuntime
ad = System.AppDomain.CreateDomain('foo')
sr = ScriptRuntime.Create(ad)
sr.LoadAssembly(clr.GetClrType(str).Assembly)
py = sr.GetEngine('py')
su = py.CreateScriptSourceFromString('import System\nprint
System.AppDomain.CurrentDomain\n', SourceCodeKind.File)
su.Execute()
Indeed partial trust might be a problem - we've run into a few bugs
there on the desktop CLR where we have divergent code paths from
Silverlight. It's also only available on Orcas / .NET 2.0 Sp1 or later
where we'll use anonymously hosted dynamic methods if they're available.
Finally I believe our "optimized module" and other subclassing of .NET
standard types won't work because those need full reflection.emit but I
haven't verified that.
Anyway, the issue of partial trust has been brought up with various
people on the DLR side of things and there should be a push at some
point to ensure this works.
But there are other advantages w/ app domains than just security. You
also get:
the ability to unload code w/ a decreased worry of corruption
This is using Thread.Abort safely. Large amounts of
code can be safely unloaded because there's no shared state outside of
the app domain which can be corrupted (note there's some code in the
world that this doesn't apply to, but it applies to most of the .NET
framework).
isolation of static variables that live outside of the script
environment
I think Tomas alluded to this
the ability to unload assemblies
Ye-olde-reason to use app domains on the CLR
on 29.04.2008 06:18
M. David Peterson wrote: > parser/scanner in favor of a from-the-ground-up implementation written > entirely by -- I believe -- Tomas Matousek. Of course, as Charlie points > out somewhat correctly in his opening paragraph, The IronRuby parser/scanner being bootstrapped by the Ruby.NET parser/scanner is certainly enough to say that's where IronRuby's roots lie. And even without that, IronRuby probably wouldn't have been attempted if Ruby.NET had shown it to be too difficult or impossible. IronRuby owes Ruby.NET for its birth, at least. >> IronRuby was still Wilco Bauer's IronRuby, a doomed codebase and >> project name eventually to be adopted by Microsoft's later Ruby >> implementation effort. > > ... which is at least partially correct, if not a bit misleading given > that for all intents and purposes the IronRuby project of today is a > from-the-ground-up implementation of the Ruby language and runtime based > on top of the from-the-ground-up Dynamic Language Runtime code base and > architecture. No, it's an entirely correct statement. At the time, IronRuby was Wilco's project, and no IronRuby work had been started at MS. I did not make any claim that the codebase was somehow reused or incorporated into the official "IronRuby", and made a point of calling it doomed because as far as I know it's never going to be touched again. Perhaps I should have said: "IronRuby" was still Wilco Bauer's IronRuby, ... - Charlie
on 29.04.2008 06:27
In a technical fashion? No. From an emotional standpoint? Yes. Right now IronRuby is very unstable from the view of an outside contributor, you don't know if the code you're working on now is going to need /major/ changes in the next drop, and you don't know when that's going to be. Why work on a bug that "in truth" may already be fixed? The most important change that MSFT can do is let you push to rubyforge DIRECTLY, none of this internal updates pushed to rubyforge once in a while. I assume it's corporate preventing this, because it really make no sense otherwise. What we have here isn't an OSS community project in the traditional sense, what we have is a Microsoft project that they've so kindly, in their infinite wisdom allow us commoners to work on now and then. Oh but you can't see or touch the real code until we're ready to let you. This is HIGHLY discouraging. Don't get me wrong, I applaud Microsoft for going this far, it's a major step, but only a step, there's still a long way to go. On Mon, Apr 28, 2008 at 11:35 AM, John Lam (IRONRUBY) <jflam@microsoft.com> wrote: > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com
on 29.04.2008 06:28
I believe one of the key problems is the DLR. As I understand, it MS makes a distinction between "important" stuff (i.e. the DLR) and "peripheral" stuff (i.e. IronXxxx). MS wants to have complete control over the DLR and is not interested in making it Open Source. Rather the DLR code is just community viewable, much like the rest of the .NET framework code. I can understand this since core .NET Framework code is central to the MS strategy and they don't want things sneaking in the sides. IronRuby, IronPython and so on are not so important to MS strategy and they are more happy to let the community muck about with the code. I believe that the long term goal is to open up the IronXxxx code much more to the community but the problem is that the line between the DLR and the IronXxxx languages is not yet nailed down. Therefore until that happens MS is unlikely to hand over the project to the community. I would be interested to know how often an SVN dump is created compared to successful check-ins going through the SNAP process. Ideally, every successful SNAP check-in should get automatically dumped out on the RubyForge SVN repos, whether it added value or broke the tests or whatever. You can always have SVN tags on the "good" builds and also create downloadable "good" releases on the RubyForge site - this point would probably help Justin Bailey's access problems too. Another scenario, which /M:D alludes to if I understand correctly, is to allow the community to modify the code in the RubyForge project and then let MS select "good" builds to check back into the Team system via the SNAP process. That way, the community feels ownership of the project and MS get that quality control on what finally goes into IronRuby. There are obviously many technical hurdles to overcome before this could become reality. In particular, there needs to be a separation of DLR from IronXxxx, including, probably, some kind of stable release of the DLR for the IronXxxx projects to work off. Any other ideas? John what are you thinking here? Pete
on 29.04.2008 06:36
On Mon, Apr 28, 2008 at 4:19 PM, Michael Foord <fuzzyman@voidspace.org.uk> wrote: > Tomas Matousek wrote: > > [snip...] > > > > And if you want app-domain isolation, just do > ScriptRuntime.Create(System.AppDomain.CreateDomain("foo")). > Does this actually work? No one has been able to post working code on > creating an IronPython engine in another app domain on the IronPython > mailing list. Actually, I seem to recall that this works fine in IronPython -- provided that you're running under FullTrust. (Which, as you pointed out, needs to be addressed.) -- Curt Hagenlocher curt@hagenlocher.org
on 29.04.2008 06:37
Dino Viehland wrote: > Here's a working example (no partial trust) in Python: > > Cool! Thanks Dino. I don't normally speak to you here. :-) Michael
on 29.04.2008 07:24
2008/4/29 Peter Bacon Darwin <bacondarwin@googlemail.com>: > I believe one of the key problems is the DLR. As I understand, it MS makes > a distinction between "important" stuff (i.e. the DLR) and "peripheral" > stuff (i.e. IronXxxx). MS wants to have complete control over the DLR and > is not interested in making it Open Source. Rather the DLR code is just > community viewable, much like the rest of the .NET framework code. I can > understand this since core .NET Framework code is central to the MS strategy > and they don't want things sneaking in the sides. I disagree. I think DLR is a non-problem. Reality check: do you have any change in your mind you would like to make to DLR? For example, (sorry for using CPython as an example; I am not familiar with Ruby world) many people contributes to CPython runtime without touching CPython's custom memory allocator. Still many people contributes to CPython standard library and C extensions without touching CPython runtime.
on 29.04.2008 08:07
My point wasn't that one needs to have access to the DLR code. It was that because IronRuby is so tightly coupled to DLR at the moment, it is not possible to remove its tethers and let it free as a proper OSS. Pete
on 29.04.2008 15:07
On Mon, Apr 28, 2008 at 1:36 PM, Peter Bacon Darwin <bacondarwin@googlemail.com> wrote: > and they don't want things sneaking in the sides. > The DLR sources are under the Microsoft Public License as well. > > > At some point the DLR and the languages will have to be separated, once the DLR stabilizes to some point. I don't really think the current arraignment is viable in the long term, not from an OSS point of view anyway. -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com
on 29.04.2008 15:14
Michael Letterle: > In a technical fashion? No. From an emotional standpoint? Yes. > Right now IronRuby is very unstable from the view of an outside > contributor, you don't know if the code you're working on now is going > to need /major/ changes in the next drop, and you don't know when > that's going to be. Why work on a bug that "in truth" may already be > fixed? Agreed. We do maintain our external bug list in Rubyforge which folks can monitor (are you all receiving update mails on status changes in tracker?). So you'll know when we've fixed a bug when you see the Resolution changes from None to Accepted along with some kind of comment that says 'fixed in next release'. > The most important change that MSFT can do is let you push to rubyforge > DIRECTLY, none of this internal updates pushed to rubyforge once in a > while. I assume it's corporate preventing this, because it really make > no sense otherwise. What we have here isn't an OSS community project > in the traditional sense, what we have is a Microsoft project that > they've so kindly, in their infinite wisdom allow us commoners to work > on now and then. Oh but you can't see or touch the real code until > we're ready to let you. This is HIGHLY discouraging. I've set the releases traditionally based on whether we had something 'interesting' to ship. Sometimes we might go a week or even longer before substantive changes happen in the Ruby tree. Such is life when working on compilers - you simply do not check in very often. Remember that we have Tomas as a full time dev and me as a part time dev on this project. We're hiring as well - please send me mail off-list if you're interested. You'll see more frequent changes in the DLR tree since they have more devs working on the project. Thanks, -John
on 29.04.2008 15:15
Peter Bacon Darwin: > I believe one of the key problems is the DLR. As I understand, it MS > makes a distinction between "important" stuff (i.e. the DLR) and > "peripheral" stuff (i.e. IronXxxx). MS wants to have complete control > over the DLR and is not interested in making it Open Source. Rather > the DLR code is just community viewable, much like the rest of the > .NET framework code. I can understand this since core .NET Framework > code is central to the MS strategy and they don't want things sneaking > in the sides. Minor correction to this point: The DLR is Open Source in as far as the license is concerned (which is not like the .NET Framework libraries source which is released under a much more restrictive read-only license), which works for folks who are interested in packaging / redistributing / forking. The DLR is does not accept contributions from the community, but feedback is certainly welcome. That said, the bar for feedback is set rather high on the DLR. Most folks are not compiler implementers, and that's the feedback that is needed there. Most folks working on libraries do not need to know anything about how the DLR is implemented (which is useful since that is changing rapidly right now). However, if you're building a language (we're doing 3) you have valuable feedback for the DLR team and that's one of the goals of IronRuby - to provide feedback to the DLR team. The reason why the DLR does not accept contributions from the community is because we intend to ship it in the next version of the .NET framework. And that means that it ships inside of our commercial products like Windows. Having community contributions in Windows is something that we simply cannot do today. > IronRuby, IronPython and so on are not so important to MS strategy and > they are more happy to let the community muck about with the code. I > believe that the long term goal is to open up the IronXxxx code much > more to the community but the problem is that the line between the DLR > and the IronXxxx languages is not yet nailed down. Therefore until > that happens MS is unlikely to hand over the project to the community. IronPython will move to an accept contributions from the community model soon. > I would be interested to know how often an SVN dump is created > compared to successful check-ins going through the SNAP process. > Ideally, every successful SNAP check-in should get automatically > dumped out on the RubyForge SVN repos, whether it added value or broke > the tests or whatever. You can always have SVN tags on the "good" > builds and also create downloadable "good" releases on the RubyForge > site - this point would probably help Justin Bailey's access problems too. Today we do not push to SVN on every successful SNAP check-in. That said, the process on my machine is more-or-less "rake to_svn", with a manual check-in after that. I would be more than happy to push on a daily basis. > Another scenario, which /M:D alludes to if I understand correctly, is > to allow the community to modify the code in the RubyForge project and > then let MS select "good" builds to check back into the Team system > via the SNAP process. That way, the community feels ownership of the > project and MS get that quality control on what finally goes into > IronRuby. > There are obviously many technical hurdles to overcome before this > could become reality. In particular, there needs to be a separation > of DLR from IronXxxx, including, probably, some kind of stable release > of the DLR for the IronXxxx projects to work off. Exactly. Right now the integrated model is good since it means that we progress faster. In the future, when we move to a modular model, it means that DLR changes will break IronRuby which means more work for everyone on this end (the DLR devs will be happier since they'll spend less time fixing us). The bottom line is that work is generated - it's just who feels the pain. > Any other ideas? John what are you thinking here? I collected my thoughts in the other thread that I started last night. Thanks for your ideas! -John
on 29.04.2008 15:24
Peter Bacon Darwin: > My point wasn't that one needs to have access to the DLR code. It was > that because IronRuby is so tightly coupled to DLR at the moment, it is > not possible to remove its tethers and let it free as a proper OSS. > Pete Yep. BTW, this is exactly the set of arguments that are used in making the distinction between integrated and modular systems. We are integrated now because we are optimizing for finishing our work on the DLR (and the first set of languages) sooner. We will become modular in the future because it lets folks build on top of us more easily. If you're curious listen to Clay Christensen's most excellent thoughts on this topic in this podcast: http://itc.conversationsnetwork.org/shows/detail135.html -John
on 29.04.2008 15:26
On Tue, Apr 29, 2008 at 9:12 AM, John Lam (IRONRUBY) <jflam@microsoft.com> wrote: > Agreed. We do maintain our external bug list in Rubyforge which folks can monitor (are you all receiving update mails on status changes in tracker?). So you'll know when we've fixed a bug when you see the Resolution changes from None to Accepted along with some kind of comment that says 'fixed in next release'. > > Is the internal bug list maintained on RubyForge? RubyForge has been getting alot more love then before, but I would still like to see more community members actively use it. > > The most important change that MSFT can do is let you push to rubyforge > > DIRECTLY, none of this internal updates pushed to rubyforge once in a > > while. I assume it's corporate preventing this, because it really make > > no sense otherwise. What we have here isn't an OSS community project > > in the traditional sense, what we have is a Microsoft project that > > they've so kindly, in their infinite wisdom allow us commoners to work > > on now and then. Oh but you can't see or touch the real code until > > we're ready to let you. This is HIGHLY discouraging. > > I've set the releases traditionally based on whether we had something 'interesting' to ship. Sometimes we might go a week or even longer before substantive changes happen in the Ruby tree. Such is life when working on compilers - you simply do not check in very often. Remember that we have Tomas as a full time dev and me as a part time dev on this project. We're hiring as well - please send me mail off-list if you're interested. "Check-in early and often", it doesn't matter if the changes are interesting or there's new features, maybe something that isn't interesting to you that seems mundane is something that causes another developer to be able to create something new and interesting. OSS development is all about collaboration, collaborating is hard when one is left in the dark until something "interesting" happens :) -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com
on 29.04.2008 16:08
M. David Peterson: > I agree. If I am remembering correctly, one of the primary reasons > behind the dual-repository approach is the need to run a myriad of > internal tests from a test suite that reaches farther and deeper than > just IronRuby, and therefore can not see the light of day outside the > MSFT firewall. There are several issues around this. We run our tests against internal drops of Silverlight (remember we're building IronRuby while simultaneously building DLR *and* CoreCLR). Externals won't be able to see this stuff, and to keep our tree consistent we need to continue to test and run against CoreCLR. > John, is this an accurate assessment? If yes, while I certainly > recognize the need to run the code against internal test suites, > couldn't it be looked at from the opposite perspective?That of: We, the > community, tell you, the big bad corporate firewall, when you get to > gain access to *our* code to run your tests. We will continue on our > way checking it whatever we want whenever we want, and you can use > repository revisions as a marker to determine what can be viewed as > "blessed" and what can not as far as releases are concerned. This is largely a philosophical issue - do you want to resolve build breaks when you sync or do you want to resolve build breaks when you commit. The former is worse than the latter, especially when it takes a significant amount of time to see if things work (40 minutes today). > If it takes a few extra weeks to take a particular > revision of the repository through the internal ringer before getting > the official rubber stamp, then so be it. > It wouldn't be getting in the way of development progress, and if not > mistaken, this is really the core of the argument as to why the process > is currently broken. This will impede progress a lot more than you think it would ... remember - you're writing library code on top of a changing IronRuby compiler + runtime which itself is built on top of a changing DLR which is itself built on top of a changing CoreCLR (aka Silverlight CLR). One of our DLR devs recently spent 30 hours debugging a buffer overrun in a daily build of CoreCLR that was fixed in a subsequent build. Is this the world that you really want to live in? Thanks, -John
on 29.04.2008 16:23
Antonio Cangiano: > The development > process behind JRuby and Rubinius is very open, while IronRuby's one is > not nearly enough so. Impressions are important, and we're working to fix that now. > While granted IronRuby may appeal to less people than Rubinius or > JRuby, I still feel that the development process could benefit a lot > from incremental/daily commits, more transparency and a greater deal of > control handed to the community. Agreed - working on this too. > As Charlie mentioned somewhere else, JRuby is not Sun's, it belongs to > the community. That statement is entirely backed up by facts, but I'm > afraid that, at this stage, it isn' possible to claim the same for > IronRuby. We will make this happen. > This, coupled with the fact that ASP.NET and languages like > C# are clearly Microsoft's main interest, lead me to believe that > IronRuby is not living up to its full potential. Those are orthogonal issues. Microsoft isn't "one" entity - it's many, many teams. Those teams that create a product are naturally invested in its success. We have lots of 3rd party software that runs on our platforms - we're a platform company. We have lived in this co-opetition space for a long, long time. Thanks, -John
on 29.04.2008 16:41
Michael Letterle: > Is the internal bug list maintained on RubyForge? RubyForge has been > getting alot more love then before, but I would still like to see more > community members actively use it. We don't have an internal bug list (well we do for DLR bugs etc but those aren't important around here). All of our bugs live on Rubyforge. > "Check-in early and often", it doesn't matter if the changes are > interesting or there's new features, maybe something that isn't > interesting to you that seems mundane is something that causes another > developer to be able to create something new and interesting. OSS > development is all about collaboration, collaborating is hard when one > is left in the dark until something "interesting" happens :) Working on this now. Thanks, -John
on 29.04.2008 16:46
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John Lam (IRONRUBY) wrote: | [...] | We will make this happen. Great. |> This, coupled with the fact that ASP.NET and languages like |> C# are clearly Microsoft's main interest, lead me to believe that |> IronRuby is not living up to its full potential. | | Those are orthogonal issues. Microsoft isn't "one" entity - it's many, many teams. Those teams that create a product are naturally invested in its success. We have lots of 3rd party software that runs on our platforms - we're a platform company. We have lived in this co-opetition space for a long, long time. Agreed, it's the same in IBM, with many teams and many realities. I mentioned Microsoft's interest (in terms of resources allocated and overall strategy) even if it's orthogonal to the issue at hand because I think that, while not a deal breaker, this aspect can become an aggravating factor if the project is not able to attract sustainable contributions from the community. Cheers, Antonio - -- http://antoniocangiano.com - Zen and the Art of Programming http://stacktrace.it - Aperiodico di resistenza informatica http://math-blog.com - Math Blog: Mathematics is wonderful! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgXNF0ACgkQqCqsu0qUj9S2LACffcNXPSi7uNh944mMNU2aOyrS 4vkAoNtmO2RVLqvzKgf24OwfKGtMg26J =Oxop -----END PGP SIGNATURE-----
on 29.04.2008 23:16
On Tue, 29 Apr 2008 08:06:57 -0600, John Lam (IRONRUBY) <jflam@microsoft.com> wrote: > Is this the world that you really want to live in? Can I think about it? ;-) I kid. No, I do recognize your point. It seems a lot of good things are becoming of this overall conversation, so regardless of how things are structured it seems we're headed in the right direction. -- /M:D M. David Peterson Co-Founder & Chief Architect, 3rd&Urban, LLC Email: m.david@3rdandUrban.com | m.david@amp.fm Mobile: (206) 999-0588 http://3rdandUrban.com | http://amp.fm | http://www.oreillynet.com/pub/au/2354
on 30.04.2008 16:02
Peter Bacon Darwin: > It is not too late to implement something like this. If a bit of work > could be done on loading external IR libraries then projects could > begin to be setup independently. This would have the multiple benefit > of getting people to work on interesting and challenging projects, > potentially creating alternative options to the IR community but also > those people working on the projects are more likely to pickup bugs and > add in the smaller patches to the core that are not getting people > excited at the moment. I'm working on giving commit rights to contributors. We will open up parts of the repository to folks who want to work / collaborate on libraries like zlib, ironi, and your jvyaml port. Something like: src\ zlib ironi yaml ... We would have external folks own those directories and they would be responsible for reviewing contributions into those directories. Those directories would compile into stand-alone assemblies, but this gives folks a place to build and collaborate. I'm leaning towards treating those projects as living on a level above our current libraries + runtime: zlib ironi yaml ironruby.libraries ironruby The ironruby.libraries + ironruby are things that we are responsible for and have to get past our check-in troll. The zlib, ironi, and yaml libraries are things that we will periodically (on a schedule) integrate with our internal test infrastructure. This way, folks outside can continue to work without the overhead (on your end or our end) of having to run each check in past our troll. That said, this means that you're deferring pain until integration time. One of the things that you'll need to ensure happens is that your code compiles and runs using Silverlight. This is *painful* since running CoreCLR outside of the browser is something that we do not support today. Internally we have a tool that lets us do this, but we cannot redist that tool to external folks. Also, that tool is being phased out, and we're replacing it with a browser-based testing infrastructure for code that has to compile and run under Silverlight. We may be able to help with this longer term, but we don't have any short term cycles to make this happen today. I think that the natural owners of these libraries are: zlib: Michael Letterle ironi: Peter Bacon Darwin yaml: John Messerly There may be others - thoughts? Thanks, -John
on 30.04.2008 18:28
I would name the assemblies (and maybe the directories for consistency) IronRuby.ZLib, IronRuby.Oniguruma, IronRuby.Yaml since they are dependent on IronRuby and are not general implementations of zlib, regex, yaml. And to be consistent with other assembly names. Tomas
on 30.04.2008 20:48
The only issue with this is we'll have to have some mechanism for them to be referenced with require 'zlib', requrie 'yaml', et. al. in order to maintain compatibility. On Wed, Apr 30, 2008 at 12:27 PM, Tomas Matousek <Tomas.Matousek@microsoft.com> wrote: > Cc: Qing Ye > > add in the smaller patches to the core that are not getting people > ... > > There may be others - thoughts? > Ironruby-core@rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > -- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com