Re: [sqlite] .timer command missing from CLI ?

On 17 Feb 2017, at 9:09pm, Scott Perry wrote: > In the future it would be most appreciated if problems with Apple's version > of SQLite were reported by Radar , doubly so > for pre-release versions of operating systems where the issues can be

Re: [sqlite] SQLite as a Delphi unit (was: SQLite Options)

@Clemmins; I'll read over that a bit more carefully, and see if there are any hints on HOW-TO in there. I'm using the free version of Berlin ATM, and when I win a small lottery, I'd love to upgrade as I REALLllly miss the code reformat functionality of previous versions. (Previous employer gave

Re: [sqlite] Thread safety of serialized mode

On Fri, Feb 17, 2017 at 6:58 PM, Jens Alfke wrote: > [from another email] > > It's why I like Go: it's the first language in 30 years to incorporate > > concurrency in its design, and finally support a theoretically sound > > model. > > Goroutines are still threads, and Go

Re: [sqlite] .timer command missing from CLI ?

On Feb 15, 2017, at 11:46 AM, Simon Slavin wrote: > On 15 Feb 2017, at 7:39pm, Richard Hipp wrote: >> Are you saying it is the one built into MacOS - not one you obtained >> from https://www.sqlite.org/download.html? If so, can you provide me >> with

Re: [sqlite] SQLite as a Delphi unit (was: SQLite Options)

Stephen Chrzanowski wrote: > Ever since I found SQLite3 and a decent wrapper that does exactly what I've > needed it to do, I've ALWAYS wanted to do a direct port of the Amalgamation > into a Delphi/Pascal unit so I can just include it and have the > functionality built in, period, built by the

Re: [sqlite] SQLite Options

Is SQLite Version 3 the same as SQLite3? ... http://www.sqlite.org/download.html. On Thu, Feb 16, 2017 at 3:01 PM, Simon Slavin wrote: > > On 16 Feb 2017, at 8:40pm, Clyde Eisenbeis wrote: > >> Is there an SQLite version that is comprised of fewer dlls,

Re: [sqlite] SQLite Options

System.Data.SQLite is the package you want if you just want a .Net style (i.e. Using the standard .net db interfaces) wrapper around SQLite. You can find it on NuGet. The entity framework is a library that maps database entries and relations to OOP style objects. Look up object relational

Re: [sqlite] SQLite Options

(A little bit off topic) On Fri, Feb 17, 2017 at 9:32 AM, R Smith wrote: > . though some wrappers exist for almost all programming languages and > they are relatively easy to use too - *but for brute speed and control, > use the API directly.* > Ever since I found

Re: [sqlite] Smallest reasonable cache size

Thanks for your responses! On Thu, Feb 16, 2017 at 8:56 PM, Dominique Pellé wrote: > > I think it's probably best to give a large cache_size to > each connection, and limit the total amount of memory > used by SQLite with sqlite3_soft_heap_limit64(). > This will

Re: [sqlite] SQLite as a Delphi unit (was: SQLite Options)

On 2017/02/17 5:17 PM, Stephen Chrzanowski wrote: (A little bit off topic) On Fri, Feb 17, 2017 at 9:32 AM, R Smith wrote: . though some wrappers exist for almost all programming languages and they are relatively easy to use too - *but for brute speed and control,

Re: [sqlite] Smallest reasonable cache size

On 2/17/17, Kim Gräsman wrote: > > Thanks, shrink_memory could come in handy. But this is not the problem > we're trying to solve -- rather we want to claim as much memory as possible > up-front to make mem usage deterministic and make it easier to diagnose > other

Re: [sqlite] Smallest reasonable cache size

Den 17 feb. 2017 5:33 em skrev "Richard Hipp" : On 2/17/17, Kim Gräsman wrote: > > If we let it use malloc directly and control it > with the soft heap limit, we'll have a steadily rising memory curve > until all caches are fully loaded (could take weeks.)

Re: [sqlite] Thread safety of serialized mode

> On Feb 17, 2017, at 3:48 AM, Simon Slavin wrote: > > It is insane that a CPU would allow two threads to interfere with each-other > in such a way as to 'break' an INC instruction. It may be insane to you, but it’s simply how multiprocessor computer architectures work,

Re: [sqlite] About the performance of recursive WITH

On 16/02/2017 15:34, Keith Medcalf wrote: H. With the current head of trunk ... I run this and the recursive version takes 93 milliseconds vs the iterative version which takes 203 milliseconds. Mystery solved. Now, I get realistic figures with sqlite.dll version 3.17 (resp. 0.012 and

Re: [sqlite] Thread safety of serialized mode

> On Feb 17, 2017, at 9:18 AM, James K. Lowden wrote: > > It's the OS. A thread is an OS abstraction, not a machine feature. You don’t need an OS to create threads. All you need is setjmp/longjmp or the equivalent. “Green” threads are more awkward to use than

Re: [sqlite] Thread safety of serialized mode

> On Feb 17, 2017, at 11:11 AM, Dominique Devienne wrote: > > No they are not. They may be scheduled on threads, but they are not threads. We're disagreeing on terminology, but I believe I’m correct. Threads don’t have to be implemented at the OS level. Threads

Re: [sqlite] SQLite Options

On Feb 17, 2017, at 7:32 AM, R Smith wrote: > > You can even checkout the latest commits via SVN There’s a Subversion mirror of the official Fossil code repository for SQLite? I tried to search the web for it, but since Subversion uses SQLite internally to manage its own

Re: [sqlite] SQLite Options

On 2017/02/18 12:45 AM, Warren Young wrote: On Feb 17, 2017, at 7:32 AM, R Smith wrote: You can even checkout the latest commits via SVN There’s a Subversion mirror of the official Fossil code repository for SQLite? Apologies, force of habit nomenclature. Have fallen

Re: [sqlite] SQLite Options

On 2017/02/17 4:11 PM, Clyde Eisenbeis wrote: Is SQLite Version 3 the same as SQLite3? ... http://www.sqlite.org/download.html. Yes. You have been using SQLite3 through a wrapper, a good one by the way, but the core API comes as a single C file which can be compiled into your program

Re: [sqlite] Thread safety of serialized mode

> On Feb 17, 2017, at 12:21 AM, Warren Young wrote: > > How can we expect people to write threaded programs when even a simple > integer increment is prone to race conditions and read-modify-write errors? "… we did not (and still do not) believe in the standard

Re: [sqlite] Smallest reasonable cache size

On 2/17/17, Kim Gräsman wrote: > > If we let it use malloc directly and control it > with the soft heap limit, we'll have a steadily rising memory curve > until all caches are fully loaded (could take weeks.) > Caches get flushed from time to time, for example when another

Re: [sqlite] Thread safety of serialized mode

On Fri, 17 Feb 2017 04:10:09 + Deon Brewis wrote: > If you look at the original underlying NT I/O architecture that > Cutler implemented - it is a thing of beauty that's based in async > patterns, and not threads. ... > If instead NT initially only exposed the Nt API's and

Re: [sqlite] Thread safety of serialized mode

On Thu, 16 Feb 2017 19:35:51 -0800 Jens Alfke wrote: > > On Feb 16, 2017, at 6:26 PM, James K. Lowden > > wrote: > > > > It doesn't change the fact that the OS has subverted the > > guarantees your language would otherwise provide, such as the > >

Re: [sqlite] Thread safety of serialized mode

Actually C# await on at least the file async IO operations will complete the await on the I/O completion port callback. It's absolutely sad that there is no C++ support for that as of yet, and the standards committee is nowhere near it. It got kicked out of C++ 17... again. MAYBE we'll have

Re: [sqlite] Thread safety of serialized mode

On Fri, Feb 17, 2017 at 5:10 AM, Deon Brewis wrote: > If you look at the original underlying NT I/O architecture that Cutler > implemented - it is a thing of beauty that's based in async patterns, and > not threads. > Thanks. That Cutler reference led me to

Re: [sqlite] About the performance of recursive WITH

Good news (CTE is a real jewel of SQLite)! Thanks Keith. My experiments were carried out with v16.2 through the CLI shell but I got the same results with older versions and with Python programs. Times were given by ".timer on". I will analyze the query plans (good exercise, never did this so

Re: [sqlite] Thread safety of serialized mode

On 2017-02-14 5:05 PM, Darren Duncan wrote: On 2017-02-14 4:46 PM, Richard Hipp wrote: This is yet another reason why I say "threads are evil". For whatever reason, programmers today think that "goto" and pointers and assert() are the causes of all errors, but threads are cool and healthful.

Re: [sqlite] Thread safety of serialized mode

Jens Alfke wrote: > A read-modify-write cycle on an address in main memory is intrinsically > _not_ atomic on a multiprocessor system, not unless the CPU goes through > some expensive efforts to make it so (cache invalidation, bus locking, > etc.) Most modern CPUs have caches, and any _normal_

Re: [sqlite] Thread safety of serialized mode

Bob Friesenhahn wrote: > Does anyone have an idea about this specific problem that we encountered? > > It is not clear to me if this is a threading issue, or memory corruption issue It's probably memory corruption causes by a threading issue. The original mail said: > Any thread may acquire and

Re: [sqlite] Thread safety of serialized mode

On 17 Feb 2017, at 8:54am, Clemens Ladisch wrote: > Bob Friesenhahn wrote: > >> Does anyone have an idea about this specific problem that we encountered? >> >> It is not clear to me if this is a threading issue, or memory corruption >> issue > > It's probably memory

Re: [sqlite] Thread safety of serialized mode

Jens Alfke wrote: > PS: I’m not aware of _any_ current CPUs that can increment main memory > in one instruction, atomically or not. X86(-64) has always had "INC [mem]" and "LOCK INC [mem]". And MSP430 calls itself RISC, but is so orthogonal that any operand can be in memory. Regards,

Re: [sqlite] Thread safety of serialized mode

On 17 Feb 2017, at 9:27am, Clemens Ladisch wrote: > X86(-64) has always had "INC [mem]" and "LOCK INC [mem]". It is insane that a CPU would allow two threads to interfere with each-other in such a way as to 'break' an INC instruction. But yes, we have drifted a long way

Re: [sqlite] Thread safety of serialized mode

The issue here (with the INC instruction) isn't 'Thread' but "Multi-Master/(Core)' On as single processor, the INC is atomic. When you have a possibility of multiple masters (or cores) access the same location, you need to be more careful, and that LOCK prefix due to what it needs to do to