/usr/share/bibledit-gtk/site/community/development.html is in bibledit-gtk-data 4.9-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<link href="../bibledit.css" rel="stylesheet" type="text/css" /><!--
Copyright (©) 2003-2011 Teus Benschop and Contributors to the Wiki.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled "GNU
Free Documentation License" in the file FDL.
-->
<title></title>
</head>
<body>
<div id="menu">
<ul>
<li>
<a href="../home.html">1 Bibledit</a>
</li>
<li>
<a href="../community.html">Community</a>
</li>
<li style="list-style: none; display: inline">
<hr />
</li>
<li>
<a href="contacts.html">Contacts</a>
</li>
<li>Development
<ul>
<li>
<a href="development/diagnostics.html">Diagnostics</a>
</li>
<li>
<a href="development/mac-os-x.html">Mac OS X Notes</a>
</li>
</ul>
</li>
</ul>
</div>
<div id="content">
<h1>
Development
</h1>
<h3>
<a name="TOC-Code-repository" href="" id="TOC-Code-repository"></a>Code repository
</h3>
<p>
The code is stored in a git repository. The repository is accessible from the <a href="http://savannah.nongnu.org/projects/bibledit" rel="nofollow">Savannah Project Page</a>. 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.
</p>
<p>
The code can be checked out from the repository. This code gives the latest versions of the Bibledit suite or programs. The code has not been thoroughly tested, but is supported.
</p>
<p>
To get the most recent code, do the following in a terminal.
</p>
<pre>
git clone git://git.savannah.nongnu.org/bibledit
</pre>
<p>
The above command clones the code repository to your local disk. It will create a directory called "bibledit". Go into that directory, go into directory "gtk" for bibledit-gtk, or into directory "web" for bibledit-web. Then do the normal "./configure", "make", "sudo make install" sequence, as is described in the <a href="https://sites.google.com/site/bibledit/gtk/installation" target="_blank">installation documentation for bibledit-gtk</a> and the <a href="http://bibleconsultants.dyndns.org/bibledit-web-demo/help/installation.php" target="_blank" rel="nofollow">installation documentation for bibledit-web</a>..
</p>
<p>
Note 1. If you are installing development versions often, to save bandwidth, it is possible 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:
</p>
<pre>
<span style="font-family:Arial,Verdana,sans-serif;white-space:normal">$ cd bibledit
$ git reset --hard
$ git pull</span>
</pre>
<pre>
<span style="font-family:Arial,Verdana,sans-serif;white-space:normal"><span style="font-family:Arial,Verdana,sans-serif;font-size:10pt;line-height:1.6;white-space:normal">Continue installation from here...</span>
</span>
</pre>
<p>
<span style="line-height:1.6;font-size:10pt">Note 2. For best results close Bibledit-Gtk while installing the new version. This does not apply to Bibledit-Web.</span>
</p>
<h3>
<a name="helpneeded" href="" id="helpneeded"></a>Help needed
</h3>
<p>
Help in developing Bibledit is welcome.
</p>
<p>
* Do you like writing good documentation? Your help is welcome to maintain the helpfiles of Bibledit.
</p>
<p>
* You know how useful packages are? Making packages could be the thing you would like to help with.
</p>
<p>
* Are you good at testing? Your feedback is welcome and suggestions for new features too.
</p>
<h3>
<a name="bugsandfeaturerequests" href="" id="bugsandfeaturerequests"></a>Bugs and feature requests
</h3>
<p>
Savannah.nongnu.org provides resources for developing Bibledit. The <a href="http://savannah.nongnu.org/projects/bibledit" rel="nofollow">Savannah Project Page</a> is the central point from where all these resources can be accessed.
</p>
<p>
To report a problem go to the <a href="http://savannah.nongnu.org/projects/bibledit" rel="nofollow">Savannah Project Page</a>, 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.
</p>
<p>
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.
</p>
<p>
When submitting bug reports it is sometimes useful to include the configuration and data of Bibledit-Gtk. This allows the programmer or tester to reproduce your bug, and so fix it. In a terminal type
</p>
<pre>
tar -czf bibledit.tar.gz .bibledit
</pre>
<p>
to create a file called bibledit.tar.gz. This file can be attached to the bug report.
</p>
<h3>
<a name="howitstarted" href="" id="howitstarted"></a>How it started
</h3>
<p>
It started with an entry in the programmer's diary:
</p>
<p>
* 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.
</p>
<p>
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 to find out 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.
</p>
<p>
In 2004 some programming work was done that aided Bible translation work, and as I foresaw a greater future use for this program, I called it Bibledit.
</p>
<p>
After that God gave sufficient energy to work on the project in the spare time. Others started to contribute too, and the project moved forward to where it is now.
</p>
<h3>
<a name="usingthedebugger" href="" id="usingthedebugger"></a>Using the debugger
</h3>
<p>
When troubleshooting bibledit a core file may be requested.
</p>
<p>
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.
</p>
<p>
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:
</p>
<pre>
ulimit -c<br />0
</pre>
<p>
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:
</p>
<pre>
ulimit -c 50000
</pre>
<p>
allows core files and limits the file size to 50000 bytes.
</p>
<p>
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.
</p>
<p>
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>.
</p>
<pre>
prompt > bibledit<br />Segmentation fault (core dumped)<br />prompt > gdb bibledit<br />...<br />(gdb) core core.<pid><br />...
</pre>
<p>
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.
</p>
<p>
Open bibledit in the debugger:
</p>
<pre>
gdb bibledit
</pre>
<p>
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:
</p>
<pre>
(gdb) set args --debug
</pre>
<p>
Run it:
</p>
<pre>
(gdb) run
</pre>
<p>
If there is a problem, bibledit will freeze. Switch to the debugger. View the stack:
</p>
<pre>
(gdb) backtrace
</pre>
<p>
You can then contact the developer and inform him about what you see and when it happened.
</p>
<p>
Notes:
</p>
<p>
On Cygwin, gdb might get stopped and return you to the terminal. Enter "fg" to get the debugger back.
</p>
</div>
</body>
</html>
|