[sqlite] editline/readline.h' file not found

[jungle Boogie]

Hello All,

Is anyone else getting this strange fatal error when building sqlite
from source:

touch .target_source
tclsh8.6 /home/jungle/fossil-repos/sqlite3/tool/mksqlite3c.tcl
cp tsrc/shell.c tsrc/sqlite3ext.h .
./libtool --mode=compile --tag=CC cc -g -O2 -DSQLITE_OS_UNIX=1 -I.
-I/home/jungle/fossil-repos/sqlite3/src
-I/home/jungle/fossil-repos/sqlite3/ext/rtree
-I/home/jungle/fossil-repos/sqlite3/ext/fts3 -D_HAVE_SQLITE_CONFIG_H
-DBUILD_sqlite -DNDEBUG -I/usr/local/include/tcl8.6
-DSQLITE_THREADSAFE=1-DSQLITE_TEMP_STORE=1 -c sqlite3.c
libtool: compile:  cc -g -O2 -DSQLITE_OS_UNIX=1 -I.
-I/home/jungle/fossil-repos/sqlite3/src
-I/home/jungle/fossil-repos/sqlite3/ext/rtree
-I/home/jungle/fossil-repos/sqlite3/ext/fts3 -D_HAVE_SQLITE_CONFIG_H
-DBUILD_sqlite -DNDEBUG -I/usr/local/include/tcl8.6
-DSQLITE_THREADSAFE=1 -DSQLITE_TEMP_STORE=1 -c sqlite3.c -o sqlite3.o
./libtool --mode=link cc -g -O2 -DSQLITE_OS_UNIX=1 -I.
-I/home/jungle/fossil-repos/sqlite3/src
-I/home/jungle/fossil-repos/sqlite3/ext/rtree
-I/home/jungle/fossil-repos/sqlite3/ext/fts3 -D_HAVE_SQLITE_CONFIG_H
-DBUILD_sqlite -DNDEBUG -I/usr/local/include/tcl8.6
-DSQLITE_THREADSAFE=1  -no-undefined -o libsqlite3.la sqlite3.lo
-lpthread -rpath "/usr/local/lib" -version-info "8:6:8"
libtool: link: ar cru .libs/libsqlite3.a  sqlite3.o
libtool: link: ranlib .libs/libsqlite3.a
libtool: link: ( cd ".libs" && rm -f "libsqlite3.la" && ln -s
"../libsqlite3.la" "libsqlite3.la" )
./libtool --mode=link cc -g -O2 -DSQLITE_OS_UNIX=1 -I.
-I/home/jungle/fossil-repos/sqlite3/src
-I/home/jungle/fossil-repos/sqlite3/ext/rtree
-I/home/jungle/fossil-repos/sqlite3/ext/fts3 -D_HAVE_SQLITE_CONFIG_H
-DBUILD_sqlite -DNDEBUG -I/usr/local/include/tcl8.6
-DSQLITE_THREADSAFE=1  -DHAVE_READLINE=0 -DHAVE_EDITLINE=1
-DSQLITE_ENABLE_JSON1 -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS5 -o
sqlite3  /home/jungle/fossil-repos/sqlite3/src/shell.c libsqlite3.la
-ledit -lpthread   -rpath "/usr/local/lib"
libtool: link: cc -g -O2 -DSQLITE_OS_UNIX=1 -I.
-I/home/jungle/fossil-repos/sqlite3/src
-I/home/jungle/fossil-repos/sqlite3/ext/rtree
-I/home/jungle/fossil-repos/sqlite3/ext/fts3 -D_HAVE_SQLITE_CONFIG_H
-DBUILD_sqlite -DNDEBUG -I/usr/local/include/tcl8.6
-DSQLITE_THREADSAFE=1 -DHAVE_READLINE=0 -DHAVE_EDITLINE=1
-DSQLITE_ENABLE_JSON1 -DSQLITE_ENABLE_FTS4 -DSQLITE_ENABLE_FTS5 -o
sqlite3 /home/jungle/fossil-repos/sqlite3/src/shell.c
./.libs/libsqlite3.a -ledit -lpthread -Wl,-rpath -Wl,/usr/local/lib
/home/jungle/fossil-repos/sqlite3/src/shell.c:71:11: fatal error:
'editline/readline.h' file not found
# include 
  ^
1 error generated.
*** Error code 1

Stop.
make: stopped in /usr/home/jungle/fossil-repos/sqlite3


-- 
---
inum: 883510009027723
sip: jungleboogie at sip2sip.info
xmpp: jungle-boogie at jit.si

[sqlite] A little light reading

[R Smith]

On 2015/11/08 6:11 PM, John McKown wrote:
> I'm not a developer. So I guess that it's my ignorance as to why a program
> would be confused by the string value of "null" or any variant thereof. I
> do understand looking for a string of length 0. If I were to want a special
> name for Some purpose, I'd likely use xyzzy. I thought of plugh as well,
> but a search turned up a article by a Mike Plugh.

Not your ignorance at all - there should never be a confusion if proper 
diligence was applied (the kind everybody learns in stage 1 of any 
education in programming).  The reason mr. Null has any discomfort is 
due to poor system design. SQL engines of any sort (for instance) have 
no problem whatsoever with strings containing the value "Null" or "null" 
or some such.

In other data formats, such as JSON etc. it is impossible to mistake the 
name Null for the value null.

The entire problem can be summed up in two words: Lazy devs.

[sqlite] A little light reading

[Stephan Beal]

On Sun, Nov 8, 2015 at 5:11 PM, John McKown 
wrote:

> I'm not a developer. So I guess that it's my ignorance as to why a program
> would be confused by the string value of "null" or any variant thereof.


Consider this XML snippet, which very likely passes through some of the
apps Mr. Null has been processed by (or failed to be processed by, as the
case may be):

Null

i've seen careless apps which would consider that to be a "program NULL" as
opposed to the string "Null".

I do understand looking for a string of length 0.
>

depending on the language/environment, an empty string is of type _string_
with a length of 0, whereas null is of a separate type called null. More
commonly, null/NULL is generic placeholder which can be used together with
references of any concrete type, but (when used with a string-typed
reference) never has a length property (whereas an empty string does). In
type-flexible languages, one typically cannot have a "null string," but
instead can have _either_ a string or a null value. In C++, one can have a
string-typed pointer to NULL, which is basically (because it keeps its data
type) a "null string," but still doesn't have a length (which is subtly
different than having a length of 0, even though the semantics are
identical for many purposes).

i can see why some systems have a problem with "Null," but in order to have
such problems i would argue that someone wasn't paying attention in the
design and/or implementation.

That poor guy.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf

[sqlite] A little light reading

[Simon Slavin]

On 8 Nov 2015, at 4:11pm, John McKown  wrote:

> I'm not a developer. So I guess that it's my ignorance as to why a program
> would be confused by the string value of "null" or any variant thereof.

NULL has a special meaning in SQL and some other database languages.  Depending 
on what the programmer wanted at the time it means something like "Value 
unknown" or "No such value" or "Not applicable".  All such programs are meant 
to keep an extremely clear distinction between these two:

surname = "Null"
surname = NULL

But fast, lazy, untested programs, especially cases where a working setup is 
moved to another language or another platform by someone who doesn't understand 
picky details of the original tend to mess this up.  Much more often than you'd 
think.

Many languages have documentation specifically on the problems of handling 
NULLs. Here's part of SQLite's:



Simon.

[sqlite] A little light reading

[Bernardo Sulzbach]

On Sun, Nov 8, 2015 at 1:25 PM, Nicolas J?ger  
wrote:
>
> reminds me when, because of some "idiots database programmers", I got (during 
> the same month) three
> cards automatically from the health care system with three times my name 
> wrongly printed (because of
> the "?"). Of course having more than one card like this is illegal...
>

Did you sent the cards back? Can't you use a "plain" a for legal purposes?

-- 
Bernardo Sulzbach

[sqlite] A little light reading

[Luca Olivetti]

El 08/11/15 a les 11:55, Simon Slavin ha escrit:
> An article by Christopher Null on how database programmers are idiots.
>
> Come to think of it, if you stare at the above line for long enough you won't 
> need the article.  But here it is anyway:
>
> 

Obligatory xkcd reference

https://xkcd.com/327/

SCNR


Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007

[sqlite] A little light reading

[Bernardo Sulzbach]

On Sun, Nov 8, 2015 at 2:42 PM, John McKown
 wrote:
> (...) What if the person is alive? What if you don't now the birth day?).

NULLs, as you mentioned, are questioned in many domains. They provide
an easy solution, but never the only one there is. In an OOP system,
for instance, LivingPerson and DeadPerson may be two different classes
and have different properties. In a RDBS, a table could store the
people that have not died yet. Or you could use strings of the form
"-" and have some "1995-02-11-" strings for the ones still
living. But there is a "semantic" nullity there if you think about it.

-- 
Bernardo Sulzbach

[sqlite] Minor errors in the documentation, building sqlite

[Zsbán Ambrus]

Hello.  In this mail I'd like to point out some minor problems with
the SQLite documentation.  (By the way, let me thank you for adding
named anchors to every heading in the docs so I can link to them
easily.  A lot of webpages don't do this.)

1. In Compilation Options For SQLite "http://sqlite.org/compile.html";,
under HAVE_MALLOC_USABLE_SIZE, "Apply systems" is probably a typo for
"Apple systems".  Please fix it, because it's confusing.  If it does
not mean Apple systems, then please clarify in the text what it means.

2. In the same document, in chapter 1.7, this sentence is confusing:
"Any SQLITE_OMIT_* options which can be used directly with the
amalgamation are listed below, however, the warnings in the following
paragraph should be noted."  The document should either explain which
of the omit options can be used with the amalgamation, or explicitly
tell that the "http://sqlite.org/howtocompile.html"; document (that
this sentence links to) tells which options can't be used with the
amalgamation.  As a fix, I suggest you replace that paragraph and the
following one with this.

Important Note: The SQLITE_OMIT_* options do
not work with the amalgamation.
SQLITE_OMIT_* compile-time options only work correctly when SQLite is
built from canonical source files.
If any of these options are defined, then the same set of
SQLITE_OMIT_* options must also be defined when using the 'lemon' tool
to generate the parse.c file and when compiling the 'mkkeywordhash'
tool which generates the keywordhash.h file. Because of this, some of
these options may only be used when the library is built from
canonical source, not from the amalgamation, nor from the collection
of pre-packaged C files provided on the website to build older
versions of SQLite for non-Unix like platforms.  http://sqlite.org/howtocompile.html";>How To Compile SQLite
lists the options that can't be used directly with the amalgamation.

3. There's something of a contradiction between the reference
Compilation Options For SQLite "http://sqlite.org/compile.html"; and
the introductory document How To Compile SQLite
"http://sqlite.org/howtocompile.html#cli";.  The former document says
that "All of the SQLITE_OMIT_* options are unsupported".  The latter
document, which describes the easiest ways to build SQLite, however,
says "If these features are not required, then they can be omitted
using SQLITE_OMIT_LOAD_EXTENSION compile-time option" without
mentioning that the option is unsupported.  Either something in the
former should claim that the SQLITE_OMIT_LOAD_EXTENSION option is
supported as an exception, or the latter document should not mention
this option or should mention it only with a note that it's
unsupported.  Marking this compilation option as supported would be
preferable if you take the claims of SQLite Is Self-Contained
"http://sqlite.org/selfcontained.html"; seriously, since that document
says "SQLite is written in ANSI-C and should be easily compiled by any
standard C compiler. It makes minimal use of the standard C library".

4. The permuted index
"http://www.sqlite.org/draft/sitemap.html#pindex"; has several entries
starting with "SQLite".  Most of those are superfluous, because the
whole index is about SQLite documentation only.  I think you should
remove most of them.  Keep "SQLite As An Application File Format",
"SQLite Consortium", "SQLite In 5 Minutes Or Less" (unless you add an
index entry at "5 Minutes" instead), "SQLite Is Self-Contained",
"SQLite Is Serverless", "SQLite Is Transactional".  Make sure every
entry you remove has an entry elsewhere in the permuted index.

-

The following minor problems with the documentation are repeats from
older mails I sent.

5. Something in the documentation should say explicitly that you're
not allowed to use parameters (placeholders) in expressions where the
expression itself would be stored in the schema.  Recent versions of
SQLite seem to enforce this in all the cases I've tested, but
"http://www.sqlite.org/draft/lang_expr.html#varparam"; doesn't mention
it.

6. There are some typos on the documentation page for SQLite Result
codes "http://sqlite.org/rescode.html";.

Under the heading "(1038) SQLITE_CANTOPEN_CONVPATH", the paragraph
talks about the error code "SQLITE_CANTOPEN_SEEK".  That constant does
not exist.  The text probably means "SQLITE_CANTOPEN_CONVPATH"
instead.

Similarly, under the heading "(6410) SQLITE_IOERR_GETTEMPPATH" and
"() SQLITE_IOERR_CONVPATH", the text mentions "SQLITE_IOERR_SEEK"
which is an existing error code, but is probably not the one meant.

The meaning of several error codes are also not documented on this
page, such as those of SQLITE_ABORT, SQLITE_CANTOPEN, SQLITE_EMPTY,
SQLITE_FORMAT, SQLITE_IOERR, SQLITE_MISMATCH,  SQLITE_IOERR_READ,
SQLITE_IOERR_WRITE, etc.  This may not be a bug. The sqlite3.h header
file has short comments next to each primary error code at least.

7. The Indexes On Expressions "http://sqlite.org/draft/expridx.html";
document should

[sqlite] A little light reading

[Nicolas Jäger]

On Sun, Nov 8, 2015 at 15:28:06 -0200,
Bernardo Sulzbach  wrote :

> On Sun, Nov 8, 2015 at 1:25 PM, Nicolas J?ger  
> wrote:
> >
> > reminds me when, because of some "idiots database programmers", I got 
> > (during the same month)
> > three cards automatically from the health care system with three times my 
> > name wrongly printed
> > (because of the "?"). Of course having more than one card like this is 
> > illegal...
> >  
> 
> Did you sent the cards back? Can't you use a "plain" a for legal purposes?
> 

actually, luckily I never had to use any of those cards... but the point is, 
Null complains
about is name, I understand that, but he seems to forget people with 
non-latin-1 name knows problem
too... even in their own country...

regards,
Nicolas

[sqlite] A little light reading

[Simon Slavin]

An article by Christopher Null on how database programmers are idiots.

Come to think of it, if you stare at the above line for long enough you won't 
need the article.  But here it is anyway:



Simon.

[sqlite] A little light reading

[John McKown]

On Sun, Nov 8, 2015 at 10:36 AM, Simon Slavin  wrote:

>
> On 8 Nov 2015, at 4:11pm, John McKown 
> wrote:
>
> > I'm not a developer. So I guess that it's my ignorance as to why a
> program
> > would be confused by the string value of "null" or any variant thereof.
>
> NULL has a special meaning in SQL and some other database languages.
> Depending on what the programmer wanted at the time it means something like
> "Value unknown" or "No such value" or "Not applicable".  All such programs
> are meant to keep an extremely clear distinction between these two:
>
> surname = "Null"
> surname = NULL
>
> But fast, lazy, untested programs, especially cases where a working setup
> is moved to another language or another platform by someone who doesn't
> understand picky details of the original tend to mess this up.  Much more
> often than you'd think.
>
> Many languages have documentation specifically on the problems of handling
> NULLs. Here's part of SQLite's:
>
> 
>

?I am, at least somewhat, aware of the problems with NULL in SQL (and Java
& C in which I "dabble"). I have read a number of Joe Celko's books. And
have formed the opinion that NULLs are anathema from the problems that they
introduce. But, then again, I do understand the need (i.e. a "person"
record which records a birth date and a death date. What if the person is
alive? What if you don't now the birth day?). ?

-- 

Schrodinger's backup: The condition of any backup is unknown until a
restore is attempted.

Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be.

He's about as useful as a wax frying pan.

10 to the 12th power microphones = 1 Megaphone

Maranatha! <><
John McKown

[sqlite] A little light reading

[Nicolas Jäger]

hi,

> An article by Christopher Null on how database programmers are idiots.
> 
> Come to think of it, if you stare at the above line for long enough you won't 
> need the article.
> But here it is anyway:
> 
> 
> 
> Simon.

reminds me when, because of some "idiots database programmers", I got (during 
the same month) three
cards automatically from the health care system with three times my name 
wrongly printed (because of
the "?"). Of course having more than one card like this is illegal...


Anyway, thx for that article, I'll try to think about that in the future.

regards,
Nicolas

[sqlite] Problem with sqldiff

[John G]

Richard
Thanks. That gives me what I would expect.

John Gillespie

sqlite-src-30902T 573 % ./sqldiff z1.db z2.db
ALTER TABLE A ADD COLUMN category;
UPDATE A SET category='' WHERE rowid=1;
UPDATE A SET category='' WHERE rowid=2;
UPDATE A SET category='' WHERE rowid=3;

On 7 November 2015 at 18:37, Richard Hipp  wrote:

> On 11/7/15, John G  wrote:
> > I saw sqldiff mentioned and decided to try it (compiled from
> > sqlite-src-3090200) and got an SQL error.
> >
>
> Please try the latest trunk version
> (https://www.sqlite.org/src/artifact/37ab2cd4f0c8b4f0) and let us know
> if that fails to solve your problem.
>
> --
> D. Richard Hipp
> drh at sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

[sqlite] A little light reading

[John McKown]

I'm not a developer. So I guess that it's my ignorance as to why a program
would be confused by the string value of "null" or any variant thereof. I
do understand looking for a string of length 0. If I were to want a special
name for Some purpose, I'd likely use xyzzy. I thought of plugh as well,
but a search turned up a article by a Mike Plugh.

I also  won't disclose the strange problem I saw for Mr. John Doe and his
wife Jane in some code.
On Nov 8, 2015 04:56, "Simon Slavin"  wrote:

> An article by Christopher Null on how database programmers are idiots.
>
> Come to think of it, if you stare at the above line for long enough you
> won't need the article.  But here it is anyway:
>
> 
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>