profile
viewpoint

kriskowal/q 14833

A promise library for JavaScript

google/schism 1105

A self-hosting Scheme to WebAssembly compiler

tc39/proposal-weakrefs 291

WeakRefs

wingo/fibers 180

Concurrent ML-like concurrency for Guile

wingo/guix-nonfree 38

Packages that are inappropriate for upstream Guix

wingo/elogind 35

The systemd project's "logind", extracted to a standalone package

wingo/bicho 8

Scheme implementation suitable for microcontrollers

wingo/guile-jpeg 3

JPEG parsing, munging, codec toolkit

wingo/node 3

evented I/O for v8 javascript

wingo/luminatrix 2

Simple ray-tracer written in Guile Scheme

pull request commentWebAssembly/benchmarks

Add Zen Garden load benchmark

Heya :) I think forcing compilation isn't necessarily the goal, fwiw -- the metric is really time-to-interactivity; other aspects of interactivity (throughput, jankiness, etc) aren't measured here.

FWIW I looked into this issue and fwiw JSC's bytecode emitter for their interpreter tier has similar overhead to V8's liftoff or spidermonkey's baseline compiler: https://wingolog.org/archives/2020/04/14/understanding-webassembly-code-generation-throughput

wingo

comment created time in 6 days

pull request commentweb-platform-tests/rfcs

RFC #54 - Code of Conduct

Hi, asked to take a look at this by my colleague @Ms2ger -- FWIW I am on the group that handles CoC reports at work. I think this is a good effort but I would not recommend merging as-is.

  • The linked PR (https://github.com/web-platform-tests/wpt/pull/7520/files) has a dangling link to the citizen CoC, so I can't see what the standards are.
  • It does not seem to me to be a good idea to spend time writing a CoC; better to choose one that represents what you want. The contributor covenant 2.0 is pretty standard at this point and would be a good choice.
  • The summary document on this PR emphasizes responsibility to "understand both sides", which to me is not the right way to see CoC incidents. If anything the moderators need to understand the situation and its impact on people; X said / Y said isn't the right framework for this.
  • In general a CoC is a bad place to promote desired behavior ("be kind", etc). That happens elsewhere and in other ways. The sole purpose of a CoC (IMO) relates to bad behavior, not "good" behavior. If you are not convinced but interested in this argument, see chapter one in https://files.frameshiftconsulting.com/books/cocguide.pdf.

This is very much "for what it's worth" feedback; although I interact with WPT in my work on WebAssembly, I'm not an active contributor. Good luck!

stephenmcgruer

comment created time in 7 days

issue commentwingo/racket-jpeg

how to obtain image latitude and longitude?

The odd-looking tags are indeed that, btw -- tags present in the EXIF but which the decoder hasn't been made to understand. If it doesn't know the meaning of the tag, it can't decode the value. Sometimes those tags are nonstandard, but support for them is welcome.

shriram

comment created time in 7 days

issue commentwingo/racket-jpeg

how to obtain image latitude and longitude?

Weirdly, GPS information is stored in a separate section of the EXIF data -- you'd have to extend https://github.com/wingo/racket-jpeg/blob/master/exif.rkt#L461 to parse tag #x8825. See EXIF spec version 2.3 section 4.6.3 (B). You'd then need to add an equivalent to define-exif-tag for define-gps-tag; see section 4.6.6 for all the tags you can get out.

I don't have time to work on this in the near future but would be happy to merge patches :) Or to give away the package if you want to maintain it. FWIW I found hacking on this to be a delight, almost magic to see this info pop out of my pictures. I hope you have the same experience if you decide to take a look :)

shriram

comment created time in 7 days

issue commentwasdk/wasmparser

Support loop and block parameters

thank you!

wingo

comment created time in 9 days

issue commentwasdk/wasmparser

Support loop and block parameters

Here is the wasm2wat on that file:

(module
  (type (;0;) (func (result i32)))
  (type (;1;) (func (param i32 i32) (result i32)))
  (type (;2;) (func (param i32) (result i32)))
  (func (;0;) (type 0) (result i32)
    (local i32)
    i32.const 0
    i32.const 10
    loop (param i32 i32) (result i32)  ;; label = @1
      local.tee 0
      i32.add
      local.get 0
      i32.const 1
      i32.sub
      local.tee 0
      i32.eqz
      if (param i32) (result i32)  ;; label = @2
      else
        local.get 0
        br 1 (;@1;)
      end
    end)
  (export "run" (func 0)))
wingo

comment created time in 12 days

issue openedwasdk/wasmparser

Support multi-value

Steps to reproduce:

  1. Open https://wingolog.org/pub/ in firefox nightly
  2. Open a debugger for the newly opened tab
  3. Open a console and type:
async function loadWasm(url, imports) {
  let {module, instance} = await WebAssembly.instantiateStreaming(fetch(url), imports);
  return instance.exports.run;
}
var sum = await loadWasm("https://wingolog.org/pub/sum.wasm");
  1. Go to the "sum.wasm" page in the sources tab

Expected behavior: I see wasm disassembly

Actual behavior: blank page; error on the command-line:

console.error: (new Error("Unexpected type 1", "resource://devtools/client/shared/vendor/WasmDis.js", 40))
console.warn: "Action loadSourceText had an exception:" (new Error("Unexpected type 1", "resource://devtools/client/shared/vendor/WasmDis.js", 40))

See https://bugzilla.mozilla.org/show_bug.cgi?id=1628352.

created time in 12 days

push eventwingo/wabt

Sam Clegg

commit sha cc1edc0c12d2cf72aec34ae246ebd43bd681671c

wasm-interp: Correctly report failure of start function (#1230) We were printing the error message but returning success.

view details

Sam Clegg

commit sha 43fef7d1c31f5b99ff9f1e79ce368fe139414882

Switch to treating segment flags as a bitfield. NFC (#1232) This is in preparation for updating to latest version reference-types proposal where there is an additional flag and they can be combined. See: https://github.com/WebAssembly/bulk-memory-operations/issues/98 Also, add ERROR_IF to binary-reader.cc as logical corollary to the existing ERROR_UNLESS.

view details

Sam Clegg

commit sha cdd59d17d89a4fa7f2bb663de78fb38317e26409

Fix for failing `git describe` in CMakeLists.txt (#1234)

view details

Sam Clegg

commit sha b51f2cd46959467c8e3bb567799f400dbf8070e7

spectest-interp: Report when assert_trap passes and include error string. NFC (#1235)

view details

Sam Clegg

commit sha 3eb3daf7af8714fe274b578fe9c289cd00d97872

interpreter: Allow traps to include custom error strings (#1236) This means we can give more precise/useful errors for runtime failures. Change interp::Result from an enum to struct so it can hold the result enum plus an optional detailed error message. Add TRAP_MSG and TRAP_IF_MSG macros that work just like TRAP and TRAP_IF but contain a format string and printf-like arguments which are formatted to produce the error message.

view details

Sam Clegg

commit sha 838256d449ecd48f37e0c2fc0c2c1d0f50ce8584

Fix i686 string formatting issues from #1236 (#1239) I'm not sure how/why I allowed that change to land without the i686 tests passing.

view details

Sam Clegg

commit sha 2da0242be007caffdf44b172e95d7903f71f5b48

Mark memory_grow test as slow. (#1242) On windows debug builds these seems to be taking a long time. Seems to have gotten worse since #1236 landed. I will continue to investigate the cause of the slowdown and possibly revert this.

view details

Sam Clegg

commit sha 0cd7bc16489fe7476b25bf4c8176095ee35d013e

Add WABT_UNREACHABLE to silence gcc/msvc warnings (#1241)

view details

Sam Clegg

commit sha 291333af0cc5acb2ed17172bdc4a258d8f1fda44

Add i686-clang build config (#1240) We have an i686-gcc build already but it doesn't work on my local machine.

view details

Sam Clegg

commit sha 1eba845b3abbf7fcc2d49b76198bdc3a563fc698

Avoid os.path.relpath in gen-spec-js.py (#1246) relpath here was failing with on windows when TMPDIR is on a different drive. This is because `new_module_filename` lives in the TMPDIR where and json_dir might be on different drive. These paths don't get embedded in the final JS anyway because we embed them directly binary strings so its not important that they are relative.

view details

Sam Clegg

commit sha e9b42933377814248b64c4fed9f58bae219443c6

Fix run-tests target on windows (#1247) Under windows binaries end with `.exe` and live a the `Debug` or `Release` subdirectory so we need to use $<TARGET_FILE> to get the full executable name.

view details

Sam Clegg

commit sha 5e81015f69262657186b3f3bf03bfa28016c5a0d

Update spec testsuite (#1237) The only major change to the interpreter is to move segment initialization out `ReadBinaryInterp` (in the binary reader) and into interp.cc. This is because the test suite now expects out of bound semgments to be reported during initialization rather than reported as validation errors.

view details

Sam Clegg

commit sha 2d1e5a0246d5b2e806ea029ec045ee6f23cf6c78

Initial support for github actions (#1238) This adds a basic workflow that builds and tests wabt on all three desktop platforms. The plan is to extend this to completely replace travis and appveyor in the future. Remove the 2.7 requirement for python in CMakeLists.txt due to issue with github actions where this ends up selected in the wrong (mingw) version of python. See: https://github.com/actions/setup-python/issues/40

view details

Wouter van Oortmerssen

commit sha e6199f223f802ef62bc00058a7fa530f359666d4

wasm-decompile: Output of other sections + import/export. (#1233) * wasm-decompile: Output of other sections + import/export. This now outputs data, memories, globals, tables, and import/export of these (and functions). Changed the syntax to be more consistent and refactored how it is checked. * code-review fixes * Fixed printf format warning.

view details

Sam Clegg

commit sha af2b4450ef9a9ce504fe95d42cc9812e5976e1f9

Add github actions badge to README.md (#1251)

view details

Sam Clegg

commit sha 3130ab89d7864ae9105ccca5c241024f9536ab69

reference-types: Add reference-types spec tests (#1225) This change adds most of the tests from the reference-types proposal. There are two tests that require new instructions (`table.fill` and `select_t`) which will be followup changes. See: #1223

view details

Sam Clegg

commit sha 4386b19e2854e8d5f303bd7236a20092ff77cb9a

reference-types: add table.fill instruction (#1252)

view details

Sam Clegg

commit sha f1716357df721cbbaeacfcf8b1e7a12d4cb99459

reference-types: add support for typed select (#1253)

view details

Sam Clegg

commit sha b807819d5501ee7ba22a178d3acfb8fa6d6bcde7

Run github actions on push as well as PR (#1254)

view details

Sam Clegg

commit sha 4191fc9e5d65f31ca7538b2a585d251b3ba07ac3

Split run-unittests out as seperate target (#1255) New `check` target now runs other. This allows for github actions to show unittests and system tests as separate steps. Also a couple of CMakeLists.txt cleanups: - Don't use add_definition to add `-fno-exceptions`, this is a C++-only flag. - Lowercase the name of the `sanitizer` function. - Remove opcode.def from list of library input file. On windows when building a DLL .def files are assumed to be windows DLL .def files, which this is not. This change is split out from #1250

view details

push time in a month

Pull request review commentWebAssembly/wabt

Add support for atomic.fence from the threads proposal

 WABT_TOKEN(Throw, "throw") WABT_TOKEN(Try, "try") WABT_TOKEN(Unary, "UNARY") WABT_TOKEN(Unreachable, "unreachable")-WABT_TOKEN_FIRST(Opcode, AtomicLoad)

Mmm, I think this was a bad change that snuck in. I will make sure it's not there in the revised patch and regenerate the lexer.

wingo

comment created time in a month

Pull request review commentWebAssembly/wabt

Add support for atomic.fence from the threads proposal

 Result TypeChecker::OnAtomicWait(Opcode opcode) {   return CheckOpcode3(opcode); } +Result TypeChecker::OnAtomicFence(uint32_t consistency_model) {+  if (consistency_model != 0x0) {+    PrintError("bad atomic.fence consistency model: %u",+               consistency_model);+    return Result::Error;+  }+  return Result::Ok;+}

Hooo, finally picking up this patch again. Rebasing and re-uploading, but yes you are right -- will include this check in the validator rather than the type checker.

wingo

comment created time in a month

PR opened WebAssembly/benchmarks

Add Zen Garden load benchmark

Builds on #3. A little gnarly because I don't know the copyright for the zen garden demo, and I don't know how to rebuild it. Can take down this PR if it turns out that the rights aren't there.

+1523 -0

0 comment

9 changed files

pr created time in 2 months

create barnchwingo/benchmarks

branch : zen-garden-load

created branch time in 2 months

pull request commentWebAssembly/spec

Allow test compilation on Python 3.6

I just updated to link my w3c account with github, hopefully the bot runs again. (Affiliation is Igalia.)

wingo

comment created time in 3 months

pull request commentWebAssembly/spec

Allow test compilation on Python 3.6

See https://docs.python.org/3/library/subprocess.html#subprocess.run

wingo

comment created time in 3 months

PR opened WebAssembly/spec

Allow test compilation on Python 3.6

The text parameter (added in Python 3.7) is simply an alias for universal_newlines (added in Python 3.5), which we are already passing. Remove the duplicate keyword argument to allow tests to generate on Ubuntu 18.04, which has Python 3.6.

+0 -1

0 comment

1 changed file

pr created time in 3 months

create barnchwingo/spec

branch : fix-test-build-on-python-3.6

created branch time in 3 months

fork wingo/spec

WebAssembly specification, reference interpreter, and test suite.

https://webassembly.github.io/spec/

fork in 3 months

issue openedbytecodealliance/wasmtime

Harmonize multiple-result ABI with SpiderMonkey

In a WebAssembly + Firefox context, the goal is to replace the optimized compiler tier with Cranelift, but keep the quick-and-dirty Baseline compiler. In that context we will need some coherence in ABI between Cranelift and Baseline. I think some of the recent excellent work by @fitzgen to add multi-value support to Cranelift (#1147) might need some adaptation, in this regard.

To back up a bit, I'm going to try to summarize the situation. Corrections welcome.

Baseline's goal is to produced compiled code soon. Doesn't have to be good code; we leave that to the optimized tier (Cranelift, eventually). To produce good code soon, Baseline uses a compilation strategy that mirrors WebAssembly's stack discipline to the machine stack. If a program does this:

local.get 1
local.get 2

and these values get spilled to the stack, local 2 will be closer to the machine stack pointer than local 1. In Baseline, any value allocated to a register will have been pushed on the WebAssembly abstract stack more recently than any value spilled to the machine stack.

Multiple function return values also follow a stack discipline. Consider a function that returns three values v0, v1, and v2. Let us assume that there's only one register allocated to function returns, so one of the values goes to a register, and two to the stack. Following the invariant about registers being more recently pushed than stack results, that means v0 and v1 should go on the stack, and v2 should be allocated to a register. Furthermore, it means that v0 should be farther from the SP than v1.

Needed changes in Cranelift

  1. Cranelift and Baseline should agree (in the baldr ABI) on which results get allocated to registers and which to stack locations.
  2. Cranelift and Baseline should agree on how to find stack locations for stack results (an extra synthetic argument).

Related: WebAssembly ABI 2020

Related: ABIResultIter

I am pretty sure that some of the choices in bytecodealliance/cranelift#1147 didn't match up with the WebAssembly stack discipline. Not a problem for Cranelift of course, but I think it is a problem for Baseline. Thoughts?

cc @Dima00782 @bnjbvr @fitzgen @lars-t-hansen

created time in 3 months

more