Re: [Administrivia] On ruby and contrib/

From: Duy Nguyen <pclouds@gmail.com>
Date: Jun 8, 2013, 11:28 UTC
Message-ID: <CACsJy8DTKr5Fy3-+8ShUrWQrKC2_7EmLHwyVgQ9Aq5JDOFBAqA@mail.gmail.com>
In-Reply-To: <CAMP44s08V1=nVbeo6r8UVT3Fd0=iSpRohinqf77Tmu4=xpDHeg@mail.gmail.com>

On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:

Show 28 quoted lines

> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
>> <Johannes.Schindelin@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. You can write a ruby extension to access libgit.a, sure, but how many people on this list understand git design and limits _and_ ruby's good enough to spot the bugs? 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? A better way to do it is linking against libgit2.

Show 29 quoted lines

>
> ---
> #!/bin/sh
>
> cat > /tmp/test <<EOF
> require './git'
>
> (1..100).each do |e|
>   puts \`git rev-parse HEAD~#{e}\`
> end
> EOF
>
> strace -o /tmp/log -e fork,clone ruby /tmp/test
> cat /tmp/log
> ---
>
> ---
> clone(child_stack=0x7f84131dbff0,
> flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
> parent_tidptr=0x7f84131dc9d0, tls=0x7f84131dc700,
> child_tidptr=0x7f84131dc9d0) = 17455
> +++ exited with 0 +++
> ---
>
> I wrote a simple Ruby extension to access Git builtins so `git
> rev-parse` actually calls cmd_rev_parse directly. I don't know of any
> other language that supports so much extensibility. Of course, as soon
> as one command does exit(), the script ends too. It could be useful to
> do experiments though.

-- Duy