TL;DR: I believe all lua_gc() calls stemmed from misunderstanding lua
documentation, and the current settings seem potentially dangerous.

First, let me rely on lua 5.1 docs, as luajit 2 is documented to have
done only minor changes in the GC.
http://www.lua.org/manual/5.1/manual.html#lua_gc
http://wiki.luajit.org/New-Garbage-Collector#rationale

Commit 5a709411 claims to have increased the speed of GC to 400 % of
speed of allocation, but LUA_GCSETSTEPMUL is the parameter that
controls that, and that one was lowered to 99 % and later in
0ee2d1d7 even to 50 %.  Documentation explicitly says that setting
the value under 100 % may cause problems.

The default values seem perfectly sane to me and currently I can't see
any particular reason to change them.  It's 200 % relative GC speed,
and waiting for allocated size to double before starting another cycle.

I assume the resulting possibility of GC being too slow caused the need
to explicitly force a non-incremental GC cycle once in a while, but
that seems not useful anymore and not good for latency.

trust anchor fixes

Closes #151

See merge request !193

- Remove abstraction of the refresh callback, as we always use the same
  function.  This way the code is significantly easier to understand.
- Add a couple more comments.

It was strange to keep it indefinitely, and the code was already
half-prepared for this change.  Theoretically, if a resolver has been
stopped for too long to miss a key's period of Revoked status, it would
continue to trust the key forever.

- The description was very misleading (far from reality).
- The removed condition in rrcache was bogus.

- printing refresh time in milliseconds could've been confusing;
- move syntactic sugar definitions close to the rest of the table;

... via trust_anchors.{bootstrap_url,bootstrap_ca}

- docs: fix cache.current_* since long ago d5272b4b
- don't allow "cache.foo = 'bar'" for abitrary foo
- restore cache['nic.cz'] after b31bad2ccf while not breaking completion
- #cache won't work on lua 5.1, so remove it

Fix -k argument processing to avoid out-of-bounds memory accesses

See merge request !195

Mangling of keyfile_dir and allocation of keyfile_path led to rare
crashes (and Valgrind complaints).

The error was introduced in 21f3a6b9.

The FD leak happened only when we exit the process, but still...

Added client (kresc) for interacting with daemon using command prompt with history and tab-completion

See merge request !177

Vladimír Čunát authored 8 years ago and Štěpán Balážik committed 8 years ago

This might help if the lua command returns an unexpected number of
arguments.

Vladimír Čunát authored 8 years ago and Štěpán Balážik committed 8 years ago

That's to allow tunnelling the TTY to a different endian.

Vladimír Čunát authored 8 years ago and Štěpán Balážik committed 8 years ago

It was possible to write past the end of the buffer, if very unlucky.

Vladimír Čunát authored 8 years ago and Štěpán Balážik committed 8 years ago

The build system is prepared for libedit.

Vladimír Čunát authored 8 years ago and Štěpán Balážik committed 8 years ago

... via "__binary" pseudocommand

Vladimír Čunát authored 8 years ago and Štěpán Balážik committed 8 years ago

That will allow us to discover the top-level symbols for completion.
For others we can e.g.: for n in pairs(net) do print(n); end
I must admit I fail to understand some of the related lua magic.

The theme is no longer included in newer Sphinx versions,
so some systems (at least) will require specifying it explicitly.
(The docs refuse to build without it.)

Closes #101.

Final 1.2.1 changelog update

See merge request !189