Re: [fossil-users] any interest in integrating jimtcl w/fossil?
On 24/09/2011, at 8:02 AM, Ron Wilson wrote: On Tue, Sep 20, 2011 at 6:06 PM, Martin S. Weber martin.we...@nist.gov wrote: 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 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. Wouldn't it be more important to compare with Fossil's TH1? Yes. In which case it is easy since TH1 implements so little. -- µWeb: Embedded Web Framework - http://uweb.workware.net.au/ WorkWare Systems Pty Ltd W: www.workware.net.au P: +61 434 921 300 E: ste...@workware.net.au F: +61 7 3391 6002 ___ 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:06 PM, Martin S. Weber martin.we...@nist.gov wrote: 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 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. Wouldn't it be more important to compare with Fossil's TH1? ___ 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 Wed, Sep 21, 2011 at 3:53 PM, Martin S. Weber martin.we...@nist.govwrote: Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll have time for that (at least rounding up an API suggestion) next week. i recently went through a very similar migration/refactoring (on a much smaller scale, but the exact same problems), and have some ideas about this. i would be VERY interested in assisting if you (or someone else) would take the reigns. -- - 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 15:53, Martin S. Weber wrote: On 09/20/11 19:20, Steve Bennett wrote: It is the interface to fossil which is important. Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll have time for that (at least rounding up an API suggestion) next week. Please keep in mind that such an API should not only help implementing language bindings for fossil but should also support tool makers. I'm working on a C# library to use fossil commands and a Windows GUI for fossil (with the goal of Visual Studio integration) and I really miss a library like the one that exists for SQLite. Implementing tools around fossil would be so much easier if a library would be available. An other thing: Seeing how much fossil developer related traffic currently is on the mailing list, maybe it is time to setup a new fossil-deve...@lists.fossil-scm.org ? I think it would make sense to split because users looking for answers regarding their day to day usage problems and not being directly interested in development of fossil should not be bothered with development topics. Maybe someone of the active developers asks Richard to set up a new list? Regards, Ingo ___ 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/21/11 14:12, Ingo Koch wrote: On 09/20/11 15:53, Martin S. Weber wrote: On 09/20/11 19:20, Steve Bennett wrote: It is the interface to fossil which is important. Yep. That's where step #1 comes in - librarization of fossil. Luckily I'll have time for that (at least rounding up an API suggestion) next week. Please keep in mind that such an API should not only help implementing language bindings for fossil but should also support tool makers. Absolutely. Rest assured, I do: On 09/20/11 15:00, Martin S. Weber wrote: 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. Sorry I forgot to mention the humongous VisualXXX ;) 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 Wed, Sep 21, 2011 at 8:12 PM, Ingo Koch ingo.k...@gmx.de wrote: Please keep in mind that such an API should not only help implementing language bindings for fossil but should also support tool makers. We're all agreed on the many potential benefits, i think. The only hurdle is the size of the task. It would be a major overhaul. That's not to discount the idea - i'm all for it. i did in fact start to do this way back in 2008, but quickly found that fossil's use of exit() as an error handling strategy (which makes sense in a standalone app) was just the first of several big worms i'd have to deal with. An other thing: Seeing how much fossil developer related traffic currently is on the mailing list, maybe it is time to setup a new fossil-deve...@lists.fossil-scm.org? Richard suggested that last week, but i don't think he's gotten around to it yet. For the sake of the non-dev users, who are certainly sick of my chatter by now, i hope he (or someone else with admin access? Bueler?) finds some time for it. -- - 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
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
