Re: [sqlite] how to pass -Dxxx compile option

[Gary R. Schmidt]

On 09/01/2020 17:47, Xingwei Lin wrote:

Hi,

How can I pass -Dxxx compile option when I build sqlite? Such as, -
DSQLITE_ENABLE_INTERNAL_FUNCTIONS.


./configure --help will tell you that CFLAGS is how you do that, so:

./configure CFLAGS=-Dwhatever

If you have many options:

./configure CFLAGS="-Dwhatever -Dthis -Dthat -mwhoops"

Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] CVE-2019-19317

[Gary R. Schmidt]

On 15/12/2019 10:16, Yongheng Chen wrote:

When we report the bugs, we said that they were from 3.31 version, but people 
in mitre changed them to 3.30.1. We just reported what we found. And the commit 
we reported in the bug report is referencing to the official GitHub repo.

Of course the people at Mitre changed the version number, they do not 
create a CVE for *unreleased* software.


It has already been pointed out that GitHub is not the official 
repository, it is a mirror.
You should be using the Fossil repository to test unreleased versions, 
which means you will get the latest version.


Also, reporting bugs here (or to sqlite-dev) would be the polite thing 
to do, as it gives the developers a chance to fix things before the 
software gets released, rather than causing a CVE to be generated, for a 
problem that does not yet exist in the real world.


And it means that I (and others) won't be having to answer email from 
customers on Monday (their time) and Tuesday (my time) where they are in 
a complete panic because they've discovered[1] that a CVE has been 
raised on a component of the products, and, "Oh, no, the sky is falling, 
what shall we do, what shall we do?!?!?!"


Cheers,
GaryB-)

1 - Yes, they're smart enough to troll the CVE lists looking for 
problems, but not smart enough to evaluate the possible effects of the 
problem.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Performance vs. memory trade-off question

[Gary R. Schmidt]

On 15/12/2019 00:27, Richard Hipp wrote:

A new feature on a branch has the following disadvantages:

(1)  It uses about 0.25% more CPU cycles.  (Each release of SQLite is
normally about 0.5% faster, so enabling this feature is sort of like
going back by one-half of a release cycle.)

(2)  The code space (the size of the library) is between 400 and 500
bytes larger (depending on compiler and optimization settings).

The this one advantage:

(3)  Each database connection uses about 72 KB less heap space.

QUESTION:  Should this feature be default-on or default-off?

What's more important to you?  0.25% fewer CPU cycles or about 72KB
less heap space used per database connection?

The feature can be activated or deactivated at start-time, but you
take the disadvantages (the performance hit and slightly larger
library size) regardless, unless you disable the feature at
compile-time.  If the feature is compile-time disabled, then the
corresponding code is omitted and and it cannot be turned on at
start-time.

If you have opinions, you can reply to this mailing list, or directly to me.


I'll vote for "default on"
- 72KB of heap is a fair old whack, particularly for those on bare 
silicon.
	- the half-a-step back in performance is a "meh," given that only those 
who manage to push the latest version to production quickly will 
probably even notice, that is, if they look for it.
	- 400-500 bytes is not a dramatic cost, but it still might be too much 
for someone's PROM.



Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Regarding the whole C89/C90 language compliance debacle ...

[Gary R. Schmidt]

On 24/11/2019 10:35, Simon Slavin wrote:

On 23 Nov 2019, at 11:06pm, Richard Hipp  wrote:


given the choice between

(1) Code that works and does something useful
(2) Code that is standards compliant

I'll always go with (1).


Another problem is that different compilers, or the same compiler with 
different options, warn about different things.  And that making changes to 
make one compiler happy can make another compiler unhappy.  Until you end up 
with

 complicated line here; /* actually does a = b but
must keep four compilers happy */


Things like this remind me of Donald Knuth's line: "Beware of bugs in 
the above code; I have only proved it correct, not tried it."


And over the decades[1] of writing (portable) C code I have sprinkled 
many such comments on how, "doing this makes it work on such-and-such a 
system" in many, many files.  :-)


Cheers,
GaryB-)

1 - I was taught C by kre back in 1982 (or was it 1983?), on a VAX 
called "munnari," for those who remember their history  :->

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Things you shouldn't assume when you store names

[Gary R. Schmidt]

On 10/11/2019 13:44, Doug wrote:

Au Contraire, Jens! In many local contexts you can normalize people's names. I 
was born in Kansas, USA. My parents filled out a birth certificate for me. It 
had a place on the form for first name, middle name, last name, and a suffix 
like II or III.

That birth certificate form determined that everyone born in Kansas (at that 
time), had a first, middle, and last name. There was no discussion of the 
matter. That's the way it was. The form led the way; people never thought about 
whether it was effective or not. Each newly-born child was given a first, 
middle, and last name.

Effective was irrelevant for that system. There was no option, no alternative. 
It simply was.

All systems are like that at each moment in time. They are what they are at any 
moment in time, and they force the users to behave the way the system wants 
them to behave. If you want to change the system and momentum is on your side, 
then immediately you have a new system - at that moment in time. It is composed 
of the old system and the momentum.

Back to names: just like the birth certificate, a system which assigns a name to you, 
actually coerces you to have that name, because within that system, you exist as that 
name. The "names" article is totally wrong when it says that each assumption is 
wrong. Each of those assumptions is correct, and I can find at least one system which 
makes each one correct. Within each system, the assumption works, and is valid.

My two cents...

Is not worth the paper it is written on!

So what happens when someone from a family who only uses first- and 
last-names moves to Kansas?


Do they have to make up a middle-name so that he idiots can fill out the 
forms?


Well, in the case of the US Navy back in the late 1980's, when a friend 
of mine from here in Australia, who only has a first and last-name 
married a USN pilot and moved to the USA, she was told that, "Yes, you 
have a middle name."  No amount of arguing, or producing of official 
documents, (well, it's the USA, most people there don't know what a 
passport is), could prevail.  In the end she conceded defeat and became 
 Doe , for the duration.


Names are impossible, unless you use a free-form, infinite-length field, 
you won't be safe, and even then, someone with turn up whose name is 'n' 
recurring to an infinite number of characters or something!


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Network file system that support sqlite3 well

[Gary R. Schmidt]

On 17/10/2019 16:42, Peng Yu wrote:

I will need to use the actual files to test for dependency (just as
the dependency that can be used by GNU make)


I don’t understand what that means. You want to use a makefile that checks the 
mod date of the database?


Suppose A is a sqlite3 db file, B is some other file which is
generated based on the content in A. When A is not changed, there is
no need to change B, otherwise, B will need to be regenerated. In
other words, B depends on A, and can be handled by tools dealing with
dependencies (e.g., GNU Make, Scons).

Many people replied to this thread suggesting not to directly use
sqlite3, but access the sqlite3 database via a network interface. That
will not be an option, as I don't think a network interface can be
easily supported by those dependency checking tools like GNU Make.

Well, that's wrong, I've been using make, cake, GNU Make, and nmake, 
across network file systems for decades, and, presuming that the various 
machines running processes and serving data have their clocks 
synchronised (and NTP has been a solved problem for a long, long, long 
time now), it Just Works(TM).


And not just with machines on the same segment of a LAN, some of them 
have been on the other side of the country (I am in Melbourne, 
Australia), and even in other countries.


So a make clause like ('ware line wrap):
/path/to/B.txt: /other/path/to/A.db
echo "select * from abc;" | sqlite3 /other/path/to/A.db > /path/to/B.txt

Will work, regardless of where A.db, B.txt, and the Makefile are located.

Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Network file system that support sqlite3 well

[Gary R. Schmidt]

On 16/10/2019 10:38, Jens Alfke wrote:




On Oct 15, 2019, at 3:47 PM, Peng Yu  wrote:

I'd like to use sqlite3 db files on many compute nodes. But they
should access the same storage device for the sqlite3 db files.


Why not use an actual client-server database system like MySQL? It's 
optimized for this use case, so it incurs a lot less disk (network) I/O.



To second what Jens has written - use the right tool for the job.

SQLite is *not* the right tool for this sort of job.

MySQL/MariaDB/PostGRESQL/Oracle/SQL Server/DB2/... are what you should 
be looking at.


    Cheers,
        Gary B-)

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Date time input

[Gary R. Schmidt]

On 09/10/2019 10:25, Kevin Benson wrote:

On Tue, Oct 8, 2019 at 2:40 PM James K. Lowden 
wrote:


On Tue, 8 Oct 2019 09:06:24 -0700
Jens Alfke  wrote:


I think the idea of a semi-official ?SQLite++? has been floated here
before


OK, but it needs a better name. --



SQLiteXTD


SQLArdArse.

Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Safe to use SQLite over a sketchy network?

[Gary R. Schmidt]

On 26/09/2019 15:30, Keith Medcalf wrote:

-Original Message-
From: sqlite-users  On
Behalf Of Gary R. Schmidt
Sent: Wednesday, 25 September, 2019 23:13
To: sqlite-users@mailinglists.sqlite.org
Subject: Re: [sqlite] Safe to use SQLite over a sketchy network?

On 26/09/2019 15:00, Jens Alfke wrote:



On Sep 24, 2019, at 3:48 PM, Keith Medcalf 

wrote:


There are not, to my knowledge, any client/server database systems

that will work properly if the database resides on a network filesystem
(meaning remote multi-access).  The "client" is remote from the "server"
because the "client" and "server" use some sort of IPC mechanism (of
which a network is an example) so that the "client" can send commands to
and receive responses from the "server".


Well, obviously. “Client/server” means databases like MySQL or Oracle.

No one would run those with the server using a networked file system.



I might have dreamt it, but NetAPP had an add-on for Oracle, quite
probably still do, that enhanced performance and behaviour when used for
storage.

Not sure if it was applied to the server or the NAS, possibly both, but
it was an Oracle-recommended solution for large storage requirements.


[Top-posting fixed.]
>
> That is remote block storage, not a remote filesystem.  Remote block
> storage just has a "longer wire" going to the block storage.  iSCSI,
> for example, will let you put your block storage anywhere, even in
> orbit.  The filesystem, however, still resides on the local computer.
>
No, it was over NFS, and while it could be used to give Oracle a "raw 
partition," it was intended to be used as a file-system that could be 
managed by the NAS, and allowed for the files to accessed by more than 
one Oracle server instance.


This was before we got Oracle RAC, I should mention.

Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Safe to use SQLite over a sketchy network?

[Gary R. Schmidt]

On 26/09/2019 15:00, Jens Alfke wrote:



On Sep 24, 2019, at 3:48 PM, Keith Medcalf  wrote:

There are not, to my knowledge, any client/server database systems that will work properly if the database resides on a network filesystem 
(meaning remote multi-access).  The "client" is remote from the "server" because the "client" and 
"server" use some sort of IPC mechanism (of which a network is an example) so that the "client" can send commands to 
and receive responses from the "server".


Well, obviously. “Client/server” means databases like MySQL or Oracle. No one 
would run those with the server using a networked file system.

I might have dreamt it, but NetAPP had an add-on for Oracle, quite 
probably still do, that enhanced performance and behaviour when used for 
storage.


Not sure if it was applied to the server or the NAS, possibly both, but 
it was an Oracle-recommended solution for large storage requirements.


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Safe to use SQLite over a sketchy network?

[Gary R. Schmidt]

On 25/09/2019 15:36, Rowan Worth wrote:

On Wed, 25 Sep 2019 at 12:58, Simon Slavin  wrote:


When I first learned the SQLite had problems with Network File Systems I
read a ton of stuff to learn why there doesn't seem to be a Network File
Systems that implements locking properly. 

Still, I wonder why someone working on a Linux network file system, or
APFS, or ZFS, hasn't done it.



I'm not sure what your definition of "locking properly" is or when your
research was done, but POSIX advisory locks¹ work just fine on linux over
nfs (since at least v3) and lustre.

¹ That's the F_SETLK/F_GETLK/F_SETLKW commands via the fcntl() syscall,
which is also sqlite's default locking mechanism under UNIX.

I don't see it as that much of a problem, I've been locking 
database-type files over NFS/RFS/DECNET since the 1980s, and SMB since 
the 1990s.


Now, there have been a *lot* of crappy implementations of NFS out there, 
probably the crappiest currently in use is the Linux version, but it is 
better than it used to be (I wonder if sharing a file system still 
causes the entire NFS server to re-start), and let's not mention the 
reasoning behind, "Why should we drop back to NFSv3 if the NFSv4 
initiation fails?"


Although I have had to convince a few people of the right /way/ to take 
out a lock...


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [EXTERNAL] Re: Getting the week of the month from strftime or date functions

[Gary R. Schmidt]

On 07/05/2019 16:46, Hick Gunter wrote:

Even the concept of "year" is subject to differing religious and cultural viewpoints, with some 
traditions still insisting on a lunar calendar with the corresponding shift of seasons by 11 days each year. 
And in one case, the length of a month depending on the weather conditions and the eyesight of the guy who 
happens to call the months. Pity the maya calendar didn't catch on. One "day number" wraparound 
every 4000 years sounds great (until you are the one who has to fix the coding that assumed it would 
"never happen")

Little known fact about the Mayan religion and calendar - you had to 
treat the "end" as really, really, being the end.


Their belief system was that the world would end at the end of a cycle, 
but they didn't know which one!  And if you got it wrong, the ghods 
would be very unhappy  :-(


So yes, it would "never happen"!!!

Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Database locking problems

[Gary R. Schmidt]

On 21/01/2019 18:46, andrew.g...@l3t.com wrote:

Okay, I put in some instrumentation.  Basically I print out all database 
queries as they happen, along with all calls to sqlite3OsLock() and 
sqlite3OsUnlock() (including their lockType argument and any abnormal return 
code).  Also I print out how many times sqlite3InvokeBusyHandler() has to call 
the busy handler.

For the moment, the solution that is working for me is to disable syncing with 
PRAGMA synchronous = OFF.  This is acceptable in this particular application 
because a power failure or OS crash will necessitate restarting the data 
gathering process anyway.  I'll explain later why this change helps.

In looking at the logs, I'm seeing several unlucky locking patterns.  Let's 
just pick one.  Process A gets starved by process B since B does many write 
transactions in a row, each time successfully getting an EXCLUSIVE lock.  When 
B calls fdatasync() (actually fsync()), it blocks while holding EXCLUSIVE.  A 
wakes up, but A can't immediately get a SHARED lock because B holds EXCLUSIVE.  
A goes to sleep while holding no locks, then B wakes up when the fsync() 
completes.  B then releases locks but grabs EXCLUSIVE again to complete its 
next transaction, and the cycle repeats.  A still can't get its SHARED lock, so 
it goes to sleep again, and then B continues to monopolize the lock.  This goes 
on long enough to exhaust A's patience, at which point SQLITE_BUSY propagates 
to the application.

Long ago, when I was at PowerFlex, on an OS long dead (Siemens-Nixdorf 
SINIX) using the MIPS RM series of processors, we saw a similar problem.


In that case it was a batch process locking out interactive users, but 
*only* on the top-of-the-line machine, the lower end, slower CPUs were fine.


One of S-N's finest engineers informed the customer that we "didn't know 
anything about file-locking on UNIX(TM) systems," which was slightly 
annoying, to say the least.


So we started into space, and we drew diagrams on the whiteboard, and I 
scribbled on my notepad, and stared at my locking code, and eventually 
decided that it was probably down to the batch process on the faster CPU 
just not giving up the lock when the interactive processes were ready to 
run.  I.e. "Here's the lock...  Oh, I've still got some time left, I'll 
hang on to it...  My time has run out but I've still got the lock, nyah, 
nyah, nyah."


We added "sleep(0)" after the "unlock()" call.

The problem went away.

This may help you, it may not.

Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure

[Gary R. Schmidt]

On 20/01/2019 15:03, Dennis Clarke wrote:

On 1/19/19 10:55 AM, Igor Korot wrote:

Dennis,
On Sat, Jan 19, 2019 at 9:31 PM Dennis Clarke  
wrote:




And SPARC version is still available for download...


Let us know when you get that running.


Install of x86 went very smooth.


The x86_64 process is trivial.


And I was able to compile fairly recent SQLite with Oracle Studio 12.6
with just couple of warnings...

Which problem did you experience on SPARC?


It is a nearly impossible process. Can not be done unless you have a
very specific class of hardware.

Really?  SQLite3 builds quite happily on the various SPARC S8 systems we 
keep alive, because, customers, and on the S8 Zone on the T1000 running 
S10.  (I have the zone (and an S9 zone) because keeping old hardware 
alive is a worry.)  (Not using Studio 12.6, of course  :-) )


Cheers,
GaryB-)

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure

[Gary R. Schmidt]

On 20/01/2019 15:03, Dennis Clarke wrote:

On 1/19/19 10:55 AM, Igor Korot wrote:

Dennis,
On Sat, Jan 19, 2019 at 9:31 PM Dennis Clarke  
wrote:




And SPARC version is still available for download...


Let us know when you get that running.


Install of x86 went very smooth.


The x86_64 process is trivial.


And I was able to compile fairly recent SQLite with Oracle Studio 12.6
with just couple of warnings...

Which problem did you experience on SPARC?


It is a nearly impossible process. Can not be done unless you have a
very specific class of hardware.

Really?  SQLite3 builds quite happily on the various SPARC S8 systems we 
keep alive, because, customers, and on the S8 Zone on the T1000 running

S10.  (I have the zone (and an S9 zone) because keeping old hardware
alive is a worry.)  (Not using Studio 12.6, of course  :-) )

Cheers,
GaryB-)

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Gary R. Schmidt]

On 03/01/2019 22:22, Peter da Silva wrote:

Why is the exponent in the low bits, since it forces unnecessary shifts for
integer operations?

That's easy, because the high bits are closer to the barrel shifter, so 
it takes less time for the electron to get there![1][2]


Cheers,
GaryB-)

1 - Oh ghod, bit-order arguments, worse than the shell wars and the 
editor wars combined!!!


2 - Sarcasm intended, for those who may not be certain.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Question about floating point

[Gary R. Schmidt]

On 2018-12-17 02:41, Simon Slavin wrote:

On 16 Dec 2018, at 2:54pm, Wout Mertens  wrote:

imagine having to handle the Zimbabwean Dollar, which ended up having 
100 trillion dollar notes. Good way to overflow your integers.


Indeed.  But when the crisis started in the early 2000s, the currency
was devalued by 1000.  Then ten zeros were wiped out at a stroke.  And
then another twelve zeros were slashed to make the "fourth Zimbabwe
dollar".

So if you were going to keep track of an account with Z$1 old and Z$1
new you'd need a precision capable of keeping track through 3+10+12 =
25 zeros, or amounts like

10,000,000,000,000,000,000,000,001

The precision of double-precision floats, 52-bit significand, is 2^52
= 4.5e15.  Just to store one new Z$.  If someone has ten new dollars
in their account you could no longer keep their account even in
double-precision floating point.  You would have needed quad-precision
(2^112 = 5.2e33), and banks weren't using that at the time even to do
calculations.  (I don't know what they use now, I'm not in the
industry.)



Banks still use, as they have for a very long time, Binary Coded 
Decimal, or some equivalent that does not suffer from a loss of 
accuracy, so all this foofaraw to do with floating point representation 
of various amounts of currency does not apply to the real world.


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Regarding CoC

[Gary R. Schmidt]

On 26/10/2018 14:12, Philip Warner wrote:

On 25/10/2018 9:59 PM, Mike King wrote:


I’m a good atheist but I love the CoC. Not bothered by the religious bits
but I get the sentiment. I guess it appeals to my British sense of irony
and odd sense of humour :)


I agree with the humour. As a satirical statement on the horrors of 
building a good CoC/CoE it is quite effective.


But...if it is a CoC/E, then I think it would be beneficial to have one 
that many people won't start by knowingly and deliberately ignoring 
large chunks, and broadly disagreeing with even more, and laughing at 
the rest.
Of course, after all, that's how christianity developed, by picking and 
choosing the various bits of whatever else was around that were in tune 
with the various prejudices and predilections of those involved.


Although the "laughing at the rest" was more often "kill them, and the 
horses they rode in on."


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite mailing list

[Gary R. Schmidt]

On 13/10/2018 16:28, Balaji Ramanathan wrote:

8. Re: sqlite-users Digest, Vol 130, Issue 11 (Shawn Wagner)

On Thu, 11 Oct 2018 09:51:15 -0500, Balaji Ramanathan <

balaji.ramanat...@gmail.com> wrote:


2. Re: SQLite mailing list



The 1990's called and they want their mailing lists back.  So, let us
switch to 21st century technology already.


And yet you read the digest! A very good way to be overwhelmed, one of
the good things about mailing lists that you can see everything
separately and only read the ones you are interested in. And you want
sub-forums, so we'll all have to go through each sub-forum looking for
things of interest.


 Well, if there is one thing that is more annoying than one email, it

is multiple emails.  If it weren't for the digest option, I probably
wouldn't be subscribed to the sqlite mailing list at all.  Emails are one
of the worst productivity killers ever invented, which is why every company
wants to move from emails, and will try practically anything else to try to
kill the beast.  Believe me, email is the bathwater that came with the
internet baby.

Just because you (and one or two others) can't manage email, those of us 
who have been successfully doing so for nigh-on four decades (or more) 
have to change everything?


No, I don't think so.

Fora, unless they supply threading, quoting, and off-line access, are 
the mouldy, poisoned, rotting, stinking underside of the WWW.


That's the thing about my email archive - I can access it without 
needing an active internet connection, and I don't have to do anything 
clever to update them, it just happens.


I can run "grep" over the files, I can use IMAP search tools, I can copy 
them onto anther storage media to take them with me when I know I will 
not be able to access them (not for just when the internet is 
unavailable, having a back-pocket full of everything when you are 
on-site and security requirements prevent external access is bloody 
useful!).


Companies want to move from email because idiot-level MBAs who haven't 
got the brains god gave to bastard geese in Ireland tell them that it 
will reduce their costs.  If they hired competent managers and 
structured their business units well they would already be reducing 
costs, but doing that requires too much of the rarest element in the 
universe: Common Sense.


Moving support to a fora won't stop me using SQLite, but I won't bother 
monitoring for problems or attempting to report them.  I'll just 
roll-back broken versions, and when a new version comes out, see if it 
fixes the problem.


Yes, I am a snarky, reactionary BOFH, and people have been asking me if 
my name is "Simon" since the middle of the 1980s.  ;-)


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite mailing list [was: SQLite Windows GUI alternative to Excel?]

[Gary R. Schmidt]

On 10/10/2018 22:20, Petite Abeille wrote:



[SNIP]

( Also, fwiw: please keep the mailing list, it's perfectly functional as is. )


Seconded.

It isn't broken, so please don't try and fix it.

Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite 3.24.0 Solaris 9 build failure

[Gary R. Schmidt]

On 2018-07-28 08:33, Andy Goth wrote:

SQLite 3.24.0 fails to build on Solaris 9 (a.k.a. Solaris 2.9) due to
not finding fchmod, fchown, readlink, lstat, usleep, struct timeval,
and gettimeofday.

To correct, do not #define _XOPEN_SOURCE.  There's already a check for
Mac OS X, so I would suggest extending the check to also exclude
Solaris 9 with something like the following:

#if !defined(_XOPEN_SOURCE) && !defined(__DARWIN__) && 
!defined(__APPLE) && \

!(defined(__sun) && defined(__SVR4))
#  define _XOPEN_SOURCE 600
#endif

This check isn't version-specific.  There doesn't appear to be a
guaranteed macro for that purpose.  Sun Studio offers macros like
_SunOS_5_9 (meaning Solaris 9), but gcc does not.  Though it's a bit
silly for me to obsess over versions since I don't know exactly which
versions of Solaris hide the relevant functions and structs if
_XOPEN_SOURCE is defined.  I only have access to Solaris 9, and by
"access" I mean I have a copy of /usr/include and such, not a computer
I can log in to.  Just enough to do a cross-compile, which succeeds
with the above change.

More investigation is needed to figure out how to make SQLite build
for Solaris 9 without breaking other Solaris/SunOS platforms.


For some time at $ORK I have been configuring with 
"--disable-readline"[1] and inserting the following lines into sqlite3.c 
as provided in the autoconf archive.


I don't recall which UNIX variant caused the need, or when, but the 
changes are applied across all my Linux and UNIX builds now.


   #include 
   #include 
   #include 

These changes, plus updating libz to a newer version, builds happily on 
Solaris 8, 9, 10, and 11.  As well as HP-UX 11.x and AIX 5.x to 7.x.


Cheers,
GaryB-)

1 - Yes, we could supply readline(), but $ORK decided not to do so 
before I arrived.

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Back on-line. Was: Mailing list shutting down...

[Gary R. Schmidt]

On 14/06/2018 23:05, Richard Hipp wrote:

On 6/13/18, Richard Hipp  wrote:

Unfortunately, I'm going to need to shut down this mailing list due to
robot harassment.  I am working to come up with a fix or an
alternative now


Mailing lists are now back on-line and once again accepting
subscriptions.  I have implemented measures to block the subscription
robots and to better log subscription activity to better detect future
mischief.

I consider this to be a stop-gap measure that will buy me some time to
implement and test a better log-term solution.  The current setup will
change.  But the temporary measure I implemented this morning do at
least get us back to a functional mailing list while work on the
improved solution proceeds.


That's nice.

Would you be willing to publish your fix to the mailman list so that 
others could make use of it?


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Mailing list shutting down...

[Gary R. Schmidt]

On 13/06/2018 21:42, Gary R. Schmidt wrote:

On 13/06/2018 21:22, Richard Hipp wrote:

Unfortunately, I'm going to need to shut down this mailing list due to
robot harassment.  I am working to come up with a fix or an
alternative now.  Your suggestions are welcomed.

This mailing list has operated for many years using GNU MailMan.
Unfortunately, that software is not able to cope with modern robot
spammers, even with the latest updates.  And the source code for
MailMan is sufficiently opaque that I am unable to work on it.

The most recent problem is that robots are visiting the subscription
page and entering innocent user's email addresses and names.  This
causes a confirmation email to be sent to that user.  If it were just
single confirmation email that the user could ignore, that would be
fine.  But apparently MailMan sends one email for each subscription
request.  The robots have figured this out and are putting in hundreds
of subscription requests for the same individual, apparently to harass
them.

I have already suspended new subscriptions.  Existing subscribers will
be able to continue using this list until I come up with a replacement
(or a fix to the current problem) but no new subscribers will be
accepted.

This is an increasing problem, and has been discussed on the Mailman 
mailing list recently, you should join them and see what mitigation 
strategies are available.



One is here: https://github.com/noabospam/abospam

Cheers,
GaryB-)


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Mailing list shutting down...

[Gary R. Schmidt]

On 14/06/2018 03:37, John Long wrote:

On Wed, 2018-06-13 at 21:42 +1000, Gary R. Schmidt wrote:



This is an increasing problem, and has been discussed on the Mailman
mailing list recently, you should join them and see what mitigation
strategies are available.


Well I'm sure he would like to, but subscriptions have probably been
suspended because of the attacks ;)


They haven't shut down access to the mailman lists, why would they do that?

If you're trying to be funny, don't give up your day job!

Cheers,
GaryB-)

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Mailing list shutting down...

[Gary R. Schmidt]

On 13/06/2018 21:22, Richard Hipp wrote:

Unfortunately, I'm going to need to shut down this mailing list due to
robot harassment.  I am working to come up with a fix or an
alternative now.  Your suggestions are welcomed.

This mailing list has operated for many years using GNU MailMan.
Unfortunately, that software is not able to cope with modern robot
spammers, even with the latest updates.  And the source code for
MailMan is sufficiently opaque that I am unable to work on it.

The most recent problem is that robots are visiting the subscription
page and entering innocent user's email addresses and names.  This
causes a confirmation email to be sent to that user.  If it were just
single confirmation email that the user could ignore, that would be
fine.  But apparently MailMan sends one email for each subscription
request.  The robots have figured this out and are putting in hundreds
of subscription requests for the same individual, apparently to harass
them.

I have already suspended new subscriptions.  Existing subscribers will
be able to continue using this list until I come up with a replacement
(or a fix to the current problem) but no new subscribers will be
accepted.

This is an increasing problem, and has been discussed on the Mailman 
mailing list recently, you should join them and see what mitigation 
strategies are available.


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] UTF8 and NUL

[Gary R. Schmidt]

On 27/01/2018 05:32, Peter Da Silva wrote:

On 1/26/18, 12:31 PM, "sqlite-users on behalf of J Decker" 
 wrote:

ctrl-z was end of file text character in DOS (wrote char 26; not FF)


DOS wasn't an operating system.
  
That will come as a surprise to the people who used DOS/360 and DOS/VSE 
and their various siblings.


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] UTF8 and NUL

[Gary R. Schmidt]

On 27/01/2018 00:55, Peter Da Silva wrote:

What is the goal of this discussion? Changing the string terminator SQLite 
uses? I think it's almost 50 years too late for that, but I'm sure that if 
Unicode and UTF8 had been a thing in 1970 then C would have selected FF as the 
string terminator.
But how would you differentiate EOF???  (Let me guess, 0.  :-) )


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Macro expansion of B0 on Linux PPC system

[Gary R. Schmidt]

On 19/12/2017 13:55, Richard Hipp wrote:

On 12/18/17, Lee, Greg  wrote:

I am still seeing the problem on Power 8 and others report the problem
persists on Power 9. Please see the spack github issue. I also attached a
configure/make output if that helps.


So, what you are saying, then, is that "B0" is a reserved word on
Power 8 and Power 9 systems, and can never be used as a local variable
name?

The "#define B0 0" etcetera have been in the terminal I/O include 
file(s) of UNIX systems since time immemorial.


I've just run up a quickie that shows the same problem on Solaris:
#include 
#include 

int fred(int me)
{
   int B0, B1;

   B0 = me;

   B1 = me / 2;

   printf("String B0 is: %d, %d\n", B0, B1);
}

$ cc -c a.c
"a.c", line 6: syntax error before or at: 0
"a.c", line 8: left operand must be modifiable lvalue: op "="
"a.c", line 10: undefined symbol: B1
cc: acomp failed for a.c

Same-same on SLES:
$ cc -c a.c
In file included from /usr/include/termios.h:39:0,
 from /usr/include/sys/termios.h:3,
 from a.c:2:
a.c: In function ???fred???:
a.c:6:8: error: expected identifier or ???(??? before numeric constant
int B0, B1;
^
a.c:8:7: error: lvalue required as left operand of assignment
B0 = me;
   ^
a.c:10:4: error: ???B1??? undeclared (first use in this function)
B1 = me / 2;
^
a.c:10:4: note: each undeclared identifier is reported only once for 
each function it appears in



Looks like something must be including file(s) on Linux PowerPC that 
isn't included on other systems.


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Macro expansion of B0 on Linux PPC system

[Gary R. Schmidt]

On 19/12/2017 13:55, Richard Hipp wrote:

On 12/18/17, Lee, Greg  wrote:

I am still seeing the problem on Power 8 and others report the problem
persists on Power 9. Please see the spack github issue. I also attached a
configure/make output if that helps.


So, what you are saying, then, is that "B0" is a reserved word on
Power 8 and Power 9 systems, and can never be used as a local variable
name?

The "#define B0 0" etcetera have been in the terminal I/O include 
file(s) of UNIX systems since time immemorial.


I've just run up a quickie that shows the same problem on Solaris:
#include 
#include 

int fred(int me)
{
   int B0, B1;

   B0 = me;

   B1 = me / 2;

   printf("String B0 is: %d, %d\n", B0, B1);
}

$ cc -c a.c
"a.c", line 6: syntax error before or at: 0
"a.c", line 8: left operand must be modifiable lvalue: op "="
"a.c", line 10: undefined symbol: B1
cc: acomp failed for a.c

Same-same on SLES:
$ cc -c a.c
In file included from /usr/include/termios.h:39:0,
 from /usr/include/sys/termios.h:3,
 from a.c:2:
a.c: In function ???fred???:
a.c:6:8: error: expected identifier or ???(??? before numeric constant
int B0, B1;
^
a.c:8:7: error: lvalue required as left operand of assignment
B0 = me;
   ^
a.c:10:4: error: ???B1??? undeclared (first use in this function)
B1 = me / 2;
^
a.c:10:4: note: each undeclared identifier is reported only once for 
each function it appears in



Looks like something must be including file(s) on Linux PowerPC that 
isn't included on other systems.


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Many ML emails going to GMail's SPAM

[Gary R. Schmidt]

On 22/11/2017 01:30, Richard Hipp wrote:

On 11/21/17, Paul Sanderson  wrote:

Coincidence!  I have just been in my gmail folder marking a load of SQLite
email as 'not spam'


I've been seeing mailing list emails go to spam for a while now.
Nothing has changed with MailMan.  I think what we are seeing is the
beginning of the end of email as a viable communication medium.

I really need to come up with an alternative to the mailing list.
Perhaps some kind of forum system.  Suggestions are welcomed.

There is nothing wrong with email - but there is an awful lot wrong with 
gnail and Google's ideas on how email is done.  (Not to mention Yahoo, 
but it seems that MS have the sense to leave the underpinnings of 
hotmail as they were.)


To put it simply - friends don't let friends use gmail.

Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Incompatibility into configure.ac

[Gary R. Schmidt]

On 05/04/2017 19:23, Richard Hipp wrote:

On 4/4/17, Jens Alfke  wrote:


The issue here seems to be that some scripts in the SQLite source
distribution are _implicitly_ assuming that the default shell is bash, or
else that ‘sh’ is an alias of bash. The best fix, IMHO, would be to make
those scripts explicitly invoke bash, using a shebang or whatever.



The deeper issue is that I do not have access to a machine that lacks
bash on which to test the modifications


Install ksh, link /bin/sh and /usr/bin/sh to it.

Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Incompatibility into configure.ac

[Gary R. Schmidt]

On 04/04/2017 23:20, Richard Hipp wrote:

On 4/4/17, Pavel Volkov  wrote:

The "+ =" operator works as you would expect in bash only.
And it causes an error in the Bourne shell, for example.


You have piqued my curiosity.  Who is still using Bourne shell instead
of the Bourne-again shell (bash)?  Bash has been with us now for like
three decades, right?


Anyone who is supporting Solaris/AIX/HP-UX or older systems.

Is SQLite going the way of "Sure it's portable, it works on Fedora Core 
*and* Ubuntu"???


Cheers,
GaryB-)
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users