felipereigosa / mock-mechanics

Mechanical/visual programming language
MIT License
168 stars 7 forks source link

run.sh crashes, Java 17, Mac M1 #1

Open eggsyntax opened 2 years ago

eggsyntax commented 2 years ago

liblwjgl.dylib not included, it looks like? Happy to provide any other info that would be helpful! Java info at the bottom.

[20:22] mock-mechanics-1.3-java> ./run.sh
OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=deny; support was removed in 17.0
[LWJGL] Failed to load a library. Possible solutions:
    a) Add the directory that contains the shared library to -Djava.library.path or -Dorg.lwjgl.librarypath.
    b) Add the JAR that contains the shared library to the classpath.
[LWJGL] Enable debug mode with -Dorg.lwjgl.util.Debug=true for better diagnostics.
[LWJGL] Enable the SharedLibraryLoader debug mode with -Dorg.lwjgl.util.DebugLoader=true for better diagnostics.
Exception in thread "main" java.lang.UnsatisfiedLinkError: Failed to locate library: liblwjgl.dylib
    at org.lwjgl.system.Library.loadSystem(Library.java:162)
    at org.lwjgl.system.Library.loadSystem(Library.java:62)
    at org.lwjgl.system.Library.<clinit>(Library.java:50)
    at org.lwjgl.glfw.GLFW.<clinit>(GLFW.java:674)
    at temp.keymap__init.load(Unknown Source)
    at temp.keymap__init.<clinit>(Unknown Source)
    at java.base/java.lang.Class.forName0(Native Method)
    at java.base/java.lang.Class.forName(Class.java:467)
    at clojure.lang.RT.classForName(RT.java:2211)
    at clojure.lang.RT.classForName(RT.java:2220)
    at clojure.lang.RT.loadClassForName(RT.java:2239)
    at clojure.lang.RT.load(RT.java:449)
    at clojure.lang.RT.load(RT.java:424)
    at clojure.core$load$fn__6839.invoke(core.clj:6126)
    at clojure.core$load.invokeStatic(core.clj:6125)
    at clojure.core$load.doInvoke(core.clj:6109)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
    at temp.core__init.load(Unknown Source)
    at temp.core__init.<clinit>(Unknown Source)
    at java.base/java.lang.Class.forName0(Native Method)
    at java.base/java.lang.Class.forName(Class.java:467)
    at clojure.lang.RT.classForName(RT.java:2211)
    at clojure.lang.RT.classForName(RT.java:2220)
    at clojure.lang.RT.loadClassForName(RT.java:2239)
    at clojure.lang.RT.load(RT.java:449)
    at clojure.lang.RT.load(RT.java:424)
    at clojure.core$load$fn__6839.invoke(core.clj:6126)
    at clojure.core$load.invokeStatic(core.clj:6125)
    at clojure.core$load.doInvoke(core.clj:6109)
    at clojure.lang.RestFn.invoke(RestFn.java:408)
    at clojure.lang.Var.invoke(Var.java:384)
    at clojure.lang.Util.loadWithClass(Util.java:251)
    at temp.core.<clinit>(Unknown Source)

[20:22] mock-mechanics-1.3-java> java --version
openjdk 17 2021-09-14
OpenJDK Runtime Environment Temurin-17+35 (build 17+35)
OpenJDK 64-Bit Server VM Temurin-17+35 (build 17+35, mixed mode)
felipereigosa commented 2 years ago

You got the latest version from the website right? That version is a little old, I need to create a new one. Or you could try running it from source, I'm not sure how familiar you are with clojure but if you don't know it's really simple, install leiningen and then go to the mock mechanics root directory and do "lein run". You should still run into that problem though as there are indeed issues on Mac so I left the library natives out for the time being. With the library, it crashes, something to do with OpenGL. It's a bit difficult for me to solve the problem since I don't own a mac. I don't know if you are familiar with java but if you want to try to find the problem I have a hello world opengl program as a single java file that has the same problem I think. If you can debug that and tell me what's wrong I can apply the fix to mock mechanics. It has something to do with the opengl context on the main thread I believe. I'm attaching the mini project with the file, if you don't know how or don't feel like it no problem someone else will help me debug this sooner or later so you have to be a little patient.

https://mockmechanics.com/mac-bug.zip

eggsyntax commented 2 years ago

Gotcha! Time is tight currently, just wanted to let you know as an FYI. I'm solid on Clojure, decent on Java although I don't do much Java-level debugging. I'll take a quick look but probably can't spend too much time. Thanks!

eggsyntax commented 2 years ago

In case it's useful, just as initial info here's the output of running run.sh (from the attached mac-bug program) after adding the -Dorg.lwjgl.util.Debug=true argument to the last line of run.sh:

[22:03] mac-bug> ./run.sh
[LWJGL] Version: 3.2.3 build 13
[LWJGL]      OS: Mac OS X v12.5.1
[LWJGL]     JRE: 17 aarch64
[LWJGL]     JVM: OpenJDK 64-Bit Server VM v17+35 by Eclipse Adoptium
[LWJGL] Loading JNI library: lwjgl
[LWJGL]     Module: org.lwjgl
[LWJGL]     macos/arm64/org/lwjgl/liblwjgl.dylib not found in java.library.path=/Users/egg/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
[LWJGL]     liblwjgl.dylib not found in java.library.path
[LWJGL] Failed to load a library. Possible solutions:
    a) Add the directory that contains the shared library to -Djava.library.path or -Dorg.lwjgl.librarypath.
    b) Add the JAR that contains the shared library to the classpath.
Exception in thread "main" java.lang.UnsatisfiedLinkError: Failed to locate library: liblwjgl.dylib
    at org.lwjgl.system.Library.loadSystem(Library.java:162)
    at org.lwjgl.system.Library.loadSystem(Library.java:62)
    at org.lwjgl.system.Library.<clinit>(Library.java:50)
    at org.lwjgl.glfw.GLFW.<clinit>(GLFW.java:674)
    at Main.<init>(Main.java:72)
    at Main.main(Main.java:152)
eggsyntax commented 2 years ago

Looks like there were problems specific to Apple's new (ARM-based) M1/M2 chips, which were resolved as of LWJGL 3.3.0. From the above it looks like you have a dependency on 3.2.3, so it seems like updating your dep to 3.3.0 would fix.

https://github.com/libgdx/libgdx/issues/6084#issuecomment-980811411

eggsyntax commented 2 years ago

I don't know anything at all about LWJGL, unfortunately; this is the first I've heard of it.

eggsyntax commented 2 years ago

I'm a bit confused that in the MANIFEST the references are all to version 1.0.0 of the jar:

Class-Path: lib/lwjgl-1.0.0.jar lib/lwjgl-glfw-1.0.0.jar lib/lwjgl-glfw-natives-linux-1.0.0.jar lib/lwjgl-glfw-natives-macos-1.0.0.jar lib/lwjgl-natives-linux-1.0.0.jar lib/lwjgl-natives-macos-1.0.0.jar lib/lwjgl-opengl-1.0.0.jar lib/lwjgl-opengl-natives-linux-1.0.0.jar lib/lwjgl-opengl-natives-macos-1.0.0.jar

Not sure how to connect that to the version numbers of the actual LWJGL releases?

eggsyntax commented 2 years ago

Oh, weird, but in the actual mock-mechanics repo, it does look like you're depending on 3.3.1 which shouldn't have that problem...

  :dependencies ~(concat '[[org.clojure/clojure "1.10.0"]
                           [org.clojars.nakkaya/jbullet "20101010"]
                           [org.apache.xmlgraphics/batik-all "1.14" :extension "pom"]]
                         (lwjgl ["lwjgl"
                                 "lwjgl-opengl"
                                 "lwjgl-glfw"] "3.3.1"))
felipereigosa commented 2 years ago

Last time I looked at this was a couple of years ago, if just updating the dependency solves it that would be great. I'll have a look soon and let's hope. No worries if you are busy, thanks for taking the time so far in any case. Regarding the 1.0.0 versions, I remember creating them manually, I think I got them from another project and didn't know the version so just named something convenient that would work with my local maven, thankfully I've since found out how to get the proper lein dependencies.

felipereigosa commented 2 years ago

Did it crash with lein run on the repo? I don't think anyone has tried on mac since I changed to the lein dependencies, maybe it's working already?

eggsyntax commented 2 years ago

Hadn't tried yet; was looking on clojars to try to figure out which of the many lwjgl libs there is the one that you have 😆

Checking now!

felipereigosa commented 2 years ago

Oh and I think you have to add the mac natives to the project.clj

felipereigosa commented 2 years ago

I think changing the lwjgl function in the project.clj to this should do it:

(defn lwjgl [names version] (mapcat (fn [name] (let [artifact (symbol "org.lwjgl" name)] [[artifact version] [artifact version :classifier "natives-linux" :native-prefix ""] [artifact version :classifier "natives-macos" :native-prefix ""]])) names))

eggsyntax commented 2 years ago

Hmm, no, crashes for me with an error that's not obviously related to LWJGL; lengthy stack trace below.

Will try updating project.clj!

java.io.FileNotFoundException: /Users/egg/tmp/mock-mechanics/target/default+64c62472/440a0aac8958c7213ed78fae906cd6a8ccde419df1e2407614d65f3cdeeae9ca-init.clj (No such file or directory)
 at java.io.FileOutputStream.open0 (FileOutputStream.java:-2)
    java.io.FileOutputStream.open (FileOutputStream.java:293)
    java.io.FileOutputStream.<init> (FileOutputStream.java:235)
    clojure.java.io$fn__11522.invokeStatic (io.clj:230)
    clojure.java.io/fn (io.clj:230)
    clojure.java.io$fn__11459$G__11428__11466.invoke (io.clj:69)
    clojure.java.io$fn__11496.invokeStatic (io.clj:166)
    clojure.java.io/fn (io.clj:166)
    clojure.java.io$fn__11472$G__11424__11479.invoke (io.clj:69)
    clojure.java.io$writer.invokeStatic (io.clj:119)
    clojure.java.io$writer.doInvoke (io.clj:104)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.core$apply.invokeStatic (core.clj:669)
    clojure.core$spit.invokeStatic (core.clj:6956)
    clojure.core$spit.doInvoke (core.clj:6956)
    clojure.lang.RestFn.invoke (RestFn.java:425)
    leiningen.core.eval$shell_command.invokeStatic (eval.clj:240)
    leiningen.core.eval$shell_command.invoke (eval.clj:233)
    leiningen.core.eval$fn__7103.invokeStatic (eval.clj:263)
    leiningen.core.eval/fn (eval.clj:261)
    clojure.lang.MultiFn.invoke (MultiFn.java:234)
    leiningen.javac$run_javac_subprocess.invokeStatic (javac.clj:128)
    leiningen.javac$run_javac_subprocess.invoke (javac.clj:115)
    leiningen.javac$javac.invokeStatic (javac.clj:147)
    leiningen.javac$javac.doInvoke (javac.clj:136)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:669)
    clojure.core$apply.invoke (core.clj:662)
    leiningen.core.main$partial_task$fn__7340.doInvoke (main.clj:284)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:31)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:669)
    clojure.core$apply.invoke (core.clj:662)
    leiningen.core.main$apply_task.invokeStatic (main.clj:334)
    leiningen.core.main$apply_task.invoke (main.clj:320)
    leiningen.core.eval$run_prep_tasks.invokeStatic (eval.clj:51)
    leiningen.core.eval$run_prep_tasks.invoke (eval.clj:43)
    leiningen.core.eval$prep.invokeStatic (eval.clj:86)
    leiningen.core.eval$prep.invoke (eval.clj:73)
    leiningen.core.eval$eval_in_project.invokeStatic (eval.clj:364)
    leiningen.core.eval$eval_in_project.invoke (eval.clj:358)
    leiningen.core.eval$eval_in_project.invokeStatic (eval.clj:362)
    leiningen.core.eval$eval_in_project.invoke (eval.clj:358)
    leiningen.run$run_main.invokeStatic (run.clj:130)
    leiningen.run$run_main.invoke (run.clj:123)
    leiningen.run$run.invokeStatic (run.clj:157)
    leiningen.run$run.doInvoke (run.clj:134)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:669)
    clojure.core$apply.invoke (core.clj:662)
    leiningen.core.main$partial_task$fn__7340.doInvoke (main.clj:284)
    clojure.lang.RestFn.invoke (RestFn.java:410)
    clojure.lang.AFn.applyToHelper (AFn.java:154)
    clojure.lang.RestFn.applyTo (RestFn.java:132)
    clojure.lang.AFunction$1.doInvoke (AFunction.java:31)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.core$apply.invokeStatic (core.clj:669)
    clojure.core$apply.invoke (core.clj:662)
    leiningen.core.main$apply_task.invokeStatic (main.clj:334)
    leiningen.core.main$apply_task.invoke (main.clj:320)
    leiningen.core.main$resolve_and_apply.invokeStatic (main.clj:343)
    leiningen.core.main$resolve_and_apply.invoke (main.clj:336)
    leiningen.core.main$_main$fn__7429.invoke (main.clj:453)
    leiningen.core.main$_main.invokeStatic (main.clj:442)
    leiningen.core.main$_main.doInvoke (main.clj:439)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.core$apply.invokeStatic (core.clj:667)
    clojure.main$main_opt.invokeStatic (main.clj:514)
    clojure.main$main_opt.invoke (main.clj:510)
    clojure.main$main.invokeStatic (main.clj:664)
    clojure.main$main.doInvoke (main.clj:616)
    clojure.lang.RestFn.applyTo (RestFn.java:137)
    clojure.lang.Var.applyTo (Var.java:705)
    clojure.main.main (main.java:40)
eggsyntax commented 2 years ago

Hmm, no, same error. Trying a lein clean...

eggsyntax commented 2 years ago

Nope, same. Sorry, I've gotta call it a night, will check back in tomorrow if I can. Thanks for all the help!

felipereigosa commented 2 years ago

No, thank you :)

ig0revich commented 2 years ago

@eggsyntax Could you please try my port from https://github.com/ig0revich/mock-mechanics ?

eggsyntax commented 2 years ago

Hi @ig0revich, thanks! that causes a Java screen to load, but I can't click on any of the buttons or seem to do anything, although I can zoom in and out by two-finger scrolling on the trackpad.

Console messages are:

[18:15] mock-mechanics-m1> lein run
OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=deny; support was removed in 17.0
Compiling 1 source files to /Users/egg/tmp/mock-mechanics-m1/target/default/classes
OpenJDK 64-Bit Server VM warning: Ignoring option --illegal-access=deny; support was removed in 17.0
Warning: the fonts "Times" and "Times" are not available for the Java logical font "Serif", which may have unexpected appearance or behavior. Re-enable the "Times" font to remove this warning.
2022-09-30 18:16:16.485 java[56853:11290613] [JRSAppKitAWT markAppIsDaemon]: Process manager already initialized: can't fully enable headless mode.
image
felipereigosa commented 2 years ago

@eggsyntax ig0revich showed me a picture exactly like this one at one point and after that he fixed a bug in the gl-println function in window.clj . I wasn't there so can't answer for him but this might be it, that function is still throwing errors, although not preventing the program from working on our machines. Try commenting out the whole body of gl-println and see if it helps, I need to rewrite that part of the code anyway.

felipereigosa commented 2 years ago

Also maybe you can't click the buttons just because they are out of place, if you start typing does the text appear on the black line at the bottom of the screen? If so try doing Ctrl + o, type piano then press enter to see if it works.

eggsyntax commented 2 years ago

Also maybe you can't click the buttons just because they are out of place, if you start typing does the text appear on the black line at the bottom of the screen? If so try doing Ctrl + o, type piano then press enter to see if it works.

That does work!

And I figured something out, more or less accidentally -- the buttons are out of place in a way that seemingly has to do with the way it's only showing content on the bottom left of the Java window. If I click on the screen or resize the window, it sometimes (but not always) corrects the problem and shows the content on the full window, and then the buttons work. And then sometimes other actions will cause the problem to reappear. Also when the error is present, I can still click on the location where the buttons should be, and they work.

I grabbed a screen recording that demonstrates most of the above:

https://user-images.githubusercontent.com/1233514/193378194-8e781a0f-74f9-48dd-8b2d-6ffdf05be046.mp4

eggsyntax commented 2 years ago

Try commenting out the whole body of gl-println and see if it helps, I need to rewrite that part of the code anyway.

That has no effect on the error I'm experiencing.

felipereigosa commented 2 years ago

You know what it looks like? Either the glViewport function on window/recompute-viewport is not being called or called with the wrong values. It looks like half the width and half the height to me but I don't know what would cause that... If you want to investigate that yourself, try printing the width, height values in that function and see if they make sense given the size of the window and that the glViewport function actually gets called (nothing fails silently above it). There's also a glViewport on window-init! but you say the problem keeps happening after the window is created so I don't think that's where the problem is.

felipereigosa commented 2 years ago

@ig0revich I don't know if you've seen the last message I sent you through reddit, but your changes mostly work over here, I just needed to make a few adjustments on the project.clj file, if you could double check it still works there with those changes I'd appreciate it.