| Age | Commit message (Collapse) | Author |
|---|
|
A typo in the custom order function of the test case caused the test case
to yield differently sorted results on OS X, triggered by differences in
the libc's `qsort()` implementation.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
- Let `require()` always evaluate the executed code in raw mode
- Let `render()` always evaluate the executed code in template mode
- Let `include()` inherit the raw mode semantics of the calling scope
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
Fixes: 4ce69a8 ("fs: implement access(), mkstemp(), file.flush() and proc.flush()")
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
The most common usecase is extracting the value of a single byte at a
specific offset, e.g. to scan a string char-by-char to construct a hash.
Furthermore, constructing an array which contains the results of multiple
`ord()` invocations is trivial while efficiently extracting a single byte
value without the overhead of an intermediate array is not.
Due to that, change `ord()` to always return a single integer byte value
at the offset specified as second argument or at offset 0 in case no
argument was supplied.
That means that `ord("Abc", 0, 1, 2)` will now return `65` instead of the
former `[ 65, 98, 99 ]` result.
Code relying on the former behaviour should either perform multiple calls
to `ord()`, passing different offsets each time or switch to the `struct`
module which allows efficient unpacking of string data.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
|
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
|
