What are your most coveted functionalities missing in the ecosystem?

A library like python’s xarray - I.e. n dimensional arrays with named and indexable axes. AxisArrays is a good foundation, but is missing a lot of the fantastic broadcasting behaviours that make xarray nice.

If there is promise for your use here https://github.com/JeffreySarnoff/CatmullRom.jl, let me know what modifications would be of use to you.

1 Like

I wish for:

  • a fast, stable, easy to use library which can interact with Postgres/PostGIS; bonus points for taking advantage of the GIS features. Possibly this exists and I don’t know about it.
  • More user friendly tools around libGEOS, GDAL, etc. The existing Julia libraries are powerful but low level.
  • callbacks to return to JuMP
3 Likes

AOT, please, executables are sexy

15 Likes

FYI I am working on some Mapnik bindings for Julia at the moment. Once it’s ready it could be used as a base to develop other geo-related packages. There’s also Turf.jl that adds the Turf functionalities to Julia.

1 Like

A usable way to distribute stand-alones

5 Likes

Someone will probably tell me that JLD works just fine, or that the matlab version is full of problems. But with that said:

When I used matlab I really liked the function save, which did let me save everything in a workspace. Later I could just load it back with load. It was a while ago since I used matlab, but this is the only feature which I really miss. I understand that JLD should be used for this kind of stuff. I have tried it out maybe three times now (with time intervals) and never gotten it to work. This compared to matlab were it all worked without effort.

1 Like

I’m experimenting with something like xarray for geospatial data.

The idea is to make a common wrapper for various existing spatial data packages with a very minimal interface.

It’s still very much work in progress but does some things xarrays does, like take the mean (or whatever) of a 3d Lat/Lon/Time dataset over the time dimension:

plot(mean(g; dims=Time()))

mean_surface_temp

What kinds of interpolations? Maybe GeoStats.jl estimation problems can be useful. Sharing just in case.

My wish list:

  1. A stable plotting system that just works (Makie.jl is not ready, and Plots.jl is… you know)
  2. A stable mechanism for precompiling full environments as opposed to just isolated packages
  3. A comprehensive package for probabilistic graphical models a la pgmpy
  4. A package for 3D meshing without external dependencies written in other languages
  5. A VTK.jl package that has WriteVTK.jl as well as “ReadVTK.jl” functionality

Besides functionality and packages, it would be really great if experienced Julia users could compile a book on HPC with Julia. There are many parallel models in the language, but the community is lacking the necessary training to pick the most appropriate model for the problem at hand.

8 Likes

Give VegaLite.jl a shot!

We’ve added experimental support for easily compiling a sys-image for an environment in the latest VS Code extension. Probably not perfect, but I’d love to hear feedback on how that works.

3 Likes

Is this a possible solution? https://github.com/cdr/code-server
@davidanthoff

Thank you @davidanthoff! VegaLite.jl is a really beautiful work. My main use case however is plot recipes. Does VegaLite.jl support plot recipes? When it comes to plotting dataframes and tabular data in general, I recommend VegaLite.jl to colleagues.

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 :slight_smile:

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:

  1. 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.
  2. Easily generate standalone applications from Julia code with UI.
  3. 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…
  4. First class support for Intel SVML.
  5. 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.