Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

setup instructions for building/running LXStudio from command line + vscode #7

Open
oveddan opened this issue Jun 29, 2023 · 6 comments

Comments

@oveddan
Copy link

oveddan commented Jun 29, 2023

It would be great to be able to use VSCode when developing against the IDE. For example VSCode has an amazing plugin ecosystem, including github copilot.

Is it possible to build/run the project entirely form the command line, and if so, are there any instructions on how to do that?

@oveddan oveddan changed the title setup instructions for command line + vscode setup instructions for building/running LXStudio from command line + vscode Jun 29, 2023
@mcslee
Copy link
Member

mcslee commented Jun 30, 2023

I am not sure about VSCode for Java myself, as I have been out of Windows land for a while. But there is a fully CLI-buildable version of LXStudio here: https://github.com/heronarts/LXStudio-IDE - that is set up for Eclipse/IntelliJ, but if VSCode supports Maven, driven by the pom.xml than it shouldn't be far to go from there.

This bypasses all the Processing IDE stuff and goes straight to using Maven for build configuration.

Eventually this will all be subsumed by the successor version of LXStudio, which will be retitled Chromatik and completely free of any of the Processing dependency chain. I don't have a hard ETA on that just yet, so for the meantime, LXStudio-IDE is your best indication of an IDE-driven build system.

@mcslee mcslee closed this as completed Jun 30, 2023
@oveddan
Copy link
Author

oveddan commented Jun 30, 2023

Ah VSCode is OS agnostic (not just for Windows) and is among the most popular IDEs out there.

And yeah you can run maven commands via VSCode with the command line:

Screenshot 2023-06-30 at 7 50 02 AM

I got it working on my Mac with Ventura by doing the following:

  1. Installing Eclipse Temurin 17 (17.0.2+8)
  2. Open the folder in VSCode.
  3. Install the Extension Pack for Java
  4. In the terminal, from the root of the project, run: mvn clean then mvn install (I'm a total n00b to Java / maven so not sure exactly if I need to run these but it was a brute force approach).
  5. cd lib/processing-4.0.1 then ln -hsf macos-aarch64 native (since I'm on a Mac silicon)
  6. Configure launch.json (as instructed in the VSCode documentation):
Screenshot 2023-06-30 at 8 17 15 AM

Select the java project, Then open the menu "Run" -> "Run without debugging":

Screenshot 2023-06-30 at 8 19 48 AM

At this point I ran into an error:

[LX 2023/06/30 08:20:30] Initializing LX version 0.4.1
[LX 2023/06/30 08:20:30] Running java 17.0.7 Eclipse Adoptium Mac OS X 13.2 aarch64
Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /Users/danoved/Source/shady-leds-lx/LXStudio-IDE/natives/macosx-universal/gluegen_rt

It seems it is not picking up the -Djava.library.path=lib/processing-4.0.1/native flag as I'm able to fix the problem by in the root of the project running: ln -hsf lib/processing-4.0.1/macos-aarch64 natives and I got it to run successfully :)

Any idea where in the launch.json That argument should go?

@mcslee
Copy link
Member

mcslee commented Jun 30, 2023

Man wow I am behind the times, didn't realize VSCode had gone cross-platform. Nice. Will have to give it a whirl sometime.

These library config things are the worst (one of many reasons I'm moving on from the Processing runtime).

It seems it is not picking up the -Djava.library.path=lib/processing-4.0.1/native flag as I'm able to fix the problem by in the root of the project running: ln -hsf lib/processing-4.0.1/macos-aarch64 natives and I got it to run successfully :)

I wonder if the symlink is a mess here. Can you quickly test on your system, does it work on your system if rather than -Djava.library.path=lib/processing-4.0.1/native you just supply the full path to the specific architecture for your system, instead of the symlink?

@mcslee mcslee reopened this Jun 30, 2023
@oveddan
Copy link
Author

oveddan commented Jun 30, 2023

thanks for your help! Yeah I def recommend trying it.

I realized my issue was that in my launch.json, there were two configurations (not sure where that came from):

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "type": "java",
      "name": "Current File",
      "request": "launch",
      "mainClass": "${file}"
    },
    {
      "type": "java",
      "name": "LXStudioApp",
      "request": "launch",
      "mainClass": "heronarts.lx.app.LXStudioApp",
      "projectName": "lxstudio-ide",
      "vmArgs": "-Djava.library.path=lib/processing-4.0.1/native -XstartOnFirstThread"
    }
  ]
}

and vscode was using the first.

I deleted the first config, and I got it working. Another thing I had to do was remove -XstartOnFirstThread as that was causing java to hang and not launch the app. Here is my working launch.json:

{
  // Use IntelliSense to learn about possible attributes.
  // Hover to view descriptions of existing attributes.
  // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
  "version": "0.2.0",
  "configurations": [
    {
      "type": "java",
      "name": "LXStudioApp",
      "request": "launch",
      "mainClass": "heronarts.lx.app.LXStudioApp",
      "projectName": "lxstudio-ide",
      "vmArgs": "-Djava.library.path=lib/processing-4.0.1/native"
    }
  ]
}

@oveddan
Copy link
Author

oveddan commented Jun 30, 2023

If you'd like I can add these vscode setup instructions to the documentation.

@mcslee
Copy link
Member

mcslee commented Jul 3, 2023

Yeah that would be great if you want to document this. Could also just check in the launch.json file if you like, it looks like everything in there is generic, no local-machine-specific paths, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants