There is an opportunity for a minor speedup in sqlite3Malloc().
sqlite3Malloc() is implemented as follows:
void *sqlite3Malloc(int n){
void *p;
if( (p = malloc(n))==0 ){
if( n>0 ) sqlite3_malloc_failed++;
}else{
memset(p, 0, n);
}
return p;
}
The separation of
OS X.
First, validate the integrity of your database file.
sqlite3 your.db
pragma integrity_check;
If the file is integral, then are you linking dynamically or
statically? If dynamically, you need to tangle with the make stuff to
build and link as a single module (it is a linker option).
b.bum
tables. Both hard to debug, unfortunately.
b.bum
?
... alternatively, try otool -L on the compiled binary produced by
Xcode.
If you are dynamically linking SQLite, try building it statically (see
the list archives -- I posed how to do this a few days ago). It may
be that you are running into a dynamic linking issue.
b.bum
statically linking SQLite or using a dylib?
b.bum
On Nov 6, 2004, at 10:48 AM, Jeff Flowers wrote:
There has to it than just being under the GPL. After all, Emacs and
other GLPed software is included in Mac OS X. Maybe it is to prevent
people from accidently mixing GPLed and non-GPLed code?
There isn't any GPL'd software on the baseline user
recompiled,
statically linked, .so in my .mac account:
http://homepage.mac.com/bbum/BumFiles/FileSharing27.html
Just grab the .so files and shove 'em in /Library/Python/2.3/. (There
is also a precompiled Python Berkeley DB module-- but it requires the
BDB dylib to be installed).
b.bum
of a bug
in Makefile.in that effectively causes .o files to be linked multiple
times in the testfixture binary.
b.bum
,
sqlite command line tool-- that is a much harder problem. Probably the
easiest way would be to change the file format slightly.
b.bum
breaking assumptions made by INSERT or UPDATE.
I guess I should really upgrade to sqlite3, which
uses PENDING locks to try and eliminate writer
starvation.
Even with PENDING, you can still write code to cause a deadlock as I
originally described.
b.bum
or the other
process to ABORT or for (A) to do an END TRANSACTION (which will work
because the INSERT/UPDATE attempt on (A) failed to advance the lock
state).
b.bum
Out of curiosity...
Both sqlite2 and sqlite3 use --version-info "8:6:8" when creating
libsqlite.la & libsqlite3.la. I would think the version # needs to be
changed?
b.bum
I'll file a bug on this. Anyone know how to file a bug such that the
formating isn't smushed into a single line?
Output from CSV mode is not properly quoted. An example (from sqlite3):
sqlite> .mode csv
sqlite> .header on
sqlite> create table "Foo" ( foo, bar );
sqlite> insert
. This also allows me to easily quantify
changes to the OS project over time and track my own changes, if
necessary.
b.bum
it -- it won't hurt anything and it'll make
your project source dir more portable)
- to include the sqlite3 header:
#include
That's all you need to do.
b.bum
to mark the lock as RESERVED at the beginning of the
transaction in certain special cases.
b.bum
ally a request to
have a test that ensures that the *** already existing locking features
*** work correctly when multiple processes are beating upon the
database. That is, to test code paths that already exist for which --
at least as far as I can tell -- there is little testing coverage.
How is that bloating SQLite?
b.bum
against the same
database file using the regular locking path. I don't believe this is
a case covered in the unit tests.
b.bum
Thank you for the precise explanation -- very helpful.
On Sep 3, 2004, at 8:19 AM, D. Richard Hipp wrote:
alloca(), which does
not work right on many systems.
... and would be on the stack anyway.
b.bum
appropriately along the way.
The larger question is what changed in SQLite3 such that the stack size
is significantly larger for common operations? I would imagine that
this could be of concern for the embedded market.
b.bum
significant
digit. doubles are only accurate to 17 signficant digits (roughly)
so the two number are indistinguishable.
Thank you for the clarification.
Could the test be changed such that it is version aware and the case
changes appropriately to ensure that it passes based on version?
b.bum
if so, -1 if not. Send 'em to me
personally and I'll be happy to keep a running tally.
b.bum
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Test 11.3 of format is failing on OS X...
do_test format3-11.3 {
execsql {SELECT '123456789012345678901'=='123456789012345678900'}
} {1}
why?
thanks,
b.bum
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
23 matches
Mail list logo
