Dear Stephan:
With regards to scripting and fossil as a separate library, I actually see
these as separate things. Having Fossil as a separate library allows other
programs to use fossil capabilities, while any scripting interface, such as a
public interface used to build shared objects that are dynamically linked at
runtime by the Fossil program, allows Fossil to use the capabilities of other
software. These are two different things. You don’t need to separate Fossil as
a library in order to get a language agnostic extension interface for Fossil.
Yours truly,
Aaron W. Hsu
--
Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us
From: Stephan Beal
Sent: Tuesday, July 23, 2013 6:55 AM
To: Fossil SCM user's discussion
On Tue, Jul 23, 2013 at 12:51 PM, Laurens Van Houtven <_...@lvh.io> wrote:
Not aimed at anyone in particular, but if you are going to suggest a particular
language, can you please point to an interpreter that is easily embeddable into
fossil? That seems to be the problem with at least JS and Python, and seems to
be Lua's strong point. There's no point in discussing the relative merits of
languages if we can't actually reasonably *use that language*.
That's one of the beauties of restructuring fossil as a library: we don't need
to embed any language at all. Instead, they can be built on top of the library.
Yes, we'll want/need one "standard" interpreter for unit test purposes, but
that will "almost certainly" end up being TCL or jimtcl, simply for reasons of
historical momentum.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
