[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: Concern about LUA & suggestions for command line ou
[Monotone-devel] Re: Concern about LUA & suggestions for command line output
Tue, 01 Feb 2005 23:41:11 +0000
Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)
Henrik Holmboe <address@hidden> writes:
> Joel Crisp <address@hidden> writes:
>>Saw a message a few back about writing output formatters in LUA - the
>>place I'm currently working at is balking at Clearcase triggers in
>>perl since they can't get anyone with perl experience (!), and I've
>>never personally even met _anyone_ with LUA experience.
> Have SWIG been evaluated? A short description from its webpage:
> "SWIG is a software development tool that connects programs written in
> C and C++ with a variety of high-level programming languages. SWIG is
> used with different types of languages including common scripting
> languages such as Perl, Python, Tcl/Tk and Ruby."
> There are drawbacks (such as it doesnt make the bindings very
> Python-like for that language etc), but there are definitly many
> benefits too.
SWIG can work well when you've got a C/C++ library that you want to
expose in a number of languages (subversion does that, for example).
But Graydon doesn't want to do that with monotone. In monotone the
plan seems to be to have an executable with relatively stable,
non-extensible behaviour, with a few things configurable in some
language (for example deciding which certificates are valid,
interactive ways of merging).
And maybe there'll be an interactive mode that front-ends such as
emacs and web-based front ends can use without all the overhead of
loading the same executable over and over again (although there's no
such mode at present, and I seem to remember there are problems with
database locking that would need to be fixed (I seem to remember
monotone doesn't lock it, currently)).
Anyway, it doesn't seem that the language directly bound with monotone
is likely to be that big a deal, so my guess is it'll stay as Lua
(which is nice and small), or maybe change to Python (which is
popular). I can imagine alternatives being proposed (although
ECMAscript took my by surprise), but I doubt that it's significant
enough that anybody will put in the work to make it happen.