subject:"Re\: \[Administrivia\] On ruby and contrib\/"

Re: [Administrivia] On ruby and contrib/

2013-06-09 Thread Ramkumar Ramachandra

Johannes Schindelin wrote:
 Correct.  The opinions of inactive community members and
 non-contributors are less useful.

 I humbly suggest to treat other people's contribution with the same
 respect you want yours' to be treated.

What?!  When did I disrespect other people's contributions?  git.git
is what it is today because of everyone's contributions: if I
disrespected them, why would I work on improving git?

My opinion has nothing to do with me, or my contributions.  I have
already stated multiple times on the list that I take no pride in my
contributions whatsoever*: I have no ego to speak of.  I said the
opinions of inactive community members and non-contributors are less
useful [than those of active contributors], and I'm still scratching
my head over what you inferred.  Do you think that the opinions of
inactive community members and non-contributors are _more_ valuable
than those of active contributors, or am I missing something?

* You'd know that if you read emails on the list.  But you don't, for
some mysterious unstated reason.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Administrivia] On ruby and contrib/

2013-06-09 Thread Junio C Hamano

Ramkumar Ramachandra artag...@gmail.com writes:

 Do you think that the opinions of
 inactive community members and non-contributors are _more_ valuable
 than those of active contributors, or am I missing something?

I am not Dscho, but it probably is worth saying this anyway.

6d297f81373e (Status update on merge-recursive in C, 2006-07-08)
stole merge-recursive.c from git-merge-recursive.py with an explicit
purpose of making sure that those without a working Python can
perform such a core operation like merge with Git without extra
forking.

The person who worked on it, as long as he knows that the project
not just accepted the patch and kept using the code but also that
the project understood the rationale behind that change, does not
necessarily have a reason to appear every week to interject comments
in discussions on any part of the system, even to proposed changes
to merge-recursive.c, as long as the original thing the change meant
to address is not broken (e.g. removing merge-recursive.c and add it
as a merge strategy written in Python or Ruby might trigger huh,
but ditching merge-recursive.c and replacing it with merge-replay.c
as long as it works would be a meh for him).

When otherwise silent old-timers feel a need to come during a
discussion that might affect the course of the project in a major
way, we should pay more attention, not less, to what they say (I am
not saying we should blindly follow).  They can explain why some
things are as they are, why some changes that may look like a good
idea did not work out and how they failed, etc.

Certainly the opinions from them are no less valuable.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Administrivia] On ruby and contrib/

2013-06-08 Thread Felipe Contreras

On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen pclo...@gmail.com wrote:
 On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
 johannes.schinde...@gmx.de 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?

---
#!/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.

-- 
Felipe Contreras
#include builtin.h
#include cache.h
#include fcntl.h

#undef NORETURN
#undef PATH_SEP

#include ruby.h

static VALUE shellwords;

struct cmd_struct {
	const char *cmd;
	int (*fn)(int, const char **, const char *);
	int option;
};

#define RUN_SETUP (1  0)
#define RUN_SETUP_GENTLY (1  1)
#define USE_PAGER (1  2)
#define NEED_WORK_TREE (1  3)

static struct cmd_struct commands[] = {
	{ rev-parse, cmd_rev_parse },
	{ show, cmd_show, RUN_SETUP },
};

static VALUE git_rb_backticks(int o_argc, VALUE *o_argv, VALUE ctx)
{
	int argc, i, old;
	int pipefd[2];
	const char **argv;
	char buf[0x1000];
	VALUE command;
	int do_read;
	struct cmd_struct *cmd = NULL;
	const char *prefix = NULL;

	if (strncmp(RSTRING_PTR(o_argv[0]), git , 4)) {
		VALUE port, result;
		port = rb_funcall(rb_cIO, rb_intern(popen), 1, o_argv[0]);
		result = rb_funcall(port, rb_intern(read), 0);
		rb_funcall(result, rb_intern(chomp!), 0);
		rb_io_close(port);
		return result;
	}

	command = rb_funcall(shellwords, rb_intern(shellsplit), 1, o_argv[0]);
	rb_ary_shift(command);

	argc = RARRAY_LEN(command);
	argv = xcalloc(sizeof(*argv), argc);

	VALUE *rarray = RARRAY_PTR(command);
	for (i = 0; i  argc; i++)
		argv[i] = RSTRING_PTR(rarray[i]);

	old = dup(1);
	i = pipe(pipefd);
	dup2(pipefd[1], 1);
	close(pipefd[1]);

	for (i = 0; i  ARRAY_SIZE(commands); i++) {
		struct cmd_struct *p = commands[i];
		if (strcmp(p-cmd, argv[0]))
			continue;
		cmd = p;
	}

	if (!cmd)
		rb_raise(rb_eArgError, unknown command: %s, argv[0]);

	if (cmd-option  RUN_SETUP)
		prefix = setup_git_directory();

	i = cmd-fn(argc, argv, prefix);
	rb_last_status_set(i, getpid());

	fflush(stdout);
	dup2(old, 1);

	i = read(pipefd[0], buf, sizeof(buf));
	if (buf[i - 1] == '\n')
		i -= 1;
	buf[i] = '\0';

	return rb_str_new(buf, i);
}

void Init_git(void)
{
	rb_require(shellwords);
	shellwords = rb_define_module(Shellwords);
	rb_define_global_function(`, git_rb_backticks, -1);
}

Re: [Administrivia] On ruby and contrib/

2013-06-08 Thread Felipe Contreras

On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen pclo...@gmail.com wrote:
 On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 The reviewer pool for code written in a new language _must_ be
 seeded by some from the current set of reviewers whose judgement
 I/we can trust.

 By that standard nothing will ever change. Ever.

 Even twenty years from now, you will still only trust people that are
 familiar with shell, Perl, and C. Because the only way to gain your
 trust, is by being proficient in shell, Perl, and C.

 I don't see why a trusted person cannot learn a new language and
 convince the community to give it a try (well given that enough
 reviewers support the new language, which was Junio's point).

I do. Raise your hand if you are interested in giving a try to Ruby
for Git's core given that somebody gives convincing reasons?

How many hands do you expect?

-- 
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Administrivia] On ruby and contrib/

2013-06-08 Thread Duy Nguyen

On Sat, Jun 8, 2013 at 5:08 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
 On Fri, Jun 7, 2013 at 9:23 PM, Duy Nguyen pclo...@gmail.com wrote:
 On Sat, Jun 8, 2013 at 3:24 AM, Felipe Contreras
 felipe.contre...@gmail.com wrote:
 The reviewer pool for code written in a new language _must_ be
 seeded by some from the current set of reviewers whose judgement
 I/we can trust.

 By that standard nothing will ever change. Ever.

 Even twenty years from now, you will still only trust people that are
 familiar with shell, Perl, and C. Because the only way to gain your
 trust, is by being proficient in shell, Perl, and C.

 I don't see why a trusted person cannot learn a new language and
 convince the community to give it a try (well given that enough
 reviewers support the new language, which was Junio's point).

 I do. Raise your hand if you are interested in giving a try to Ruby
 for Git's core given that somebody gives convincing reasons?

Personally, no additional runtime dependency  Ruby  Python. I don't
think Ruby is available on SunOS and I prefer not to build and install
Python nor Ruby myself to be able to use Git. So no hands from me.

 How many hands do you expect?

If not many hands show up, the Git community clearly is not ready to
adopt Ruby. Maybe ask again next year when Ruby is getting more
popular?
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Administrivia] On ruby and contrib/

2013-06-08 Thread Duy Nguyen

On Sat, Jun 8, 2013 at 5:02 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Fri, Jun 7, 2013 at 9:17 PM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Jun 6, 2013 at 11:22 PM, Johannes Schindelin
johannes.schinde...@gmx.de 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
---

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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

63 matches

Mail list logo