Re: [PATCH/RFC 0/7] Support for Ruby
On Mon, Sep 23, 2013 at 1:17 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Junio C Hamano wrote: In other words, now the Git user and developer community are strong and thriving, we should strive to make the core smaller, not larger, and encourage people to form more third party communities that specialise in the areas the participant of these communities are stronger than those who are involved in the core (e.g. like myself, Peff, Nico, Jonathan, etc.). For programs that talk remote-helper or credential-helper protocols, for example, it is wasteful to have them in our contrib/ and have the changes to them go through my tree, with the same coding style standard applied to the core, which would in the longer term only add unnecessary overhead to what they want to do and what their effort supply the users with. Of course, we can make the core smaller, by replacing all the perl/shell scripts with ruby ones. Sure, it would be better if all the scripts were rewritten in C, but that has been going on for years, and there's no end in sight, and not that much progress at all. So, it's fair to say that the rewrite to C is just not going to happen any time soon, and if we accept that, we should accept that an interim solution is needed, because Windows users are important and they are hurting right now, and that solution could definitely be Ruby. Rewriting scripts to C is hard, rewriting them to Ruby is easy, and one of the advantages of rewriting to Ruby, is that having the C-Ruby bindings available would make it easy to replace part of the scripts chunk by chunk, so we could have a half Ruby, half C script, and eventually 100% C. This is a practical solution, it's a realistic path to move forward, not one based on wishful thinking and intentions that never get realized. Once again, the perfect being the enemy of the good in the Git project, even when the good leads to perfect. I think I've pretty much demonstrated that Ruby would be an excellent tool to make the code smaller with my 44 patch series. -- 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: [PATCH/RFC 0/7] Support for Ruby
On Sun, Sep 22, 2013 at 8:41 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Sun, Sep 22, 2013 at 05:00:44PM -0700, Junio C Hamano wrote: - Moving away from higher-level scripting languages such as shell and Perl. Recent clean --interactive may have added some code that could be reused for a rewrite of add -i (which I think is in Perl), for example. The minimum You need to have these to use Git should be made more portable by doing *less* in shell or Perl, not by adding more in the higher- level languages, and certainly not by adding other languages, be it Ruby or Lua. I can certainly go for that. C is faster and the codebase can be more consistent (and more portable to non-Unix). My concern was that if we're going to be adding additional languages, some previous warning would be appropriate. As I said, I wouldn't be able to deploy a git using Ruby immediately, and I'm sure I'm not the only one. If we're not going to be adding another language, then obviously the issue becomes moot. You could just build with NO_RUBY=y. Problem solved. -- 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: [PATCH/RFC 0/7] Support for Ruby
On Sat, Sep 21, 2013 at 6:56 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Sat, Sep 21, 2013 at 05:52:05PM -0500, Felipe Contreras wrote:
On Sat, Sep 21, 2013 at 4:29 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
Now, if anybody has ideas into how the bindings could be more object
oriented, I'm all ears, but unfortunately what I foresee is that
nobody will consider this proposal seriously.
My concern is that the Ruby code will end up not being idiomatic, and
people will view it as bizarre and unmaintainable.
for_each_ref could end up being something like REPOSITORY.refs.each,
which would be more idiomatic. repository.refs would probably be an
Enumerator in that case. If the decision is made to incorporate Ruby
code, I'm happy to submit some patches to help provide a sane interface,
even though I'm not that familiar with Ruby.
I think my proposed bindings are quite idiomatic.
git ruby - master origin/master EOF
commits = ARGV.map { |id| Git::Commit.get(get_sha1(id)) }
puts get_merge_bases(commits, 0).map { |commit| sha1_to_hex(commit.sha1) }
EOF
--
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: [PATCH/RFC 0/7] Support for Ruby
Hello Felipe, On Sun, Sep 22, 2013 at 4:29 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Sep 22, 2013 at 3:12 AM, Fredrik Gustafsson iv...@iveqy.com wrote: And see my humble test of what the speedup would be for git-submodule even with a faulty lua integration (still forking... but huge performance boost anyway): http://thread.gmane.org/gmane.comp.version-control.git/228031/focus=228051 I don't see how that is relevant, but I'm certain the same can be done with Ruby. As you can see a lua integration would increase the git binary with 300kb. And my patch would increase it 49Kb. Unless you statically compile in Ruby (which is what the above quoted 300kb implied for Lua, in actually it is less than 200kb). [Also good luck statically compiling Python/Ruby into an executable.] IMO the problem with lua is that it's too simple, it's syntax doesn't resemble c, perl, python, shell, or ruby, it's just weird. Also, it's much less popular, it's not as powerful, and there isn't a big community involved with Git like with Ruby. *sigh*. At this point you've really cemented your purpose here as a language evangelist. It's unfortunate I have to reply to dismiss this FUD (which you complained about earlier, ironically) otherwise community accepts it as fact (oh, I remember some guys saying Lua was a language for idiots...). Lua is by no means *simple*. Try small or lightweight. Its syntax is engineered to be readable and amateur friendly. You've placed Ruby on a pedestal alongside those other major languages but its syntax doesn't resemble any of those. Also, it's much less popular https://sites.google.com/site/marbux/home/where-lua-is-used The hallmark of a good embedded language is your users don't even know it is there. it's not as powerful, This is really funny to me. Despite Lua's small size, it has lead the way for modern dynamic language features, such as coroutines, block level scoping and real closure, incremental GC, a simple and usable C API (*yes* this is a feature), and a register based VM [1]. It is consistently placed as the *fastest* dynamic language in existence [e.g. 2]? The LuaJIT compiler often achieves competitive or better performance than C [3]. What about this isn't powerful? [1] Ierusalimschy, Roberto, Luiz Henrique De Figueiredo, and Waldemar Celes Filho. The Implementation of Lua 5.0. J. UCS 11.7 (2005): 1159-1176. [2] http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=alllang=lualang2=yarvdata=u32 [3] http://luajit.org/performance_x86.html -- Patrick Donnelly -- 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: [PATCH/RFC 0/7] Support for Ruby
On Mon, Sep 23, 2013 at 1:20 PM, Patrick Donnelly batr...@batbytes.com wrote: Hello Felipe, On Sun, Sep 22, 2013 at 4:29 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Sep 22, 2013 at 3:12 AM, Fredrik Gustafsson iv...@iveqy.com wrote: And see my humble test of what the speedup would be for git-submodule even with a faulty lua integration (still forking... but huge performance boost anyway): http://thread.gmane.org/gmane.comp.version-control.git/228031/focus=228051 I don't see how that is relevant, but I'm certain the same can be done with Ruby. As you can see a lua integration would increase the git binary with 300kb. And my patch would increase it 49Kb. Unless you statically compile in Ruby (which is what the above quoted 300kb implied for Lua, in actually it is less than 200kb). [Also good luck statically compiling Python/Ruby into an executable.] Yes, but that's not what the words said, the words said 'lua integration' and 'ruby integration' would take that much. Either way it doesn't matter, shared libraries exist for a reason. We don't need to statically compile openssl do we? No? Good. IMO the problem with lua is that it's too simple, it's syntax doesn't resemble c, perl, python, shell, or ruby, it's just weird. Also, it's much less popular, it's not as powerful, and there isn't a big community involved with Git like with Ruby. *sigh*. At this point you've really cemented your purpose here as a language evangelist. It's unfortunate I have to reply to dismiss this FUD (which you complained about earlier, ironically) otherwise community accepts it as fact (oh, I remember some guys saying Lua was a language for idiots...). I dismissed the claim as FUD, when the conclusion was exaggerated, and there was no evidence in sight. When I say Ruby is a superior alternative, I provide evidence. Lua is by no means *simple*. Try small or lightweight. Its syntax is engineered to be readable and amateur friendly. You've placed Ruby on a pedestal alongside those other major languages but its syntax doesn't resemble any of those. Also, it's much less popular https://sites.google.com/site/marbux/home/where-lua-is-used The hallmark of a good embedded language is your users don't even know it is there. Users don't even know in what language those projects are programmed, that's irrelevant. If MediaWiki does indeed use Lua, it must be a tiny fraction of it. Lua is #25 in the tiobe index with 0.518%, Ruby is #13 with 1.382%, right next to Perl. Ruby is 54 times used more in GitHub than Lua. These are the numbers I have, if you have other numbers, please, share them. it's not as powerful, This is really funny to me. Despite Lua's small size, it has lead the way for modern dynamic language features, such as coroutines, block level scoping and real closure, incremental GC, a simple and usable C API (*yes* this is a feature), and a register based VM [1]. It is consistently placed as the *fastest* dynamic language in existence [e.g. 2]? The LuaJIT compiler often achieves competitive or better performance than C [3]. What about this isn't powerful? Talk is cheap, show me the code. Do what I did. Add lua bindings for several C functions, replace a script with a Lua script (like git request-pull), replace a major builtin (like git reset), and show how this succinct example I provided in Ruby would look like: cb_data = 'foo' for_each_ref() do |name, sha1, flags| puts '%s: %s: %s' % [cb_data, name, sha1_to_hex(sha1)] end Let's see how it looks. Until you do that, I'd say you are the one that is language evangelizing, I'm providing an actual real solution to a very important problem. -- 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: [PATCH/RFC 0/7] Support for Ruby
Junio C Hamano wrote: [on vacaion, with only gmail webmail UI; please excuse me if this message comes out badly formatted or gets dropped by vger.kernel.org] On Sat, Sep 21, 2013 at 4:56 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Sat, Sep 21, 2013 at 05:52:05PM -0500, Felipe Contreras wrote: On Sat, Sep 21, 2013 at 4:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: As Junio has also pointed out in the past, there are people who aren't able to use Ruby in the same way that they are Perl and Python. If it's announced now, Git 2.0 might be a good time to start accepting Ruby scripts, as that will give people time to plan for its inclusion. In the very beginning, the codebase and development community of Git was very small. In order to give usability and also easy availability of minimally sufficient features, we used shell and Perl for quicker turn-around and implementation and included these Porcelain scripts written in higher level languages in the same package as the core Git. We should look at use of shell and Perl as necessary evil in that context, not as an enabler for people who do not want to write in C. It is no longer 2005 and the enabler side has a much more suited project for it these days. Namely, it is better served by various language-binding efforts around libgit2. Binding that takes advantage of each specific language is better done over there, I think. Cf. http://www.youtube.com/watch?v=4ZWqr6iih3s If libgit2 is so good as a library to interact with Git repositories, why isn't Git using it? Because it's not. It is a necessary evil due to the fact that Git developers neglected to write code in a reusable manner so other people could utilize libgit. So somebody else had to step up, so now we have two code-bases. If anything, I think the core side should be focused on three things (in addition to bug-fixes, of course) in the longer term: - Defining and implementing necessary improvements to the core on-file and on-the-wire data structures and the protocols to serve as the canonical implementation. - Moving away from higher-level scripting languages such as shell and Perl. Recent clean --interactive may have added some code that could be reused for a rewrite of add -i (which I think is in Perl), for example. The minimum You need to have these to use Git should be made more portable by doing *less* in shell or Perl, not by adding more in the higher- level languages, and certainly not by adding other languages, be it Ruby or Lua. - Giving solid interface to the outside world, e.g. remote-helpers, credential- helpers API, and let the users and developers that want to use them do their own projects, without adding things to contrib/. It's interesting how none of these goals reflect what the users want: https://www.survs.com/results/QPESOB10/ME8UTHXM4M 1. Better user-interface 2. Better documentation 3. GUI tools Do you deny this is what users want? Or you just don't care? I'm not trying to antagonize you, I just truly don't understand how something so obvious for so many users just doesn't even factor into your decision making as what needs to be done. In other words, now the Git user and developer community are strong and thriving, we should strive to make the core smaller, not larger, and encourage people to form more third party communities that specialise in the areas the participant of these communities are stronger than those who are involved in the core (e.g. like myself, Peff, Nico, Jonathan, etc.). For programs that talk remote-helper or credential-helper protocols, for example, it is wasteful to have them in our contrib/ and have the changes to them go through my tree, with the same coding style standard applied to the core, which would in the longer term only add unnecessary overhead to what they want to do and what their effort supply the users with. Of course, we can make the core smaller, by replacing all the perl/shell scripts with ruby ones. Sure, it would be better if all the scripts were rewritten in C, but that has been going on for years, and there's no end in sight, and not that much progress at all. So, it's fair to say that the rewrite to C is just not going to happen any time soon, and if we accept that, we should accept that an interim solution is needed, because Windows users are important and they are hurting right now, and that solution could definitely be Ruby. Rewriting scripts to C is hard, rewriting them to Ruby is easy, and one of the advantages of rewriting to Ruby, is that having the C-Ruby bindings available would make it easy to replace part of the scripts chunk by chunk, so we could have a half Ruby, half C script, and eventually 100% C. This is a practical solution, it's a realistic path to move forward, not one based on wishful thinking and intentions that never get realized. Once again, the
Re: [PATCH/RFC 0/7] Support for Ruby
On Mon, Sep 23, 2013 at 2:53 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Yes, but that's not what the words said, the words said 'lua integration' and 'ruby integration' would take that much. Either way it doesn't matter, shared libraries exist for a reason. We don't need to statically compile openssl do we? No? Good. Uh, you're willfully ignoring the conversation about avoiding dependencies. One way to do that is to include and statically link Lua along with Git. The cost of doing that is 200kb. I know this because I actually do it for Nmap. IMO the problem with lua is that it's too simple, it's syntax doesn't resemble c, perl, python, shell, or ruby, it's just weird. Also, it's much less popular, it's not as powerful, and there isn't a big community involved with Git like with Ruby. *sigh*. At this point you've really cemented your purpose here as a language evangelist. It's unfortunate I have to reply to dismiss this FUD (which you complained about earlier, ironically) otherwise community accepts it as fact (oh, I remember some guys saying Lua was a language for idiots...). I dismissed the claim as FUD, when the conclusion was exaggerated, and there was no evidence in sight. When I say Ruby is a superior alternative, I provide evidence. You have provided *no* evidence. Lua is by no means *simple*. Try small or lightweight. Its syntax is engineered to be readable and amateur friendly. You've placed Ruby on a pedestal alongside those other major languages but its syntax doesn't resemble any of those. Also, it's much less popular https://sites.google.com/site/marbux/home/where-lua-is-used The hallmark of a good embedded language is your users don't even know it is there. Users don't even know in what language those projects are programmed, that's irrelevant. *Absolutely relevant*: as normal git user *never* wants to know, care, or be exposed to the details of how `git` operates. If MediaWiki does indeed use Lua, it must be a tiny fraction of it. They just started using it. Well done cherry-picking 1 example from a host for your dismissal. it's not as powerful, This is really funny to me. Despite Lua's small size, it has lead the way for modern dynamic language features, such as coroutines, block level scoping and real closure, incremental GC, a simple and usable C API (*yes* this is a feature), and a register based VM [1]. It is consistently placed as the *fastest* dynamic language in existence [e.g. 2]? The LuaJIT compiler often achieves competitive or better performance than C [3]. What about this isn't powerful? Talk is cheap, show me the code. Do what I did. Add lua bindings for several C functions, replace a script with a Lua script (like git request-pull), replace a major builtin (like git reset), and show how this succinct example I provided in Ruby would look like: cb_data = 'foo' for_each_ref() do |name, sha1, flags| puts '%s: %s: %s' % [cb_data, name, sha1_to_hex(sha1)] end Let's see how it looks. I address your performance claims, you dismiss them and then ask for code to compare? Code which is primarily bindings to C which does all the work? No thanks, that circle jerk doesn't interest me. Until you do that, I'd say you are the one that is language evangelizing, I'm providing an actual real solution to a very important problem. As mentioned elsewhere, the solution Git is using is to move porcelain commands to C. You're manufacturing problems and spreading FUD. I'm letting this thread die as I only wanted to confront your baseless dismissal of Lua. If you want to continue this, I'll do it offlist. -- Patrick Donnelly -- 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: [PATCH/RFC 0/7] Support for Ruby
On Mon, Sep 23, 2013 at 2:20 PM, Patrick Donnelly batr...@batbytes.com wrote: On Mon, Sep 23, 2013 at 2:53 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Yes, but that's not what the words said, the words said 'lua integration' and 'ruby integration' would take that much. Either way it doesn't matter, shared libraries exist for a reason. We don't need to statically compile openssl do we? No? Good. Uh, you're willfully ignoring the conversation about avoiding dependencies. One way to do that is to include and statically link Lua along with Git. The cost of doing that is 200kb. I know this because I actually do it for Nmap. Dependencies are avoided when it's possible and sensible to do so. Yet, we still depend on a bunch of things. My proposal to replace perl/shell with ruby would actually remove two dependencies and add one, so in effect would remove one dependency. Of course, people could still build with NO_RUBY=y, just like they can build with NO_PERL=y, and deal with the consequences. IMO the problem with lua is that it's too simple, it's syntax doesn't resemble c, perl, python, shell, or ruby, it's just weird. Also, it's much less popular, it's not as powerful, and there isn't a big community involved with Git like with Ruby. *sigh*. At this point you've really cemented your purpose here as a language evangelist. It's unfortunate I have to reply to dismiss this FUD (which you complained about earlier, ironically) otherwise community accepts it as fact (oh, I remember some guys saying Lua was a language for idiots...). I dismissed the claim as FUD, when the conclusion was exaggerated, and there was no evidence in sight. When I say Ruby is a superior alternative, I provide evidence. You have provided *no* evidence. I have, you just chose to ignore it. Lua is by no means *simple*. Try small or lightweight. Its syntax is engineered to be readable and amateur friendly. You've placed Ruby on a pedestal alongside those other major languages but its syntax doesn't resemble any of those. Also, it's much less popular https://sites.google.com/site/marbux/home/where-lua-is-used The hallmark of a good embedded language is your users don't even know it is there. Users don't even know in what language those projects are programmed, that's irrelevant. *Absolutely relevant*: as normal git user *never* wants to know, care, or be exposed to the details of how `git` operates. So? Before and after this patch they still wouldn't be exposed. This is a total red herring. If MediaWiki does indeed use Lua, it must be a tiny fraction of it. They just started using it. Well done cherry-picking 1 example from a host for your dismissal. I didn't cherry pick anything, I used the project I'm more familiar with, replace MediaWiki with any other of your examples, and the claim still stands. it's not as powerful, This is really funny to me. Despite Lua's small size, it has lead the way for modern dynamic language features, such as coroutines, block level scoping and real closure, incremental GC, a simple and usable C API (*yes* this is a feature), and a register based VM [1]. It is consistently placed as the *fastest* dynamic language in existence [e.g. 2]? The LuaJIT compiler often achieves competitive or better performance than C [3]. What about this isn't powerful? Talk is cheap, show me the code. Do what I did. Add lua bindings for several C functions, replace a script with a Lua script (like git request-pull), replace a major builtin (like git reset), and show how this succinct example I provided in Ruby would look like: cb_data = 'foo' for_each_ref() do |name, sha1, flags| puts '%s: %s: %s' % [cb_data, name, sha1_to_hex(sha1)] end Let's see how it looks. I address your performance claims, you dismiss them and then ask for code to compare? Code which is primarily bindings to C which does all the work? No thanks, that circle jerk doesn't interest me. I didn't make any performance claims, you made claims about being a powerful language, well, let's see how powerful it is. Ruby is so powerful I was able to write these patches with moderate effort, surely if Lua is so powerful you can do the same. Until you do that, I'd say you are the one that is language evangelizing, I'm providing an actual real solution to a very important problem. As mentioned elsewhere, the solution Git is using is to move porcelain commands to C. You're manufacturing problems and spreading FUD. This effort has no end in sight, and as I've explained, using Ruby as an interim solution would actually speed up the move to pure C. In fact, I would know much more about the impediments since I sent twenty eight patches to start replacing 'git rebase' with C code: http://thread.gmane.org/gmane.comp.version-control.git/233396 They got rejected without so much as a reply. Why if it's so important to move the scripts to C did these patches get ignored? Because
Re: [PATCH/RFC 0/7] Support for Ruby
On Sun, Sep 22, 2013 at 12:36:51AM -0500, Felipe Contreras wrote: I think it's a bad idea to introduce an entirely new runtime, especially one known to occasionally blow up on less-common architectures, without some advance notice. This is just FUD. What do you mean blow up on less-common architectures? Do you have actual evidence or can we just dismiss that as a baseless argument? For example, at work I would not be able to deploy a git using Ruby immediately because Git is an RPM and Ruby is compiled from source, if it is even present at all. Again, what do you mean? In all the distributions I've seen, vim is compiled with Ruby support by default, so unless you think vim is an essoteric package, libruby is almost definetly packaged and available. It would actually be usefull to know stats on where git is runned. In my world of embedded computing, ruby support definitely isn't a standard, nor is glibc. As for architecture speaking I think it's important that git works on ARM since that architecture increases on the server market. I've no idea if this is a problem with ruby or not. Also, the only Python script that is shipped with Git is git-p4, which is essentially optional, since most git users probably do not use Perforce. Otherwise, all the scripts in git are shell or Perl. Neither perl, nor shell, nor python scripts solve the forking problem. My proposal does. It does, and so does Lua, which can be bundled with git and used in the configuration files as well and is pure ansi C. However bundling something has it bad sides too. At least this will solve the dependency problem. So let the language war begin =). -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- 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: [PATCH/RFC 0/7] Support for Ruby
On Sun, Sep 22, 2013 at 2:31 AM, Fredrik Gustafsson iv...@iveqy.com wrote: On Sun, Sep 22, 2013 at 12:36:51AM -0500, Felipe Contreras wrote: I think it's a bad idea to introduce an entirely new runtime, especially one known to occasionally blow up on less-common architectures, without some advance notice. This is just FUD. What do you mean blow up on less-common architectures? Do you have actual evidence or can we just dismiss that as a baseless argument? For example, at work I would not be able to deploy a git using Ruby immediately because Git is an RPM and Ruby is compiled from source, if it is even present at all. Again, what do you mean? In all the distributions I've seen, vim is compiled with Ruby support by default, so unless you think vim is an essoteric package, libruby is almost definetly packaged and available. It would actually be usefull to know stats on where git is runned. In my world of embedded computing, ruby support definitely isn't a standard, nor is glibc. I come from the embedded world as well, and I've never seen Git used there. I'd say Windows support is much more important than embedded, and we are not supporting that properly. Also, the only Python script that is shipped with Git is git-p4, which is essentially optional, since most git users probably do not use Perforce. Otherwise, all the scripts in git are shell or Perl. Neither perl, nor shell, nor python scripts solve the forking problem. My proposal does. It does, No, it does not. All the **current** perl/shell/python scripts use 'git foo' commands to achieve everything. and so does Lua, There is no lua in Git. which can be bundled with git and used in the configuration files as well and is pure ansi C. However bundling something has it bad sides too. At least this will solve the dependency problem. So let the language war begin =). Talk is cheap, show me the code. -- 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: [PATCH/RFC 0/7] Support for Ruby
On Sun, Sep 22, 2013 at 02:43:39AM -0500, Felipe Contreras wrote: It would actually be usefull to know stats on where git is runned. In my world of embedded computing, ruby support definitely isn't a standard, nor is glibc. I come from the embedded world as well, and I've never seen Git used there. I'd say Windows support is much more important than embedded, and we are not supporting that properly. Me neither, it doesn't mean that it isn't used though... I agree with the lack of windows support from git.git. However since Microsoft working with libgit2 on a Visual Studio plugin this it might be that the need for windows support decreases. Also, the only Python script that is shipped with Git is git-p4, which is essentially optional, since most git users probably do not use Perforce. Otherwise, all the scripts in git are shell or Perl. Neither perl, nor shell, nor python scripts solve the forking problem. My proposal does. It does, No, it does not. All the **current** perl/shell/python scripts use 'git foo' commands to achieve everything. As I said, It does meaning Your solution solves the forking problem. and so does Lua, There is no lua in Git. There's no ruby in git either as far as I know... (and no, I don't think contrib/ counts). which can be bundled with git and used in the configuration files as well and is pure ansi C. However bundling something has it bad sides too. At least this will solve the dependency problem. So let the language war begin =). Talk is cheap, show me the code. See this thread by Jeff King: http://thread.gmane.org/gmane.comp.version-control.git/206335/focus=206337 And see my humble test of what the speedup would be for git-submodule even with a faulty lua integration (still forking... but huge performance boost anyway): http://thread.gmane.org/gmane.comp.version-control.git/228031/focus=228051 As you can see a lua integration would increase the git binary with 300kb. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- 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: [PATCH/RFC 0/7] Support for Ruby
On Sun, Sep 22, 2013 at 3:12 AM, Fredrik Gustafsson iv...@iveqy.com wrote: On Sun, Sep 22, 2013 at 02:43:39AM -0500, Felipe Contreras wrote: It would actually be usefull to know stats on where git is runned. In my world of embedded computing, ruby support definitely isn't a standard, nor is glibc. I come from the embedded world as well, and I've never seen Git used there. I'd say Windows support is much more important than embedded, and we are not supporting that properly. Me neither, it doesn't mean that it isn't used though... I agree with the lack of windows support from git.git. Sure, it *might* be used, but I don't understand this fascination about worrying about hypothetical users, possibly non-existent, when we have real users to worry about, and in big numbers. However since Microsoft working with libgit2 on a Visual Studio plugin this it might be that the need for windows support decreases. I'll believe it when I see it. And then, when the users like it and don't report brokenness. Personally, I don't have much faith the in the libgit2 project, and it's ability to keep up with git.git. Also, the only Python script that is shipped with Git is git-p4, which is essentially optional, since most git users probably do not use Perforce. Otherwise, all the scripts in git are shell or Perl. Neither perl, nor shell, nor python scripts solve the forking problem. My proposal does. It does, No, it does not. All the **current** perl/shell/python scripts use 'git foo' commands to achieve everything. As I said, It does meaning Your solution solves the forking problem. Oh. and so does Lua, There is no lua in Git. There's no ruby in git either as far as I know... (and no, I don't think contrib/ counts). There is when you apply this patch. which can be bundled with git and used in the configuration files as well and is pure ansi C. However bundling something has it bad sides too. At least this will solve the dependency problem. So let the language war begin =). Talk is cheap, show me the code. See this thread by Jeff King: http://thread.gmane.org/gmane.comp.version-control.git/206335/focus=206337 That is very very far from what I'm doing. And see my humble test of what the speedup would be for git-submodule even with a faulty lua integration (still forking... but huge performance boost anyway): http://thread.gmane.org/gmane.comp.version-control.git/228031/focus=228051 I don't see how that is relevant, but I'm certain the same can be done with Ruby. As you can see a lua integration would increase the git binary with 300kb. And my patch would increase it 49Kb. IMO the problem with lua is that it's too simple, it's syntax doesn't resemble c, perl, python, shell, or ruby, it's just weird. Also, it's much less popular, it's not as powerful, and there isn't a big community involved with Git like with Ruby. Sure, for a couple of simple scripts lua bindings would be great, but for the future, better maintainability, and to grab future developers, Ruby is simply a better option. -- 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: [PATCH/RFC 0/7] Support for Ruby
[on vacaion, with only gmail webmail UI; please excuse me if this message comes out badly formatted or gets dropped by vger.kernel.org] On Sat, Sep 21, 2013 at 4:56 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Sat, Sep 21, 2013 at 05:52:05PM -0500, Felipe Contreras wrote: On Sat, Sep 21, 2013 at 4:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: As Junio has also pointed out in the past, there are people who aren't able to use Ruby in the same way that they are Perl and Python. If it's announced now, Git 2.0 might be a good time to start accepting Ruby scripts, as that will give people time to plan for its inclusion. In the very beginning, the codebase and development community of Git was very small. In order to give usability and also easy availability of minimally sufficient features, we used shell and Perl for quicker turn-around and implementation and included these Porcelain scripts written in higher level languages in the same package as the core Git. We should look at use of shell and Perl as necessary evil in that context, not as an enabler for people who do not want to write in C. It is no longer 2005 and the enabler side has a much more suited project for it these days. Namely, it is better served by various language-binding efforts around libgit2. Binding that takes advantage of each specific language is better done over there, I think. Cf. http://www.youtube.com/watch?v=4ZWqr6iih3s If anything, I think the core side should be focused on three things (in addition to bug-fixes, of course) in the longer term: - Defining and implementing necessary improvements to the core on-file and on-the-wire data structures and the protocols to serve as the canonical implementation. - Moving away from higher-level scripting languages such as shell and Perl. Recent clean --interactive may have added some code that could be reused for a rewrite of add -i (which I think is in Perl), for example. The minimum You need to have these to use Git should be made more portable by doing *less* in shell or Perl, not by adding more in the higher- level languages, and certainly not by adding other languages, be it Ruby or Lua. - Giving solid interface to the outside world, e.g. remote-helpers, credential- helpers API, and let the users and developers that want to use them do their own projects, without adding things to contrib/. In other words, now the Git user and developer community are strong and thriving, we should strive to make the core smaller, not larger, and encourage people to form more third party communities that specialise in the areas the participant of these communities are stronger than those who are involved in the core (e.g. like myself, Peff, Nico, Jonathan, etc.). For programs that talk remote-helper or credential-helper protocols, for example, it is wasteful to have them in our contrib/ and have the changes to them go through my tree, with the same coding style standard applied to the core, which would in the longer term only add unnecessary overhead to what they want to do and what their effort supply the users with. For that, defining a good inter-system interface boundary is essential on the core side, but we do not need to (and I do not want to see us on the core side doing) design and implement the other side that talks to us, which people may write in their favorite higher-level languages. We define a reasonably robust object history transfer mechanism over SSH connection with set of necessary hooks to customize what happens when a push and a fetch is requested, and Sitaram built Gitolite totally outside the core. I think that is the kind of thing we want to see *more* in this community. Was it better if we defined in the core how hosting service is to be done and implemented one ourselves? I do not think so. Similarly for Michael Haggerty's iMerge, which was done outside the core. -- 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: [PATCH/RFC 0/7] Support for Ruby
On Sun, Sep 22, 2013 at 05:00:44PM -0700, Junio C Hamano wrote: - Moving away from higher-level scripting languages such as shell and Perl. Recent clean --interactive may have added some code that could be reused for a rewrite of add -i (which I think is in Perl), for example. The minimum You need to have these to use Git should be made more portable by doing *less* in shell or Perl, not by adding more in the higher- level languages, and certainly not by adding other languages, be it Ruby or Lua. I can certainly go for that. C is faster and the codebase can be more consistent (and more portable to non-Unix). My concern was that if we're going to be adding additional languages, some previous warning would be appropriate. As I said, I wouldn't be able to deploy a git using Ruby immediately, and I'm sure I'm not the only one. If we're not going to be adding another language, then obviously the issue becomes moot. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
[PATCH/RFC 0/7] Support for Ruby
Hi,
It was discussed before that there was a need to replace Git scripts from perl
and sh that utilize the 'git' binary to do everything they need, which requires
many forks, and that creates problems on platforms like Windows.
This is a first step meant to show how a solution using Ruby would look like.
Other alternatives just don't cut it. Shell scripts are too simple, and
invariably require forks. Perl could use Git's internal C code, but it's syntax
is too cumbersome and it's loosing more and more popularity. Python and Ruby
are the only modern languages that could fit all the needs, but Python's syntax
is not ideal, specially considering the background of the Git community, and
also, Ruby's C extensibility is simply superb.
This patch series introduces Ruby bindings for Git's C internal library, and
add example commands to show how it could be used, and how it resembles the
original C code, shell code, and perl code. Basically, Ruby fits like a glove.
== Syntax ==
First of all, the syntax of Ruby is very similar to other languages used by Git:
C:
if (a b || (c FLAG) != 0)
return 0
else
break
end
printf(format: %s: %i\n, this string, 0)
count += 1
Shell:
out = `git rev-parse #{committish}`
str = EOF
multi
line
string
EOF
Perl
var ||= 'default'
The following Perl code:
sub abbr {
my $ref = shift;
if ($ref =~ m{^refs/heads/(.*)$}) {
return $1;
}
return $ref;
}
Looks like this in Ruby:
def abbr(ref)
if (ref =~ %r{^refs/heads/(.*)$}m)
return $1
end
return ref
end
== C bindings ==
It's extremely easy to write wrappers for Git's C functions:
static VALUE git_rb_get_git_dir(VALUE self)
{
return rb_str_new2(get_git_dir());
}
rb_define_global_function(get_git_dir, git_rb_get_git_dir, 0);
Then in Ruby:
dir = get_git_dir()
== Much more ==
Ruby's power allows for plenty of extensibility.
For example:
p `echo yes`
= yes\n
Usually we want to chomp the last new line. Fortunately everything is open in
Ruby, so it's possible to override the `() method:
def `(cmd)
IO.popen(cmd) { |pipe| pipe.read.chomp }
end
Now:
p `echo yes`
= yes
Also, in shell, if we want to make sure a sequence of commands is executed, we
would do something like:
git command 1
git command 2
git command 3 ||
error
This gets specially troublesome the bigger the sequence. In Ruby:
def run(*args)
system(*args)
raise RuntimeError unless $?.success?
end
begin
run('git command 1')
run('git command 2')
run('git command 3')
rescue RuntimeError
error
end
Finally, Ruby has the concept of blocks:
def run_with_lock()
puts lock
yield
puts unlock
end
branch = 'master'
run_with_lock() do
puts do stuff with #{branch}
end
Notice how the block inside run_with_lock() is able to access the 'branch'
variable, because it's in it's context, but the block is not actually called
until run_with_lock() calls 'yield'.
Python has a similar concept, but not nearly as powerful.
== Upgrade path ==
Ruby 2.0 didn't suffer the problems Python 3 is suffering because they have a
sane upgrade path.
Ruby 1.9 changed the syntax, so people using 1.8 had to do minor changes to
upgrade to 1.9, but they didn't miss many major features. After people updated
to 1.9, 2.0 came along with major features, but it was compatible with 1.9, so
nobody had to do any further changes.
Either way, it's still possible to run code that works in 1.8, 1.9, and 2.0.
== Community ==
The Ruby community is already heavily engaged in Git, as statistics in GitHub
show, plenty of Ruby projects use Git, outnumbering by far the Python ones.
There might be some correlation based on the fact that Mercurial is written in
Python.
http://adambard.com/blog/top-github-languages-for-2013-so-far/
== Conclusion ==
Ruby is an extremly powerful modern language, it features object oriented
paradigm, as well as functional, and procedural. It borrows from languages such
as C, Perl, and many others.
It's possible that by opening the possibilities to write Ruby scripts, many
Ruby developers would join the effort to improve Git.
Felipe Contreras (7):
Add support for ruby commands
ruby: add setup script
ruby: add simple wrappers
ruby: rewrite 'request-pull'
ruby: rewrite perl script
ruby: remove one fork
ruby: rewrite 'reset'
Makefile| 16 +-
cache.h | 2 +
git-rb-setup.rb | 125 +
git-refs.rb | 7 +
git-request-pull.rb | 159
git-request-pull.sh | 162 -
git-reset.rb| 223 +++
git.c | 4 +-
ruby.c | 511
9 files changed, 1044 insertions(+), 165 deletions(-)
create mode 100644 git-rb-setup.rb
create mode 100644 git-refs.rb
create mode 100644 git-request-pull.rb
delete mode 100755
Re: [PATCH/RFC 0/7] Support for Ruby
On Sat, Sep 21, 2013 at 01:48:08PM -0500, Felipe Contreras wrote: Hi, It was discussed before that there was a need to replace Git scripts from perl and sh that utilize the 'git' binary to do everything they need, which requires many forks, and that creates problems on platforms like Windows. This is a first step meant to show how a solution using Ruby would look like. Other alternatives just don't cut it. Shell scripts are too simple, and invariably require forks. Perl could use Git's internal C code, but it's syntax is too cumbersome and it's loosing more and more popularity. Python and Ruby are the only modern languages that could fit all the needs, but Python's syntax is not ideal, specially considering the background of the Git community, and also, Ruby's C extensibility is simply superb. This patch series introduces Ruby bindings for Git's C internal library, and add example commands to show how it could be used, and how it resembles the original C code, shell code, and perl code. Basically, Ruby fits like a glove. A couple of things: first, I'm not opposed in principle to using Ruby for git. As you say, it's a good language and it has much nicer C bindings. As Junio has also pointed out in the past, there are people who aren't able to use Ruby in the same way that they are Perl and Python. If it's announced now, Git 2.0 might be a good time to start accepting Ruby scripts, as that will give people time to plan for its inclusion. On a more technical note, my objection to your binding implementation is that fundamentally, Ruby is an object-oriented language, but your bindings don't take advantage of that; they're completely procedural. I realize most of the git codebase is as well, but that's because it's written in C. It seems a shame not to take advantage of what the language offers, especially since I know others are going to want to take advantage of the provided bindings. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH/RFC 0/7] Support for Ruby
On Sat, Sep 21, 2013 at 4:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: On Sat, Sep 21, 2013 at 01:48:08PM -0500, Felipe Contreras wrote: Hi, It was discussed before that there was a need to replace Git scripts from perl and sh that utilize the 'git' binary to do everything they need, which requires many forks, and that creates problems on platforms like Windows. This is a first step meant to show how a solution using Ruby would look like. Other alternatives just don't cut it. Shell scripts are too simple, and invariably require forks. Perl could use Git's internal C code, but it's syntax is too cumbersome and it's loosing more and more popularity. Python and Ruby are the only modern languages that could fit all the needs, but Python's syntax is not ideal, specially considering the background of the Git community, and also, Ruby's C extensibility is simply superb. This patch series introduces Ruby bindings for Git's C internal library, and add example commands to show how it could be used, and how it resembles the original C code, shell code, and perl code. Basically, Ruby fits like a glove. A couple of things: first, I'm not opposed in principle to using Ruby for git. As you say, it's a good language and it has much nicer C bindings. As Junio has also pointed out in the past, there are people who aren't able to use Ruby in the same way that they are Perl and Python. If it's announced now, Git 2.0 might be a good time to start accepting Ruby scripts, as that will give people time to plan for its inclusion. Yes, and there are people who aren't able to use Perl/Python in the same way they use Ruby. That's why I tried to show why Ruby makes a perfect choice. On a more technical note, my objection to your binding implementation is that fundamentally, Ruby is an object-oriented language, but your bindings don't take advantage of that; they're completely procedural. I realize most of the git codebase is as well, but that's because it's written in C. It seems a shame not to take advantage of what the language offers, especially since I know others are going to want to take advantage of the provided bindings. For the moment the bindings are only for Git commands, so the primary users are Git developers, that's why I tried to leave them close to the current C/shell/perl code. Having said that, it does use a little bit of object-oriented stuff: commit = lookup_commit_reference(sha1) p commit.buffer Now, if anybody has ideas into how the bindings could be more object oriented, I'm all ears, but unfortunately what I foresee is that nobody will consider this proposal seriously. Cheers. -- 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: [PATCH/RFC 0/7] Support for Ruby
On Sat, Sep 21, 2013 at 05:52:05PM -0500, Felipe Contreras wrote: On Sat, Sep 21, 2013 at 4:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: As Junio has also pointed out in the past, there are people who aren't able to use Ruby in the same way that they are Perl and Python. If it's announced now, Git 2.0 might be a good time to start accepting Ruby scripts, as that will give people time to plan for its inclusion. Yes, and there are people who aren't able to use Perl/Python in the same way they use Ruby. That's why I tried to show why Ruby makes a perfect choice. I'm not arguing against Ruby. As I said, it's a nice language. I'm just saying that Ruby is not as common as Perl and Python. For example, in Debian, Perl is Essential (cannot be removed), Python is priority standard, and Ruby is priority optional. I think it's a bad idea to introduce an entirely new runtime, especially one known to occasionally blow up on less-common architectures, without some advance notice. For example, at work I would not be able to deploy a git using Ruby immediately because Git is an RPM and Ruby is compiled from source, if it is even present at all. Also, the only Python script that is shipped with Git is git-p4, which is essentially optional, since most git users probably do not use Perforce. Otherwise, all the scripts in git are shell or Perl. So this would be adding a significant additional dependency to core git, one which is likely not installed on many systems. Of the systems in the Debian popularity contest, 41% have git installed and 23% have ruby1.8 installed, with only 16% having the default ruby installed. Now, if anybody has ideas into how the bindings could be more object oriented, I'm all ears, but unfortunately what I foresee is that nobody will consider this proposal seriously. My concern is that the Ruby code will end up not being idiomatic, and people will view it as bizarre and unmaintainable. for_each_ref could end up being something like REPOSITORY.refs.each, which would be more idiomatic. repository.refs would probably be an Enumerator in that case. If the decision is made to incorporate Ruby code, I'm happy to submit some patches to help provide a sane interface, even though I'm not that familiar with Ruby. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH/RFC 0/7] Support for Ruby
brian m. carlson wrote: On Sat, Sep 21, 2013 at 05:52:05PM -0500, Felipe Contreras wrote: On Sat, Sep 21, 2013 at 4:29 PM, brian m. carlson sand...@crustytoothpaste.net wrote: As Junio has also pointed out in the past, there are people who aren't able to use Ruby in the same way that they are Perl and Python. If it's announced now, Git 2.0 might be a good time to start accepting Ruby scripts, as that will give people time to plan for its inclusion. Yes, and there are people who aren't able to use Perl/Python in the same way they use Ruby. That's why I tried to show why Ruby makes a perfect choice. I'm not arguing against Ruby. As I said, it's a nice language. I'm just saying that Ruby is not as common as Perl and Python. In my books Perl is only a tiny bit more common than Ruby. http://www.tiobe.com/content/paperinfo/tpci/index.html I think it's a bad idea to introduce an entirely new runtime, especially one known to occasionally blow up on less-common architectures, without some advance notice. This is just FUD. What do you mean blow up on less-common architectures? Do you have actual evidence or can we just dismiss that as a baseless argument? For example, at work I would not be able to deploy a git using Ruby immediately because Git is an RPM and Ruby is compiled from source, if it is even present at all. Again, what do you mean? In all the distributions I've seen, vim is compiled with Ruby support by default, so unless you think vim is an essoteric package, libruby is almost definetly packaged and available. Also, the only Python script that is shipped with Git is git-p4, which is essentially optional, since most git users probably do not use Perforce. Otherwise, all the scripts in git are shell or Perl. Neither perl, nor shell, nor python scripts solve the forking problem. My proposal does. So this would be adding a significant additional dependency to core git, one which is likely not installed on many systems. Another claim without a shred of evidence. It's the other way around, it's likely already installed, and it would not be an additional dependency if the current scripts get phased out in favor Ruby ones, or even better, C code. Of the systems in the Debian popularity contest, 41% have git installed and 23% have ruby1.8 installed, with only 16% having the default ruby installed. Plus the 17% of ruby1.9.1, you get 41%, exactly the same as Git. But we don't need ruby, all we need is libruby, which is 47%. Now, if anybody has ideas into how the bindings could be more object oriented, I'm all ears, but unfortunately what I foresee is that nobody will consider this proposal seriously. My concern is that the Ruby code will end up not being idiomatic, and people will view it as bizarre and unmaintainable. There is no such thing as idiomatic Ruby code. In Ruby there's no single best way to do something, there's many ways to do the same thing. for_each_ref could end up being something like REPOSITORY.refs.each, which would be more idiomatic. And how do you propose to achieve that if the C code doesn't support that? Do you have in mind the C code that would achieve that, or are you just saying? -- 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
