profile
viewpoint

graph-gophers/graphql-go 3322

GraphQL server with a focus on ease of use

gopherjs/vecty 1708

Vecty: your frontend, in Go

gopherjs/gopherwasm 82

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

neelance/go-angularjs 77

GopherJS bindings to AngularJS

neelance/ffi_gen 75

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

Build Docker images from Go packages

neelance/cdp-go 6

Go client for the Chrome Debugging Protocol

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 3 days

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 9 days

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 9 days

issue commentsverweij/dependency-cruiser

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

This works great. Thanks! 👍

neelance

comment created time in 9 days

starteddenoland/deno

started time in 13 days

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 16 days

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 16 days

startedsverweij/dependency-cruiser

started time in 22 days

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 22 days

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 22 days

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 22 days

issue commentsverweij/dependency-cruiser

wrong priority of extensions

Thanks @sverweij, it works well.

neelance

comment created time in 22 days

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 23 days

issue commentTristonJ/eslint-plugin-prefer-arrow

allowStandaloneDeclarations does not apply to exported functions

Thank you. It works well.

neelance

comment created time in 25 days

issue commentgolang/go

proposal: replace CallImport with go:wasmimport directive

All right, I agree that it is good to discourage anyone else from using abi0 by exposing it less. Shall I edit the proposal in the first post or add a new version below?

neelance

comment created time in 25 days

startedbradfitz/shotizam

started time in a month

issue commentgolang/go

proposal: replace CallImport with go:wasmimport directive

So let's make the proposal what we both want, that it applies to the next function.

Great!

Will other importmodules use that same ABI?

They should not.

is it the case that long term nothing will say abi0? That is, will it be that some future Go release removes support for the abi0 annotation?

Yes, that's the long term plan, but I can't say when this will be the case. It depends a lot on how fast the development of WASI goes until it has enough features to completely replace the custom interface that wasm_exec.js currently uses.

I don't mind picking a different flag name than abi0. Making it implicit with the name of the importmodule feels a bit bad to me, but I do not strongly oppose it either.

neelance

comment created time in a month

issue commentsverweij/dependency-cruiser

wrong priority of extensions

Hi @sverweij. Thanks for the quick response and your work on the project. I'll wait for your fix and I'm looking forward to using dependency cruiser.

neelance

comment created time in a month

issue openedsverweij/dependency-cruiser

wrong priority of extensions

Each of our UI components consist of a .ts and a .vue file with the same name. An import without an extension prefers the .ts file. The .ts file then imports the .vue file with explicit extension. Dependency cruiser seems to default to the .vue files, so the dependency graph has edges to the .vue files instead of the .ts files.

created time in a month

issue openedTristonJ/eslint-plugin-prefer-arrow

allowStandaloneDeclarations does not apply to exported functions

Thanks for adding the allowStandaloneDeclarations option. However, this is still disallowed:

export function test() {
}

I think it should be allowed if allowStandaloneDeclarations is set.

created time in a month

PR opened a-fas/mt940js

do not discard spaces at line end

A long "details" field may wrap over more than one line. A space character right before the line wrap should not be discarded.

+3 -8

0 comment

2 changed files

pr created time in a month

push eventneelance/mt940js

Richard Musiol

commit sha 262e1df77549d05396d69510dee56f76cd2631d3

do not discard spaces at line end A long "details" field may wrap over more than one line. A space character right before the line wrap should not be discarded.

view details

push time in a month

fork neelance/mt940js

Swift MT940 bank statement javascript parser

fork in a month

issue commentgolang/go

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

This is the same issue as #38574, please see my analysis there.

hajimehoshi

comment created time in a month

issue commentgolang/go

runtime: wasm runtime crashes under certain/undefined conditions

I managed to debug the issue. What is happening is that https://github.com/golang/go/blob/b0a87544754a41312aa454f69d4e820979f19ef0/src/runtime/lock_js.go#L196-L200 wakes up the innermost event handler, but then findrunnable of proc.go schedules a different goroutine instead of the e.gp here. This messes up the wasm event handling. It is a bit strange that another goroutine gets scheduled because the code above (beforeIdle) got called because no goroutine was awake any more. I guess there is some internal timer logic that if triggered at the very right moment makes some goroutine available.

I see three possible solutions:

  1. Make the event handler detect this situation and go to sleep once more. This can be done by changing https://github.com/golang/go/blob/b0a87544754a41312aa454f69d4e820979f19ef0/src/runtime/lock_js.go#L243 to
	gopark(nil, nil, waitReasonZero, traceEvNone, 1)
	for events[len(events)-1] != e {
		gopark(nil, nil, waitReasonZero, traceEvNone, 1)
	}
  1. Make findrunnable not check the timers. One way to do this is to change https://github.com/golang/go/blob/b0a87544754a41312aa454f69d4e820979f19ef0/src/runtime/proc.go#L2276-L2279 to
	if beforeIdle(delta) {
		// At least one goroutine got woken.
		if gp, inheritTime := runqget(_p_); gp != nil {
			return gp, inheritTime
		}
		throw("findrunnable: no goroutine woken by beforeIdle")
	}
  1. Option 2 does not seem very clean to me. I guess there should be some way t make beforeIdle return the specific goroutine e.gp that needs to run next. I wasn't able to quickly figure out how to do this.

@ianlancetaylor @cherrymui I am not sure which way is a good solution. Do you have any preference?

mihaiav

comment created time in a month

issue commentgolang/go

proposal: replace CallImport with go:wasmimport directive

I fully agree that a version without localname would be better. In fact this was my initial plan.

However, all the current directives that apply to the next function are just flags without any parameters. They get processed by the pragmaValue function in lex.go and the return type is type Pragma uint16. No arguments possible.

This is why I opted for not doing a large change to Go's lexer/parser and instead copied a solution that already exists: //go:linkname.

About the abi flag: The default should be the abi that wasi uses, since it is a more native way to pass arguments to a WebAssembly function. The abi0 flag only needs to exist so I don't have to change everything in a massive CL. This way I can still support the abi that wasm_exec.js uses and slowly migrate to wasi. Having a special case for the importmodule go is possible, sure, but such implicit behavior change seems bad to me.

neelance

comment created time in a month

issue commenttypescript-eslint/tslint-to-eslint-config

v0.6.0 not on npm

Thanks! 👍

neelance

comment created time in a month

issue openedtypescript-eslint/tslint-to-eslint-config

v0.6.0 not on npm

Just asking: Is there a reason why the latest version on npm is still 0.5.1 but 0.6.0 got released on GitHub?

created time in a month

issue commentgolang/go

x/text/unicode/norm: tests run over 10 minutes and time out on js/wasm

The latest nightly of Node.js still fails to instantiate the WebAssembly module in a reasonable amount of time. It reports the following V8 version:

> node --version
v14.0.0-nightly202004175a4f24e7e1
> node -p process.versions.v8
8.1.307.26-node.12

However, Chrome 80.0.3987.163 with V8 8.0.426.30 is able to instantiate the module in a few seconds.

Node.js is using the newer V8 version, so I guess the issue is on Node.js' side, not V8's.

bradfitz

comment created time in a month

issue commentgolang/go

proposal: replace CallImport with go:wasmimport directive

Right, I forgot to include a clear explanation of the arguments of the directive. The usage is like this:

//go:wasmimport localname importmodule importname [abi0]

localname is the name of the Go function, same as with //go:linkname.

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.

[abi0] is the optional flag to indicate that this import is using the ABI0 way for passing arguments.

Hope this helps.

neelance

comment created time in a month

push eventneelance/destiny-quest-coordinator

Richard Musiol

commit sha 0bf5c0a1485b63b52b7fede48e409143b24cc882

fix login redirect

view details

push time in a month

push eventneelance/destiny-quest-coordinator

Richard Musiol

commit sha 113cf4bcddacc2fad58e1621b3c6d1cc6a53e9f6

fix public path

view details

push time in a month

push eventneelance/destiny-quest-coordinator

Richard Musiol

commit sha d3304fe3246d03bda8b5eee48f70c3449be4d738

add .nojekyll

view details

push time in a month

create barnchneelance/destiny-quest-coordinator

branch : master

created branch time in a month

created repositoryneelance/destiny-quest-coordinator

created time in a month

startedeclipse-theia/theia

started time in 2 months

issue openedobservablehq/runtime

Lazy evaluation

I hope I am not asking for a feature that already exists. I couldn't find an elegant solution for it.

I have a notebook that now uses 5 data sources: https://observablehq.com/@neelance/corvid-19-trends Initially only the first source gets displayed, so it is not nice that all downloads have to be done at page load and only afterwards the graph gets displayed.

Now I could manually wrap all data dependencies in some function that returns a Promise, but isn't this something that Observable could do automatically? E.g. instead of using data directly, I could use it with some keyword like lazy so that lazy data would return a function with the type () => Promise<Data>. Then I could only call the function if this is the data I currently want to display and Observable would only evaluate the data cell and its dependencies if necessary. This of course assumes that the data cell got imported form another notebook, so its result is not getting displayed directly.

created time in 2 months

issue openedgolang/go

proposal: replace CallImport with go:wasmimport directive

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 __wasi_proc_exit wasi_unstable proc_exit
func __wasi_proc_exit(code int32)

By default go:wasmimport will use the ABI used by WASI. An optional parameter can be used for backwards compatibility with wasm_exec.js. This parameter is called abi0 because wasm_exec.js is reading the parameters form memory with Go's normal ABI0 layout:

//go:wasmimport wasmExit go runtime.wasmExit abi0
func wasmExit(code int32)

I do not plan to add other ABIs. On the contrary, the abi0 mode is supposed to go away once WASI can be used as the primary interface (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.

created time in 2 months

issue openedparcel-bundler/parcel

Strict mode broken for Vue.js bundle

<!--- 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

Parcel generates this code for the Vue.js bundle:

},{[...],"node_modules/vue/dist/vue.runtime.esm.js":[function(require,module,exports) {
var global = arguments[3];
"use strict";

Object.defineProperty(exports, "__esModule", {
  value: true
});
exports.default = void 0;

/*!
 * Vue.js v2.6.10
 * (c) 2014-2019 Evan You
 * Released under the MIT License.
 */
[...]

The problem is that the var global = arguments[3]; statement is above the "use strict"; statement, so the strict mode setting gets ignored because it must be the first statement of the function. This makes all Vue.js code run in "sloppy mode".

<!--- Provide a general summary of the issue here -->

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

Nothing relevant.

💁 Possible Solution

The responsible line of code for prepending var global is: https://github.com/parcel-bundler/parcel/blob/f01437e7f646f4aa74a5d3cf48ed7c4f21822352/packages/core/parcel-bundler/src/assets/JSAsset.js#L182

🔦 Context

I am investigating a bug that only occasionally happens in production. This made me notice that certain types of errors are silent in the Vue.js bundle, but they should not be silent because of strict mode.

created time in 2 months

pull request commentdominikh/go-js-dom

v2: fix js.Value argument in PutImageData and PutImageDataDirty

syscall/js can not depend on reflect. Also it seems preferable to keep it simple. The use of syscall/js will never be pretty, wrapper libraries need to hide it from the user.

dmitshur

comment created time in 2 months

startednytimes/covid-19-data

started time in 2 months

startedpion/webrtc

started time in 2 months

startedpion/ion

started time in 2 months

issue closedneelance/covid19-trends

Today's numbers did not change

Hi! The numbers in the graph did not change today. I saw this already last night, but now it is still the same problem. And this is the graph that I look at every day, it is a great resource. Maybe the problem is not your code, but something at the data source.

Edit: It was fixed now!

closed time in 2 months

pietkuip

issue commentneelance/covid19-trends

Today's numbers did not change

Yes, the data source had an issue. They also deprecated the source I was using, so I already changed to the new format now.

pietkuip

comment created time in 2 months

push eventneelance/go

Richard Musiol

commit sha 40aec9a29ab0c01172bdc4daaca7ee0942dd00bf

cmd/compile: replace CallImport with go:wasmimport directive This change replaces the special assembler instruction CallImport of the wasm architecture with a new go:wasmimport directive. This new directive is cleaner and has more flexibility with regards to how parameters get passed to WebAssembly function imports. This is a preparation for adding support for wasi (WebAssembly System Interface). The default mode of the directive passes Go parameters as individual WebAssembly parameters. This mode will be used with wasi. The second mode "abi0" only passes the current SP as a single parameter. The called function then reads its arguments from memory. This is the method currently used by wasm_exec.js and the goal is to eventually remove this mode. Change-Id: Ibf712348f20ed9a484e3ac22d318401425d9c168

view details

Richard Musiol

commit sha 691118ec5704cba0231e7de3440c557cca05bec5

add wasi/wasm Change-Id: I450230235179105aee7160ab7638387342aa6cdb

view details

Richard Musiol

commit sha c47c426cdcc6005ee9ef1b3cfa78413ec56620a5

wasi wip Change-Id: Ia1c96a8461c7c11b8fcb173f9108a5ffbc277510

view details

push time in 2 months

push eventneelance/go

Richard Musiol

commit sha 597970747b8075ea25423a1060026236a5fa67c1

WIP: better wasm imports Change-Id: Ibf712348f20ed9a484e3ac22d318401425d9c168

view details

Richard Musiol

commit sha 9acfb7d0c3c213593974ff224f029ed3183666a7

wasi wip Change-Id: Ia1c96a8461c7c11b8fcb173f9108a5ffbc277510

view details

push time in 2 months

issue commentwasmerio/wasmer-js

wasm-transformer: add support for lowing phase 4 proposals

I'm not a rust dev (yet), so I can not easily contribute directly. My current focus is on adding support for wasi to Go.

neelance

comment created time in 2 months

issue openedwasmerio/wasmer-js

wasm-transformer: add support for lowing phase 4 proposals

As far as I can see, nowadays Safari is very slow with adopting modern web features. All other major browsers have support for https://github.com/WebAssembly/nontrapping-float-to-int-conversions and https://github.com/WebAssembly/sign-extension-ops except Safari, including its "technology preview" version.

Unfortunately Safari is the default browser on all iOS devices and alternative browsers are required to use Safari's renderer. So it is infeasible to ship WebAssembly binaries with new features that are not supported by Safari.

This is why I would like to suggest to add support to wasm-transformer for lowering phase 4 proposals. Ideally it would do automatic feature detection and only apply the necessary lowering.

created time in 2 months

issue closedwasmerio/webassembly.sh

"Error: undefined is not a function" when trying to run wasm binary

I tried running a wasm binary built with the Go compiler. I am able to run it locally with wasmer:

> wasmer run hello-go.wasm
Hello world!

However, I get an error when trying to run it with WebAssembly.sh:

$ hello-go
Error: undefined is not a function

Am I doing something wrong?

closed time in 2 months

neelance

issue commentmollie/mollie-api-node

v3: Various invalid TypeScript definitions

I just ran into this issue. I think I'll just use plain HTTP requests for now.

Karasuni

comment created time in 3 months

issue commentgolang/go

wasm: support new WASI interface

@philippgille I've updated my fork and just successfully ran a Go program on webassembly.sh. Try hello-go.

johanbrandhorst

comment created time in 3 months

push eventneelance/go

Richard Musiol

commit sha 7a9055e5f130d6a08ccd739e0b8dada12ca27ff1

wasi wip Change-Id: Ia1c96a8461c7c11b8fcb173f9108a5ffbc277510

view details

push time in 3 months

push eventneelance/go

Ian Lance Taylor

commit sha 2d6f8cc2cdd5993eb8dc80655735a38ef067af6e

doc/go1.14: mention increased number of EINTR errors Updates #36281 Change-Id: I3c4487caaf47566212dc62322b2e884e695ea7f1 Reviewed-on: https://go-review.googlesource.com/c/go/+/212657 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>

view details

Ian Lance Taylor

commit sha 4f757179543e06daec58df6af5884516f8bceb86

io: show ErrUnexpectedEOF in ExampleReadAtLeast Fixes #36245 Change-Id: I10ce50b0cc28b15f4e7be85b8f12cf9d0e4fac96 Reviewed-on: https://go-review.googlesource.com/c/go/+/212404 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>

view details

Michael Anthony Knyszek

commit sha dcd3b2c173b77d93be1c391e3b5f932e0779fb1f

runtime: check whether scavAddr is in inUse on scavengeOne fast path This change makes it so that we check whether scavAddr is actually mapped before trying to look at the summary for the fast path, since we may segfault if that that part of the summary is not mapped in. Previously this wasn't a problem because we would conservatively map all memory for the summaries between the lowest mapped heap address and the highest one. This change also adds a test for this case. Change-Id: I2b1d89b5e044dce81745964dfaba829f4becdc57 Reviewed-on: https://go-review.googlesource.com/c/go/+/212637 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>

view details

Tobias Klauser

commit sha 4b4370066f97ac40a4f095ca56a7b21a375aa5aa

syscall: use fcntl64 on 32-bit GNU/Linux systems Use fcntl64Syscall in forkAndExecInChild1 to get fcntl64 on 32-bit Linux systems. Updates #36211 Change-Id: Id0e34359256beace970e72102fdace7a987ff2b0 Reviewed-on: https://go-review.googlesource.com/c/go/+/212598 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Josh Bleecher Snyder

commit sha 53dede938b5c3322627a846e6c073d8d45dc21ac

cmd/compile: fix typo in comment Change-Id: I25fbd63f10ea9892589ad44cc45761926aff0648 Reviewed-on: https://go-review.googlesource.com/c/go/+/212841 Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Tobias Klauser

commit sha aa175a196d74f2788ec3d02b990487f7ca2af5b0

internal/syscall/unix: use libc based fcntl for IsNonblock on aix and solaris On aix and solaris (like on darwin) use libc fcntl to implement IsNonblock instead of Syscall(SYS_FCNTL, ...) which isn't supported. Change-Id: I989b02aa0c90b7e2dae025572867dda277fef8be Reviewed-on: https://go-review.googlesource.com/c/go/+/212600 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Tobias Klauser

commit sha bbd25d26c0a86660fb3968137f16e74837b7a9c6

internal/poll: use correct fcntl implementations Use the libc fcntl (via syscall.fcntl) on aix and solaris like it is already done for darwin. For the syscall-based fcntl implementation use FcntlSyscall from internal/syscall/unix in order to get fcntl64 on 32-bit Linux systems. On aix, fcntl with F_DUPFD_CLOEXEC is not supported. Thus, defined F_DUPFD_CLOEXEC = 0 in the syscall package and check its value before calling fcntl(fd, syscall.F_DUPFD_CLOEXEC, 0). On js/wasm, fcntl is not supported thus let its implementation return ENOSYS directly. Updates #36211 Change-Id: I96a2ea79e5c4eed2fefd94d0aefd72c940825682 Reviewed-on: https://go-review.googlesource.com/c/go/+/212278 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Dmitri Shuralyov

commit sha bf268472408b0f46767d46ae1d14439e5eb84014

doc: 2020 is the Year of the Gopher Starting with 2014 (golang.org/cl/46660043), we have enjoyed 6 consecutive years of the gopher. Now, the slice¹ of gophers is ready to make its way into the next decade, as 2020 is the new Year of the Gopher. ¹ https://en.wikipedia.org/w/index.php?title=List_of_English_terms_of_venery,_by_animal&oldid=932675028#G Change-Id: I5f9598dbedb373bd13021964193fa9e44c67693e Reviewed-on: https://go-review.googlesource.com/c/go/+/213017 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: David Symonds <dsymonds@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Rhys Hiltner

commit sha a4c579e8f7c8129b2c27779f206ebd2c9b393633

runtime: emit trace event in direct semaphore handoff When a goroutine yields the remainder of its time to another goroutine during direct semaphore handoff (as in an Unlock of a sync.Mutex in starvation mode), it needs to signal that change to the execution tracer. The discussion in CL 200577 didn't reach consensus on how best to describe that, but pointed out that "traceEvGoSched / goroutine calls Gosched" could be confusing. Emit a "traceEvGoPreempt / goroutine is preempted" event in this case, to allow the execution tracer to find a consistent event ordering without being both specific and inaccurate about why the active goroutine has changed. Fixes #36186 Change-Id: Ic4ade19325126db2599aff6aba7cba028bb0bee9 Reviewed-on: https://go-review.googlesource.com/c/go/+/211797 Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>

view details

Cherry Zhang

commit sha ffbc02761abb47106ce88e09290a31513b5f6c8a

runtime: ensure memmove write pointer atomically on ARM64 If a pointer write is not atomic, if the GC is running concurrently, it may observe a partially updated pointer, which may point to unallocated or already dead memory. Most pointer writes, like the store instructions generated by the compiler, are already atomic. But we still need to be careful in places like memmove. In memmove, we don't know which bits are pointers (or too expensive to query), so we ensure that all aligned pointer-sized units are written atomically. Fixes #36101. Change-Id: I1b3ca24c6b1ac8a8aaf9ee470115e9a89ec1b00b Reviewed-on: https://go-review.googlesource.com/c/go/+/212626 Reviewed-by: Austin Clements <austin@google.com>

view details

Austin Clements

commit sha 73b657e96e498e0b6314e6054795f81400de4afc

doc/go1.14: mention sync.Mutex changes Change-Id: Icd92d115e5d7f00b2100598baf2522ebebcdb223 Reviewed-on: https://go-review.googlesource.com/c/go/+/213125 Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Katie Hockman

commit sha a65f08830151101d4fbb524edfa2bc792932f8cc

doc: add section for checksum database to module reference doc Updates #33637 Change-Id: Ia782b3fdc5a8873606b96120a34c9bf194a1a346 Reviewed-on: https://go-review.googlesource.com/c/go/+/211197 Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

Emmanuel T Odeke

commit sha f376b8510ed7884c69a09fbcf61418f7285f2787

all: fix invalid invocations of Fatalf in goroutines Found by running the go vet pass 'testinggoroutine' that I started in CL 212920. Change-Id: Ic9462fac85dbafc437fe4a323b886755a67a1efa Reviewed-on: https://go-review.googlesource.com/c/go/+/213097 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>

view details

Dmitri Shuralyov

commit sha 0bd3853512ea0dcb252ce02113d3929db03d6aa6

doc: remove root.html and conduct.html (moved to x/website) root.html has been moved to the x/website repo in CL 180959 (commit golang/website@d83058ced3fadc3e8189107d2fb86c333c356b75). conduct.html has been moved to the x/website repo in CL 207437 (commit golang/website@99763cba2e5b53679a96f69725f917feb319b799). There should be only one copy, otherwise it may lead to confusion, or changes made in the wrong place. This CL removes the old copies from this repo since they're no longer used. Updates #29206 Change-Id: I41adfb2c34ed3d870fb7a671f48ccc8f90863feb Reviewed-on: https://go-review.googlesource.com/c/go/+/213157 Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

Michael Matloob

commit sha a7be8cccf80e04bb5c09e9f8c53d2eec4bc36d3a

cmd/go: convert tests using testdata/src/syntaxerror to scripts This includes TestMatchesNoTestsDoesNotOverrideBuildFailure and TestErrorMessageForSyntaxErrorInTestGoFileSaysFAIL. Convert the tests that use the testdata/src/syntaxerror directory to the script framework. Part of converting all tests to script framework to improve test parallelism. Updates #36320 Updates #17751 Change-Id: I2b2b616e8c124996ae8c8e5b737f15bb493ec588 Reviewed-on: https://go-review.googlesource.com/c/go/+/212816 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

Michael Matloob

commit sha 8cc2b73a7439e303d015e53176575e649ace68bf

cmd/go: convert TestPluginNonMain to script framework TestPluginNonMain was broken before this change! (It provided the wrong directory for testdep/p2: testdata/testdep/p2 instead of testdata/src/testdep/p2). Change-Id: Ib815f119bae1d758b500cd8ad82c016cb630d71e Reviewed-on: https://go-review.googlesource.com/c/go/+/212938 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

Michael Matloob

commit sha 4ffd1a0f1ca5f92d4185d02c3f1be00683d755e2

cmd/go: remove TestGoTestDetectsTestOnlyImportCycles The error that's tested in this test is also tested in list_test_err.txt which uses go list -test -deps. Because both commands are just loading packages, the difference is not meaningful. Updates #36320 Updates #17751 Change-Id: Ie712a77d64e8985dd908a1afb515ed3ecc0a9985 Reviewed-on: https://go-review.googlesource.com/c/go/+/212937 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

Michael Matloob

commit sha c57665f4e62d713e3f4c20c3e8ea075f712b1c65

cmd/go: convert TestCoveragePattern to the script framework This test already runs in parallel, but still convert it to the script framework so we can delete the testdata/src directory and remove any ambiguity about which tests can run in parallel. Updates #36320 Change-Id: I6470979bd8bad0631dc6ead0d4eb9c83878356e8 Reviewed-on: https://go-review.googlesource.com/c/go/+/212815 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

Michael Matloob

commit sha 421cefdc59fe4797a75558860964e76b4d9befbd

cmd/go: convert TestRunInternal to the script test framework This conversion is a bit weird, because the original test runs in the cmd/go directory, while the script test runs in the GOPATH directory. So even though it's not necessary for the new test, it changes dircectory to $WORK, so that its error message regexp can have four components like the original, just changing the old gopath directory 'testdata' the new one 'gopath'. Part of converting all tests to script framework to improve test parallelism. Updates #36320 Updates #17751 Change-Id: Ie5b029c43dc22167278d3104b37c0b57c61326be Reviewed-on: https://go-review.googlesource.com/c/go/+/212814 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

Michael Matloob

commit sha 0d09b7e041e24fd2707282b5440e029019c73190

cmd/go: convert TestGoBuildNotMain to script framework Part of converting all tests to script framework to improve test parallelism. Updates #36320 Updates #17751 Change-Id: Icd62dc8db55bec52ad326bc370ee7e435aae2559 Reviewed-on: https://go-review.googlesource.com/c/go/+/212812 Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by: Jay Conrod <jayconrod@google.com>

view details

push time in 3 months

issue commentwasmerio/webassembly.sh

"Error: undefined is not a function" when trying to run wasm binary

You are right, a hard-refresh solved it. Are there known caching issues?

neelance

comment created time in 3 months

issue openedwasmerio/webassembly.sh

"Error: undefined is not a function" when trying to run wasm binary

I tried running a wasm binary built with the Go compiler. I am able to run it locally with wasmer:

> wasmer run hello-go.wasm
Hello world!

However, I get an error when trying to run it with WebAssembly.sh:

$ hello-go
Error: undefined is not a function

Am I doing something wrong?

created time in 3 months

push eventneelance/covid19-trends

Richard Musiol

commit sha 61cf53999154c2e5b776da75723425b780db1cfe

Update README.md

view details

push time in 3 months

push eventneelance/covid19-trends

Richard Musiol

commit sha f7912e6e5f230a5416f04d1706e76cc4027e0748

Update README.md

view details

push time in 3 months

create barnchneelance/covid19-trends

branch : master

created branch time in 3 months

created repositoryneelance/covid19-trends

A graph showing COVID-19 case statistics in an easy to grasp way

created time in 3 months

startedCSSEGISandData/COVID-19

started time in 3 months

issue commentgolang/go

runtime: mlock of signal stack failed: 12

Everyone please keep in mind that successful communication is hard and a skill one needs to practice. Emotions can work against us and hinder our goal of successful communication, I've been there myself. Yes, there has been a violation of the code of conduct and pointing it out is good. A voluntary apology is also helpful. Now let's try to make sure that every post has a positive net impact on collaboration and solving this issue.

karalabe

comment created time in 3 months

issue commentgolang/go

runtime: mlock of signal stack failed: 12

@howardjohn (primary dev of Google's Istio) on https://github.com/istio/istio/issues/21672:

My kernel on my personal machine is not patched. But it doesn't really matter what my machine has, we ship Istio to 1000s of users. I cannot control what machine they run it on, and I would love to not have to restrict that to some subset of kernel versions

karalabe

comment created time in 3 months

issue commentistio/istio

golang 1.14: mlock signal stack failed

Yes, this seems worse. However, on an unpatched kernel this is seen as "works as intended". Question is: Is your kernel patched or not?

howardjohn

comment created time in 3 months

issue commentistio/istio

golang 1.14: mlock signal stack failed

I am already involved with the issue. I am still unclear on how much the issue is seen as a regression, that's why I wondered if you perceive Go 1.14 as "broken".

howardjohn

comment created time in 3 months

pull request commentalphagov/gsp

Bump golang from 1.13.8 to 1.14.0 in /components/service-operator

This is https://github.com/golang/go/issues/37436

dependabot-preview[bot]

comment created time in 3 months

issue commentistio/istio

golang 1.14: mlock signal stack failed

@howardjohn Just for clarification: What do you mean by "it" in "it is broken"? Go?

howardjohn

comment created time in 3 months

issue commentgolang/go

runtime: mlock of signal stack failed: 12

@rtreffer's post again sounds like false positives are unavoidable. Currently I still vote for the solution of limiting the negative impact of a false positive.

karalabe

comment created time in 3 months

issue commentgolang/go

runtime: mlock of signal stack failed: 12

@aclements I am a bit confused about which of the kernels you posted need the workaround and which are already patched. Maybe you could annotate your post.

karalabe

comment created time in 3 months

more