profile
viewpoint

graph-gophers/graphql-go 3184

GraphQL server with a focus on ease of use

gopherjs/vecty 1606

Vecty: your frontend, in Go

gopherjs/gopherwasm 83

This package is deprecated. Use syscall/js of GopherJS instead.

neelance/go-angularjs 77

GopherJS bindings to AngularJS

neelance/ffi_gen 76

A generator for Ruby FFI bindings, directly from header files via LLVM's Clang compiler

neelance/go 60

The Go programming language

neelance/go_js_wasm_exec 23

POC on how to use WebAssembly binaries generated by the Go compiler in a non-web environment

neelance/java2ruby 17

A transpiler from Java to Ruby

neelance/godockerize 12

Build Docker images from Go packages

issue commentgolang/go

runtime: mlock of signal stack failed: 12

The crash is intentional because we considered that preferable to random memory corruption.

@aclements There is a small flaw in this argument: The problem are not the true positives that run into the ulimit, but the false positives that would not have memory corruption without the workaround.

karalabe

comment created time in 18 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

Is there a way to detect the ulimit setting and avoid the crash if the workaround can not be applied? This way we could still improve the situation but not cause new crashes? We could then instead print a warning about potential memory corruption.

karalabe

comment created time in 18 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

The discussion seems to be about either accepting more false positives or false negatives. Here's a summary:

False positive: The workaround gets enabled on a patched kernel.

  • Reproducible. Instructions can be shown.
  • Looks like a regression.
  • Hard to fix in certain environments.
  • Go binary may run in some environments but fails to run in others.

False negative: The workaround is not enabled on an unpatched kernel.

  • Failure only happens rarely, especially if async preemption is disabled.
  • Possibly severe consequences due to memory corruption.
  • Hard to debug.
karalabe

comment created time in 18 hours

issue commentgolang/go

runtime: mlock of signal stack failed: 12

https://github.com/golang/go/issues/37436#issuecomment-591237929 states that disabling async preemption is not a proper solution, is it?

karalabe

comment created time in a day

issue commentgolang/go

runtime: mlock of signal stack failed: 12

It sounds like proper automatic detection across all distributions is nearly impossible. I see three options:

  • Do nothing.
  • Make the workaround opt-in.
  • Make the workaround opt-out.
karalabe

comment created time in a day

issue commentgolang/go

runtime: mlock of signal stack failed: 12

With my limited knowledge right now, this seems weird. Patch releases are intended to distribute patches in a controlled way so people (and in this case the Go compiler) can know which patches are included and which are not. However, this is the way it is, so we have to live with it.

Open questions:

  • How many people are affected by this issue?
  • Is ulimit a viable workaround?
  • Is Ubuntu the only distribution that "disregards" Linux kernel patch numbers?
  • Depending on the answers to the questions above: Would it be reasonable to add a special detection for Ubuntu?
karalabe

comment created time in a day

issue commentgolang/go

runtime: mlock of signal stack failed: 12

Is it common for Ubuntu (and other distributions?) to use cherry-picking instead of following Linux kernel patch releases? On https://packages.ubuntu.com/search?keywords=linux-image-generic all kernels have a patch release of zero.

karalabe

comment created time in a day

issue commentgolang/go

runtime: mlock of signal stack failed: 12

A little summary because I had to piece it together myself:

  • Root cause: https://bugzilla.kernel.org/show_bug.cgi?id=205663
  • Affected Linux kernels: 5.2 - 5.4.1
  • Fixed Linux kernel 5.4.2 released at 2019-12-05: https://lwn.net/Articles/806394/
  • Go's partial workaround: https://go-review.googlesource.com/c/go/+/209899/
  • Available Linux kernels for the latest Ubuntu release: https://packages.ubuntu.com/search?keywords=linux-image-generic
  • Latest linux kernel available for Ubuntu is version 5.3.0
  • However, it seems like the patch was cherry-picked into Ubuntu's 5.3.0 kernel: https://kernel.ubuntu.com/git/ubuntu/ubuntu-eoan.git/commit/?id=59e7e6398a9d6d91cd01bc364f9491dc1bf2a426

So it seems like Ubuntu's kernel is patched, but the workaround is enabled anyways.

karalabe

comment created time in a day

push eventneelance/sourcemap

Tod Bachman

commit sha 379ac5d7f899ead3a1561f283108230007655bf6

Include empty lists rather than for Names and Sources

view details

Tod Bachman

commit sha 2833bce08e4c77c3e07af9cc765b046ccb259671

Include error description in names and sources unit tests

view details

push time in 14 days

PR merged neelance/sourcemap

Include empty lists rather than "null" for Names and Sources

Problem:

I submitted a PR recently to ensure the names and sources keys are included in source maps even when they are empty. I failed to fully test it and didn't notice that if they are null they will be written out to the source map as "names":null rather than "names":[]. 🤕 The latter is the behavior that should be expected.

Solution:

I updated the WriteTo method to check if either of those fields is nil and set it to an empty []string before json encoding the map. This ensures we will always see an empty list in the map rather than null. I added a couple unit tests to cover this behavior.

FYI: @neelance

+43 -0

0 comment

2 changed files

todbachman-wf

pr closed time in 14 days

Pull request review commentneelance/sourcemap

Include empty lists rather than "null" for Names and Sources

 func TestWriteTo(t *testing.T) { 		t.Error(b.String()) 	} }++func TestWriteToShouldIncludeEmptyNames(t *testing.T) {+	m, err := ReadFrom(strings.NewReader(testFileWithoutNames))+	if err != nil {+		t.Fatal(err)+	}+	if m.Names != nil {+		t.Error("Names expected to be nil")+	}+	b := bytes.NewBuffer(nil)+	if err := m.WriteTo(b); err != nil {+		t.Fatal(err)+	}+	if !strings.Contains(b.String(), `"names":[]`) {+		t.Error(b.String())

Please add at least a small error description, so the error message is not only the json.

todbachman-wf

comment created time in 14 days

issue commentgolang/go

syscall/js: add support for fork/exec syscalls?

Fork is a very difficult syscall. I don't see an easy way to support it with Node.js. It is unlikely that I will work on this. Maybe someone else wants to try...

myitcv

comment created time in 17 days

pull request commentneelance/sourcemap

Include names and sources even when empty

Thanks!

todbachman-wf

comment created time in 17 days

push eventneelance/sourcemap

Tod Bachman

commit sha ac8afc4bd5b69cab96fc452db85ba773b31566ac

Include names and sources even when empty The names and sources fields are not optional according to the source maps spec. Omitting them when they are empty can cause source map parsers that expect them to always be present to crash. This changes the json encoding of those fields so they are no longer omitted when empty. https://sourcemaps.info/spec.html

view details

push time in 17 days

PR merged neelance/sourcemap

Include names and sources even when empty

Problem

The names and sources fields are not optional according to the source maps spec. Omitting them when they are empty causes source map parsers that expect them to always be present to crash. We are using the Dart source_maps package to parse stack traces that include frames originating in both Dart and Go code (the Go code is compiled to Js using gopherjs). We've run into exceptions parsing these types of stack traces due to the absence of the names field in the Go source maps.

Solution

This changes the json encoding of those fields so they are no longer omitted when empty.

+2 -2

1 comment

1 changed file

todbachman-wf

pr closed time in 17 days

issue commentgolang/go

wasm: improve error message when wasm file is not supplied

Please keep in mind that wasm_exec.js's API is not fully "public" until js/wasm is stable. Right now it is meant for early adopters and can change at any time. However, I agree with you that a better error message can ease this pitfall at almost zero cost. I'll add it in the next release cycle.

Gregory-Ledray

comment created time in 23 days

issue commentgolang/go

misc/wasm: Possible bug in _makeFuncWrapper

You don't have to use bind, it is much more common to assign the function to a property of some object and then call it as a method:

const fn = function () { console.log("the answer:", this.answer); };
const deepThought = { answer: 42 };
deepThought.calculateAnswer = fn;
deepThought.calculateAnswer();

Since the wrapper function is meant to capture this, there is no other way to write it.

albrow

comment created time in a month

push eventneelance/clientside-pdf-merge

Richard Musiol

commit sha 22cacef44723fb6899e548efd9fd594c555cbb60

empty commit to build github page

view details

push time in 2 months

create barnchneelance/clientside-pdf-merge

branch : master

created branch time in 2 months

created repositoryneelance/clientside-pdf-merge

Merge PDFs locally in your browser

created time in 2 months

startedHopding/pdf-lib

started time in 2 months

startedgolang/tools

started time in 2 months

issue commentwasmerio/wasmer

Can't run Golang with large binary

I've now rebased my fork for wasi at https://github.com/neelance/go/tree/wasi.

lucklove

comment created time in 2 months

push eventneelance/go

Richard Musiol

commit sha 3b00639dad1f92d5fa6cafed72f46113db115703

wasi wip Change-Id: Iec4be7d71320b411f4f859a64dc8a5cc260a2288

view details

push time in 2 months

push eventneelance/go

Robert Griesemer

commit sha 27fc32ff01cc699e160890546816bd99d6c57823

cmd/compile: better error message for language version errors Fixes #33753. Updates #31747. Change-Id: Icc42b23405ead4f7f17b0ffa3611405454b6b271 Reviewed-on: https://go-review.googlesource.com/c/go/+/198491 Run-TryBot: Robert Griesemer <gri@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Utkarsh Dixit

commit sha 3d437ac6bc655c7c1a3e2811a9d73fb64e342de1

C: update email address for utkarsh-extc Change-Id: If657dab2df19d3b0c2ff9869a64e3a97446646ac GitHub-Last-Rev: b921b01cf4e5bcbbc65fb1fb0b5cd836bda73596 GitHub-Pull-Request: golang/go#34637 Reviewed-on: https://go-review.googlesource.com/c/go/+/198041 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

view details

Tobias Klauser

commit sha 64785bf96c5942e5e2a3d326b48eae4e7b189e03

cmd/go/internal/modfetch: update TestCodeRepo for gopkg.in/yaml.v2 again Update the expected data to fix the longtest builder. Updates #28856 Change-Id: I7fb6ee72e8469d974561b4b4057f40142f5b3654 Reviewed-on: https://go-review.googlesource.com/c/go/+/198557 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>

view details

Jeremy Faller

commit sha 9e6a84f2b126cfe15eaa57b86b0d074a018dbef4

cmd/compile: walk the progs to generate debug_lines Rather than use the pcln tables, walk progs while generating debug_lines. This code slightly increases the number of is_stmt toggles in the debug information due to a previous bug in how the pcline walking worked. (Previous versions of the line walking code wouldn't return the old_value, instead returning 0. This behavior might lose is_stmt toggles in the line table.) We suspected there would be a speedup with this change, but benchmarking hasn't shown this to be true (but has been noisy enough to not really show any large differences either way). These benchmarks are comparing non-prog walking code with this prog-walking code: name old time/op new time/op delta Template 321ms ± 4% 316ms ± 3% ~ (p=0.165 n=10+10) Unicode 146ms ± 5% 142ms ± 4% ~ (p=0.063 n=10+10) GoTypes 1.06s ± 2% 1.07s ± 2% ~ (p=0.280 n=10+10) Compiler 4.07s ± 1% 4.06s ± 1% ~ (p=0.549 n=10+9) SSA 12.6s ± 2% 12.7s ± 2% +1.27% (p=0.019 n=10+10) Flate 201ms ± 7% 202ms ± 4% ~ (p=0.436 n=10+10) GoParser 248ms ± 4% 250ms ± 2% ~ (p=0.356 n=9+10) Reflect 679ms ± 5% 678ms ± 4% ~ (p=0.971 n=10+10) Tar 281ms ± 2% 283ms ± 3% ~ (p=0.222 n=9+9) XML 381ms ± 3% 384ms ± 5% ~ (p=0.393 n=10+10) LinkCompiler 1.08s ± 2% 1.10s ± 2% +1.89% (p=0.009 n=10+10) ExternalLinkCompiler 2.23s ± 4% 2.23s ± 1% ~ (p=1.000 n=10+8) LinkWithoutDebugCompiler 654ms ± 4% 673ms ± 4% +2.94% (p=0.019 n=10+10) StdCmd 13.6s ± 2% 13.9s ± 1% +2.00% (p=0.000 n=10+10) name old user-time/op new user-time/op delta Template 582ms ±11% 575ms ±14% ~ (p=0.631 n=10+10) Unicode 431ms ±24% 390ms ±38% ~ (p=0.315 n=10+10) GoTypes 2.47s ±11% 2.51s ± 4% ~ (p=0.280 n=10+10) Compiler 9.09s ± 3% 9.04s ± 5% ~ (p=0.684 n=10+10) SSA 25.8s ± 4% 26.0s ± 3% ~ (p=0.529 n=10+10) Flate 318ms ±14% 322ms ±13% ~ (p=0.912 n=10+10) GoParser 386ms ± 6% 386ms ± 5% ~ (p=0.888 n=9+8) Reflect 1.42s ±20% 1.32s ±24% ~ (p=0.393 n=10+10) Tar 476ms ±19% 471ms ±25% ~ (p=1.000 n=10+10) XML 681ms ±25% 745ms ±21% ~ (p=0.143 n=10+10) LinkCompiler 1.75s ±13% 1.86s ±12% ~ (p=0.075 n=10+10) ExternalLinkCompiler 2.98s ±18% 3.41s ±13% +14.48% (p=0.003 n=10+10) LinkWithoutDebugCompiler 1.05s ±12% 1.08s ±16% ~ (p=0.739 n=10+10) name old alloc/op new alloc/op delta Template 36.4MB ± 0% 36.4MB ± 0% -0.11% (p=0.000 n=10+10) Unicode 28.6MB ± 0% 28.5MB ± 0% -0.06% (p=0.029 n=10+10) GoTypes 121MB ± 0% 121MB ± 0% -0.09% (p=0.000 n=9+9) Compiler 548MB ± 0% 547MB ± 0% -0.10% (p=0.000 n=10+10) SSA 1.87GB ± 0% 1.87GB ± 0% -0.13% (p=0.000 n=10+10) Flate 23.0MB ± 0% 22.9MB ± 0% -0.09% (p=0.000 n=9+10) GoParser 27.9MB ± 0% 27.8MB ± 0% -0.12% (p=0.000 n=10+10) Reflect 77.7MB ± 0% 77.6MB ± 0% -0.12% (p=0.000 n=8+10) Tar 34.5MB ± 0% 34.5MB ± 0% -0.07% (p=0.003 n=10+10) XML 44.4MB ± 0% 44.4MB ± 0% -0.07% (p=0.000 n=10+10) LinkCompiler 236MB ± 0% 240MB ± 0% +1.72% (p=0.000 n=10+10) ExternalLinkCompiler 246MB ± 0% 254MB ± 0% +3.02% (p=0.000 n=10+10) LinkWithoutDebugCompiler 159MB ± 0% 164MB ± 0% +3.35% (p=0.000 n=10+10) name old allocs/op new allocs/op delta Template 372k ± 0% 371k ± 0% -0.23% (p=0.000 n=10+10) Unicode 340k ± 0% 340k ± 0% -0.05% (p=0.000 n=10+10) GoTypes 1.33M ± 0% 1.32M ± 0% -0.20% (p=0.000 n=9+10) Compiler 5.37M ± 0% 5.36M ± 0% -0.17% (p=0.000 n=10+10) SSA 17.9M ± 0% 17.9M ± 0% -0.15% (p=0.000 n=10+10) Flate 234k ± 0% 233k ± 0% -0.24% (p=0.000 n=9+10) GoParser 309k ± 0% 309k ± 0% -0.21% (p=0.000 n=10+10) Reflect 969k ± 0% 966k ± 0% -0.30% (p=0.000 n=9+10) Tar 348k ± 0% 347k ± 0% -0.22% (p=0.000 n=10+9) XML 426k ± 0% 425k ± 0% -0.15% (p=0.000 n=9+10) LinkCompiler 638k ± 0% 637k ± 0% -0.07% (p=0.000 n=10+10) ExternalLinkCompiler 1.69M ± 0% 1.69M ± 0% -0.05% (p=0.000 n=10+10) LinkWithoutDebugCompiler 222k ± 0% 221k ± 0% -0.03% (p=0.007 n=10+9) name old object-bytes new object-bytes delta Template 559kB ± 0% 560kB ± 0% +0.23% (p=0.000 n=10+10) Unicode 216kB ± 0% 216kB ± 0% +0.01% (p=0.000 n=10+10) GoTypes 2.03MB ± 0% 2.04MB ± 0% +0.31% (p=0.000 n=10+10) Compiler 8.07MB ± 0% 8.10MB ± 0% +0.35% (p=0.000 n=10+10) SSA 27.1MB ± 0% 27.3MB ± 0% +0.72% (p=0.000 n=10+10) Flate 343kB ± 0% 344kB ± 0% +0.22% (p=0.000 n=10+10) GoParser 441kB ± 0% 442kB ± 0% +0.34% (p=0.000 n=10+10) Reflect 1.36MB ± 0% 1.36MB ± 0% +0.23% (p=0.000 n=10+10) Tar 487kB ± 0% 488kB ± 0% +0.21% (p=0.000 n=10+10) XML 632kB ± 0% 634kB ± 0% +0.35% (p=0.000 n=10+10) name old export-bytes new export-bytes delta Template 18.5kB ± 0% 18.5kB ± 0% ~ (all equal) Unicode 7.92kB ± 0% 7.92kB ± 0% ~ (all equal) GoTypes 35.0kB ± 0% 35.0kB ± 0% ~ (all equal) Compiler 109kB ± 0% 109kB ± 0% +0.00% (p=0.000 n=10+10) SSA 137kB ± 0% 137kB ± 0% +0.00% (p=0.000 n=10+10) Flate 4.89kB ± 0% 4.89kB ± 0% ~ (all equal) GoParser 8.49kB ± 0% 8.49kB ± 0% ~ (all equal) Reflect 11.4kB ± 0% 11.4kB ± 0% ~ (all equal) Tar 10.5kB ± 0% 10.5kB ± 0% ~ (all equal) XML 16.7kB ± 0% 16.7kB ± 0% ~ (all equal) name old text-bytes new text-bytes delta HelloSize 760kB ± 0% 760kB ± 0% ~ (all equal) CmdGoSize 10.8MB ± 0% 10.8MB ± 0% ~ (all equal) name old data-bytes new data-bytes delta HelloSize 10.7kB ± 0% 10.7kB ± 0% ~ (all equal) CmdGoSize 312kB ± 0% 312kB ± 0% ~ (all equal) name old bss-bytes new bss-bytes delta HelloSize 122kB ± 0% 122kB ± 0% ~ (all equal) CmdGoSize 146kB ± 0% 146kB ± 0% ~ (all equal) name old exe-bytes new exe-bytes delta HelloSize 1.13MB ± 0% 1.13MB ± 0% ~ (all equal) CmdGoSize 15.0MB ± 0% 15.1MB ± 0% +0.22% (p=0.000 n=10+10) Change-Id: If6e0982cd1398062a88e6c0c7513e141f9503531 Reviewed-on: https://go-review.googlesource.com/c/go/+/196661 Run-TryBot: Jeremy Faller <jeremy@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>

view details

Cherry Zhang

commit sha a09cd8ccb372d760bd21d7e56f42b9dbea6ecc2b

[dev.link] cmd/compile: fix data race on LSym.Pkg LSym may be created concurrently. Reading/writing LSym.Pkg may cause data race (see https://build.golang.org/log/f0351c5cc7bf4c92e3aa5e78e294c2d009ebf118). Fix this by setting LSym.Pkg only when holding the lock. Change-Id: Ib3160ecf47c4ca530b09369e0e8284db6597cfd0 Reviewed-on: https://go-review.googlesource.com/c/go/+/198492 Reviewed-by: Than McIntosh <thanm@google.com>

view details

Jason A. Donenfeld

commit sha 6b85fa80519615ae5fd58154277b47d77e5cf08b

runtime: iterate ms via allm linked list to avoid race It's pointless to reach all ms via allgs, and doing so introduces a race, since the m member of a g can change underneath it. Instead iterate directly through the allm linked list. Updates: #31528 Updates: #34130 Change-Id: I34b88402b44339b0a5b4cd76eafd0ce6e43e2be1 Reviewed-on: https://go-review.googlesource.com/c/go/+/198417 Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Matthew Dempsky

commit sha c33d45a898ab1d966faba33d18acdffefb0fae0d

cmd/compile: don't statically copy string-typed variables During package initialization, the compiler tries to optimize: var A = "foo" var B = A into var A = "foo" var B = "foo" so that we can statically initialize both A and B and skip emitting dynamic initialization code to assign "B = A". However, this isn't safe in the presence of cmd/link's -X flag, which might overwrite an initialized string-typed variable at link time. In particular, if cmd/link changes A's static initialization, it won't know it also needs to change B's static initialization. To address this, this CL disables this optimization for string-typed variables. Fixes #34675. Change-Id: I1c18f3b855f6d7114aeb39f96aaaf1b452b88236 Reviewed-on: https://go-review.googlesource.com/c/go/+/198657 Run-TryBot: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Bryan C. Mills

commit sha 5fe3b49a0540aacf685273a43b0fb31b44cf5dd6

Revert "cmd/compile: walk the progs to generate debug_lines" This reverts CL 196661. Reason for revert: broke TestGdb* tests on mips64le, ppc64le, and s390x builders. Change-Id: I3b5c97c840819a0d407b943f7cf7e2d97f06042d Reviewed-on: https://go-review.googlesource.com/c/go/+/198697 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Cherry Zhang

commit sha 2c484c0356c5e13a480b3842de0d345224a7bbf8

[dev.link] cmd/internal/obj: write object file in new format If -newobj is set, write object file in new format, which uses indices for symbol references instead of symbol names. The file format is described at the beginning of cmd/internal/goobj2/objfile.go. A new package, cmd/internal/goobj2, is introduced for reading and writing new object files. (The package name is temporary.) It is written in a way that trys to make the encoding as regular as possible, and the reader and writer as symmetric as possible. This is incomplete, and currently nothing will consume the new object file. Change-Id: Ifefedbf6456d760d15a9f40a28af6486c93100fe Reviewed-on: https://go-review.googlesource.com/c/go/+/196030 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>

view details

Meng Zhuo

commit sha 2bf7a925712dca5646f9215cda17c5b61eea14ce

cmd/asm: add VLD[1-4]R vector instructions on arm64 This change adds VLD1R, VLD2R, VLD3R, VLD4R Change-Id: Ie19e9ae02fdfc94b9344acde8c9938849efb0bf0 Reviewed-on: https://go-review.googlesource.com/c/go/+/181697 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>

view details

Meng Zhuo

commit sha a1b1ba7daf4d612cb08e98567d809a6f202498ce

internal/bytealg: (re)adding mips64x compare implementation The original CL of mips64x compare function has been reverted due to wrong implement for little endian. Original CL: https://go-review.googlesource.com/c/go/+/196837 name old time/op new time/op delta BytesCompare/1 28.9ns ± 4% 22.1ns ± 0% -23.60% (p=0.000 n=9+8) BytesCompare/2 34.6ns ± 0% 23.1ns ± 0% -33.25% (p=0.000 n=8+10) BytesCompare/4 54.6ns ± 0% 40.8ns ± 0% -25.27% (p=0.000 n=8+8) BytesCompare/8 73.9ns ± 0% 49.1ns ± 0% -33.56% (p=0.000 n=8+8) BytesCompare/16 113ns ± 0% 24ns ± 0% -79.20% (p=0.000 n=9+9) BytesCompare/32 190ns ± 0% 26ns ± 0% -86.53% (p=0.000 n=10+10) BytesCompare/64 345ns ± 0% 44ns ± 0% -87.19% (p=0.000 n=10+8) BytesCompare/128 654ns ± 0% 52ns ± 0% -91.97% (p=0.000 n=9+8) BytesCompare/256 1.27µs ± 0% 0.07µs ± 0% -94.14% (p=0.001 n=8+9) BytesCompare/512 2.51µs ± 0% 0.12µs ± 0% -95.26% (p=0.000 n=9+10) BytesCompare/1024 4.99µs ± 0% 0.21µs ± 0% -95.85% (p=0.000 n=8+10) BytesCompare/2048 9.94µs ± 0% 0.38µs ± 0% -96.14% (p=0.000 n=8+8) CompareBytesEqual 105ns ± 0% 64ns ± 0% -39.43% (p=0.000 n=10+9) CompareBytesToNil 34.8ns ± 1% 38.6ns ± 3% +11.01% (p=0.000 n=10+10) CompareBytesEmpty 33.6ns ± 3% 36.6ns ± 0% +8.77% (p=0.000 n=10+8) CompareBytesIdentical 29.7ns ± 0% 40.5ns ± 1% +36.45% (p=0.000 n=10+8) CompareBytesSameLength 69.1ns ± 0% 51.8ns ± 0% -25.04% (p=0.000 n=10+9) CompareBytesDifferentLength 69.8ns ± 0% 52.5ns ± 0% -24.79% (p=0.000 n=10+8) CompareBytesBigUnaligned 5.15ms ± 0% 2.19ms ± 0% -57.59% (p=0.000 n=9+9) CompareBytesBig 5.28ms ± 0% 0.28ms ± 0% -94.64% (p=0.000 n=8+8) CompareBytesBigIdentical 29.7ns ± 0% 36.9ns ± 2% +24.11% (p=0.000 n=8+10) name old speed new speed delta CompareBytesBigUnaligned 204MB/s ± 0% 480MB/s ± 0% +135.77% (p=0.000 n=9+9) CompareBytesBig 198MB/s ± 0% 3704MB/s ± 0% +1765.97% (p=0.000 n=8+8) CompareBytesBigIdentical 35.3TB/s ± 0% 28.4TB/s ± 2% -19.44% (p=0.000 n=8+10) Fixes #34549 Change-Id: I2ef29f13cdd4229745ac2d018bb53c76f2ff1209 Reviewed-on: https://go-review.googlesource.com/c/go/+/197557 Reviewed-by: Cherry Zhang <cherryyz@google.com> Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Matthew Dempsky

commit sha 3ad350820df8217b4d05c56923e533a196bace27

cmd/compile: change size diagnostic to use benchmark format Makes it easier to run go build -a -gcflags=-d=export std |& grep ^BenchmarkExportSize and get useful output for feeding into benchstat. Change-Id: I2b52e8f5ff33b7ccb6c25b18e464513344bd9ad9 Reviewed-on: https://go-review.googlesource.com/c/go/+/198698 Reviewed-by: Robert Griesemer <gri@golang.org>

view details

David Chase

commit sha f7f85bdc2c4a8a472a271a7d2333557ad6143eeb

cmd/compile: refine statement marking in numberlines 1) An empty block is treated as not-a-statement unless its line differs from at least one of its predecessors (it might make sense to rearrange branches in predecessors, but that is a different issue). 2) When iterating forward to choose a "good" place for a statement, actually check that the chosen place is in fact good. 3) Refactor same line and same file into methods on XPos and Pos. This reduces the failure rate of ssa/stmtlines_test by 7-ish lines. (And interacts favorably with later debugging CLs.) Change-Id: Idb7cca7068f6fc9fbfdbe25bc0da15bcfc7b9d4a Reviewed-on: https://go-review.googlesource.com/c/go/+/188217 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org>

view details

David Chase

commit sha 6139019efaa3faa9ec94a57ab8c15b726d516664

cmd/compile: pick position of implicit break statements more carefully The previous version used the position of the switch statement, which makes for potentially jumpy stepping and introduces a large number of statements repeating the line (tricky for inserting breaks). It also shared a single OBREAK node and this was not really a syntax "tree". This improves both the nostmt test (by 6 lines) and reduces the total badness score from dwarf-goodness (by about 200). Change-Id: I1f71b231a26f152bdb6ce9bc8f95828bb222f665 Reviewed-on: https://go-review.googlesource.com/c/go/+/188218 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org>

view details

David Chase

commit sha 53bd9151099c54ffb4fee73d8b1771e311f6a271

cmd/compile: classify more nodes as "poor choices" for statements Aggregate-making nodes that are later decomposed are poor choices for statements, because the decomposition phase turns them into multiple sub-values, some of which may be dead. Better to look elsewhere for a statement mark. Change-Id: Ibd9584138ab3d1384548686896a28580a2e43f54 Reviewed-on: https://go-review.googlesource.com/c/go/+/198477 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>

view details

David Chase

commit sha 08a87938bb95ae8859600be20a998fbb4b904915

cmd/compile: make nilcheck more careful about statement relocations The earlier code was picking nodes that were "poor choices" and thus sometimes losing statements altogether. Change-Id: Ibe5ed800ffbd3c926c0ab1bc10c77d72d3042e45 Reviewed-on: https://go-review.googlesource.com/c/go/+/198478 Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org>

view details

David Chase

commit sha adc4d2cc2dbc20c14bae7bbdbca8d75421e1bef5

cmd/compile: run deadcode before nilcheck for better statement relocation Nilcheck would move statements from NilCheck values to others that turned out were already dead, which leads to lost statements. Better to eliminate the dead code first. One "error" is removed from test/prove.go because the code is actually dead, and the additional deadcode pass removes it before prove can run. Change-Id: If75926ca1acbb59c7ab9c8ef14d60a02a0a94f8b Reviewed-on: https://go-review.googlesource.com/c/go/+/198479 Run-TryBot: David Chase <drchase@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jeremy Faller <jeremy@golang.org>

view details

Cherry Zhang

commit sha d79380026cd9f3a65e4896e77a7f3fbe1a954934

[dev.link] cmd/internal/goobj: support parsing new object file Add support of parsing new object file format. We use the new parser if the magic string matches the new one, otherwise use the old one. The parsed data are still filled into the current goobj API. In the future we may consider to change the goobj API to a close match of the object file data. Now objdump and nm commands support new object file format. For a reference to a symbol defined in another package, with the new object file format we don't know its name. Write it as pkg.<#nn> for now, where nn is its symbol index. Change-Id: I06d05b2ca834ba36980da3c5d76aee16c3b0a483 Reviewed-on: https://go-review.googlesource.com/c/go/+/196031 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>

view details

Josh Bleecher Snyder

commit sha a7042249abdba39a7c8dce35661b62094eb97117

os/exec: simplify doc wording for cmd.StdoutPipe and cmd.StderrPipe The existing text was hard to parse. Shorten the sentences and simplify the text. Change-Id: Ic16f486925090ea303c04e70969e5a4b27a60896 Reviewed-on: https://go-review.googlesource.com/c/go/+/198758 Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Duco van Amstel

commit sha 8c74bfb491bc28d99b591eff0c062012e3717f68

cmd/go: fix listing of ambiguous paths Passing ambiguous patterns, ending in `.go`, to `go list` results in them being interpreted as Go files despite potentially being package references. This can then result in errors on other package references. The parsing logic is modified to check for a locally present file corresponding to any pattern ending in `.go`. If no such file is present the pattern is considered to be a package reference. We're also adding a variety of non-regression tests that fail with the original parsing code but passes after applying the fix. Fixes #32483 Fixes #34653 Change-Id: I073871da0dfc5641a359643f95ac14608fdca09b GitHub-Last-Rev: 5abc200103ffc122df05422d79cf30c3ba0ee646 GitHub-Pull-Request: golang/go#34663 Reviewed-on: https://go-review.googlesource.com/c/go/+/198459 Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>

view details

push time in 2 months

issue openedparcel-bundler/parcel

Upgrade to 1.12.4 breaks production due to wrongly reused asset hashes

<!--- Thanks for filing an issue 😄 ! Before you submit, please read the following:

Search open/closed issues before submitting since someone might have asked the same thing before! -->

🐛 bug report

After upgrading from Parcel 1.12.3 to 1.12.4 our application crashed in production with Cannot find module errors.

🎛 Configuration (.babelrc, package.json, cli command)

No .babelrc.

🤔 Expected Behavior

A minor upgrade of parcel-bundler should not break production.

😯 Current Behavior

After upgrading from Parcel 1.12.3 to 1.12.4 our application crashed in production with Cannot find module errors.

It turned out that the new version generated different bundle contents, but sometimes used the same hash in the asset filename. Since we are using static hosting with infinite caching, this meant that some changed files did not get to production, since the caching assumes that a file with the same hash in the filename also has the same content. Now loading some files built with 1.12.3 and some files with 1.12.4 caused a conflict at runtime, causing the Cannot find module error.

The concrete difference between the old and new files is that some of the internal bundle IDs changed, e.g. lI+P became lIP9.

💁 Possible Solution

Either keep the old internal IDs or ensure that the hash in the filename changes.

created time in 3 months

issue commentwasmerio/wasmer

Can't run Golang with large binary

I believe this issue is already fixed on Go master. I need to rebase my branch. Will do so later.

lucklove

comment created time in 3 months

issue commentgolang/go

syscall/js: possibility of using String.prototype.* methods on strings

This is because of JavaScript's autoboxing. string and String are two distinct types. The first is the primitive type, the second one is the boxed object type and only the second has methods. Autoboxing makes it so the expression

"foo".toUpperCase()

gets interpreted as

new String("foo").toUpperCase()

I do not yet see why syscall/js should emulate autoboxing. Is there any proper use case? In my opinion, for the examples above the proper solution is to use the .String() method to get the Go string and then use Go's functions for manipulating the string.

dmitshur

comment created time in 3 months

issue commentgolang/go

misc/wasm: using wasm_exec.js in a NodeJs project

fetch is not referenced by the wasm_exec.js on master. Your error message looks like you have a line }console.log(fetch); in your version of wasm_exec.js.

If you're planning to use net/http package, which requires fetch, then you should use a polyfill like https://www.npmjs.com/package/node-fetch.

Mikerah

comment created time in 3 months

issue commentgoogleapis/google-auth-library-nodejs

Google Cloud Function - Error: Could not load the default credentials.

I just saw the same error with one of our webhook functions after redeploying it. Special about this function was that it sent the response early with resp.sendStatus(202); and did the heavy lifting afterwards. This caused the function to already log Function execution took X ms, finished with status code: 202 early. My guess is that the function then tried to fetch the default credentials, but couldn't get them because the execution was already marked as finished.

I am now writing the webhook's payload into the database before returning 202 and then using a separate cloud function to process it asynchronously. This made the error go away.

timhj

comment created time in 4 months

issue commentgolang/go

wasm: scheduling of JavaScript callbacks is not fair

What constitutes "awake"? If one goroutine is blocked on a channel read and another is sleeping via time.Sleep, will Go immediately relinquish control to JavaScript to process pending events?

Yes, if there is no other goroutine.

sherhut

comment created time in 4 months

issue commentgolang/go

build: skip building toolchain on js/wasm?

I would be okay with skipping the build of cmd for js/wasm. Theoretically it should be possible to run the Go compiler and linker entirely in your browser, to have a Go playground that needs no server any more. In practice this needs some effort which nobody seems interested in atm.

bradfitz

comment created time in 4 months

issue commentgolang/go

wasm: scheduling of JavaScript callbacks is not fair

No, goroutines are not mapped to the event queue. If there are still goroutines awake, then the event queue will not get processed.

sherhut

comment created time in 4 months

startedpubkey/rxdb

started time in 4 months

issue commentgolang/go

runtime: js-wasm builder broken due to timeout

All right.

katiehockman

comment created time in 5 months

issue commentgolang/go

runtime: js-wasm builder broken due to timeout

@bradfitz Do you want to keep https://golang.org/cl/200438 ?

katiehockman

comment created time in 5 months

issue commentgolang/go

runtime: js-wasm builder broken due to timeout

I'll have a fix ready by tomorrow. :)

katiehockman

comment created time in 5 months

issue commentgolang/go

runtime: js-wasm builder broken due to timeout

It hangs here: https://github.com/golang/go/blob/ed7e43085ef2e2c6a1d62785b2d2b343a80039bc/test/goprint.go#L18-L20

The additional goroutine that handles async events now also counts for NumGoroutine, so it never becomes 1.

@aclements @cherrymui I am not sure how to solve this the cleanest way. Do we need to adapt the test? Should the additional goroutine not count for NumGoroutine? Or should it not count as a user goroutine at all as defined by isSystemGoroutine?

katiehockman

comment created time in 5 months

issue commentgopherjs/gopherjs

Health and future of the GopherJS open source project

I've tried again: image If you don't see the request, then maybe add mail@richard-musiol.de manually?

dmitshur

comment created time in 5 months

push eventneelance/amplitude-to-bigquery

Richard Musiol

commit sha c29f40dd15d638364943b37ce7049b9722ee5053

detect error files, retry failed downloads

view details

push time in 5 months

issue commentgolang/go

syscall/js: "goroutines are asleep" error only in Node.js

The problem with this code is that you are doing a blocking operation (fmt.Println) in a callback (listen). This causes listen to never return, thus the HTTP server never starts. This means that there is no event that can ever cause the program to continue, which is a deadlock.

If you replace fmt.Println with go fmt.Println or println, then it works as expected.

However, the stack of the hanging listen function does not show up when printing the deadlock. This is bad, I'll look into it.

agnivade

comment created time in 5 months

issue commentgolang/go

syscall/js: "goroutines are asleep" error only in Node.js

The issue is not the callback, but that there is no code at all running any more, thus the application would hang forever. Explicitly saying "this is a deadlock" is a feature, not a bug.

What are you trying to do?

agnivade

comment created time in 5 months

issue commentgolang/go

cmd/compile: wasm: LinkError: "data segment does not fit in memory"

Let's try to come up with a minimal example that triggers this bug. Maybe a large global array?

Splizard

comment created time in 5 months

issue commentgolang/go

syscall/js: "goroutines are asleep" error only in Node.js

This is expected. The following code is only used by Node.js: https://github.com/golang/go/blob/5f4aa5d79fba270d6a14f2a55999b5b6ccec2326/misc/wasm/wasm_exec.js#L525-L531

The reasoning is that if all goroutines are asleep AND there is no Node.js event handler pending, then the program can never continue, which is a "deadlock" situation. In fact, the default behavior of Node.js is to just quit with exit code 0, because there is no code to run any more 😒. I opted for throwing the error instead.

agnivade

comment created time in 5 months

issue commentgolang/go

regexp/syntax: compilation results in maximum call stack exceeded on js/wasm (safari)

I agree, there should be a way to not require 11k stack frames. Seems like I was a bit too quick with saying that there is nothing to change on Go's side...

Is there anyone in particular we should ping who is most familiar with the regexp/syntax package?

tobowers

comment created time in 5 months

issue commentgolang/go

regexp: compilation results in maximum call stack exceeded on js/wasm (safari)

The most likely explanation is that we're hitting some implementation-specific limit and Safari has the lowest limit. Unfortunately the WebAssembly spec does not specify concrete limits:

Concrete limits are usually not fixed but may be dependent on specifics, interdependent, vary over time, or depend on other implementation- or embedder-specific situations or events.

Source: http://webassembly.github.io/spec/core/appendix/implementation.html?highlight=limits#execution

Like I said, Safari is in general not an engaged player in the WebAssembly ecosystem, which is why I am inclined to say that the incompatibility should be fixed by Safari, not Go.

tobowers

comment created time in 5 months

issue commentgolang/go

regexp: compilation results in maximum call stack exceeded on js/wasm (safari)

It works fine in Chrome and Firefox, so I think this needs a fix on Safari's end. Unfortunately Safari is not investing much in proper support for WebAssembly.

tobowers

comment created time in 5 months

issue commentGoogleChrome/puppeteer

Timeouts with 1.12.2 on cloud function

@aslushnikov Can we please reopen this issue, since it is not solved yet?

neelance

comment created time in 5 months

issue commentgolang/go

proposal: add "Backlog" milestone

@andybons Thanks for the clarification. Sounds good to me.

andybons

comment created time in 5 months

issue commentgolang/go

proposal: add "Backlog" milestone

@bcmills Did I phrase it badly? I was not trying to say anything about fixing it early. I'm just saying that with every release that passes with an issue in the backlog not being fixed, the probability of "probably eventually" becomes lower. If it wasn't important enough for several releases, it is unlikely to be important enough to be included in future releases. So the issue shifts from "probably eventually" to "probably never". I'm just suggesting that a default expiry of issues from backlog to unplanned would mitigate the concern that the backlog can grow without bounds (which may or may not be a problem).

andybons

comment created time in 5 months

issue commentGoogleChrome/puppeteer

Timeouts with 1.12.2 on cloud function

I just managed to avoid the issue by not reusing the browser across function invocations. I was keeping the browser as a global variable and only initialized it once. I used try { ... } finally { page.close() } to clean up at the end of every invocation. Now I'm using try { ... } finally { browser.close() } instead.

neelance

comment created time in 5 months

issue commentgolang/go

proposal: add "Backlog" milestone

Backlog would be: “Given enough time, someone on the Go team will eventually address this, but not in the current release cycle.” Unplanned would be: “If you want this to ever happen, you will need to do it yourself.”

What about a maximum number of releases that an issue can stay in the backlog? If it doesn't make the cut several times in a row, then it is unlikely to do so in subsequent cycles. It effectively turns into "you will need to do it yourself."

andybons

comment created time in 5 months

issue closedgolang/go

wasm: fatal error: all goroutines are asleep - deadlock!

Version: go1.13 windows/amd64 Does this issue reproduce with the latest release? Yes

<details><summary><code>go env</code> Output</summary><br><pre> set GO111MODULE= set GOARCH=wasm set GOBIN= set GOCACHE=C:\Users\danau\AppData\Local\go-build set GOENV=C:\Users\danau\AppData\Roaming\go\env set GOEXE=.exe set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GONOPROXY= set GONOSUMDB= set GOOS=js set GOPATH=C:\projects\go set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=c:\go set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=c:\go\pkg\tool\windows_amd64 set GCCGO=gccgo set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD= set CGO_CFLAGS=-g -O2 set CGO_CPPFLAGS= set CGO_CXXFLAGS=-g -O2 set CGO_FFLAGS=-g -O2 set CGO_LDFLAGS=-g -O2 set PKG_CONFIG=pkg-config set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\danau\AppData\Local\Temp\go-build158127038=/tmp/go-build -gno-record-gcc-switches </pre></details>

</details>

Minimal Reproducible Example

package main

import (
	"fmt"
	"syscall/js"
)

func doStuffSynchronously() {
	done := make(chan bool)
	f := js.FuncOf(func(this js.Value, args []js.Value) interface{} {
		fmt.Println("DOING STUFF")
		done <- true
		return nil
	})
	defer f.Release()
	js.Global().Call("setTimeout", f, 1000)
	<-done
	fmt.Println("DONE DOING STUFF")
}

func main() {
	
	doStuffSynchronously() // <- WORKS HERE

	cb := js.FuncOf(func(this js.Value, args []js.Value) interface{} {
		fmt.Println("CB CALLED")
		doStuffSynchronously() // <- CRASHES WITH "fatal error: all goroutines are asleep - deadlock!"
		return nil
	})
	defer cb.Release()
	js.Global().Call("setTimeout", cb, 1000)

	// Prevent app from finishing while we wait for callback to execute
	neverDone := make(chan bool)
	<-neverDone
}

What did you expect to see?

I expected doStuffSynchronously() to work inside a callback just like it works outside one.

What did you see instead?

fatal error: all goroutines are asleep - deadlock!

closed time in 5 months

danaugrs

issue commentgolang/go

wasm: fatal error: all goroutines are asleep - deadlock!

@bcmills I don't see any way to relax this restriction. setTimeout can only fire its callback if the event loop continues to run. The documentation may get improved by https://github.com/golang/go/issues/34324#issuecomment-534272747. Closing this issue.

@danaugrs Btw: You can use select {} instead of neverDone.

danaugrs

comment created time in 5 months

issue commentgolang/go

syscall/js: unclear behavior of js-triggered and wrapped functions

This is great, I like it a lot! Would you mind opening a CL or pull request for the change?

torbenschinke

comment created time in 5 months

issue commentgolang/go

syscall/js: unclear behavior of js-triggered and wrapped functions

I agree that we should try to make this as easily understandable as possible.

The statement about waiting for the function to return is actually a bit earlier in the documentation:

Invoking the JavaScript function will synchronously call the Go function fn with the value of JavaScript's "this" keyword and the arguments of the invocation.

Maybe this "synchronously" is not enough. Do you have any suggestion on how we can amend this part?

torbenschinke

comment created time in 5 months

issue commentgopherjs/gopherjs

Health and future of the GopherJS open source project

@Russtopia Did you get my request on StackShare?

dmitshur

comment created time in 5 months

issue commentgolang/go

syscall/js: unclear behavior of js-triggered and wrapped functions

Current doc:

A wrapped function triggered by JavaScript's event loop gets executed on an extra goroutine. Blocking operations in the wrapped function will block the event loop. As a consequence, if one wrapped function blocks, other wrapped funcs will not be processed. A blocking function should therefore explicitly start a new goroutine.

Proposed doc:

A wrapped function triggered by JavaScript's event loop gets executed on an extra goroutine, however the event loop waits until the goroutine returns. Therefore blocking operations in the wrapped function should explicitly start a new goroutine.

@torbenschinke Could you please give me some more detail on the reasons for your change? Doing any blocking operation directly in the wrapped function most likely results in a "deadlock" error. For this result, "the event loop waits until the goroutine returns" sounds a bit too innocent. :)

torbenschinke

comment created time in 5 months

issue commentgolang/go

wasm: emit producer custom section

@xtuc Is there already some tool that prints the contents of the producer section (and checks its format while doing so)?

xtuc

comment created time in 5 months

issue commentgolang/go

cmd/compile: wasm: LinkError: "data segment does not fit in memory"

This is most likely due to https://github.com/golang/go/commit/460f9c60689c38bdd938d09903f3b414f6082a7d. Could you please check if increasing the initialSize solves the issue?

Splizard

comment created time in 5 months

issue commentgolang/go

syscall/js: unclear behavior of js-triggered and wrapped functions

This works fine for me. The code I tested:

package main

import (
	"fmt"
	"syscall/js"
)

func main() {
	outerDiv := js.Global().Get("document").Call("getElementById", "outer")
	innerDiv := js.Global().Get("document").Call("getElementById", "inner")

	outerDiv.Call("addEventListener", "click", js.FuncOf(func(this js.Value, args []js.Value) interface{} {
		fmt.Println("outer listener called")
		return nil
	}))
	innerDiv.Call("addEventListener", "click", js.FuncOf(func(this js.Value, args []js.Value) interface{} {
		args[0].Call("stopPropagation")
		fmt.Println("inner listener called")
		return nil
	}))

	select {}
}
torbenschinke

comment created time in 5 months

pull request commenttinygo-org/tinygo

WASM: Support for setting an imported function's module name

Why use //export for a WebAssembly import?

pkedy

comment created time in 5 months

pull request commenttinygo-org/tinygo

WASM: Support for setting an imported function's module name

Honestly I haven't put much thought into this name yet, other than making it similar to //go:linkname.

Unfortunately the Go compiler is currently written in a way that allows flags like //go:noinline to be associated with the function below, but more complex directives like //go:linkname are position independent. This is why //go:wasmimport now also has a localname parameter.

pkedy

comment created time in 5 months

push eventneelance/go

Richard Musiol

commit sha 89aa07149d79d712568a5bd8ff34a3424470aec5

wasi wip Change-Id: Iec4be7d71320b411f4f859a64dc8a5cc260a2288

view details

push time in 5 months

push eventneelance/go

Richard Musiol

commit sha 078213564f0a56906d9f93c6f5b678c917afd30d

add wasi/wasm Change-Id: I450230235179105aee7160ab7638387342aa6cdb

view details

Richard Musiol

commit sha 01610c51ebbb7a4ed1338c3dc784983aead3b826

WIP: better wasm imports Change-Id: Ibf712348f20ed9a484e3ac22d318401425d9c168

view details

Richard Musiol

commit sha abff2b18fc60a1043760a049b1148bdc3fd90c2c

wasi wip Change-Id: Ida9a47486df10d17993356c086aaa05af898e3b3

view details

push time in 5 months

push eventneelance/go

Russ Cox

commit sha a62887aade0fa0db4c4bd47aed72d93cb820da2c

api: add recent Go 1.13 work Change-Id: I0d1048723057dff0caf2059ce2efd63eb953ed82 Reviewed-on: https://go-review.googlesource.com/c/go/+/173947 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

Russ Cox

commit sha d6b06f025475d62c9d4615d23b463af4395b0c23

cmd/link: make it easy to find binary versions It is useful to be able to dig the Go version out of a binary, even a stripped binary. rsc.io/goversion does this for x86 binaries by disassembling the binary to find runtime/proc.go's startup-time reference to runtime.buildVersion's address. That approach is quite fragile: the implementation doesn't work for non-x86 and must be updated as the generated code changes. rsc.io/goversion finds the module version string by looking for random 16-byte framing around the actual string. This is less fragile but fairly kludgy and requires scanning the entire data segment. cmd/buildid finds the build ID by looking for an ELF note or else falling back to scanning the beginning of the text segment for a magic string. This has proved quite reliable and doesn't require scanning much of the binary. This CL makes it possible to find the Go and module versions using a scan more like the build ID scan: a symbol early in the writable data segment starts with a magic number and then has pointers to the two string variables. Setting up for "go version <binary>". For #31624. Change-Id: I78ea8c52fe1686b5cc5a829ca5f198104d10ebf0 Reviewed-on: https://go-review.googlesource.com/c/go/+/173342 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

Russ Cox

commit sha 216797b63bb3d2f54c32a968d63857d75895113e

cmd/go: make 'go version' apply to files Expand "go version" from printing just the version of the go command itself to being able to print the version of any go binary (when listed on the command line). This is a simplified version of rsc.io/goversion, which will now be deprecated in favor of "go version". (Preparatory changes to runtime, cmd/go, and cmd/link made this version information easier to find, allowing a much simpler implementation than in rsc.io/goversion.) Fixes #31624. Change-Id: I5f6f5b8392ce86a617e32ce287f6bf2aceafccff Reviewed-on: https://go-review.googlesource.com/c/go/+/173343 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

Russ Cox

commit sha a7dc6ca4b176cc4a918a73ffd0ab7df92011fdbb

net/url: document, test that PathEscape escapes / to %2F I couldn't remember and couldn't tell from the docs, so I added a test and documented what I found. Change-Id: Ic5d837c2d620b15d7a831823e94e70080f5e5324 Reviewed-on: https://go-review.googlesource.com/c/go/+/173948 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

Ian Lance Taylor

commit sha bc48cc770f966e401873436413d31436e84df2d8

runtime: gofmt defs1_netbsd_arm64.go Updates #30824 Change-Id: I3d9ad7896d528d8274ec78378a546b0356986b9d Reviewed-on: https://go-review.googlesource.com/c/go/+/174078 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

LE Manh Cuong

commit sha 8feeada50cf3f783fe3c8113d5da51ad8c0b3014

time: fix misleading error with the leading zero format When the leading zero format is used, we currently don't handle the month and year properly. For the month, we were reporting an out of range error when getnum returns zero of its own, as it also returns the month 0. That's confusing, so only check the range when getnum returns a nil error. For the year, we don't restore the value when parsing error occurs. For example, with the incorrect input "111-01", "01" will be used to report an error. So restore the value when an error occurs fix the problem. Fixes #29918 Fixes #29916 Change-Id: I3145f8c46813a0457766b7c302482e6b56f94ed6 Reviewed-on: https://go-review.googlesource.com/c/go/+/160338 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Clément Chigot

commit sha f61353f2d9fda9b5d8ae3026f815986d749d530e

runtime: enable runtime_mmap_test.go on AIX AIX doesn't allow to mmap an address range which is already mmap. Therefore, once the region has been allocated, it must munmap before being able to play with it. Change-Id: I1547782f0379024f57869f1dda8c1c9bb12d831f Reviewed-on: https://go-review.googlesource.com/c/go/+/174059 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Brandon Ryan

commit sha 06a8f6840750132ba4836e579d4763b2e482ef66

doc: clarify to use MinGW-W64 for amd64 systems Fixes #19686 Change-Id: I5c2dd60636b521425647afd0725fdd7c18e7bbbe GitHub-Last-Rev: a1c5f569409d8759d5d81da811eaf873073bfe39 GitHub-Pull-Request: golang/go#31682 Reviewed-on: https://go-review.googlesource.com/c/go/+/173997 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

Joel Sing

commit sha 3f7276c029162043f938e173e63f55d26462a2ca

cmd: update vendored golang.org/x/sys This brings in support for openbsd/arm64. Updated via 'go get' and 'go mod vendor'. Updates #31656 Change-Id: I18ffbc622d542f61ca0442b9dab28271fa2cfa85 Reviewed-on: https://go-review.googlesource.com/c/go/+/174118 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Ian Lance Taylor

commit sha 80704ec3fa79e6efb50124e8063b31a4c032a1ff

runtime: test for cgo build tag in TestGdbPythonCgo Testing whether cgo is enabled in go/build is not the same as testing whether the go tool supports cgo. They differ, for example, when using GOARCH=386 on an amd64 system, as for a cross-build cgo is disabled by default. Change-Id: Ib59106c92a3131b73ac6a91c0f7658a1769acf73 Reviewed-on: https://go-review.googlesource.com/c/go/+/174098 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

Joel Sing

commit sha 3d94dd78d464e4e802fdc9db345daea35f230ba2

runtime: add support for openbsd/arm64 Updates #31656 Change-Id: I0b7486f7381fd8bd16a76278c0e9ec9763671fcc Reviewed-on: https://go-review.googlesource.com/c/go/+/174119 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

Joel Sing

commit sha 6c04c26c651ba48a0671f5295e605b0c37ba6599

syscall: add support for openbsd/arm64 Generated on OpenBSD 6.5. Updates #31656 Change-Id: I0a7ddeee42d982ecbc226e82dec983c63e6c836d Reviewed-on: https://go-review.googlesource.com/c/go/+/174120 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Joel Sing

commit sha a4f9c2a29e175272fa1fb49c561733abe88ffe6b

cmd/link: add support for openbsd/arm64 Updates #31656 Change-Id: Iff0b2c2b2ca95f8c246436e35a22b70efb8e61d3 Reviewed-on: https://go-review.googlesource.com/c/go/+/174121 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Russ Cox

commit sha 3cafbeab2a56f52f7c8265a0b0c45d494b541f84

cmd/vendor: add golang.org/x/crypto/ed25519 Needed for Go checksum database integration in cmd/go. Generated with "go mod vendor" in client with that CL already applied. Change-Id: I1aa84977ba3a62504d3f4c069f48c07c67b83023 Reviewed-on: https://go-review.googlesource.com/c/go/+/173949 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

Russ Cox

commit sha 511484afa2fa4ab6cd85a783c77ab345c83b1b88

cmd/go: add internal/note, internal/sumweb, internal/tlog from golang.org/x/exp/sumdb Copied and updated import paths. Eventually we will probably publish these packages somewhere in golang.org/x (as non-internal packages) and then we will be able to vendor them properly. For now, copy. sumweb.globsMatchPath moved to str.GlobsMatchPath. Change-Id: I4585e6dc5daa423e4ca9669195d41e58e7c8c275 Reviewed-on: https://go-review.googlesource.com/c/go/+/173950 Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

Marcel van Lohuizen

commit sha 2ae5e7f9bf0267dbc9c6f3f88ae0f6197bfe70ef

vendor: pull in text@v0.3.2 This updates the packages from text and net to use the Unicode 11 tables. Updates golang/go#27945 Change-Id: I096e80283f37b596f2aa8bd3e5ffec6b7045469a Reviewed-on: https://go-review.googlesource.com/c/go/+/174057 Run-TryBot: Marcel van Lohuizen <mpvl@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

Daniel Theophanes

commit sha 1805f425ada8184b53175fd166b5fec7c02850a4

database/sql: check if src is nil before converting to string A nil src (NULL database value) will result in a "nil" string, which will never parse correctly in a ParseInt or similar numeric conversion. The resulting error is confusing. Check for a nil src prior to converting the value to string if the resulting string will be parsed after that. Closes #31274 Change-Id: I90f12cceff00fbbfdd3e343b04fa7e2596390e6d Reviewed-on: https://go-review.googlesource.com/c/go/+/174177 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>

view details

Cherry Zhang

commit sha 8ef45cf60b347abb1a08416fca1b6d19d317b26e

cmd/link: reduce the size of Reloc struct For linking large binaries, the slice of Relocs consumes a large amount of memory. We can reduce this memory consumption by shrinking the size of the Reloc struct. This CL moves the fields used only in external linking or only on PPC64 and S390X to a lazily initialized side struct. Linking k8s.io/kubernetes/cmd/kube-apiserver on Linux/AMD64, before: inuse_space 1240.25MB total 438.11MB 35.32% 35.32% 438.11MB 35.32% cmd/link/internal/objfile.(*objReader).readSlices after: inuse_space 1123.39MB total 306.85MB 27.31% 55.03% 306.85MB 27.31% cmd/link/internal/objfile.(*objReader).readSlices Under GOGC=5 (to simulate system under memory pressure), the max RSS reduces from ~2.05G to ~1.83G. Even with external linking the max RSS doesn't increase. Change-Id: I9bb8a8effaed24a8b3c4b1cfb93e6992b8740f91 Reviewed-on: https://go-review.googlesource.com/c/go/+/173437 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

Daniel Theophanes

commit sha 2177bfb343c4950be88536044bb38c90f05ad3ed

database/sql: add NullInt32 It is common for database integers to be represented as int32 internally. Although NullInt64 is already defined, this should remove some type casts and make working with those eaiser. For #31231 Change-Id: Ia0c37ecef035fee0734c1d1fb6f58aef6905cf5e Reviewed-on: https://go-review.googlesource.com/c/go/+/174178 Run-TryBot: Daniel Theophanes <kardianos@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

Mark Rushakoff

commit sha 2b325f8d5240fe46de768b15cb5085eddfa2b8f6

cmd/go: fix typo in "go help version" output Change-Id: I38b22786aae3d7a08cf2863ef5d15e476fe30093 GitHub-Last-Rev: 57d07dd1c711029b965afd32e1d8a3c22560276f GitHub-Pull-Request: golang/go#31711 Reviewed-on: https://go-review.googlesource.com/c/go/+/174086 Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

view details

push time in 5 months

more