On my mac laptop there's no `sha256sum` command, but there's
`gsha256sum`: using `g` prefix is common when GNU utilities are
installed on macOS.
```
SCHEME=chez make bootstrap
```
no longer fails on my laptop.
The downside is that compilation now continuously prints a warning
about `sha256sum` command not found (when it is not found). And I
don't know how to fix it cross-platform way.
```
1/5: Building Network.Socket.Data (Network/Socket/Data.idr)
sh: sha256sum: command not found
2/5: Building Network.FFI (Network/FFI.idr)
sh: sha256sum: command not found
3/5: Building Network.Socket.Raw (Network/Socket/Raw.idr)
sh: sha256sum: command not found
4/5: Building Network.Socket (Network/Socket.idr)
sh: sha256sum: command not found
5/5: Building Control.Linear.Network (Control/Linear/Network.idr)
sh: sha256sum: command not found
```
To be able to modify `Data.IOArray` as proposed in #1677.
Currently `Data.IOArray` cannot be modified because compiler need
to be built with previous compiler. This PR removes compiler
dependency on `Data.IOArray`.
The 'with' type and application need to treat the parameters with the
same plicity, but the application has just always treated them as
explicit since it never looked. It's easiest just to make them all
explicit, since this isn't a user visible type. Fixes#1695.
To be able to use `C` functions for both Scheme and RefC: it was
not possible for `Buffer` before this PR.
As an example, `writeBufferData` and `readBufferData` functions are
removed: generic C backend implementations are used instead.
While the discussion about how to refactor test framework is not
finished (#1654), make this change: move `rm -rf build` in the
beginning of the test. For these reasons:
* it is useful to inspect the contents of the `build` directory
especially after the test failure
* if build crashes mid-test (e.g. process killed), next run should
not be affected by the `build` directory from the previous run
```
IDRIS2_VERIFY(cond, message_format, ...)
```
When condition is false, crash.
Used in native functions where correct error handling is hard or
not impossible.
For example, `malloc` rarely fails, but if it fails, better crash
with clear error message than spend time debugging null pointer
dereference.
* add `strerror` function
* move `getErrno` to `System.Errno`
* use `strerror` in `Show FileError`
* on node there's no access to `strerror`, so `strerror` just converts the number to string