New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Q: setting to make int/uint an int64/uint64 #734

Closed
glycerine opened this Issue Jan 1, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@glycerine

glycerine commented Jan 1, 2018

As always, gopherjs is amazing. Thank you all so much for your work on it.

Quick question: is there a simple setting to make gopherjs treat int as 64-bit instead of 32-bits by default?

Thanks!

@neelance

This comment has been minimized.

Show comment
Hide comment
@neelance

neelance Jan 1, 2018

Member

I'm happy to hear that you like GopherJS.

You wouldn't want 64 bit for int. It would cripple performance, since JS only supports 32 bit integers natively. However, the WebAssembly backend for the Go compiler that I'm currently working on will have 64 bit ints.

Member

neelance commented Jan 1, 2018

I'm happy to hear that you like GopherJS.

You wouldn't want 64 bit for int. It would cripple performance, since JS only supports 32 bit integers natively. However, the WebAssembly backend for the Go compiler that I'm currently working on will have 64 bit ints.

@glycerine

This comment has been minimized.

Show comment
Hide comment
@glycerine

glycerine Jan 1, 2018

Understood, but for my use case, performance isn't that important. Rationale: I'm working on a REPL based on gopherjs and otto, so performance is much less important than correctness when stepping through code being tried at the REPL. I'd just like the REPL's values to match as closely as possible my typical 64-bit operating environment.

glycerine commented Jan 1, 2018

Understood, but for my use case, performance isn't that important. Rationale: I'm working on a REPL based on gopherjs and otto, so performance is much less important than correctness when stepping through code being tried at the REPL. I'd just like the REPL's values to match as closely as possible my typical 64-bit operating environment.

@glycerine

This comment has been minimized.

Show comment
Hide comment
@glycerine

glycerine Jan 1, 2018

And by the way: I am very excited that you are working the WebAseembly back end!

glycerine commented Jan 1, 2018

And by the way: I am very excited that you are working the WebAseembly back end!

@dmitshur

This comment has been minimized.

Show comment
Hide comment
@dmitshur

dmitshur Jan 4, 2018

Member

Quick question: is there a simple setting to make gopherjs treat int as 64-bit instead of 32-bits by default?

There isn't. It would be a non-trivial change (and, performance would be decreased as Richard said).

I would suggest using int64/uint64 if you truly need 64-bit integers.

If you have a REPL, perhaps you can make it execute the following code to create custom types:

// Override predeclared int and uint types to be int64 and uint64.
type (
	int  int64
	uint uint64
)

It's possible to do this because int, uint are not keywords, they're predeclared types. E.g., see https://play.golang.org/p/kzENFqV7Hll.

Member

dmitshur commented Jan 4, 2018

Quick question: is there a simple setting to make gopherjs treat int as 64-bit instead of 32-bits by default?

There isn't. It would be a non-trivial change (and, performance would be decreased as Richard said).

I would suggest using int64/uint64 if you truly need 64-bit integers.

If you have a REPL, perhaps you can make it execute the following code to create custom types:

// Override predeclared int and uint types to be int64 and uint64.
type (
	int  int64
	uint uint64
)

It's possible to do this because int, uint are not keywords, they're predeclared types. E.g., see https://play.golang.org/p/kzENFqV7Hll.

@glycerine

This comment has been minimized.

Show comment
Hide comment
@glycerine

glycerine Jan 4, 2018

It's possible to do this because int, uint are not keywords, they're predeclared types

Thanks Dmitri. Very cool. I didn't know that.

I played with having the gi REPL target node.js, but then ultimately decided to target LuaJIT instead. I'm utilizing a very heavily modified gopherjs library that produces Lua instead of javascript and does incremental typechecking and complication (edit: rather compilation, haha), and I must say gopherjs is really delightful.

As an aside, if you want to follow along the repo is public at https://github.com/go-interpreter/gi and the todo list is https://github.com/go-interpreter/gi/issues . It's still probably a bit early to get anything real done, and the REPL barfs tons of debug prints after every command, but closures and slices and for loops work in a very elementary fashion. Still working on maps, and things like goroutines and channels are a long way off. You can see what is tested and working thus far by checking the tests in this file, https://github.com/go-interpreter/gi/blob/master/pkg/compiler/repl_test.go. There's quite a bit to do, but gopherjs is making it go quite quickly.

glycerine commented Jan 4, 2018

It's possible to do this because int, uint are not keywords, they're predeclared types

Thanks Dmitri. Very cool. I didn't know that.

I played with having the gi REPL target node.js, but then ultimately decided to target LuaJIT instead. I'm utilizing a very heavily modified gopherjs library that produces Lua instead of javascript and does incremental typechecking and complication (edit: rather compilation, haha), and I must say gopherjs is really delightful.

As an aside, if you want to follow along the repo is public at https://github.com/go-interpreter/gi and the todo list is https://github.com/go-interpreter/gi/issues . It's still probably a bit early to get anything real done, and the REPL barfs tons of debug prints after every command, but closures and slices and for loops work in a very elementary fashion. Still working on maps, and things like goroutines and channels are a long way off. You can see what is tested and working thus far by checking the tests in this file, https://github.com/go-interpreter/gi/blob/master/pkg/compiler/repl_test.go. There's quite a bit to do, but gopherjs is making it go quite quickly.

@glycerine glycerine closed this Jan 4, 2018

@dmitshur dmitshur added the question label Jan 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment