This is removed in emscripten 1.39.16, and for the wasm backend, was
broken since 1.39.6. Eliminating the setting will make it easier to
upgrade in the future.
This was introduced in #96 to bypass a Chrome bug introduced in Chrome
69 and fixed in Chrome 70. Chrome 69 supposedly has a market share of
0.09%, so I think it is safe to drop support.
Implementation of hiwire_get_dtype is split across two files. The reason seems to be that get_dtype returns two values: format and size. I changed it to take pointers to write the results into. This makes the code shorter and easier to understand (someone reading the files would have to search the source to find out that those constants are only used in two spots).
This resolves#935. I also changed the lint make recipe to use find which is more resilient to changes in directory structure and doesn't output those annoying No such file or directory messages to stdout.
I changed the name of the apply-lints recipe to apply-lint for consistency, and I updated it to only apply lints to files with staged changes.
Before this PR, hiwire effectively opts out of the C type system entirely by declaring everything as int. A char*? Cast it to int. What about a PyObject*? Better cast it to int too. This makes the calling code more verbose (at least if the calling code uses the type system) and is not good for maintainability.
I made a NewType called HwObject for hiwire keys. If you google how to make a NewType in C, people recommend a single field struct. However, EM_JS does not convert that compatibly: it converts any struct to the address of the struct, but an integer to the value of the integer. This created trouble. I decided instead to make a dummy empty struct and work with pointers to that struct. To ensure that converting to and from the NewType always requires an explicit cast, I added -Werror=int-conversion -Werror=incompatible-pointer-types to the compiler options. (I like this setting better in any case.)
I added asserts to main.c checking that HwObject has the same alignment and size as int. Hopefully this will prevent confusing bugs if that ever changes.
This incorporates two changes.
1. Since chrome tests are now much less flaky, we require chrome tests
to pass before deploying.
2. Mark all jobs (except benchmark) as filters/tags/only: /.*/ so that
they run on releases. This was previously causing the 1.16.0 release
to not contain package builds.
This addresses part of #713, by listing and building C libraries as
dependencies. This means we automatically build CLAPACK when needed, and
`lxml`'s C dependencies are not built if lxml is not. In particular,
building "core" should now be faster.
The building itself is still performed by Makefile.
Hood Chatham