Re: [fossil-users] Feature request: edit files via web interface
On Tue, Sep 20, 2011 at 1:38 AM, Joshua Paine jos...@letterblock.comwrote: On 9/19/2011 7:15 PM, Stephan Beal wrote: To the C side it's pretty easy, but adding any sort of encoding inherently limits the clients which can use it. Well, unless you only use it for stuff that fossil treats as binary anyway, in which case no one's limited, because the alternative is not having access at all. LOL! That's a very fair point. (Sometimes my short-sightedness frightens me.) and JS cannot natively deal with binary data (that's coming in v5 or whatever new version is coming soon). Standard javascript doesn't have this ability yet, but individual impl have relevant capabilities. E.g., privileged JS in XUL has access to files and can get base64 strings from them, and the canvas element has a toDataURL method that returns base64 encoded data plus a tiny amount of metadata. The JS version accompanying HTMLv5 (i don't remember the version number) contains some support for binary data. Some browsers have already started implementing this and some apps already use it (e.g. gmail). So the option for binary data certainly can't be ruled out altogether. OTOH, while JS is expected to (==i expect) be the primary client, there will likely be other platforms out there for which base64 is more convenient. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] any interest in integrating jimtcl w/ fossil?
Hi, all, i'm just curious - is there any interest out there in integrating jimtcl with fossil, e.g. as a replacement for th1? While i'm not currently a tcl user, binding C/C++ code to scripting languages is a hobby of mine (e.g. http://code.google.com/p/v8-juice), and i'd be interested in assisting with such an effort, but until the JSON API is done i couldn't take it on myself. If we had the full power of tcl, as opposed to the minimalistic th1, we could almost certainly do some really cool things with it, e.g. adding new features completely in tcl. :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 interest in integrating jimtcl w/ fossil?
On 09/20/11 11:19, Stephan Beal wrote: Hi, all, i'm just curious - is there any interest out there in integrating jimtcl with fossil, e.g. as a replacement for th1? While i'm not currently a tcl user, binding C/C++ code to scripting languages is a hobby of mine (e.g. http://code.google.com/p/v8-juice), and i'd be interested in assisting with such an effort, but until the JSON API is done i couldn't take it on myself. If we had the full power of tcl, as opposed to the minimalistic th1, we could almost certainly do some really cool things with it, e.g. adding new features completely in tcl. Yes. It is one of my plans, the reasons I joined here, to extend fossil with tcl. Whether that's ought to be jimtcl (for size and embedding concerncs) or the real full-blown tcl (for compatibility with the language and all the software out there), I haven't come to a decision yet. Of course the single-file approach of fossil has to be kept up. So if you want to include a standard library, starpacks etc. come into play.. Anyways, I'm still sketching and juggling available time with other projects :) But definitely, I want to see a real language in fossil, and fossil being a library for that language... -Martin ___ 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 interest in integrating jimtcl w/ fossil?
On Tue, Sep 20, 2011 at 5:44 PM, Martin S. Weber martin.we...@nist.govwrote: Yes. It is one of my plans, the reasons I joined here, to extend fossil with tcl. Whether that's ought to be jimtcl (for size and embedding concerncs) or the i only suggest jim because it's already in the source tree (and it appears to be quite powerful, with lots of optional modules). And jimtcl is a one-file distribution, so physically the integration is trivial. Anyways, I'm still sketching and juggling available time with other projects :) But definitely, I want to see a real language in fossil, and fossil being a library for that language... i'd be interested in helping out, but i haven't currently got the spare energy to pick this up and run with it. Preferably, someone who's experienced with tcl should lead it because they'll see more of the pitfalls and dead ends in advance, whereas i would end up discovering them along the way ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 interest in integrating jimtcl w/ fossil?
On 09/20/11 11:52, Stephan Beal wrote: On Tue, Sep 20, 2011 at 5:44 PM, Martin S. Weber martin.we...@nist.gov mailto:martin.we...@nist.gov wrote: Yes. It is one of my plans, the reasons I joined here, to extend fossil with tcl. Whether that's ought to be jimtcl (for size and embedding concerncs) or the i only suggest jim because it's already in the source tree (and it appears to be quite powerful, with lots of optional modules). And jimtcl is a one-file distribution, so physically the integration is trivial. I know and like jim. I was around on the tclers chat when it was conceived :) There's one thing that I don't like about it now though, there's no clear compatibility statement wrt tcl itself, or at least none I could find. I'd like a table of all the tcl commands and their subcommands and a check-or-cross for their support in jimtcl... Without that, it's hard to decide which to take. Naturally, Tcl in itself is highly portable, and a good enough wrapper around exec (via the file command) to support wrappers/triggers portably. It's gonna be fun to hack this up. On a side note, fossil should grow something to import artifacts-with-history from other projects/databases. Tcl itself is managed via fossil. If fossil could import properly, 3rd party software use could be handled way better imho... -Martin ___ 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 interest in integrating jimtcl w/ fossil?
On Tue, 20 Sep 2011 17:19:34 +0200 Stephan Beal sgb...@googlemail.com wrote: i'm just curious - is there any interest out there in integrating jimtcl with fossil, e.g. as a replacement for th1? While i'm not currently a tcl user, binding C/C++ code to scripting languages is a hobby of mine (e.g. http://code.google.com/p/v8-juice), and i'd be interested in assisting with such an effort, but until the JSON API is done i couldn't take it on myself. If we had the full power of tcl, as opposed to the minimalistic th1, we could almost certainly do some really cool things with it, e.g. adding new features completely in tcl. Not that I ever had any need to touch either th1 or jimtcl, but I'd like to ask an obligatory question: what are the current th1's shortcomings so that replacing it with something else is needed? ___ 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 interest in integrating jimtcl w/ fossil?
On 09/20/11 12:07, Konstantin Khomoutov wrote: Not that I ever had any need to touch either th1 or jimtcl, but I'd like to ask an obligatory question: what are the current th1's shortcomings so that replacing it with something else is needed? It's no general programming language. It is modeled after Tcl, but implements only a very tiny subset of the language. What Th1 is doing can be done as well by a full-blown programming language. Having one of the latter integrated with fossil would also mean that you can call fossil from the language (and not only the other way around). Which would enable you to integrate fossil into more software written in that language. Choosing a portable language like Tcl, which supports portable path names, program execution etc., has the benefit that then you can implement hooks/triggers as calls to tcl procedures, which then may (portably) call external programs if they so wish, or use existing, stable and featureful libraries for performing the checks/actions they wish to perform. -Martin ___ 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 interest in integrating jimtcl w/ fossil?
On Tue, 20 Sep 2011 12:20:32 -0400 Martin S. Weber martin.we...@nist.gov wrote: Not that I ever had any need to touch either th1 or jimtcl, but I'd like to ask an obligatory question: what are the current th1's shortcomings so that replacing it with something else is needed? It's no general programming language. It is modeled after Tcl, but implements only a very tiny subset of the language. What Th1 is doing can be done as well by a full-blown programming language. Having one of the latter integrated with fossil would also mean that you can call fossil from the language (and not only the other way around). Which would enable you to integrate fossil into more software written in that language. Choosing a portable language like Tcl, which supports portable path names, program execution etc., has the benefit that then you can implement hooks/triggers as calls to tcl procedures, which then may (portably) call external programs if they so wish, or use existing, stable and featureful libraries for performing the checks/actions they wish to perform. Well, my question was actually a veiled uneasy feeling about possible code bloat and feature creep. While I *am* a Tcl aficionado, for me, one of the Fossil's selling points is its self-containment and a minimal set of dependencies. Won't we get another Mercurial? ___ 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 interest in integrating jimtcl w/ fossil?
On 9/20/2011 9:01 AM, Martin S. Weber wrote: On a side note, fossil should grow something to import artifacts-with-history from other projects/databases. How would the proposed command (extension) differ from the existing fossil import --incremental --git REPOSITORY GIT-FAST-EXPORT-FILE ? -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 andre...@activestate.com http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog ___ 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 interest in integrating jimtcl w/ fossil?
On 09/20/11 12:49, Konstantin Khomoutov wrote: Well, my question was actually a veiled uneasy feeling about possible code bloat and feature creep. If you look at the top feature request for fossil I wouldn't say that's bloat or feature creep. It's a necessity for fossil to be considered in some settings. While I *am* a Tcl aficionado, for me, one of the Fossil's selling points is its self-containment and a minimal set of dependencies. As I've written in another email, the single-file blessing of fossil needs to be contained. Anything not fulfilling that is a failure even before its conception. Static linking of the respective language library is a must, as is self-containment of its (standard) library. Users may choose to use the system installations for both, naturally, as is possible already right now for using the system sqlite. But I do not want, at all, to touch the single file blessing of fossil. Regards, -Martin ___ 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 interest in integrating jimtcl w/ fossil?
On 09/20/2011 07:07 PM, Konstantin Khomoutov wrote: Not that I ever had any need to touch either th1 or jimtcl, but I'd like to ask an obligatory question: what are the current th1's shortcomings so that replacing it with something else is needed? An excellent question... ___ 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 interest in integrating jimtcl w/ fossil?
Yes. It is one of my plans, the reasons I joined here, to extend fossil with tcl. Whether that's ought to be jimtcl (for size and embedding concerncs) or the real full-blown tcl (for compatibility with the language and all the software out there), I haven't come to a decision yet. Of course the single-file approach of fossil has to be kept up. So if you want to include a standard library, starpacks etc. come into play.. Has you looked at the tcl-integration branch in Fossil? It has experimental changes to allow full-blown Tcl to be used in Fossil. It allows Tcl and TH1 to call into each other. Currently, I've only modified the MSVC makefile; however, I was hoping somebody would help me to add the necessary configure magic to link with Tcl on Unix. -- Joe Mistachkin ___ 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 interest in integrating jimtcl w/ fossil?
On 09/20/11 12:55, Andreas Kupries wrote: On 9/20/2011 9:01 AM, Martin S. Weber wrote: On a side note, fossil should grow something to import artifacts-with-history from other projects/databases. How would the proposed command (extension) differ from the existing fossil import --incremental --git REPOSITORY GIT-FAST-EXPORT-FILE You're saying to import another fossil project A into my project B, I should export that other project into A.git and then import the resulting project A.git into B.fossil? -Martin ___ 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 interest in integrating jimtcl w/ fossil?
On Tue, Sep 20, 2011 at 6:49 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: Well, my question was actually a veiled uneasy feeling about possible code bloat and feature creep. That's certainly a fair concern. While I *am* a Tcl aficionado, for me, one of the Fossil's selling points is its self-containment and a minimal set of dependencies. That's the beauty of jimtcl - it's already there and required (or optionally used) by the build process, so deps aren't a problem here. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 interest in integrating jimtcl w/ fossil?
On 09/20/11 12:58, Joe Mistachkin wrote: Has you looked at the tcl-integration branch in Fossil? It has experimental changes to allow full-blown Tcl to be used in Fossil. It allows Tcl and TH1 to call into each other. I've seen it, but I disagree with the approach. Tcl is a superset of Th1. Th1 should disappear within tcl, if tcl is present, IMO. -Martin ___ 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 interest in integrating jimtcl w/ fossil?
On Tue, Sep 20, 2011 at 6:58 PM, Joe Mistachkin sql...@mistachkin.comwrote: Has you looked at the tcl-integration branch in Fossil? It has experimental changes to allow full-blown Tcl to be used in Fossil. It allows Tcl and TH1 to call into each other. i wasn't aware of that, no. Currently, I've only modified the MSVC makefile; however, I was hoping somebody would help me to add the necessary configure magic to link with Tcl on Unix. If one of the tcl guys doesn't respond to this i'll take a look. i'm don't know off hand what the conventional/portable way to get these args is on Unix, e.g. if there's a tcl-config script to which we can pass --cflags or --ldflags to get the compiler/linker args. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 interest in integrating jimtcl w/ fossil?
On Tue, Sep 20, 2011 at 7:01 PM, Martin S. Weber martin.we...@nist.govwrote: I've seen it, but I disagree with the approach. Tcl is a superset of Th1. Th1 should disappear within tcl, if tcl is present, IMO. +1 -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 interest in integrating jimtcl w/ fossil?
On 09/20/11 13:00, Stephan Beal wrote: On Tue, Sep 20, 2011 at 6:49 PM, Konstantin Khomoutov flatw...@users.sourceforge.net mailto:flatw...@users.sourceforge.net wrote: While I *am* a Tcl aficionado, for me, one of the Fossil's selling points is its self-containment and a minimal set of dependencies. That's the beauty of jimtcl - it's already there and required (or optionally used) by the build process, so deps aren't a problem here. Dependencies on the source level never are a concern (if the license is right) because we can import anything into some subdirectory of fossil's fossil. It's run-time dependencies that count. Yes, jim fares well there, too, but I have other concerns with it... -Martin ___ 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 interest in integrating jimtcl w/ fossil?
On 9/20/2011 9:59 AM, Martin S. Weber wrote: On 09/20/11 12:55, Andreas Kupries wrote: On 9/20/2011 9:01 AM, Martin S. Weber wrote: On a side note, fossil should grow something to import artifacts-with-history from other projects/databases. How would the proposed command (extension) differ from the existing fossil import --incremental --git REPOSITORY GIT-FAST-EXPORT-FILE You're saying to import another fossil project A into my project B, I should export that other project into A.git and then import the resulting project A.git into B.fossil? Ah. You wish to merge two (or more) projects into a single history. That wasn't fully clear to me from the original description. The only related thing I could think of was 'import', hence my question. Right, I don't believe that this can be done with the existing import or other functionality of fossil. What is not clear to me still, how to merge the two independent histories of A and B into a single timeline ? Especially in the presence of branches. This however I leave to others to think about. -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 andre...@activestate.com http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog ___ 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 interest in integrating jimtcl w/ fossil?
On Tue, Sep 20, 2011 at 7:15 PM, Andreas Kupries andre...@activestate.comwrote: Especially in the presence of branches. This however I leave to others to think about. Was the branch/leave pun intended? ;) -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 interest in integrating jimtcl w/ fossil?
On 9/20/2011 10:17 AM, Stephan Beal wrote: On Tue, Sep 20, 2011 at 7:15 PM, Andreas Kupries andre...@activestate.com mailto:andre...@activestate.com wrote: Especially in the presence of branches. This however I leave to others to think about. Was the branch/leave pun intended? ;) No. And not noticing it gives insight into my state of mind right now, i.e. slightly not here. -- Andreas Kupries Senior Tcl Developer ActiveState, The Dynamic Language Experts P: 778.786.1122 F: 778.786.1133 andre...@activestate.com http://www.activestate.com Get insights on Open Source and Dynamic Languages at www.activestate.com/blog ___ 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 interest in integrating jimtcl w/ fossil?
I did this with one of my projects which consists of a core library, web-based and Android app. The way I did this was to create a bunch of projects out of the git exports, s/master/someotherbranchname/g in the export dumps, create them into separate fossils, dump/restore the config table from one repository into all of them such that they had the same project ID, then pull the individual fossils into one. At least, I think that was how I did it. Having actual blessed support for this in the tools would be awesome, because there are other instances where I want to do this and it'd be nice to have a less error-prone process. Similarly, it'd be neat to break one branch out of a fossil and place it in another if I want to split them apart later. Of course, this can be done from a new project starting from scratch. I'd just like the flexibility to develop a bunch of related projects together, then split them apart later if one takes on a life of its own, or to bring someone else's project under my umbrella if it matures far enough. On 09/20/2011 12:15 PM, Andreas Kupries wrote: On 9/20/2011 9:59 AM, Martin S. Weber wrote: On 09/20/11 12:55, Andreas Kupries wrote: On 9/20/2011 9:01 AM, Martin S. Weber wrote: On a side note, fossil should grow something to import artifacts-with-history from other projects/databases. How would the proposed command (extension) differ from the existing fossil import --incremental --git REPOSITORY GIT-FAST-EXPORT-FILE You're saying to import another fossil project A into my project B, I should export that other project into A.git and then import the resulting project A.git into B.fossil? Ah. You wish to merge two (or more) projects into a single history. That wasn't fully clear to me from the original description. The only related thing I could think of was 'import', hence my question. Right, I don't believe that this can be done with the existing import or other functionality of fossil. What is not clear to me still, how to merge the two independent histories of A and B into a single timeline ? Especially in the presence of branches. This however I leave to others to think about. ___ 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 interest in integrating jimtcl w/fossil?
Excuse my bluntness: that sounds like a terrible idea. Tcl is huge compared to fossil, and certainly not installed everywhere by default. And for what benefit? To have a full-blown programming language built in? That of course isn't a benefit in itself. If an organization needs some sort of sophisticated processing attached to a hook, e.g. some verification on commits, let them call an external program, a shell script, a tcl script, whatever. Embedding an interpreter into Fossil itself, to run code called by the hook, seems like entirely the wrong approach. ___ 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 interest in integrating jimtcl w/fossil?
On 09/20/11 13:38, Steve Havelka wrote: Excuse my bluntness: that sounds like a terrible idea. Tcl is huge compared to fossil, and certainly not installed everywhere by default. Which is why it would have to be integrated in the fossil source, built from source, and attached to fossil at buildtime. No runtime dependencies. Alternatively, if jimtcl was the way to go, we're talking about a 200k increase in the fossil binary, no external dependencies at all. Does that sound so bad? And for what benefit? To have a full-blown programming language built in? It's the other way around. Proper tcl integration would also mean to turn fossil around, so that fossil is actually the library, allowing to call any fossil command (and, in some cases, even finer-grained controls) from within that other PL. That of course isn't a benefit in itself. If an organization needs some sort of sophisticated processing attached to a hook, e.g. some verification on commits, let them call an external program, a shell script, a tcl script, whatever. It can't do so portably. To do that, it would have to introduce a compat layer handling the platform differences of windows/unix/... Then again, it could use an existing compat layer. Like Tcl. Embedding an interpreter into Fossil itself, to run code called by the hook, seems like entirely the wrong approach. Again, the right way to integrate those two would be to make fossil a library. If done properly, bindings for other languages can emerge naturally. And of course there needs to be a compile-time option to strip all that support in case you want a real slim fossil binary. As Stephan said in another context, it's a herculian task. But one worth undertaking IMO. Regards, -Martin ___ 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 interest in integrating jimtcl w/fossil?
On Tue, September 20, 2011 6:38 pm, Steve Havelka wrote: Excuse my bluntness: that sounds like a terrible idea. Tcl is huge compared to fossil, and certainly not installed everywhere by default. And for what benefit? To have a full-blown programming language built in? That of course isn't a benefit in itself. If an organization needs some sort of sophisticated processing attached to a hook, e.g. some verification on commits, let them call an external program, a shell script, a tcl script, whatever. Embedding an interpreter into Fossil itself, to run code called by the hook, seems like entirely the wrong approach. I agree entirely. I think Fossil is in danger of becoming some sort of Swiss Army Knife, rather than a finely honed specialised tool. The only suggestion for major change that I have seen lately that I approve of is to be able to build Fossil as a library. Regards -- ms fnd in a lbry ___ 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 interest in integrating jimtcl w/fossil?
On 09/20/11 14:53, Eric wrote: I agree entirely. I think Fossil is in danger of becoming some sort of Swiss Army Knife, rather than a finely honed specialised tool. Actually fossil IS a swiss army knife. It combines a DVCS with tickets, wiki, http UI, user-mgmt embedded doc. Its specialization is its swiss army knife function, while remaining self-sufficient. The only suggestion for major change that I have seen lately that I approve of is to be able to build Fossil as a library. If you have fossil as a library, having something to remote-control the fossil library is the next logical step. Of course if you're an IDE person, you'll appreciate easier integration with, say, the behemothian eclipse, the leviathan netbeans, the Zizian IDEA or the all-encompassing emacs. In case you aren't and want a finer grained control and scriptability than is doable right now with shell scripts and parsing the output of fossil, then I think you'll appreciate integration with a (script) language. One point of the whole integration is, as has been stated already, for it to be optional (not the fossil as library part, but the remote control part). No harm done for you if you don't want to use it; just as there's no harm done if you don't want to use the wiki, tickets, the user management, the web UI, i.e., fossil as a swiss army knife. Regards, -Martin ___ 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 interest in integrating jimtcl w/fossil?
I agree that if your are going to integrate some language with fossil then Jim Tcl is nearly an ideal fit. It is small, modular, self contained, can replace TH1 easily and should be licence compatible. But... let's see a design proposal, or at least a prototype implementation. I think that understanding some core use cases and designing a good API is important. Regarding someone's concern over Tcl vs Jim Tcl differences - yes there are differences, but in practice they are unlikely to be a problem. Take a look at the online doc http://repo.or.cz/w/jimtcl.git/blob_plain/HEAD:/Tcl_shipped.html Cheers, Steve On 21/09/2011, at 6:05 AM, Martin S. Weber martin.we...@nist.gov wrote: Why don't we all save the napalm for when we've come up with a real design proposal for a) making fossil a library, and b) integrating $LANG with a) The whole argument is somewhat bogus until then, although the voice of concerns is valuable input for creating said design proposal. I don't see why we should delve into details of a potential integration without having thought out these details. I plead guilty of getting carried away with reacting to some of these concerns; after all all I wanted to do was answer Stephan's question positively. Regards, -Martin ___ 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] First JSON timeline demo
Hiya!
i've started implementing the /json/timeline handling. i'm going to break it
down into /ci, /wiki, and /ticket (any others?) because the structures are
very different for each. This initial code doesn't do all that much but set
up some of the infrastructure, but it didn't take long to throw together, so
i'm hopeful that we'll have something usable very soon.
Here's a quick example... this is first-draft/alpha quality, still subject
to many changes - and please ignore the fact that i'm setting CLI options
options via environment variables (that's a workaround for the time being):
(And ignore the SQL code - that of course won't be in any production code!)
stephan@tiny:~/cvs/fossil/fossil-json$ n=1 indent=2 ./fossil json timeline
ci
{
fossil:6ce6b5e63ff041a757db81bd587dec5032bc0769,
timestamp:1316558823,
payload:{
timelineSql:INSERT OR IGNORE INTO timeline SELECT\n blob.rid AS
blobRid,\n uuid AS uuid,\n datetime(event.mtime,'localtime') AS
timestamp,\n coalesce(ecomment, comment) AS comment,\n coalesce(euser,
user) AS user,\n blob.rid IN leaf AS leaf,\n bgcolor AS bgColor,\n
event.type AS eventType,\n (SELECT group_concat(substr(tagname,5), ', ')
FROM tag, tagxref\nWHERE tagname GLOB 'sym-*' AND
tag.tagid=tagxref.tagid\n AND tagxref.rid=blob.rid AND
tagxref.tagtype0) AS tags,\n tagid AS tagid,\n brief AS brief,\n
event.mtime AS mtime\n FROM event JOIN blob\nWHERE
blob.rid=event.objid\nAND event.type IN('ci') ORDER BY mtime DESC LIMIT 1 ,
timeline:[{
rid:13752,
uuid:eff3f7d92960b0a0af2599bf19bd238afcd4d3b8,
timestamp:2011-09-20 22:42:58,
comment:Started adding /json/timeline support, but this is gonna
be a doozie. Breaking it down into separate calls for ci/wiki/ticket, e.g.
/json/timeline/ci because the structures will be different for each.,
user:stephan,
isLeaf:1,
bgColor:null,
eventType:ci,
tagList:json,
tagId:null,
shortText:null
}]
}
}
(and i hope your mail client wraps that!)
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] First JSON timeline demo
Is it possible to dump all structures to the same call, then require
clients to intelligently determine which is which? Seems like it should
be fairly trivial on the client side. Mind you, I'm not opposed to
separate calls either, I just wonder why the different structures
automatically rule out someone taking up the challenge of
differentiating them in whatever clients they've dreamed up?
On 09/20/2011 05:51 PM, Stephan Beal wrote:
Hiya!
i've started implementing the /json/timeline handling. i'm going to
break it down into /ci, /wiki, and /ticket (any others?) because the
structures are very different for each. This initial code doesn't do
all that much but set up some of the infrastructure, but it didn't
take long to throw together, so i'm hopeful that we'll have something
usable very soon.
Here's a quick example... this is first-draft/alpha quality, still
subject to many changes - and please ignore the fact that i'm setting
CLI options options via environment variables (that's a workaround for
the time being):
(And ignore the SQL code - that of course won't be in any production
code!)
stephan@tiny:~/cvs/fossil/fossil-json$ n=1 indent=2 ./fossil json
timeline ci
{
fossil:6ce6b5e63ff041a757db81bd587dec5032bc0769,
timestamp:1316558823,
payload:{
timelineSql:INSERT OR IGNORE INTO timeline SELECT\n blob.rid
AS blobRid,\n uuid AS uuid,\n datetime(event.mtime,'localtime') AS
timestamp,\n coalesce(ecomment, comment) AS comment,\n
coalesce(euser, user) AS user,\n blob.rid IN leaf AS leaf,\n
bgcolor AS bgColor,\n event.type AS eventType,\n (SELECT
group_concat(substr(tagname,5), ', ') FROM tag, tagxref\nWHERE
tagname GLOB 'sym-*' AND tag.tagid=tagxref.tagid\n AND
tagxref.rid=blob.rid AND tagxref.tagtype0) AS tags,\n tagid AS
tagid,\n brief AS brief,\n event.mtime AS mtime\n FROM event JOIN
blob\nWHERE blob.rid=event.objid\nAND event.type IN('ci') ORDER BY
mtime DESC LIMIT 1 ,
timeline:[{
rid:13752,
uuid:eff3f7d92960b0a0af2599bf19bd238afcd4d3b8,
timestamp:2011-09-20 22:42:58,
comment:Started adding /json/timeline support, but this is
gonna be a doozie. Breaking it down into separate calls for
ci/wiki/ticket, e.g. /json/timeline/ci because the structures will be
different for each.,
user:stephan,
isLeaf:1,
bgColor:null,
eventType:ci,
tagList:json,
tagId:null,
shortText:null
}]
}
}
(and i hope your mail client wraps that!)
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] any interest in integrating jimtcl w/fossil?
On 21/09/2011, at 8:06 AM, Martin S. Weber martin.we...@nist.gov wrote: On 09/20/11 17:57, Steve Bennett wrote: I agree that if your are going to integrate some language with fossil then Jim Tcl is nearly an ideal fit. It is small, modular, self contained, can replace TH1 easily and should be licence compatible. But... let's see a design proposal, or at least a prototype implementation. I think that understanding some core use cases and designing a good API is important. Regarding someone's concern over Tcl vs Jim Tcl differences - yes there are differences, but in practice they are unlikely to be a problem. Take a look at the online doc http://repo.or.cz/w/jimtcl.git/blob_plain/HEAD:/Tcl_shipped.html I did. That's not enough to make an informed decision though as to: - which tcl code will run unaltered on jim? - -- with the tclcompat package loaded? both of which are critical questions IMO. E.g.: 5. Builtin dictionary type (dict) with some limitations compared to Tcl 8.6 Yes thank you, but WHICH limitations? Then you follow the link, and see a couple of subcommands, and most importantly, a couple of them missing when comparing to Tcl 8.6. That's not some limitations, that's some commands are not implemented/supported at all. There's no dict with; there's no dict for; no dict remove; no dict replace; no ... the list goes on. What about tcl code that uses these subcommands? will the tclcompat package bring in the missing dict subcommands? Will the tcl code have to be rewritten? In practice, with not supporting dict with, about 90% of the tcl code I've written in the past five years would NOT run unaltered on jim, thus being very likely to be a problem in practice. The simple answer is, No, you will not be able run (any) Tcl code unaltered. If that is what you want, you have no choice but to use full Tcl. It may not be unreasonable to allow an arbitrary language binding to fossil. Python anyone? But I think the proposal here is to have a full scripting language built in to fossil. This is a different proposition. Lua is another reasonable alternative here, and that won't run *any* of your existing Tcl scripts. As I've written earlier, I'd really like to see a list of all the commands and subcommands of tcl on one side, and all of the commands and subcommands of jim on the other side, and an indicator whether a) jim does not support given command and/or subcommand, b) jim supports it but with differences, c) jim supports it and it behaves idempotent to the tcl command/subcommand, d) a) or b) is the case but by loading package x it becomes c). Without this information IMO it is impossible to do an informed choice on whether to use jim or tcl. I understand, but this is not trivial since there are some subtle differences which go beyond commands existing or not. But in general, if it isn't in the manual, it doesn't exist. dict for, dict replace, etc. If I wanted to come up with a design proposal (and I do want), the only choice I have is basically scavenge all unit tests of tcl and run them on jim, and say c) for each failure. And then compare the parts which aren't covered by that. I.e., a LOT of manual work. It sucks. Sigh. I don't think the design proposal needs to care too much about the language features. It is the interface to fossil which is important. Cheers, Steve Regards, -Martin ___ 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
