You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Garrett Rooney <ro...@electricjellyfish.net> on 2006/10/19 17:37:34 UTC
Higher level languages as part of the core of SVN
So, one of the contentious topics at the Subversion Summit earlier
this week was a choice of language for Subversion 2.0. There are many
people who want to think about things like using some subset of C++
for parts of the application (the "batons suck damn it, lets have
objects!" crowd), and many other people who hate C++ with the fires of
a thousand hells, and just don't want to see that happen.
Another group advocated (and I'm not sure how serious this was) the
idea of writing things like the command line client and other tools in
something like Python, rather than doing so in C. This kind of thing
would mean that our bindings would get a lot more attention, which
would be nice.
I'd like to propose another idea for how we could write parts of
Subversion itself (not just the command line clients, but actual
portions of the libraries) in a higher level language, but still
expose a C level interface to the rest of the world, without dealing
with the binary compatibility and other issues that come with C++.
Ideally I'd see us writing the code at the level of libsvn_client in a
language other than C, and that would call into things like libsvn_ra
and libsvn_wc. If we went forward with ideas like reimplementing the
working copy in a newer better faster way, we could decide then if it
would be written in C or something else.
So, the way I'd propose doing this would be to start making use of Lua
for our higher level language. Now this may seem a little weird,
since we don't even have Lua bindings at the moment, and most of you
have probably never used it, but bear with me here. Lua is a
scripting language that's designed to both embed C code (i.e. call
into C libraries, like we do with the bindings today) and be embedded
within C code (i.e. act as an embedded scripting language for a big
application, this is actually done within things like World of
Warcraft and other similar games). With decent Lua bindings for the
lower level performance critical parts of the application, we could
fairly easily implement chunks of the application in Lua, while still
providing a C interface that would enable us to build bindings for
other languages.
Actual code written in Lua looks pretty much like code in other common
scripting languages today. Here's an example:
-- defines a factorial function
function fact (n)
if n == 0 then
return 1
else
return n * fact(n-1)
end
end
print("enter a number:")
a = io.read("*number") -- read a number
print(fact(a))
That does basically what you expect it to.
The real kicker though, and the reason that Lua is in my opinion a
more practical solution than doing the same sort of thing in a
language like Perl or Ruby or Python is that Lua is tiny. The entire
lua5.1 interpreter on my Ubuntu machine is 124k. The actual Lua 5.1
codebase is just under 17000 lines of code, and is written in pure C89
(with the exception of some platform specific code for dlopen type
stuff, but it's already at least as portable as APR is, so no worries
there). It's also built for doing this sort of thing, calling C and
being called from it, which means it's far more practical to do things
like that in Lua than it is to do similar things in the other popular
scripting languages.
Anyway, this has gone on long enough, and it's really just something I
think people should think about, since it provides some intriguing
possibilities for the future. You can find more info on Lua at the
following URLs:
http://www.lua.org/ - The main Lua web site
http://www.luaforge.org/ - A site that hosts Lua related projects
http://www.swig.org/Doc1.3/Lua.html - The SWIG Lua docs
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/19/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> http://www.luaforge.org/ - A site that hosts Lua related projects
Oops.
s/www.luaforge.org/www.luaforge.net/
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Sun, Oct 29, 2006 at 11:16:34PM -0700, Justin Erenkrantz wrote:
> On 10/28/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> >I meant binary compatibility. My understanding from speaking to Dan
> >earlier was that g++/win32 follows the vendor-defined ABI (that is,
> >MSVC on Win32) for C++, so we should be okay as long as we don't expose
> >anything to do with an STL implementation.
>
> Messages on the GCC list earlier this year from Mark Mitchell hints
> that there is no ABI compatibility between MSVC and g++ and won't be
> any time soon:
>
> http://gcc.gnu.org/ml/gcc/2006-06/msg00911.html
>
Interesting. That's in direct opposition to what I thought Dan was
saying when we discussed this at the summit. Dan: did I misunderstand?
Regards,
Malcolm
Re: Higher level languages as part of the core of SVN
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/30/06, Daniel Berlin <db...@dberlin.org> wrote:
> It's not really that odd, it's the way it's always been, and not just
> for svn. I don't remember whether you can, for example, mix python
> extensions build with mingw32 and a python built with msvc right now
> (it might be possible, but i believe there are edge cases).
You can, but Python has a C extension interface, not a C++ interface.
This is what the MinGW folks say about building Python extensions:
http://www.mingw.org/MinGWiki/index.php/Python%20extensions
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Daniel Berlin <db...@dberlin.org>.
On 10/30/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> On Mon, Oct 30, 2006 at 10:04:48AM -0500, Daniel Berlin wrote:
> > Because seriously, on win32, people use MSVC compiled binaries, and
> > on unix, most people use packages or compile from source code.
> > So uh, which users are we worried about trying to mix incompatible
> > libraries?
> >
>
> If we're happy to say that win32 binary packages must always be built
> with Microsoft compilers, that's fine, but I got the impression that
> some people would like to be able to develop using non-Microsoft tools
> (mingw, g++/win32). And a decision that means that those people can't
> ever release a binary-compatible package seems odd.
It's not really that odd, it's the way it's always been, and not just
for svn. I don't remember whether you can, for example, mix python
extensions build with mingw32 and a python built with msvc right now
(it might be possible, but i believe there are edge cases).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Oct 30, 2006 at 10:04:48AM -0500, Daniel Berlin wrote:
> Because seriously, on win32, people use MSVC compiled binaries, and
> on unix, most people use packages or compile from source code.
> So uh, which users are we worried about trying to mix incompatible
> libraries?
>
If we're happy to say that win32 binary packages must always be built
with Microsoft compilers, that's fine, but I got the impression that
some people would like to be able to develop using non-Microsoft tools
(mingw, g++/win32). And a decision that means that those people can't
ever release a binary-compatible package seems odd.
Regards,
Malcolm
Re: Higher level languages as part of the core of SVN
Posted by Daniel Berlin <db...@dberlin.org>.
On 10/30/06, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On 10/28/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> > I meant binary compatibility. My understanding from speaking to Dan
> > earlier was that g++/win32 follows the vendor-defined ABI (that is,
> > MSVC on Win32) for C++, so we should be okay as long as we don't expose
> > anything to do with an STL implementation.
>
> Messages on the GCC list earlier this year from Mark Mitchell hints
> that there is no ABI compatibility between MSVC and g++ and won't be
> any time soon:
This is correct.
We can't implement the MSVC C++ ABI even if we wanted to, due to
patents. However, on all other platforms, the C++ ABI is cross-vendor
and compatible across compilers. If I gave the impressiont that we
follow the MSVC abi on win32, this was incorrect.
Anyway, this discussion is a bit, well odd.
I'd rather see it go like this:
Tell me what situation you believe users are going to run into C++
problems with, and i'll tell you how to solve it.
Because seriously, on win32, people use MSVC compiled binaries, and
on unix, most people use packages or compile from source code.
So uh, which users are we worried about trying to mix incompatible libraries?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 10/28/06, Malcolm Rowe <ma...@farside.org.uk> wrote:
> I meant binary compatibility. My understanding from speaking to Dan
> earlier was that g++/win32 follows the vendor-defined ABI (that is,
> MSVC on Win32) for C++, so we should be okay as long as we don't expose
> anything to do with an STL implementation.
Messages on the GCC list earlier this year from Mark Mitchell hints
that there is no ABI compatibility between MSVC and g++ and won't be
any time soon:
http://gcc.gnu.org/ml/gcc/2006-06/msg00911.html
HTH. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Malcolm Rowe <ma...@farside.org.uk>:
> I meant binary compatibility. My understanding from speaking to Dan
> earlier was that g++/win32 follows the vendor-defined ABI
Not quite. It follows the "Multi-vendor C++ ABI":
http://www.codesourcery.com/cxx-abi/
> (that is, MSVC on Win32) for C++,
MSVC++ does not follow the above ABI, and probably never will.
The Intel C++ compiler supports it, though.
> so we should be okay as long as we don't expose anything to do with
> an STL implementation.
Nope.
> It matters because we wouldn't want people to need to worry about
> whether the same compiler was used to compile the Subversion
> libraries as was used to compile the client (Tortoise, etc). This
> may become more of an issue on win32 in the future, as people were
> interested in making Subversion compile using e.g. mingw.
There may be ABI compatibility between the two C compilers. I thought
svn was mostly C?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Fri, Oct 27, 2006 at 10:21:45PM +0200, Steinar Bang wrote:
> >>>>> Malcolm Rowe <ma...@farside.org.uk>:
>
> > I think some people are also concerned about maintaining compatibility
> > across g++/win32 and MSVC/win32. Then, the STL (etc) is more of a concern.
>
> What kind of compatibility are you referring to? Source code
> compatiblity? Or binary compatiblity?
>
> If you're talking binary compatiblity between g++/Win32 and MSVC++,
> you don't have it, and I don't think you ever will. But I don't see
> why that would matter?
>
I meant binary compatibility. My understanding from speaking to Dan
earlier was that g++/win32 follows the vendor-defined ABI (that is,
MSVC on Win32) for C++, so we should be okay as long as we don't expose
anything to do with an STL implementation.
It matters because we wouldn't want people to need to worry about
whether the same compiler was used to compile the Subversion libraries
as was used to compile the client (Tortoise, etc). This may become more
of an issue on win32 in the future, as people were interested in making
Subversion compile using e.g. mingw.
Regards,
Malcolm
Re: Higher level languages as part of the core of SVN
Posted by Steinar Bang <sb...@dod.no>.
>>>>> Malcolm Rowe <ma...@farside.org.uk>:
> I think some people are also concerned about maintaining compatibility
> across g++/win32 and MSVC/win32. Then, the STL (etc) is more of a concern.
What kind of compatibility are you referring to? Source code
compatiblity? Or binary compatiblity?
If you're talking binary compatiblity between g++/Win32 and MSVC++,
you don't have it, and I don't think you ever will. But I don't see
why that would matter?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Thu, Oct 26, 2006 at 07:58:10PM -0400, Daniel Berlin wrote:
> We would not be the first people to try to maintain compatibility of a
> library over multiple versions of G++.
>
I think some people are also concerned about maintaining compatibility
across g++/win32 and MSVC/win32. Then, the STL (etc) is more of a concern.
> It's certainly not something that would make me throw up my hands and
> move to lua.
>
I think that the two things are orthogonal :-)
Regards,
Malcolm
Re: Higher level languages as part of the core of SVN
Posted by Daniel Berlin <db...@dberlin.org>.
>
> It is certainly a problem of similar scope, although not exposing
> stuff like the STL probably also means not using it internally, since
> it's kind of tricky to require the linking in of multiple STL
> implementations if we use one and the app using our libraries uses
> another.
No, no it isn't. This is why they inventing symbol versioning.
> Not saying it's impossible, just hard.
It depends on your solution.
If you wanted absolute full binary compatibility in absolutely all
cases, you'd just include STLPort as a dependency and be done with it,
since your real issue is libstdc++ not the C++ ABI.
This is not hard at all. Since the C++ ABI of gcc hasn't changed
since 4.0 (or maybe there was one super-corner case that was fixed in
4.1, but that could easily be fixed using -fabi-version to select an
abi version), this would buy you compatibility.
We would not be the first people to try to maintain compatibility of a
library over multiple versions of G++.
We won't be the last.
It's certainly not something that would make me throw up my hands and
move to lua.
;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Russell Hind <rh...@mac.com>.
Garrett Rooney wrote:
>
> It is certainly a problem of similar scope, although not exposing
> stuff like the STL probably also means not using it internally, since
> it's kind of tricky to require the linking in of multiple STL
> implementations if we use one and the app using our libraries uses
> another. Not saying it's impossible, just hard.
>
It would only mean not exposing STL constructs in libsvn_client wouldn't
it? As the entire project will typically be built with the same
compiler, then you can expose whatever constructs you like through the
other libs, just not in the one people may link to with their own compilers.
We generate both C and C++ interfaces in our libraries so people who use
the same compiler can use the C++ interface if they wish and others can
use the C interface. The entire project is C++ though.
Cheers
Russell
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Steinar Bang <sb...@dod.no>.
>>>>> "Garrett Rooney" <ro...@electricjellyfish.net>:
> It is certainly a problem of similar scope, although not exposing
> stuff like the STL probably also means not using it internally,
> since it's kind of tricky to require the linking in of multiple STL
> implementations if we use one and the app using our libraries uses
> another. Not saying it's impossible, just hard.
Granted linking with multiple "STL" implementations is a pain. But
why would you want to use multiple implementations of
that-subset-of-the-standard-C++-library-colloqually-known-as-"STL"
these days?
The native standard libraries of MSVC7 and g++3 and 4 (including mingw
and cygwin). are good enough to use, and have been so for quite a
while. (are there any other C++ compilers that are important these
days? SunPRO? Intel? If so, I'm guessing they have quite adequate
standard C++ libraries)
<unsolicited-lurker-advice>
On the note of the subject of this thread: stay with C unless you have
_really_ compelling reasons to change it. And if you have to change
it, change it to something in the mainstream.
</unsolicited-lurker-advice>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/21/06, Branko Čibej <br...@xbc.nu> wrote:
> Garrett Rooney wrote:
> > On 10/21/06, Branko Čibej <br...@xbc.nu> wrote:
> >> Garrett Rooney wrote:
> >> > I'd like to propose another idea for how we could write parts of
> >> > Subversion itself (not just the command line clients, but actual
> >> > portions of the libraries) in a higher level language, but still
> >> > expose a C level interface to the rest of the world, without dealing
> >> > with the binary compatibility and other issues that come with C++.
> >>
> >>
> >> I am continually amazed by the thousands of otherwise quite competent
> >> programmers who still believe that "C++" and "binary incompatibility"
> >> are two sides of the same coin, or that you can't expose a completely
> >> C-like interface from something compiled as C++.
> >>
> >> You can, and you can even provide a C++ API that has *no* binary
> >> compatibility issues, ever, on any platform (heh, that is, no more than
> >> any C API).
> >>
> >> Of course "API" and "implementation language" aren't related either,
> >> that's another bugaboo.
> >
> > No argument there, it's certainly possible to write in C++ yet avoid
> > the various types of binary incompatibility (i.e. don't expose
> > anything that depends on the STL).
>
> You mean, like, "don't expose anything that depends on APR?" :)
>
> Sorry, couldn't resist ...
It is certainly a problem of similar scope, although not exposing
stuff like the STL probably also means not using it internally, since
it's kind of tricky to require the linking in of multiple STL
implementations if we use one and the app using our libraries uses
another. Not saying it's impossible, just hard.
-garrett
Re: Higher level languages as part of the core of SVN
Posted by Branko Čibej <br...@xbc.nu>.
Garrett Rooney wrote:
> On 10/21/06, Branko Čibej <br...@xbc.nu> wrote:
>> Garrett Rooney wrote:
>> > I'd like to propose another idea for how we could write parts of
>> > Subversion itself (not just the command line clients, but actual
>> > portions of the libraries) in a higher level language, but still
>> > expose a C level interface to the rest of the world, without dealing
>> > with the binary compatibility and other issues that come with C++.
>>
>>
>> I am continually amazed by the thousands of otherwise quite competent
>> programmers who still believe that "C++" and "binary incompatibility"
>> are two sides of the same coin, or that you can't expose a completely
>> C-like interface from something compiled as C++.
>>
>> You can, and you can even provide a C++ API that has *no* binary
>> compatibility issues, ever, on any platform (heh, that is, no more than
>> any C API).
>>
>> Of course "API" and "implementation language" aren't related either,
>> that's another bugaboo.
>
> No argument there, it's certainly possible to write in C++ yet avoid
> the various types of binary incompatibility (i.e. don't expose
> anything that depends on the STL).
You mean, like, "don't expose anything that depends on APR?" :)
Sorry, couldn't resist ...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/21/06, Branko Čibej <br...@xbc.nu> wrote:
> Garrett Rooney wrote:
> > I'd like to propose another idea for how we could write parts of
> > Subversion itself (not just the command line clients, but actual
> > portions of the libraries) in a higher level language, but still
> > expose a C level interface to the rest of the world, without dealing
> > with the binary compatibility and other issues that come with C++.
>
>
> I am continually amazed by the thousands of otherwise quite competent
> programmers who still believe that "C++" and "binary incompatibility"
> are two sides of the same coin, or that you can't expose a completely
> C-like interface from something compiled as C++.
>
> You can, and you can even provide a C++ API that has *no* binary
> compatibility issues, ever, on any platform (heh, that is, no more than
> any C API).
>
> Of course "API" and "implementation language" aren't related either,
> that's another bugaboo.
No argument there, it's certainly possible to write in C++ yet avoid
the various types of binary incompatibility (i.e. don't expose
anything that depends on the STL). It just seems that if we're going
to jump through hoops to do that sort of thing in a C++
implementation, we might consider jumping through a similar number of
hoops to use a language that's a bit less prone to shooting oneself in
the foot.
-garrett
Re: Higher level languages as part of the core of SVN
Posted by Branko Čibej <br...@xbc.nu>.
Garrett Rooney wrote:
> I'd like to propose another idea for how we could write parts of
> Subversion itself (not just the command line clients, but actual
> portions of the libraries) in a higher level language, but still
> expose a C level interface to the rest of the world, without dealing
> with the binary compatibility and other issues that come with C++.
I am continually amazed by the thousands of otherwise quite competent
programmers who still believe that "C++" and "binary incompatibility"
are two sides of the same coin, or that you can't expose a completely
C-like interface from something compiled as C++.
You can, and you can even provide a C++ API that has *no* binary
compatibility issues, ever, on any platform (heh, that is, no more than
any C API).
Of course "API" and "implementation language" aren't related either,
that's another bugaboo.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/20/06, Giovanni Bajo <ra...@develer.com> wrote:
> Garrett Rooney wrote:
>
> >> I don't get this. You're suggesting a non-mainstream under-supported
> >> second-class higher level language, just because the interpeter has
> >> a lower footprint than, say, Python? I don't remember anyone being
> >> concerned with Mercurial's memory occupation, or svk's.
> >
> > It's not memory footprint I'm worrying about, it's dependencies. It's
> > practical to just bundle Lua with the system, it's not so reasonable
> > for Perl or Python or Ruby.
>
> I understand your concerns.
>
> Deployment of Python application has gone a long way nowadays. We can ship
> self-contained executables for Windows (like Mercurial does), and typically
> you can just "require" (assume) an existing Python installation on the
> system. If you write your Python code with some stricter rule, it will work
> on any Python version in the last 4-5 years, which is enough not to create
> too many headaches. If we are speaking of SVN 2.0 here, it will be several
> years in the future anyway. For now, a Python command line client could live
> as external contribution until it's more mature, and that'd raise even more
> the chances that having Python installed is not a problem anymore.
You're missing the point. I don't care about writing the actual
command line client in something like python, I care about being able
to actually use something that is not C to write the logic inside the
svn libraries, at least the bits that don't do any heavy computational
work.
> > I'm not advocating a C API for calling into the actual command line
> > code, just for calling into the kind of thing we put into
> > libsvn_client, which is theoretically client agnostic.
>
> How many libsvn_client users are there, in the wild? Is there any idea about
> this number?
I'm not so concerned about people calling directly into libsvn_client,
but in allowing people to do so via language bindings, which are
considerably easier to construct if libsvn_client has a C API, as
opposed to the gymnastics that would be required if it was written in
python.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Giuliano Gavazzi <de...@humph.com>.
On 26 Oct 2006, at 23:27, Barry Scott wrote:
>
> The pysvn WorkBench GUI is delivered as a binary application on
> Windows, Mac OS X and Unix.
Hi Barry,
I have tried your pysvn WorkBench and I have noticed that on MacOSX
where a KeyChain is available for storing passwords I get a plain
password written in the appropriate .svn file. This should not happen
if the authentication has already been performed using svn (command
line) and thus the credential stored in the keychain.
Perhaps you could do as I did for SCFinderPlugin that had the same
problem, by simply substituting a function as in:
svn_auth_get_keychain_simple_provider (&provider, [self pool]); //GG
use keychain
//GG svn_client_get_simple_provider (&provider, [self pool]);
APR_ARRAY_PUSH (providers, svn_auth_provider_object_t *) =
provider;
Giuliano
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Oct 20, 2006, at 17:20, Giovanni Bajo wrote:
>
> Deployment of Python application has gone a long way nowadays. We
> can ship
> self-contained executables for Windows (like Mercurial does), and
> typically
> you can just "require" (assume) an existing Python installation on the
> system. If you write your Python code with some stricter rule, it
> will work
> on any Python version in the last 4-5 years, which is enough not to
> create
> too many headaches. If we are speaking of SVN 2.0 here, it will be
> several
> years in the future anyway. For now, a Python command line client
> could live
> as external contribution until it's more mature, and that'd raise
> even more
> the chances that having Python installed is not a problem anymore.
In support of what you are saying.
My pysvn Extension is written in C++. It lives between the C API of svn
and the C API of Python (hidden by my PyCXX library).
The main example for pysvn is a python clone of the svn command line.
I have most of the commands and most of the options. Its 1497 lines
of python.
The svn C version is 28765 lines include libsvn_subr.
The pysvn WorkBench GUI is delivered as a binary application on
Windows, Mac OS X and Unix.
>> I'm not advocating a C API for calling into the actual command line
>> code, just for calling into the kind of thing we put into
>> libsvn_client, which is theoretically client agnostic.
>
> How many libsvn_client users are there, in the wild? Is there any
> idea about
> this number?
Each of the GUIs that are built on top of use the libsvn_client API.
Some via
language bindings.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Giovanni Bajo <ra...@develer.com>.
Garrett Rooney wrote:
>> I don't get this. You're suggesting a non-mainstream under-supported
>> second-class higher level language, just because the interpeter has
>> a lower footprint than, say, Python? I don't remember anyone being
>> concerned with Mercurial's memory occupation, or svk's.
>
> It's not memory footprint I'm worrying about, it's dependencies. It's
> practical to just bundle Lua with the system, it's not so reasonable
> for Perl or Python or Ruby.
I understand your concerns.
Deployment of Python application has gone a long way nowadays. We can ship
self-contained executables for Windows (like Mercurial does), and typically
you can just "require" (assume) an existing Python installation on the
system. If you write your Python code with some stricter rule, it will work
on any Python version in the last 4-5 years, which is enough not to create
too many headaches. If we are speaking of SVN 2.0 here, it will be several
years in the future anyway. For now, a Python command line client could live
as external contribution until it's more mature, and that'd raise even more
the chances that having Python installed is not a problem anymore.
> I'm not advocating a C API for calling into the actual command line
> code, just for calling into the kind of thing we put into
> libsvn_client, which is theoretically client agnostic.
How many libsvn_client users are there, in the wild? Is there any idea about
this number?
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/20/06, Giovanni Bajo <ra...@develer.com> wrote:
> Garrett Rooney wrote:
>
> > The real kicker though, and the reason that Lua is in my opinion a
> > more practical solution than doing the same sort of thing in a
> > language like Perl or Ruby or Python is that Lua is tiny. The entire
> > lua5.1 interpreter on my Ubuntu machine is 124k.
>
> I don't get this. You're suggesting a non-mainstream under-supported
> second-class higher level language, just because the interpeter has a lower
> footprint than, say, Python? I don't remember anyone being concerned with
> Mercurial's memory occupation, or svk's.
It's not memory footprint I'm worrying about, it's dependencies. It's
practical to just bundle Lua with the system, it's not so reasonable
for Perl or Python or Ruby.
> I sincerely believe that choosing anything which is not Perl or Python is
> going to just go against us, in that people are not going to learn a
> language just to contribute to Subversion. It is already hard enough to get
> external contribution if you use a first-class language.
That is certainly something to worry about.
> > The actual Lua 5.1
> > codebase is just under 17000 lines of code, and is written in pure C89
> > (with the exception of some platform specific code for dlopen type
> > stuff, but it's already at least as portable as APR is, so no worries
> > there). It's also built for doing this sort of thing, calling C and
> > being called from it, which means it's far more practical to do things
> > like that in Lua than it is to do similar things in the other popular
> > scripting languages.
>
> Would you elaborate on why the svn command line client should support a C
> interface? I understand that we want to go higher-level for the svn* command
> line utils, but why should they expose an interface for being called from C
> applications?
I'm not advocating a C API for calling into the actual command line
code, just for calling into the kind of thing we put into
libsvn_client, which is theoretically client agnostic.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Giovanni Bajo <ra...@develer.com>.
Garrett Rooney wrote:
> The real kicker though, and the reason that Lua is in my opinion a
> more practical solution than doing the same sort of thing in a
> language like Perl or Ruby or Python is that Lua is tiny. The entire
> lua5.1 interpreter on my Ubuntu machine is 124k.
I don't get this. You're suggesting a non-mainstream under-supported
second-class higher level language, just because the interpeter has a lower
footprint than, say, Python? I don't remember anyone being concerned with
Mercurial's memory occupation, or svk's.
I sincerely believe that choosing anything which is not Perl or Python is
going to just go against us, in that people are not going to learn a
language just to contribute to Subversion. It is already hard enough to get
external contribution if you use a first-class language.
> The actual Lua 5.1
> codebase is just under 17000 lines of code, and is written in pure C89
> (with the exception of some platform specific code for dlopen type
> stuff, but it's already at least as portable as APR is, so no worries
> there). It's also built for doing this sort of thing, calling C and
> being called from it, which means it's far more practical to do things
> like that in Lua than it is to do similar things in the other popular
> scripting languages.
Would you elaborate on why the svn command line client should support a C
interface? I understand that we want to go higher-level for the svn* command
line utils, but why should they expose an interface for being called from C
applications?
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/21/06, Branko Čibej <br...@xbc.nu> wrote:
> Garrett Rooney wrote:
> > Sure, that's certainly an issue we'd have to worry about. In this
> > proposal there would continue to be large chunks of code written in C,
> > the low level libraries especially, but perhaps even big things like
> > mod_dav_svn.
>
> So, now I'm really interested ... just /why/ would mod_dav_svn have to
> be written in C?
Well, at least the core apache module itself would be C. Sure, it
could call into Lua or any other language that had an appropriate C
interface, so if we provided that sort of thing for a portion of the
system written in Lua it could certainly be used from mod_dav_svn just
like any other program.
> Another note about C++ vs. any other higher-level language: I bet I can
> fix current trunk so that it compiles (and works) with C++ within a
> week. Three weeks, if you want to avoid using casts wherever we pass
> around void* batons. From that point onwards, it's all just incremental
> changes.
>
> I challenge anyone to do the same with Lua or Python or anything else.
No argument there, the difference between C and C++ is certainly
smaller than the difference between C and Lua or Python or any other
scripting language for that matter. One one hand that means it's
easier to retrofit to our current code. On the other it means that
you're still writing in something rather low level, with all the
problems that entails.
> > Using multiple languages would introduce some problems,
> > there is no doubt, but I'm not convinced that they are insurmountable.
>
> Of course they're not, after all, half of our contrib is in Python or
> Perl today.
>
> On the other hand ... mixing C and C++ is probably much easier than
> mixing C and Lua. Or maybe not ... the differences are subtle enough
> that they still catch me unawares from time to time.
>
> Not that I care, I'm perfectly comfortable mixing SmallTalk and PDP-10
> assembly, or even Visual Basic, but I suppose something like that would
> be too much of a good thing for this project. :)
Heh.
-garrett
Re: Higher level languages as part of the core of SVN
Posted by Branko Čibej <br...@xbc.nu>.
Garrett Rooney wrote:
> Sure, that's certainly an issue we'd have to worry about. In this
> proposal there would continue to be large chunks of code written in C,
> the low level libraries especially, but perhaps even big things like
> mod_dav_svn.
So, now I'm really interested ... just /why/ would mod_dav_svn have to
be written in C?
Another note about C++ vs. any other higher-level language: I bet I can
fix current trunk so that it compiles (and works) with C++ within a
week. Three weeks, if you want to avoid using casts wherever we pass
around void* batons. From that point onwards, it's all just incremental
changes.
I challenge anyone to do the same with Lua or Python or anything else.
> Using multiple languages would introduce some problems,
> there is no doubt, but I'm not convinced that they are insurmountable.
Of course they're not, after all, half of our contrib is in Python or
Perl today.
On the other hand ... mixing C and C++ is probably much easier than
mixing C and Lua. Or maybe not ... the differences are subtle enough
that they still catch me unawares from time to time.
Not that I care, I'm perfectly comfortable mixing SmallTalk and PDP-10
assembly, or even Visual Basic, but I suppose something like that would
be too much of a good thing for this project. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/21/06, Mark Phippard <ma...@softlanding.com> wrote:
> I have to admit that I do not "get this". Not so much this specific
> proposal, but the whole idea of changing languages. What are the problems
> caused by the current language choice that would be solved by a new
> language? They likely exist, but I do not recall them being discussed
> publicly (maybe on IRC??) very often. How do you know that you are not
> trading one set of *known* problems for a new set of *unknown* problems?
> Changing languages seems like it could be one of those collosal blunders
> that eventually kills the project.
No decisions have been made on IRC or in person about this or any
topic. There have been some people talking about how they'd like to
switch to a subset of C++ so that they can take advantage of some of
its features, using objects instead of bending over backwards to
reimplement that functionality in C, etc.
> I have some practical concerns. How are you going to provide good Java
> (or other language) bindings if the code is in Lua or Python or Ruby? How
> does something like TortoiseSVN make use of the code?
Lua can be called from C just as easily as it can call into C. If we
wanted to we could expose exactly the same C API we have now, allowing
things like the Java, Perl, Python, and Ruby bindings to continue to
work.
> When all is said and done, I do trust the committers, and that they are
> going to take all of this into account before making any decision. If you
> think you can write better, faster code in Lua and it is all still easy to
> use from language bindings and TortoiseSVN etc.. then I trust you. I just
> do not really see what we are not doing now with Subversion because of the
> language choice.
>
> If people really think that C is holding them back, maybe they should
> spend some time with the JavaSVN code to see if it proves or disproves
> this notion? It is a good chunk of the Subversion code written in an OO
> language. While Java is likely a non-starter for a language change, the
> fact that the JavaSVN code exists and is at the 1.4 level might make it a
> good proving ground for testing what applying OO concepts can do. There
> are some enhancements over the Subversion API that have been made in
> JavaSVN, so perhaps there is some validity to the language holding things
> back?
>
> I assume there are still layers of the code, like mod_dav_svn, that pretty
> much have to be written in C. Does anyone see any problems with having
> the code written in too many different languages?
Sure, that's certainly an issue we'd have to worry about. In this
proposal there would continue to be large chunks of code written in C,
the low level libraries especially, but perhaps even big things like
mod_dav_svn. Using multiple languages would introduce some problems,
there is no doubt, but I'm not convinced that they are insurmountable.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by eg <eg...@gmail.com>.
Erik Huelsmann wrote:
> So, that's what I understand from the background. I too however have
> my concerns. From one of the papers on the Lua site: "All statements
> in Lua are executed in a global environment, which keeps all global
> variables and functions. This environment is initialized at the
> beginning of the host program and persists until its end." This
> sentence seems to conflict (badly!) with our opinion that our
> libraries are to be thread safe: global variables generally are not,
> as is the global interpreter resource. Or is the article outdated?
> [Lua-an extensible extension language (http://www.lua.org/spe.html)]
>
The following thread might shed some additional light:
http://lua-users.org/lists/lua-l/2006-02/msg00358.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Greg Stein <gs...@lyra.org>.
On 12/13/06, Daniel Rall <dl...@collab.net> wrote:
> On Thu, 26 Oct 2006, Daniel Berlin wrote:
> ...
>
> > If we were going to have a core set of libs, and use a HLL to write
> > the client, i'd do the libs in C++ and use python.
>
> FWIW, this is my preference, too. I'd even be game for keeping the
> libraries in C if we could switch to writing the executables in a HLL
> (preferable Python ;).
+1
Note that this would not necessarily imply a 2.0 release. Nor would it
preclude a future implementation that uses Lua in some capacity. The
Lua thing is neat, but I think that is going to be a "try it on a
branch so we can evaluate the benefits/costs" rather than any advanced
buy-in.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Daniel Rall <dl...@collab.net>.
On Thu, 26 Oct 2006, Daniel Berlin wrote:
...
> If we were going to have a core set of libs, and use a HLL to write
> the client, i'd do the libs in C++ and use python.
FWIW, this is my preference, too. I'd even be game for keeping the
libraries in C if we could switch to writing the executables in a HLL
(preferable Python ;).
Re: Higher level languages as part of the core of SVN
Posted by Daniel Berlin <db...@dberlin.org>.
On 10/21/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:
> On 10/21/06, Erik Huelsmann <eh...@gmail.com> wrote:
>
> > Ah, but that's why Garrett is explicitly rejecting Python, Ruby or
> > Perl as a higher level language. Interfacing with Python is (in my
> > personal experience) a big pain.
> >
> > Lua is designed to be easy to interface with, both to call into from
> > anything that supports C interfaces as well as that it supports
> > calling into C (or anything that can support C interfaces) itself.
>
> Exactly.
>
Lua is an interesting language, but not one I would choose (though I
know tons of game developers use it, or use python).
Almost all of the major stcripting languages (python, perl, etc) have
modules that allow calling c functions that do not require writing
extensions. In fact, in python 2.5, the ctypes module is now part of
the standard library.
Really, LUA's C integration is just nothing to write home about. I've
embedded it before, and calling into/out of it is just as easy/hard
(depending on your view) as python with ctypes.
I also don't buy the dependencies argument. Python has roughly no
dependencies, it's just that most people choose to compile the
standard distribution with some of it's optional modules.
If you wanted to make use of optional extensions, there is a nice way
to auto-bundle them with the executable on windows, and for unix it's
up to packagers.
If we were going to have a core set of libs, and use a HLL to write
the client, i'd do the libs in C++ and use python.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Jack Repenning <jr...@collab.net>.
On Oct 21, 2006, at 8:23 AM, Garrett Rooney wrote:
> On 10/21/06, Erik Huelsmann <eh...@gmail.com> wrote:
>
>> Ah, but that's why Garrett is explicitly rejecting Python, Ruby or
>> Perl as a higher level language. Interfacing with Python is (in my
>> personal experience) a big pain.
>>
>> Lua is designed to be easy to interface with, both to call into from
>> anything that supports C interfaces as well as that it supports
>> calling into C (or anything that can support C interfaces) itself.
>
> Exactly.
Sorry, but if it's not on my O'Reilly Genealogical Chart of
Programming Languages, then it Just Doesn't Exist! ;-)
-==-
Jack Repenning
Director, Software Product Architecture
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: 844.7461
skype: jrepenning
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/21/06, Erik Huelsmann <eh...@gmail.com> wrote:
> Ah, but that's why Garrett is explicitly rejecting Python, Ruby or
> Perl as a higher level language. Interfacing with Python is (in my
> personal experience) a big pain.
>
> Lua is designed to be easy to interface with, both to call into from
> anything that supports C interfaces as well as that it supports
> calling into C (or anything that can support C interfaces) itself.
Exactly.
> Reading on the Lua site, it supports OO as well.
>
> > When all is said and done, I do trust the committers, and that they are
> > going to take all of this into account before making any decision. If you
> > think you can write better, faster code in Lua and it is all still easy to
> > use from language bindings and TortoiseSVN etc.. then I trust you. I just
> > do not really see what we are not doing now with Subversion because of the
> > language choice.
>
> > If people really think that C is holding them back, maybe they should
> > spend some time with the JavaSVN code to see if it proves or disproves
> > this notion? It is a good chunk of the Subversion code written in an OO
> > language. While Java is likely a non-starter for a language change, the
> > fact that the JavaSVN code exists and is at the 1.4 level might make it a
> > good proving ground for testing what applying OO concepts can do. There
> > are some enhancements over the Subversion API that have been made in
> > JavaSVN, so perhaps there is some validity to the language holding things
> > back?
>
> Well, given that the merge-tracking branch -after months of
> development- is not much more than svnmerge.py in C, I do understand
> some people feel they need to be able to write higher level
> constructs, not worrying about memory management and other things that
> have been invented and implemented several millions of times before.
Yep, that's basically what I'm thinking. I mean look at what JavaSVN
has done with less programmers than us and in less time. Sure, some
of that is because we paved the way for them, but some of it is just
features they've added that we haven't yet. Or take a look at SVK.
Whatever complaints you have about Perl, you must admit that it's
allowed fewer programmers to move faster than we have in many ways.
> So, that's what I understand from the background. I too however have
> my concerns. From one of the papers on the Lua site: "All statements
> in Lua are executed in a global environment, which keeps all global
> variables and functions. This environment is initialized at the
> beginning of the host program and persists until its end." This
> sentence seems to conflict (badly!) with our opinion that our
> libraries are to be thread safe: global variables generally are not,
> as is the global interpreter resource. Or is the article outdated?
> [Lua-an extensible extension language (http://www.lua.org/spe.html)]
You can run multiple instances of the Lua VM if you wish to, each of
which is completely separate from the rest.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Branko Čibej <br...@xbc.nu>.
listman wrote:
> we should be making implementation decisions based on what easiest for
> users not what is easiest to implement. lots of people know and are
> efficient
> in Python, i've never even heard of Lua..
I assume you meant "developers", not "users".
And I'd almost rather implement svn in some obscure,
complex-but-efficient language than in something mainstream; at least
we'd attract only those who are comfortable switching to new languages,
that's usually a measure of competence. :)
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by listman <li...@burble.net>.
we should be making implementation decisions based on what easiest for
users not what is easiest to implement. lots of people know and are
efficient
in Python, i've never even heard of Lua..
On Oct 21, 2006, at 7:09 AM, Erik Huelsmann wrote:
> On 10/21/06, Mark Phippard <ma...@softlanding.com> wrote:
>> rooneg@gmail.com wrote on 10/19/2006 01:37:34 PM:
>
> [ snip summary of arguments made for changing languages ]
>
>> > So, the way I'd propose doing this would be to start making use
>> of Lua
>> > for our higher level language. Now this may seem a little weird,
>> > since we don't even have Lua bindings at the moment, and most of
>> you
>> > have probably never used it, but bear with me here. Lua is a
>> > scripting language that's designed to both embed C code (i.e. call
>> > into C libraries, like we do with the bindings today) and be
>> embedded
>> > within C code (i.e. act as an embedded scripting language for a big
>> > application, this is actually done within things like World of
>> > Warcraft and other similar games). With decent Lua bindings for
>> the
>> > lower level performance critical parts of the application, we could
>> > fairly easily implement chunks of the application in Lua, while
>> still
>> > providing a C interface that would enable us to build bindings for
>> > other languages.
>>
>> I have to admit that I do not "get this". Not so much this specific
>> proposal, but the whole idea of changing languages. What are the
>> problems
>> caused by the current language choice that would be solved by a new
>> language? They likely exist, but I do not recall them being
>> discussed
>> publicly (maybe on IRC??) very often. How do you know that you
>> are not
>> trading one set of *known* problems for a new set of *unknown*
>> problems?
>> Changing languages seems like it could be one of those collosal
>> blunders
>> that eventually kills the project.
>>
>> I have some practical concerns. How are you going to provide good
>> Java
>> (or other language) bindings if the code is in Lua or Python or
>> Ruby? How
>> does something like TortoiseSVN make use of the code?
>
> Ah, but that's why Garrett is explicitly rejecting Python, Ruby or
> Perl as a higher level language. Interfacing with Python is (in my
> personal experience) a big pain.
>
> Lua is designed to be easy to interface with, both to call into from
> anything that supports C interfaces as well as that it supports
> calling into C (or anything that can support C interfaces) itself.
>
> Reading on the Lua site, it supports OO as well.
>
>> When all is said and done, I do trust the committers, and that
>> they are
>> going to take all of this into account before making any
>> decision. If you
>> think you can write better, faster code in Lua and it is all still
>> easy to
>> use from language bindings and TortoiseSVN etc.. then I trust
>> you. I just
>> do not really see what we are not doing now with Subversion
>> because of the
>> language choice.
>
>> If people really think that C is holding them back, maybe they should
>> spend some time with the JavaSVN code to see if it proves or
>> disproves
>> this notion? It is a good chunk of the Subversion code written in
>> an OO
>> language. While Java is likely a non-starter for a language
>> change, the
>> fact that the JavaSVN code exists and is at the 1.4 level might
>> make it a
>> good proving ground for testing what applying OO concepts can do.
>> There
>> are some enhancements over the Subversion API that have been made in
>> JavaSVN, so perhaps there is some validity to the language holding
>> things
>> back?
>
> Well, given that the merge-tracking branch -after months of
> development- is not much more than svnmerge.py in C, I do understand
> some people feel they need to be able to write higher level
> constructs, not worrying about memory management and other things that
> have been invented and implemented several millions of times before.
>
> So, that's what I understand from the background. I too however have
> my concerns. From one of the papers on the Lua site: "All statements
> in Lua are executed in a global environment, which keeps all global
> variables and functions. This environment is initialized at the
> beginning of the host program and persists until its end." This
> sentence seems to conflict (badly!) with our opinion that our
> libraries are to be thread safe: global variables generally are not,
> as is the global interpreter resource. Or is the article outdated?
> [Lua-an extensible extension language (http://www.lua.org/spe.html)]
>
>
> bye,
>
>
> Erik.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Erik Huelsmann <eh...@gmail.com>.
On 10/21/06, Mark Phippard <ma...@softlanding.com> wrote:
> rooneg@gmail.com wrote on 10/19/2006 01:37:34 PM:
[ snip summary of arguments made for changing languages ]
> > So, the way I'd propose doing this would be to start making use of Lua
> > for our higher level language. Now this may seem a little weird,
> > since we don't even have Lua bindings at the moment, and most of you
> > have probably never used it, but bear with me here. Lua is a
> > scripting language that's designed to both embed C code (i.e. call
> > into C libraries, like we do with the bindings today) and be embedded
> > within C code (i.e. act as an embedded scripting language for a big
> > application, this is actually done within things like World of
> > Warcraft and other similar games). With decent Lua bindings for the
> > lower level performance critical parts of the application, we could
> > fairly easily implement chunks of the application in Lua, while still
> > providing a C interface that would enable us to build bindings for
> > other languages.
>
> I have to admit that I do not "get this". Not so much this specific
> proposal, but the whole idea of changing languages. What are the problems
> caused by the current language choice that would be solved by a new
> language? They likely exist, but I do not recall them being discussed
> publicly (maybe on IRC??) very often. How do you know that you are not
> trading one set of *known* problems for a new set of *unknown* problems?
> Changing languages seems like it could be one of those collosal blunders
> that eventually kills the project.
>
> I have some practical concerns. How are you going to provide good Java
> (or other language) bindings if the code is in Lua or Python or Ruby? How
> does something like TortoiseSVN make use of the code?
Ah, but that's why Garrett is explicitly rejecting Python, Ruby or
Perl as a higher level language. Interfacing with Python is (in my
personal experience) a big pain.
Lua is designed to be easy to interface with, both to call into from
anything that supports C interfaces as well as that it supports
calling into C (or anything that can support C interfaces) itself.
Reading on the Lua site, it supports OO as well.
> When all is said and done, I do trust the committers, and that they are
> going to take all of this into account before making any decision. If you
> think you can write better, faster code in Lua and it is all still easy to
> use from language bindings and TortoiseSVN etc.. then I trust you. I just
> do not really see what we are not doing now with Subversion because of the
> language choice.
> If people really think that C is holding them back, maybe they should
> spend some time with the JavaSVN code to see if it proves or disproves
> this notion? It is a good chunk of the Subversion code written in an OO
> language. While Java is likely a non-starter for a language change, the
> fact that the JavaSVN code exists and is at the 1.4 level might make it a
> good proving ground for testing what applying OO concepts can do. There
> are some enhancements over the Subversion API that have been made in
> JavaSVN, so perhaps there is some validity to the language holding things
> back?
Well, given that the merge-tracking branch -after months of
development- is not much more than svnmerge.py in C, I do understand
some people feel they need to be able to write higher level
constructs, not worrying about memory management and other things that
have been invented and implemented several millions of times before.
So, that's what I understand from the background. I too however have
my concerns. From one of the papers on the Lua site: "All statements
in Lua are executed in a global environment, which keeps all global
variables and functions. This environment is initialized at the
beginning of the host program and persists until its end." This
sentence seems to conflict (badly!) with our opinion that our
libraries are to be thread safe: global variables generally are not,
as is the global interpreter resource. Or is the article outdated?
[Lua-an extensible extension language (http://www.lua.org/spe.html)]
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Higher level languages as part of the core of SVN
Posted by Mark Phippard <ma...@softlanding.com>.
rooneg@gmail.com wrote on 10/19/2006 01:37:34 PM:
> So, one of the contentious topics at the Subversion Summit earlier
> this week was a choice of language for Subversion 2.0. There are many
> people who want to think about things like using some subset of C++
> for parts of the application (the "batons suck damn it, lets have
> objects!" crowd), and many other people who hate C++ with the fires of
> a thousand hells, and just don't want to see that happen.
>
> Another group advocated (and I'm not sure how serious this was) the
> idea of writing things like the command line client and other tools in
> something like Python, rather than doing so in C. This kind of thing
> would mean that our bindings would get a lot more attention, which
> would be nice.
>
> I'd like to propose another idea for how we could write parts of
> Subversion itself (not just the command line clients, but actual
> portions of the libraries) in a higher level language, but still
> expose a C level interface to the rest of the world, without dealing
> with the binary compatibility and other issues that come with C++.
> Ideally I'd see us writing the code at the level of libsvn_client in a
> language other than C, and that would call into things like libsvn_ra
> and libsvn_wc. If we went forward with ideas like reimplementing the
> working copy in a newer better faster way, we could decide then if it
> would be written in C or something else.
>
> So, the way I'd propose doing this would be to start making use of Lua
> for our higher level language. Now this may seem a little weird,
> since we don't even have Lua bindings at the moment, and most of you
> have probably never used it, but bear with me here. Lua is a
> scripting language that's designed to both embed C code (i.e. call
> into C libraries, like we do with the bindings today) and be embedded
> within C code (i.e. act as an embedded scripting language for a big
> application, this is actually done within things like World of
> Warcraft and other similar games). With decent Lua bindings for the
> lower level performance critical parts of the application, we could
> fairly easily implement chunks of the application in Lua, while still
> providing a C interface that would enable us to build bindings for
> other languages.
I have to admit that I do not "get this". Not so much this specific
proposal, but the whole idea of changing languages. What are the problems
caused by the current language choice that would be solved by a new
language? They likely exist, but I do not recall them being discussed
publicly (maybe on IRC??) very often. How do you know that you are not
trading one set of *known* problems for a new set of *unknown* problems?
Changing languages seems like it could be one of those collosal blunders
that eventually kills the project.
I have some practical concerns. How are you going to provide good Java
(or other language) bindings if the code is in Lua or Python or Ruby? How
does something like TortoiseSVN make use of the code?
When all is said and done, I do trust the committers, and that they are
going to take all of this into account before making any decision. If you
think you can write better, faster code in Lua and it is all still easy to
use from language bindings and TortoiseSVN etc.. then I trust you. I just
do not really see what we are not doing now with Subversion because of the
language choice.
If people really think that C is holding them back, maybe they should
spend some time with the JavaSVN code to see if it proves or disproves
this notion? It is a good chunk of the Subversion code written in an OO
language. While Java is likely a non-starter for a language change, the
fact that the JavaSVN code exists and is at the 1.4 level might make it a
good proving ground for testing what applying OO concepts can do. There
are some enhancements over the Subversion API that have been made in
JavaSVN, so perhaps there is some validity to the language holding things
back?
I assume there are still layers of the code, like mod_dav_svn, that pretty
much have to be written in C. Does anyone see any problems with having
the code written in too many different languages?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org