Re: [Administrivia] On ruby and contrib/

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
> On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
>> On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
>> <Johannes.Schindelin@xxxxxx> 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.

>
> ---
> #!/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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]