The code is stored in a git repository. The repository is accessible from the Savannah Project Page. To view the code on the web, click on "Source Code" - and then "Browse Sources Repository" just below "Use Git". To use the repository in another way, click on "Source Code" - "Use Git". It will give some information there.
Recent code can be checked out from the repository. This code gives the latest versions of Bibledit. Every night this code is updated, hence it contains the nightly builds. This code has not been thoroughly tested, but is supported, and give you a great way to follow the newest and latest developments in Bibledit.
In order to get the most recent code, do the following in a terminal.
git clone git://git.savannah.nongnu.org/bibledit
The above command clones the code repository to your local disk. It will create a directory called "bibledit". Go into that directory, and do the normal "./configure", "make", "sudo make install" sequence, as is described for installing bibledit.
Note 1. To save bandwidth, it is recommended to leave the directory "bibledit", created above, as it is. If that directory is left there, then next time there is no need to clone the whole repository. Just pulling the changes is enough:
cd bibledit git reset --hard git pull ./configure make sudo make install
Formerly if anybody wished to run what was then called nightly builds needed to download the full build each time. The current method saves a lot of bandwidth, because it downloads the changes only, and these changes are usually small.
Note 2. For best results close Bibledit while installing the new version.
Note 3. This also works for updating/upgrading to full versions where the version number is x.x. But there is a good change that the version that you get will be a newer version, like x.x.1 or x.x.2.
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 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.
Savannah.nongnu.org provides resources for developing Bibledit. The Savannah Project Page is the central point from where all these resources can be accessed.
To report a problem go to the Savannah 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 "Bugs" - "Submit", 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 at the bottom of the screen. You need to open an account to do this, and then you'll be emailed whenever this bug is attended to.
Asking for a new feature works similar. Click on "Tasks". A list of tasks, that is, feature requests, will appear. If the feature you wish to have it not yet in, click "Tasks" - "Submit", and submit a new task.
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.
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.
When troubleshooting bibledit 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 causes a segmentation fault 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
Bibledit would not run in gdb normally and say that another copy is already running. To disable that check for another instance, and have it run in gdb, add the --debug argument to the commandline:
(gdb) set args --debug
Run it:
(gdb) run
If there is a problem, bibledit will freeze. Switch to the debugger. View the stack:
(gdb) backtrace
You can then contact 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 debugger back.