| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Still only a type definition.
Typed Lua is no longer maintained.
Teal is currently an active project.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
For completeness and consistency with set of plain hash functions
|
| | |
| |
| |
| | |
Tells you if you make a typo like "gropchat" or so
|
| | |
| |
| |
| | |
Gets you nice error messages if you make a typo in with error_reply()
|
| | |
| |
| |
| |
| | |
This previously was considered an error because the module API Teal spec
did not document a return value from module:add_timer()
|
| | |
| |
| |
| | |
Since it's used in mod_cron
|
| |/ |
|
| |
|
|
|
|
| |
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
|
| | |
|
| | |
|
