Re: [fossil-users] Scripting in Fossil v2
On Wed, Jul 24, 2013 at 1:17 PM, Mark Janssen wrote: > Synchronisation and authentication is definitely not a app-level detail > for a DVCS, the actual transport used could be though. > In fossil's case authentication is (currently) largely an app-level detail. The core bits provide the basis of user+password+hashes+roles, but a large portion of (the majority?) of the real auth-related code is very much dependent on HTTP specifics. When running locally, without HTTP, you effectively have no authentication. My point is only that yes, the lib has to provided some basis for this, but much of the auth legwork is (at least currently) happening at a higher level. My current thinking is that, similar to now, the app is responsible for telling the library which user it is acting on behalf of (which is actually only relevant in a minority of cases - those which make db changes). The user ID/object would become part of the parameters/state for any ops which require it (commit, wiki edit, etc.). -- - 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
Re: [fossil-users] Scripting in Fossil v2
On Wed, Jul 24, 2013 at 12:37 PM, Stephan Beal wrote: > On Wed, Jul 24, 2013 at 10:43 AM, Mark Janssen wrote: > >> I would just like to add that fossil already has a defined "API" in the >> sense that what a fossil repo and server are is described in >> http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki and >> http://fossil-scm.org/index.html/doc/trunk/www/sync.wiki. I would say >> that any truly useful fossil library should be built on those concepts. >> > > i was recently wondering (haven't checked) whether the sync really belongs > in the core lib or if networking is an app-level detail? The file > format/manifest will (must) remain central to the design, and i started > sketching out interfaces for working with the manifests. > > -- > Synchronisation and authentication is definitely not a app-level detail for a DVCS, the actual transport used could be though. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Scripting in Fossil v2
On Wed, Jul 24, 2013 at 10:43 AM, Mark Janssen wrote: > I would just like to add that fossil already has a defined "API" in the > sense that what a fossil repo and server are is described in > http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki and > http://fossil-scm.org/index.html/doc/trunk/www/sync.wiki. I would say > that any truly useful fossil library should be built on those concepts. > i was recently wondering (haven't checked) whether the sync really belongs in the core lib or if networking is an app-level detail? The file format/manifest will (must) remain central to the design, and i started sketching out interfaces for working with the manifests. -- - 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
Re: [fossil-users] Scripting in Fossil v2
I would just like to add that fossil already has a defined "API" in the sense that what a fossil repo and server are is described in http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki and http://fossil-scm.org/index.html/doc/trunk/www/sync.wiki. I would say that any truly useful fossil library should be built on those concepts. On Wed, Jul 24, 2013 at 3:42 AM, Stephan Beal wrote: > On Wed, Jul 24, 2013 at 1:55 AM, Aaron W.Hsu wrote: > >> against a fossil(3) library. This functionality can therefore be provided >> by the fossil(1) executable program as well as from a separate shared >> object against which the fossil(1) program links. >> > > Right - that's just a question of how the modules/extensions are linked. > That bit only affects how they are loaded/initialized, but not how they > operate. > > Once we recognize that these are all technically orthogonal, we can then >> try to understand how they synergize together. For instance, it makes sense >> that the fossil API that is accessible through shared objects loaded by >> fossil(1) at runtime and the API provided by fossil(3) be the same. >> > > i hadn't ever thought explicitly about them being available via fossil(1), > probably because the matter of where the APIs are linked to/from doesn't > change the fundamental design (which is where the work/energy is going at > the moment). > > >> On the other hand, it doesn’t make much sense for the extension API to >> be a part of fossil(3). >> > > Not necessarily. Where exactly those bits will/should/could live isn't a > problem i've considered much yet. i'm at the point where i can instantiate > and destroy a fossil instance and create formatted output to a few > different output channels, but not yet at a point where anything really > interesting is happening, e.g. opening an existing repo DB will be the next > step. > > >>1. Should fossil(3) exist at all? >> >> > That is a fair question. Despite my overall enthusiasm and hype regarding > fossil(3), i do have concerns about whether it is truly going to work. > Richard has also expressed skepticism - you're not alone! i do, however, > think that it's an interesting enough problem to be worth trying out. If it > turns out that it's not reasonable or doesn't fit, it'll get tossed aside. > At this point there is _no_ commitment that fossil(3) will/should/must > happen. > > >> >>1. What is the extension API? >> >> > (Sorry, gmail is renumbering your entries when i split them.) > > i'm not yet that far along, but i expect to have some interesting > discussions on that topic later. > > >> >>1. >>2. What is the fossil API? >> >> >> Notice that I’ve explicitly created a difference between the extension >> API and the fossil API. I think this is not only important, but at the crux >> of our particular current line of discourse. In particular, you’ve >> mentioned a number of times that having a fossil API, such as what >> fossil(3) might provide, sort of automatically entails extensibility and >> scriptability. I disagree with the usage of those terms here. I think one >> should distinguish clearly between the extension API and the fossil API. >> There is no extension API in fossil(3). >> > > i hadn't thought about those being separate until your post. i'll have to > ponder why that separation is significant. i haven't yet gotten to the > level of detail where i can just point to the function and say, "that does > or does not fit." > > > >> Namely, you cannot change the way that fossil operations work. Instead, >> you are expected to have access to these operations as primitives for >> writing other programs, but by and large you are not altering the behavior >> of fossil itself. >> > > Correct. > > >> An extension API is not for providing fossil operations to the rest of >> the programming space, but is instead for the sole purpose of allowing one >> to alter the behavior of the fossil operations themselves. >> > > Yes, and building off of them to provide bigger or more special-purpose > features. e.g. specialized timeline reports or exports to spreadsheets. > > > >> Based on your prior messages, I think it is clear that you are talking >> about the fossil API, and consider that to be the really sticky issue. >> > > Right. > > >> I have no doubt that the fossil API itself is a very important and >> tricky issue. However, I want to elevate the extension API question to the >> fore here. What’s interesting and relevant here is not the fossil API, but >> the extension API. And here I want to emphasize that the fossil API and the >> extension API can both reasonably and technically exist *without* ever >> having to create a shared fossil(3) library. Whether one should do that or >> not is a different question, and important, but not the question I want to >> focus on. >> > > That's an interesting direction. i would at this point argue that until we > know what the core fossil lib really should look like, that we can't say > what wi
Re: [fossil-users] Scripting in Fossil v2
On Wed, Jul 24, 2013 at 1:55 AM, Aaron W.Hsu wrote: > against a fossil(3) library. This functionality can therefore be provided > by the fossil(1) executable program as well as from a separate shared > object against which the fossil(1) program links. > Right - that's just a question of how the modules/extensions are linked. That bit only affects how they are loaded/initialized, but not how they operate. Once we recognize that these are all technically orthogonal, we can then > try to understand how they synergize together. For instance, it makes sense > that the fossil API that is accessible through shared objects loaded by > fossil(1) at runtime and the API provided by fossil(3) be the same. > i hadn't ever thought explicitly about them being available via fossil(1), probably because the matter of where the APIs are linked to/from doesn't change the fundamental design (which is where the work/energy is going at the moment). > On the other hand, it doesn’t make much sense for the extension API to be > a part of fossil(3). > Not necessarily. Where exactly those bits will/should/could live isn't a problem i've considered much yet. i'm at the point where i can instantiate and destroy a fossil instance and create formatted output to a few different output channels, but not yet at a point where anything really interesting is happening, e.g. opening an existing repo DB will be the next step. >1. Should fossil(3) exist at all? > > That is a fair question. Despite my overall enthusiasm and hype regarding fossil(3), i do have concerns about whether it is truly going to work. Richard has also expressed skepticism - you're not alone! i do, however, think that it's an interesting enough problem to be worth trying out. If it turns out that it's not reasonable or doesn't fit, it'll get tossed aside. At this point there is _no_ commitment that fossil(3) will/should/must happen. > >1. What is the extension API? > > (Sorry, gmail is renumbering your entries when i split them.) i'm not yet that far along, but i expect to have some interesting discussions on that topic later. > >1. >2. What is the fossil API? > > > Notice that I’ve explicitly created a difference between the extension API > and the fossil API. I think this is not only important, but at the crux of > our particular current line of discourse. In particular, you’ve mentioned a > number of times that having a fossil API, such as what fossil(3) might > provide, sort of automatically entails extensibility and scriptability. I > disagree with the usage of those terms here. I think one should distinguish > clearly between the extension API and the fossil API. There is no extension > API in fossil(3). > i hadn't thought about those being separate until your post. i'll have to ponder why that separation is significant. i haven't yet gotten to the level of detail where i can just point to the function and say, "that does or does not fit." > Namely, you cannot change the way that fossil operations work. Instead, > you are expected to have access to these operations as primitives for > writing other programs, but by and large you are not altering the behavior > of fossil itself. > Correct. > An extension API is not for providing fossil operations to the rest of the > programming space, but is instead for the sole purpose of allowing one to > alter the behavior of the fossil operations themselves. > Yes, and building off of them to provide bigger or more special-purpose features. e.g. specialized timeline reports or exports to spreadsheets. > Based on your prior messages, I think it is clear that you are talking > about the fossil API, and consider that to be the really sticky issue. > Right. > I have no doubt that the fossil API itself is a very important and tricky > issue. However, I want to elevate the extension API question to the fore > here. What’s interesting and relevant here is not the fossil API, but the > extension API. And here I want to emphasize that the fossil API and the > extension API can both reasonably and technically exist *without* ever > having to create a shared fossil(3) library. Whether one should do that or > not is a different question, and important, but not the question I want to > focus on. > That's an interesting direction. i would at this point argue that until we know what the core fossil lib really should look like, that we can't say what will be possible with the extension API. That said, we do need to know what the extension API _should_ be able to do in order to design the core API to do it,. So from that angle, the extension API is really the bigger factor. We've seen, the past couple days, a huge amount of input on what people want it to do, so i think we have a lot of good data for figuring out what the core API needs to look like. There's still lots of thinking, experimenting, and hacking left here, and nothing is ruled out at this point (except maybe an Oracle back-end - i won't go
Re: [fossil-users] Scripting in Fossil v2
On Wed, Jul 24, 2013 at 1:32 AM, B Harder wrote: > The first example would be "Fossil with hooks", while the second would be > "full scripting environment drives the operation, with full access to > fossil routines". > > I'm personally more interested in the second.To my senses, it's more > dynamic, and I'd say lends itself to more rapid prototyping/testing, > accelerating the development of the fossil core itself. > That might sound counter-intuitive to those who haven't experienced it for themselves, but i will second it. -- - 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
Re: [fossil-users] Scripting in Fossil v2
On Wed, Jul 24, 2013 at 12:12 AM, Ron Wilson wrote: > Seems to me it would act like a static binary unless requested to load one > or more shared libraries, only calling whatever hook "services" are > registered by the shared libraries. If no libraries are loaded, then the > binary would behave as if it were static (that is, self-contained with no > required dependencies). > Absolutely. One of my goals is to be able to build modules either statically compiled in or as DLLs. Basically a classloader which is ignorant of the linkage of the bits its loading. i've done that in C++ before, but doing it in C will be new for me. For a "notification only" hook, it could be like: > i've been pondering the ideas of events, similar to HTML DOM events, so you'd register a callback which abstractly looks like: int callback( Fossil * f, event_type_t eventId, void * eventState ) the eventId would determine the type of state passed to the event. i don't know if this is reasonable/feasible yet, but i _think_ that would allow us to easily plug in (from client code) post-commit, pre-commit, etc. events which the client (i.e. app) then uses to trigger whatever he wants. > return spawn_no_wait(hook_NNN_service( hookData )); > Can we do that one cross-platform? Then again, add-ons don't necessarily need to be platform-specific. > Baring a near complete restructuring, I think this would be the most > flexible way to add extensions to Fossil and, theoretically, could be > implemented in the current Fossil. > i'd like to discuss that further and get your ideas on how hooks/triggers/etc can/should be done. Can we move this one to the dev list? (i've spammed the -user list enough this week!) -- - 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
Re: [fossil-users] Scripting in Fossil v2
Dear Stephan: Here’s my attempt to define and clearly distinguish the various parts of this discussion into a piece that might be useful for talking about these things in the future. In my opinion, there are a few mutually orthogonal things to think about: The fossil API itself, which is just the abstract interface for speaking about Fossil operations in some fashion, independent of how this API is realized; The fossil(1) program and interface itself, which is the current interface seen by users, which happens to also contain other servers for hosting other interfaces -- I distinguish here the Fossil interface from the Web interface; The Web Interface, which is currently launched by various calls to the fossil(1) interface; The “extension” API, which is to say, the API allowing one to alter the observable behavior of the fossil(1) program; and finally, The fossil(3) library, which is an instantiated implementation of the fossil API. I think the important first note is that each of the above five things are technically independent of one another. One need not have a realized fossil API in order to have an extension API; if you do not, you will not have programmatic access to fossil operations when writing extensions, but you might still do interesting things. Likewise, one need not have a literal fossil(3) library to provide access to the fossil API. It is perfectly possible for Fossil to dynamically, at runtime, load user-written shared objects which access this functionality without needed these shared objects to explicitly link at link time against a fossil(3) library. This functionality can therefore be provided by the fossil(1) executable program as well as from a separate shared object against which the fossil(1) program links. On the other hand, not having the fossil(3) library may preclude certain use cases, such as when one wishes to use the fossil operations without ever interfacing or touching the fossil(1) program, which is something that you have provided a number of use cases for. Once we recognize that these are all technically orthogonal, we can then try to understand how they synergize together. For instance, it makes sense that the fossil API that is accessible through shared objects loaded by fossil(1) at runtime and the API provided by fossil(3) be the same. On the other hand, it doesn’t make much sense for the extension API to be a part of fossil(3). After all this, we come to the question of what the best implementation of each of the above actually is. Here are a few of those questions that have come up: Should fossil(3) exist at all? What is the extension API? What is the fossil API? Notice that I’ve explicitly created a difference between the extension API and the fossil API. I think this is not only important, but at the crux of our particular current line of discourse. In particular, you’ve mentioned a number of times that having a fossil API, such as what fossil(3) might provide, sort of automatically entails extensibility and scriptability. I disagree with the usage of those terms here. I think one should distinguish clearly between the extension API and the fossil API. There is no extension API in fossil(3). Namely, you cannot change the way that fossil operations work. Instead, you are expected to have access to these operations as primitives for writing other programs, but by and large you are not altering the behavior of fossil itself. An extension API is not for providing fossil operations to the rest of the programming space, but is instead for the sole purpose of allowing one to alter the behavior of the fossil operations themselves. Based on your prior messages, I think it is clear that you are talking about the fossil API, and consider that to be the really sticky issue. I have no doubt that the fossil API itself is a very important and tricky issue. However, I want to elevate the extension API question to the fore here. What’s interesting and relevant here is not the fossil API, but the extension API. And here I want to emphasize that the fossil API and the extension API can both reasonably and technically exist *without* ever having to create a shared fossil(3) library. Whether one should do that or not is a different question, and important, but not the question I want to focus on. Let me focus in on the specific question of the extension API to clarify it, because I think it’s a very important design choice that doesn’t receive enough attention. To lift out this question, let’s assume that we still only have a static fossil executable, and no shared object. Let us further assume that the fossil API already exists, and is implemented in that fossil executable. Now, there is the question of the extension API. How do current systems allow for the extending of their VCS? Some use specific “hook” points that call external programs to do work; Some embed a specific scripting language. I’ve writt
Re: [fossil-users] Scripting in Fossil v2
I think these things support each other. Specifically, with respect to Tcl (and likely Guile, Lua), scripting support can come by embedding the Tcl interpreter inside the app (ie: the standalone fossil executable), by linking libtcl with fossil, and having fossil call into it appropriately. Alternatively, one can take a library (ie: hypothetical libfossil), and build bindings to it which satisfy loading those bindings/library into Tcl. In this case, a Tcl script (or person at the keyboard) does the driving, calling into fossil routines appropriately. The first example would be "Fossil with hooks", while the second would be "full scripting environment drives the operation, with full access to fossil routines". I'm personally more interested in the second. To my senses, it's more dynamic, and I'd say lends itself to more rapid prototyping/testing, accelerating the development of the fossil core itself. I think in terms of Tcl, but this second approach also facilitates other languages participating more than the first model does. Ie: if Perl wants to participate, they write bindings against libfossil. If Ruby wants to participate, they write bindings against libfossil, etc. In the first model, to support multiple languages, you must necessarily fork fossil and build out internal support within the fossil executable for Perl, in another for support for Ruby, in another fork, support for Python, etc. Does that make sense, or am I missing something? -bch On Jul 23, 2013 11:01 AM, "Aaron W.Hsu" wrote: > 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 > > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 4:29 AM, Stephan Beal wrote:
> On Tue, Jul 23, 2013 at 3:25 AM, Aaron W.Hsu wrote:
>
>> When fossil runs, it can dynamically link in any of the shared objects
>> that it finds there, and these can register additional functionality with
>> the Fossil system.
>>
>
> And we're very much on the same page. Note, however, that people really
> like having fossil as a static binary, so that will likely be the "tier 1
> target."
>
Seems to me it would act like a static binary unless requested to load one
or more shared libraries, only calling whatever hook "services" are
registered by the shared libraries. If no libraries are loaded, then the
binary would behave as if it were static (that is, self-contained with no
required dependencies).
As an example, here is some pseudo code:
Hook_XXX( hookData )
{
if (registered(hook_XXX_service))
{
return hook_XXX_service( hookData );
}
return SUCCESS;
}
For a "notification only" hook, it could be like:
Hook_NNN( hookData )
{
if (registered(hook_NNN_service))
{
return spawn_no_wait(hook_NNN_service( hookData ));
}
return SUCCESS;
}
Baring a near complete restructuring, I think this would be the most
flexible way to add extensions to Fossil and, theoretically, could be
implemented in the current Fossil.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 5:29 AM, Konstantin Khomoutov wrote: > [...] > > But please don't also miss out a first-hand experience of someone who > implemented a well-visible program centered around Lua: [1], [2]. > > Personally, I find that minimality (of the runtime) is the only strong > point of Lua. Then it quickly falls apart when you hit its idiocy with > using tables for everything which is ripe with special weird cases. > > Lua's stack-based API debunked in [1] also sounds bad to me as I have > decent experience with extending Tcl in C (and embedding it in C), and > I find Tcl's C API to be brilliant as well as its concept of > reference-counted objects. Unfortunately, I have no experience using > Lua from C so I, personally, have no real say here. But still... > > 1. http://julien.danjou.info/blog/2011/why-not-lua > 2. http://julien.danjou.info/blog/2008/rants-about-lua > Well, everyone is entitled to her/his opinion. Hence, here is mine. I have been using Lua for the last 6 years over several projects from small to moderatly large (as in 30K Lua + 20K in C++) and it has very invigorating and positive experience. Somewhat repetative nature of stack based C-API can be substantially simplified by means of helper functions. Moreover, using LuaJIT with its own FFI facility has been a pure joy. Added bonus being that LuaJIT is the fastest JIT compiler for any scripting language out there (beats JS V8 handily). In any case give Lua or/and LuaJIT a try and form your own opinion. Just my two cents. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 9:07 PM, Aaron W.Hsu wrote: > distinguish these use cases and the technical solutions that present > themselves for these cases. Everything you’ve mentioned in your previous > email related directly to how one might have access to fossil within > another program. That is certainly useful and desirable, but what I’ve been > talking about is how people programmatically alter the behavior of the > fossil program, not how they use fossil within other programs. > The two are closely related. If the API is sane, it can be used for both purposes. When working in the use case you have mentioned, most people tend to follow > the pattern of designing a library; this library tends to be accessible > through any language that has good intra-language support. However, in the > use case that I am discussing, IMO, people usually choose either to embed a > very specific scripting language into the program to allow its behavior to > be extended, or they go with some sort of UNIX style plumbing. > Fossil has th1 as a language, but it's not scalable to the things i'd like to do with it. It cannot report error locations, for example, making debugging problematic. > > The point of my message is to suggest that Fossil might strongly consider > not tying itself down to a specific scripting language in order to extend > fossil itself (that is, the use case that has nothing to do with accessing > fossil’s capabilities from other programs or interfaces), and to not follow > others in using the UNIX plumbing approach, but instead to create an > equally robust API that allows one to extend the behavior of fossil(1) > using any programming language that they want, simply by providing a new > shared object that uses the API. > That's essentially my goal with fossil(3). Scriptability would be a natural side effect a robust/portable/flexible API, and is an important consideration in the APIs design, but scriptability itself is not the core goal - it's just bonus points. Side note: For those who don't know what this fossil(1) and fossil(3) business is - it's "man(1) notation", referring to sections 1 (applications) and 3 (libraries) of the "man page" documentation on Unix platforms. Google "man strcmp" and you'll see what i mean. It's not referring to fossil v1 and v3. > This is something completely different than what you’ve been talking > about, and it’s something that very few people do when writing extension > interfaces. > To me they are either the same or very closely related. > For instance, Emacs is extended using Elisp, and that’s pretty much it. > Monotone is in Lua. Blender is in Python. Some software does do a good job > of it, and it’s always a welcome change from the status quo. When you have > a well designed interface that can be accessed and used by your languages > of choice, no matter what they are (reasonably speaking), then you can > integrate fossil into your development workflow much easier. > i think you and i are talking about the same things, just from different angles :). > So, again, splitting fossil into a library and front end has no bearing on > this particular problem, because the technical question here is not how to > use fossil from other programs, but how fossil uses other code (ideally > written in any language) within itself. It does no good to have a library > if every time you want to extend the behavior of the fossil program you > have to write your own version of the fossil front-end. > That's the point where we differ. To me the API is the core/central concept, and everything else just kind of cascades out from there - natural side effects of having a flexible tool. fossil(1) is just one use case of fossil(3) for me. fossil(1) _can_ also be implemented as a library with a thin app shell on top of it, making it a basis for other applications (which is what i understand you would like to see?). e.g. hypothetically fossil(1) could provide Wordpress-like features to allow people to plug in their own site layouts, everything else. It could provide a server-side scripting language and an AJAX interface. Or maybe it provides slightly lower-level components which could be used with UI toolkits (e.g. some abstraction over the timeline data, which a UI app might export directly into to Excel using ODBC or COM, or whatever the current IPC model is on Windows). With fossil(3) in place, we can add any number of abstraction levels to integrate various apps in different ways. Fundamentally i think we want the exact same things, i'm just seeing the details and eventual use cases from a different perspective (from the library user level, primarily) than you. -- - 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
Re: [fossil-users] Scripting in Fossil v2
Dear Stephan: Thanks for your explanation. I, of course, agree that there are plenty of interesting benefits that one gains from having a fossil(3) in addition to a fossil(1). On the other hand, my initial email and my comments have nothing to do with a fossil(3) interface. What I’ve been talking about is how fossil, in the future, might choose to extend fossil’s behavior itself, *not* how other programs might have access to fossil capabilities. These are two quite different things. I think it is helpful to distinguish these use cases and the technical solutions that present themselves for these cases. Everything you’ve mentioned in your previous email related directly to how one might have access to fossil within another program. That is certainly useful and desirable, but what I’ve been talking about is how people programmatically alter the behavior of the fossil program, not how they use fossil within other programs. When working in the use case you have mentioned, most people tend to follow the pattern of designing a library; this library tends to be accessible through any language that has good intra-language support. However, in the use case that I am discussing, IMO, people usually choose either to embed a very specific scripting language into the program to allow its behavior to be extended, or they go with some sort of UNIX style plumbing. The point of my message is to suggest that Fossil might strongly consider not tying itself down to a specific scripting language in order to extend fossil itself (that is, the use case that has nothing to do with accessing fossil’s capabilities from other programs or interfaces), and to not follow others in using the UNIX plumbing approach, but instead to create an equally robust API that allows one to extend the behavior of fossil(1) using any programming language that they want, simply by providing a new shared object that uses the API. This is something completely different than what you’ve been talking about, and it’s something that very few people do when writing extension interfaces. For instance, Emacs is extended using Elisp, and that’s pretty much it. Monotone is in Lua. Blender is in Python. Some software does do a good job of it, and it’s always a welcome change from the status quo. When you have a well designed interface that can be accessed and used by your languages of choice, no matter what they are (reasonably speaking), then you can integrate fossil into your development workflow much easier. So, again, splitting fossil into a library and front end has no bearing on this particular problem, because the technical question here is not how to use fossil from other programs, but how fossil uses other code (ideally written in any language) within itself. It does no good to have a library if every time you want to extend the behavior of the fossil program you have to write your own version of the fossil front-end. Yours truly, Aaron W. Hsu -- Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us From: Stephan Beal Sent: Tuesday, July 23, 2013 2:58 PM To: Fossil SCM user's discussion On Tue, Jul 23, 2013 at 8:28 PM, Aaron W.Hsu wrote: Thanks for the response. I think I’m a little confused about what the intended use cases for a scripting language are? Scriptability, more than anything, is simply a benchmark which says, "this app is extensible." Personally i'm not so much interested in _how_ people extend it, just that they _can_. In my experience, adding a scripting API to a C/C++ library can drastically improve its development by allowing the devs to write more code (test cases) more quickly, and try out new ideas more easily than writing them in C. When I think of scripting the Fossil SCM I’m envisioning like post and pre-commit hooks, or adding support for a different sort of Wiki format, or integrating a release schedule or engineering methodology (so, perhaps, a change committed which triggers an engineering changes activates and populates a ticket that points to the most recent commit for consideration by another team, such as testing). Okay, imagine this: http://fossil.wanderinghorse.net/wikis/cson/?page=cson that site is actually a fossil repo, but i have completely replaced the UI with one written in HTML5, CSS, and JavaScript. That is possible because it uses the JSON API (which is, in effect, a networked library interface for fossil). Scriptability is very similar, and with it i gain the ability to write custom UIs like that in a language of my choosing. Special-purpose apps, e.g. a ticket polling widget, are a good use case for scripting. I’m not sure how having a separate library would help with this, because the user would still be interacting with the program through the fossil(1) executable. There would not be a separate program that they are running, it’s just that "The user" is an important ter
Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 8:28 PM, Aaron W.Hsu wrote: > Thanks for the response. I think I’m a little confused about what the > intended use cases for a scripting language are? > Scriptability, more than anything, is simply a benchmark which says, "this app is extensible." Personally i'm not so much interested in _how_ people extend it, just that they _can_. In my experience, adding a scripting API to a C/C++ library can drastically improve its development by allowing the devs to write more code (test cases) more quickly, and try out new ideas more easily than writing them in C. > When I think of scripting the Fossil SCM I’m envisioning like post and > pre-commit hooks, or adding support for a different sort of Wiki format, or > integrating a release schedule or engineering methodology (so, perhaps, a > change committed which triggers an engineering changes activates and > populates a ticket that points to the most recent commit for consideration > by another team, such as testing). > Okay, imagine this: http://fossil.wanderinghorse.net/wikis/cson/?page=cson that site is actually a fossil repo, but i have completely replaced the UI with one written in HTML5, CSS, and JavaScript. That is possible because it uses the JSON API (which is, in effect, a networked library interface for fossil). Scriptability is very similar, and with it i gain the ability to write custom UIs like that in a language of my choosing. Special-purpose apps, e.g. a ticket polling widget, are a good use case for scripting. > I’m not sure how having a separate library would help with this, because > the user would still be interacting with the program through the fossil(1) > executable. There would not be a separate program that they are running, > it’s just that > "The user" is an important term here. "The user" as we currently now know "the user," yes, will still be interacting with fossil(1). However, if i have access to a library which allows me to embed version control inside an arbitrary app, then i am going to use it to do things my apps cannot currently do. i.e. i want to use fossil(3) outside of fossil(1). what happens when checking out, or committing, or the like. Yes, I would > need programmatic access to do certain things from within Fossil, perhaps. > Custom reports are another case where scripting simplifies things. > However, in the course of making that access public to the world, that > would naturally require some sort of refactoring to ensure that errors and > exceptional situations were all dealt with in a way that provides the > appropriate levels of safety. > There are no intentions to break how people use fossil(1), in particular no plans to change how the current version (long may it live) works in any way. Any "librification" of fossil would/will be done under the umbrella of "version 2," and i think people expect "some" level of change between v1 and v2 of just about any program. The goal here is not to obviate fossil(1), per se, just taking it up a step on the evolutionary scale. i think it goes without saying that even if v2 appeared today, v1 would still be in widespread use for years to come. It’s much less interesting to me whether or not we can write separate, > external programs that are accessed on their own, which happen to use > Fossil as a backend. > But it is to me :-D That’s the case that I see libraries would be good for, but in the previous > case I detailed above, I don’t understand how a library would make any use, > because the point is for the user to have that code accessed and used > during the normal course of using the Fossil executable, not through a > separate program. > For 98% of users/people there will be zero interest in the underlying library (they don't need to know it exists). For the other 2% of us, though, there are all kinds of things we could do with such a tool. Adding versioning to essentially any data in any program, complete with merging, diffing, delta compression, etc. AND the stability of an sqlite data store. That's a dream come true for some of us :). -- - 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
Re: [fossil-users] Scripting in Fossil v2
Dear Stephan:
Thanks for the response. I think I’m a little confused about what the intended
use cases for a scripting language are? When I think of scripting the Fossil
SCM I’m envisioning like post and pre-commit hooks, or adding support for a
different sort of Wiki format, or integrating a release schedule or engineering
methodology (so, perhaps, a change committed which triggers an engineering
changes activates and populates a ticket that points to the most recent commit
for consideration by another team, such as testing).
I’m not sure how having a separate library would help with this, because the
user would still be interacting with the program through the fossil(1)
executable. There would not be a separate program that they are running, it’s
just that additional things happen in the background when the user starts
working with Fossil. In this case, I don’t want to be able to run something
like Checkout from a separate program; fossil(1) already lets me do a checkout,
I just want to adjust what happens when checking out, or committing, or the
like. Yes, I would need programmatic access to do certain things from within
Fossil, perhaps. However, in the course of making that access public to the
world, that would naturally require some sort of refactoring to ensure that
errors and exceptional situations were all dealt with in a way that provides
the appropriate levels of safety.
It’s much less interesting to me whether or not we can write separate, external
programs that are accessed on their own, which happen to use Fossil as a
backend. That’s the case that I see libraries would be good for, but in the
previous case I detailed above, I don’t understand how a library would make any
use, because the point is for the user to have that code accessed and used
during the normal course of using the Fossil executable, not through a separate
program.
--
Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us
From: Stephan Beal
Sent: Tuesday, July 23, 2013 2:20 PM
To: Fossil SCM user's discussion
You do, though - fossil's core logic and UI are very interwoven and its error
handling mechanism prohibits any usable scripting. For example, assume the
following pseudo-script:
fossil.open("/path/to/my.fsl")
fossil.checkout("my-branch")
if the open() fails (for _any_ reason), fossil exits _fatally_. We do not get a
chance to handle that error and try something else. This makes it impossible to
write a shell-like interface for fossil (that was one of the first things i
tried to extend fossil to do, back in 2008). It also prohibits any useful
scripting unless that scripting language is closely tied to the fossil
internals and can intercept all of the errors (which is not possible if it uses
the internal utility APIs - it would have to implement all/most of the useful
functionality itself). The current monolithic approach makes reuse next to
impossible - the user interaction and app logic are tightly woven together.
Yes, there has been some confusion about the whole "which scripting language?"
topic. The fact is, once we have a library, anyone can tie any scripting
language to it, so that question simply goes away. Specific application parts,
e.g. the HTML UI will almost certainly select some scripting language (maybe
TH1, maybe TCL, maybe lua) for their parts, but that doesn't affect others in
any way. But there might be more than one HTML UI, so even then we might end up
with multiple choices for scripting engines. If/when the v2 library starts to
become functional i will be binding it to my own scripting engine, basically as
a sanity check for, "does this API make sense for use with script bindings?"
That particular binding will be for my own use/play, though, and i don't intend
to submit it for inclusion into the core fossil project (because my scripting
engine is a toy).
--
- 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
Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 8:20 PM, Stephan Beal wrote: > Yes, there has been some confusion about the whole "which scripting > language?" topic. The fact is, once we have a library, anyone can tie any > amendment... scripting, to me, is important mainly because it provides an indication of how extensible an application is. If it has one or more scripting APIs, the chances are very good that it is also suitable for easily extending from C. So i often say "scripting" when i really mean, "extensibility." -- - 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
Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 7:57 PM, Aaron W.Hsu wrote:
> 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.
>
They are two separate things, but in the case of fossil...
> You don’t need to separate Fossil as a library in order to get a language
> agnostic extension interface for Fossil.
>
You do, though - fossil's core logic and UI are very interwoven and its
error handling mechanism prohibits any usable scripting. For example,
assume the following pseudo-script:
fossil.open("/path/to/my.fsl")
fossil.checkout("my-branch")
if the open() fails (for _any_ reason), fossil exits _fatally_. We do not
get a chance to handle that error and try something else. This makes it
impossible to write a shell-like interface for fossil (that was one of the
first things i tried to extend fossil to do, back in 2008). It also
prohibits any useful scripting unless that scripting language is closely
tied to the fossil internals and can intercept all of the errors (which is
not possible if it uses the internal utility APIs - it would have to
implement all/most of the useful functionality itself). The current
monolithic approach makes reuse next to impossible - the user interaction
and app logic are tightly woven together.
Yes, there has been some confusion about the whole "which scripting
language?" topic. The fact is, once we have a library, anyone can tie any
scripting language to it, so that question simply goes away. Specific
application parts, e.g. the HTML UI will almost certainly select some
scripting language (maybe TH1, maybe TCL, maybe lua) for their parts, but
that doesn't affect others in any way. But there might be more than one
HTML UI, so even then we might end up with multiple choices for scripting
engines. If/when the v2 library starts to become functional i will be
binding it to my own scripting engine, basically as a sanity check for,
"does this API make sense for use with script bindings?" That particular
binding will be for my own use/play, though, and i don't intend to submit
it for inclusion into the core fossil project (because my scripting engine
is a toy).
--
- 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
Re: [fossil-users] Scripting in Fossil v2
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
Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 12:55 PM, Stephan Beal wrote: > 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. > Sure thing: but if that happens (which I'm rooting for), arguing about what language is better is even sillier, since any particular binding existing doesn't negatively affect any other binding :) cheers lvh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Scripting in Fossil v2
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
Re: [fossil-users] Scripting in Fossil v2
Hi, 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*. cheers lvh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Scripting in Fossil v2
On Tue, 23 Jul 2013 11:29:32 +0200, Konstantin Khomoutov wrote: On Tue, 23 Jul 2013 11:03:09 +0200 "j. van den hoff" wrote: [...] >> While the Lua scripting enabled me to gain a level of >> sophistication and relative rigor in the process more than what I >> could get from normal UNIX >> plumbing, if my project wasn’t in Lua in the first place, I found >> it breaking my concentration a good deal more than I would have >> liked. > > That's my impression of lua, though i haven't worked with it (it's > too weird, both at the script and C API level). really? regarding the language (the scripting level) I find lua exceptionally well thought out and clear. the syntax is intentionally very "boring" -- no surprises here -- and sure much easier to swallow than tcl, for instance, for people starting from scratch. regarding the C level API I don't have any experience (nor an opinion) but it claims to be much easier than that of other scripting languages. the LaTeX guys at least have decided to move into this direction to get a real scripting facility into latex http://luatex.org/ which personally I feel was a good decision. [...] But please don't also miss out a first-hand experience of someone who implemented a well-visible program centered around Lua: [1], [2]. I don't know about `awesome' being that "well-visible". in any case the original `dwm' is much saner and way more stable (or used to be when I last looked at `awesome' a year ago or so). otherwise it's just a single (and sure not majority) view of someone who's personal taste is different. fine with me but sur not sufficient reason for dismissing lua. Personally, I find that minimality (of the runtime) is the only strong point of Lua. Then it quickly falls apart when you hit its idiocy with using tables for everything which is ripe with special weird cases. always talking from the average scripting usage perspective: I don't see any deficiency (let alone idiocy) here. works well. I don't miss any other data type/container. it's just not fancy, but works all the same. but again: I'm not a lua fan boy and ultimately I don't care what the final choice will be (if there is to be a single choice). Lua's stack-based API debunked in [1] also sounds bad to me as I have decent experience with extending Tcl in C (and embedding it in C), and I find Tcl's C API to be brilliant as well as its concept of reference-counted objects. Unfortunately, I have no experience using Lua from C so I, personally, have no real say here. But still... yes, all that might be which would mean implementation (making it work) might be less fun than it could. more important to me is the question how good the user visible part is working in the end. and here I'm still quite sure that people would be more happy with lua than with tcl (if that's the alternative), assuming they know neither before starting. but to reiterate: is it really worth the trouble to add scripting capabilities to fossil instead of focusing on more pressing improvements such as a good grep through old revisions? and also, maybe, just making a smoother more consistent CLI? fossil sure is the first VCS where I felt the need to write several small shell scripts (or use others) in order to make live easy enough (did not happen to me with svn and mercurial at least). and obviously I'm not the only one as the mailing list clearly shows... but i think I will now try to no longer disrupt this thread with such defeatism ;-) 1. http://julien.danjou.info/blog/2011/why-not-lua 2. http://julien.danjou.info/blog/2008/rants-about-lua -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Scripting in Fossil v2
On Tue, 23 Jul 2013 11:03:09 +0200 "j. van den hoff" wrote: [...] > >> While the Lua scripting enabled me to gain a level of > >> sophistication and relative rigor in the process more than what I > >> could get from normal UNIX > >> plumbing, if my project wasn’t in Lua in the first place, I found > >> it breaking my concentration a good deal more than I would have > >> liked. > > > > That's my impression of lua, though i haven't worked with it (it's > > too weird, both at the script and C API level). > > really? regarding the language (the scripting level) I find lua > exceptionally well thought out and clear. the syntax is > intentionally very "boring" -- no surprises here -- and sure much > easier to swallow than tcl, for instance, for people > starting from scratch. regarding the C level API I don't have any > experience (nor an opinion) > but it claims to be much easier than that of other scripting > languages. the LaTeX guys at least have decided to > move into this direction to get a real scripting facility into latex > http://luatex.org/ which personally > I feel was a good decision. [...] But please don't also miss out a first-hand experience of someone who implemented a well-visible program centered around Lua: [1], [2]. Personally, I find that minimality (of the runtime) is the only strong point of Lua. Then it quickly falls apart when you hit its idiocy with using tables for everything which is ripe with special weird cases. Lua's stack-based API debunked in [1] also sounds bad to me as I have decent experience with extending Tcl in C (and embedding it in C), and I find Tcl's C API to be brilliant as well as its concept of reference-counted objects. Unfortunately, I have no experience using Lua from C so I, personally, have no real say here. But still... 1. http://julien.danjou.info/blog/2011/why-not-lua 2. http://julien.danjou.info/blog/2008/rants-about-lua ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Scripting in Fossil v2
On Tue, 23 Jul 2013 10:29:36 +0200, Stephan Beal wrote: On Tue, Jul 23, 2013 at 3:25 AM, Aaron W.Hsu wrote: I’ve so far managed to avoid using the feature myself, but I have been on teams where people tried to use this to some effect, and unfortunately, the interfaces always seemed to scale very poorly. That’s not to say that they cannot be made to scale, but it seems to be a little too fragile for my sensibilities. Monotone’s integrated scripting, on the other hand, had another problem. From an user’s perspective, I found that the strict support for a single scripting language made it difficult to integrate Monotone fully into whatever project I was using. Hi Aaron, you've just summarized two of the hurdles any potential scripting language would have vis-a-vis v2. My current thinking is that if the library's interface is sane then we can bind it to arbitrary script languages and find out which one is best. i've got lots of experience with binding third-party libraries to scripting engines (SpiderMonkey, Google v8, QtScript, TH1, and custom engines) and have a fairly good feel for what is required of a C API vis-a-vis scripting engines. So i'm fairly confident that, with the help of the list, we can conquer this without all that much grief. It'll be fun :). While the Lua scripting enabled me to gain a level of sophistication and relative rigor in the process more than what I could get from normal UNIX plumbing, if my project wasn’t in Lua in the first place, I found it breaking my concentration a good deal more than I would have liked. That's my impression of lua, though i haven't worked with it (it's too weird, both at the script and C API level). really? regarding the language (the scripting level) I find lua exceptionally well thought out and clear. the syntax is intentionally very "boring" -- no surprises here -- and sure much easier to swallow than tcl, for instance, for people starting from scratch. regarding the C level API I don't have any experience (nor an opinion) but it claims to be much easier than that of other scripting languages. the LaTeX guys at least have decided to move into this direction to get a real scripting facility into latex http://luatex.org/ which personally I feel was a good decision. which is not to mean that I want to advertise lua here. ultimately I personally don't care too much and, as has been said in this thread elsewhere already I would argue that for 99.9% of the projects of 99.9% of the users there should be (and probably actually will be) no need to script a revision control system (beyond, maybe, some basic shell script drivers patching together fossil commands): the SCM needs to provide the required functionality through it's commmand set. I also do hope any potential changes/extensions will not interfere with the current 'look and feel' of fossil (the single-executable/zero-installation-overhead, minimal dependencies, and single file for whole repo (and, yes, the nice web ui, although personally I could live without it) are the things which sets fossil apart. otherwise I would just use mercurial ;-). personally, my impression is that the absence of a scripting facility is _not_ high on the least of current shortcomings. maybe, one should try to also go through the archives and the assorted wish lists and to agree among the developers which functionality changes should be implemented if the serious overhaul to realize `fossil2' (please don't call it that in the end...) is actually undertaken. `grep' sure would be high on my list as would be a more consistent and less idiosyncratic CLI. E.g., I'm very happy that recently significant progress has been achieved regarding the use of SSH (long overdue, I feel) which I find more important than any scripting facilities in one or more languages. but maybe my perspective is to limited ;-) I feel like there should be a balance when it comes to extensibility. Indeed, I think that a good DVCS ought to never require the user to start extending or programming their VCS in order to use it normally from day to day. And we shall call it "fossilmacs" :) The plug-and-play nature of Fossil is a huge advantage to me right now, as it’s so simple to use and get running on any given platform and workflow. It just works, and does not rely on any extension interface, such as a scripting or hook layer to get things done. One of my goals is that we will be able to compile specific modules in and out, e.g. the HTML UI might not be needed for someone who just wants an AJAX back-end. Ideally these could be compiled in/out or be loaded at runtime, but runtime loading is a low priority [for me] because static binaries of fossil are amazingly popular. On the other hand, it seems to me that scripting and a programmatic interface *is* very good when it comes to integrating VCS into a project’s workflow. In my experience script
Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 3:25 AM, Aaron W.Hsu wrote: > I’ve so far managed to avoid using the feature myself, but I have been on > teams where people tried to use this to some effect, and unfortunately, the > interfaces always seemed to scale very poorly. That’s not to say that they > cannot be made to scale, but it seems to be a little too fragile for my > sensibilities. Monotone’s integrated scripting, on the other hand, had > another problem. From an user’s perspective, I found that the strict > support for a single scripting language made it difficult to integrate > Monotone fully into whatever project I was using. > Hi Aaron, you've just summarized two of the hurdles any potential scripting language would have vis-a-vis v2. My current thinking is that if the library's interface is sane then we can bind it to arbitrary script languages and find out which one is best. i've got lots of experience with binding third-party libraries to scripting engines (SpiderMonkey, Google v8, QtScript, TH1, and custom engines) and have a fairly good feel for what is required of a C API vis-a-vis scripting engines. So i'm fairly confident that, with the help of the list, we can conquer this without all that much grief. It'll be fun :). > While the Lua scripting enabled me to gain a level of sophistication and > relative rigor in the process more than what I could get from normal UNIX > plumbing, if my project wasn’t in Lua in the first place, I found it > breaking my concentration a good deal more than I would have liked. > That's my impression of lua, though i haven't worked with it (it's too weird, both at the script and C API level). > I feel like there should be a balance when it comes to extensibility. > Indeed, I think that a good DVCS ought to never require the user to start > extending or programming their VCS in order to use it normally from day to > day. > And we shall call it "fossilmacs" :) > The plug-and-play nature of Fossil is a huge advantage to me right now, as > it’s so simple to use and get running on any given platform and workflow. > It just works, and does not rely on any extension interface, such as a > scripting or hook layer to get things done. > One of my goals is that we will be able to compile specific modules in and out, e.g. the HTML UI might not be needed for someone who just wants an AJAX back-end. Ideally these could be compiled in/out or be loaded at runtime, but runtime loading is a low priority [for me] because static binaries of fossil are amazingly popular. On the other hand, it seems to me that scripting and a programmatic > interface *is* very good when it comes to integrating VCS into a project’s > workflow. > In my experience scripting is the only flexible way to do this. Once an API is scriptable, all kinds of new/unimagined things become possible with it. > It’s this last part that I think should be the target of any > extensibility. I would argue that, to me, one should not direct the > programmatic interface towards end-users, but rather, those who wish to > integrate Fossil into a larger framework. > That's a good point. > In that case, I see the limitation of a single scripting language as a > problem. I also think that the ad hoc nature of a “text” based interface > like UNIX style plumbing to be a problem. Instead, perhaps there is a way > of creating a public interface to Fossil that allows one to reliably extend > its functionality without restricting yourself to a single language. > That's one of my primary goals. i recently developed my own scripting engine and will be developing a fossil wrapper in that language parallel to any v2 development, the intention being to make sure that the v2 interface is indeed suitable for scripting. Here’s a simple idea of how this might work. Publish a specific interface > in C against which people can write their code. Allow people to generate > shared objects that export a specific set of functions for registering or > extending functionality of the Fossil executable. > That's in principal where i'd like to head. i'd like for modules to be either statically or dynamically linkable, but those details are still far down the road and does not affect the planning of the overall architecture at this point. > Then, these executables can be placed inside of a specific directory, > perhaps found through a set of paths in an environment variable. > i'm also thinking something like: export FOSSIL_AUTOLOAD_MODULES=foo,bar,baz and it would try to load those from $FOSSIL_MODULES_PATH. When fossil runs, it can dynamically link in any of the shared objects that > it finds there, and these can register additional functionality with the > Fossil system. > And we're very much on the same page. Note, however, that people really like having fossil as a static binary, so that will likely be the "tier 1 target." > In this way, people can use whatever language they want to use, as long as > it has a bi-directional C F
[fossil-users] Scripting in Fossil v2
I am a relatively new Fossil user, and I have not even really stretched fossil’s muscles yet. However, I have made extensive use of Git and Monotone. I far preferred Monotone to Git, but the social pressures eventually made me give up fighting for Monotone and move to Git. I hope that Fossil can provide a number of the things that I really enjoyed about Monotone without the associated disadvantages. This brings me to the discussion that I have seen about Scripting languages in DVCS systems. I’m really not sure how I feel about scripting and all of these hooks in various DVCS systems, especially in comparison to the relative plug and play nature of Fossil. In particular, I am thinking of the very plumbing oriented nature of Git, and the very integrated scripting layer, in Lua, for Monotone. For one thing, while I enjoy the dirty convenience of the piping and UNIX style workflow for most work, I’m not as convinced when it comes to version control. I’ve so far managed to avoid using the feature myself, but I have been on teams where people tried to use this to some effect, and unfortunately, the interfaces always seemed to scale very poorly. That’s not to say that they cannot be made to scale, but it seems to be a little too fragile for my sensibilities. Monotone’s integrated scripting, on the other hand, had another problem. From an user’s perspective, I found that the strict support for a single scripting language made it difficult to integrate Monotone fully into whatever project I was using. While the Lua scripting enabled me to gain a level of sophistication and relative rigor in the process more than what I could get from normal UNIX plumbing, if my project wasn’t in Lua in the first place, I found it breaking my concentration a good deal more than I would have liked. I feel like there should be a balance when it comes to extensibility. Indeed, I think that a good DVCS ought to never require the user to start extending or programming their VCS in order to use it normally from day to day. The plug-and-play nature of Fossil is a huge advantage to me right now, as it’s so simple to use and get running on any given platform and workflow. It just works, and does not rely on any extension interface, such as a scripting or hook layer to get things done. On the other hand, it seems to me that scripting and a programmatic interface *is* very good when it comes to integrating VCS into a project’s workflow. It’s this last part that I think should be the target of any extensibility. I would argue that, to me, one should not direct the programmatic interface towards end-users, but rather, those who wish to integrate Fossil into a larger framework. In that case, I see the limitation of a single scripting language as a problem. I also think that the ad hoc nature of a “text” based interface like UNIX style plumbing to be a problem. Instead, perhaps there is a way of creating a public interface to Fossil that allows one to reliably extend its functionality without restricting yourself to a single language. Here’s a simple idea of how this might work. Publish a specific interface in C against which people can write their code. Allow people to generate shared objects that export a specific set of functions for registering or extending functionality of the Fossil executable. Then, these executables can be placed inside of a specific directory, perhaps found through a set of paths in an environment variable. When fossil runs, it can dynamically link in any of the shared objects that it finds there, and these can register additional functionality with the Fossil system. In this way, people can use whatever language they want to use, as long as it has a bi-directional C FFI, which most languages I have seen have. The fossil executable will still be shipped as a single executable, and people would only need a simple C header file to use the extended features, which can be obtained separately. It would have the benefit of a rigorously defined interface with more than textual interfaces for increased reliability of the code, but people could still use shell scripts if that’s what they really wanted to do, they would just have to be dispatched from a shared object. Just a few thoughts that I have wondered about when it comes to extension interfaces. Most of the time I tend not to use them because they don’t work with my language or they are too ad hoc for me to rely on. I think the above would solve those issues while still keeping Fossil dirt simple for the end user. -- Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
