Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 03 2019 16:20
    jarble commented #143
  • Aug 13 2019 16:38
    ballercat closed #183
  • Jun 11 2019 11:19
    JobLeonard commented #183
  • Jun 10 2019 19:02
    coveralls commented #183
  • Jun 10 2019 18:56
    coveralls commented #183
  • Jun 10 2019 18:54
    CrazyPython synchronize #183
  • Jun 10 2019 18:50
    CrazyPython opened #183
  • May 12 2019 00:49
    ShrewdSpirit edited #182
  • May 12 2019 00:46
    ShrewdSpirit opened #182
  • Mar 11 2019 15:01
    maudnals commented #112
  • Mar 11 2019 14:59
    maudnals commented #112
  • Mar 11 2019 14:59
    maudnals commented #112
  • Mar 11 2019 14:59
    maudnals commented #112
  • Mar 11 2019 14:56
    maudnals commented #112
  • Jan 25 2019 01:32
    MaxGraey commented #174
  • Jan 22 2019 13:17

    ballercat on master

    fix walt-cli tests on windows (… (compare)

  • Jan 22 2019 13:17
    ballercat closed #181
  • Jan 22 2019 13:17
    ballercat commented #181
  • Jan 22 2019 00:45
    coveralls commented #181
  • Jan 22 2019 00:39
    fcrick opened #181
Ronald Chen
@pyrolistical_twitter
ah, memory.dataSize() is how you let people know where walt has written up to
Ronald Chen
@pyrolistical_twitter
chrome 70 is previewing thread support
Arthur Buldauskas
@ballercat
:smile:
Should be fun to experiment with though
I wonder if there is some way to test it via node. It'll be a pain to rely on a browser for tests
Ronald Chen
@pyrolistical_twitter
i've been running walt in node.js, but for threads, you'll need to wait for them to integrate v8...which i bet would be in node.js 11
Arthur Buldauskas
@ballercat
Right. Testing Threads would have to wait till them hopefully you are right about v11 as it's out in just a few days https://github.com/nodejs/Release#release-schedule
Elifarley C.
@elifarley
Hi, I have a very basic question (I have no experience with Node, though I do have with JS).
When I try to follow the Walt in 5 minutes guide, I end up with an error (project root is at /data):
npx webpack --config webpack.config.js
Hash: 1ad81fe6a9804622703d
Version: webpack 4.23.1
Time: 139ms
Built at: 10/27/2018 4:09:39 PM
 1 asset
Entrypoint main = bundle.js
[0] ./src/index.js 265 bytes {0} [built]

WARNING in configuration
The 'mode' option has not been set, webpack will fallback to 'production' for this value. Set 'mode' option to 'development' or 'production' to enable defaults for each environment.
You can also set it to 'none' to disable any default behavior. Learn more: https://webpack.js.org/concepts/mode/

ERROR in ./src/index.js
Module not found: Error: Can't resolve 'walt-loader' in '/data'
 @ ./src/index.js 1:0-45 3:0-11

I'm using Docker to make things repeatable, so you can find what my image contains at https://github.com/elifarley/docker-dev-env/blob/master/alpine-wasm/Dockerfile

It basically runs this:

npm install --save-dev --global webpack webpack-cli walt-compiler walt-loader
Should I report this in Github issues instead, even though this is not a problem in Walt itself?
Arthur Buldauskas
@ballercat
Hmmm
It's likely an issue with your webpack config. If you link to it here I can help you resolve the issue
Arthur Buldauskas
@ballercat
Strange that it would complain about index.js though
Arthur Buldauskas
@ballercat
@elifarley sanity check your setup with this config. It's a working walt demo on github https://github.com/thomassturm/walt-mandelbrot-demo
Elifarley C.
@elifarley
My webpack.config:
const path = require('path')

module.exports = {
  resolve: {
    extensions: [".walt"]
  },
  module: {
    rules: [
      { test: /\.walt$/, use: 'walt-loader' }
    ]
  },
  entry: './src/index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist')
  }
}
Let me check that demo...
Elifarley C.
@elifarley
Here's the output of the demo:
walt-mandelbrot-demo:/data$ pwd
/data
walt-mandelbrot-demo:/data$ npx webpack --config webpack.config.js
Hash: 99912301cc15b509e53d
Version: webpack 4.23.1
Time: 459ms
Built at: 10/28/2018 2:09:24 PM
 1 asset
Entrypoint main = bundle.js
[0] ./src/index.js 2.55 KiB {0} [built]

ERROR in ./src/index.js
Module not found: Error: Can't resolve 'walt-loader' in '/data'
 @ ./src/index.js 6:0-43 75:1-11
The project root is mounted inside the Docker container at /data:
walt-mandelbrot-demo:~$ ls -Falk /data
total 12
drwxr-xr-x    5 app      node           101 Oct 28 14:11 ./
drwxr-xr-x    1 root     root            96 Oct 28 14:08 ../
drwxr-xr-x    8 app      node           163 Oct 28 14:08 .git/
-rw-r--r--    1 app      node           418 Oct 28 14:07 README.md
drwxr-xr-x    2 app      node            23 Oct 28 14:07 dist/
-rw-r--r--    1 app      node           261 Oct 28 14:07 index.html
drwxr-xr-x    3 app      node            34 Oct 28 14:07 src/
-rw-r--r--    1 app      node           311 Oct 28 14:07 webpack.config.js
Elifarley C.
@elifarley
If interested, the Docker image that contains npm, webpack and Walt installed can be run with:
docker run -it --rm --name walt -v "$PWD":/data elifarley/docker-dev-env:alpine-wasm bash
Arthur Buldauskas
@ballercat
aha
@elifarley it's likely because you are installing all the packages globally. Webpack is trying to resolve the loader in the local folder and isn't finding it. If you can't install locally, you will need to tell webpack how to resolve your global loader installs. This issue may be helpful to you https://github.com/webpack/webpack/issues/1482#issuecomment-245272707
I'm referring to this line https://github.com/elifarley/docker-dev-env/blob/master/alpine-wasm/Dockerfile#L35 in you setup, the --global bit
Elifarley C.
@elifarley

Oh, I'll take a look at this webpack issue, thank you!

I decided to install modules globally because I wanted to have a single Docker image that could be used for Walt development.

Elifarley C.
@elifarley

I tried to change the webpack.config.js like this:

  resolve: {
    extensions: [".walt"],
    alias: {
      walt: "/usr/local/lib/node_modules"
    }
  },

But it didn't work.

Then I changed the rules:

  module: {
    rules: [
      { test: /\.walt$/, use: '/usr/local/lib/node_modules/walt-loader' }
    ]
  },
Elifarley C.
@elifarley
And now it's working fine.
Arthur Buldauskas
@ballercat
Nice
Elifarley C.
@elifarley
For completeness' sake, here's the updated webpack.config.js file:
const path = require('path')

module.exports = {
  resolve: {
    modules: [ process.env.NODE_PATH ],
    extensions: [".walt"]
  },
  resolveLoader: {
    modules: [ process.env.NODE_PATH ],
    extensions: [".walt"]
  },
  module: {
    rules: [
      { test: /\.walt$/, use: 'walt-loader' }
    ]
  },
  entry: './src/index.js',
  mode: 'development',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist')
  }
}
Elifarley C.
@elifarley
What should I do to simply compile WALT to a WASM file, preferably without using Webpack?
Arthur Buldauskas
@ballercat
you may simply compile it with a node script and write the output (as binary) to a any file you like :)
Elifarley C.
@elifarley
Great, thank you!
Elifarley C.
@elifarley
In walt/src/index.js, we have import makeCounter from './walt/counter.walt'. I suppose this imports a default function from counter.walt while choosing a local name for it (makeCounter).
However, there's no default export on counter.walt, right?
Where's the definition of this makeCounter function? What's it do?
Arthur Buldauskas
@ballercat
It's a factory function which returns a promise. This promise resolves to a WebAssembly module instance. This is necessary because WASM modules need to compile asynchronously (at least that's the preferred way of doing it). It's created by the Webpack loader (it's not a "real" file)
Elifarley C.
@elifarley
Great, so by default the WASM file will use streaming compilation, right?
Arthur Buldauskas
@ballercat
There is no streaming, the wasm module is inlined into your application so there isn't anything to download to stream. It is asynchronous compile though.
You can use streaming compilation but you'll need a local server for that and the loader is unnecessary at that point.
Elifarley C.
@elifarley

On another subject: I'm importing memory from JS like this:

import {
    memory: Memory
} from 'env';

Now, how can I change some of its bytes, get its length, and so on? I could not find references for it

I'll use memory to create a few strings in WALT and then pass them to JS
Arthur Buldauskas
@ballercat
You can access memory by defining an array type i32[] (or other built in types) and then using subscript notation. There is not a ton of documentation but there are a ton of tests you can look at here https://github.com/ballercat/walt/tree/master/packages/walt-compiler/src/__tests__
Elifarley C.
@elifarley
tests and examples should help, thanks!
I saw the mandel.walt and didn't quite understand this: const raster: i32[] = 0
Now I do.
In the test folder, there should be some tests that show how to work with string types, right?
string-spec.js
Arthur Buldauskas
@ballercat
Yes, see the .walt version of that file for the tests themselves
Elifarley C.
@elifarley
oh sure
Elifarley C.
@elifarley
Instead of having 2 variable declarations like const memory: Memory = { initial: 1 }; and const raster: i32[] = 0;, maybe it would be better to have only one, like this:
const raster: Memory = { initial: 1 };
raster[3] = 47;
Elifarley C.
@elifarley
There's a problem with the suggestion above. I've changed it and posted at https://github.com/ballercat/walt/issues/163#issuecomment-435384889
bytebao
@bytebao
Hi guys, is there a bigger webassembly community on Gitter?