A company asked me to program a GIT wrapper for them.
The people there have absolute no versioning systems experience, but it will be incorporated in their daily routine eventually (through my program).
I'm planning on using VC++ to create a tiny windows applet that will help ppl in this process. Any thoughts on that?
What about a Deamon process checking if people want to commit/push their files?
For almost (but not all!) use cases, libgit2 is the easiest way to interact with Git repositories via code.
Git already has two layers: The plumbing (which you may be interested in) on top of which is built the primary porcelain which provides the user interface. If you want to implement something like git-commit but with slightly different semantics all of the underlying programs like git-write-tree and git-rev-parse are there for you to build on.
See also What does the term "porcelain" mean in Git?
There's already TortoiseGit, among other "friendly" interfaces. Don't re-invent the wheel, start by researching what's already available.
In order to easier the search for documentation hereafter the link to the official. It's about the plumbing and porcelain:
https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
Related
Well I'm working since some months ago with Alfresco 4.2b, mainly with Share. I'm preforming some customization works and my colleagues and myself are always wondering about the subject of this post.
We know extension modules is a relatively new feature which is available since the first release of Alfresco 4 but we don't know which way should the developments performed take in terms of the extension mechanism used. We are putting all our efforts on using the extension module mechanism rather than using the web-extension directory. We are doing that because we understand that probably the it is more versatile, maintainable and scalable and who knows, perhaps the use of the web-extension directory could be deprecated in further releases. We are also aware that at the moment you cannot do "everything" with extension modules.
So according to that, I would like to know about pros and cons of both mechanisms based on other developers experience, as well as whether we are doing right with our extension philosophy. At the same time, I would like to find a reasonable answer to the next questions:
Are we doing right prioritizing and "sacrifice" our time trying to perform customization with extension modules? Is it worth?
Could be deprecated the web-extension directory as a customization mechanism in further releases?
Is the extension modules feature going to be improved?
(Roughly) known limitations of extension modules? Mainly the question could be, when should be used one extension mechanism or the other?
I'm looking forward to hear your opinions. It would be strongly appreciated opinions based on your real experience and as honest as possible.
Thanks very much in advance.
Actually both are not exclusive.
I'm using myself for instance the extension mechanism to define new components which webscripts are defined in the web-extension folder.
In fact the extension module itself can be located in the web-extension folder under alfresco/web-extension/site-data/extensions/...
For me using the extension modules is a way to logically package (because of the deployment process of modules) your customization. That's the main advantage because it can be configured through evaluators if you want the customization to be available only in particular conditions.
The two main problems with the web-extension route is that you will end up duplicating core code in your customisation, and that if multiple extensions try to extend the same component, one must win.
Extensibility modules may be a little bit more work but you will more than get that back in terms of a much reduced maintenance burden, and in troubleshooting problems when multiple add-ons clash with each other.
From 4.2 onwards you should not need to override web script components - in Share at least. You should always use an extensibility module.
I am not sure if the title of this question gets to the point. I have written a large software system in C C++ for Windows, and want to give the users of this system the option to add compiled code to it. The user should be able to do basic stuff, and exchange data with my program.
Currently the implemented way is via DLLs. But for this, a grown up compiler is needed, and it is not as easy as I wished. Is there a tiny C compiler that can create Windows DLLs?
Another idea is the Java native interface. But this requires a complete Java system to run in the background, and it is not easy to run code in it.
Do you have any other ideas?
Any interpreted language? (TCL and Lua were designed as extension languages, but you can nearly as easily interface with any other).
How about python integration?
You could create an python interface that interfaces with your application. Python is rather easy to learn and should integrate easily with c/c++. The python documentation has an own chapter on that.
You could also use a tool like swig to generate the interface.
The advantage of this is that they wouldn't have to compile anything. They could just supply python files that could be loaded into your application and run within the software. This is a well known use for python, and something its simple syntax promotes.
As the other says you will be best of by providing an embedded language.
I would chip in for javascript and use the google v8 engine
By using javascript you get a language nearly everbody can use and program in.
There is other javascript engines you can embed like SpiderMonkey.
See this answer for what to choose.
An interpreted language is not good enough. I need speed. The software itself is an interpreted language. So I added support for the tiny C compiler. It is only C, and I do check mingw, which probably would not be as tiny as this. Thanks for all your hints.
Added after several months:
I have now two tools, actually: TinyC and Python. The speed difference between those is noticable (factor 5-10), but that usually does not matter too much. Python is much easier for the user, though I managed to integrate both into the Euler GUI quite nicely.
One of the ways is to add scripting. You application can host scripting environment and expose its services there. Users would be able to execute JScript/VBScript scripts and interact with your application. The advantage is that with reasonable effort you can get the power of well known and well documented scripting languages into your application (I suppose there is even debugger for scripting there). You will be required to shape your app services as COM interfaces and scripts will be able to access them automatically using method names you assigned on C++ side.
C++, Win32 and Scripting: Quick way to add Scripting support to your applications
MSDN Entry Point - IActiveScript interface
what would be (rough estimation, average, of course) the initial learning and setup curve and subsequent overhead for using Maven for C++/Eclipse/Linux project of small to medium size?
We are 4 developers at the beginning of the way. We currently have ~20 native eclipse C++ (CDT) "projects", which we compile interactively. We would like to have an automated checkout & build script.
It seems a bit overkill at this stage, but perhaps we should adopt it sooner then later, provided that it does not incur an overhead. We don't have bandwidth for extensive configuration management right now. Thanks a lot!
EDITED / DETAILED:
I realize I haven't described my needs well enough. Having read the references provided below, I see that CI tool seems an overkill for us at the moment. What I'd like to have is a build tool that is well integrated with eclipse on one hand, and allows offline, non-interactive builds on the other. I enjoy the simplicity of working with eclipse projects: you just add files, add references to internal components and 3rd part libs as they add up, and that's it. You don't need to manually maintain makefiles or the like. The trouble with it, as with MSVS a few years ago when I worked with it, is that it does not give you an option of non-interactive builds. So, does such tool exist?
First, while Maven has some support to build C++ projects with the maven-native-plugin or, if you already are using Make, with the maven-make-plugin from the c-builds suite, this is not a common use case and there aren't widely used. So while it should be possible, you won't get support and find resources easily (just Google a bit or browse the maven users list to get an idea).
Second, if you add to this that you'll have to learn Maven in the same time, then it seems reasonable to say that you are not taking the easiest path.
So, instead, I'd stick with more traditional tools and/or Ant. For the continuous integration itself, I've seen several references mentioning the use of CruseControl to build a C++ project. Refer to What continuous integration tool is best for a C++ project? or UsingCruiseControlWithCplusPlus for example. But I guess the principles are transposable to another CI engine (like Hudson that I find much more easy to use than CruiseControl).
I've found only two FastCGI libraries for C++. There's the "official" one, and fastcgi++. How is either one better than the other? Do any others exist?
What you probably want is hidden in the contrib directory of Cgicc package.
fcgi-test.cpp is an example of how to use cgicc with FastCGI.
Path to the installed fcgi-test.cpp should be
/usr/share/doc/libcgicc-doc/examples/contrib/fcgi-test.cpp
As fastcgi++ is still listed as "Development Status: 4- Beta" so I would suggest going for the official one. It has been around for ages and has bindings for a whole host of languages. Licences between the 2 don't seem to make much difference. Put some measurements in your code and if performance is an issue then spend some time playing around with alternatives.
The official library is rather low-level, and as such, is only useful as an intermediate for a high-level CGI library such as cgicc.
Fastcgi++, on the other hand, allows for use of C++ idioms when dealing with FastCGI. Incompleteness in v1 motivated me to fork it into mosh-fcgi.
Pros:
My fork complies with every point of the standard (especially ROLE_FILTER)
everything's extensively templated, so it's easier to use arbitrary T for std::basic_strings.
Cons:
My modifications are in alpha mode.
In any case, download the latest zip from https://github.com/moshbear/mosh-fcgi.
See also the Cgicc library:
http://www.gnu.org/software/cgicc/
The library appears to be mature (currently at version 3.x). According to the documentation it can be used with FastCGI by passing a custom reader (reader_function_t) to the constructor of the Cgicc class.
There is a pretty library for creating FastCGI daemons: https://github.com/golubtsov/Fastcgi-Daemon
The C-version of FastCGI does very little, and developing in C++ isn't such a big problem as it hardly interferes with your own code. It's most likely just a loop and an environment variable.
So my advice would be just to stick with the official version.
Just be aware of one thing: it works by redefining printf! So if you use cout it won't work.
I'm looking to add full text indexing to a Linux desktop application written in C++. I am thinking that the easiest way to do this would be to call an existing library or utility. This article reviews various open source utilities available for the Gnome and KDE desktops; metatracker, recoll and stigi are all written in C++ so they each seem reasonable. But I cannot find any notable documentation on how to use them as libraries or through an API. I could, instead, use something like Clucene or Xapian, which are generic full text indexing libraries. They seem more straightforward but if I used them, I'd have to implement my own indexing daemon, an unappealing prospect.
Also, Xesam seems to be the latest thing, does anyone have any evidence that it works?
So, does anyone have experience using any of the applications or libraries? How did you use it and what documentation was useful?
I used CLucene, which you mentioned (and also Lucene.NET), and found it to be pretty good.
There's also Strigi which AFAIK works with Xesam and is the default used in KDE.
After further looking around, I found and worked with Recol. It believe that it has the best C++ interface to a full text search engine, in this case Xapian.
It is important to realize that clucene and Xapian are both highly complex libraries designed primarily for multi-user server applications. Cutting them down to a level appropriate for a client-system is not easy. If I remember correctly, Strigi has a complex, pure C interface which isn't adapted.
Clucene also doesn't seem to be that actively maintained currently and Xapian seems to be maintained. But the thing is the existence of recol, which allows you to index particular files without the massive, massive setup that raw Xapian or clucene requires - creating your own "stemming" set is not normally desirable, etc.