YOUR CONTRIBUTION

Cooperative development with SVN

Unitex is developed using a SVN server that facilitates cooperative development. If you are interested in contributing to Unitex, you should read these explanations.

Linguistic contribution

You can contribute to the development of the RELEX resources by sending your DELAF dictionaries, grammars or any valuable document to unitex@univ-mlv.fr. Dictionaries should be Unicode text files. Grammars should be Unitex GRF files.

Computing contribution

As Unitex is free software, you can modify the source code to develop your own functionality. If you develop a new function that may be useful for the Unitex users, please don't hesitate to contact us at the following address unitex@univ-mlv.fr, in case it might be suitable for integration into our standard version of Unitex. In that case, we will give you a write access to the SVN server that hosts the sources.

Golden rules

Here is a list of rules that Unitex contributors need to respect in order to have their contributions integrated in the Unitex official version distributed on this web site. Of course, the LGPL license allows anyone to modify and distribute Unitex, but if you want to contribute to the official version maintained at the IGM, it is asked that you respect these rules. You will find here general programming guidelines and instructions regarding Unitex code and resources. Thank you for respecting these rules, so that we can make the system grow preventing it from being a mess.

Programming rules

1. Before you commit, you must do an update in order to check if your modifications generate conflicts.


2. Before committing your changes, make sure that you accept the LGPL license.


3. Always explain your modifications in the commit comment.


4. Unitex is and must stay cross-platform. Make sure that your code can compile and run correctly on Windows and Linux/MacOS by respecting the following rules:

   C++

   1. If you work under Windows, please use the Dev-C++ compiler. We chose this software because it is GPL-licensed, and so, accessible to anyone.
   
   
   2. Do not forget to send the Makefile if it needs to be modified. Make sure that the Makefile remains functional on both Windows and Linux/MacOs.
   
   
   3. Use only unicode functions that are in the Unitex Unicode.cpp library. THIS IS VERY IMPORTANT, since standard functions like fwprintf do not have the same behavior on little-endian and big-endian systems. If you miss a function, please code it from the primitive functions of this library.
   
   
   4. Do not use extended strings like L"This a unicode string".
   
   
   5. Do not use \n and \r. Always use the Windows line break sequence, that is to say 0D 0A in hexadecimal (in little-endian: 0D 00 0A 00).
   
   
   6. If you must use path delimiters, use the macro #ifdef _NOT_UNDER_WINDOWS in order to use \ or /, depending on the system.
   
   
   7. If you need to use a library that depends on the system, use the macro #ifdef _NOT_UNDER_WINDOWS.
   
   
   Java
   1. Always use File.separatorChar or File.separator as path delimiter in file names.
   
   
   2. If you add a program named Foo to Unitex that will be launched from the graphical interface, create and use a class named FooCommand that inherits from fr.umlv.unitex.process.CommandBuilder. Add FooCommand.class in the commands array in the the class fr.umlv.unitex.process.CommandMenuFactory.
   
   
   3. Only use unicode functions that are in the fr.umlv.unitex.io.UnicodeIO class. This is very important, since IO functions do not have the same behavior on little-endian and big-endian systems. If you miss a function, please code it from the primitive functions of this library.
   
   
5. After any modification on C++ files, rebuild all programs with make clean and make, in order to verify that all programs still compile correctly.


6. Every .cpp, .h and .java file must begin with the LGPL disclaimer.


7. Every C++ program launched with no parameter must show the COPYRIGHT string (located in Copyright.cpp), followed by its synopsis. It must return the value 0.


8. Every C++ program must return 0 when terminated correctly or invoked with no parameter, and else any non-zero value.


9. Any substantial modification (such as introducing new constants, variables or functions) must contain a comment that explains it and tells who the author is. By default, the code is from Sébastien Paumier.


10. Do not hardcode information in programs. Use configuration files instead.


11. Do not put non trivial numeric constants in programs. Use constant definitions instead, with #define directives in C++ and static final variables in Java.


12. Keep in mind that Unitex is and must stay multi-language. Do not make language-specific modifications when they can be generalized for other languages.


13. Comment your code. Java files must contain javadoc comments.


14. NEVER USE printf OR scanf: use u_printf and u_scanf instead.


15. Error messages must be written with the functions of the Error.cpp library in C++ and System.err.println(...) in Java. Other messages must be written in the standard output with u_printf(...) in C++ and System.out.println(...) in Java.


16. If you need to give unicode arguments to a program (for instance Reg2Grf), enclose the arguments into a unicode text file and give the file name as an argument to the program instead.


17. If you modify a program, preserve compatibility as far as possible. Keep in mind that some users call Unitex programs in scripts and do not want to modify them without a very good reason.


18. If you create a program or modify the behavior of an existing one, send a detailed description in order to update Unitex manual. Do the same if you introduce a new configuration or data file.


19. Only use 7-bits ASCII characters in file names.


20. Beware of letter case in file names, since inconsistencies will lead to errors under Linux-like systems.


21. String literals in C++ programs will be supposed to contain only 7-bits ASCII characters. If you use accented letters, some compilers may interpret them as part of UTF-8 character definitions.


22. The very first instruction of the main function of a C++ program must be a call to the setBufferMode() function, located in the IOBuffer.cpp library. If this is not respected, the Java frame that displays the standard output of programs may display it asynchronously.


23. All C++ programs must conform to the following naming rules. Let us take a program named Foo. There must be the 3 following files:
    • Main_Foo.cpp: contains the call to setBufferMode(), followed by a call to the main_Foo() function, and NOTHING MORE.

    • Foo.f: declares the main_Foo() function.

    • Foo.cpp: defines the main_Foo() function.

The underlying idea is to exclude all the Main_Foo.cpp files when compiling Unitex as a library.

24. All C++ programs must parse their parameters with the UnitexGetOpt.cpp library included in Unitex. DO NOT USE #include <getopt.h>, since this library is not ported under Windows. Use #include "UnitexGetOpt.h" instead.


25. Every call to malloc, calloc, realloc and strdup must be followed by a NULL test. If the test fails, the fatal_alloc_error function must be used to report the problem.

Linguistic resources rules

1. If you send linguistic resources, make sure that you accept the LGPLLR license.


2. If you send a dictionary, send the .dic version and a .txt file that describes its content (description of codes used in it, number of entries, authors, ...).


3. If you send graphs, send the .grf versions. Put information about the authors in a comment box.


4. Only use 7-bits ASCII characters in file names.


5. Beware of letter case in file names, since inconsistencies will lead to errors under Linux-like systems.


6. If you want to add a new language to Unitex, you need to send the language directory, observing the following rules:


• Send a complete directory structure, even if some directories are empty (the best way to do it is to copy an existing language directory and to delete all the files it contains).


• The name of the language directory must be the capitalized English name of the language. If the language is a variant of an existing language, put a description of the variant between parenthesis. For instance: Portuguese (Brazil).


• You must provide an alphabet file.


• You must provide a sample unicode text file. Beware of the copyright of this text. To avoid problems, we recommend to provide a classical novel that is in the public domain.


• You must provide a sample dictionary that should contain at least the words of the sample text.


• You should provide a sentence delimitation graph, even if it is trivial.


• Any extra resource is welcome.

Configuring Eclipse

Unitex is developped with free tools. In this section, we explain how to install everything you need to reproduce the environment used by Unitex's main developper.

Step 0: installing g++

Step 1: installing Eclipse

Step 2: chosing your workspace

Step 3: installing Subclipse

Now, you need to install the SVN client Subclipse. Go in "Help > Install New Software...". Click on the "Add..." button to see the "Add site" frame. Fill the "Name" frame with Subclipse and the "Location" frame with http://subclipse.tigris.org/update_1.6.x, and click on the "OK" button.



Then, in the "Work with" frame, select the Subclipse line and check all three boxes:

Click on "Next", and say that you accept licenses when asked. After a while, the plugin will be installed, and you will be asked for restarting Eclipse. Accept. Then, go in "Windows > Preferences". In the "Team > SVN" tab, select SVNKit in the "SVN interface" combo box. Then, click on the "Apply" button.

Step 4: importing Unitex C/C++ sources

Step 5: importing Unitex Java sources

Your suggestions

Please don't hesitate to mail us any comment, suggestion, bug report or question. A free software like Unitex grows with the participation of the users, so any contribution is welcome.