Re: [sqlite] how to pass -Dxxx compile option
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
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
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 ...
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
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
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
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
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?
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?
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?
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
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
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
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
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
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
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
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
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?]
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
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...
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...
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...
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...
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
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
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
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
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
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
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
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
