JuliaInterop / JavaCall.jl

Call Java from Julia
http://juliainterop.github.io/JavaCall.jl
Other
118 stars 53 forks source link

jvoid missing in JavaCall v0.7.7 #153

Closed bardo84 closed 2 years ago

bardo84 commented 2 years ago

Hi, using your jmathplot example and [494afd89] JavaCall v0.7.7 installed, I get ERROR: LoadError: UndefVarError: jvoid not defined temp fix using jvoid = Nothing

BTW 1) jcall(frame, "pack", jvoid) ERROR: MethodError: no method matching jcall(::JavaObject{Symbol("javax.swing.JFrame")}, ::String, ::Type{jvoid})

BTW 2) How to conditionally avoid ERROR: LoadError: JavaCall.JavaCallError("JVM already initialised")

BTW 3) The whole jmathplot effort was to have a lightweight drawing pane (text, line) allowing interactivity and possibly callbacks. Do you have something in this direction?

Thx again!

mkitti commented 2 years ago

Just use Nothing for jvoid.

1) jcall(frame, "pack", jvoid, ()) 2) Check JavaCall.isloaded() before calling JavaCall.init() 3) In Julia? Sure. Plenty. I might start with Plots.jl using either the GR or PyPlot backends. If you need something very light weight, I would consider using GR.jl directly or GRUtils.jl. You might consider combining GR.jl with QT / QML.jl. If you want something more, I would suggest Makie.jl. There are also several wrappers around GNUPlot such as Gaston.jl

It's probably best to ask these kind of questions on Discourse. You might also try searching for answers there as well.

mkitti commented 2 years ago

Per README, 0.7 branch is currently being maintained for bug fixes only.

bardo84 commented 2 years ago

3x thank you! I know all these packages. My quest for a drawing pane allowing interactivity is more for low-level. Now every package depends on one drawing backend, does something right but misses another feature, Like Plots.jl translates a common plot syntax to various backends, I wonder if it could make sense to provide an interface at the lowest drawing level. Then one could separate the elaborated scaling/margin/grouping/updating from the actual physical drawing backend.

mkitti commented 2 years ago

PyPlot is quite comprehensive in it's functionality. If you want something low level, I would focus on the C API exposed in GR.jl as documented here: https://gr-framework.org/c.html https://gr-framework.org/julia-gr.html I do not think you can get much lower level than that.

Also I forgot to mention https://gadflyjl.org/

bardo84 commented 2 years ago

Hm. The lowest denominator should be drawing + interactivity. The latter is often lacking. I am quite satisfied with Makie for fine-grain control. With InteractiveViz.jl everything could be fine, have to see. But Makie has among the longest TTFP - not lightweight.

mkitti commented 2 years ago

What kind of interactivity and in what context? GR has interactive capability including pan, zoom, and datatips. You can also program additional functionality via callbacks. Interactivity works both in native windows and in the browser.

For example, see https://twitter.com/josef_heinen/status/1308733083101925381.

It is also configurable to the degree that I can lower the the time to first plot to less than a second even on Windows: https://discourse.julialang.org/t/why-is-plotting-with-gr-faster-when-using-gr-jll-and-ccall-directly/58199/2

mkitti commented 2 years ago

Overall, the strategy to lower the time to first plot is to compile as much as possible ahead of time. The GR-based approach to this is staying as close to the ccalls as possible and then trying to precompile the rest.

bardo84 commented 2 years ago

Thats the more annoying side of Julia: incomplete or outdated documentation. GR is not listed as "interactive" in the Plots.jl doc. I also looked for GR interactive on the Web, found nothing. THX!

mkitti commented 2 years ago

Anyways, I would much rather have this conversation on Discourse since it would much easier for others to find it when they have the same question. Could you start a thread there and link it here?

bardo84 commented 2 years ago

sure