* frodwith/urcrypt: (75 commits)
move libaes_siv to deps
fix typo in urcrypt.h
libaes_siv now using tip of dfoxfranke master
check for recovery header presence in configure, put -O3 in flags, move pc to distcleanfiles
clean generated pkg-config file
update urbit's configure to use a liburcrypt version
add a versioning scheme to urcrypt
remove scrypt from urbit build (in urcrypt now)
move the rest of the scrypt jets to urcrypt, enable them, and correct the hoon test to match the source rfc.
scr-pbk->urcrypt
start scrypt porting
Squashed 'pkg/urcrypt/scrypt/' content from commit a402f4116
finish porting secp jets to urcrypt
pkg-config support for urcrypt, update urbit build
cosmetic configure things
require shared ssl when building a shared urcrypt
remove some old files
add autogen.sh
use srcdir in -I to support out of tree builds
whitespace and symbol cleanup
...
Vere will not run a ship if STDIN is closed, unless passed the `-t`
flag. Hosted docker containers will not be interactive, but we would
like the docker image to be usable locally and interactively as well.
Thus, we check for STDIN being closed in the shell prior to launching
Vere, and if it is closed, pass the `-t` flag.
This commit adds the `docker-image` attribute to the main Nix
entrypoint, invoking `nix/pkgs/docker-image` which will build
a 'smart' docker image that can load keyfiles or a pier and
boot a ship
It includes a README for the official docker image, suitable
for posting as the README to a Docker Hub or similar docker
image repository.
This also removes nixcrpkgs and OSX cross compilation in favour of
compiling on the target. x86_64/musl targets are still supported
on Linux.
All sources are now managed via niv (see nix/sources.json) and Haskell
package sets are provided/organised via IOHK's haskell.nix.
Some effort has been made to expose similar top-level attributes for
development, but in some cases there have been changes. Please see
the comments in the top-level default.nix and ci.nix files for usage.
Adds the equivalent arm patches to the i386 patches added in #3054
These result in a dramatic speedup in running `=a (bex 1.000.000.000)` just as they do on x86_x64
This also sneaks in a hack to `/nix/nixcrpkgs/pkgs/libsigsegv/builder.sh` that allows libsigsegv to configure itself properly when cross compiling release binaries from x86_64 to aarch64.
It won’t trigger for you, since you’re not doing that (yet) but it will make it a little easier for me to maintain my aarch64 static release binaries if that `if [ $host = aarch64-linux-musleabi ]` section is upstreamed.
* master: (147 commits)
vere: bump version to 0.10.7
libsigsegv: disable stack vma check
vere: bump version to 0.10.6
ci: add travis as trusted user
jets: use appropriate macro
noun: add -C to control memo cache size
jets: restore fond/play/peek hooks
jam: add commented-out functionality to count size of atom
jets: cap memo cache and remove peek, play, and fond jets
noun: add functions to count size of noun
release: urbit-os-v1.0.23
interface/config: fix production build
soto: run +on-load migration once
publish, links: restore full height
sh/build-interface: amend for SPA
interface/CONTRIBUTING: amend for SPA / webpack
solid: update pill
hood + apps: fix OTA process for feat/SPA
hood: add version %6 for %file-server upgrade
chat: equally size both code + s3 buttons
...
This patches libsigsegv to not check the stack vma on Linux, since that
involves reading procfs, and we make very heavy use of sigsegv. This
eliminates most of urbit's performance discrepancy between Linux and
MacOS. These are the benchmarks used; note this is a local MBP vs a
cloud Linux server, and the MBP is almost certainly faster hardware.
We take two benchmarks, one of which decrements 10 million times and the
other simply allocates 125MB of memory. These are the results:
cpu-heavy == =/ n 10.000.000 |-(?~(n n $(n (dec n))))
mem-heavy == =a (bex 1.000.000.008)
macos, cpu-heavy: 6 seconds
macos, mem-heavy: 1 second
linux-before, cpu-heavy: 30 seconds
linux-before, mem-heavy: 160 seconds
linux-after, cpu-heavy 9 seconds
linux-after, mem-heavy 1.3 seconds
This represents a 3x speedup for the cpu-heavy operation and a 120x
speedup for the memory-heavy operation.
This check was used to try to distinguish stack overflow from other
forms of segmentation fault. In the comments in src/handler-unix.c, it
describes three heuristics it uses, depending on what's available from
the OS. In the linux-i386 case, all three are availble, so we simply
disable the slow one. This correctly recognizes stack overflow if you
simply alloca(10000000000).
