Update precompile.jl

[oheil]

fix #321

The issue are some Cairo remnants from the precompile step, called when using Luxor. I do not understand the exact details, because I don't want to delve deeper into precompile. Somehow it seems that I knew something when implementing things, because function _reset_all_drawings() exist, which, if called as last command in precompile.jl, resolves the issue.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.43%. Comparing base (b8efebf) to head (2fd4712).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #322      +/-   ##
==========================================
- Coverage   73.45%   73.43%   -0.02%     
==========================================
  Files          36       36              
  Lines        6893     6893              
==========================================
- Hits         5063     5062       -1     
- Misses       1830     1831       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[cormullion]

Thanks! Sorry you spent a day on it 😱😂

[oheil]

Thanks! Sorry you spent a day on it 😱😂

No need for sorry, debugging threading issues is always fun and thrilling. Just wanted to express my effort because the solution is so meager in this case 😂

And there may be more issues in future, OP is right when saying relying on threadid is a problem, but todays experience still didn't open a better path for me. Perhaps I need to do more research on general thread techniques, my guess is, this is a well known computer science problem with a well known approach, but I don't know it yet.

[guo-yong-zhi]

Perhaps the root problem is not the threadid but the global state variables. For example, the famous matplotlib library may also be struggling with the global state. So their explicit object-oriented style (Axes.plot) is currently more recommended for complex or non-interactive drawing instead of the convenient plt.plot one. The explicit style also has better support for multi-threading. I wish the Luxor will also have an explicit form to manage the drawing state.

[cormullion]

An interesting debate. Feel free to open an issue proposing a new design!

I would guess that there are two main ways in which Luxor.jl can be used:

1. as a library controlled by higher-level source code
2. as an interactive exploration environment

I think 1. is basically the same as Cairo.jl - you wouldn’t want to interactively make drawings with Cairo.jl (At least, I don’t - it’s why the package exists at all.)

With 2., I can type drawing commands without any set-up or use of any Julia types - press Shift-Enter and you see the results. And multi-threading doesn’t seem to be as important.

I suppose this interactive “live coding” approach is what I was intending. Otherwise, why not just drive Cairo.jl directly, as indeed many Julia package developers already do? There are a number of packages where graphics are made by calling Cairo.jl functions.

Perhaps there is room for a new ‘library-level’ package interface to Cairo.jl, suitable for use as graphics engine for higher-level packages. Though, if so, why after 10 years aren’t there already lots of them? 😀