Tag InspectDR v0.1.2 [https://github.com/ma-laforge/InspectDR.jl]

[ma-laforge]

Add support for Plots.jl

Also:
Add sample notebooks.
Improve F1 accelleration.

[tkelman]

Don't you unconditionally depend on Gtk? When does it fail to load? You currently don't have precompilation explicitly turned on, but if your module was imported by one that did, then the try-catch importing of Gtk would not interact well with precompilation.

[ma-laforge]

Don't you unconditionally depend on Gtk?

No, my situation is sort of like ProfileView (which also depends on Gtk - i.e. in REQUIRE).

When does it fail to load?

Gtk fails to load in the JuliaBox environment for some reason, but InspectDR is developped in layers such that the Cairo layer still works fine to construct plots as images - even if the GUI/widgets cannot be created/displayed.

I noticed ProfileView uses conditional inclusions in its __init__() code instead:

isdefined(Main, :IJulia) && !isdefined(Main, :PROFILEVIEW_USEGTK)

...But InspectDR typically works fine in IJulia... this seems to be more of a JuliaBox issue.

You currently don't have precompilation explicitly turned on, but if your module was imported by one that did, then the try-catch importing of Gtk would not interact well with precompilation.

Good to know, thanks. Is this because of it being a try-catch specifically? Is it because precompilation does not deal well with conditional inclusion in general?

@tkelman /anybody: Do you have any good suggestion on how to handle this?: I could add a conditional inclusion similar to isdefined(Main, :PROFILEVIEW_USEGTK) but this will not help users that are unaware of the Gtk issue/bypass switch solution (they might just give up on the package altogether).

I would rather be able to at least inform users of the failed attempt at loading Gtk and how to circumvent the issue - so the solution is self-documenting.

[tkelman]

If this is JuliaBox-specific, is there an issue that has more details on it? Maybe we can fix the underlying problem and make such workarounds unnecessary.

Is it because precompilation does not deal well with conditional inclusion in general?

Right.

[tkelman]

A somewhat tedious, but will-work-now option would be to split the package up into separate pieces, one for the parts that can work with just Cairo vs the parts that also need Gtk.

[ma-laforge]

If this is JuliaBox-specific, is there an issue that has more details on it? Maybe we can fix the underlying problem and make such workarounds unnecessary.

JuliaGraphics/Gtk.jl#279

A somewhat tedious, but will-work-now option would be to split the package up into separate pieces, one for the parts that can work with just Cairo vs the parts that also need Gtk.

... I would not mind this option that much if we could have multiple Julia packages bundled under a single GIT repository. It is sort of a pain to divide two tightly coupled modules (ie Gtk<->Cairo layers) into two separate GIT repositories.

[ma-laforge]

The problem sounds alot like what is discussed in:
JuliaLang/julia#6195

Thinking aloud:
Would it be ok to push the Gtk-specific code to a "GtkLayer" module within the "InspectDR" package?

--> That would allow me to keep everything within the same GIT repository/Julia package

Q: But would there still be a precompilation issue here?

[tkelman]

ProfileView has a little hack that makes something like that kinda work, ref timholy/ProfileView.jl#38 (comment)

[ma-laforge]

Cannot easily get ProfileView hack to work in my context due to cyclical issues:

Gtk layer depends on base... which won't pre-compile before core functionnality is pre-compiled.

This small workaround for a bug with the JuliaBox/Gtk installation is not worth it at this time.