Add tooling updates to NEWS.md #17582
Conversation
|
|
||
| * A convenient C++ FFI in | ||
| [Cxx.jl](https://github.com/Keno/Cxx.jl). Using it requires | ||
| building Julia with some additional build flags that will build clang along with llvm. |
There was a problem hiding this comment.
I don't think this is the case any more. Still a bit in flux.
There was a problem hiding this comment.
The Cxx.jl page still says so. @Keno - suggestions?
There was a problem hiding this comment.
Readme last modified a month ago, but see https://github.com/Keno/Cxx.jl/commits/master and the deps/build.jl script
There was a problem hiding this comment.
@tkelman is correct, even though there is still a small bug right now that makes it necessary. Once that's resolved Pkg.add will just work though.
|
Startup time on Windows will be very noticeably better, and the upgraded LLVM version is worth noting. |
|
Is there an issue or PR for faster startup on windows, or something I can refer to? Not necessary, but good to link if available. |
|
#16953, though a lot of the discussion happened in a few older issues that were mostly about backtraces |
|
Many, many new deprecations are also not mentioned in https://github.com/JuliaLang/julia/blob/master/NEWS.md#deprecated-or-removed |
|
I guess the deprecations list should either be complete, or removed altogether. Personally, I don't find the list of all deprecations in NEWS.md useful. |
|
The list in NEWS can have more elaboration on subtleties and backwards-compatibility concerns for porting code, since naively following the warning has been frequently seen to be the wrong way to update packages if they don't want to drop support for old versions of Julia yet. |
|
The current one looks not much better than the deprecation warnings. If you can list out the different kinds of subtleties and backwards compatibility, everyone can then put things in the right place. My guess is that many people will just move on and support 0.5 as the min version within a couple of months of its release, unless we have very clear instructions. |
|
I like the idea of highlights, but I wonder if it's a concern that 3/4 of them are about packages rather than improvements in core julia. Of course core changes enable that functionality, but a casual reader won't know that and might think that julia proper has hardly changed since 0.4. ("Julia development slowing down, they rely on advertising community packages just to have enough NEWS!") I also wonder a bit about picking and choosing among the package ecosystem (should Plots and GLVisualize be in that list? won't they be more widely used than Cxx?), but of course the ones you picked out are indeed tremendously exciting highlights. |
|
I don't think the highlights should be restricted to the things I listed, and there are probably other things worth calling out that are of general interest. I am not sure about GLVisualize being of direct wide interest (even though it is fantastic), but Plots.jl certainly deserves a mention. Even the language and compiler improvements could perhaps use more description. I think the fact that many of these are packages is just the way they are organized, but the debugger and Cxx FFI could equally be in the julia repo. |
|
Let's just mention multithreading under new language features, and then we can label this new section something like "tooling improvements", since that's basically what it's about. -1 to a "highlights" section. I don't want to go through the file and debate/decide which items count as highlights. |
|
I think that we should have a blog post that goes along with the release that highlights the most significant changes with cool examples of what you can do with them. I can work on something. |
|
Yes, we can have highlights as a blog post, and change this to tools in the NEWS. |
|
I have renamed the section to tools improvements. I am perhaps missing this, but the Do we need a performance section? |
| Julia provides an API for writing generic algorithms for arbitrary | ||
| indexing schemes ([#16260]). | ||
|
|
||
| New architectures |
There was a problem hiding this comment.
you have this section twice now
A short one would be a good idea. Explaining the consequences of jb/functions making anonymous functions now fast, better startup time on Windows, and better SIMD from newer LLVM (we're paying for it in compile time, but maybe that's a known bug rather than something to advertise...)? |
|
I am unlikely to be able to update this for the next couple of days as I will be flying. If someone wants to clean this up and move the breaking changes back to the original place, I'll be grateful. Otherwise, I'll do it once I am back home. |
|
Having language changes first seems like the only sane thing to me – you go from most central to least. Starting at tooling seems like going from the outside in, Viral. Any intuitive reason for that? |
|
My thinking was having things that more users are likely to find value in as they read this. Perhaps as you said, maybe the blog post is the right place to do this. Please feel free to move things around as necessary. Can someone check if @JeffBezanson's jb/functions stuff is mentioned and appropriately highlighted. Would be nice to have it in a performance section. |
|
Updated. |
fixes #16982, mention `writemime` deprecation [ci skip]
Mention debugger, Juno+Debugger integration, C++ FFI and multi-threading. I thought these are all big enough to be mentioned right upfront as the major highlights. Perhaps we should also have a few other major highlights such as jb/functions and broadcasting?