Re: [Administrivia] On ruby and contrib/

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

 



On Sat, Jun 8, 2013 at 6:56 PM, Felipe Contreras
<felipe.contreras@xxxxxxxxx> wrote:
> On Sat, Jun 8, 2013 at 6:28 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
>> 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.
>
> 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 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]