Currently, ANSI escape codes are not supported in the console.
This is fixed by adding an extra javascript file that jQuery Terminal needs to render the codes.
Without this PR,
```js
let f = pyodide.globals.get("some_async_function");
setTimeout(f, 100);
```
doesn't work because `setTimeout` calls `f` which returns a coroutine
which is left unscheduled and so the actual work in `f` is never executed.
This is surprising to people, see for instance
https://github.com/pyodide/pyodide/discussions/2229.
This changes the behavior to automatically schedule all coroutines created
from async functions called from Javascript so that async functions can be
used as Javascript event handlers.
Old usage is still accepted but causes a deprecation warning, saying
we will remove it in v0.21. Similar to #2300. I am planning to add
an option to do wasm compilation in a subsequent PR.
I also did some cleanup from #2300 and added tests for the deprecation
warnings.
With newer versions of emscripten, linker errors surface eariler.
This makes it easier to find function pointer cast errors without
having to execute the bad code path -- the errors happen when the
wasm modules are linked (at load time in the browser)
Anyways, this fixes more linker errors. Mostly the problems have
to do with LAPACK functions that take string arguments. Most
LAPACK functions that take string arguments use them as enums and
only care about the first character of the string. Because of the
way that f2c works, we need to replace these strings with the ascii
code of the first character so we should replace:
sTRSV( 'UPPER', 'NOTRANS', 'NONUNIT', J, H, LDH, Y, 1 )
==>
CALL sTRSV( 85, 78, 78, J, H, LDH, Y, 1 )
where 85 and 78 are the ascii codes of U and N. Various character
variables are subbed into being integer variables. The two
functions `ilaenv` and `xerbla` expect actual C strings as an
argument, but it is very annoying to produce C strings so instead
I added wrapper functions ilaenvf2c and xerblaf2c to clapack and
instead of calling ilaenv and xerbla we call the f2c versions.
This is for future-proofing in case we decide to add more options at
some point. Old usage is still accepted but causes a deprecation warning,
saying we will remove in v0.21.
On rare occasions, a Javascript object that isn't an error gets thrown.
This PR ensures that we are handling this situation without anything going
too far astray.
This is a followup to #2236.
If no indexURL is provided, we throw and catch an error and
then use ErrorStackParser to calculate where pyodide.js has
been loaded from. Resolves#2290.
Question: But getting the URL from error stack trace is well... really
hacky. Can't we use
[`document.currentScript`](https://developer.mozilla.org/en-US/docs/Web/API/Document/currentScript)
or
[`import.meta.url`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import.meta)
instead?
Answer: `document.currentScript` works for the browser main thread.
`import.meta` works for es6 modules. In a classic webworker, I think there
is no approach that works. Also we would need some third approach for node
when loading a commonjs module using `require`. On the other hand, this
stack trace approach works for every case without any feature detection
code.
* Fix dangling webdriver
* Embed humor sans font
* Refactor matplotlib testing codes
* Trigger CI
* Trigger CI
* Catch error when import from js fails
* Update changelog
* Apply suggestions from the review
Our package build process currently has a significant flaw: we first run setup.py, recording all compilation commands, then we rewrite these compilation commands to invoke emcc and replay them, and then we pray that the cross compiled executables ended up in the right place to go into the wheel. This is not a good strategy because the build script is allowed to implement arbitrary logic, and if it moves, renames, etc any of the output files then we lose track of them. This has repeatedly caused difficulty for us.
However, we also make no particularly significant use of the two pass approach. We can just do the simpler thing: capture the compiler commands as they occur, modify them as needed, and then run the fixed command.
I also added a patch to fix the numpy feature detection for wasm so that we don't have to include _npyconfig.h and config.h, numpy can generate them in the way it would for a native build. I opened a numpy PR that would fix the detection for us upstream:
numpy/numpy#21154
This clears the way for us to switch to using pypa/build (as @henryiii has suggested) by removing our dependence on specific setuptools behavior.
This is on top of #2238.
One can select which benchmark (pystone, numpy, matplotlib, or all) to be run through command-line arguments.
We can divide each benchmark to separate CI jobs in the future if needed.
Moved pystone benchmark to benchmark directory, preventing it from being included in Pyodide release.
Boris Feld