Re: [sqlite] philosophy behind public domain?

2005-05-26 Thread Greg Miller

Chad Whitacre wrote:


I am interested in the reasoning behind SQLite's dedication to the
public domain vis-a-vis other copyright/licensing options (GPL, BSD,
etc.) Is there any documentation available on this decision?


It comes down to goals. If your goal is to give other people code to 
use, then BSDL or public domain would be the way to go. If your goal is 
to get other people to give you code, then GPL would be a better approach.


Also keep in mind that many users of SQLite are using it on server-side 
apps that aren't distributed to others and wouldn't be affected by the 
GPL distribution restrictions anyway.

--
http://www.velocityvector.com/ | http://glmiller.blogspot.com/
http://www.classic-games.com/  |
 Linux is UNIX for Windows users. BSD is UNIX for UNIX users.


Re: [sqlite] sqlite3_bind_text() and SQLITE_STATIC question

2005-05-01 Thread Greg Miller
Thomas Briggs wrote:
 

From the looks of this warning, I would guess that you could redefine
SQLITE_STATIC like this (or some variation of this that is 
legal C++) to solve
the problem:

 #define SQLITE_STATIC ((extern "C" void(*)(void*)) 0)

   I don't think there's any legal way to do this, is there?  Linkage
is, well, a linker issue; this is a passing-a-function-pointer issue.
It doesn't seem sensible to me that you would/should be able to specify
the linkage for a function as you're passing around a pointer to that
function around.
As I recall, there's no truly portable way in C or C++ to do any sort of 
conversion involving pointers to functions. Even if you turn around and 
convert it back to the original type, you may get a different value 
because some platforms lose data. This is a side-effect of allowing fat 
pointers.

That being said, this code should work fine on nearly all platforms, 
since we're dealing with a special value of zero rather than actually 
attempting to call a real function.
--
http://www.velocityvector.com/ | http://glmiller.blogspot.com/
http://www.classic-games.com/  |
 Linux is UNIX for Windows users. BSD is UNIX for UNIX users.


Re: [sqlite] Thanks!

2005-03-03 Thread Greg Miller
[EMAIL PROTECTED] wrote:
After 15 years of assembler programming, I am still to find a compiler that
makes debugging and optimizing as easy as assembler.
I can't remember the number of times that C has got me deep into memory
leaks.

Then give C++ a try.
If you need low level programming, C is a good compromise.
If you need high level programming, C is a good compromise.
If you don't care about performance and need an idiot proof programming
language, try Java or perl.
Obviously C has a place but the day Java performs as well as C, who would
one to deal with all of those "shot your own foot" issues.

Java provides its own ways of shooting yourself in the foot. See the 
"finally" kludge for example.
--
http://www.velocityvector.com/ | http://glmiller.blogspot.com/
http://www.classic-games.com/  |
"We have declared a fierce war on this evil principle of
democracy and those who follow this wrong ideology,"
   -- Abu Musab al-Zarqawi


Re: [sqlite] Best way to check for existence of a table?

2005-02-14 Thread Greg Miller
Richard Boyd wrote:
I tried what you suggested and I always get the error message:
"SQL error: no such column: table32"
Whether the table exists or not, I always get returned value of 1 from
sqlite3_exec().
The exact command that I use is:
SELECT count(*) FROM sqlite_master WHERE name=table32 AND type='table';

If you don't quote "table32", then the database thinks you're trying to 
compare the value in the "name" column to the value in the "table32" 
column, which doesn't exist.

I also tried single quotes around the table32 name:
SELECT count(*) FROM sqlite_master WHERE name='table32' AND type='table';
And get no errors whether the table exists or not

Good, that's correct.
When I try the other method suggested ("SELECT NULL FROM sqlite_master WHERE
tbl_name = 'your-table';") I don’t get any error messages whether the table
exists or not. The return value is always 0.

SQLITE_OK is zero, so that means the query succeeded.
I'm obviously missing where the error is being flagged, have you any more
pointers?
Sorry if I'm being dense here but I'm new to SQL databases.

You need to check the returned data. The first query returns a result 
set containing a single row with one value, the number of tables named 
"table32"... The second query returns one or more rows containing a 
single NULL value if a table named "table32" exists or any empty result 
set if it doesn't.
--
http://www.velocityvector.com/ | http://glmiller.blogspot.com/
http://www.classic-games.com/  |
"We have declared a fierce war on this evil principle of
democracy and those who follow this wrong ideology,"
   -- Abu Musab al-Zarqawi


Re: [sqlite] SQLite Advocacy

2005-01-31 Thread Greg Miller
D. Richard Hipp wrote:
On Mon, 2005-01-31 at 11:31 -0600, [EMAIL PROTECTED] wrote:
99% of the world is on windows

I can't speak for the whole world, but visitors to the 
SQLite website over the past two weeks break out something 
like this:

Windows:  80.6%
Linux:14.9%
Mac:   4.5%
(There was really an 11.8% "other" or "not reported" which
I omitted then scaled the numbers above accordingly.)
Last time I checked Google Zeitgeist, they were reporting that 92% (or 
was it 93%?) of visitors used Windows. Kind of makes those claims of 
Internet Explorer having 95% marketshare back at its peak seem kind of 
silly. 95% would have been right at 100% of Windows and Mac users.
--
http://www.velocityvector.com/ | http://www.indie-games.com/
http://www.classic-games.com/  | http://glmiller.blogspot.com/
"We have declared a fierce war on this evil principle of
democracy and those who follow this wrong ideology,"
   -- Abu Musab al-Zarqawi


Re: [sqlite] Version 3.1.0

2005-01-21 Thread Greg Miller
Robert L Cochran wrote:
I should have indicated in my earlier post that magazines which do 
side-by-side hardware testing are saying that the AMD Athlon 64 is 
indeed faster than the Pentium 4; for example look in the January issue 
of Maximum PC magazine. they have a followup test supplementing an 
earlier review of Athlon vs. Pentium systems. Their testing results 
speak better than my faltering around with words. Tom's Hardware Guide 
has also compared Socket 939 Athlon systems to the latest that Intel 
has; I can't remember THG's exact judgement but it was overall more 
favorable to the Athlon systems.
Well, that's not an interesting or relevant comparison. A better 
comparison would be the same test run with a 32-bit application and a 
64-bit version of the same application on the same Athlon system.

Comparisons to other chips are irrelevant. That's different hardware.
--
http://www.velocityvector.com/ | http://www.indie-games.com/
http://www.classic-games.com/  | http://glmiller.blogspot.com/
"If my forgeries looked as bad as the CBS documents, it would
have been 'Catch Me In Two Days'"   -- Frank Abagnale, Jr.


Re: [sqlite] Version 3.1.0

2005-01-21 Thread Greg Miller
Robert L Cochran wrote:
I don't know how to explain this "excitement" myself, except through 
examples that might bore you because I don't know the details of how to 
write a program that takes advantage of a 64 bit cpu. The excitement is 
mainly about speed, I would say. To make compiled software harness that 
speed, it may be that only a compiler flag has to be turned on; I'm not 
real sure and should research it. But here are some examples:
64-bit code, in general, tends to be a little slower than 32-bit code on 
the same CPU. There are exceptions, of course.

AMD64 has the advantage of adding a number of new registers, and that 
can boost performance enough to make up for it. AMD claims something 
like a 5% net increase with AMD64 vs. IA32 on their own chips. This is 
not enough to really be visible. Unless you happen to have one of those 
apps that's really well suited to AMD64, you won't benefit much.

Where the Athlon 64 and Opteron really shine is the integrated memory 
controller. Without it, early Opterons and A64s would have been slower 
than the Athlon XPs that were released before them, according to AMD's 
own performance numbers.

Also keep in mind that many of the most demanding apps (e.g., games and 
workstation graphics) are heavy on floating point math. Those won't see 
any benefit, and many companies have struggled to even match the 
performance of 32-bit code, much less exceed it. The Unreal Engine (used 
in numerous games) is one notorious example.

In answer to your question, the compiler will automatically attempt to 
make use of the extra registers when compiling on your AM64 system. Just 
don't expect too much.
--
http://www.velocityvector.com/ | http://www.indie-games.com/
http://www.classic-games.com/  | http://glmiller.blogspot.com/
"If my forgeries looked as bad as the CBS documents, it would
have been 'Catch Me In Two Days'"   -- Frank Abagnale, Jr.


Re: [sqlite] Is there any way to enable recursive triggers?

2005-01-04 Thread Greg Miller
Sandy Ganz wrote:
This doesn't sound right, I have seen the problem that linux will not use
the allocated memory until it is touched, but doesn't the memory manger keep
track ultimatly of all allocations (in the kernel which as all encompassing
knowledge of allocations) which might include things that have not yet been
written too? In some of the apps that I wrote I saw the behaviour that I

This is intentional. It has all the information it needs, but it doesn't 
want to fail, since the apps allocating the memory may not need it all 
simultaneously. As I recall, FreeBSD behaves the same way.

could not allocate more ram and malloc fails, but never really noticed if it
fails on memory that has not been touched. I do remember in TOP not seeing
allocations happen until it was cleared (memset). For the critical stuff I
preallocate and mlock() allocated memory to force it into ram for most of
the server processes, but other processes, have run out of ram  at
allocation time, so I'm not sure that it won't fail just on allocation (all
on linux 2.4x btw). Good food for thought...

Been a while since I last thought about this issue, but if I remember 
correctly, you get a malloc() failure if the OS is unable to allocate 
another page of memory for allocation overhead, and a success if it can 
allocate that but doesn't have enough swap space left to write to all of it.

If you need to be sure that you detect out-of-memory conditions when 
allocating, you need to write to it immediately and catch any signals, 
OS exceptions, or whatever the target platform uses.
--
http://www.velocityvector.com/ | http://www.indie-games.com/
http://www.classic-games.com/  | http://glmiller.blogspot.com/
"If my forgeries looked as bad as the CBS documents, it would
have been 'Catch Me In Two Days'"   -- Frank Abagnale, Jr.


Re: [sqlite] absolute vs. relative path to database on Cygwin

2004-12-14 Thread Greg Miller
amead wrote:
Are you doing this at the Cygwin prompt or Window's command prompt?  My 
installation of Cygwin doesn't recognize DOS style paths at all:

$ ls c:\cygwin
ls: c:cygwin: No such file or directory
You used a backslash, escaping the 'c' character. Notice that the error 
message refers to "c:cygwin" rather than "c:\cygwin", which isn't 
equivalent.

Try "ls c:/cygwin" instead.
--
http://www.velocityvector.com/ | http://www.indie-games.com/
http://www.classic-games.com/  | http://glmiller.blogspot.com/
"If my forgeries looked as bad as the CBS documents, it would
have been 'Catch Me In Two Days'"   -- Frank Abagnale, Jr.


Re: [sqlite] [OT] Shell globbing - Re: [sqlite] trying to compile SQLite

2004-09-05 Thread Greg Miller
Christian Smith wrote:
On Fri, 3 Sep 2004, Greg Miller wrote:
I guess the UNIX folks just didn't know any better way back then.
Putting globbing in the API instead of the shell is a much better
approach, but that wasn't all that obvious when UNIX first came along.

You condone the DOS/Windows (lack of) approach?
Put it in a library, yes. But it is still best done by the shell (IMHO.)
The shell is written once, so for the common case, globbing only has to be
implemented in one place.

And for anything even slightly uncommon, life becomes more difficult. 
It's hard to produce good error messages in some cases, certain command 
syntaxes become impossible, many commands (e.g., find) need wildcard 
args quoted in order to prevent the shell from screwing them up, you 
have to work around commandlines that exceed the length limit, etc. As 
both a user and programmer on UNIX(ish) operating systems, I've come to 
be quite annoyed by this behavior.

Having every utility do it's own globbing results is code reuse for the
sake of code reuse. I prefer just having a list of files the user wants
manipulated.

Putting globbing support in the API makes it easy without destroying 
information about the arguments. UNIX(ish) platforms ended up having to 
do this, anyway with functions like glob().

I do recall reading both the DDJ column you mentioned and the follow-up 
in which he acknowledged the problems with shell globbing, BTW.
--
http://www.velocityvector.com/ | "F--- 'em all. That's how I feel."
http://www.classic-games.com/  | -- Michael Moore on small business
http://www.indie-games.com/|


Re: [sqlite] trying to compile SQLite

2004-09-03 Thread Greg Miller
Christian Smith wrote:
I found it funny, while looking through Dr Dobbs journal some time ago,
about a columnist (Al Stevens, I think!) being surprised that under UNIX,
such things as filename globbing was done by the shell, and all main()
usually gets is a list of valid filenames. Under DOS and Windows, given:
  C:\Temp> grep foo *
The '*' would have to be interpreted and expanded by the grep program, but
under UNIX, the list of files is generated by the shell. Of course, you
can get decent shells on Windows as well, but generally only as ports of
UNIX shells.

I guess the UNIX folks just didn't know any better way back then. 
Putting globbing in the API instead of the shell is a much better 
approach, but that wasn't all that obvious when UNIX first came along.

--
http://www.velocityvector.com/ | "F--- 'em all. That's how I feel."
http://www.classic-games.com/  | -- Michael Moore on small business
http://www.indie-games.com/|


Re: [sqlite] OT: Reply-To Munging Considered Useful

2004-07-23 Thread Greg Miller
Michael Roth wrote:
Please switch off Reply-To again.
There are certainly a few drawbacks to using Reply-To, but I can't 
remember the last time I was on a mailing list that didn't make use of 
it. Clearly, there's a very solid consensus out there that Reply-To is 
the way to go.

--
http://www.velocityvector.com/ | "F--- 'em all. That's how I feel."
http://www.classic-games.com/  | -- Michael Moore on small business
http://www.indie-games.com/|


Re: [sqlite] Re: sqlite-users Digest 22 May 2004 05:23:11 -0000 Issue 115

2004-05-22 Thread Greg Miller
Ulrik Petersen wrote:
IANAL, but the way I understand it, you can't link against their 
libraries and still distribute your code under an Open Source license, 
or distribute your binaries under a license that requires that the 
software be offered at no charge.  My understanding may be flawed, so 
read the EULA yourself before deciding whether the toolchain is for you.
It looks like they only bar you from distributing their redistributables 
under the terms of a viral license. You'd still be free to compile, 
link, and distribute binaries of open source apps under other licenses.

--
http://www.classic-games.com/ http://www.indie-games.com/
"Iraq may not be the war on terror itself, but it is critical to
the outcome of the war on terror, and therefore any advance in
Iraq is an advance forward in that..." -- John Kerry 12/15/03
"I took part in search and destroy missions, in the burning of
villages." -- John Kerry 4/18/71
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [sqlite] row size limit

2004-04-18 Thread Greg Miller
Greg Obleshchuk wrote:

I know the MS is looking at replacing the file system with the SQL engine in Longhorn so they must have solved the issue.
They're not replacing NTFS with a database. They're implementing a 
database layer (WinFS) on top of NTFS. It's not entirely clear what 
they're doing, but apparently they index a bunch of metadata in order to 
help manage files.

On a related note, this has apparently been pushed back to a 
post-Longhorn release so that they can keep Longhorn on track for 2006. 
That, at least, is what the tech media is reporting.
--
http://www.classic-games.com/ http://www.indie-games.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [sqlite] Effectiveness of PRAGMA integrity_check;

2004-04-15 Thread Greg Miller
D. Richard Hipp wrote:

 From what I am told, most IDE drives do signal the OS when the data
reaches the platter.  I'm also told that the Linux fsync() call does
not return until it gets that signal.  The Windows FlushFileBuffers(),
on the other hand, does not wait for the data to get to platter.  So
on a windows system, there is a brief moment of vulnerability where
a power loss can lose data.  But on Linux, that window of vulnerability
is zero.
The above is how IDE drives are *suppose* to work.  There is wide-
spread suspicion that many cheap IDE drives do not implement the
protocol correctly.  If your have one of those broken IDE disks,
all bets are off.


Keep in mind that I'm simply parroting my interpretation of the 
discussions over on the mailing lists at freebsd.org... You might want 
to go straight to the horse's mouth instead of having it filtered 
(possibly incorrectly) through me. :)

I am also told that the Linux IDE driver is broken with respect to
media errors.  If the disk drive has a media error, Linux does not
take appropriate corrective action, nor does it alert the user-space
code.  I don't know how true this is or if it is really a problem.
(How common are media errors?)


Not very common, but I don't anything about the Linux ATA driver, so I 
couldn't begin to guess just how badly broken it might or might not be.

Regardless of the situation, though, the window of vulnerability
during which a power loss might cause database corruption is small.
And Liz is reporting that she can reproduce the corruption
consistently.  So perhaps her trouble have a different cause.
Even a small window could do the job if it's being written to at a high 
rate of speed. By the time one set of writes actually hits the disk, 
more may be in flight. Dunno, there could be any number of factors 
contributing to this.

I guess the moral of the story is that reliable power is important.
--
http://www.classic-games.com/ http://www.indie-games.com/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [sqlite] Effectiveness of PRAGMA integrity_check;

2004-04-15 Thread Greg Miller
Andrew Piskorski wrote:

On Thu, Apr 15, 2004 at 08:33:14AM -0500, Greg Miller wrote:
support that. The FreeBSD folks tried to solve this by turning off write 
caching by default. Unfortunately, this hurt performance so much they 
had to turn it back on and just recommend SCSI drives for important data.


Why, do SCSI drives all come with battery-backed cache?  (So when you
power them up again they complete the old cached write.)  I didn't
think so, but would be pleased to learn otherwise...


No, but the OS can ensure that the ordering constraints are honored on 
any writes that actually make it to the disk. That's the only constraint 
the OS makes anyway, since it ensures that the only disk corruption that 
can occur is that some disk space that is currently unused may still 
appear to be in use. Then when the system boots after a failure, the 
system snapshots the disk, and fsck runs in the background to free up 
that unused space in the background. That's how FreeBSD avoids journalling.

Of course, with a good UPS *AND* the proper software running to react
to signals from the UPS, you get that sort of protection for free, and
you certainly want the system UPS anyway.  But that's also much more
complicated and vulnerable to failures due to misconfigured software,
so it'd sure be nice to have the hard-drive-UPS as well.
I suspect there's just not enough demand. People that need the safety 
just go out and by SCSI drives, IDE drives with tagged queueing, or a 
general purpose UPS.
--
http://www.classic-games.com/ http://www.indie-games.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [sqlite] Effectiveness of PRAGMA integrity_check;

2004-04-15 Thread Greg Miller
Liz Steel wrote:

You say that I shouldn't get a corrupt database when I pull the power, 
but I am consistently getting this. I am using SQLite version 2.8.9 
using the C++ interface running on Windows XP Home. Is there anything I 
can do to stop this happening?
If you have an IDE hard drive that's caching writes, there's not much 
the OS and database software can do to prevent corruption on power loss. 
It's possible to avoid this with tagged queueing, but most drives don't 
support that. The FreeBSD folks tried to solve this by turning off write 
caching by default. Unfortunately, this hurt performance so much they 
had to turn it back on and just recommend SCSI drives for important data.
--
http://www.classic-games.com/ http://www.indie-games.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: [sqlite] FreeBSD and SQLite

2004-04-14 Thread Greg Miller
Al Rider wrote:

Is there anyone successfully running SQLite on a FreeBSD machine?  If so,
would you email me and give me some help with it.
I've never used it on anything else. The instructions assume that make 
is actually GNU make, which is almost certainly not the case on a 
non-Linux machine. If you substitute "gmake" for "make" in the 
instructions, it should build fine as long as GNU make is installed.

Alternatively, you can build it from the databases/sqlite port by 
changing to the appropriate directory (/usr/ports/databases/sqlite) and 
typing "make install"

If you continue to have problems, I'd be glad to help. Need more 
details, though.
--
http://www.classic-games.com/ http://www.indie-games.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]