It hasn't been http_enable for yonks - slightly worried I didn't notice
this earlier.
Also don't refer to ComputerCraft.cfg - the name has changed several
times across versions, so let's leave it ambiguous.
This adds documentation comments to many of CC's Lua APIs, and
a couple of the Java ones, through the use of stubs. We then
export these to HTML using illuaminate [1] and upload them to our
documentation site [2].
Uploads currently occur on pushes to master and any release/tag. The
site is entirely static - there is no way to switch between versions,
etc... but hopefully we can improve this in the future.
[1]: github.com/SquidDev/illuaminate/
[2]: https://tweaked.cc/
- Add a cc.pretty module, which provides a Wadler style pretty printer [1].
- The cc.pretty.pretty function converts an arbitrary object into a
pretty-printed document. This can then be printed to the screen with
cc.pretty.{write, print} or converted to a string with cc.pretty.render.
- Convert the Lua REPL to use the pretty printer rather than
textutils.serialise.
[1]: http://homepages.inf.ed.ac.uk/wadler/papers/prettier/prettier.pdf
GPS requests are now sent and received on CHANNEL_GPS by default
instead. This means it should not be possible to distinguish
computers (and thus locate them) via their GPS requests.
"exit" now has a custom __tostring method, which prints an explanation
message. This is very similar to how Python achives the same
functionality:
lua> exit
Call exit() to exit
lua> exit()
> Actually leaves the REPL
We now use illuaminate[1]'s linting facilities to check the rom and
bios.lua for a couple of common bugs and other problems.
Right now this doesn't detect any especially important bugs, though it
has caught lots of small things (unused variables, some noisy code). In
the future, the linter will grow in scope and features, which should
allow us to be stricter and catch most issues.
As a fun aside, we started off with ~150 bugs, and illuaminate was able
to fix all but 30 of them, which is pretty neat.
[1]: https://github.com/SquidDev/illuaminate
- Adds cc.completions module, with a couple of helper functions for
working with the more general completion functionality (i.e. that
provided by read).
- Adds cc.shell.completions module, which provides shell-specific
completion functions.
- Add a "program completion builder", which allows you to write stuff
like this:
shell.setCompletionFunction( "rom/programs/redstone.lua",
completion.build(
{ completion.choice, { "probe", "set ", "pulse " } },
completion.side) )
Closes#232
Lua 5.2+ uses loadfile(filename, mode, env), not loadfile(filename,
env). While this is a minor incompatibility, it'd be nice to be
consistent as much as possible.
We try to handle the incorrect case too, as obviously we don't want to
break existing programs.
This moves expect from the bios into a new craftos.expect module,
removing the internal _G["~expect"] definition. Apparently people were
using this irrespective of the "don't use this" comment, so we need to
find another solution.
While this does introduce some ugliness (having to load the module in
weird ways for programs, duplicating the expect function in memory), it
does allow people to use the function in a supported way, and removes
the global ugliness.
Equivalent to `pastebin run`, but allows running arbitrary URLs
instead.
Is this a little questionable? Yes - people shouldn't be downloading
and running code from the internet. But hey, people do that already,
so we might as well make it convenient.
- Convert existing changelog over to use Markdown. This mostly involves
wrapping code in backticks, and marking things as headers where
appropriate.
- Copy all of CC:T's release notes over to the changelog. This is
somewhat more verbose than Dan's notes, but keeping them in sync
seems reasonable (and allows for automation!).
As 'require' operates relative to the current program's directory,
rather than the current directory, it meant we were trying to load files
from /rom/programs.
This is never a good idea, so we add the current directory to the
package path, allowing you to use require as one'd expect.
- Define an expect(index, actual_value, types...) helper function which
takes an argument index, value and list of permissable types and
ensures the value is of one of those types.
If not, it will produce an error message with the expected and actual
type, as well as the argument number and (if available) the function
name.
- Expose expect in the global scope as _G["~expect"], hopefully making
it clear it is internal.
- Replace most manual type checks with this helper method.
- Write tests to ensure this argument validation works as expected
Also fix a couple of bugs exposed by this refactor and the subsequent
tests:
- Make rednet checks a little more strict - rednet.close(false) is no
longer valid.
- Error when attempting to redirect the terminal to itself
(term.redirect(term)).
