Documentation Source Text

Check-in [801e11b806]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Updates to the matrix generator and to the custombuild.html document.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: 801e11b8062f0008ab834bf58c0cb951787e230e
User & Date: drh 2010-02-01 16:19:12
Context
2010-02-09
23:25
Add an evidence mark to a statement in fts3.in. Add an evidence mark to a statement in fts3.in. check-in: 58746651dd user: dan tags: trunk
2010-02-01
16:19
Updates to the matrix generator and to the custombuild.html document. check-in: 801e11b806 user: drh tags: trunk
16:18
Fix a typo in the FTS3 documentation. check-in: f0a07e571f user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Show Whitespace Changes Patch

Changes to matrix.tcl.

63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
...
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
      puts "$srcfile: bad requirement: [string range $nx 0 40]..."
      set x $nx
      continue
    }
    set orig [string trim $req]
    regsub -all {<.+?>} $orig {} req
    regsub -all {\s+} [string trim $req] { } req
    set req [string map {&lt; < &gt; > &amp; &} $req]
    set req [string trim $req]
    set reqno R-[md5-10x8 $req]
    db eval {SELECT srcfile AS s2, reqtext as r2
             FROM requirement WHERE reqno=$reqno} {
      puts "$srcfile: duplicate [string range $reqno 0 12] in $s2: \[$r2\]"
    }
    db eval {
................................................................................
    } else {
      regexp {^([^<]|<.+?>)*?\.} $nx req
      regsub {^([^<]|<.+?>)*?\.} $nx {} nx
    }
    set orig [string trim $req]
    regsub -all {<.+?>} $orig {} req
    regsub -all {\s+} [string trim $req] { } req
    set req [string map {&lt; < &gt; > &amp; &} $req]
    set req [string trim $req]
    set rno R-[md5-10x8 $req]
    set shortrno [string range $rno 0 12]
    append out "<a name=\"$rno\"></a><font color=\"blue\"><b>\n"
    set link "<a href=\"$matrixpath#$rno\" style=\"color: #0000ff\">"
    append out "$link$shortrno</a>:\[</b></font>"
    if {$proof($rno)>=2} {







|







 







|







63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
...
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
      puts "$srcfile: bad requirement: [string range $nx 0 40]..."
      set x $nx
      continue
    }
    set orig [string trim $req]
    regsub -all {<.+?>} $orig {} req
    regsub -all {\s+} [string trim $req] { } req
    set req [string map {&lt; < &gt; > &#91; [ &#93; ] &amp; &} $req]
    set req [string trim $req]
    set reqno R-[md5-10x8 $req]
    db eval {SELECT srcfile AS s2, reqtext as r2
             FROM requirement WHERE reqno=$reqno} {
      puts "$srcfile: duplicate [string range $reqno 0 12] in $s2: \[$r2\]"
    }
    db eval {
................................................................................
    } else {
      regexp {^([^<]|<.+?>)*?\.} $nx req
      regsub {^([^<]|<.+?>)*?\.} $nx {} nx
    }
    set orig [string trim $req]
    regsub -all {<.+?>} $orig {} req
    regsub -all {\s+} [string trim $req] { } req
    set req [string map {&lt; < &gt; > &#91; [ &#93; ] &amp; &} $req]
    set req [string trim $req]
    set rno R-[md5-10x8 $req]
    set shortrno [string range $rno 0 12]
    append out "<a name=\"$rno\"></a><font color=\"blue\"><b>\n"
    set link "<a href=\"$matrixpath#$rno\" style=\"color: #0000ff\">"
    append out "$link$shortrno</a>:\[</b></font>"
    if {$proof($rno)>=2} {

Changes to pages/custombuild.in.

25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
...
197
198
199
200
201
202
203



204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
Most developers should be able to completely ignore this document
and simply build SQLite from
<a href="amalgamation.html">the amalgamation</a> without any
special knowledge and without taking any special actions.</i></blockquote>

<p>However, highly tuned and specialized
applications may want or need to replace some of
SQLite's built-in system interface with alternative implementations
more suitable for the needs of the application.  SQLite is designed
to be easily reconfigured at compile-time to meet the specific
needs of individual projects.  Among the compile-time configuration
options for SQLite are these:</p>

<ul>
<li><p> Replace the built-in mutex subsystem with an alternative
................................................................................
There is also on-going work with experimental memory allocators that
satisfy all memory requests from a single fixed memory buffer handed
to SQLite at application start.  Additional information on these
experimental memory allocators will be provided in a future revision
of this document.</p>

<p>SQLite supports the ability of an application to specify an alternative



memory allocator at run-time using the [sqlite3_config()] interface.
For example:</p>

<blockquote><pre>
sqlite3_config(SQLITE_CONFIG_MALLOC, dlmalloc, dlfree, dlrealloc, dlmalloc_usable_size);
</pre></blockquote>

<p>The [SQLITE_CONFIG_MALLOC] setting to [sqlite3_config()] passes four
function pointers into SQLite.  The first three functions work exactly
like malloc(), free(), and realloc(), respectively, from the standard
C library.  The fourth function pointer must be for a routine that
returns the size of a memory allocation given a pointer to that allocation.
In the default memory allocator implementation for SQLite, these fourth
"memsize" function is implemented by prepending an 8-byte size integer
to the beginning of every allocation.  The memsize function is not a
standard part of must memory alloction libraries and so must be implemented
in this way.  However, Doug Lea's dlmalloc implementation, as shown in the
example above, does provide an implementation of memsize which, if used,
reduces the size overhead and execution time of every memory allocation
and deallocation.</p>

<p><i>TBD: Talk about alternative zero-malloc implementations and how to
select them at compile-time.</i></p>

<p><i>TBD: Talk about how to disable any built-in memory allocator so that
an application is required to register the memory allocator at
startup.</i></p>

<h2>4.0 Adding New Virtual File Systems</h2>

<p>Since [version 3.5.0], SQLite has supported an interface called the
[sqlite3_vfs | virtual file system] or "VFS".
This object is somewhat misnamed since it
is really an interface to whole underlying operating system, not
just the filesystem.</p>

<p> One of the interesting features
of the VFS interface is that SQLite can support multiple VFSes at the
same time.  Each [database connection] has to choose a single VFS for its
use when the connection is first opened using [sqlite3_open_v2()].
But if a process contains multiple [database connections] each can choose







|







 







>
>
>
|



|


|
|
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<
<






|







25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
...
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215


















216
217
218
219
220
221
222
223
224
225
226
227
228
229
Most developers should be able to completely ignore this document
and simply build SQLite from
<a href="amalgamation.html">the amalgamation</a> without any
special knowledge and without taking any special actions.</i></blockquote>

<p>However, highly tuned and specialized
applications may want or need to replace some of
SQLite's built-in system interfaces with alternative implementations
more suitable for the needs of the application.  SQLite is designed
to be easily reconfigured at compile-time to meet the specific
needs of individual projects.  Among the compile-time configuration
options for SQLite are these:</p>

<ul>
<li><p> Replace the built-in mutex subsystem with an alternative
................................................................................
There is also on-going work with experimental memory allocators that
satisfy all memory requests from a single fixed memory buffer handed
to SQLite at application start.  Additional information on these
experimental memory allocators will be provided in a future revision
of this document.</p>

<p>SQLite supports the ability of an application to specify an alternative
memory allocator at run-time by filling in an instance of the
[sqlite3_mem_methods] object with pointers to the routines of the
alternative implementation then registering the new alternative
implementation using the [sqlite3_config()] interface.
For example:</p>

<blockquote><pre>
sqlite3_config(SQLITE_CONFIG_MALLOC, &my_malloc_implementation);
</pre></blockquote>

<p>SQLite makes a copy of the content of the [sqlite3_mem_methods] object
so the object can be modified after the [sqlite3_config()] call returns.</p>



















<h2>4.0 Adding New Virtual File Systems</h2>

<p>Since [version 3.5.0], SQLite has supported an interface called the
[sqlite3_vfs | virtual file system] or "VFS".
This object is somewhat misnamed since it
is really an interface to the whole underlying operating system, not
just the filesystem.</p>

<p> One of the interesting features
of the VFS interface is that SQLite can support multiple VFSes at the
same time.  Each [database connection] has to choose a single VFS for its
use when the connection is first opened using [sqlite3_open_v2()].
But if a process contains multiple [database connections] each can choose