profile
viewpoint

graph-gophers/graphql-go 3407

GraphQL server with a focus on ease of use

gopherjs/vecty 1771

Vecty: your frontend, in Go

gopherjs/gopherwasm 81

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/godockerize 12

Build Docker images from Go packages

neelance/goml 7

experiment on syntactic sugar for putting markup into Go code

neelance/cdp-go 6

Go client for the Chrome Debugging Protocol

push eventneelance/destiny-quest-coordinator

dependabot[bot]

commit sha a9f2e92284a48606e1504e415cae91d045dea88f

Bump elliptic from 6.5.2 to 6.5.3 Bumps [elliptic](https://github.com/indutny/elliptic) from 6.5.2 to 6.5.3. - [Release notes](https://github.com/indutny/elliptic/releases) - [Commits](https://github.com/indutny/elliptic/compare/v6.5.2...v6.5.3) Signed-off-by: dependabot[bot] <support@github.com>

view details

Richard Musiol

commit sha 488c60ddb618498cecb861dac57f9f1d1ebb4427

Merge pull request #2 from neelance/dependabot/npm_and_yarn/elliptic-6.5.3 Bump elliptic from 6.5.2 to 6.5.3

view details

push time in 2 days

PR merged neelance/destiny-quest-coordinator

Bump elliptic from 6.5.2 to 6.5.3 dependencies

Bumps elliptic from 6.5.2 to 6.5.3. <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/indutny/elliptic/commit/8647803dc3d90506aa03021737f7b061ba959ae1"><code>8647803</code></a> 6.5.3</li> <li><a href="https://github.com/indutny/elliptic/commit/856fe4d99fe7b6200556e6400b3bf585b1721bec"><code>856fe4d</code></a> signature: prevent malleability and overflows</li> <li>See full diff in <a href="https://github.com/indutny/elliptic/compare/v6.5.2...v6.5.3">compare view</a></li> </ul> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 2 days

issue commentgolang/go

misc/wasm: incorrectly checks for require("fs") validity

The CL will land in the next release cycle.

tharvik

comment created time in 5 days

issue commentfirebase/extensions

Error when mirroring data to BigQuery PartialFailureError

Awesome! Are you going to improve the logging, too?

zdenulo

comment created time in 7 days

issue commentfirebase/extensions

Error when mirroring data to BigQuery PartialFailureError

There is no document_id column.

zdenulo

comment created time in 7 days

issue commentgolang/go

syscall/js: running web assembly in Wasmer is failing on bad type flag

The error "bad type flag" is an internal error. It should not even be thrown if something is null or undefined.

The constants that you say are missing are in your own code: https://github.com/martinkunc/gowasmer/blob/master/wasm/bridge.go#L169 However, this "bridge" is a hack on an internal interface and apparently not compatible with the latest version of said interface.

martinkunc

comment created time in 8 days

pull request commentfirebase/firebase-js-sdk

Add check if crypto.getRandomValues is available

@googlebot I signed it!

neelance

comment created time in 8 days

PR opened firebase/firebase-js-sdk

Add check if crypto.getRandomValues is available

On some IE11 the randomBytes helper crashes with "TypeError: getRandomValues is not defined". The reason is not clear, maybe something pollutes self.crypto with a bad polyfill. Nevertheless it makes sense to fall back to Math.random if crypto.getRandomValues is not available.

+1 -1

0 comment

1 changed file

pr created time in 8 days

push eventneelance/firebase-js-sdk

Richard Musiol

commit sha e3a853fa897fea1a8e2952b07becf84009ed71a7

Add check if crypto.getRandomValues is available On some IE11 the randomBytes helper crashes with "TypeError: getRandomValues is not defined". The reason is not clear, maybe something pollutes self.crypto with a bad polyfill. Nevertheless it makes sense to fall back to Math.random if crypto.getRandomValues is not available.

view details

push time in 8 days

issue commentgolang/go

syscall/js: running web assembly in Wasmer is failing on bad type flag

The interface between src/syscall/js/js.go and misc/wasm/wasm_exec.js is internal and not stable. Wasmer can not use wasm_exec.js since it has no JavaScript runtime. So if Wasmer has support for syscall/js, then it seems to be a hack on their end which is using the internal interface. If there is any incompatibility with the new Go version, then it needs to be resolved on Wasmer's end. Please file an issue with the Wasmer project.

martinkunc

comment created time in 10 days

push eventneelance/godockerize

Richard Musiol

commit sha 03677d4c45101f2999e975e6a37b344dc38a5e0c

add go.mod

view details

Richard Musiol

commit sha f6858e0b8fd48fa6cc715ab0f497dd9f9d9aceff

use Alpine 3.12

view details

Richard Musiol

commit sha 30d306e72f5b625fc7f3d27d626030046864048c

adapt to go modules

view details

push time in 12 days

issue commentfirebase/extensions

Error when mirroring data to BigQuery PartialFailureError

We are also seeing PartialFailureErrors after upgrading to 0.1.6. Unfortunately I can not give more information because a PartialFailureError does not get logged in a way that allows looking at the individual errors in the errors field.

zdenulo

comment created time in 15 days

push eventneelance/destiny-quest-coordinator

dependabot[bot]

commit sha 60354d2f2bc55861e42e2ddb502365bd5383abb2

Bump lodash from 4.17.15 to 4.17.19 Bumps [lodash](https://github.com/lodash/lodash) from 4.17.15 to 4.17.19. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](https://github.com/lodash/lodash/compare/4.17.15...4.17.19) Signed-off-by: dependabot[bot] <support@github.com>

view details

Richard Musiol

commit sha fc20efa55bfce5933a8da30de203c593b1d704a6

Merge pull request #1 from neelance/dependabot/npm_and_yarn/lodash-4.17.19 Bump lodash from 4.17.15 to 4.17.19

view details

push time in 16 days

PR merged neelance/destiny-quest-coordinator

Bump lodash from 4.17.15 to 4.17.19 dependencies

Bumps lodash from 4.17.15 to 4.17.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lodash/lodash/releases">lodash's releases</a>.</em></p> <blockquote> <h2>4.17.16</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/d7fbc52ee0466a6d248f047b5d5c3e6d1e099056"><code>d7fbc52</code></a> Bump to v4.17.19</li> <li><a href="https://github.com/lodash/lodash/commit/2e1c0f22f425e9c013815b2cd7c2ebd51f49a8d6"><code>2e1c0f2</code></a> Add npm-package</li> <li><a href="https://github.com/lodash/lodash/commit/1b6c282299f4e0271f932b466c67f0f822aa308e"><code>1b6c282</code></a> Bump to v4.17.18</li> <li><a href="https://github.com/lodash/lodash/commit/a370ac81408de2da77a82b3c4b61a01a3b9c2fac"><code>a370ac8</code></a> Bump to v4.17.17</li> <li><a href="https://github.com/lodash/lodash/commit/1144918f3578a84fcc4986da9b806e63a6175cbb"><code>1144918</code></a> Rebuild lodash and docs</li> <li><a href="https://github.com/lodash/lodash/commit/3a3b0fd339c2109563f7e8167dc95265ed82ef3e"><code>3a3b0fd</code></a> Bump to v4.17.16</li> <li><a href="https://github.com/lodash/lodash/commit/c84fe82760fb2d3e03a63379b297a1cc1a2fce12"><code>c84fe82</code></a> fix(zipObjectDeep): prototype pollution (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4759">#4759</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/e7b28ea6cb17b4ca021e7c9d66218c8c89782f32"><code>e7b28ea</code></a> Sanitize sourceURL so it cannot affect evaled code (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4518">#4518</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/0cec225778d4ac26c2bac95031ecc92a94f08bbb"><code>0cec225</code></a> Fix lodash.isEqual for circular references (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4320">#4320</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4515">#4515</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/94c3a8133cb4fcdb50db72b4fd14dd884b195cd5"><code>94c3a81</code></a> Document matches* shorthands for over* methods (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4510">#4510</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4514">#4514</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lodash/lodash/compare/4.17.15...4.17.19">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~mathias">mathias</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 16 days

issue commentgolang/go

misc/wasm, runtime: calling fmt.Println in different goroutines causes a crash

This is very likely a duplicate of #38574.

albrow

comment created time in a month

issue closedgolang/go

math: inconsistent conversion from NaN to int on js/wasm

<!-- Please answer these questions before submitting your issue. Thanks! -->

What version of Go are you using (go version)?

<pre> $ go version go version go1.13.3 windows/amd64

</pre>

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

windows/amd64 js/wasm

<details><summary><code>go env</code> Output</summary><br><pre> $ go env

</pre></details>

What did you do?

The following program converts a NaN to int32. The conversion is different on js/wasm, if math.NaN() is used or the bit pattern, even if both seem to be identical.

<pre> package main

import ( "fmt" "math" )

var unan = uint64(0x7FF8000000000001)

func main() { n := math.NaN() i := int32(n) fmt.Printf("%f %d %d\n", n, i, math.Float64bits(n))

    n = math.Float64frombits(unan)
    i = int32(n)
    fmt.Printf("%f %d %d\n", n, i, math.Float64bits(n))

} </pre>

To run the wasm program, it is compiled with: GOOS=js GOARCH=wasm go build -o main.wasm main.go and loaded in a browser with the method described in github.com/golang/go/wiki/WebAssembly

What did you expect to see?

On playground and windows/amd64 the result is as expected: NaN -2147483648 9221120237041090561 NaN -2147483648 9221120237041090561

I expect to see the same result in the js console when running the wasm program.

What did you see instead?

on js/wasm the result is: NaN -2147483648 9221120237041090561 NaN 0 9221120237041090561

Both chrome and firefox give the same result.

closed time in a month

ktye

issue commentgolang/go

math: inconsistent conversion from NaN to int on js/wasm

Right, NaN can not be represented as an int32. Closing.

ktye

comment created time in a month

issue commentgolang/go

syscall/js: increase performance of Call, Invoke, and New by not allowing new slices to escape onto the heap

@cherrymui Would this be a good case for sync.Pool? Would it be okay to restrict the maximum number of arguments so we can have a pool of slices with a fixed size?

finnbear

comment created time in a month

issue commentgolang/go

misc/wasm: long tasks with Go WebAssembly

@cherrymui Maybe possible, but not trivial. An event/callback handler needs to be able to run synchronous. Yielding would make the handler return early.

jalextowle

comment created time in 2 months

issue commentgolang/go

misc/wasm: long tasks with Go WebAssembly

I don't know. In general the event loop can continue as soon as all goroutines are asleep/blocked.

jalextowle

comment created time in 2 months

issue commentgolang/go

misc/wasm: long tasks with Go WebAssembly

Preemption of goroutines to let the event loop continue is not yet implemented. I think it only makes sense to tackle this after we have WebAssembly threads. You can try time.Sleep to actively pause your goroutine after certain intervals.

jalextowle

comment created time in 2 months

issue commentgolang/go

wasm: support new WASI interface

Open source doesn't mean work is not paid or not compensated in other ways.

@inliquid Just to be clear: I am not getting compensated for my work on WebAssembly/WASI in any way. I am not even using it at my day job. I just work on it because I believe it should exist.

@icholy The phrasing of your comment is ambiguous, at least to me.

johanbrandhorst

comment created time in 2 months

issue commentgolang/go

net/http: “protocol not available” and “fetch failed” when running with Denoland and GOARCH=wasm go run but not with browser

https://www.npmjs.com/package/node-fetch#class-headers

carlskii

comment created time in 2 months

issue commentgolang/go

net/http: “protocol not available” and “fetch failed” when running with Denoland and GOARCH=wasm go run but not with browser

The line of this crash refers to the global Headers constructor: https://github.com/golang/go/blob/cd8f8026bb3bf78889e406e3253aad047e49b2e4/src/net/http/roundtrip_js.go#L80 Seems like you need to set this, too.

carlskii

comment created time in 2 months

issue commentgolang/go

runtime: compiled WASM with NodeJS fails with “ TypeError: (intermediate value).arrayBuffer is not a function”

wasm_exec.html is not meant to be used with Node.js. Either simply use go run ... or use the go_js_wasm_exec helper for running the wasm binary.

carlskii

comment created time in 2 months

issue commentgolang/go

wasm: support new WASI interface

See https://github.com/golang/go/issues/38248 for what I was working on. No ETA though. Depends on how much time I get to spend on contributing to the Go project.

johanbrandhorst

comment created time in 2 months

issue commentgolang/go

cmd/compile: uncaught RuntimeError: memory access out of bounds

@hajimehoshi Seems unlikely, because js/wasm is still experimental. See https://github.com/golang/go/wiki/MinorReleases for the policy on backports.

hajimehoshi

comment created time in 2 months

issue commentgolang/go

proposal: replace CallImport with go:wasmimport directive

Does go:wasmimport work for arbitrary modules and functions, or only for a list of special functions?

There is no list. The parameter types need to be supported. Like I said above, I would be okay with restricting it to runtime and syscall/js if people are worried about usage outside of the Go project itself.

A bit bikeshedding: is "go" the best name for wasm_exec.js?

I am fine with changing this name. No preference on my end.

neelance

comment created time in 2 months

issue commentgolang/go

proposal: replace CallImport with go:wasmimport directive

My goal with go:wasmimport is to support WASI and it will do whatever WASI needs now or in the future. I think this is very reasonable, because WASI will set certain standards in the WebAssembly ecosystem on how to pass data between WebAssembly modules. This may include other aspects than the calling convention.

I do not want to define some "WebAssembly interface for Go" here, since I believe this is too early and Go should rather follow the WebAssembly ecosystem (namely WASI) than to diverge with its own interface. So if there is some concern about other people using this interface, then I would be okay with restricting go:wasmimport to the runtime and syscall/js packages. If people really want to experiment in other contexts, then they would need to patch the Go compiler first.

neelance

comment created time in 3 months

issue commentsverweij/dependency-cruiser

Feature request: exit code for depcruise-fmt

We're now using this together with #297. Thanks.

neelance

comment created time in 3 months

issue commentsverweij/dependency-cruiser

Feature request: hide nodes from dot output without fully excluding them

This works great. Thanks! 👍

neelance

comment created time in 3 months

starteddenoland/deno

started time in 3 months

issue commentgolang/go

proposal: replace CallImport with go:wasmimport directive

On the lowest level the ABI consists of passing data via arguments (on the WebAssembly stack) to WebAssembly's call instruction. There may be higher level additions in the future, such as a standardized way of how to pass strings, but currently this seems to be still in development. So by "ABI used by WASI" I really mean whatever WASI is doing right now and in the future.

neelance

comment created time in 3 months

issue commentgolang/go

proposal: replace CallImport with go:wasmimport directive

Here is the new full proposal text:


The wasm architecture currently uses a special CallImport assembler instruction to call function imports. This approach is quite inflexible and only compatible with the ABI used by wasm_exec.js.

The WebAssembly ecosystem is converging on using WASI (WebAssembly System Interface) as a standardized interface between the WebAssembly binary and its host (similar to system calls). I am working on adding support for WASI to Go. As a first step, Go needs to be able to use function imports with the ABI used by WASI.

For this reason I propose to replace CallImport with a new compiler directive go:wasmimport. It can be used like this:

//go:wasmimport importmodule importname

Concrete example:

//go:wasmimport wasi_unstable proc_exit
func __wasi_proc_exit(code int32)

importmodule and importname identify the function to import. WebAssembly functions always live within a module. For WASI this module is currently called wasi_unstable, see here. For wasm_exec.js it is called go, see https://github.com/golang/go/blob/aa3413cd98b6e11fe0d37d3d2a489a9cd83b47ad/misc/wasm/wasm_exec.js#L261-L262

By default go:wasmimport will use the ABI used by WASI. There is a special case for backwards compatibility with wasm_exec.js: If importmodule is go, then the arguments will get passed in a way so wasm_exec.js can read them from memory with Go's ABI0 layout. This special case will be removed once the interface of wasm_exec.js has been fully superseded by WASI (currently it is still missing certain features).

The go:wasmimport directive will not be covered by Go's compatibility promise as long as the wasm architecture itself is not considered stable.

neelance

comment created time in 3 months

startedsverweij/dependency-cruiser

started time in 3 months

issue commentsverweij/dependency-cruiser

Feature request: hide nodes from dot output without fully excluding them

I want to apply checks (rules) on where certain npm dependencies get used, but omit them from the dependency graph since they get used a lot and just clutter the graph without giving much information. Same goes for some internal utility modules.

The goal of the dependency graph is to help us with giving our application a proper overall structure. External npm packages and internal utility modules usually have a clear semantic boundary (no outgoing dependencies to other parts of our app (which I want to check)), so I don't worry about them that much with regards to the overall structure.

Does this answer help?

neelance

comment created time in 3 months

issue openedsverweij/dependency-cruiser

Feature request: hide nodes from dot output without fully excluding them

I would like to exclude nodes from the dot graph, but still validate rules on them. Is this already possible? I think the easiest way would be to do so via reporterOptions.

I see two alternatives:

  • Manually filter the output json before passing it to depcruise-fmt. An option would be simpler.
  • Run depcruise twice with different configs. This is slower because of duplicate work.

created time in 3 months

issue openedsverweij/dependency-cruiser

Feature request: exit code for depcruise-fmt

I figured out to first use depcruise --output-type json to do the analysis and then invoke depcruise-fmt two times to generate a dependency graph and an error log. What I couldn't figure out is how to still get a proper exit code that makes our CI system fail if dependency rules are violated. Is this a missing feature of depcruise-fmt?

created time in 3 months

issue commentsverweij/dependency-cruiser

wrong priority of extensions

Thanks @sverweij, it works well.

neelance

comment created time in 3 months

issue commentWebAssembly/design

Please Support Arbitrary Labels and Gotos.

Could someone in charge of V8 confirm in this thread that the opposition against irreducible control flow is not influenced by V8's current implementation?

I am asking because this is what bugs me most. To me it seems like this should be a discussion on the spec level about pros and cons of this feature. It should not at all be influenced by how a particular implementation is currently designed. However, there have been statements that make me believe that V8's implementation is influencing this. Maybe I am wrong. An open statement might help.

oridb

comment created time in 3 months

more