Fork me on GitHub

hello @mfikes, @sritchie09 and I were looking at BigInt support in ClojureScript for and and came across your work on it Are you considering getting that merged and is there remaining work we can help with to make that happen?


@mkvlr There is a lot of work to see if it is possible to even do this without breaking changes, making things depend on newer JavaScript engines, etc. ...


I haven't been pursuing it...


@mfikes adding this in such a way that it doesn’t break on older engines without BigInt you mean?


Meaning, in a way that doesn't break existing codebases.


And, the concern about older engines is also a valid one.


Also, to add to the list: In a way that doesn't regress perf.


Seems pretty challenging IMHO.


I don’t think I understand where you expect existing codebases to break


I think I'm just expressing a very cautious view and don't have good examples of breakage at hand.


Maybe with the introduction of things like +' codebases can opt into new behavior, etc...


ok understood, thanks. And in general you feel it’s pretty challenging.

Sam Ritchie16:03:16

@mfikes understood! If you do want some help implementing it / thinking it through, in sicmutils I ended up extending the numeric tower, IEquiv, Icomparable etc to BigInt, goog.math.Long and goog.math.Integer

Sam Ritchie16:03:53

the performance hit would come from numbers on the left of these operations, since the implementations of those protocols would have to change


You could feel free to take the work I've done as a basis for attempting to work up a potential patch

👍 9
Sam Ritchie16:03:47

I’ll add that to the list, as I think at least laying out the case would be a valuable thing

Sam Ritchie16:03:04

this was the most sketchy thing necessary to get the goog numbers to play well

Sam Ritchie16:03:38

and honestly something that should probably get pushed up to Closure… these types don’t implement valueOf. (of course that’s beyond the scope of the bigint discussion)


some things about bigint: TLDR; it will only work when your runtime support it. There is no polyfill or compiler tricks.


Apple M1 is a pretty serious performance improvement for JVM based dev

👍 3
clj 3
Sam Ritchie22:03:36

Wild, right? I had my 8 minute test suite drop to 2m, and emacs with many batteries in is smoking fast


Any experience with docker on M1 yet?


Do you ever run into problems with 16GB? Or it’s just that much faster that 16GB is not an issue.


Absolutely. And the OpenJDK port is soooo close to being done: