From 3724634f0ab9643316f79124d8859fdef6be9c4f Mon Sep 17 00:00:00 2001 From: Shuhei Kadowaki Date: Fri, 6 Mar 2020 13:20:22 +0900 Subject: [PATCH] add project doc --- misc/juliacon2020.md | 4 +++ misc/juno1.0-project.md | 71 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 75 insertions(+) create mode 100644 misc/juno1.0-project.md diff --git a/misc/juliacon2020.md b/misc/juliacon2020.md index 0d4b373..8586263 100644 --- a/misc/juliacon2020.md +++ b/misc/juliacon2020.md @@ -2,6 +2,8 @@ ## What to present +NOTE: [Juno 1.0 Project](./juno1.0-project.md) summarizes what we will do for Juno 1.0. + My current plan of the presentation consists of two parts: 1. Showcase improvements/features @@ -54,6 +56,8 @@ We also plan to describe our approach to solve the difficult problems and implem ### Notes (optional) +[Juno 1.0 Project](./juno1.0-project.md) describes our current plan for this project in details. + ### Talk image (optional) ![](juno1.0-logo.png) diff --git a/misc/juno1.0-project.md b/misc/juno1.0-project.md new file mode 100644 index 0000000..3ea4725 --- /dev/null +++ b/misc/juno1.0-project.md @@ -0,0 +1,71 @@ +# Juno 1.0 Project + +TODO: We may want to migrate this into our future (unified) repository. + +## Plans + +### Unify `julia-client` and `ink` + +Basically we want to migrate `ink` into `julia-client`. +Instead of just moving code in the former into the latter, +I would rather create a brand new repository, let's say `JunoLab/Juno`, and put the work into there. + +This should give us several _huge_ improvements: +- **Easy installation/update**: An user just need to install/update only one package +- **Better startup time**: A loading/activation consumed on deserialization should vastly improve; we can statically serialize/deserialize items without inter-package interactions + * We may be able to go even future, by deserializing items lazily or something like that +- Better maintainability + * E.g.: CI won't break because of incompatibility between julia-client and ink (although we still don't have enough test suites for code in Atom side :P) + * And also, we can think of `JunoLab/Juno` as a new main repository of our project, i.e. issues/FRs will be bundled there, documentation can be developed there and so on + +This will require **tons** of work; we need man power ! + +NOTE: +In theory, the UI components in `ink` are better to be composable, +and this is why they have been developed separately so far AFAIU. +But Atom is no longer a popular place to develop an IDE and now +we want to focus on our benefits rather than the ideal form of software for general uses. + +### Ship Julia packages in the unified Atom package + +Bundles Julia packages that constitute Juno within `JunoLab/Juno`, as [julia-vscode extension](https://github.com/julia-vscode/julia-vscode) does to some extent. + +This also brings several and similar user experience improvements: +- **Easy installation/update**: Users now don't need to update both Atom and Julia packages separately; what they need to do is only to update `JunoLab/Juno`, the new unified Atom package +- **Non-interference with user's environment** + * By hacking on uuids of our Juno-related packages (Julia side), we can trick Julia into seeing them as totally different packages from user's ones, even when they are actually the same or ones with different versions + * This means Juno users no longer worry about incompatibility between Juno packages and the ones they want to use for their use + +### Moar IDE features + +We already started to provide (ordinary) IDE features based on static code analysis using [CSTParser](https://github.com/julia-vscode/CSTParser.jl), like outline/goto, but we can go even more further. + +Judging from what users require/complain about (and of course from our own interests), these features seem to have high priority: +- linter implementation: @pfitzseb actually already implemented the linter on UI side, but we still not have its backend implementation on Julia side +- rename refactor: [WIP here](https://github.com/JunoLab/Atom.jl/pull/203) +- symbols view: can be nicely integrated with rename refactor feature +- outline view: can be enhanced more by allowing nested items + * once it becomes to handle nested items, our outline view can be used for more things, like markdown, TOML, Weave document, etc + +For implementing these features, I would like to go with our own implementations, i.e. don't just rely on [StaticLint.jl](https://github.com/julia-vscode/StaticLint.jl), because: +- caching everything on the first time environment loading isn't preferable from our point of view +- its linter implementation is sometimes too conservative; maybe it's because it doesn't use runtime information, which can be very helpful for linting, while it's a core functionality of Juno + +These features are kinda related to each other. +First I would like to refactor [our global (goto) symbol cache](https://github.com/JunoLab/Atom.jl/blob/e8abd9b8e19e7100471dd110a4d417817a53d4e2/src/goto.jl#L146-L164) and make it suitable for more general uses, and then we can reuse it for all the things. +By using user runtime information, it may be possible to enhance their implementations even more. + +## Ideas + +There are several other things we've wanted to do. +List them here because they have less priority than things above in terms of releasing Juno 1.0. + +- update documentation and showcase our latest features: there are lots of features that only we developers know ! + * https://github.com/JunoLab/Juno.jl/issues/419 +- improve module handling: + * https://github.com/JunoLab/Juno.jl/issues/411 + * https://github.com/timholy/Revise.jl/issues/391 + * https://github.com/JunoLab/Juno.jl/issues/407 +- [Infiltrator.jl](https://github.com/JuliaDebug/Infiltrator.jl) integration +- [Literate.jl](https://github.com/fredrikekre/Literate.jl) integration +- improvements on remote sessions