Skip to content
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

switch to scala 2.12 and add scaffolding for scala.js #1426

Merged
merged 3 commits into from Jul 27, 2017
Merged

switch to scala 2.12 and add scaffolding for scala.js #1426

merged 3 commits into from Jul 27, 2017

Conversation

jdegoes
Copy link
Member

@jdegoes jdegoes commented Jul 18, 2017

A bunch of prep work to ease the painful situation I'm in presently with scalaz.effect.

  • Add Scala.js compiler plug-in
  • Reorganize for scala.js support
  • Modify build to build JS versions
  • Add sbt script for reproducible builds
  • Upgrade Scala to 2.12.x as default
  • Add optimization flags that have useful performance benefits

Copy link
Contributor

@aloiscochard aloiscochard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is sad to see all the pain introduced by cross-compiling to JS, but oh well. There is no better way anyway.

.gitignore Outdated
@@ -1,2 +1,3 @@
tags
target
.DS_Store
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should not be here, you can include such OS specific exclude in your global gitignore, ty

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. Should I remove tags as well, while I'm in there?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep indeed! ty

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I deleted everything but target.

scalacOptions ++= Seq("-feature","-deprecation", "-Xlint", "-language:higherKinds",
"-Ydelambdafy:method", "-Ypartial-unification", "-target:jvm-1.8"),
"-Ydelambdafy:method", "-Ypartial-unification", "-target:jvm-1.8", "-opt:l:project",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find suspicious that -opt:l:project is required here, what is the impact on performance?

Inlining is known to have cause issues in the best in users library/projects.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's definitely measurable. However, I can manually inline the critical section if necessary, which will achieve most of the gains. The optimizer will only inline methods so annotated (@inline), and it looks more carefully engineered than 2.11.x.

Let me know how to handle it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would interesting to have opinion of @retronym on such thing, as he knows how such a library is crafted and he is probably well aware of the current state of the inliner.

I don't feel qualified enough to make a decision here, I'm just pushing on the safe side due to bad memories about inlining... But it would be a shame to miss such improvement if they are now properly implemented... might be worth trying initially... and can go back later...

Thanks Kenji for the pointer!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left the inline pragma for now. However, in the future, if we decide to remove it, I can manually inline critical section code.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it looks like opt:l:project is now deprecated: scala/scala#5964

build.sbt Outdated
@@ -1,28 +1,57 @@
import org.scalajs.sbtplugin.ScalaJSPlugin
import org.scalajs.sbtplugin.ScalaJSPlugin.autoImport._
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe these imports unnecessary

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I deleted them, turns out they were not required.

@aloiscochard
Copy link
Contributor

Great effort BTW, I wish I did start this way.

@jdegoes
Copy link
Member Author

jdegoes commented Jul 19, 2017

@aloiscochard @xuwei-k All right, this is ready for merge.

@jdegoes
Copy link
Member Author

jdegoes commented Jul 25, 2017

@aloiscochard @xuwei-k Anything else I should change before this gets merged?

@aloiscochard
Copy link
Contributor

LGTM! great stuff :)

@jdegoes
Copy link
Member Author

jdegoes commented Jul 26, 2017

@aloiscochard Would you mind merging? I don't have permissions. Thanks!

@aloiscochard aloiscochard merged commit 0eb50ba into scalaz:series/8.0.x Jul 27, 2017
@jdegoes
Copy link
Member Author

jdegoes commented Aug 9, 2017

@jbgi Great. So now you have to inline in two places: the code, and the build file. 🙄 😆

I think in my next PR I'll just manually inline...

@jdegoes jdegoes deleted the series/8.0.x branch August 9, 2017 01:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants