Re: [sqlite] SQLite version 3.8.4 release schedule

[Klaas V]

| JN: "... the Cygwin VFS to behave the same as other UNIX'es"

Warning: Off topic: RTF* and Gnu's Not Unix 
Two answers from Cygwin's  FAQ

Q: What?
A The Cygwin tools are ports of the popular GNU development tools for Microsoft 
Windows. 
They run thanks to the Cygwin library which provides the POSIX system calls and 
environment 
these programs expect. 
Q ECCN?
A No. Cygwin source and binary are made publicly available and free of charge 
to download 
so Cygwin is provided under TSU/TSPA exemption. As a result, 
Cygwin does not require an ECCN number.

I interpret this as Cygwin *not* being "other UNIX". 
In an attempt to become on topic: SQLite is another library without ECCN.

Cordiali saluti | Kind regards | Vriendelijke groeten | Freundliche Grüsse,
Klaas `Z4us` V, freelance CIO / ICT-guru / SystemDeveloper-Analyst 


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

Re: [sqlite] SQLite version 3.8.4 release schedule

[Jan Nijtmans]

2014-03-06 22:02 GMT+01:00 Larry Brasfield :
> This makes Cygwin unique among all operating systems with which I am
> familiar having support for hierarchical filesystems.  Most importantly, if
> true, it would differ from Unixen.  I suggest that, in fact, bare
> filenames, (names without any prepended directory path components), ARE
> expected to be found in "the current directory" as that is known to any
> process.

But not in dlopen():
See:
  
Quoting:
If filename contains a slash ("/"), then it
is interpreted as a (relative or absolute) pathname.  Otherwise, the
dynamic linker searches for the library as follows (see ld.so(8) for
further details):

I want the dlopen() in the Cygwin VFS to behave the same as other UNIX'es.

Regards,
 Jan Nijtmans
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.4 release schedule

[Larry Brasfield]

Jan Nijtmans wrote, in part, re Cygwin :
*> *bare filenames are NOT expected to be found in the current directory

This makes Cygwin unique among all operating systems with which I am
familiar having support for hierarchical filesystems.  Most importantly, if
true, it would differ from Unixen.  I suggest that, in fact, bare
filenames, (names without any prepended directory path components), ARE
expected to be found in "the current directory" as that is known to any
process.  This is the way Unix has worked forever, and the way its
derivatives and inspirees all work.  Any other behavior will come as a
great surprise to most people.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.4 release schedule

[Jan Nijtmans]

2014-03-05 17:07 GMT+01:00 Richard Hipp :
> A number of bugs have recently been revealed in SQLite.  All are obscure.
> Nevertheless, we want to accelerate the release of version 3.8.4 in order
> to get the fixes in circulation.

Great, I'm looking forward to this!  One of the bugs recently
discovered was the handling of absolute paths in Cygwin. E.g.
when loading an extension
 
or when using "pragma database_list"
 

I don't think today's attempt in fixing this is a good idea:

Although it fixes the loading of extensions on Cygwin when
using absolute paths, it breaks it when using relative
paths (bare filenames are NOT expected to be found in
the current directory). My recommendation would be to
revert this, and - after the SQLite 3.8.4 release - start
handling that. So short before a new release it is more
risk than that it really helps. The Cygwin package of
3.8.4 will contain another (better IMHO) fix anyway.
There is no hurry in applying whatever fix upstream.

The MinGW 4.x enhancements works great!

Thanks!

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

Re: [sqlite] SQLite version 3.8.4 release schedule

[tonyp]

I noticed the message:

Enter SQL statements terminated with a ";"

was removed from the shell.  Is this supposed to be in the right direction 
when a red message is added to warn newbies to SQLite about working with 
in-memory database, yet they are assumed to know that SQL commands end with 
";", when up to now everybody (even seasoned SQLiters) had to be reminded 
about this?


My €0.02 


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

Re: [sqlite] SQLite version 3.8.4 release schedule

[Richard Hipp]

On Wed, Mar 5, 2014 at 12:53 PM, big stone  wrote:

>
> ==> Is it expected to have a big speed-up in index creation ?
>

Yes.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SQLite version 3.8.4 release schedule

[big stone]

Hello,

Comparing 3.8.3 to 3.8.4beta fo today :
- both compiled in  -o2 mode and running in ":memory:" ,
- on a windows pc.

Changes :
* 8% quicker on Recursive CTE
   (sudoku test of  http://www.sqlite.org/lang_with.html)
* 12% quicker on Index Creation over a 5M record table
(
ftp://ftp.fec.gov/FEC/Presidential_Map/2012/P0001/P0001-ALL.zip)

==> Is it expected to have a big speed-up in index creation ? Or is it
noise ?


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

[sqlite] SQLite version 3.8.4 release schedule

[Richard Hipp]

A number of bugs have recently been revealed in SQLite.  All are obscure.
Nevertheless, we want to accelerate the release of version 3.8.4 in order
to get the fixes in circulation.

To this end, SQLite version 3.8.4 should now be considered "in beta".
Amalgamation snapshots are now available on the download page (
http://www.sqlite.org/download.html) and will be updated regularly.
Preliminary documentation for 3.8.4 is available at
http://www.sqlite.org/draft with a change log at
http://www.sqlite.org/draft/releaselog/3_8_4.html that will also be updated
regularly. A status board (http://www.sqlite.org/checklists/3080400) is now
up and when it goes all-green, the release will occur.  The anticipated
beta period is about 7 to 10 days.

Please try out SQLite 3.8.4 beta in your applications and report any issues
found to this mailing list, or directly to me, as soon as possible.  If you
are able to report on performance differences (hopefully performance
*improvements*) then please do.

There are no significant new features in SQLite 3.8.4.  This will be
primarily a performance-enhancement and bug-fix release.

Thanks for your help.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users