On Wed, Dec 12, 2012 at 7:43 AM, Eric S. Raymond wrote:
> Patrick Donnelly :
>>How would another language (e.g. Python) mitigate this?
>
> The way you mitigate this sort of problem is to have a good set of
> high-level bindings for standard services (like socket I/O) built in
> your extens
Andrew Ardill writes:
> On 13 December 2012 04:49, Junio C Hamano wrote:
>> "bisect" with " vs
>> " issue unsettled
>
> Would you want to see this issue resolved in-script before a porting
> attempt was started?
Honestly, I do not care too much either way, but for the people who
want to work ei
Jeff King writes:
> I think there are really two separate use cases to consider:
>
> 1. Providing snippets of script to Git to get Turing-complete behavior
> for existing Git features. For example, selecting commits during a
> traversal (e.g., a better "log --grep"), formatting output
Patrick Donnelly :
> On Tue, Dec 11, 2012 at 10:30 PM, Eric S. Raymond wrote:
> > It might be a good fit for extending git; I wouldn't be very surprised if
> > that worked. However, I do have concerns about the "Oh, we'll just
> > lash together a binding to C" attitude common among lua programmers
On Wed, Dec 12, 2012 at 07:26:25AM -0500, Eric S. Raymond wrote:
> Jeff King :
> > I think there are really two separate use cases to consider:
> >
> > 1. Providing snippets of script to Git to get Turing-complete behavior
> > for existing Git features. For example, selecting commits durin
Jeff King :
> I think there are really two separate use cases to consider:
>
> 1. Providing snippets of script to Git to get Turing-complete behavior
> for existing Git features. For example, selecting commits during a
> traversal (e.g., a better "log --grep"), formatting output (e.g.,
Joshua Jensen :
> Anyway, my preference is to allow scripts to run in-process within
> Git, because it is far, far faster on Windows. I imagine it is
> faster than forking processes on non-Windows machines, too, but I
> have no statistics to back that up.
>
> Python, Perl, or Ruby can be embedded
On Wed, Dec 12, 2012 at 02:03:56AM -0500, Patrick Donnelly wrote:
> On Wed, Dec 12, 2012 at 1:32 AM, Jeff King wrote:
> > It would take a lot of effort to expose git-core's internals in a clean
> > way; you'd probably be better off starting from scratch and rewriting
> > large parts in a friendly
Hi Eric,
On Tue, Dec 11, 2012 at 10:30 PM, Eric S. Raymond wrote:
> It might be a good fit for extending git; I wouldn't be very surprised if
> that worked. However, I do have concerns about the "Oh, we'll just
> lash together a binding to C" attitude common among lua programmers; I
> foresee mai
Hi Jeff,
On Wed, Dec 12, 2012 at 1:32 AM, Jeff King wrote:
> It would take a lot of effort to expose git-core's internals in a clean
> way; you'd probably be better off starting from scratch and rewriting
> large parts in a friendly library-like manner. Fortunately, there is
> already a project u
On Tue, Dec 11, 2012 at 10:30:43PM -0500, Eric S. Raymond wrote:
> My sense is that git's use cases are better served by a glue language
> in the Python/Perl/Ruby class rather than an extension langage. But
> my mind is open on this issue.
I think there are really two separate use cases to consid
- Original Message -
From: Patrick Donnelly
Date: 12/11/2012 7:26 PM
If we use lua for writing "builtin" commands,
we'll need to export a lot of C functions and writing wrappers like
this is boring and time consuming. Also, assume I export fn(char*,int)
to Lua, then I change the prototype
- Original Message -
From: Eric S. Raymond
Date: 12/11/2012 8:30 PM
It might be a good fit for extending git; I wouldn't be very surprised if
that worked. However, I do have concerns about the "Oh, we'll just
lash together a binding to C" attitude common among lua programmers; I
foresee m
On Wed, 12 Dec 2012 08:50:27 +0700, Nguyen Thai Ngoc Duy
wrote:
> On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
> wrote:
> > If it doesn't, it would be trivial to add. It's a one-liner. It's been a
> > while
> > since I used Lua, but it would be something like this:
> >
> > void L_putenv(
Sitaram Chamarty :
> [snipping the rest; all valid points no doubt]
I meant to respond to Patrick's post earlier.
I haven't actually written any code in lua yet, but I've read the book;
I think I get it. I've seen the effects of lua integration on another
large project, Battle for Wesnoth.
I'm
Hi Duy,
On Tue, Dec 11, 2012 at 8:50 PM, Nguyen Thai Ngoc Duy wrote:
> On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
> wrote:
>> If it doesn't, it would be trivial to add. It's a one-liner. It's been a
>> while
>> since I used Lua, but it would be something like this:
>>
>> void L_putenv(
On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
wrote:
> If it doesn't, it would be trivial to add. It's a one-liner. It's been a while
> since I used Lua, but it would be something like this:
>
> void L_putenv(lua_State *L) {
> putenv(lua_tostring(L, 1));
> }
>
> and then somewher
On Wed, 12 Dec 2012 05:39:43 +0530, Sitaram Chamarty wrote:
> 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.
If it doesn't, it would be trivial to add. It's a one-liner. It's been a while
since I u
Hi Sitaram,
On Tue, Dec 11, 2012 at 7:09 PM, Sitaram Chamarty wrote:
> On Tue, Dec 11, 2012 at 11:14 AM, Patrick Donnelly
> wrote:
>> 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
On Tue, Dec 11, 2012 at 11:14 AM, Patrick Donnelly 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
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 wrote:
>> The most important issues to consider when imaginin
On Sat, Nov 24, 2012 at 9:44 PM, Eric S. Raymond wrote:
> git presently contains one Python extension command, Pete Wycoff's p4
> importer. If my git-weave code is merged it will acquire another.
Write a really compelling tool. Don't argue languages. Make it
wonderful. The git maintainers, tool
- Original Message -
> From: "Felipe Contreras"
> Sent: Tuesday, December 4, 2012 9:19:18 AM
> Subject: Re: Python extension commands in git - request for policy change
>
> > > Also, you are ignoring all the advantages that shell has and
> > > p
On Mon, Dec 3, 2012 at 3:45 PM, Philippe Vaucher
wrote:
>> Also, you are ignoring all the advantages that shell has and python does not.
>
> Out of curiosity, can you list the advantages? From what I gathered:
>
> - no need to install bash
Unless you are in Windows or OS X. OS X has a shell, but
> Also, you are ignoring all the advantages that shell has and python does not.
Out of curiosity, can you list the advantages? From what I gathered:
- no need to install bash
- git contributors are more used to bash
- there's only one "version" of bash (no real need to handle different
versions c
On Tuesday, November 27, 2012 at 19:10 EST,
Felipe Contreras wrote:
> On Tue, Nov 27, 2012 at 3:35 PM, Magnus Bäck wrote:
>
> > While "constant traffic" probably overstates the issue, these are
> > not theoretical problems. I recall at least three cases in the last
> > year or so where Git
- Original Message -
From: Michael Haggerty
Date: 11/25/2012 3:44 AM
* 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
On Wed, Nov 28, 2012 at 02:22:09AM +0100, Felipe Contreras wrote:
> Sure, you will argue that we don't see the *real* issues, because they
> were fixed preemptively, but the fact of the matter is that we will
> never know. All we know is the reality we can observe, and the reality
> is that we hit
On Wed, Nov 28, 2012 at 1:51 AM, Jeff King wrote:
> On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras wrote:
>
>> > While "constant traffic" probably overstates the issue, these are not
>> > theoretical problems. I recall at least three cases in the last year
>> > or so where Git has seen
On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras wrote:
> > While "constant traffic" probably overstates the issue, these are not
> > theoretical problems. I recall at least three cases in the last year
> > or so where Git has seen breakage with Solaris or Mac OS X because
> > of sed or
Le mardi 27 novembre 2012 02:51:04 David Aguilar a écrit :
> On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty
wrote:
> > On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar wrote:
> >> *cough* git-cola *cough*
> >>
> >> it runs everywhere. Yes, windows too. It's written in python.
> >> It's been a
On Wed, Nov 28, 2012 at 12:05 AM, Eric S. Raymond wrote:
> Magnus Bäck :
>> While "constant traffic" probably overstates the issue, these are not
>> theoretical problems. I recall at least three cases in the last year
>> or so where Git has seen breakage with Solaris or Mac OS X because
>> of sed
Magnus Bäck :
> While "constant traffic" probably overstates the issue, these are not
> theoretical problems. I recall at least three cases in the last year
> or so where Git has seen breakage with Solaris or Mac OS X because
> of sed or tr incompatibilities, and I don't even read this list that
>
Hi David,
On Mon, 26 Nov 2012, David Aguilar wrote:
> *cough* git-cola *cough*
If you had a couple of free cycles to help us get Python/Qt compiled in
msysGit, I will be happy to make a Git for Windows package including
git-cola.
Ciao,
Dscho
--
To unsubscribe from this list: send the line "unsu
On Sunday, November 25, 2012 at 06:40 EST,
Felipe Contreras wrote:
> On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty
> wrote:
[...]
> > On the contrary, there is *constant* traffic on the mailing list
> > about incompatibilities between different shell implementations (sh,
> > dash, ba
On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty wrote:
> On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar wrote:
>
>> *cough* git-cola *cough*
>>
>> it runs everywhere. Yes, windows too. It's written in python.
>> It's been actively maintained since 2007.
>>
>> It's "modern" and has features tha
On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar wrote:
> *cough* git-cola *cough*
>
> it runs everywhere. Yes, windows too. It's written in python.
> It's been actively maintained since 2007.
>
> It's "modern" and has features that don't exist anywhere else.
>
> It even has tests. It even comes
On Tue, Nov 27, 2012 at 8:54 AM, David Aguilar wrote:
> On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
> wrote:
>> http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces
>
> *cough* git-cola *cough*
>
> it runs everywhere. Yes, windows too. It's written in python.
> It's been actively m
On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
wrote:
> And I don't agree that the project would be better off with something
> else, if it was, somebody would have proposed an alternative by now,
> but there aren't any. I have tried gitg, and giggle, and I have even
> contributed to them, but
On Sun, Nov 25, 2012 at 11:11 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> And are you going to be around to spot them? It seems my patches for
>> git-remote-hg slipped by your watch, because it seems they use stuff
>> specific to python 2.7.
>
> The dev group hasn't decided (in whatever way
On Sun, Nov 25, 2012 at 10:56 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> And gitk is an integral part of git. But if you have different
>> numbers, what are they?
>
> I looked at the Makefile. I saw that there are shell variables that collect
> C commands, shell command, Perl commands, an
On 11/25/2012 11:44 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> According to the results of the last survey, our users do care about
>> performance, so I don't think there's anything excessive about it. Are
>> there any hidden costs in maintenance problems? I don't think so.
>
> Then you're
On Mon, Nov 26, 2012 at 10:40:00AM +0530, Sitaram Chamarty wrote:
> On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond wrote:
> > Krzysztof Mazur :
> >> What about embedded systems? git is also useful there. C and shell is
> >> everywhere, python is not.
> >
> > Supposing this is true (and I questio
On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond wrote:
> Krzysztof Mazur :
>> What about embedded systems? git is also useful there. C and shell is
>> everywhere, python is not.
>
> Supposing this is true (and I question it with regard to shell) if you
> tell me how you live without gitk and the
Krzysztof Mazur :
> What about embedded systems? git is also useful there. C and shell is
> everywhere, python is not.
Supposing this is true (and I question it with regard to shell) if you
tell me how you live without gitk and the Perl pieces I'll play that
right back at you as your answer.
--
Felipe Contreras :
> > I'd be happy to help you out by auditing them for version dependencies.
>
> Be my guest:
> http://git.kernel.org/?p=git/git.git;a=tree;f=contrib/remote-helpers;h=adfdcc164e634c74024c8f69bb0cdb9f3b4a9f18;hb=7b4a70c62f3a83fbd8b44bf712141754a5f64205
>
> Some patches might be m
Felipe Contreras :
> And are you going to be around to spot them? It seems my patches for
> git-remote-hg slipped by your watch, because it seems they use stuff
> specific to python 2.7.
The dev group hasn't decided (in whatever way it decides these
things) to require 2.6 yet. When and if it does
Felipe Contreras :
> And gitk is an integral part of git. But if you have different
> numbers, what are they?
I looked at the Makefile. I saw that there are shell variables that collect
C commands, shell command, Perl commands, and Python commands. There are no
collections of other commands. Th
On Sun, Nov 25, 2012 at 6:32 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> Seems sensible, but I don't know what "rejection" would actually mean.
>
> Why is this mysterious? We reject a patch when we don't choose to merge it.
Why would you reject it? If, according to you, it's very simple t
On Sat, Nov 24, 2012 at 09:44:51PM -0500, Eric S. Raymond wrote:
>
> We're behind the best-practices curve here. The major Linux
> distributions, which have to deal with almost the same set of
> tradeoffs we do, went to Python for pretty much all glue and
> administration scripts outside /etc a d
On Sun, Nov 25, 2012 at 6:36 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> Of course, but there are experts in C and shell around, not so many
>> python experts. So if somebody sneaks in a python program that makes
>> use of features specific to python 2.7, I doubt anybody would notice.
>
> I
On Sun, Nov 25, 2012 at 6:50 PM, Eric S. Raymond wrote:
> Felipe Contreras :
>> Not according to ohloh:
>>
>> 1) shell 33%
>> 2) tcl 9%
>> 3) perl 9.7%
>>
>> 4) python 1.8%
>
> Look in the Makefile - all that tcl code is buried in gitk. We're
> very, very lucky the author did such a good job, bec
Felipe Contreras :
> Not according to ohloh:
>
> 1) shell 33%
> 2) tcl 9%
> 3) perl 9.7%
>
> 4) python 1.8%
Look in the Makefile - all that tcl code is buried in gitk. We're
very, very lucky the author did such a good job, because it's a
potentially serious headache; who can maintain it?
--
David Lang :
> You may think that C and Bash are poor choices, but that is what the
> community is familar with.
I don't think C is a "poor" choice. bash, on the other hand...so
many dependencies on tool quirks!
> You are far from the first person to say that git should be
> re-written (or at le
Felipe Contreras :
> Of course, but there are experts in C and shell around, not so many
> python experts. So if somebody sneaks in a python program that makes
> use of features specific to python 2.7, I doubt anybody would notice.
I would.
> And if they did, I doubt that would be reason enough f
Felipe Contreras :
> Seems sensible, but I don't know what "rejection" would actually mean.
Why is this mysterious? We reject a patch when we don't choose to merge it.
> My "extensions" are on the way to the contrib area. Is the contrib
> area supposed to have different rules? I don't know.
I d
Hi,
thank you Duy for thinking of Cc:ing the msysGit mailing list. We indeed
do not have a working Python in Git for Windows yet (mainly because I did
not review kusma's patch yet thanks to a non-fun-at-all side track).
On Sun, 25 Nov 2012, Eric S. Raymond wrote:
> Nguyen Thai Ngoc Duy :
> > The
On Sun, Nov 25, 2012 at 11:33 AM, Eric S. Raymond wrote:
> Pat Thoyts :
>> Git for Windows simply ships everything we need to run git - so if a
>> desirable module requires a version of python, we will add that
>> version plus any required modules into the installer. We already have
>> a patch to
Hi David. One minor but important correction ...
On 11/25/2012 12:51 PM, David Lang wrote:
>
> You may think that C and Bash are poor choices, but that is what the
> community is familar with.
>
Actually, it is C and POSIX shell -- not merely bash. Indeed, the shell
code in Git is expected to wo
On Sun, 25 Nov 2012, Eric S. Raymond wrote:
Michael Haggerty :
There is, of course, the awkward issue of how/when to transition to
Python 3.x, which is *not* backwards compatible with Python 2.x. I
expect that when the time comes there will be volunteers (myself
included) willing to help adapt
On Sun, Nov 25, 2012 at 10:54 AM, Eric S. Raymond wrote:
> Felipe Contreras :
>> On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond wrote:
>> > Nguyen Thai Ngoc Duy :
>> >> These may apply to other languages as well. Where do we draw a line?
>> >
>> > I'm in favor of the general policy of avoiding
On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty wrote:
> On 11/25/2012 09:53 AM, Felipe Contreras wrote:
>> On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond wrote:
>>> 1) In 2012, we can specify a "floor" Python version of 2.6 (shipped in
>>> 2008) and be pretty much guaranteed it will be anyw
On Sun, Nov 25, 2012 at 5:44 PM, Michael Haggerty wrote:
> On the contrary, there is *constant* traffic on the mailing list about
> incompatibilities between different shell implementations (sh, dash,
> bash, etc), not to mention those in other utilities (sed, grep, etc)
> that one is forced to wo
On Sun, Nov 25, 2012 at 10:53 AM, Eric S. Raymond wrote:
> Felipe Contreras :
>> If your friends jump off a bridge, would you? Yes, using python has
>> served them well, but as opposed to what? Other scripting languages? I
>> don't think so.
>
> The competition that Python won was *precisely* agai
Michael Haggerty :
> There is, of course, the awkward issue of how/when to transition to
> Python 3.x, which is *not* backwards compatible with Python 2.x. I
> expect that when the time comes there will be volunteers (myself
> included) willing to help adapt Python scripts to the new version, but
On 11/25/2012 09:53 AM, Felipe Contreras wrote:
> On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond wrote:
>> 1) In 2012, we can specify a "floor" Python version of 2.6 (shipped in
>> 2008) and be pretty much guaranteed it will be anywhere we want to
>> deploy except Windows. Windows will remain a
Pat Thoyts :
> Git for Windows simply ships everything we need to run git - so if a
> desirable module requires a version of python, we will add that
> version plus any required modules into the installer. We already have
> a patch to provide python in the msysgit tree - it would just require
> pol
On 25 November 2012 03:15, Nguyen Thai Ngoc Duy wrote:
> CCing msysgit. I vaguely remember they had problems with building
> Python on Windows. I don't know if it's still an issue.
>
> On Sun, Nov 25, 2012 at 9:44 AM, Eric S. Raymond wrote:
>> git presently contains one Python extension command,
Johannes Sixt :
> Am 25.11.2012 03:44, schrieb Eric S. Raymond:
> > That, among other things, means up-to-date versions of Python are
> > ubiquitous unless we're looking at Windows - in which case Perl and
> > shell actually become much bigger portability problems.
>
> You seem to ignore that more
Felipe Contreras :
> On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond wrote:
> > Nguyen Thai Ngoc Duy :
> >> These may apply to other languages as well. Where do we draw a line?
> >
> > I'm in favor of the general policy of avoiding scripting languages
> > other than the top three most widely depl
Felipe Contreras :
> If your friends jump off a bridge, would you? Yes, using python has
> served them well, but as opposed to what? Other scripting languages? I
> don't think so.
The competition that Python won was *precisely* against other scripting
languages, notably shell and Perl. Both used
Am 25.11.2012 03:44, schrieb Eric S. Raymond:
> That, among other things, means up-to-date versions of Python are
> ubiquitous unless we're looking at Windows - in which case Perl and
> shell actually become much bigger portability problems.
You seem to ignore that more than a quater of users are
On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond wrote:
> Nguyen Thai Ngoc Duy :
>> These may apply to other languages as well. Where do we draw a line?
>
> I'm in favor of the general policy of avoiding scripting languages
> other than the top three most widely deployed. At the moment that
> mea
On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond wrote:
> git presently contains one Python extension command, Pete Wycoff's p4
> importer. If my git-weave code is merged it will acquire another.
> I think we can expect more submissions of Python extensions in the
> future, for two good reasons:
Nguyen Thai Ngoc Duy :
> These may apply to other languages as well. Where do we draw a line?
I'm in favor of the general policy of avoiding scripting languages
other than the top three most widely deployed. At the moment that
means shell, Python, Perl; on present trends, in a few years Perl
(dro
git presently contains one Python extension command, Pete Wycoff's p4
importer. If my git-weave code is merged it will acquire another.
I think we can expect more submissions of Python extensions in the
future, for two good reasons:
1. Python has a much richer type ontology than shell; there ar
76 matches
Mail list logo
