I think code-server might also work, but my guess is that the various remote extensions that MS is putting out are probably a more stable story. But not sure, I haven’t really tried 
No, not at this point. I assume it is something that could be added, though, but I’m not familiar enough with that ecosystem right now. Has the whole plots recipe story settled, or is that all in flux with the imminent Makie.jl story? I have to admit I haven’t followed this closely. BUT, it would be great to use vega and vega-lite plotting capabilities for non grammar of graphics APIs as well.
2 Likes
I think the recipes API is still evolving because of Makie.jl. Maintainers of these projects already pointed out that their plan is to migrate all existing recipes as smooth as possible to the new ecosystem.
Vega-Lite and Vega themselves are language-agnostic recipe systems (plus the runtime implemented in JavaScript). I think a better direction is to implement Vega-Lite/Vega runtime in Julia to handle amount of data which is too large to put in row-oriented JSON format. It would be beneficial for people outside Julia community, too. Of course, this is a pretty ambitious project… (Also, there is already https://github.com/vega/vega-loader-arrow so this may not be necessary at all)
1 Like
My wish list:
- Simple way to generate independent Shared / Static Libraries from Julia code which doesn’t require embedding Julia when linked to a C / C++ code. With support for Windows, macOS and Linux.
- Easily generate standalone applications from Julia code with UI.
- First class support for Intel MKL with all optimizations (JIT in MKL, Batch API, Compact API, etc…). Including utilizing MKL Solvers, MKL Sparse Matrices support, etc…
- First class support for Intel SVML.
- Better control for vectorization of code.
9 Likes
This is a little off topic with regards to the original post, feel free to split this discussion out into a separate thread.
Yes, that sounds very interesting. Reading through the paper explaining vega-lite, it seems to me that there are shared goals between vega-lite and Makie with respect to interactivity. One key advantage of vega-lite is that you can send interactive visualizations to people and they can open it in their browsers without jumping over any installation hurdles. My understanding is that WGLMakie will bring similar functionality to Makie.
To me, the logical way to make vega/vega-lite available in a non grammar of graphics form would be to make a vega/vega-lite backend for either Plots.jl or Makie.jl. Or were you thinking of making a non grammar of graphics API that is separate to those packages?
Making a separate API would be sad because then you can’t support plot recipes. However, making vega-lite a backend to Plots/Makie is also sad because then you lose the grammar of interactive graphics which one of the central features of vega-lite.
Maybe we should just be greedy and do both.
Complete Elimination of compilation latency! When installling a package, I imagine a scrip called, to_compile.jl can be supplied with the package and anything contained within it will be compiled, so that when you load up a packages it just loads the compile versions so it starts up until you try to run a funcion that isn’t in the to_compile.jl then it will compile, otherwise my true feelings are that Julia feel too “lethargic” to use. But compiliation latency is a top prioritise as listed in the “What’s bad about Julia” talk at Juliacon 2019. So I am sure something is being worked on.
JuliaDB.jl! Everytime it nevered worked for my use-case and the thing is I can’t share the data that I tried to use it with! So I can’t give the JuliaDB team much useful info! Also some key features seems to be missing from JuliaDB (e.g. chunks argument to loadtable not working as expected · Issue #257 · JuliaData/JuliaDB.jl · GitHub).
I still use R for larger data because JuliaDB.jl doesn’t work on my data. It’s hard to beat R’s data.table though, so I have builit a R medium data tool (GitHub - DiskFrame/disk.frame: Fast Disk-Based Parallelized Data Manipulation Framework for Larger-than-RAM Data) which is generating some interests in the R community. Once I am happy with the R pacakge, I might create a disk.frame.jl package. I think CSV.jl and DataFrames.jl have come a long way!
2 Likes
Hi @Maurizio_Tomasi,
since the pull request #68 has been merged, YAML.jl is able to emit Julia objects to YAML files (and YAML-formatted strings).
1 Like
A Julia interface to distributed-memory FFTW-MPI that works with DistributedArrays.jl.
3 Likes
A dataframe package that works and is fast as data.table in R. This would be a killer feature to bring over a lot of people that use R and Python for data analysis, which in turn would bring even more development support.
1 Like
More generic UI widgets. IE: Interactive plots, click and drag event listeners.
2 Likes
I wish Julia version of Simulink. It will be the lethal strike to Matlab.
5 Likes
Hold your horses.
9 Likes
The option to create concretely “typed” functions similar to FunctionWrappers.jl (except without the ccall and both the run time and compilation overheads which are currently killing me).
2 Likes
I want to share that I have worked on getting my top coveted functionality for the ecosystem.
5 Likes