Clojurians Log v2

@pez: FYI, I have created an issue for the jEnv need, as we discussed above: https://github.com/BetterThanTomorrow/calva/issues/1452

@leif.eric.fredheim Do you have eval "$(jenv init -)" in your shell’s rc file (e.g. .zshrc)?

I’m asking because I have that and it seems to me that if I open a new project (with Calva), I get Java 17 environment, but if I open an existing project that has .java-version file, it will use it.

@tero.matinlassi: Yeah, it’s in there 🙂

Interesting… then I’m not sure why it works for me 🙂

That’s fascinating! Maybe I’ve messed up something else in my environment 🤔

I was about to ask on the issue. Have you restarted VS Code since you updated your .zshrc?

You might even have to start VS Code from the terminal to have it inherit the change, until you have restarted the machine.

Oh! I was not aware of that. I'll try to reboot my machine, then try again to see if it works!

This is quite dynamic, wouldn’t you say? 😃

Wow! That’s fantastic, @pez! Exactly what I was trying to achieve! Bravo! 👏 By the way, I think you guys were into something regarding jEnv and Calva. Upon rebooting my Mac and starting VS Code, I noticed this error (see screenshot). Which led me to https://code.visualstudio.com/docs/supporting/faq#_resolving-shell-environment-fails with more info: > “[…] when launched via a UI gesture, VS Code will start a small process to run (or “resolve”) the shell environment defined in your `.bashrc` or `.zshrc` files. If, after 10 seconds, the shell environment has still not been resolved or resolving failed for any other reason, VS Code will abort the “resolve” process […] So it looks like my .zshrc is messed up or something… looking into that now

I have had that situation… How long does it take for you to get a prompt when opening a new terminal?

I found the culprit by enabling start-up profiling in https://iterm2.com, i.e., starting zsh with some additional options, like so: /bin/zsh -i -x. Turns out some of the https://ohmyz.sh plug-ins were causing a long start-up time. Interestingly, the start-up time was no more than 1-2 seconds with iTerm2, but it was slower from VS Code. Seems to be fixed now that I removed a bunch of plug-ins that I wasn’t using anyways (I had just forgotten about enabling them some years ago).

It works like a dream now! (The GIF is a bit laggy, but the experience in CS Code is not.)

Awesome.

I did try to use Quil in VS Code/Calva, but I think I couldn’t get “dynamic workflow” working at all (it’s been a while, so I don’t remember the details). The closest I could get to working was the “alternative” workflow described later in the same page. It wasn’t perfect, for example every time I got an exception in the code, I had to restart the application to resume development. So, not quite smooth…

Would definitely love to see a smooth workflow with Calva, if that’s possible. And of course, working with Processing 4 would be nice (working with old JDK’s is painful..)

@tero.matinlassi: Yes, I had the same experience. I have thus far not been able to get the “alternative REPL workflow” working with VS Code and Calva; only the first approach (but I had to make some code changes to get it working).

I don’t have enough experience with Clojure or TypeScript (used to develop VS Code plug-ins and extend Calva) to get it working. But I will let you know if I manage to figure it out.

What I dont understand is that, when “jacked in” via Leiningen, evaluating an expression in the editor is supposed to be effectively the same as typing the expression directly into the REPL. So I thought it would work to evaluate (use :reload 'quil-workflow.dynamic) in the editor, but it does not for some reason. I suppose one would have to create some kind of wrapper or VS Code plug-in (or extend Calva) to get it working well.

I haven’t read the guide yet, but generally, if the workflow relies on the REPL, then it should be possible to use Calva with it. So your expectations there are correct, I’d say, @leif.eric.fredheim. I expect this to be less about Calva and more about setting up the code structure to support the workflow. Calva does not do much in the way of magic, it just an interface to the REPL, really. It was a long time ago I played anything with quil, I will read the guide and see if I can get a nice workflow going.

Thanks, @pez! I appreciate you taking the time to comment and check it out. I also suspect the issue is code organization, some limitation of Quil’s architecture (unlikely), or perhaps some more fundamental limitation of Processing and OpenGL (Quil’s dependencies).

I have read the guide now, we should at least be able to get those things working. I’ll fiddle around a bit and see what I can cook up. On Wednesday I have a full day for Calva things so will try to make a video with my findings. Similar to this one: https://www.youtube.com/watch?v=fJpDztSR53E&t=1s

You’re awesome, @pez! No rush, and thanks again for Calva and your community efforts. I have enjoyed several of your YouTube videos already 🙂 When I get up to speed with Clojure, VS Code and Calva, I will be sure to contribute whenever possible.

@pez: One small gotcha from the Quil guide: I had to change one dependency from [org.clojure/clojure "1.6.0"] to [org.clojure/clojure "1.8.0"] in project.clj for the first example to work, because I was getting an error that CIDER requires a newer version of Clojure. And I have to start the REPL manually in the terminal, then evaluate (use :reload 'quil-workflow.dynamic) directly in the REPL. Then it works. But the same thing does not work when using Calva’s “jack in” and evaluating the same expression via the VS Code editor.

Thanks.

Very strange with the different results.

Indeed, that’s what I’m thinking, too. But I’m quite new to all of this, so there is a decent chance that I’m just doing something incorrectly as well. That is always my first assumption 😅

I have many hours of training in this game, let’s hope I can leverage it. 😃

I don’t get any errors evaluating the use form here

(comment
  (use :reload 'quil-workflow.sketch)
  )

I’m using quil 0.4.4-SNAPSHOT. though, so that might be what is different. Or that I use Java 13 and not 8, as you do.

(I’m also using deps.edn, just because, haha.)

Generally it seems better to try free ourselves out of Java 1.8 jail and unless necessary drop Leiningen for deps.edn/tools-build.

That said. I now tried with Java 1.8 and quil 3.1.10 and get no errors either.

@pez: Thanks for checking/confirming! Then most likely I’m being a dunce, or something is wrong with my system. I’m going to try some more to figure out what I’m doing wrong. And I also need to learn how to use deps.edn/tools-build.

I’ll try to describe what I am doing in a short blog post and probably a video as well, and maybe we can find where things go wrong for you.

There is not much need for the dynamic workflow or anything, afaict. It’s enough to re-evaluate a function using alt+ enter to update the quil as it is running.

Which function are you evaluating to update the drawing?

I’m using these from the leiningen quil template:

(defn setup []
  ; Set frame rate to 30 frames per second.
  (q/frame-rate 30)
  ; Set color mode to HSB (HSV) instead of default RGB.
  (q/color-mode :hsb)
  ; setup function returns initial state. It contains
  ; circle color and position.
  {:color 0
   :angle 0})

(defn update-state [state]
  ; Update sketch state by changing circle color and position.
  {:color (mod (+ (:color state) 0.7) 255)
   :angle (+ (:angle state) 0.1)})

(defn draw-state [state]
  ; Clear the sketch by filling it with light-grey color.
  (q/background 240)
  ; Set circle color.
  (q/fill (:color state) 255 255)
  ; Calculate x and y coordinates of the circle.
  (let [angle (:angle state)
        x (* 150 (q/cos angle))
        y (* 150 (q/sin angle))]
    ; Move origin point to the center of the sketch.
    (q/with-translation [(/ (q/width) 2)
                         (/ (q/height) 2)]
      ; Draw the circle.
      (q/ellipse x y 100 100))))

Same with anything in draw-state.

Ah, I see. I did get that working, but I couldn’t figure out how to update the rendered image without closing and reopening the OpenGL window, and that’s why I started looking at the “dynamic” guide instead. I will go back to that basic example, using the Quil Leiningen template, to see if I can get that working “dynamically” instead.

Which rendered image?

The spinning circles ☺️

I do get the fresh project running with Java 8, but not with newer versions of Java. Shown here using terminal only, to eliminate other potential sources of error. Using Quil v3.1.0 in this case. Now moving to VS Code to try there…

To @tero.matinlassi’s observation about recovering from errors, that too is simply a matter of reevaluating the functions when they are fixed, when I try it. But I’m not using the alternative workflow, of course, so the matter is probably about figuring out why simply re-evaluating the functions doesn’t work for everyone.

In VS Code, when I open core.clj (using the same project as shown in the previous screenshot), I get an error when I try to evaluate this expression on line 36. When I check my Java version in a VS Code terminal, it shows that I’m using Java 8 (which was error-free outside of VS Code). Perhaps VS Code and/or the REPL doesn’t “see” the Java 8 version set through jEnv? And the terminal is “tricking” me. Hmmm.

Now that I re-read some of the documentation, it actually states on the page about alternative workflow that (emphasis mine): > Note this isn’t perfect, for example, changes to setup or if an exception causes m/pause-on-error to trigger, will often require re-creating the window [..] I guess what I would want is that if I fix the error situation, it would continue without the need to re-evaluate sketch function (only needing to evaluate the part that caused the error), but I guess it’s just a limitation of the alternative workflow.

@tero.matinlassi: Yeah, I noticed that part as well for the “alternative workflow.” Now I’m back to trying the basic setup, using the vanilla Leiningen Quil template. It looks like @pez has gotten that to work in a “dynamic” way, by re-evaluating the functions in the template.

To my experience jack-in will use the same java as used by a newly opened terminal pane.

Is there a built-in function of Clojure or the REPL that can be used to see which Java version has actually been loaded? 🤔 searching in docs

That error does look like the error I got when using 3.1.0 and a >1.8 java…

(System/getProperty "java.version") should do it.

^edited 😃

Yes, it’s the same error I see when using 3.1.0 and > Java 1.8 in the terminal as well (shown in my first terminal screenshot above), so I suspect my “jack in REPL” is not using the Java specified by the .java-version file (created by jEnv).

Could be. A way to get around it is to run the Copy Jack-in command line (or whatever the command is named). and paste that in the terminal and then connect, instead of using jack-in.

(Or sdk-man 😃 )

Or start VS Code from a terminal, using the code command.

Or, if, jEnv can read from an environment variable use the jackInEnv setting.

Aha! That seems to be the problem! The terminal in VS Code tells me I’m running Java 8, but the “jack in”/REPL actually loaded Java 15 somehow.

I think I also had some trouble with VS Code and multiple Java versions, but unfortunately I don’t remember how I did get around that… I think VS Code’s Java extension has some way to define the JDK in use but it might not be applied to anything else than (Java) code handled by that extension which was making things more complicated. Probably starting VS Code from terminal was the solution…

Starting the VS Code from a terminal has the drawback that all jack-in sessions will use that Java version. At least for me, who juggles a lot of projects in parallel, that doesn’t work. sdk-man let’s me redefine default system java version at will. So when I have some project that needs some special java version I just use sdk-man.

I don’t understand why jack-in doesn’t get a java version from that .java-versionfile when using jEnv. But then again, TIL that there is a jEnv. 😃

Great success! I got it working by using the Calva command “Copy Jack-in Command to Clipboard,” pasting/executing it in the terminal within VS Code, then using the Calva command “Start or Connect to a Clojure REPL” within my project. Man, Calva is amazing! Thanks, @pez! Next I will try to figure out how to get jEnv to play nicely with VS Code and Calva, but this is a great workaround.

Do you have the :p3d renderer working?

Haha! Every time I evaluate (use 'my-art.core :reload-all) (or with :reload) it creates a new window. But it’s super fast! I’ll try see if I can get :p3d to work as well (haven’t tried that at all yet, actually—not even directly in Processing).

Are you doing defsketch in my-art.core?

I get SIGKILL when trying :p3d so I have so far no reason to use Java 1,8. 😃

Same. I just tried :p3d with Java 8, and it crashes the JVM. Tries and fails to dumps core 😅

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGILL (0x4) at pc=0x00007ff815ec07a3, pid=37157, tid=0x0000000000012a03
#
# JRE version: OpenJDK Runtime Environment (8.0_312) (build 1.8.0_312-bre_2022_01_01_23_04-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.312-b00 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C  [libdispatch.dylib+0x47a3]  _dispatch_assert_queue_fail+0x63
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /Users/leif/art/my-art/hs_err_pid37157.log
#
# If you would like to submit a bug report, please visit:
#   
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Subprocess failed (exit code: 134)

As far as I know, only the p2d and p3d Processing renderers are using OpenGL, and the default renderer when neither of those are specified (forgot what it’s called) does not. I seem to recall seeing something about that in one of the book I’m reading… searching in book Indeed! Found it. The default renderer uses Java 2D instead of OpenGL. This might explain why the OpenGL renderers dump core, even when the default renderer is working fine.

Yeah, so until that’s sorted, seems like Quil 4.0.0-SNAPSHOT is best to use, right? 😃

@pez: Yes, when I use defsketch in my-art.core, it opens a new sketch instead of updated the existing one. The same happens when I use (use 'my-art.core :reload), (use 'my-art.core :reload-all) and also (use 'my-art.core :update).

My understanding from reading the GitHub issues (comments from the creator of Quil) is that Quil 4.0.0-SNAPSHOT does not work with p2d and p3d yet, but the older version with Java 8 is supposed to work. I think that’s the current “blocker” in the “Processing4" branch of Quil, of I’m not mistaken. I will go back to GitHub to check if I have understood that correctly.

Yeah, https://github.com/quil/quil/issues/228#issuecomment-882219561 is the comment I was thinking of: > “You can try using quil 4.0.0-SNAPSHOT but p2d and p3d will likely not work.”

By the way, would it be worth reporting a bug in some GitHub repo about “jack in”/REPL not picking up on the Java version defined by jEnv via .java-version? If that is indeed a valid bug, and not just a fluke on my system. I wouldn't know if that's a bug in VS Code, CIDER, or Calva… or somewhere deeper in Clojure.

It’s a valid feature request at least. Not sure we can fix it, but to have an issue to track the need would be great.

I added info on the renders not working with java 1.8 and quil 3.1.0 on the issue. My guess is that the processing4 branch is where we will see it working first.