With a brave new world ahead for IronRuby, what do you all think about the following ideas? 1) Move to GitHub - I won''t likely contribute if I have to use CodePlex. And I''d like to contribute. Can we do like the rest of Mono and make GitHub the central repository and source of all truth? Please? 2) Detach IronPython - Looking through the code, it seems that IronPython is in the same repo. I''m sure this is a holdover of how Microsoft had everything organized. And I''m sure it made sense then, but I don''t think it makes sense now. I''d like to work on IronRuby, and I honestly don''t care about having to check IronPython. Now that the DLR API is fixed, and there is no longer one Microsoft group in charge of both projects, can we move these into separate repos? 3) Detach from Visual Studio - I''m not on Windows, and I won''t be using Visual Studio. I''d prefer everything to build with rake tasks on Windows and Mono. I assume things are the way they are right now because of Microsoft''s build process. And right now it does not seem possible for me to build without Visual Studio. What about devs who are using MonoDevelop? Or any of the more powerful text editors? I''m convinced this is a major hurdle to getting many of the other Rubyist language implementors involved. Assuming I am not alone on this, is it possible we can make this project reflect the realities of the majority of folks that would like to contribute? 4) Remove ancillary projects into their own repos - IronRuby.Rack should live in its own repo, IMO. So should the Visual Studio tools. This is similar to separating IronPython into its own repo, but it needs to go further. Are there any reasons this should not be done? What else do you guys think needs to change now that IronRuby is free from Microsoft''s processes? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101022/57218e61/attachment.html>
1) IronRuby is on github. I has been there for a while. There is no source code on CodePlex. The only CodePlex service we use is the bug tracker. 2) It is not a holdover. It makes a lot of sense actually for at least the following reasons: a) Some IronRuby tests test interop between these languages. So there is a direct dependency. When you debug issues in language interop you need to have IronPython source code as well to step thru and make sense of the interactions. b) DLR has two parts - the "inner ring" that shipped in .NET Framework 4.0 and the "outer ring", which hasn''t shipped. Although the outer ring is pretty stable there are still many improvements that can/should be done. Obviously when you change the DLR you should run tests for both languages so that you don''t break anything. Thus IronPython''s test suite in the repo is handy. Also, if you change public API in the outer ring you might need to change both IronPython and IronRuby. All of this could be done in stages across different repos and even source control systems, but that''s obviously much more complicated than having it just work. Is size of the repo really an issue? If not, what is? 3) It is absolutely possible to build without Visual Studio. On Mono you can build using xbuild. Sometimes Mono''s xbuild might have a bug but I can assure you that Mono guys are more than happy to fix it asap if it breaks IronRuby or IronPython builds. Doesn''t MonoDevelop support .csproj files? I have no experience with it, but I would assume it does. The only part of the repo that is Visual Studio specific is (not surprisingly) Visual Studio integration in the Tools directory. Building a separate rake build system is just a redundancy that is difficult to maintain. Trust me, we tried. The less duplication in the build infrastructure the better. 4) We have an installer builder in the MSI directory that builds the entire IronRuby.msi and IronPython.msi from command line. These installers include Visual Studio integration so it needs to be there. Of course we can come up with some sub-module structuring of the repo that allows you to make a local enlistment with VS and without VS. That might be the way to go. Though, again, why spend time on changing the infrastructure? Shouldn''t we focus on implementing features and fixing bugs instead? Does the size of the repo bother you? Be assured that me and Dino have spent a lot of time to make sure no unnecessary process (Microsoft''s or not) is needed when working on IronRuby and IronPython. There might be a few small things to clean up that were needed at Microsoft and are not needed now. I''ll be happy to make the changes. Two of them that I can think of right now are removing "LCA_RESTRICTED" and TFS bindings from the solutions. Other than that there is not much. Any ideas how to make the development easier on Windows, Linux or MacOS are indeed welcome. Just be aware there might be good reasons behind the current repo setup and virtually none of them would be Microsoft process requirements. I''ll be happy to explain them should you have any questions. Thanks, Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Mike Moore Sent: Friday, October 22, 2010 5:10 PM To: ironruby-core at rubyforge.org Subject: [Ironruby-core] Contributing? With a brave new world ahead for IronRuby, what do you all think about the following ideas? 1) Move to GitHub - I won''t likely contribute if I have to use CodePlex. And I''d like to contribute. Can we do like the rest of Mono and make GitHub the central repository and source of all truth? Please? 2) Detach IronPython - Looking through the code, it seems that IronPython is in the same repo. I''m sure this is a holdover of how Microsoft had everything organized. And I''m sure it made sense then, but I don''t think it makes sense now. I''d like to work on IronRuby, and I honestly don''t care about having to check IronPython. Now that the DLR API is fixed, and there is no longer one Microsoft group in charge of both projects, can we move these into separate repos? 3) Detach from Visual Studio - I''m not on Windows, and I won''t be using Visual Studio. I''d prefer everything to build with rake tasks on Windows and Mono. I assume things are the way they are right now because of Microsoft''s build process. And right now it does not seem possible for me to build without Visual Studio. What about devs who are using MonoDevelop? Or any of the more powerful text editors? I''m convinced this is a major hurdle to getting many of the other Rubyist language implementors involved. Assuming I am not alone on this, is it possible we can make this project reflect the realities of the majority of folks that would like to contribute? 4) Remove ancillary projects into their own repos - IronRuby.Rack should live in its own repo, IMO. So should the Visual Studio tools. This is similar to separating IronPython into its own repo, but it needs to go further. Are there any reasons this should not be done? What else do you guys think needs to change now that IronRuby is free from Microsoft''s processes? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101023/c99f41d3/attachment.html>
I would caution you against moving too far away from Microsoft Technology, lest you alienate Windows developers. 1. If this project is going to be owned by Mono, then it would be reasonable to move to GitHub. But to drop CodePlex just because you feel like being stubborn isn''t. 3. One of the biggest barriers for Windows developers who want to contribute to Mono is the project/build system. When looking at it for the first time it is really hard to just figure out where to start. And they certainly don''t want to go back to editing source files with notepad. So while being able to build without Visual Studio is important, be careful not to remove the VS/MSBuild option. Jonathan Allen On Fri, Oct 22, 2010 at 5:10 PM, Mike Moore <blowmage at gmail.com> wrote:> With a brave new world ahead for IronRuby, what do you all think about the > following ideas? > > 1) Move to GitHub - I won''t likely contribute if I have to use CodePlex. > And I''d like to contribute. Can we do like the rest of Mono and make GitHub > the central repository and source of all truth? Please? > > 2) Detach IronPython - Looking through the code, it seems that IronPython > is in the same repo. I''m sure this is a holdover of how Microsoft had > everything organized. And I''m sure it made sense then, but I don''t think it > makes sense now. I''d like to work on IronRuby, and I honestly don''t care > about having to check IronPython. Now that the DLR API is fixed, and there > is no longer one Microsoft group in charge of both projects, can we move > these into separate repos? > > 3) Detach from Visual Studio - I''m not on Windows, and I won''t be using > Visual Studio. I''d prefer everything to build with rake tasks on Windows and > Mono. I assume things are the way they are right now because of Microsoft''s > build process. And right now it does not seem possible for me to build > without Visual Studio. What about devs who are using MonoDevelop? Or any of > the more powerful text editors? I''m convinced this is a major hurdle to > getting many of the other Rubyist language implementors involved. Assuming I > am not alone on this, is it possible we can make this project reflect the > realities of the majority of folks that would like to contribute? > > 4) Remove ancillary projects into their own repos - IronRuby.Rack should > live in its own repo, IMO. So should the Visual Studio tools. This is > similar to separating IronPython into its own repo, but it needs to go > further. Are there any reasons this should not be done? > > What else do you guys think needs to change now that IronRuby is free from > Microsoft''s processes? > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-- Jonathan Allen 619-933-8527 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101022/e8baca08/attachment-0001.html>
A couple thoughts below: On Fri, Oct 22, 2010 at 8:10 PM, Mike Moore <blowmage at gmail.com> wrote:> With a brave new world ahead for IronRuby, what do you all think about the > following ideas? > 1) Move to GitHub - I won''t likely contribute if I have to use CodePlex. And > I''d like to contribute. Can we do like the rest of Mono and make GitHub the > central repository and source of all truth? Please?http://github.com/ironruby/ironruby My understanding is that Codeplex is used only for end user distribution and bug tracking> 3)?Detach?from Visual Studio - I''m not on Windows, and I won''t be using > Visual Studio. I''d prefer everything to build with rake tasks on Windows and > Mono. I assume things are the way they are right now because of Microsoft''s > build process. And right now it does not seem possible for me to build > without Visual Studio. What about devs who are using MonoDevelop? Or any of > the more powerful text editors? I''m convinced this is a major hurdle to > getting many of the other Rubyist language implementors involved. Assuming I > am not alone on this, is it possible we can make this project reflect the > realities of the majority of folks that would like to contribute?You can certainly build without VS, this has always been the case. All you need is msbuild or xbuild for the solution files, in the past there have been Rake files as part of the repo from very early on.. but they seem to have disappeared.. anyone know what happened? I''m taking a look now on building under mono on linux, it''s something me and Ivan were working on earlier in the year and this seems like a good time to revisit. -- Michael Letterle IronRuby MVP http://blog.prokrams.com
Along the lines of IronRuby on mono, a small change was required for now since Mono doesn''t implement one of the newer Monitor.TryEnter overloads, see my branch here: http://github.com/mletterle/ironruby/tree/linux compiles with: xbuild /property:TreatWarningsAsErrors=false /property:DefineConstants="DEBUG MONO" Ruby.csproj Working on getting IronRuby.Console compiled now... already ran into a casing issue >.< On Fri, Oct 22, 2010 at 9:02 PM, Jonathan Allen <grauenwolf at gmail.com> wrote:> I would caution you against moving too far away from Microsoft Technology, > lest you alienate Windows developers. > > 1. If this project is going to be owned by Mono, then it would be reasonable > to move to GitHub. But to drop CodePlex just because you feel like being > stubborn isn''t. > > 3. One of the biggest barriers for Windows developers who want to contribute > to Mono is the project/build system. When looking at it for the first time > it is really hard to just figure out where to start. And they certainly > don''t want to go back to editing source files with notepad. So while being > able to build without Visual Studio is important, be careful not to remove > the VS/MSBuild option. > > > Jonathan Allen > > On Fri, Oct 22, 2010 at 5:10 PM, Mike Moore <blowmage at gmail.com> wrote: >> >> With a brave new world ahead for IronRuby, what do you all think about the >> following ideas? >> 1) Move to GitHub - I won''t likely contribute if I have to use CodePlex. >> And I''d like to contribute. Can we do like the rest of Mono and make GitHub >> the central repository and source of all truth? Please? >> 2) Detach IronPython - Looking through the code, it seems that IronPython >> is in the same repo. I''m sure this is a holdover of how Microsoft had >> everything organized. And I''m sure it made sense then, but I don''t think it >> makes sense now. I''d like to work on IronRuby, and I honestly don''t care >> about having to check IronPython. Now that the DLR API is fixed, and there >> is no longer one Microsoft group in charge of both projects, can we move >> these into separate repos? >> 3)?Detach?from Visual Studio - I''m not on Windows, and I won''t be using >> Visual Studio. I''d prefer everything to build with rake tasks on Windows and >> Mono. I assume things are the way they are right now because of Microsoft''s >> build process. And right now it does not seem possible for me to build >> without Visual Studio. What about devs who are using MonoDevelop? Or any of >> the more powerful text editors? I''m convinced this is a major hurdle to >> getting many of the other Rubyist language implementors involved. Assuming I >> am not alone on this, is it possible we can make this project reflect the >> realities of the majority of folks that would like to contribute? >> 4) Remove ancillary projects into their own repos - IronRuby.Rack should >> live in its own repo, IMO. So should the Visual Studio tools. This is >> similar to separating IronPython into its own repo, but it needs to go >> further. Are there any reasons this should not be done? >> What else do you guys think needs to change now that IronRuby is free from >> Microsoft''s processes? >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> > > > > -- > Jonathan Allen > 619-933-8527 > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-- Michael Letterle IronRuby MVP http://blog.prokrams.com
On Fri, Oct 22, 2010 at 7:06 PM, Michael Letterle < michael.letterle at gmail.com> wrote:> > http://github.com/ironruby/ironruby > > My understanding is that Codeplex is used only for end user > distribution and bug tracking >Good to know. Last time I was paying attention this was not the case. The commits I''ve seen through twitter seemed to be syncing commits from Microsoft''s internal system out. I readily admin I am ignorant of the truth however. :) You can certainly build without VS, this has always been the case.> All you need is msbuild or xbuild for the solution files, in the past > there have been Rake files as part of the repo from very early on.. > but they seem to have disappeared.. anyone know what happened? > > I''m taking a look now on building under mono on linux, it''s something > me and Ivan were working on earlier in the year and this seems like a > good time to revisit. >Excellent. I''d prefer to have rake be the official way to test and build, since that is what every other Ruby project I work on does. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101022/7c65a022/attachment.html>
On Fri, Oct 22, 2010 at 6:59 PM, Tomas Matousek < Tomas.Matousek at microsoft.com> wrote:> 2) It is not a holdover. It makes a lot of sense actually for at least > the following reasons: > > a) Some IronRuby tests test interop between these languages. So there is a > direct dependency. When you debug issues in language interop you need to > have IronPython source code as well to step thru and make sense of the > interactions. >I don''t understand why the code needs to exist within the same git repo for this then. Can you not have a Visual Studio solution that includes multiple projects with their own repository? Can''t you have your automated build system pull both the IronRuby and IronPython projects to run the integration tests?> b) DLR has two parts ? the ?inner ring? that shipped in .NET Framework > 4.0 and the ?outer ring?, which hasn?t shipped. Although the outer ring is > pretty stable there are still many improvements that can/should be done. > Obviously when you change the DLR you should run tests for both languages so > that you don?t break anything. Thus IronPython?s test suite in the repo is > handy. Also, if you change public API in the outer ring you might need to > change both IronPython and IronRuby. All of this could be done in stages > across different repos and even source control systems, but that?s obviously > much more complicated than having it just work. >I assumed the DLR was fixed. If that is not the case then shouldn''t the DLR should be its own separate git repo as well? Is size of the repo really an issue? If not, what is?>No, its not the size of the repo, rather the amount of tangental code. As someone who hasn''t looked at the code for well over a year, I am struck by the amount of orthogonal concerns that are front and center. I find it too busy and off-putting as a developer looking to become familiar with the code or make a small contribution. I don''t doubt there aren''t reasons it is the way it is, just that it can be better if you want to really open the floodgates of contributions. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101022/8f538cfa/attachment.html>
On Fri, Oct 22, 2010 at 7:02 PM, Jonathan Allen <grauenwolf at gmail.com>wrote:> I would caution you against moving too far away from Microsoft Technology, > lest you alienate Windows developers. >I don''t think Windows developers could be anymore alienated from IronRuby.> 1. If this project is going to be owned by Mono, then it would be > reasonable to move to GitHub. But to drop CodePlex just because you feel > like being stubborn isn''t. >Dropping CodePlex because it requires some Uber Visual Studio product to access the code repo and make code contributions is reasonable, and not some emotional reaction. Gladly this doesn''t seem to be the case anymore. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101022/196ac9db/attachment.html>
The Rake files were deleted because they were hard to maintain and redundant. -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle Sent: Friday, October 22, 2010 6:07 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Contributing? A couple thoughts below: On Fri, Oct 22, 2010 at 8:10 PM, Mike Moore <blowmage at gmail.com> wrote:> With a brave new world ahead for IronRuby, what do you all think about > the following ideas? > 1) Move to GitHub - I won''t likely contribute if I have to use > CodePlex. And I''d like to contribute. Can we do like the rest of Mono > and make GitHub the central repository and source of all truth? Please?http://github.com/ironruby/ironruby My understanding is that Codeplex is used only for end user distribution and bug tracking> 3)?Detach?from Visual Studio - I''m not on Windows, and I won''t be > using Visual Studio. I''d prefer everything to build with rake tasks on > Windows and Mono. I assume things are the way they are right now > because of Microsoft''s build process. And right now it does not seem > possible for me to build without Visual Studio. What about devs who > are using MonoDevelop? Or any of the more powerful text editors? I''m > convinced this is a major hurdle to getting many of the other Rubyist > language implementors involved. Assuming I am not alone on this, is it > possible we can make this project reflect the realities of the majority of folks that would like to contribute?You can certainly build without VS, this has always been the case. All you need is msbuild or xbuild for the solution files, in the past there have been Rake files as part of the repo from very early on.. but they seem to have disappeared.. anyone know what happened? I''m taking a look now on building under mono on linux, it''s something me and Ivan were working on earlier in the year and this seems like a good time to revisit. -- Michael Letterle IronRuby MVP http://blog.prokrams.com _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
>> 1. If this project is going to be owned by Mono, then it would be >> reasonable to move to GitHub. But to drop CodePlex just because you feel >> like being stubborn isn''t. > > Dropping CodePlex because it requires some Uber Visual Studio product to > access the code repo and make code contributions is reasonable, and not some > emotional reaction. Gladly this doesn''t seem to be the case anymore. > _______________________________________________Uh.. you know it doesn''t, right? Codeplex supports SVN and Mercurial and there are free TFS tools available in any case. http://codeplex.codeplex.com/wikipage?title=Source%20Control&version=1 -- Michael Letterle IronRuby MVP http://blog.prokrams.com
On Oct 22, 2010, at 10:13 PM, Michael Letterle <michael.letterle at gmail.com> wrote:> Uh.. you know it doesn''t, right?Obviously I don''t. :)
On Oct 22, 2010, at 10:00 PM, Jim Deville <jdeville at microsoft.com> wrote:> The Rake files were deleted because they were hard to maintain and redundant.Not all of them. http://github.com/ironruby/ironruby/blob/master/Rakefile
> Dropping CodePlex because it requires some Uber Visual Studio product toaccess the code repo and make code contributions is reasonable, and not some emotional reaction. While academic at this point, I would like to reiterate that you don''t need Visual Studio for CodePlex, Subversion works just fine. In fact, Subversion is preferred over VS because it allows anonymous access the source control repository while VS requires at least developer status on the project. Jonathan On Fri, Oct 22, 2010 at 8:27 PM, Mike Moore <blowmage at gmail.com> wrote:> On Fri, Oct 22, 2010 at 7:02 PM, Jonathan Allen <grauenwolf at gmail.com>wrote: > >> I would caution you against moving too far away from Microsoft Technology, >> lest you alienate Windows developers. >> > > I don''t think Windows developers could be anymore alienated from IronRuby. > > >> 1. If this project is going to be owned by Mono, then it would be >> reasonable to move to GitHub. But to drop CodePlex just because you feel >> like being stubborn isn''t. >> > > Dropping CodePlex because it requires some Uber Visual Studio product to > access the code repo and make code contributions is reasonable, and not some > emotional reaction. Gladly this doesn''t seem to be the case anymore. > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-- Jonathan Allen 619-933-8527 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101022/785a5a89/attachment.html>
On Oct 22, 2010, at 8:27 PM, Mike Moore <blowmage at gmail.com> wrote:> > Dropping CodePlex because it requires some Uber Visual Studio product to access the code repo and make code contributions is reasonable, and not some emotional reaction. Gladly this doesn''t seem to be the case anymore.Or, has never been the case. I''ve used vim and mono on some pieces before, so the new arrangement doesn''t change anything except allow us to contribute directly to parts of the codebase we couldn''t before. :) Ryan
Jim, Jimmy, Tomas, and Miguel: Shri used to offer pair programming sessions to people interested in helping out with the project. I know at least a few participated, and I found it really helpful. Is there any chance of starting this up again? I don''t mean for you to necessarily be the ones to do it, but you might know some food candidates. This might help onboard people like Mike who are interested but unsure where to begin. Ryan Sent from my iPhone On Oct 22, 2010, at 8:26 PM, Mike Moore <blowmage at gmail.com> wrote:> On Fri, Oct 22, 2010 at 6:59 PM, Tomas Matousek <Tomas.Matousek at microsoft.com> wrote: > 2) It is not a holdover. It makes a lot of sense actually for at least the following reasons: > > a) Some IronRuby tests test interop between these languages. So there is a direct dependency. When you debug issues in language interop you need to have IronPython source code as well to step thru and make sense of the interactions. > > > I don''t understand why the code needs to exist within the same git repo for this then. Can you not have a Visual Studio solution that includes multiple projects with their own repository? Can''t you have your automated build system pull both the IronRuby and IronPython projects to run the integration tests? > > > b) DLR has two parts ? the ?inner ring? that shipped in .NET Framework 4.0 and the ?outer ring?, which hasn?t shipped. Although the outer ring is pretty stable there are still many improvements that can/should be done. Obviously when you change the DLR you should run tests for both languages so that you don?t break anything. Thus IronPython?s test suite in the repo is handy. Also, if you change public API in the outer ring you might need to change both IronPython and IronRuby. All of this could be done in stages across different repos and even source control systems, but that?s obviously much more complicated than having it just work. > > > I assumed the DLR was fixed. If that is not the case then shouldn''t the DLR should be its own separate git repo as well? > > Is size of the repo really an issue? If not, what is? > > > No, its not the size of the repo, rather the amount of tangental code. As someone who hasn''t looked at the code for well over a year, I am struck by the amount of orthogonal concerns that are front and center. I find it too busy and off-putting as a developer looking to become familiar with the code or make a small contribution. I don''t doubt there aren''t reasons it is the way it is, just that it can be better if you want to really open the floodgates of contributions. > _______________________________________________ > 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/20101022/5ee7b9b2/attachment.html>
What do you need the "DEBUG MONO" constant for? The default "Debug" configuration doesn''t work? What version of Mono do you use? I think 2.8 should be the target for IronRUby. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle Sent: Friday, October 22, 2010 8:02 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Contributing? Along the lines of IronRuby on mono, a small change was required for now since Mono doesn''t implement one of the newer Monitor.TryEnter overloads, see my branch here: http://github.com/mletterle/ironruby/tree/linux compiles with: xbuild /property:TreatWarningsAsErrors=false /property:DefineConstants="DEBUG MONO" Ruby.csproj Working on getting IronRuby.Console compiled now... already ran into a casing issue >.< On Fri, Oct 22, 2010 at 9:02 PM, Jonathan Allen <grauenwolf at gmail.com> wrote:> I would caution you against moving too far away from Microsoft > Technology, lest you alienate Windows developers. > > 1. If this project is going to be owned by Mono, then it would be > reasonable to move to GitHub. But to drop CodePlex just because you > feel like being stubborn isn''t. > > 3. One of the biggest barriers for Windows developers who want to > contribute to Mono is the project/build system. When looking at it for > the first time it is really hard to just figure out where to start. > And they certainly don''t want to go back to editing source files with > notepad. So while being able to build without Visual Studio is > important, be careful not to remove the VS/MSBuild option. > > > Jonathan Allen > > On Fri, Oct 22, 2010 at 5:10 PM, Mike Moore <blowmage at gmail.com> wrote: >> >> With a brave new world ahead for IronRuby, what do you all think >> about the following ideas? >> 1) Move to GitHub - I won''t likely contribute if I have to use CodePlex. >> And I''d like to contribute. Can we do like the rest of Mono and make >> GitHub the central repository and source of all truth? Please? >> 2) Detach IronPython - Looking through the code, it seems that >> IronPython is in the same repo. I''m sure this is a holdover of how >> Microsoft had everything organized. And I''m sure it made sense then, >> but I don''t think it makes sense now. I''d like to work on IronRuby, >> and I honestly don''t care about having to check IronPython. Now that >> the DLR API is fixed, and there is no longer one Microsoft group in >> charge of both projects, can we move these into separate repos? >> 3)?Detach?from Visual Studio - I''m not on Windows, and I won''t be >> using Visual Studio. I''d prefer everything to build with rake tasks >> on Windows and Mono. I assume things are the way they are right now >> because of Microsoft''s build process. And right now it does not seem >> possible for me to build without Visual Studio. What about devs who >> are using MonoDevelop? Or any of the more powerful text editors? I''m >> convinced this is a major hurdle to getting many of the other Rubyist >> language implementors involved. Assuming I am not alone on this, is >> it possible we can make this project reflect the realities of the majority of folks that would like to contribute? >> 4) Remove ancillary projects into their own repos - IronRuby.Rack >> should live in its own repo, IMO. So should the Visual Studio tools. >> This is similar to separating IronPython into its own repo, but it >> needs to go further. Are there any reasons this should not be done? >> What else do you guys think needs to change now that IronRuby is free >> from Microsoft''s processes? >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> > > > > -- > Jonathan Allen > 619-933-8527 > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-- Michael Letterle IronRuby MVP http://blog.prokrams.com _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
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. 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 :). 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. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Mike Moore Sent: Friday, October 22, 2010 8:27 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Contributing? On Fri, Oct 22, 2010 at 6:59 PM, Tomas Matousek <Tomas.Matousek at microsoft.com<mailto:Tomas.Matousek at microsoft.com>> wrote: 2) It is not a holdover. It makes a lot of sense actually for at least the following reasons: a) Some IronRuby tests test interop between these languages. So there is a direct dependency. When you debug issues in language interop you need to have IronPython source code as well to step thru and make sense of the interactions. I don''t understand why the code needs to exist within the same git repo for this then. Can you not have a Visual Studio solution that includes multiple projects with their own repository? Can''t you have your automated build system pull both the IronRuby and IronPython projects to run the integration tests? b) DLR has two parts - the "inner ring" that shipped in .NET Framework 4.0 and the "outer ring", which hasn''t shipped. Although the outer ring is pretty stable there are still many improvements that can/should be done. Obviously when you change the DLR you should run tests for both languages so that you don''t break anything. Thus IronPython''s test suite in the repo is handy. Also, if you change public API in the outer ring you might need to change both IronPython and IronRuby. All of this could be done in stages across different repos and even source control systems, but that''s obviously much more complicated than having it just work. I assumed the DLR was fixed. If that is not the case then shouldn''t the DLR should be its own separate git repo as well? Is size of the repo really an issue? If not, what is? No, its not the size of the repo, rather the amount of tangental code. As someone who hasn''t looked at the code for well over a year, I am struck by the amount of orthogonal concerns that are front and center. I find it too busy and off-putting as a developer looking to become familiar with the code or make a small contribution. I don''t doubt there aren''t reasons it is the way it is, just that it can be better if you want to really open the floodgates of contributions. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101023/fbbdab3e/attachment-0001.html>
Well, it''s just the DEBUG constant and a MONO constant. I''m building with mono trunk, I added the MONO to the ifdef to use the Monitor.TryEnter(object) overload that is also used for CLR2. I couldn''t just use the CLR2 constant because that broke everything else. I''m going to look into adding the Monitor.TryEnter(object, bool) overloads to mono proper so this is just temporary. On Sat, Oct 23, 2010 at 3:19 AM, Tomas Matousek <Tomas.Matousek at microsoft.com> wrote:> What do you need the "DEBUG MONO" constant for? The default "Debug" configuration doesn''t work? > > What version of Mono do you use? I think 2.8 should be the target for IronRUby. > > Tomas > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle > Sent: Friday, October 22, 2010 8:02 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Contributing? > > Along the lines of IronRuby on mono, a small change was required for now since Mono doesn''t implement one of the newer Monitor.TryEnter overloads, see my branch here: > http://github.com/mletterle/ironruby/tree/linux > > compiles with: > > xbuild /property:TreatWarningsAsErrors=false > /property:DefineConstants="DEBUG MONO" Ruby.csproj > > Working on getting IronRuby.Console compiled now... already ran into a casing issue >.< > > On Fri, Oct 22, 2010 at 9:02 PM, Jonathan Allen <grauenwolf at gmail.com> wrote: >> I would caution you against moving too far away from Microsoft >> Technology, lest you alienate Windows developers. >> >> 1. If this project is going to be owned by Mono, then it would be >> reasonable to move to GitHub. But to drop CodePlex just because you >> feel like being stubborn isn''t. >> >> 3. One of the biggest barriers for Windows developers who want to >> contribute to Mono is the project/build system. When looking at it for >> the first time it is really hard to just figure out where to start. >> And they certainly don''t want to go back to editing source files with >> notepad. So while being able to build without Visual Studio is >> important, be careful not to remove the VS/MSBuild option. >> >> >> Jonathan Allen >> >> On Fri, Oct 22, 2010 at 5:10 PM, Mike Moore <blowmage at gmail.com> wrote: >>> >>> With a brave new world ahead for IronRuby, what do you all think >>> about the following ideas? >>> 1) Move to GitHub - I won''t likely contribute if I have to use CodePlex. >>> And I''d like to contribute. Can we do like the rest of Mono and make >>> GitHub the central repository and source of all truth? Please? >>> 2) Detach IronPython - Looking through the code, it seems that >>> IronPython is in the same repo. I''m sure this is a holdover of how >>> Microsoft had everything organized. And I''m sure it made sense then, >>> but I don''t think it makes sense now. I''d like to work on IronRuby, >>> and I honestly don''t care about having to check IronPython. Now that >>> the DLR API is fixed, and there is no longer one Microsoft group in >>> charge of both projects, can we move these into separate repos? >>> 3)?Detach?from Visual Studio - I''m not on Windows, and I won''t be >>> using Visual Studio. I''d prefer everything to build with rake tasks >>> on Windows and Mono. I assume things are the way they are right now >>> because of Microsoft''s build process. And right now it does not seem >>> possible for me to build without Visual Studio. What about devs who >>> are using MonoDevelop? Or any of the more powerful text editors? I''m >>> convinced this is a major hurdle to getting many of the other Rubyist >>> language implementors involved. Assuming I am not alone on this, is >>> it possible we can make this project reflect the realities of the majority of folks that would like to contribute? >>> 4) Remove ancillary projects into their own repos - IronRuby.Rack >>> should live in its own repo, IMO. So should the Visual Studio tools. >>> This is similar to separating IronPython into its own repo, but it >>> needs to go further. Are there any reasons this should not be done? >>> What else do you guys think needs to change now that IronRuby is free >>> from Microsoft''s processes? >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >> >> >> >> -- >> Jonathan Allen >> 619-933-8527 >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> > > > > -- > Michael Letterle > IronRuby MVP > http://blog.prokrams.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 >-- Michael Letterle IronRuby MVP http://blog.prokrams.com
On Oct 23, 2010, at 1:30 AM, Tomas Matousek <Tomas.Matousek at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101023/9be54d84/attachment.html>
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: blowmage at gmail.com Date: Sat, 23 Oct 2010 06:44:16 -0600 To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Contributing? On Oct 23, 2010, at 1:30 AM, Tomas Matousek <Tomas.Matousek at 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 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/20101023/bebcdc36/attachment-0001.html>
mletterle at michael2:~/src/ironruby/Languages/Ruby/bin/Debug$ mono ir64.exe IronRuby 1.1.1.0 on 2.8.1 (master/e8a3aab Fri Oct 22 22:15:50 EDT 2010) Copyright (c) Microsoft Corporation. All rights reserved.>>> print RUBY_PLATFORMi386-linux>>>>>> [1,2,3,4].reverse.each{|x| print "Hello! #{x}"}=> nil Hello! 4Hello! 3Hello! 2Hello! 1=> [4, 3, 2, 1]>>> Mono didn''t like how some stuff was done in Enumerable.cs, but a slight refactoring (eliminate gotos, move an anonymous method out of a method argument) did the trick. Working on running the tests now. Changes are here: http://github.com/mletterle/ironruby/tree/linux On Sat, Oct 23, 2010 at 7:02 AM, Michael Letterle <michael.letterle at gmail.com> wrote:> Well, it''s just the DEBUG constant and a MONO constant. > > I''m building with mono trunk, I added the MONO to the ifdef to use the > Monitor.TryEnter(object) overload that is also used for CLR2. ?I > couldn''t just use ?the CLR2 constant because that broke everything > else. ?I''m going to look into adding the Monitor.TryEnter(object, > bool) overloads to mono proper so this is just temporary. > > > > On Sat, Oct 23, 2010 at 3:19 AM, Tomas Matousek > <Tomas.Matousek at microsoft.com> wrote: >> What do you need the "DEBUG MONO" constant for? The default "Debug" configuration doesn''t work? >> >> What version of Mono do you use? I think 2.8 should be the target for IronRUby. >> >> Tomas >> >> -----Original Message----- >> From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle >> Sent: Friday, October 22, 2010 8:02 PM >> To: ironruby-core at rubyforge.org >> Subject: Re: [Ironruby-core] Contributing? >> >> Along the lines of IronRuby on mono, a small change was required for now since Mono doesn''t implement one of the newer Monitor.TryEnter overloads, see my branch here: >> http://github.com/mletterle/ironruby/tree/linux >> >> compiles with: >> >> xbuild /property:TreatWarningsAsErrors=false >> /property:DefineConstants="DEBUG MONO" Ruby.csproj >> >> Working on getting IronRuby.Console compiled now... already ran into a casing issue >.< >> >> On Fri, Oct 22, 2010 at 9:02 PM, Jonathan Allen <grauenwolf at gmail.com> wrote: >>> I would caution you against moving too far away from Microsoft >>> Technology, lest you alienate Windows developers. >>> >>> 1. If this project is going to be owned by Mono, then it would be >>> reasonable to move to GitHub. But to drop CodePlex just because you >>> feel like being stubborn isn''t. >>> >>> 3. One of the biggest barriers for Windows developers who want to >>> contribute to Mono is the project/build system. When looking at it for >>> the first time it is really hard to just figure out where to start. >>> And they certainly don''t want to go back to editing source files with >>> notepad. So while being able to build without Visual Studio is >>> important, be careful not to remove the VS/MSBuild option. >>> >>> >>> Jonathan Allen >>> >>> On Fri, Oct 22, 2010 at 5:10 PM, Mike Moore <blowmage at gmail.com> wrote: >>>> >>>> With a brave new world ahead for IronRuby, what do you all think >>>> about the following ideas? >>>> 1) Move to GitHub - I won''t likely contribute if I have to use CodePlex. >>>> And I''d like to contribute. Can we do like the rest of Mono and make >>>> GitHub the central repository and source of all truth? Please? >>>> 2) Detach IronPython - Looking through the code, it seems that >>>> IronPython is in the same repo. I''m sure this is a holdover of how >>>> Microsoft had everything organized. And I''m sure it made sense then, >>>> but I don''t think it makes sense now. I''d like to work on IronRuby, >>>> and I honestly don''t care about having to check IronPython. Now that >>>> the DLR API is fixed, and there is no longer one Microsoft group in >>>> charge of both projects, can we move these into separate repos? >>>> 3)?Detach?from Visual Studio - I''m not on Windows, and I won''t be >>>> using Visual Studio. I''d prefer everything to build with rake tasks >>>> on Windows and Mono. I assume things are the way they are right now >>>> because of Microsoft''s build process. And right now it does not seem >>>> possible for me to build without Visual Studio. What about devs who >>>> are using MonoDevelop? Or any of the more powerful text editors? I''m >>>> convinced this is a major hurdle to getting many of the other Rubyist >>>> language implementors involved. Assuming I am not alone on this, is >>>> it possible we can make this project reflect the realities of the majority of folks that would like to contribute? >>>> 4) Remove ancillary projects into their own repos - IronRuby.Rack >>>> should live in its own repo, IMO. So should the Visual Studio tools. >>>> This is similar to separating IronPython into its own repo, but it >>>> needs to go further. Are there any reasons this should not be done? >>>> What else do you guys think needs to change now that IronRuby is free >>>> from Microsoft''s processes? >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>> >>> >>> >>> -- >>> Jonathan Allen >>> 619-933-8527 >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >> >> >> >> -- >> Michael Letterle >> IronRuby MVP >> http://blog.prokrams.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 >> > > > > -- > Michael Letterle > IronRuby MVP > http://blog.prokrams.com >-- Michael Letterle IronRuby MVP http://blog.prokrams.com
I see. "DEBUG" seems to be redundant since it''s set by the default Debug configuration in the project files. Strange, I think I tried running IronRuby on Mono 2.8 and most of it worked. If TryEnter implementation was missing something should have failed. But this was compiled using our compiler not Mono''s. So maybe the problem is just at build time? We should work with JB to get any issues fixed. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle Sent: Saturday, October 23, 2010 4:03 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Contributing? Well, it''s just the DEBUG constant and a MONO constant. I''m building with mono trunk, I added the MONO to the ifdef to use the Monitor.TryEnter(object) overload that is also used for CLR2. I couldn''t just use the CLR2 constant because that broke everything else. I''m going to look into adding the Monitor.TryEnter(object, bool) overloads to mono proper so this is just temporary. On Sat, Oct 23, 2010 at 3:19 AM, Tomas Matousek <Tomas.Matousek at microsoft.com> wrote:> What do you need the "DEBUG MONO" constant for? The default "Debug" configuration doesn''t work? > > What version of Mono do you use? I think 2.8 should be the target for IronRUby. > > Tomas > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org > [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael > Letterle > Sent: Friday, October 22, 2010 8:02 PM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Contributing? > > Along the lines of IronRuby on mono, a small change was required for now since Mono doesn''t implement one of the newer Monitor.TryEnter overloads, see my branch here: > http://github.com/mletterle/ironruby/tree/linux > > compiles with: > > xbuild /property:TreatWarningsAsErrors=false > /property:DefineConstants="DEBUG MONO" Ruby.csproj > > Working on getting IronRuby.Console compiled now... already ran into a > casing issue >.< > > On Fri, Oct 22, 2010 at 9:02 PM, Jonathan Allen <grauenwolf at gmail.com> wrote: >> I would caution you against moving too far away from Microsoft >> Technology, lest you alienate Windows developers. >> >> 1. If this project is going to be owned by Mono, then it would be >> reasonable to move to GitHub. But to drop CodePlex just because you >> feel like being stubborn isn''t. >> >> 3. One of the biggest barriers for Windows developers who want to >> contribute to Mono is the project/build system. When looking at it >> for the first time it is really hard to just figure out where to start. >> And they certainly don''t want to go back to editing source files with >> notepad. So while being able to build without Visual Studio is >> important, be careful not to remove the VS/MSBuild option. >> >> >> Jonathan Allen >> >> On Fri, Oct 22, 2010 at 5:10 PM, Mike Moore <blowmage at gmail.com> wrote: >>> >>> With a brave new world ahead for IronRuby, what do you all think >>> about the following ideas? >>> 1) Move to GitHub - I won''t likely contribute if I have to use CodePlex. >>> And I''d like to contribute. Can we do like the rest of Mono and make >>> GitHub the central repository and source of all truth? Please? >>> 2) Detach IronPython - Looking through the code, it seems that >>> IronPython is in the same repo. I''m sure this is a holdover of how >>> Microsoft had everything organized. And I''m sure it made sense then, >>> but I don''t think it makes sense now. I''d like to work on IronRuby, >>> and I honestly don''t care about having to check IronPython. Now that >>> the DLR API is fixed, and there is no longer one Microsoft group in >>> charge of both projects, can we move these into separate repos? >>> 3)?Detach?from Visual Studio - I''m not on Windows, and I won''t be >>> using Visual Studio. I''d prefer everything to build with rake tasks >>> on Windows and Mono. I assume things are the way they are right now >>> because of Microsoft''s build process. And right now it does not seem >>> possible for me to build without Visual Studio. What about devs who >>> are using MonoDevelop? Or any of the more powerful text editors? I''m >>> convinced this is a major hurdle to getting many of the other >>> Rubyist language implementors involved. Assuming I am not alone on >>> this, is it possible we can make this project reflect the realities of the majority of folks that would like to contribute? >>> 4) Remove ancillary projects into their own repos - IronRuby.Rack >>> should live in its own repo, IMO. So should the Visual Studio tools. >>> This is similar to separating IronPython into its own repo, but it >>> needs to go further. Are there any reasons this should not be done? >>> What else do you guys think needs to change now that IronRuby is >>> free from Microsoft''s processes? >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >> >> >> >> -- >> Jonathan Allen >> 619-933-8527 >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> > > > > -- > Michael Letterle > IronRuby MVP > http://blog.prokrams.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 >-- Michael Letterle IronRuby MVP http://blog.prokrams.com _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
On Sat, Oct 23, 2010 at 5:44 AM, Mike Moore <blowmage at gmail.com> wrote:> On Oct 23, 2010, at 1:30 AM, Tomas Matousek <<Tomas.Matousek at microsoft.com> > Tomas.Matousek at 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. >And you are speaking like someone who has tried hard several times to contribute to IronRuby and failed because of a bloated project structure. I''m sure there are several people who would be willing to help you figure out what''s wrong. Where''s the repo with your contribution?> 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... >Ah yes, and if only github had something like forking ...> > 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. >If you want to create and maintain these, I''m sure no one would complain. I don''t understand the push back to the idea that the three core contributors were a little tired of building IronRuby and maintaining two build approaches. I also don''t understand a Rubyist''s failure to see an opportunity to contribute rake tasks to a project.> 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? >IronPython already has a separate repo at http://ironpython.codeplex.com/.> 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. >Great! Fork the project and show everyone! Sorry for the tone. If you were intending to come across differently, it would help offer help and not critique the great work Tomas and the rest have done. Try working on the project. Ask for help. You''ll receive it readily. You may even find some people to help you restructure the project. If it works better, I''m sure you''ll get support for moving the project to that structure. Just don''t demand "your way right away" when you haven''t contributed and don''t understand the history. It''s not your project yet. Get involved and make it yours. Ryan Riley Email: ryan.riley at panesofglass.org LinkedIn: http://www.linkedin.com/in/ryanriley Twitter: @panesofglass Blog: http://wizardsofsmart.net/ Website: http://panesofglass.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101023/22df2cae/attachment.html>
Hey, On Sat, Oct 23, 2010 at 6:01 PM, Michael Letterle <michael.letterle at gmail.com> wrote:> Mono didn''t like how some stuff was done in Enumerable.cs, but a > slight refactoring (eliminate gotos, move an anonymous method out of a > method argument) did the trick. ?Working on running the tests now.When stumbling about cases like that, it would be really nice to extract repros and file bugs for Mono. Thanks! -- Jb Evain? <jb at nurv.fr>
I have to respecify DEBUG since I''m redefining the DefineConstants property. Running would have worked as long as you didn''t try to call that method :) On Sat, Oct 23, 2010 at 12:29 PM, Tomas Matousek <Tomas.Matousek at microsoft.com> wrote:> I see. "DEBUG" seems to be redundant since it''s set by the default Debug configuration in the project files. > Strange, I think I tried running IronRuby on Mono 2.8 and most of it worked. If TryEnter implementation was missing something should have failed. But this was compiled using our compiler not Mono''s. So maybe the problem is just at build time? > > We should work with JB to get any issues fixed. > > Tomas > > -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael Letterle > Sent: Saturday, October 23, 2010 4:03 AM > To: ironruby-core at rubyforge.org > Subject: Re: [Ironruby-core] Contributing? > > Well, it''s just the DEBUG constant and a MONO constant. > > I''m building with mono trunk, I added the MONO to the ifdef to use the > Monitor.TryEnter(object) overload that is also used for CLR2. ?I couldn''t just use ?the CLR2 constant because that broke everything else. ?I''m going to look into adding the Monitor.TryEnter(object, > bool) overloads to mono proper so this is just temporary. > > > > On Sat, Oct 23, 2010 at 3:19 AM, Tomas Matousek <Tomas.Matousek at microsoft.com> wrote: >> What do you need the "DEBUG MONO" constant for? The default "Debug" configuration doesn''t work? >> >> What version of Mono do you use? I think 2.8 should be the target for IronRUby. >> >> Tomas >> >> -----Original Message----- >> From: ironruby-core-bounces at rubyforge.org >> [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Michael >> Letterle >> Sent: Friday, October 22, 2010 8:02 PM >> To: ironruby-core at rubyforge.org >> Subject: Re: [Ironruby-core] Contributing? >> >> Along the lines of IronRuby on mono, a small change was required for now since Mono doesn''t implement one of the newer Monitor.TryEnter overloads, see my branch here: >> http://github.com/mletterle/ironruby/tree/linux >> >> compiles with: >> >> xbuild /property:TreatWarningsAsErrors=false >> /property:DefineConstants="DEBUG MONO" Ruby.csproj >> >> Working on getting IronRuby.Console compiled now... already ran into a >> casing issue >.< >> >> On Fri, Oct 22, 2010 at 9:02 PM, Jonathan Allen <grauenwolf at gmail.com> wrote: >>> I would caution you against moving too far away from Microsoft >>> Technology, lest you alienate Windows developers. >>> >>> 1. If this project is going to be owned by Mono, then it would be >>> reasonable to move to GitHub. But to drop CodePlex just because you >>> feel like being stubborn isn''t. >>> >>> 3. One of the biggest barriers for Windows developers who want to >>> contribute to Mono is the project/build system. When looking at it >>> for the first time it is really hard to just figure out where to start. >>> And they certainly don''t want to go back to editing source files with >>> notepad. So while being able to build without Visual Studio is >>> important, be careful not to remove the VS/MSBuild option. >>> >>> >>> Jonathan Allen >>> >>> On Fri, Oct 22, 2010 at 5:10 PM, Mike Moore <blowmage at gmail.com> wrote: >>>> >>>> With a brave new world ahead for IronRuby, what do you all think >>>> about the following ideas? >>>> 1) Move to GitHub - I won''t likely contribute if I have to use CodePlex. >>>> And I''d like to contribute. Can we do like the rest of Mono and make >>>> GitHub the central repository and source of all truth? Please? >>>> 2) Detach IronPython - Looking through the code, it seems that >>>> IronPython is in the same repo. I''m sure this is a holdover of how >>>> Microsoft had everything organized. And I''m sure it made sense then, >>>> but I don''t think it makes sense now. I''d like to work on IronRuby, >>>> and I honestly don''t care about having to check IronPython. Now that >>>> the DLR API is fixed, and there is no longer one Microsoft group in >>>> charge of both projects, can we move these into separate repos? >>>> 3)?Detach?from Visual Studio - I''m not on Windows, and I won''t be >>>> using Visual Studio. I''d prefer everything to build with rake tasks >>>> on Windows and Mono. I assume things are the way they are right now >>>> because of Microsoft''s build process. And right now it does not seem >>>> possible for me to build without Visual Studio. What about devs who >>>> are using MonoDevelop? Or any of the more powerful text editors? I''m >>>> convinced this is a major hurdle to getting many of the other >>>> Rubyist language implementors involved. Assuming I am not alone on >>>> this, is it possible we can make this project reflect the realities of the majority of folks that would like to contribute? >>>> 4) Remove ancillary projects into their own repos - IronRuby.Rack >>>> should live in its own repo, IMO. So should the Visual Studio tools. >>>> This is similar to separating IronPython into its own repo, but it >>>> needs to go further. Are there any reasons this should not be done? >>>> What else do you guys think needs to change now that IronRuby is >>>> free from Microsoft''s processes? >>>> _______________________________________________ >>>> Ironruby-core mailing list >>>> Ironruby-core at rubyforge.org >>>> http://rubyforge.org/mailman/listinfo/ironruby-core >>>> >>> >>> >>> >>> -- >>> Jonathan Allen >>> 619-933-8527 >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >>> >>> >> >> >> >> -- >> Michael Letterle >> IronRuby MVP >> http://blog.prokrams.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 >> > > > > -- > Michael Letterle > IronRuby MVP > http://blog.prokrams.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 >-- Michael Letterle IronRuby MVP http://blog.prokrams.com
Working on it actually... ;) Maybe, possibly, with a patch as well... (perhaps). On Sat, Oct 23, 2010 at 12:34 PM, Jb Evain <jb at nurv.fr> wrote:> Hey, > > On Sat, Oct 23, 2010 at 6:01 PM, Michael Letterle > <michael.letterle at gmail.com> wrote: >> Mono didn''t like how some stuff was done in Enumerable.cs, but a >> slight refactoring (eliminate gotos, move an anonymous method out of a >> method argument) did the trick. ?Working on running the tests now. > > When stumbling about cases like that, it would be really nice to > extract repros and file bugs for Mono. > > Thanks! > > -- > Jb Evain? <jb at nurv.fr> > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-- Michael Letterle IronRuby MVP http://blog.prokrams.com
I don''t want a confrontation, I was just trying to voice some concerns I have. If everyone is in agreement that the way things have been done is the best way they could have possibly been done, and that nothing should be changed now that the project owners and the rules for making contributions are fundamentally different, then by all means continue. On Sat, Oct 23, 2010 at 10:32 AM, Ryan Riley <ryan.riley at panesofglass.org>wrote:> On Sat, Oct 23, 2010 at 5:44 AM, Mike Moore <blowmage at gmail.com> wrote: > >> On Oct 23, 2010, at 1:30 AM, Tomas Matousek <<Tomas.Matousek at microsoft.com> >> Tomas.Matousek at 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. >> > > And you are speaking like someone who has tried hard several times to > contribute to IronRuby and failed because of a bloated project structure. > I''m sure there are several people who would be willing to help you figure > out what''s wrong. Where''s the repo with your contribution? >I don''t understand. Is this some sort of challenge?> 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... >> > > Ah yes, and if only github had something like forking ... >I don''t think changing the structure in forked repos would do anyone any good, as it would make sharing contributions between repos difficult.> 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. >> > > If you want to create and maintain these, I''m sure no one would complain. I > don''t understand the push back to the idea that the three core contributors > were a little tired of building IronRuby and maintaining two build > approaches. I also don''t understand a Rubyist''s failure to see an > opportunity to contribute rake tasks to a project. >I think you are confused to where I am puzzled about resistance. It is not about having rake tasks. I agree that they are easy enough to add and maintain, and that whining about them would be quite ridiculous. That''s not my point, however. My point is that there would be more contributions if it were not a single monolithic repository. I also think most of the historic benefits of having a monolithic repo can be mitigated with submodules and an automated build and integration server. Feel free to disagree. 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? >> > > IronPython already has a separate repo at http://ironpython.codeplex.com/ > . >I dunno, it looks really, really similar to the IronRuby repo on GitHub to me. Is this synched with the GitHub repo? Is this where all the "Project Merlin" changes are coming from? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101023/ba4920da/attachment-0001.html>
FWIW having separate IronRuby, IronPython, and Common repos that are sub moduled(is that a word?) would make sense, that way changes that are done in Common by both people working on Ruby and Python are easily shared.. the current configuration feels.. fragile. Perhaps the BEST thing to do is to layout what a more reasonable structure could look like in concrete terms rather then just complaining about the current setup. The repo in general needs some love though, build instructions should be in the README, and the current layout could use some explanations, some files that seem to be needed are incorrect or in places different than project files expect (specifically thinking of App.config here) I think the fundamental problem is the current repo was never really put together with the idea of someone coming in blind to it.. the only way to change that is to.. well start changing it. :) On the subject of the rake tasks, when the rake files were originally there xbuild was nowhere near the state it is now, and it WAS a pain to maintain, especially across platforms, we probably should have some linux scripts to call xbuild though. The most important thing, in my opinion, is that these discussions are now occurring. On Sat, Oct 23, 2010 at 7:09 PM, Mike Moore <blowmage at gmail.com> wrote:> I don''t want a confrontation, I was just trying to voice some concerns I > have. If everyone is in agreement that the way things have been done is the > best way they could have possibly been done, and that nothing should be > changed now that the project owners and the rules for making contributions > are fundamentally different, then by all means continue. > > On Sat, Oct 23, 2010 at 10:32 AM, Ryan Riley <ryan.riley at panesofglass.org> > wrote: >> >> On Sat, Oct 23, 2010 at 5:44 AM, Mike Moore <blowmage at gmail.com> wrote: >>> >>> On Oct 23, 2010, at 1:30 AM, Tomas Matousek >>> <Tomas.Matousek at 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. >> >> And you are speaking like someone who has tried hard several times to >> contribute to IronRuby and failed because of a bloated project structure. >> I''m sure there are several people who would be willing to help you figure >> out what''s wrong. Where''s the repo with your contribution? > > I don''t understand. Is this some sort of challenge? > >>> >>> 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... >> >> Ah yes, and if only github had something like forking ... > > I don''t think changing the structure in forked repos would do anyone any > good, as it would make sharing contributions between repos difficult. > >>> >>> 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. >> >> If you want to create and maintain these, I''m sure no one would complain. >> I don''t understand the push back to the idea that the three core >> contributors were a little tired of building IronRuby and maintaining two >> build approaches. I also don''t understand a Rubyist''s failure to see an >> opportunity to contribute rake tasks to a project. > > I think you are confused to where I am puzzled about resistance. It is not > about having rake tasks. I agree that they are easy enough to add and > maintain, and that whining about them would be quite ridiculous. That''s not > my point, however.?My point is that there would be more contributions if it > were not a single monolithic repository. I also think most of the historic > benefits of having a monolithic repo can be mitigated with submodules and an > automated build and integration server. > Feel free to disagree. >>> >>> 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? >> >> IronPython already has a separate repo at >> http://ironpython.codeplex.com/. > > I dunno, it looks really, really similar to the IronRuby repo on GitHub to > me. Is this synched with the GitHub repo? Is this where all the "Project > Merlin" changes are coming from? > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-- Michael Letterle IronRuby MVP http://blog.prokrams.com
On Sat, Oct 23, 2010 at 4:09 PM, Mike Moore <blowmage at gmail.com> wrote:> I don''t want a confrontation, I was just trying to voice some concerns I > have. If everyone is in agreement that the way things have been done is the > best way they could have possibly been done, and that nothing should be > changed now that the project owners and the rules for making contributions > are fundamentally different, then by all means continue. > > On Sat, Oct 23, 2010 at 10:32 AM, Ryan Riley <ryan.riley at panesofglass.org>wrote: > >> On Sat, Oct 23, 2010 at 5:44 AM, Mike Moore <blowmage at gmail.com> wrote: >>> >>> You are speaking like someone responsible for both languages and the DLR. >>> >> >> And you are speaking like someone who has tried hard several times to >> contribute to IronRuby and failed because of a bloated project structure. >> I''m sure there are several people who would be willing to help you figure >> out what''s wrong. Where''s the repo with your contribution? >> > > I don''t understand. Is this some sort of challenge? >No, that''s just how I read your message. You seem to indicate that the current repo structure causes difficulty when you want to contribute. If you need help finding your way around, I''m happy to help, as I''m sure are many others. (Of course, you may want the help of others as I''m a bit rusty myself.) :)> I don''t think changing the structure in forked repos would do anyone any > good, as it would make sharing contributions between repos difficult. >True, but if you were able to create a repo structure you think would allow more freedom to contribute, then I think everyone would move to that structure. Changing the structure is going to take work, and I think most people who have been contributing are fine with the current structure since they''ve been used to it for some time. Actually, several layers of the repo have already been removed, so it''s better than it was six months ago. I think you are confused to where I am puzzled about resistance. It is not> about having rake tasks. I agree that they are easy enough to add and > maintain, and that whining about them would be quite ridiculous. That''s not > my point, however. My point is that there would be more contributions if it > were not a single monolithic repository. I also think most of the historic > benefits of having a monolithic repo can be mitigated with submodules and an > automated build and integration server. > > Feel free to disagree. >I don''t really disagree with you at all. I use that same strategy myself on my own projects. I just don''t want to volunteer to restructure the entire project, especially if people are actively working on integration scenarios. Yes, the project was originally in both TFS and git, so it had to play nice with both. Other options are now open. Hence why I suggested forking it and showing a better structure. I dunno, it looks really, really similar to the IronRuby repo on GitHub to> me. Is this synched with the GitHub repo? Is this where all the "Project > Merlin" changes are coming from? >I believe the sync is one-way, IronRuby includes IronPython. I''m sure the similarity in structure comes from the internal TFS repos that were used and the fact that the teams were both working on the DLR together. Someone please correct me if this is wrong. Cheers, Ryan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101023/a2cc63d5/attachment.html>
> I have to respecify DEBUG since I''m redefining the DefineConstants > property. > > Running would have worked as long as you didn''t try to call that method :) >I would love to see your work. Ive been meaning to package ironruby for gentoo linux for ages, but so far have not got around to it. The main reason for this is that it doesn''t build "naked". Gentoo has a policy of staying as close to upstream as possible combined with me being lazy and until a couple of days ago was unsure of whether I could contribute patches upstream. none of those made me particularly motivated to create patches :) If you have made changes I would 1) like to get them merged into ironruby. so #if MONO''s would be nice instead of a straight fix. (assuming they are acceptable) 2) like to get the issue fixed in mono (if its that doc one for which there is already a bug, but also that cast from dynamic to object one) so please can we file bugs upstream too. On a more general note. if you are interested in ruby on gentoo I suggest you have a look at a fellow dev''s blog [1]. Its an interesting read and you won''t be disappointed :) Really please read it, you might learn some of the challenges gentooers currently face. From a linux packaging perspective. Ultimately I would hope that we can acheive nice, easy (for everyone), reproducable builds. Im perfectly happy with msbuild, but could we add bat/sh files that call msbuild/xbuild to build specific parts of the project. Could we document all the options available to configure the build (including defines if necessary, etc). -Alistair. [1] http://blog.flameeyes.eu/tag/rubyng [2] https://bugs.gentoo.org/show_bug.cgi?id=94374 ps. Does ironruby have a irc channel, other place where dev''s hang out?
The project directory structure is a mess. Dozens of executable files in the versioning and what not. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101025/821553c2/attachment.html>
On Sun, Oct 24, 2010 at 1:57 AM, Michael Letterle < michael.letterle at gmail.com> wrote:> FWIW having separate IronRuby, IronPython, and Common repos that are > sub moduled(is that a word?) would make sense, that way changes that > are done in Common by both people working on Ruby and Python are > easily shared.. the current configuration feels.. fragile. >There is a major problem: different vcs tools. I guess the IronPython project will stay with TFS/SVN while IronRuby will use git(hub). Having common submodule repos managed by different VCS would be a world of pain. There is no way of dividing the project into submodules if IronPython doesn''t move to github/git. Maybe some git-svn magic would help and mirror versions on github of the svn repositories would be needed. I think that another major problem the IronRuby project has are the 4 sites with IronRuby content. There are like 4 sites now on github, rubyforge, ironruby.net and the codeplex with different content on ironruby. This is madness, IronPython as only 2 sites, ironpython.net and codeplex and that makes sence. When I looked into the project I was just confused, because I couldn''t find any information and the little bits of Information were scattered and outdated. And this is a real dilemma, because you just can''t move away from any of these sites: you have to stay at codeplex at because it is an Iron project, you have to stay at rubyforge because it is ruby afterall, you can''t move from github, because all the ruby kids use git, so there is only ironruby.net left, but you can''t get rid of that either, it''s after all the ironruby domain. The purposes of the sites need to be trimmed down: use codeplex and rubyforge only for binary distribution, github for versioning, issue tracking and wiki and ironruby.net as a presentation site just like ironpython.net is, cut the documentation out of it and stuff it in the github wiki, redudancy is hard to version. I don''t think that keeping the issue tracking system on codeplex really helps in any way: people who are interested only in IronRuby have to register now on codeplex and github, people who are interested in bot iron projects will have to register on both anyway. I guess splitting up this this project is a nasty nasty dilemma, because the project tries to unite different communities which have different tool preferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101025/932b1250/attachment-0001.html>
Can you be more specific? What''s wrong with the structure (other than LCA_RESTRICTED directories, which I agree were there only to satisfy our lawyers but can be now merged into other directories)? Yes, there are executable files checked in. These are tools that are needed for running scripts, tests and various code generators. Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Andrius Bentkus Sent: Monday, October 25, 2010 12:51 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Contributing? The project directory structure is a mess. Dozens of executable files in the versioning and what not. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101025/1c99b9c2/attachment.html>
On Mon, Oct 25, 2010 at 4:22 AM, Andrius Bentkus < Andrius.Bentkus at rwth-aachen.de> wrote:> > On Sun, Oct 24, 2010 at 1:57 AM, Michael Letterle < > michael.letterle at gmail.com> wrote: > >> FWIW having separate IronRuby, IronPython, and Common repos that are >> sub moduled(is that a word?) would make sense, that way changes that >> are done in Common by both people working on Ruby and Python are >> easily shared.. the current configuration feels.. fragile. >> > > There is a major problem: different vcs tools. I guess the IronPython > project will stay with TFS/SVN while IronRuby will use git(hub). Having > common submodule repos managed by different VCS would be a world of pain. > There is no way of dividing the project into submodules if IronPython > doesn''t move to github/git. Maybe some git-svn magic would help and mirror > versions on github of the svn repositories would be needed. >I don''t think this would be too difficult to work around. There is already some process that replicates changes from the IronPython''s CodePlex repo to IronRuby''s GitHub repo. If the current monolithic project structure were broken up into submoldules, you could have just IronPython''s CodePlex being replicated to an IronPython git repo. I think that another major problem the IronRuby project has are the 4 sites> with IronRuby content. There are like 4 sites now on github, rubyforge, > ironruby.net and the codeplex with different content on ironruby. This is > madness, IronPython as only 2 sites, ironpython.net and codeplex and that > makes sence. When I looked into the project I was just confused, because I > couldn''t find any information and the little bits of Information were > scattered and outdated. And this is a real dilemma, because you just can''t > move away from any of these sites: you have to stay at codeplex at because > it is an Iron project, you have to stay at rubyforge because it is ruby > afterall, you can''t move from github, because all the ruby kids use git, so > there is only ironruby.net left, but you can''t get rid of that either, > it''s after all the ironruby domain. > The purposes of the sites need to be trimmed down: use codeplex and > rubyforge only for binary distribution, github for versioning, issue > tracking and wiki and ironruby.net as a presentation site just like > ironpython.net is, cut the documentation out of it and stuff it in the > github wiki, redudancy is hard to version. > I don''t think that keeping the issue tracking system on codeplex really > helps in any way: people who are interested only in IronRuby have to > register now on codeplex and github, people who are interested in bot iron > projects will have to register on both anyway. >I don''t see the number of content sites as a major problem. Rubyforge is being phased out in favor of better tools, so I don''t think its a long term solution. (Even gem hosting has moved to rubygems.org instead of gems.rubyforge.org.) I don''t think the ironruby.net site is holding the project back at all, but I agree it could be better. I think a better solution would be to replace it with a jekyll site running on GitHub. Just point the ironruby.net domain to GitHub and you''re done. The reason I like the jekyll approach is because it makes it much easier for folks to create and improve web content. Its just a pull request away from being published. I think that system works really well, and its free. It doesn''t really matter where downloads are hosted, as long as ironruby.netlinks to them. But they could just as easily be hosted on GitHub. The only thing that I''m aware is being used at CodePlex is the ticketing. Again, I think there are better ticketing solutions out there, most of them free for open source projects. I don''t really see a need for CodePlex myself, but I understand the desire to stay on it for some things. Its probable that you could also push the jekyll content to CodePlex (and Rubyforge) if that was desired.> I guess splitting up this this project is a nasty nasty dilemma, because > the project tries to unite different communities which have different tool > preferences. >All the more reason to have separate repositories, IMO. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101025/bdf17954/attachment-0001.html>
Let''s assume IronPython moves to github. There would be two options: 1) We could just rename the current IronRuby repo to "DynamicLanguages" repo and IronPython can use it as it is (more or less). 2) It might be possible to split the repo to 3 parts - IronRuby specific, IronPython specific, and DLR, make a submodule for each and combine those submodules into "DynamicLanguages" repo. So what''s exactly the effective difference among the repo built this way and 1)? AFAICT it''s only that super-module doesn''t track the head of the sub-module automatically. You need to manually update it to the latest version. How does that help us? If we have a (single) CI server that makes sure that both IronPython''s and IronRuby''s heads are passing all tests, what is the advantage of not using the latest source code of each other? Or am I missing something (maybe I misunderstand what git submodule can do)? PS: All this is orthogonal to minor refactoring of the current directory structure that is a no-brainer and I already mentioned them (like removing LCA_RESTRICTED). Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Mike Moore Sent: Monday, October 25, 2010 10:28 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Contributing? On Mon, Oct 25, 2010 at 4:22 AM, Andrius Bentkus <Andrius.Bentkus at rwth-aachen.de<mailto:Andrius.Bentkus at rwth-aachen.de>> wrote: On Sun, Oct 24, 2010 at 1:57 AM, Michael Letterle <michael.letterle at gmail.com<mailto:michael.letterle at gmail.com>> wrote: FWIW having separate IronRuby, IronPython, and Common repos that are sub moduled(is that a word?) would make sense, that way changes that are done in Common by both people working on Ruby and Python are easily shared.. the current configuration feels.. fragile. There is a major problem: different vcs tools. I guess the IronPython project will stay with TFS/SVN while IronRuby will use git(hub). Having common submodule repos managed by different VCS would be a world of pain. There is no way of dividing the project into submodules if IronPython doesn''t move to github/git. Maybe some git-svn magic would help and mirror versions on github of the svn repositories would be needed. I don''t think this would be too difficult to work around. There is already some process that replicates changes from the IronPython''s CodePlex repo to IronRuby''s GitHub repo. If the current monolithic project structure were broken up into submoldules, you could have just IronPython''s CodePlex being replicated to an IronPython git repo. I think that another major problem the IronRuby project has are the 4 sites with IronRuby content. There are like 4 sites now on github, rubyforge, ironruby.net<http://ironruby.net> and the codeplex with different content on ironruby. This is madness, IronPython as only 2 sites, ironpython.net<http://ironpython.net> and codeplex and that makes sence. When I looked into the project I was just confused, because I couldn''t find any information and the little bits of Information were scattered and outdated. And this is a real dilemma, because you just can''t move away from any of these sites: you have to stay at codeplex at because it is an Iron project, you have to stay at rubyforge because it is ruby afterall, you can''t move from github, because all the ruby kids use git, so there is only ironruby.net<http://ironruby.net> left, but you can''t get rid of that either, it''s after all the ironruby domain. The purposes of the sites need to be trimmed down: use codeplex and rubyforge only for binary distribution, github for versioning, issue tracking and wiki and ironruby.net<http://ironruby.net> as a presentation site just like ironpython.net<http://ironpython.net> is, cut the documentation out of it and stuff it in the github wiki, redudancy is hard to version. I don''t think that keeping the issue tracking system on codeplex really helps in any way: people who are interested only in IronRuby have to register now on codeplex and github, people who are interested in bot iron projects will have to register on both anyway. I don''t see the number of content sites as a major problem. Rubyforge is being phased out in favor of better tools, so I don''t think its a long term solution. (Even gem hosting has moved to rubygems.org<http://rubygems.org> instead of gems.rubyforge.org<http://gems.rubyforge.org>.) I don''t think the ironruby.net<http://ironruby.net> site is holding the project back at all, but I agree it could be better. I think a better solution would be to replace it with a jekyll site running on GitHub. Just point the ironruby.net<http://ironruby.net> domain to GitHub and you''re done. The reason I like the jekyll approach is because it makes it much easier for folks to create and improve web content. Its just a pull request away from being published. I think that system works really well, and its free. It doesn''t really matter where downloads are hosted, as long as ironruby.net<http://ironruby.net> links to them. But they could just as easily be hosted on GitHub. The only thing that I''m aware is being used at CodePlex is the ticketing. Again, I think there are better ticketing solutions out there, most of them free for open source projects. I don''t really see a need for CodePlex myself, but I understand the desire to stay on it for some things. Its probable that you could also push the jekyll content to CodePlex (and Rubyforge) if that was desired. I guess splitting up this this project is a nasty nasty dilemma, because the project tries to unite different communities which have different tool preferences. All the more reason to have separate repositories, IMO. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101025/3365529d/attachment-0001.html>
As someone who attempted to dive into IronRuby a couple of months ago, I found it difficult to discern the "IronRuby Story" from the various websites. By that I mean that was not immediately obvious to me what information was current and what was outdated. I''d like to see an executive summary of the project that is updated at least once a month and perhaps a more conspicuous hub for FeRb activity. (For example, see the one page site we have for Caliburn -> http://www.caliburnproject.com/) I''m .NET dev, but a ruby beginner. However, we''re also a git shop, OSS enthusiasts, and so on. That''s just to say that tooling and culture were not a roadblock. I''d also be interested in contributing to the effort of web presence. Christopher -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101025/5a8439a9/attachment.html>
My only comment on the sites: 1) github = source control, 2) rubyforge = mailing list, 3) codeplex = issue tracker/binary distro, 4) ironruby.net = documentaiton 1 and 2 are pretty set, I see no reason to change from them. 3 is probably fine as well, though having source control and issue tracking in one location may be desirable. 4) Using gh-pages is an interesting idea, is ironruby.net being hosted at Microsoft''s expense or one of the team members? That would probably have some bearing on that. Regardless, I''d rather see a nice README first. :) On Mon, Oct 25, 2010 at 1:27 PM, Mike Moore <blowmage at gmail.com> wrote:> > I don''t think this would be too difficult to work around. There is already > some process that replicates changes from the IronPython''s CodePlex repo to > IronRuby''s GitHub repo. If the current monolithic project structure were > broken up into submoldules, you could have just IronPython''s CodePlex being > replicated to an IronPython git repo. >>This I agree with. The current repo structure is counter-intuitive IMHO. -- Michael Letterle IronRuby MVP http://blog.prokrams.com
Yes, I agree our web sites need some work. Jimmy, what is that status of the new design you started working on (the one IronPython.net has already)? Tomas From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Christopher Bennage Sent: Monday, October 25, 2010 11:20 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Contributing? As someone who attempted to dive into IronRuby a couple of months ago, I found it difficult to discern the "IronRuby Story" from the various websites. By that I mean that was not immediately obvious to me what information was current and what was outdated. I''d like to see an executive summary of the project that is updated at least once a month and perhaps a more conspicuous hub for FeRb activity. (For example, see the one page site we have for Caliburn -> http://www.caliburnproject.com/) I''m .NET dev, but a ruby beginner. However, we''re also a git shop, OSS enthusiasts, and so on. That''s just to say that tooling and culture were not a roadblock. I''d also be interested in contributing to the effort of web presence. Christopher -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101025/b5de5cb4/attachment.html>
On Mon, Oct 25, 2010 at 12:26 PM, Michael Letterle < michael.letterle at gmail.com> wrote:> Regardless, I''d rather see a nice README first. :) >+1 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20101025/c94c702c/attachment.html>
Hey, On Mon, Oct 25, 2010 at 8:19 PM, Tomas Matousek <Tomas.Matousek at microsoft.com> wrote:> 2)????? It might be possible to split the repo to 3 parts ? IronRuby > specific, IronPython specific, and DLR, make a submodule for each and > combine those submodules into ?DynamicLanguages? repo. So what?s exactly the > effective difference among the repo built this way and 1)?The difference is that it then becomes easier for people that are only interested in either IronPython or IronRuby to track commits. There will be a timeline for each modules. And you get to follow the ones you''re interested in. And if you''re only interested in one, your timeline isn''t ?polluted? with comments or commits from the others. Jb
Makes sense. That seems like a goodness and I guess we should evolve the repo that way. Let''s keep everything working and get there one step at a time. It doesn''t feel like something that would be critical to do right now though. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jb Evain Sent: Monday, October 25, 2010 1:03 PM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Contributing? Hey, On Mon, Oct 25, 2010 at 8:19 PM, Tomas Matousek <Tomas.Matousek at microsoft.com> wrote:> 2)????? It might be possible to split the repo to 3 parts ? IronRuby > specific, IronPython specific, and DLR, make a submodule for each and > combine those submodules into ?DynamicLanguages? repo. So what?s > exactly the effective difference among the repo built this way and 1)?The difference is that it then becomes easier for people that are only interested in either IronPython or IronRuby to track commits. There will be a timeline for each modules. And you get to follow the ones you''re interested in. And if you''re only interested in one, your timeline isn''t ?polluted? with comments or commits from the others. Jb _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core