On Wed, Dec 12, 2012 at 7:43 AM, Eric S. Raymond e...@thyrsus.com wrote:
Patrick Donnelly batr...@batbytes.com:
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
On Wed, Dec 12, 2012 at 02:03:56AM -0500, Patrick Donnelly wrote:
On Wed, Dec 12, 2012 at 1:32 AM, Jeff King p...@peff.net 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
Joshua Jensen jjen...@workspacewhiz.com:
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
Jeff King p...@peff.net:
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
On Wed, Dec 12, 2012 at 07:26:25AM -0500, Eric S. Raymond wrote:
Jeff King p...@peff.net:
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
Jeff King p...@peff.net 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
Andrew Ardill andrew.ard...@gmail.com writes:
On 13 December 2012 04:49, Junio C Hamano gits...@pobox.com wrote:
bisect with used-to-be, now-is vs
good, bad issue unsettled
Would you want to see this issue resolved in-script before a porting
attempt was started?
Honestly, I do not care too
On Tue, Dec 11, 2012 at 11:14 AM, Patrick Donnelly batr...@batbytes.com 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
Hi Sitaram,
On Tue, Dec 11, 2012 at 7:09 PM, Sitaram Chamarty sitar...@gmail.com wrote:
On Tue, Dec 11, 2012 at 11:14 AM, Patrick Donnelly batr...@batbytes.com
wrote:
Lua has been an incredible success for Nmap [2](and other projects).
As an embedded scripting language, it's unrivaled in
On Wed, 12 Dec 2012 05:39:43 +0530, Sitaram Chamarty sitar...@gmail.com 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
On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
tomas.carne...@gmail.com 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));
}
Hi Duy,
On Tue, Dec 11, 2012 at 8:50 PM, Nguyen Thai Ngoc Duy pclo...@gmail.com wrote:
On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
tomas.carne...@gmail.com 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
Sitaram Chamarty sitar...@gmail.com:
[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
On Wed, 12 Dec 2012 08:50:27 +0700, Nguyen Thai Ngoc Duy pclo...@gmail.com
wrote:
On Wed, Dec 12, 2012 at 7:53 AM, Tomas Carnecky
tomas.carne...@gmail.com 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
- 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
- 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
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
Hi Jeff,
On Wed, Dec 12, 2012 at 1:32 AM, Jeff King p...@peff.net 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
Hi Eric,
On Tue, Dec 11, 2012 at 10:30 PM, Eric S. Raymond e...@thyrsus.com 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
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 pclo...@gmail.com wrote:
The most important issues to
On Mon, Dec 3, 2012 at 3:45 PM, Philippe Vaucher
philippe.vauc...@gmail.com 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.
- Original Message -
From: Felipe Contreras felipe.contre...@gmail.com
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
python does not.
Out
On Sat, Nov 24, 2012 at 9:44 PM, Eric S. Raymond e...@thyrsus.com 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
On Tuesday, November 27, 2012 at 19:10 EST,
Felipe Contreras felipe.contre...@gmail.com wrote:
On Tue, Nov 27, 2012 at 3:35 PM, Magnus Bäck ba...@google.com wrote:
While constant traffic probably overstates the issue, these are
not theoretical problems. I recall at least three cases in
On Tue, Nov 27, 2012 at 8:54 AM, David Aguilar dav...@gmail.com wrote:
On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces
*cough* git-cola *cough*
it runs everywhere. Yes, windows too. It's
On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar dav...@gmail.com 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
On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty sitar...@gmail.com wrote:
On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar dav...@gmail.com 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
On Sunday, November 25, 2012 at 06:40 EST,
Felipe Contreras felipe.contre...@gmail.com wrote:
On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty
mhag...@alum.mit.edu wrote:
[...]
On the contrary, there is *constant* traffic on the mailing list
about incompatibilities between
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
Magnus Bäck ba...@google.com:
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
On Wed, Nov 28, 2012 at 12:05 AM, Eric S. Raymond e...@thyrsus.com wrote:
Magnus Bäck ba...@google.com:
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
Le mardi 27 novembre 2012 02:51:04 David Aguilar a écrit :
On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty sitar...@gmail.com
wrote:
On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar dav...@gmail.com wrote:
*cough* git-cola *cough*
it runs everywhere. Yes, windows too. It's written in
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 tr
On Wed, Nov 28, 2012 at 1:51 AM, Jeff King p...@peff.net 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
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
- 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 by
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 e...@thyrsus.com wrote:
Krzysztof Mazur krzys...@podlesie.net:
What about embedded systems? git is also useful there. C and shell is
everywhere, python is not.
Supposing
On 11/25/2012 11:44 PM, Eric S. Raymond wrote:
Felipe Contreras felipe.contre...@gmail.com:
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
On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras
felipe.contre...@gmail.com 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
On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond e...@thyrsus.com 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
On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond e...@thyrsus.com wrote:
Nguyen Thai Ngoc Duy pclo...@gmail.com:
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
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
Pat Thoyts pattho...@gmail.com:
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
On 11/25/2012 09:53 AM, Felipe Contreras wrote:
On Sun, Nov 25, 2012 at 3:44 AM, Eric S. Raymond e...@thyrsus.com 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
Michael Haggerty mhag...@alum.mit.edu:
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
On Sun, Nov 25, 2012 at 5:44 PM, Michael Haggerty mhag...@alum.mit.edu 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
On Sun, Nov 25, 2012 at 10:54 AM, Eric S. Raymond e...@thyrsus.com wrote:
Felipe Contreras felipe.contre...@gmail.com:
On Sun, Nov 25, 2012 at 6:18 AM, Eric S. Raymond e...@thyrsus.com wrote:
Nguyen Thai Ngoc Duy pclo...@gmail.com:
These may apply to other languages as well. Where do we draw
On Sun, 25 Nov 2012, Eric S. Raymond wrote:
Michael Haggerty mhag...@alum.mit.edu:
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)
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 work
Felipe Contreras felipe.contre...@gmail.com:
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
David Lang da...@lang.hm:
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
Felipe Contreras felipe.contre...@gmail.com:
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
On Sun, Nov 25, 2012 at 6:50 PM, Eric S. Raymond e...@thyrsus.com wrote:
Felipe Contreras felipe.contre...@gmail.com:
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
On Sun, Nov 25, 2012 at 6:36 PM, Eric S. Raymond e...@thyrsus.com wrote:
Felipe Contreras felipe.contre...@gmail.com:
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,
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
On Sun, Nov 25, 2012 at 6:32 PM, Eric S. Raymond e...@thyrsus.com wrote:
Felipe Contreras felipe.contre...@gmail.com:
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,
Felipe Contreras felipe.contre...@gmail.com:
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
Krzysztof Mazur krzys...@podlesie.net:
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
On Mon, Nov 26, 2012 at 4:17 AM, Eric S. Raymond e...@thyrsus.com wrote:
Krzysztof Mazur krzys...@podlesie.net:
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
Nguyen Thai Ngoc Duy pclo...@gmail.com:
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
60 matches
Mail list logo
