I updated our spec test suite to up-to-date version in #2484, but there are numerous syntax that are not currently supported in Binaryen. So I triaged them into different categories and added them to spec test BLACKLIST in shared.py.

While it is not a goal of Binaryen to

Present license file does not look right. Need to change it to the correct one

It seems bad to just code up our implementation of the instructions and hope for the best. We should have tests to make sure they are correct.

cc @pmntang

We need a document describing what the supported environment variables are (print_defaults ...) and what they do

for example:

DEVITO_DEBUG_COMPILER: writes to standard output the command line used to jit-compile an operator (eg gcc ... -O3 ...
DEVITO_JIT_BACKDOOR: escape hatch for custom kernels. The typical use case is as follows: one runs a Devito program; then, once the session is ov

Mid-range starter task:

Implement $ as a parameter value, see IEEE 6.20.2.1. Rough steps:

1. Create tests including passing $ through an instantiation, and using the parameter (with $) to form a queue.
2. Parser already handles $ as part of queues; need to see these and record them as parameter value.
3. Substitute the parameter value appropriately.

Description

Deploying a single file takes at minimum 30sec whereas vs-deploy does it immediately.

{
    "deploy.reloaded": {
      "targets": [
        {
           "type": "ftp",
           "dir": "/public_html",
           "host": "...",
           "port": 21,
           "secure": false,
           "user": "...",
           "password": "...",
           "mappings": 

Hi,

Everything is in title, it's a feature request to make a better user experience on mobile where short key can not be done to clear console.

This is kind of like #27, but I don' think people who are just starting out should worry about how to set up a package to go into opam.

What I have in mind is a guide that tells you how to release a package in simple cases, but notes likely potential gotchas, and has links to further info for more complex cases and for understaning the process under the hood.

This is something I'm trying to

The current runtime source generates a lot of warnings when being compiled. We should go through and fix the ones we can and suppress the ones we think are OK.

For future docs:

Instance instantiation in the outermost scope

Consider the following snippet:

implicit def eqList[A](implicit A: Eq[A]): Eq[List[A]] =
  new Eq[A] { ... }
implicit class EqOps[A](value: A) {
  def ===(other: A)(implicit A: Eq[A]): Boolean = A.equal(value, other)
}
...
object Test {
  def test: Unit = {
    val a : List[Int] = ...
    val b : List[In