Maybe it is time to come up with the why's?? This is how I see the Iron languages. The languages are built on top of the DLR for Interoperability between the languages and to Ensure that the DLR offers the basic building blocks for Dynamic languages and to the base CLR. (be that mono or the CLR now that it is oss) the Iron languages are built so that a Rubiest will feel comfortable in the .net platform or a pythonist for that matter. But more importantly that the libraries built can be used clr/dlr wide. IOW a Ruby library can be used (in theory) by a rubiest for sure, but also a pythonist, a c sharper, a Vber, and for that matter a Fsharper. Now to get working on my programming skills so I can contribute in the future. took a 17 year diversion into equipment repair. But to me the single most important part of the project is the interoperability it offers. D
From: blowm...@gmail.com Date: Sat, 23 Oct 2010 06:44:16 -0600 To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] Contributing? On Oct 23, 2010, at 1:30 AM, Tomas Matousek <tomas.matou...@microsoft.com> wrote: I don’t understand how three distinct github repos that I need to map into some directories on my disk whose relative location to each other is hardcoded in some scripts in each are better than a single repo that has a well-defined structure. You are speaking like someone responsible for both languages and the DLR. I'm making a suggestion as someone really only interested in IronRuby. The repo isn't called "DynamicLanguages", it's called "IronRuby", which is at best confusing. If only git had some way to define a link to another repository as some sort of sub module... As a Rubyist I'd like to run a rake task to build to each defined target and run the RubySpecs. It wouldn't replace xbuild, just automate it. I don't understand the pushback to this idea. Why not make a dedicated repo for IronRuby free of the ancillary projects and geared to someone like me? And likewise make the IronPython repo friendly to our Pythonic friends? The amount of code you need to know depends on the part you contribute to. If you work on IronRuby libraries you don’t need to even look at IronPython. It is indeed better to look there because similar functionality might already be implemented there. For example, if you worked on FFI you might want to check out IronPython’s CTypes and perhaps reuse some code. Why would you need to understand the entire code base if you needed to do a local change? Just don’t look where you don’t need to J. Building IronRuby is also simple – you just run xbuild Ruby.sln from Solution directory. Subsequent builds are incremental, so you don’t even need to build everything if you don’t change core components. I don’t see how this could be any simpler. Unfortunately I do see how this could be simpler. _______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
