Re: Python extension commands in git - request for policy change

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

 



On Tue, Dec 11, 2012 at 11:14 AM, Patrick Donnelly <batrick@xxxxxxxxxxxx> wrote:
> Sorry I'm late to this party...
>
> I'm an Nmap developer that is casually interested in git development.
> I've been lurking for a while and thought I'd post my thoughts on this
> thread.
>
> On Sun, Nov 25, 2012 at 6:25 AM, Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> wrote:
>>> The most important issues to consider when imagining a future with a
>>> hybrid of code in C and some scripting language "X" are:
>>>
>>> * Portability: is "X" available on all platforms targeted by git, in
>>>   usable and mutually-compatible versions?
>>>
>>> * Startup time: Is the time to start the "X" interpreter prohibitive?
>>>   (On my computer, "python -c pass", which starts the Python
>>>   interpreter and does nothing, takes about 24ms.)  This overhead would
>>>   be incurred by every command that is not pure C.
>>>
>>> * Should the scripting language access the C functionality only by
>>>   calling pure-C executables or by dynamically or statically linking to
>>>   a binary module interface?  If the former, then the granularity of
>>>   interactions between "X" and C is necessarily coarse, and "X" cannot
>>>   be used to implement anything but the outermost layer of
>>>   functionality.  If the latter, then the way would be clear to
>>>   implement much more of git in "X" (and lua would also be worth
>>>   considering).
>>>
>>> * Learning curve for developers: how difficult is it for a typical git
>>>   developer to become conversant with "X", considering both (1) how
>>>   likely is it that the typical git developer already knows "X" and
>>>   (2) how straightforward and predictable is the language "X"?
>>>   In this category I think that Python has a huge advantage over
>>>   Perl, though certainly opinions will differ and Ruby would also be
>>>   a contender.
>>
>> * We might also need an embedded language variant, like Jeff's lua
>> experiment. I'd be nice if "X" can also take this role.
>
> Lua has been an incredible success for Nmap [2](and other projects).
> As an embedded scripting language, it's unrivaled in terms of ease of
> embedding, ease of use for users, and performance. I would strongly
> recommend the git developers to seriously consider it.

[snipping the rest; all valid points no doubt]

Does lua have os.putenv() yet?  The inability to even *set* an env var
before calling something else was a killer for me when I last tried
it.

That may make it fine as an embedded language (called *by* something
else) but it is a bit too "frugal" to use as a glue language (calls
other things).
--
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]