| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Backport of 1f93e4f78c53
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The JSON Schema specification says that schemas are objects or booleans,
and that the 'type' property is optional and can be an array.
This module previously allowed bare type names as schemas and did not
really handle booleans.
It now handles missing 'type' properties and boolean 'true' as a schema.
Objects and arrays are guessed based on the presence of 'properties' or
'items' field.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MattJ reported a curious issue where validation did not work as
expected. Primarily that the "type" field was expected to be mandatory,
and thus leaving it out would result in no checks being performed.
This was likely caused by misreading during initial development.
Spent some time testing against
https://github.com/json-schema-org/JSON-Schema-Test-Suite.git and
discovered a multitude of issues, far too many to bother splitting into
separate commits.
More than half of them fail. Many because of features not implemented,
which have been marked NYI. For example, some require deep comparisons
e.g. when objects or arrays are present in enums fields.
Some because of quirks with how Lua differs from JavaScript, e.g. no
distinct array or object types. Tests involving fractional floating
point numbers. We're definitely not going to follow references to remote
resources. Or deal with UTF-16 sillyness. One test asserted that 1.0 is
an integer, where Lua 5.3+ will disagree.
|
| |
|
|
|
|
| |
Fixes #1753
Not known to be used anywhere
|
| |
|
|
|
|
|
| |
The type checks, they do nothing!
Observed: Tasks that were supposed to run weekly or daily were running
each hour.
|
| |
|
|
|
|
| |
Words, sometimes I wonder how they even work
Maybe I missed something.
|
| |
|
|
| |
Might be better than select(), more portable than epoll.
|
| |
|
|
| |
Could he handy to know for debugging or decisions
|
| |
|
|
|
|
| |
This one takes a stanza as input
Roughly based on util.interpolation
|
| |
|
|
|
|
|
|
|
| |
If the timer activates a bit early then a task might be just a few
seconds short of being allowed to run. This would run such a task rather
than wait another hour.
The value 0.5% chosen so that a weekly task does not run an entire hour
earlier than last time.
|
| |
|
|
| |
Allows reuse of repetitive definitions in schemas.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
There was an off-by-one in the modulo calculation. Switching to a plain
old array-table makes the apparent size of the queue wrong, but since
some of the queue may not be available this is likely for the best.
|
| | |
|
| |
|
|
|
|
|
|
| |
Meant to be used in mod_smacks for XEP-0198
Meant to have a larger virtual size than actual number of items stored,
on the theory that in most cases, the excess will be acked before needed
for a resumption event.
|
| | |
|
| |
|
|
|
| |
Makes it more generic so new periods (e.g. weekly etc) can be added
easily.
|
| | |
|
| |
|
|
|
|
| |
Eventually the goal is to have daily tasks run while there is little
activity, but that will vary with the server and the usage patterns of
its users. This is a start anyway.
|
| |
|
|
|
|
| |
A number of modules now have periodic tasks that need to run, e.g. for
cleaning out old messages or files. This has highlighted a need for
coordinating and optimizing scheduling of such tasks.
|
| |
|
|
| |
Helps when writing modules in Teal
|
| |
|
|
|
| |
Useful for disabling certain behavior, ANSI colors etc when not
connected to a terminal.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Since there is no way to distinguish an empty such array from a
zero-length array. Dropping it seems like the least annoying thing to
do.
|
| |
|
|
|
|
| |
Turns falsy values into nil instead of nothing, which ensures this
function always has 1 return value, or table.insert({}) complains. Would
still happen on some unexpected input, but that's actually a good thing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So the problem is that xmlns is not inherited when building a stanza,
and then :get_child(n, ns) with an explicit namespace does not find that
such child tags.
E.g.
local t = st.stanza("foo", { xmlns = "urn:example:bar" })
:text_tag("hello", "world");
assert(t:get_child("hello", "urn:example:bar"), "This fails");
Meanwhile, during parsing (util.xmppstream or util.xml) child tags do
get the parents xmlns when not overriding them.
Thus, in the above example, if the stanza is passed trough
`t = util.xml.parse(tostring(t))` then the assert succeeds.
This change makes it so that it leaves out the namespace argument to
:get_child when it is the same as the current/parent namespace, which
behaves the same for both built and parsed stanzas.
|
| |
|
|
| |
Since this was the last severely duplicated code left.
|
| | |
|
| |
|
|
| |
Turns out the unreachable error is reachable :D
|
| |
|
|
|
|
|
|
|
| |
Relevant commits:
* 6a51749af7f4
* 0e00fa518688
* d1982b7eb00d
* c098d07e6717
* 348b191cd850
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
So extract_value() takes an XML tag and details about which part we're
interested in and returns that.
Factoring this out will help with array implementation since this will
be common behavior.
|
| |
|
|
| |
Fixes error due to attempting to index a nil value
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This code extracts the bits from the schema that determines how the data
is to be mapped to/from XML.
|
| |
|
|
|
|
| |
Now it gets the text, attribute or name first, then turns it into
whatever the schema wants. This should be easier to further factor out
into preparation for array support.
|
| |
|
|
| |
Cleaner and rules out invalid combinations.
|
| |
|
|
| |
E.g. error conditions or chat states.
|
