asinghvi17
commented
4 months ago What exactly is the issue here? Does GLMakie work normally (try using GLMakie; display(lines(rand(10))))?
Closed sergstesh closed 4 months ago
asinghvi17
commented
4 months ago What exactly is the issue here? Does GLMakie work normally (try using GLMakie; display(lines(rand(10))))?
sergstesh
commented
4 months ago What exactly is the issue here?
As can be seen from the above,
This means that a package has started a background task or event source that has not finished running. For precompilation to complete successfully, the event source needs to be closed explicitly. See the developer documentation on fixing precompilation hangs for more help. .
Does GLMakie work normally ... ?
using GLMakie; display(lines(rand(10)))
produces a window with random data, but, as stated above, there is a problem with zoom in, which is a separate issue.
asinghvi17
commented
4 months ago In this case it looks like an error downloading the MKL artifact, which is not something we can solve here. Could you open another issue for the zooming problem?
sergstesh
commented
4 months ago In this case it looks like an error downloading the MKL artifact, which is not something we can solve here
for starters, IMO the approach is wrong. If a package is being installed, the user should either be sure that the package is installed properly, or a clear message that installation has failed should be issued.
In this case it's neither.
All in all it may be a bug in the whole Pkg infrastructure. For example, the timeout for downloading is too low, or the problematic MKL artifact is not being downloaded at all, but the build process of MKL expects it to be downloaded, and because no actual download is happening, the process times out.
sergstesh
commented
4 months ago Could you open another issue for the zooming problem?
I've been working in High Tech for more than 20 years, and my overall industry experience (HW (analog + digital), SW, VLSI design + verification, CAD/EDA, STA, DSP, etc) is about 40 years. The golden rule is to deal with first error message/problem first. I strongly suggest to read "Everything Is Broken" - https://medium.com/message/everything-is-broken-81e5f33a24e1 .
Since the bug report is closed without proper investigation of the issue, I do not have motivation to file yet another bug report.
I do have my own 'gnuplot' based package which works fine for me; I tried 'GLMakie' in the hope to use well advertised package instead of reinventing the wheel (my 'gnuplot' based package unlike 'Gaston' has separate 'gnuplot' process per window).
So it looks like I'll stick to my 'gnuplot' based package and save time.
asinghvi17
commented
4 months ago Ah, my bad - it seems I didn't notice that you're running on an Intel N100. Do you have an associated GPU? It seems like a low powered processor so that might have something to do with it, but would need more details about what the zooming issue you're facing is to understand this.
sergstesh
commented
4 months ago Do you have an associated GPU?
Yes, the N100 is a system on chip, and it has GPU. The official data on N100: https://ark.intel.com/content/www/us/en/ark/products/231803/intel-processor-n100-6m-cache-up-to-3-40-ghz.html .
would need more details about what the zooming issue you're facing is to understand this
...
Here are two other bug reports I filed in the last about 24 hours: https://github.com/JeffFessler/Sound.jl/issues/29 , https://github.com/JuliaLang/julia/issues/54234 .
The essence of all the reports is that the item they were filed against fails basic sanity check. The 'Sound' report is conceptually similar to this - though the package installs, simple 'using Sound; fails. The report against Julia is that Julia fails its own 'make test'.
Since all three cases are about sanity checks, it should have been the developers, and not me who should have detected the issue.
OTOH, in full accordance with "Everything is broken" Boeing airplanes disintegrate in the air.
So, again, first things first, and I suggest to start debugging from MKL/MKL_jll. The observed phenomena might also be an indication of coroutines/threads/asynchronous execution problem.
While working for a well known company (VLSI, STA role) i was told that they were running a well known game on their chip as a test and found just one pixel with wrong value on the screen. Digging deeper they discovered bus arbitration problem.
asinghvi17
commented
4 months ago Can you use control + left click to reset the axis to original state, or does that not work? This could be either an OpenGL issue or something within Makie, but without the error message I couldn't tell what.
Also, could you post the output of versioninfo() in the REPL?
sergstesh
commented
4 months ago Could you post the output of versioninfo() in the REPL?
julia> versioninfo()
Julia Version 1.10.2
Commit bd47eca2c8* (2024-03-01 10:14 UTC)
Build Info:
Note: This is an unofficial build, please report bugs to the project
responsible for this build and not to the Julia project unless you can
reproduce the issue using official builds available at https://julialang.org/downloads
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: 4 × Intel(R) N100
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-15.0.7 (ORCJIT, goldmont)
Threads: 1 default, 0 interactive, 1 GC (on 4 virtual cores)
julia>
. The info is available in already mentioned in my original report https://github.com/JuliaLang/julia/issues/54234 .
jkrumbiegel
commented
4 months ago Zooming issue sounds like https://github.com/MakieOrg/Makie.jl/issues/3738 or https://github.com/MakieOrg/Makie.jl/issues/1040.
It reads like the warnings about MKL during installation do not affect loading GLMakie, as you can display a test plot
display(lines(rand(10)))produces a window with random data
I understand "random data" not to mean random pixels but just the random data being generated there, so that sounds ok.
If you have trouble with MKL, please file an issue there. Or if you suspect it's a Pkg issue, over there.
Aside from the zooming problem which seems already covered by other issues, I'm closing this as there's nothing actionable for Makie here.
sergstesh
commented
4 months ago It reads like the warnings about MKL during installation do not affect loading GLMakie
However, there might be a case, i.e. a GLMakie function which is not called during loading GLMakie or during the simple test, but is called in other cases, and the function depends on MKL, and in such a case there will be a crash.
sergstesh
commented
4 months ago Zooming issue sounds like https://github.com/MakieOrg/Makie.jl/issues/3738
IIRC that is the case.
SimonDanisch
commented
4 months ago However, there might be a case, i.e. a GLMakie function which is not called during loading GLMakie or during the simple test, but is called in other cases, and the function depends on MKL, and in such a case there will be a crash.
Makie is not using MKL, and even if it would, as far as I can tell your log only shows warnings so it looks to me like MKL will work perfectly fine.
sergstesh
commented
4 months ago your log only shows warnings so it looks to me like MKL will work perfectly fine
According to my understanding of the warnings one can not be sure MKL compilation/installation is actually complete.
Makie is not using MKL
But Makie is using a lot of other packages, and some of the packages might use MKL.
For the above reasons I filed the bug report in the first place.
]activate --temp; add Makie)I have tried to install 'GLMakie' using fresh environment, i.e. with non-existent ~/.julia directory. Detailed data on my setup can be found here: https://github.com/JuliaLang/julia/issues/54234 .
I have tried to install 'GLMakie' the usual way:
.
Screen output of Julia interactive session:
.
As stated above, I've tried the above sequence of actions several times, and have always had the problem with MKL aka MKL_jll.