Development

Nightly builds

Nightly builds are at http://bibledit.sourceforge.net/hot-off-press. These are the latest versions of Bibledit, which are released frequently, usually every night. These builds have not been thoroughly tested, but are supported, and give you a great way to follow the newest and latest developments in Bibledit.

Help needed

Help in developing Bibledit is welcome.

* Do you like writing good documentation? Your help is welcome to maintain the helpfiles of Bibledit.

* You know how useful .rpm and .deb packages are? Making packages could be the thing you would like to help with.

* Are you good at testing? Your feedback is welcome and suggestions for new features too.

Bugs and feature requests

Sourceforge provides resources for developing Bibledit, and the Project Page is the central point from where all these resources can be accessed.

To report a problem go to the Project Page, and click on "Bugs". A list of open bugs will show, and you can see whether your bug has been reported already. If not, click "Submit New", fill in the screen with detailed information on when the bug occurs, and the steps to be taken to reproduce it, and any other information that may be useful, and click the "Submit" button. You need to open an account with sourceforge to be able to do this, and then you'll be emailed whenever this bug is attended to.

Asking for a new feature works the same, but this is done by clicking on "Feature Requests".

More information can be found in the Features and Use of the SourceForge Software Development Tracking System.

When submitting bug reports it is sometimes useful to include your configuration and data. This allows the programmer or tester to reproduce your bug, and so fix it. In a terminal type

tar -czf bibledit.tar.gz .bibledit

to create a file called bibledit.tar.gz. This file can be attached to the bug report.

Testing

The graphical user interface, including key functions of Bibledit, are automatically and continuously tested by several shell scripts and X11::Test.

For the future Bibledit should get scripting possibilities to that testing can concentrate on data integrity and functionality rather than on the user interface.

How it started

It started with an entry in the programmer's diary:

* Friday 30 May 2003. I made the decision to move from Windows to Linux. God will help here, and the future will show why this decision had to be taken. A lot of programming needs to be done to move the Bible translation programs to Linux.

I remember that at that time I had lost peace with God for a good while, was in great unrest of mind, and examined myself thoroughly what it was, and then came to the above decision. It seemed to me a bit an unusual cause for this unrest, but nevertheless I could not find another one. After the decision was made and the actual move, I regained my peace.

In 2004 some programming efforts were made to synchronize data between Paratext on Windows and Linux storage, and as I forsaw a greater future for this program, I called it Bibledit.

After that I had a health breakdown and lost my energy, and was not able to contribute to Bibledit and had to lay down to rest during the breaks of our regular translation work. Then we as a family changed our lifestyle, and God restored my energy to the level I had in the days of my youth.

From then on programming in Bibledit went in high gear, others started to contribute, and the project moved forward to where it is now.

Using the debugger

When working with support to troubleshoot a program, a core file may be requested.

A core file is a file created by the operating system when a program terminates unexpectedly, encounters a bug, or violates the operating system's protection mechanisms.

By default core files are not created on some Linux systems. Whether or not the operating system creates core files is controlled by the ulimit command. To see the current ulimit setting for core files, do the following:

ulimit -c
0

The ulimit command sets limits on the resource available to the bash shell. The -c parameter controls the size of core files. The value 0 indicates that core files are not created. To enable core file creation, increase the size limit of core files to a number greater than zero. For example:

ulimit -c 50000

allows core files and limits the file size to 50000 bytes.

If you need to enable core file creation temporarily to create a core file for a problem application, increase the ulimit at the command line and then run the application.

When bibledit segfaults and leaves a core dump file, you can use gdb to look at the program state when it crashed. Use the core command to load a core file.The argument to the core command is the filename of the core dump file, which is usually "core.<pid>", making the full command core core.<pid>.

prompt > bibledit
Segmentation fault (core dumped)
prompt > gdb bibledit
...
(gdb) core core.<pid>
...

If bibledit crashes repeatedly, an easier way is to start bibledit through the debugger, and then use the backtrace command to see what happened and when.

Open bibledit in the debugger:

gdb bibledit

Run it:

(gdb) run

If there is a problem, bibledit will freeze. Switch to the debugger, which has stopped. View the stack:

(gdb) backtrace

Pls. mail the developer and inform him about what you see and when it happened.

Notes

On Cygwin, gdb might get stopped and return you to the terminal. Enter "fg" to get the program back.