-
Notifications
You must be signed in to change notification settings - Fork 251
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 Colors package (do not merge yet) #667
Conversation
This uses function barriers to build containers that may, under favorable circumstances, use a leaftype for their eltypes. For Colors, it also starts trying to more "input santizing" at the beginning (in the constructor) to avoid passing type-instability down to lower levels.
Replaced by #667. |
|
||
# Allow users to supply strings without deprecation warnings | ||
# Note this strips any transparency; is this desirable? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dcjones, is this what you want here? Or is any Colorant
OK?
Again, the test failure on |
@timholy, it looks like JuliaLang/julia#12508: Solution: put (You never saw it again because it only happens the first time something is precompiled.) |
Some of the test files have (But in general, whenever you are using a package X and are precompiling, it is best practice to file a PR/issue and get |
Thanks for looking, @stevengj! |
@dcjones, if you need more time to review, I will push C-day back. Just let me know. |
This looks good to me. Actually, it seems pretty safe to merge this at any time. It works fine with pre-transition Cairo. |
Thanks! Combined testing here: https://travis-ci.org/timholy/Dummy.jl. Assuming this is on-track tomorrow, I'll merge. |
Switch to Colors package (do not merge yet)
What is the difference between “pre-transition” Ciaro and what’s coming?
|
@dcjones was pointing out that he was able to make it work even without switching Cairo to Colors. But both have been switched now. |
Replacement for #664. Do not merge until C-day.
The last commit is mostly for fun, experimenting with whether we can use more concretely-typed containers. This represents what should be a path towards performance improvements for Gadfly (but I haven't tested). If done well, the only potential cost I'm aware of might be increased compilation times under some circumstances. (EDIT: meaning, it might have to compile multiple type-stable versions of some methods, whereas formerly it used only one type-unstable version.)