proposal: Limit support to one GOOS value (primarily for stdlib). #693

dmitshur · 2017-09-05T19:20:01Z

The GopherJS compiler supports building output only for GOARCH=js value, and any GOOS value.

That means it will produce valid and different output for this Go package, depending on which GOOS value is used:

// +build plan9

package p

const Message = "It was a hot summer..."

// +build !plan9

package p

const Message = "It was a cold winter..."

Of course, it also supports cross-compiling, so one can produce different outputs by doing:

$ GOOS=plan9 gopherjs build
# hot summer

$ GOOS=solaris gopherjs build
# cold winter

I propose we limit support to just a single fixed GOOS value.

This is primarily meant to apply to the Go standard library, which we must manually apply overrides for in order to get it to build and work correctly for GOARCH=js. See https://github.com/gopherjs/gopherjs/commits/master/compiler/natives/src. However, I think we should apply for all packages for simplicity/consistency. Applying the limit to just Go stdlib but not 3rd party packages would be weird and unnecessary.

The motivation is simple. It costs a lot of developer time to support Go standard library for GopherJS. Right now, I don't think this project can afford to continue to support all GOOS values. It's an open source project, with no funding, and most of the progress is made by volunteers contributing in their spare time in after work hours.

The value gained from supporting multiple GOOS values is small. The cost is prohibitively high.

The compiler will continue to be able to (theoretically) compile for many GOOS values, we're just not going to support GOOS values other than a single one that we pick.

dmitshur · 2017-09-05T19:29:21Z

This came up when I investigated what it'd take to fix #688.

I seriously considered 3 alternative fixed GOOS values to use:

darwin - this is the same GOOS that the 2 primary GopherJS developers (@neelance and me) use when developing GopherJS and using it.
linux - it's one of the most popular and generic GOOS values. Even android build tag piggybacks off it. Also, unlike darwin, it's open source. Given open source and proprietary, I'd rather we support an open source OS.
nacl - this is the GOOS environment that is most similar to GOARCH=js. In fact, there are a number of times where I base GOARCH=js implementations after NaCL ones. There are tests that could be simplified if we also targetted nacl.

Using darwin is the easiest and works best from my testing. It's what Richard and I have used all this time. I'm sure many other users also use it.

Using linux would require some work; it didn't work out of box for me.

Using windows (for reference) seems like it'd require even more work. It clearly doesn't work right now (see #688).

Using nacl would require some initial investment, but would pay off in simplicity in the long term, IMO.

Consider the following Go code in syscall package override to print to stdout and stderr (file descriptors 1 and 2):

gopherjs/compiler/natives/src/syscall/syscall_unix.go

Lines 57 to 74 in f7c5653

    
           func Syscall(trap, a1, a2, a3 uintptr) (r1, r2 uintptr, err Errno) { 
        
           	if f := syscall("Syscall"); f != nil { 
        
           		r := f.Invoke(trap, a1, a2, a3) 
        
           		return uintptr(r.Index(0).Int()), uintptr(r.Index(1).Int()), Errno(r.Index(2).Int()) 
        
           	} 
        
           	if trap == SYS_WRITE && (a1 == 1 || a1 == 2) { 
        
           		array := js.InternalObject(a2) 
        
           		slice := make([]byte, array.Length()) 
        
           		js.InternalObject(slice).Set("$array", array) 
        
           		printToConsole(slice) 
        
           		return uintptr(array.Length()), 0, 0 
        
           	} 
        
           	if trap == SYS_EXIT { 
        
           		runtime.Goexit() 
        
           	} 
        
           	printWarning() 
        
           	return uintptr(minusOne), 0, EACCES 
        
           }

Here's the equivalent code if we targeted nacl:

func naclWrite(fd int, b []byte) int {
	switch fd {
	case 1, 2:
		printToConsole(b)
		return len(b)
	default:
		printWarning() 
		return -1
	}
}

See how much cleaner that is?

Of course, I haven't implemented everything for nacl, that was just a brief attempt, so there may be unexpected things. But it seems like the best option in the long run to me.

dmitshur · 2017-09-05T19:30:10Z

To conclude, my recommendation if this proposal is accepted is to target darwin in the short term. And to consider optionally targetting nacl instead in the long run.

@neelance What do you think?

neelance · 2017-09-05T22:23:17Z

The main reason for supporting multiple GOOS is so that gopherjs test can work on multiple platforms.

Could you please list some examples of support for multiple GOOS causing overhead? Is it mainly about windows?

dmitshur · 2017-09-05T22:30:18Z

The main reason for supporting multiple GOOS is so that gopherjs test can work on multiple platforms.

I don't understand why gopherjs test wouldn't work on multiple platforms if we target compilation for a single GOOS value. Can you explain?

dmitshur · 2017-09-06T00:08:32Z

Ok, I see now. It's about the syscall module, which is used to implement os for reading/writing files from on disk during gopherjs test time (i.e., when using node to execute the JavaScript in terminal).

Normally, JavaScript is portable and can be run on any OS with node, but in this case, we're using non-portable syscall module API for os implementation.

I'm going to put this proposal on hold and think more about this, given the new information (well, old, but remembered now).

j7b · 2017-11-01T16:26:02Z

In playing around with #688 it seemed life would be simpler the goroot surrogate was (nacl) libgo, which might be a good idea anyway for wasm-related reasons. It also occurs to me the syscall issue could be addressed by giving the node addon moderately more love and mandating it if you want to gohperjs test.

Changes in this commit ensure that we can at least build supported standard library packages with GOOS=darwin. In theory, GOOS shouldn't even matter, since we always target the same platform (nodejs or browser), but for historical reasons, it does matter and we need to take extra steps to make it work. See gopherjs#693 for more details.

So long as we rely on OS-specific syscalls, we must build the package with OS-appropriate GOOS/GOARCH (see also gopherjs#693). Using runtime.GOOS here is not ideal, since it ignores environment variables, making "cross-compiling" impossible. This is not a big deal in most cases, but makes reproducing errors like in gopherjs#1027 more difficult.

nevkontakte · 2021-06-03T22:41:53Z

I would like to revive discussion of this proposal. Now that the upstream support js,wasm architecture we could reduce the amount of standard library overlays we maintain by reusing some of that code.

To be coherent with the upstream I would propose using GOOS=js GOARCH=ecmascript, which reflects that we run in the same JS environment, but our generated code is, in fact, ES5.

As a proof of concept for code reuse, I hacked gopherjs build system to use js/wasm for certain low-level packages (with the focus on syscall in particular) and it seems to compile just fine, which is great news. If I manage to get it pass tests, it would allow us to dispose of our custom node-syscall extension 🙂 The only problem is, using different build tags for different packages is quite ugly and leads to inconsistencies. I would really prefer to be able to add js,ecmascript to the build tags in the original sources. @dmitshur do you think this is something the Go Team would be open to?.. If not, we'd have to fork code just to change build tags, which feels kind of silly.

dmitshur · 2021-06-04T02:57:53Z

In the Go project, an area we wanted to explore is improving experience for out-of-tree ports to reduce the need for having all ports be added in-tree. GopherJS is a compiler for an out-of-tree port. If there’s a small and reasonable change in the main repo that can help here significantly, I think it would be worth proposing and considering.

However, I don’t quite understand why a change would need to happen in the Go tree. You said:

The only problem is, using different build tags for different packages is quite ugly and leads to inconsistencies.

Can you elaborate on this?

nevkontakte · 2021-06-04T18:21:22Z

Sorry, I realize now that my original comment had a few logical leaps that are likely confusing to anyone who can't read my mind 😅

Here's my chain of reasoning:

Originally GopherJS needed host's GOOS to interact with the OS (file system, etc.) and there wasn't one GOOS value that would be portable in the context of nodejs.
The price for the ability to do that was extra complexity of supporting several values GOOS and, for example, not supporting GOOS=windows even though nodejs is presumably a cross-platform runtime.
Wasm support in the upstream solved that problem and the code you build with the upstream Go under GOOS=js GOARCH=wasm will run exactly the same on nodejs on every OS it supports.
That means if GopherJS could take advantage of standard library code that is there for wasm, we could converge on our own GOOS=js GOARCH=ecmascript and simplify some things on our side.
But Go standard library uses very targeted build tags js,wasm to guard the code that would work just as well for GopherJS, so to take advantage of it we have three options:
- Use GOOS=js GOARCH=wasm for our builds. That's probably not ideal for our users who may want to distinguish between GopherJS and wasm at build time.
- Hard-code exceptions in our build process to adjust the set of sources we build despite the build tags.
- Change standard library sources upstream to either use js instead of js,wasm, or js,ecmascript in addition to js,wasm.

nevkontakte · 2021-10-03T14:35:32Z

I'm going to give this a go, since I suspect this will have several simplification benefits for our users, as well as for maintenance. Roughly my plan is:

All standard library packages are built with GOOS=js GOARCH=wasm to maximize code reuse with upstream.
All user code is built with GOOS=js GOARCH=ecmascript.
Build tag gopherjs is always set.

At the moment I'm conducting early experiments in my own fork: https://github.com/nevkontakte/gopherjs/tree/syscall2. I'm keeping my experiment notes in https://github.com/nevkontakte/gopherjs/wiki/The-Syscall-Experiment for the time being.

Suggestions/comments are welcome!

paralin · 2021-10-05T19:31:57Z

@nevkontakte Looks good, thanks, will try to test it. following your branch.

GopherJS will use this target going forward. The values where chosen by the following logic: - GOOS describes the targeted API environment, which is generally the same as when building wasm: both execute under a browser or nodejs. Build tag `js` is shared by GopherJS and wasm and can be used to target the general environment. - GOARCH describes the low-level emitted code, which is currently EcmaScript 5. Using `ecmascript` here differentiates from `wasm`, while not referencing GopherJS explicitly. It also leaves us a different paths for future upgrades to ES6+ by either changing GOARCH or keeping it and making this change implicit. At the same time, we use fixed js/wasm target when building standard library packages, which resolves a lot of concerns discussed in gopherjs#693. Using js/ecmascript is not feasible because it'll require us to maintain a lot more overlays and/or rewrite build tags, which leads to the exactly same outcome. This change is potentially breaking for users that may have relied on GOOS=linux in their sources. To make transition easier for them, we support using GOOS/GOARCH from environment. However, they will be only applied to the user code. Standard library will still be built with js/wasm.

GopherJS will use this target going forward. The values where chosen by the following logic: - GOOS describes the targeted API environment, which is generally the same as when building wasm: both execute under a browser or nodejs. Build tag `js` is shared by GopherJS and wasm and can be used to target the general environment. - GOARCH describes the low-level emitted code, which is currently EcmaScript 5. Using `ecmascript` here differentiates from `wasm`, while not referencing GopherJS explicitly. It also leaves us a different paths for future upgrades to ES6+ by either changing GOARCH or keeping it and making this change implicit. At the same time, we use fixed js/wasm target when building standard library packages, which resolves a lot of concerns discussed in gopherjs#693. Using js/ecmascript is not feasible because it'll require us to maintain a lot more overlays and/or rewrite build tags, which leads to the exactly same outcome. In addition, we always set `gopherjs` build tag to make it easy to guard sources using GopherJS-specific features. This is similar to `gc` and `gccgo` build tags respective compilers set. This change is potentially breaking for users that may have relied on GOOS=linux in their sources. To make transition easier for them, we support using GOOS/GOARCH from environment. However, they will be only applied to the user code. Standard library will still be built with js/wasm.

nevkontakte · 2022-03-20T18:12:31Z

Hi all, it took me longer than I wished, but I think I have a pretty usable implementation in https://github.com/nevkontakte/gopherjs/tree/syscall2 I'd like to merge into the master (before I start working on Go 1.18 support). I have a couple of minor items on the TODO list, but the hard part of the work is done.

Here are some of the notable changes:

The most exciting one — node-syscall extension is no longer needed for routing file system access (and a few other things like os.Getpid()). The old extension can still be used if you really need it, but I plan to completely remove it in a release or two.
GopherJS will now standardize on GOOS=js GOARCH=ecmascript. This means that GOOS is now shared with wasm, and GOARCH can be used to tell them apart. In addition the new gopherjs build tag is always set now.
Standard library is built is if we were using GOOS=js GOARCH=wasm, meaning that we can reuse quite a bit more standard library code that works with Go WebAssembly. It should make writing portable code easier, and also reduce maintenance burden.
- As a consequence, syscall package API is now the same as with js/wasm.
Output size for our reference TodoMVC app reduced by 2.17% minified, mostly thanks to throwing away unnecessary platform-specific code.
For folks who only run GopherJS in a browser environment, nothing significant should have changed.

While I'm polishing things up, I would like to ask everyone to try checking out my branch (https://github.com/nevkontakte/gopherjs/tree/syscall2) and trying to use that version of GopherJS with your projects. If you find any problems, please report them here.

paralin · 2022-03-21T13:51:38Z

@nevkontakte I'm happy to report that I've switched to your syscall2 branch on a fairly large project and everything seems to work fine!

regenvanwalbeek-wf · 2022-03-25T21:54:58Z

@nevkontakte I tested out your syscall2 branch and was able to get everything running, though I did run into a roadbump.

Our bindings would not load in our dev build.

We serve our application in the browser with Dart Dev Compiler, which generates AMD modules and uses requirejs to load modules. Since this snippet sees that require exists, it tries to load fs and fails. When I delete that snippet from our build output, everything loads. Do you think it's reasonable to add a try/catch, or some way to exclude that from the build? (It looks like this was taken from a previous iteration of wasm_exec.js and that logic recently changed, so I don't know how reasonable that request is)

Our production build does not use requirejs and did not run into any problems loading our js.

Other than that, looks great! We were able to remove GOOS=linux from our test targets (we use macs for local dev). Tests no longer error with fatal error: all goroutines are asleep - deadlock! 🎉 We did not discover any change in behavior in the application.

There are environments like AMD, which expose `require()` function, but do not provide `fs` module. In such cases we should fall back to our stub (see gopherjs#693 (comment)).

nevkontakte · 2022-03-27T13:44:02Z

@regenvanwalbeek-wf thanks for the report, it's a good catch. I've pushed a fix (note that it was a force push), could you try it again?

regenvanwalbeek-wf · 2022-03-28T20:31:01Z

@nevkontakte This fix works for us, thank you! 🚀

flimzy · 2022-03-30T14:00:58Z

I've found a problem with one of my test suites. It's an OSS package, if you care to do your own testing/debugging: https://github.com/go-kivik/kivik

With master GopherJS:

jonhall@ivy:~/src/kivik/kivik$ gopherjs test ./...
PASS
ok      github.com/go-kivik/kivik/v4    1.487s
PASS
ok      github.com/go-kivik/kivik/v4/driver     0.691s
?       github.com/go-kivik/kivik/v4/internal/mock      [no test files]
PASS
ok      github.com/go-kivik/kivik/v4/errors     0.723s
PASS
ok      github.com/go-kivik/kivik/v4/internal/registry  0.609s

When I switch to your syscall2 branch and install that version:

jonhall@ivy:~/src/kivik/kivik$ gopherjs test ./...
../../../go/pkg/mod/github.com/otiai10/[email protected]/test_setup.go:16:10: Mkfifo not declared by package syscall
../../../go/pkg/mod/github.com/otiai10/[email protected]/stat_times.go:17:31: stat.Atim undefined (type *syscall.Stat_t has no field or method Atim)
../../../go/pkg/mod/github.com/otiai10/[email protected]/stat_times.go:17:53: stat.Atim undefined (type *syscall.Stat_t has no field or method Atim)
../../../go/pkg/mod/github.com/otiai10/[email protected]/stat_times.go:18:31: stat.Ctim undefined (type *syscall.Stat_t has no field or method Ctim)
../../../go/pkg/mod/github.com/otiai10/[email protected]/stat_times.go:18:53: stat.Ctim undefined (type *syscall.Stat_t has no field or method Ctim)
../../../go/pkg/mod/github.com/otiai10/[email protected]/copy_namedpipes.go:16:17: Mkfifo not declared by package syscall

paralin · 2022-03-30T19:05:14Z

That's probably a package that isn't designed to build on js.

You'll need to figure out which package is importing syscall and referencing those undefined types on js. I can take a look today maybe

nevkontakte · 2022-04-03T21:21:07Z

@flimzy this is an interesting example.

The error (obviously) comes from the github.com/otiai10/copy package, which sole function is (apparently) recursively copying directories. It is required transitively:

$ go mod why github.com/otiai10/copy
# github.com/otiai10/copy
github.com/go-kivik/kivik/v4
github.com/go-kivik/kivik/v4.test
gitlab.com/flimzy/testy
github.com/otiai10/copy

Looking at the source code, github.com/otiai10/copy seems to use syscall for two purposes:

Get atime and mtime from io/fs.FileInfo.Sys(). This information is present in the wasm version of syscall.Stat_t, but the fields are named differently, which is unfortunate.
To copy a pipe via syscall.Mkfifo(). This operation is not supported by Go wasm, but I can see that there is a version of the package for platforms that don't support it.

So I think Christian is correct here, this package was never designed to work with js/wasm and therefore it fails for GopherJS syscall2 branch. Personally, I think it would be best to send a PR to the github.com/otiai10/copy adding support for wasm and upcoming GopherJS. It should be as trivial as adjusting build tags in a couple of places. We could theoretically add some extra shims on the GopherJS side to make it compile, but that would be quite hacky and go against the intent of converging with upstream as much as possible. @flimzy WDYT?

GopherJS will use this target going forward. The values where chosen by the following logic: - GOOS describes the targeted API environment, which is generally the same as when building wasm: both execute under a browser or nodejs. Build tag `js` is shared by GopherJS and wasm and can be used to target the general environment. - GOARCH describes the low-level emitted code, which is currently EcmaScript 5. Using `ecmascript` here differentiates from `wasm`, while not referencing GopherJS explicitly. It also leaves us a different paths for future upgrades to ES6+ by either changing GOARCH or keeping it and making this change implicit. At the same time, we use fixed js/wasm target when building standard library packages, which resolves a lot of concerns discussed in gopherjs#693. Using js/ecmascript is not feasible because it'll require us to maintain a lot more overlays and/or rewrite build tags, which leads to the exactly same outcome. In addition, we always set `gopherjs` build tag to make it easy to guard sources using GopherJS-specific features. This is similar to `gc` and `gccgo` build tags respective compilers set. This change is potentially breaking for users that may have relied on GOOS=linux in their sources. To make transition easier for them, we support using GOOS/GOARCH from environment. However, they will be only applied to the user code. Standard library will still be built with js/wasm.

There are environments like AMD, which expose `require()` function, but do not provide `fs` module. In such cases we should fall back to our stub (see gopherjs#693 (comment)).

flimzy · 2022-04-13T13:37:34Z

Upstream patch submitted: otiai10/copy#75

nevkontakte · 2022-04-17T15:46:21Z

@flimzy do you want to wait for otiai10/copy#75 to get merged before we merge #1111?

flimzy · 2022-04-18T13:13:35Z

@flimzy do you want to wait for otiai10/copy#75 to get merged before we merge #1111?

No, that's not necessary. I have no idea how long that will take, and I can always use a fork of that repo in the meantime.

nevkontakte · 2022-04-18T13:23:07Z

In that case, I'm happy to merge as soon as I have your approval :)

GopherJS will use this target going forward. The values where chosen by the following logic: - GOOS describes the targeted API environment, which is generally the same as when building wasm: both execute under a browser or nodejs. Build tag `js` is shared by GopherJS and wasm and can be used to target the general environment. - GOARCH describes the low-level emitted code, which is currently EcmaScript 5. Using `ecmascript` here differentiates from `wasm`, while not referencing GopherJS explicitly. It also leaves us a different paths for future upgrades to ES6+ by either changing GOARCH or keeping it and making this change implicit. At the same time, we use fixed js/wasm target when building standard library packages, which resolves a lot of concerns discussed in gopherjs#693. Using js/ecmascript is not feasible because it'll require us to maintain a lot more overlays and/or rewrite build tags, which leads to the exactly same outcome. In addition, we always set `gopherjs` build tag to make it easy to guard sources using GopherJS-specific features. This is similar to `gc` and `gccgo` build tags respective compilers set. This change is potentially breaking for users that may have relied on GOOS=linux in their sources. To make transition easier for them, we support using GOOS/GOARCH from environment. However, they will be only applied to the user code. Standard library will still be built with js/wasm.

There are environments like AMD, which expose `require()` function, but do not provide `fs` module. In such cases we should fall back to our stub (see gopherjs#693 (comment)).

dmitshur added the Proposal label Sep 5, 2017

dmitshur mentioned this issue Sep 6, 2017

internal/poll: fails to build on Windows #688

Open

dmitshur added the Proposal Hold label Sep 6, 2017

dmitshur mentioned this issue Mar 8, 2021

GopherJS should use GOOS=js instead of build.Default.GOOS #991

Closed

nevkontakte mentioned this issue Mar 28, 2021

not working on macOS Big Sur M1 goplusjs/gopherjs#33

Closed

nevkontakte mentioned this issue May 3, 2021

Improve Mac OS (darwin) support. #1024

Merged

nevkontakte mentioned this issue Jul 20, 2021

Support Go Modules builds. #1042

Merged

nevkontakte mentioned this issue Aug 4, 2021

syscall.Stat_t: consider shimming os.Ctime #1047

Open

nevkontakte self-assigned this Oct 3, 2021

nevkontakte removed the Proposal Hold label Oct 3, 2021

nevkontakte pinned this issue Oct 3, 2021

nevkontakte mentioned this issue Oct 11, 2021

fmt.Println() panics #1074

Open

nevkontakte unpinned this issue Dec 19, 2021

nevkontakte mentioned this issue Feb 9, 2022

Question: how to debug non-compiling code? (syscall error) #1104

Closed

nevkontakte mentioned this issue Mar 23, 2022

Fix: Don't bust cache so aggressively when compiling test sources #1110

Closed

nevkontakte mentioned this issue Mar 27, 2022

Standardize on a single GOOS/GOARCH and deprecate node-syscall module. #1111

Merged

nevkontakte closed this as completed in #1111 Apr 20, 2022

nevkontakte mentioned this issue Sep 25, 2022

SOCK_NONBLOCK / SOCK_CLOEXEC syscall issues #1148

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

proposal: Limit support to one GOOS value (primarily for stdlib). #693

proposal: Limit support to one GOOS value (primarily for stdlib). #693

dmitshur commented Sep 5, 2017 •

edited

Loading

dmitshur commented Sep 5, 2017 •

edited

Loading

dmitshur commented Sep 5, 2017

neelance commented Sep 5, 2017

dmitshur commented Sep 5, 2017 •

edited

Loading

dmitshur commented Sep 6, 2017

j7b commented Nov 1, 2017

nevkontakte commented Jun 3, 2021

dmitshur commented Jun 4, 2021

nevkontakte commented Jun 4, 2021

nevkontakte commented Oct 3, 2021 •

edited

Loading

paralin commented Oct 5, 2021

nevkontakte commented Mar 20, 2022

paralin commented Mar 21, 2022

regenvanwalbeek-wf commented Mar 25, 2022

nevkontakte commented Mar 27, 2022

regenvanwalbeek-wf commented Mar 28, 2022

flimzy commented Mar 30, 2022

paralin commented Mar 30, 2022

nevkontakte commented Apr 3, 2022

flimzy commented Apr 13, 2022

nevkontakte commented Apr 17, 2022

flimzy commented Apr 18, 2022

nevkontakte commented Apr 18, 2022

proposal: Limit support to one GOOS value (primarily for stdlib). #693

proposal: Limit support to one GOOS value (primarily for stdlib). #693

Comments

dmitshur commented Sep 5, 2017 • edited Loading

dmitshur commented Sep 5, 2017 • edited Loading

dmitshur commented Sep 5, 2017

neelance commented Sep 5, 2017

dmitshur commented Sep 5, 2017 • edited Loading

dmitshur commented Sep 6, 2017

j7b commented Nov 1, 2017

nevkontakte commented Jun 3, 2021

dmitshur commented Jun 4, 2021

nevkontakte commented Jun 4, 2021

nevkontakte commented Oct 3, 2021 • edited Loading

paralin commented Oct 5, 2021

nevkontakte commented Mar 20, 2022

paralin commented Mar 21, 2022

regenvanwalbeek-wf commented Mar 25, 2022

nevkontakte commented Mar 27, 2022

regenvanwalbeek-wf commented Mar 28, 2022

flimzy commented Mar 30, 2022

paralin commented Mar 30, 2022

nevkontakte commented Apr 3, 2022

flimzy commented Apr 13, 2022

nevkontakte commented Apr 17, 2022

flimzy commented Apr 18, 2022

nevkontakte commented Apr 18, 2022

dmitshur commented Sep 5, 2017 •

edited

Loading

dmitshur commented Sep 5, 2017 •

edited

Loading

dmitshur commented Sep 5, 2017 •

edited

Loading

nevkontakte commented Oct 3, 2021 •

edited

Loading