[fossil-users] Linking to fossil.exe [Re: GUI client for Windows?]
Hi Stephan, All I've just realized that despite fossil is an executable it does not prevent if from exporting functions for other programs to use (at least on Windows, am not sure if this is possible on *nix). I've just made a simple test executable Prog1.exe that links to another executable Prog2.exe. You can run Prog2.exe normally (it has it's own main function), but also you can link to it and use the functions it exports. My Prog1.exe uses a test function from Prog2.exe. All works as a breeze! A quick look on wikipedia and PE format (http://en.wikipedia.org/wiki/Portable_Executable) shows that PE is somewhat related to a unix COFF format. Perhaps the same trick is possible on *nix platforms. I think that it would solve a lot of pain in creating JSON API. Best regards, Jacek 2011/10/6 Stephan Beal : > On Thu, Oct 6, 2011 at 12:02 PM, Gilles wrote: >> >> Thanks for the info. Out of curiosity, what do you mean by "monolithic >> design", and why is it a problem to write a GUI? > > Fossil is a standalone application, not a C library of functionality. That > means that in order to write a UI the only possibility you have is to parse > the command-line output. Since fossil makes no guarantees about output > format, it's basically impossible (or, long-term, futile) to try to create a > UI in this way. This worked (barely) with CVS because CVS had well-defined > output formats (where as fossil is more "free form" (which i happen to > prefer, so that isn't a complaint)). > The JSON API effectively adds a library interface (of a sort) to fossil, > which allows other applications to call specific functions of fossil and get > well-defined responses which are easily parsed (JSON format) and understood. > For example, we can write a shell-like interface which communicates with a > fossil instance over JSON, hiding the JSON bits from the user in the form of > command-shell-style input and output. > More infos about the JSON API (still incomplete, but can already do a good > deal) can be found here: > https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?hl=en_US > -- > - 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] Linking to fossil.exe [Re: GUI client for Windows?]
On Oct 6, 2011, at 16:59 , Jacek Cała wrote: > I've just realized that despite fossil is an executable it does not > prevent if from exporting functions for other programs to use (at > least on Windows, am not sure if this is possible on *nix). It doesn't matter how the program is linked. Fossil calls exit() when a function needs to fail, and it leaves it up to the OS to clean up allocated memory. -- Dmitry Chestnykh ___ 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] Linking to fossil.exe [Re: GUI client for Windows?]
2011/10/6 Jacek Cała > I've just made a simple test executable Prog1.exe that links to > another executable Prog2.exe. You can run Prog2.exe normally (it has > it's own main function), but also you can link to it and use the > functions it exports. My Prog1.exe uses a test function from > Prog2.exe. All works as a breeze! > LOL! i've been programming since my childhood and never thought of trying that. > A quick look on wikipedia and PE format > (http://en.wikipedia.org/wiki/Portable_Executable) shows that PE is > somewhat related to a unix COFF format. Perhaps the same trick is > possible on *nix platforms. I think that it would solve a lot of pain > in creating JSON API. > It wouldn't save much, if any, in this case. In writing the JSON API i often have to minorly refactor existing fossil functionality or change its visibility from static to non-static so that the json code can use it. More often than not i have to create separate impls for the JSON variant of a given call because the original variants generate output to stdout (which is absolutely taboo in JSON mode, and must be avoided at all costs because it would corrupt the output). If i were using fossil.exe as a library (of sorts) i couldn't do that - i would still be limited to the set of features which are not static. Whether or not a function in fossil is static is almost arbitrarily decided - if the function is only used in one file, it's typically static, else it is not static. -- - 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] Linking to fossil.exe [Re: GUI client for Windows?]
2011/10/6 Stephan Beal : > 2011/10/6 Jacek Cała >> >> A quick look on wikipedia and PE format >> (http://en.wikipedia.org/wiki/Portable_Executable) shows that PE is >> somewhat related to a unix COFF format. Perhaps the same trick is >> possible on *nix platforms. I think that it would solve a lot of pain >> in creating JSON API. > > It wouldn't save much, if any, in this case. In writing the JSON API i often > have to minorly refactor existing fossil functionality or change its > visibility from static to non-static so that the json code can use it. More > often than not i have to create separate impls for the JSON variant of a > given call because the original variants generate output to stdout (which is > absolutely taboo in JSON mode, and must be avoided at all costs because it > would corrupt the output). If i were using fossil.exe as a library (of > sorts) i couldn't do that - i would still be limited to the set of features > which are not static. Whether or not a function in fossil is static is > almost arbitrarily decided - if the function is only used in one file, it's > typically static, else it is not static. Agree, however, I thought that JSON API was the solution for linking external apps to fossil, and hence having ability to call fossil directly would make the API redundant. But, obviously, the API may be needed for some other reasons as well. Nonetheless, I think that (at least for windows builds) exporting fossil functions for others to link to is a viable and valuable option. Regards, Jacek > - 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] Linking to fossil.exe [Re: GUI client for Windows?]
Is this too much hassle to improve the exec in this matter? As said @Stephan, I think that this option is much more viable than using any intermediaries like standard output/error, protocol buffers or JSON API. What do you think? I could spent a bit of my time and look at it if this is doable and anyone is interested. Cheers, Jacek 2011/10/6 Dmitry Chestnykh : > On Oct 6, 2011, at 16:59 , Jacek Cała wrote: > >> I've just realized that despite fossil is an executable it does not >> prevent if from exporting functions for other programs to use (at >> least on Windows, am not sure if this is possible on *nix). > > It doesn't matter how the program is linked. Fossil calls exit() when a > function needs to fail, and it leaves it up to the OS to clean up allocated > memory. > > -- > Dmitry Chestnykh > > ___ > 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] Linking to fossil.exe [Re: GUI client for Windows?]
2011/10/6 Jacek Cała > Agree, however, I thought that JSON API was the solution for linking > Well, it's "a" solution, not "the" solution. But it's "the" only solution for the time being ;). > external apps to fossil, and hence having ability to call fossil > directly would make the API redundant. That is also my thinking. With this in place, a "librification" rewrite/refactor of fossil becomes "less necessary." (Though there are still certainly many good arguments for such a rewrite, but we've beaten that horse to death several times already, so this is not a call for comments on the topic ;).) i've learned through implementing the JSON API that this will actually give us a great many options i had never really considered. e.g. someone suggested reading POST data from a file/stdin in CLI mode. Adding that ability was easy to do (30 lines or so of code[1], plus some touch-ups in CLI argument-handling code in other places) and indeed gives us a new way to interact with a local fossil binary. i do not yet have it running, but i've started work on a prototype shell for fossil which uses this approach, calling either a local fossil binary or sending the commands to a remote repo. [1] = http://www.fossil-scm.org/index.html/artifact/00d07d18aa32de91151831823347836cd5015aa8?ln=1055-1080 -- - 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] Linking to fossil.exe [Re: GUI client for Windows?]
On Thu, Oct 06, 2011 at 04:18:27PM +0100, Jacek Cała wrote: > Is this too much hassle to improve the exec in this matter? As said > @Stephan, I think that this option is much more viable than using any > intermediaries like standard output/error, protocol buffers or JSON > API. What do you think? I could spent a bit of my time and look at it > if this is doable and anyone is interested. Well, it's not that easy, because it plays with fork() and exit(), in order to have simpler code (less cleanup, less heap maintenance, ...) Regards, Lluís > 2011/10/6 Dmitry Chestnykh : > > On Oct 6, 2011, at 16:59 , Jacek Cała wrote: > > > >> I've just realized that despite fossil is an executable it does not > >> prevent if from exporting functions for other programs to use (at > >> least on Windows, am not sure if this is possible on *nix). > > > > It doesn't matter how the program is linked. Fossil calls exit() when a > > function needs to fail, and it leaves it up to the OS to clean up allocated > > memory. > > > > -- > > Dmitry Chestnykh > > > > ___ > > 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
