Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 3:25 AM, Aaron W.Hsu arcf...@sacrideo.us 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 FFI, which most languages I have
Re: [fossil-users] Random thoughts on Fossil v2
On Tue, Jul 23, 2013 at 4:30 AM, Joseph R. Justice jayare...@gmail.comwrote: ...Some random thoughts on Fossil v2 as a library (call it libfossil2) and as a default client / server binary which makes use of the library (call it fossil2client or fossil2scm, I seem to have used both names), which I realize you might already know about or have thought of but just in case... (if only because I have a terminal case of Male Answer Syndrome) (and, wow, this got longer than I expected, and I apologize in advance for telling you in detail all about everything you Probably Already Knew and moreover Knew Far More About Than I Do...): Rabid rants are in no way excluded from participation, provided they remain polite ;). * Fossil2client should *not* expect or require libfossil2 to be compiled into it statically, or have an embedded copy of the source for libfossil2 within the source of fossil2client. Right. My goal here is a normal library/client relationship. Static linking is an important option for fossil (because it's popular with users) but is not a requirement. Debian, which is the Linux distro I am most familiar with, already does this (or appears to anyway) with fossil v1, see http://packages.debian.org/jessie/fossil where the fossil binary depends on libsqlite3-0 (= 3.7.11 at this instant). I don't know if fossil v1 ships with an embedded code copy of sqlite (I haven't looked), Strange. Yes, fossil embeds its own. That dependency was probably automatically determined by a script which looks for common symbol names in the resulting binary. but if it does they're stripping it in favor of sqlite as an independent library object and making their binary for fossil v1 dependent on that independent sqlite library object. i suspect it's only a bookkeeping error, and that (ld fossil) on that system will reveal that it does not link against /usr/lib/libsqlite3.so I fully expect they would / will do the same with fossil2scm as a dependency of libfossil2. They'll probably do what's easiest - if it's distributed as a package which builds everything together (as i suspect it will be) then they'll probably just 'make; make install'. * The library should be implemented in such a way that multiple versions / generations of it can be installed simultaneously. Perhaps alternatively, there should be a mechanism where the library can be queried as to which API version it is supporting, and/or instructed as to which API version a client using it understands how to use. Long term that is a good point, and if you have concrete ideas on how best to achieve this, please elaborate. Now, let's say a new release of libfossil2 is made with API version Berry (Berry Apple). Let's say there is some reason that libfossil2 with API version Berry is not fully compatible with clients that only know how to use API version Apple. Now, fossil2scm, because it comes from the fine folks who brought you libfossil2, has a new version released in conjunction with the new version of libfossil2 and the new version of fossil2scm is compatible with API version Berry. However, IDEusingfossil2 does not yet have a new release that understands API version Berry. i'm hoping that (A) 95% of the people just keep using the standalone client binary, (B) that the 5% who don't will use an amalgamation build so that they do not have such problems :/. That is the official solution sqlite3 recommends, and i see no reason not to do the same for fossil. That said, sqlite3 has much stricter compatibility requirements than fossil is likely to have. (Maybe we'll be cursed with success and indeed have to cast the API in stone at some point, but then there's always v3 to hack on...) However, note that if IDEusingfossil2 is able to tell whatever version of libfossil2 it is linked with I understand API version Apple, and I need you to behave precisely as if you are API version Apple, and if libfossil2 is willing and able to obey this requirement, then it would be possible to update libfossil2 (and other dependencies) to API version Berry even tho IDEusingfossil2 is not yet updated to understand that API. sqlite has functions which allow you to query the linked in library version, and fossil would of course have the same. * The library should be implemented in such a way that multiple instances of the library, and/or multiple different clients using either the same instance of the library and/or multiple different instances of the library, will not accidentally corrupt fossil repositories. Note that under Unix/Linux many types of file locking (especially network file locking) are less than fully secure or reliable. Those (extremely difficult) details are 100% delegated to sqlite. There's no reason fossil has no directly deal with them. * It might be worthwhile to reach out to the various major Linux and BSD Unix distros to see what will make their lives easier in terms of packaging and
Re: [fossil-users] Scripting in Fossil v2
On Tue, 23 Jul 2013 10:29:36 +0200, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 23, 2013 at 3:25 AM, Aaron W.Hsu arcf...@sacrideo.us 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
Re: [fossil-users] Scripting in Fossil v2
On Tue, 23 Jul 2013 11:03:09 +0200 j. van den hoff veedeeh...@googlemail.com 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 11:29:32 +0200, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Tue, 23 Jul 2013 11:03:09 +0200 j. van den hoff veedeeh...@googlemail.com 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
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, 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] Random thoughts on Fossil v2
On Mon, 22 Jul 2013 13:36:37 +0200 Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 22, 2013 at 1:30 PM, Eduardo Morras emorr...@yahoo.es wrote: Xcb uses an async mechanism, it creates a cookie, sends it and data to the external code, keep working. External code calls xcb, sends the cookie with the answer. Data and cookie can be exchanged through sql table. Then it starts looking like a message queue, and i personally have no intention of seeing fossil grow into such a creature. And fossil is single thread single process app and can't do any other thing while waiting. I applaud the single thread, I dislike threads too, don't understand why it must be single process. That's why I said I confused user with role. The role owns the files, not the user. Currently, a user without wiki role capabilities can't modify the wiki files. Yes he can - he simply needs to clone it. At that point any access rights fly out the window. Similar, a C developer role can modify /src dir but not /documentation or /sql, the DBA role can change /sql but not /src and similar. Role info is already exchanged in pull/push/sync, user info not. So in your scenary, a user can get the role capabilities and access them. So what happens when i (as a wiki editor) make a change to src/foo.c, commit it to my local copy (because locally i have admin access) and then try to push? i can't, and my repo then gets (permanently) out of sync. i don't think this model is possible in a DVCS. Yes it is. There's a big difference between Project and Repository. There's the fossil project, only one, but there are lots of repositories and fossil project forks that aren't the main 'Fossil Project'. I don't want to restrict what you do with your repository or your project fork, I want to restrict what you can do to main Project. The problem is that a user is admin of his own repository file and can set whatever s/he wants and access everything. A global dvcs role and user data can solve this, not allowing this user make changes in public branches or trunk directories of central repo (or other users repos) if s/he has no privileges to do so. Once i clone it, the central repository has NO say-so in what i can and cannot check out. It can only control what i check IN, or (more correctly), what i try to push to the central server. If it will not let me push the changes i have already committed to my local repo then i have a serious problem. No, I sync with fossil main repository each week, but I don't have permission to push my changes. That's because my user (anonymous) don't have the role to do so. If I want to push my changes I must convince someone who has the correct role to do so. I want to restrict that a developer user, with a defined role, can push changes only to certains files/directories of main repository and not others. For example, in Fossil, sqlite3.c, sqlite3.h, copyright file, makefile, etc... should be changed only by user drh, at least in trunk, because he is the project architect. It's true that 'it shouldn't happen if everyone follow the manual and touch the files he owns', but there are sometimes, specially with newbies, that the repository becomes unusable because they touch a file they shouldn't. --- --- Eduardo Morras emorr...@yahoo.es ___ 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] Random thoughts on Fossil v2
On Tue, Jul 23, 2013 at 1:04 PM, Eduardo Morras emorr...@yahoo.es wrote: Yes it is. There's a big difference between Project and Repository. There's the fossil project, only one, but there are lots of repositories and fossil project forks that aren't the main 'Fossil Project'. I don't want to restrict what you do with your repository or your project fork, I want to restrict what you can do to main Project. That's the problem: my clone of your project is a first-class copy of your project. There is essentially no distinction. If you copy goes up in flames me can drop in my copy, re-add the users, and we're done. So here's what happens with user restrictions: - i clone your repo - i edit some dir which you have restricted. - i check it in locally (offline) - Later i try to push to your repo and it fails. My repo is now in a state where i can _never_ push my copy to yours ever again because pushing to yours will fail as long as i have no access (on your side) for that file. No, I sync with fossil main repository each week, but I don't have permission to push my changes. That's because my user (anonymous) don't have the role to do so. If I want to push my changes I must convince someone who has the correct role to do so. But for partial access ALL pushes from me to you will fail if i have edited a file to which i cannot push. There is no partial push in fossil - you can push everything or nothing. Fossil, as a piece of software, could not possibly decide which parts of my commits are safe to push, and Fossil _MUST_ fail if _any_ part of my push/sync fails because it has no heuristic which can say, oh, that was just that file under /noaccess/... which you edited 3 weeks ago and is still not writable for you (and if it could decide that, then failing is still the proper response). The only reasonable action Fossil can take there is to fail. How could it possibly know which parts are okay and which not? How can i possibly ever recover my repo to a sane state if you refuse to give me write access to changes i have already made locally (but not cannot commit, leaving my repo in an unclean/divergent state). -- - 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] Random thoughts on Fossil v2
On Tue, 23 Jul 2013 13:17:47 +0200 Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 23, 2013 at 1:04 PM, Eduardo Morras emorr...@yahoo.es wrote: Yes it is. There's a big difference between Project and Repository. There's the fossil project, only one, but there are lots of repositories and fossil project forks that aren't the main 'Fossil Project'. I don't want to restrict what you do with your repository or your project fork, I want to restrict what you can do to main Project. That's the problem: my clone of your project is a first-class copy of your project. There is essentially no distinction. If you copy goes up in flames me can drop in my copy, re-add the users, and we're done. So here's what happens with user restrictions: - i clone your repo - i edit some dir which you have restricted. - i check it in locally (offline) - Later i try to push to your repo and it fails. My repo is now in a state where i can _never_ push my copy to yours ever again because pushing to yours will fail as long as i have no access (on your side) for that file. I must insist here ;) There's a distinction, your repository is not the official Project repository, mine, the central one, yes. You can fork and create a new project and name it as you wish and change what you want. If you want to merge with the Only and Real True Project, your changes must be approved by the person that has the permission to do that, that's me. No, I sync with fossil main repository each week, but I don't have permission to push my changes. That's because my user (anonymous) don't have the role to do so. If I want to push my changes I must convince someone who has the correct role to do so. But for partial access ALL pushes from me to you will fail if i have edited a file to which i cannot push. There is no partial push in fossil - you can push everything or nothing. Fossil, as a piece of software, could not possibly decide which parts of my commits are safe to push, and Fossil _MUST_ fail if _any_ part of my push/sync fails because it has no heuristic which can say, oh, that was just that file under /noaccess/... which you edited 3 weeks ago and is still not writable for you (and if it could decide that, then failing is still the proper response). The only reasonable action Fossil can take there is to fail. How could it possibly know which parts are okay and which not? How can i possibly ever recover my repo to a sane state if you refuse to give me write access to changes i have already made locally (but not cannot commit, leaving my repo in an unclean/divergent state). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal --- --- Eduardo Morras emorr...@yahoo.es ___ 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 arcf...@sacrideo.us 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
On Tue, Jul 23, 2013 at 8:20 PM, Stephan Beal sgb...@googlemail.com 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
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:28 PM, Aaron W.Hsu arcf...@sacrideo.us 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 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 arcf...@sacrideo.us 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
Re: [fossil-users] Scripting in Fossil v2
On Tue, Jul 23, 2013 at 9:07 PM, Aaron W.Hsu arcf...@sacrideo.us 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] Any objections to renaming /stats_report...
On Sun, Jul 21, 2013 at 7:49 PM, Richard Hipp d...@sqlite.org wrote: On Sun, Jul 21, 2013 at 11:42 AM, Stephan Beal sgb...@googlemail.comwrote: ... to /reports? the name /stats_report just seems cumbersome to me. I have no objections. I suggest you want a few days and if you get no other replies, then make the change. @List: the countdown is running. Sometime this weekend /stats_report will be renamed to /reports unless someone comes up with a better name (consider that a challenge ;). -- - 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] Any objections to renaming /stats_report...
I personally have no objections, but as a matter of business and visibility, perhaps do final last call for objections/alternatives! on a business day. On Jul 23, 2013 12:59 PM, Stephan Beal sgb...@googlemail.com wrote: On Sun, Jul 21, 2013 at 7:49 PM, Richard Hipp d...@sqlite.org wrote: On Sun, Jul 21, 2013 at 11:42 AM, Stephan Beal sgb...@googlemail.comwrote: ... to /reports? the name /stats_report just seems cumbersome to me. I have no objections. I suggest you want a few days and if you get no other replies, then make the change. @List: the countdown is running. Sometime this weekend /stats_report will be renamed to /reports unless someone comes up with a better name (consider that a challenge ;). -- - 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] Random thoughts on Fossil v2
Here are a couple features that would make fossil a reasonable replacement for zim wiki and might be worth considering for fossil2.0. 1. Ability to Edit/save/commit files from the UI. 2. In wiki files square brackets at beginning of line parse into check box list (as is done in zim wiki). On Sun, Jul 21, 2013 at 3:54 AM, Stephan Beal sgb...@googlemail.com wrote: Hi, all, This topic has been tossed around before, but the amount of effort involved in its undertaking has always kept us from actually doing it... To help bootstrap the process of figuring out what Fossil v2 might look like i have started writing down ideas in a public Google Doc: https://docs.google.com/document/d/12g0s5A2TPX7-y47Nsw235rvsjcuh49TnHfMDB4ASvlo/view Any of you who have write access to the JSON API docs also have write access to that one, so feel free to expand/comment/etc. It's just a big scratchpad, not a formal doc, nor does it provide any indication of what Fossil's future has in store - it's just ideas regarding what v2 might look like if i were to start working on it today (which, in a way, i am ;). If you don't have access to that doc, either send me your gmail address and i'll gladly add you, or post your ideas here and i'll integrate them into the doc. -- - 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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] Random thoughts on Fossil v2
Bit late to the party, but my 2 cents 1) Fossil as a library or API with the fossil executable as a single file built on top of it. One could even consider a SCGI/FCGI type of interface where the fossil binary serves JSON+BSON requests. 2) Ticket notifications by email (notification when merged into my main repo would be fine). Using the ticketing system for any app with a decent userbase is a pain right now. Mark On Tue, Jul 23, 2013 at 10:35 PM, Matt Welland estifo...@gmail.com wrote: Here are a couple features that would make fossil a reasonable replacement for zim wiki and might be worth considering for fossil2.0. 1. Ability to Edit/save/commit files from the UI. 2. In wiki files square brackets at beginning of line parse into check box list (as is done in zim wiki). On Sun, Jul 21, 2013 at 3:54 AM, Stephan Beal sgb...@googlemail.comwrote: Hi, all, This topic has been tossed around before, but the amount of effort involved in its undertaking has always kept us from actually doing it... To help bootstrap the process of figuring out what Fossil v2 might look like i have started writing down ideas in a public Google Doc: https://docs.google.com/document/d/12g0s5A2TPX7-y47Nsw235rvsjcuh49TnHfMDB4ASvlo/view Any of you who have write access to the JSON API docs also have write access to that one, so feel free to expand/comment/etc. It's just a big scratchpad, not a formal doc, nor does it provide any indication of what Fossil's future has in store - it's just ideas regarding what v2 might look like if i were to start working on it today (which, in a way, i am ;). If you don't have access to that doc, either send me your gmail address and i'll gladly add you, or post your ideas here and i'll integrate them into the doc. -- - 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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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
[fossil-users] mingw and default ssh command
Hi all, I've notice that here: http://fossil-scm.org/index.html/artifact/111c393f1bb93a3585078d5ee23e0b3ecc1408fe?ln=97,101 the -e none argument to ssh is removed when __MINGW32__ is defined. Is there a reason for that ? On my windows setup, I have mingw and I use openssh that come with msys. I know it's not a big issue and we can set the command using set, but I think that default values have to be working ones.. Regards, -- Martin G. ___ 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 flatw...@users.sourceforge.net 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 4:29 AM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Jul 23, 2013 at 3:25 AM, Aaron W.Hsu arcf...@sacrideo.us 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
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 arcf...@sacrideo.us 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
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
Re: [fossil-users] Random thoughts on Fossil v2
On Tue, Jul 23, 2013 at 10:35 PM, Matt Welland estifo...@gmail.com wrote: Here are a couple features that would make fossil a reasonable replacement for zim wiki and might be worth considering for fossil2.0. 1. Ability to Edit/save/commit files from the UI. That one's been on my TODO for a long time because the JSON API really wants this for embedded docs (which are just files, so it would then work for any text file). 2. In wiki files square brackets at beginning of line parse into check box list (as is done in zim wiki). That's at a much further downstream and the whole Wiki Wars are a topic i'm gonna side-step for the time being ;). In case you've missed them in the past... i think wiki-related threads are the only ones who approached this one's size. -- - 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] Random thoughts on Fossil v2
On Tue, Jul 23, 2013 at 10:42 PM, Mark Janssen mpc.jans...@gmail.comwrote: Bit late to the party, but my 2 cents Not late at all - the ball's just getting rolling. 1) Fossil as a library or API with the fossil executable as a single file built on top of it. One could even consider a SCGI/FCGI type of interface where the fossil binary serves JSON+BSON requests. i think the idea of the lib/app separation is starting to sink in with people :). 2) Ticket notifications by email (notification when merged into my main repo would be fine). Using the ticketing system for any app with a decent userbase is a pain right now. That one would come almost automatically as a side effect of triggers support, i suspect, which is high on many peoples' wish lists. -- - 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 ronw.m...@gmail.com 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
On Wed, Jul 24, 2013 at 1:32 AM, B Harder brad.har...@gmail.com 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] mingw and default ssh command
Thus said Martin Gagnon on Tue, 23 Jul 2013 16:57:46 -0400: the -e none argument to ssh is removed when __MINGW32__ is defined. Is there a reason for that ? On my windows setup, I have mingw and I use openssh that come with msys. I'm not sure why it would be this way. If all versions of ssh that run on Windows support -e then we might as well set the default ssh command to ssh -e none -T for all OSes and drop the #ifdef. Now, there must be a way to search fossil for when a particular line of code was introduced... Looks like it was introduced here: http://fossil-scm.org/index.html/info/0cdb6403cb1dd73d So it looks like it was part of working with plink.exe which apparently does not support -e: http://the.earth.li/~sgtatham/putty/0.62/htmldoc/Chapter7.html#plink What I don't understand is... how does a default of ``ssh -T'' translate into ``plink.exe -T'' on Windows? When you install plink.exe does it get aliased somehow as ssh? At any rate, if we specify -e as a default on Windows, then it would only work for versions of ssh on Windows that understand -e. Andy -- TAI64 timestamp: 400051ef2b67 ___ 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 1:55 AM, Aaron W.Hsu arcf...@sacrideo.us 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 quite that far ;). Let me focus
[fossil-users] admin pages are empty and have bad titles
I've started a fossil repo by importing a git repo to my local laptop, and
then cloning the repo over to my target production web server.
For testing, I've exposed the fossil server like this:
/usr/local/bin/fossil server /home/fossil/myrepo.fossil --th-trace -P 10080
--baseurl http://localhost:10080/
and I'm accessing the server from my laptop using an ssh tunnel:
ssh -L 10080:localhost:10080 mycompany.com
so that I can point my browser to localhost:10080 and see the site exposed
by fossil. Works fine, including login etc, until I try to access an admin
page.
By an admin page, I mean any admin page. They all behave the same.
I click Admin and that works fine. I click any of the links, and I'm
taken to a web page that has all of fossil's normal headers (so the name of
my project, who I'm logged in as, links for Admin, the Timeline etc) but
the body of the web page says Empty page. And the page title is e.g.
xfersetup instead of Transfer Setup. The other pages' titles are
analogous.
The TH tracer shows no indication that there is a capabilities issue:
=
BEGIN_HEADER
th1-setup {} = TH_OK
set project_name {My project name}
set title {xfersetup}
set baseurl {http://localhost:10080/}
set home {}
set index_page {/home}
set current_page {?name=xfersetup}
set release_version {1.26}
set manifest_version {[c9cb6e7293]}
set manifest_date {2013-06-18 21:09:23}
set compiler_name {gcc-4.4.5 20101112 (Red Hat 4.4.5-2)}
set login {eas}
BEGIN_HEADER_SCRIPT
eval {
if {[info exists login]} {
puts Logged in as $login
} else {
puts Not logged in
}
}
eval {
html a href='$home$index_page'Home/a\n
if {[anycap jor]} {
html a href='$home/timeline'Timeline/a\n
}
if {[hascap oh]} {
html a href='$home/dir?ci=tip'Files/a\n
}
if {[hascap o]} {
html a href='$home/brlist'Branches/a\n
html a href='$home/taglist'Tags/a\n
}
if {[hascap r]} {
html a href='$home/reportlist'Tickets/a\n
}
if {[hascap j]} {
html a href='$home/wiki'Wiki/a\n
}
if {[hascap s]} {
html a href='$home/setup'Admin/a\n
} elseif {[hascap a]} {
html a href='$home/setup_ulist'Users/a\n
}
if {[info exists login]} {
html a href='$home/login'Logout/a\n
} else {
html a href='$home/login'Login/a\n
}
}
[hascap jor] = 1
[hascap oh] = 1
[hascap o] = 1
[hascap r] = 1
[hascap j] = 1
[hascap s] = 1
END_HEADER
BEGIN_FOOTER
eval {
puts [expr {([utime]+[stime]+1000)/1000*0.001}]
}
END_FOOTER
=
Any hints?
Thanks,
Eric
___
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] admin pages are empty and have bad titles
Thus said Eric Rubin-Smith on Tue, 23 Jul 2013 22:02:11 -0400: /usr/local/bin/fossil server /home/fossil/myrepo.fossil --th-trace -P 10080 --baseurl http://localhost:10080/ Try removing the --baseurl option. It works for me when I do: fossil server /tmp/test.fossil ssh -L 10080:localhost:10080 remote Andy -- TAI64 timestamp: 400051ef3a90 ___ 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] admin pages are empty and have bad titles
Thus said Andy Bradford on 23 Jul 2013 20:22:37 -0600: fossil server /tmp/test.fossil Of course I meant: fossil server -P 10080 /tmp/test.fossil ssh -L 10080:localhost:10080 remote Cheers, Andy -- TAI64 timestamp: 400051ef3c17 ___ 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] admin pages are empty and have bad titles
Yes, that works for the test case. But I think I'll need --baseurl for when I put fossil behind an SSL-terminating reverse proxy and want to access it using the company FQDN. On Tue, Jul 23, 2013 at 10:22 PM, Andy Bradford amb-sendok-1377224557.emjjjkijcgiknbipb...@bradfords.org wrote: Thus said Eric Rubin-Smith on Tue, 23 Jul 2013 22:02:11 -0400: /usr/local/bin/fossil server /home/fossil/myrepo.fossil --th-trace -P 10080 --baseurl http://localhost:10080/ Try removing the --baseurl option. It works for me when I do: fossil server /tmp/test.fossil ssh -L 10080:localhost:10080 remote Andy -- TAI64 timestamp: 400051ef3a90 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] v2 hello, world app
i know you guys are probably sick of hearing about the hypothetical v2 by now, but i haven't slept and need an outlet ;). A brief demo of all [two] currently working v2 features can be seen here: http://fossil.wanderinghorse.net/repos/f2/index.cgi/wiki?name=home It can open _and_ close an existing DB without leaking memory :-D. http://fossil.wanderinghorse.net/repos/f2/index.cgi/artifact/457ea11cd2700dd3d8e099c98000565a9f10ad1d -- - 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
