On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras <felipe.contre...@gmail.com> wrote: > On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen <pclo...@gmail.com> wrote: >> On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras >> <felipe.contre...@gmail.com> wrote: >>> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen <pclo...@gmail.com> wrote: >>>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin >>>> <johannes.schinde...@gmx.de> wrote: >>>>> Hi Greg, >>>>> >>>>> On Thu, 6 Jun 2013, Greg Troxel wrote: >>>>> >>>>>> As one of the people who helps maintain git packages in pkgsrc, my >>>>>> initial reaction is negative to adding a ruby dependency. >>>>> >>>>> My initial reaction, too. It was hard enough to get Perl included with Git >>>>> for Windows (because of that pesky Subversion dependency). >>>>> >>>>> As you can see from the commit history, I was the primary force behind >>>>> trying to get everything "core" in Git away from requiring scripting >>>>> languages (I think it is an awesome thing to provide APIs for as many >>>>> languages as possible, but a not-so-cool thing to use more than one >>>>> language in the core code). It does not seem that anybody picked up that >>>>> task when I left, though. >>>> >>>> Nobody seems to mention it yet. There's another reason behind the C >>>> rewrite effort: fork is costly on Windows. The C rewrite allows us to >>>> run with one process (most of the time). This applies for shell, perl >>>> and even ruby scripts because libgit.a is never meant to be used >>>> outside git.c context (unlike libgit2). In this regard, ruby is just >>>> as bad as currently supported non-C languages. >>> >>> Are you sure? >> >> I'm not saying you can't. I'm saying it's not meant to be used that >> way. Which means there may be problems lurking around. > > Code is code. If something is not meant to be used in certain way, you fix it.
Code is code. Bugs can be hard and easy. Hard bugs take a lot of time and may not be worth it after all. >> You can write a ruby extension to access libgit.a, sure, > > I'm not using libgit.a, I'm using the builtin commands. This is > exactly the same code you run when you type 'git foo'. > >> but how many people on this >> list understand git design and limits _and_ ruby's good enough to spot >> the bugs? > > Now you are changing the subject. Does that mean that you accept that > 'fork' wouldn't be a problem when writing Ruby scripts? There are a lot of static variables in builtin/ (and outside too), which make it non-entrant, or at least not safe. fork provides a process space isolation, some depend on that. And there are die() everywhere. Good luck controlling them. > As for the people that know Git and Ruby; they can learn. Didn't you > just said that you didn't see any problem with the community learning > a new language? I said nothing about the community being ready _now_, did I? When you have the support for Ruby in Git, sure go ahead. >> If a bug is found and requires major restructuring in >> libgit.a, how are you sure it's worth the effort and does not >> destablize the rest of git? > > There is no need to destabilize anything. I just showed you 100 lines > of code that are able to run git commands without forks, and without > changing anything in libgit.a. And how do you deal with, for example die(), or thread safety? -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
