Re: [sqlite] SQLite Options

2017-02-19 Thread Barry Smith 
Strange, I replied to this earlier... Perhaps my messages are not getting 
through.

You cannot include a .c file for compilation in a c# project. You'd have to do 
use a separate DLL and do some pinvoke stuff to get to the raw SQLite 
interface, but in my opinion you're better off using the system.data.sqlite 
wrapper. If you need the speed and power of the raw interface, you probably 
need to drop out of an interpreted and managed language (c#) too...

You don't need the entity framework (EF) to run system.data.sqlite. That is an 
object relational mapper (ORM) that uses a lot of fancy reflection to make data 
access a little easier* (until you get stung by it) and a lot slower. EF is 
developed my Microsoft, although SQLite must provide some input to make it work 
with its syntax. You should be able to remove the entity framework dependencies 
from your project and still compile with no issues. Try a complete rebuild / 
clean compile to try get rid of the unnecessary dlls.

*whether an ORM actually makes data access easier is debatable, they basically 
allow you to write your data access queries in LINQ rather than SQL, and 
automatically instansiate c# objects for each line in the results. I find SQL 
easier...

> On 19 Feb 2017, at 1:50 PM, Clyde Eisenbeis  wrote:
> 
> Sorry for the slow response.
> 
> My code is in C#.  I don't know if the amalgamation source code in C
> can be compiled so it is compatible with C#.
> 
> If it can, I'd be interested in details.  Thanks!
> 
>> On Sat, Feb 18, 2017 at 1:29 AM, R Smith  wrote:
>> 
>> 
>>> 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 to calling any Software
>> Versioning system just 'SVN' for short. I did of course mean for it to be
>> checked out via Fossil.
>> 
>>> https://goo.gl/KzLcV8
>>> 
>>> (Excuse the shortener, it’s a raly long URL.)
>>> 
>>> I could give you that Zip file link, but I suspect it’s purposely not
>>> being published to avoid load on the SQLite repository server caused by bots
>>> repeatedly requesting Zip files and tarballs.
>> 
>> 
>> The bots can read goo links nowadays. ;)
>> 
>>> Using Fossil is far more efficient than downloading Zip archives, but as I
>>> keep getting reminded in my own Fossil-hosted public project, some people
>>> just refuse to install and use anything they don’t absolutely have to.  It’s
>>> six easy steps, but apparently that’s too many for some.
>> 
>> 
>> Agreed, and what is more sad is that Fossil is so much better at actual
>> "Version-Control" (as opposed to making sharing code easiest). If we could
>> get the rest of the World to rather Fossil, everybody wins. (I can already
>> hear Linus clutching his chest and breathing erratically!)
>> 
>> 
>> 
>> ___
>> sqlite-users mailing list
>> sqlite-users@mailinglists.sqlite.org
>> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Thread safety of serialized mode

2017-02-19 Thread Rowan Worth 
On 18 February 2017 at 01:16, James K. Lowden 
wrote:

> 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.
>

I like Go too, but this is giving it a bit too much credit. What of Alef
and Limbo, which bore a similar concurrency model, and of which Go is
almost the spiritual successor? What of Clojure, which incorporates a
different concurrency model but is still theoretically sound (STM)? What of
Erlan- oh, Erlang *is* 30 years old :P

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

Re: [sqlite] Compile Windows dll with MinGW with stdcall calling convention?

2017-02-19 Thread Keith Medcalf 

Can you tell us how you do it with the amalgamation using MSVS?

> -Original Message-
> From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
> On Behalf Of Bart Smissaert
> Sent: Saturday, 18 February, 2017 09:35
> To: General Discussion of SQLite Database
> Subject: [sqlite] Compile Windows dll with MinGW with stdcall calling
> convention?
> 
> This is simple in MSVS, but can't see how this can be done with the MinGW
> compiler.
> Any idea how this can be done with the sqlite3.c amalgation?
> 
> RBS
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



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

Re: [sqlite] Compile Windows dll with MinGW with stdcall calling convention?

2017-02-19 Thread Bart Smissaert 
I think that something like this should work:

gcc -o SQLite3_StdCall.dll -shared sqlite3.c -s -Wl,--subsystem,windows,--
kill-at

It does compile, but I for some reason I can't access the .dll from VB6.
I had a look at the name mangling and corrected for that, but still no luck.
Maybe best to stick with MSVS.

RBS


On Sun, Feb 19, 2017 at 4:00 PM, Cezary H. Noweta 
wrote:

> Hello,
>
> On 2017-02-18 17:35, Bart Smissaert wrote:
>
>> This is simple in MSVS, but can't see how this can be done with the MinGW
>> compiler.
>> Any idea how this can be done with the sqlite3.c amalgation?
>>
>
> I have just tried ``CFLAGS=-mrtd -DSQLITE_CDECL=__cdecl'' option on
> different compilers and configurations, but without a success. :-(
> ``-mrtd'' is not working as good as MSVS' ``-Gz''.
>
> -- best regards
>
> Cezary H. Noweta
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite Options

2017-02-19 Thread Clyde Eisenbeis 
Sorry for the slow response.

My code is in C#.  I don't know if the amalgamation source code in C
can be compiled so it is compatible with C#.

If it can, I'd be interested in details.  Thanks!

On Sat, Feb 18, 2017 at 1:29 AM, R Smith  wrote:
>
>
> 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 to calling any Software
> Versioning system just 'SVN' for short. I did of course mean for it to be
> checked out via Fossil.
>
>>  https://goo.gl/KzLcV8
>>
>> (Excuse the shortener, it’s a raly long URL.)
>>
>> I could give you that Zip file link, but I suspect it’s purposely not
>> being published to avoid load on the SQLite repository server caused by bots
>> repeatedly requesting Zip files and tarballs.
>
>
> The bots can read goo links nowadays. ;)
>
>> Using Fossil is far more efficient than downloading Zip archives, but as I
>> keep getting reminded in my own Fossil-hosted public project, some people
>> just refuse to install and use anything they don’t absolutely have to.  It’s
>> six easy steps, but apparently that’s too many for some.
>
>
> Agreed, and what is more sad is that Fossil is so much better at actual
> "Version-Control" (as opposed to making sharing code easiest). If we could
> get the rest of the World to rather Fossil, everybody wins. (I can already
> hear Linus clutching his chest and breathing erratically!)
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Compile Windows dll with MinGW with stdcall calling convention?

2017-02-19 Thread Cezary H. Noweta 

Hello,

On 2017-02-18 17:35, Bart Smissaert wrote:

This is simple in MSVS, but can't see how this can be done with the MinGW
compiler.
Any idea how this can be done with the sqlite3.c amalgation?


I have just tried ``CFLAGS=-mrtd -DSQLITE_CDECL=__cdecl'' option on 
different compilers and configurations, but without a success. :-( 
``-mrtd'' is not working as good as MSVS' ``-Gz''.


-- best regards

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

Re: [sqlite] Problem compiling 3.17.0 in MSVS 12

2017-02-19 Thread Bart Smissaert 
Just to update on this.
I fixed it by getting the MSVS solution setup from the other PC and replace
the one that had the problem.
This was to do with some faulty setting in the solution setup, not sure
which one.
So, it had not do with a corrupted MSVS application and also not with a
messed up source file, sqlite3.c.

RBS

On Wed, Feb 15, 2017 at 3:36 AM, Kevin Benson 
wrote:

> On Tue, Feb 14, 2017 at 7:56 PM, Bart Smissaert 
> wrote:
>
> > I had to install WinZip though and at the first unzip I got directly to
> the
> > files whereas now I had a .tar file first and had to unzip that.
> >
>
> Following on from David Empson's post... the WinZip docs show an
> Advanced->File handling option named  that
> likely facilitated your .TAR file attempt:
> http://kb.winzip.com/help/HELP_CONFIG_MISC.htm
> --
>--
>   --
>  --Ö¿Ö--
> K e V i N
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Smallest reasonable cache size

2017-02-19 Thread Kim Gräsman 
On Fri, Feb 17, 2017 at 8:37 PM, Richard Hipp  wrote:
> 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 subsystems with run-away memory usage.
>
> In that case, consider using MEMSYS5
> (https://www.sqlite.org/malloc.html#experimental_memory_allocators).
> You give SQLite a single big chunk of RAM up front, and that is all
> the memory it will ever use.  And it won't share any of it with any
> other subsystems.

As I've said earlier, we don't want to risk SQLITE_NOMEM.

But if we can combine sqlite_soft_heap_limit64 with
SQLITE_CONFIG_HEAP, that might give us a nice self-adjusting system
(where caches are flushed when heap is running low) in the rare cases
that this might happen.

Do the two play nice together? I guess the challenge is to find a good
number for the limit, but we can afford to "waste" some memory to play
it safe here.

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