network error

[aprilcoffee]

Surprised about this project, therefore downloaded to give it a try.

I'm running with macOS Mojave(10.14.2) Haven't started anything yet, just press the "sketch" button to run, and fail with a "network error" error on the top bar. And everything in the editor view disappeared, and without any way but reopen the application to fix it.

Hope there is any solution, and keep up the great work!

[EmperorJack]

Hi @aprilcoffee,

Thank you for your error report and for trying Visor. To try and narrow down what is going on, could you please send a screenshot of Visor when the error comes up? Also, could you try to open up the developer tools (option + command + i, or view -> toggle developer tools from the menu bar) and then navigate to the console. Here you should see some debug information including errors. Could you please send a screenshot of this information too?

Let me know how you go!

[monkstone]

@aprilcoffee @EmperorJack I wonder could the problem I've just had with linux be similar:- Here is screenshot:-

Now this tells me that Visor is picking up GEM_HOME from ~/.profile on Mint Linux ~/.bashrc on Archlinux:-

export GEM_HOME="$HOME/.gem/ruby/2.5.0"
export GEM_PATH="$HOME/.gem/ruby/2.5.0"
export _JAVA_OPTIONS='-Dsun.java2d.opengl=true'
export PATH="$HOME/bin:$HOME/.local/bin:$GEM_HOME/bin:$PATH"

What is surprising to me is that I was getting away with it before, and it probably helped when I wanted include my vecmath gem.

Anyway a fix is to unset GEM_HOME, but this is not too satisfactory to me as I rely on this setting to run JRubyArt. Following this fix, I can no longer pick up my vecmath gem (PS: I've found rvm to be an absolute pain, and think its design is awful), I also avoid using bundler which doesn't seem to play too well with jruby, but at least it is not evil like rvm.

[EmperorJack]

Thank you for the investigation @monkstone.

I'm using a combination of warbler and bundler under the hood but am making no effort to override GEM_HOME, which appears to be a problem as you have pointed out. If I was to override GEM_HOME then I would still want a way for people to include their own gems, such as your own vecmath. Can you please test if the following works for loading vecmath if you unset your GEM_HOME?

$LOAD_PATH << File.expand_path('path/to/vecmath/lib', __FILE__)
require 'vecmath'

An ideal solution would ensure that any user specified GEM_HOME or GEM_PATH is still appended to the load path to make loading custom gems easy while still enabling Visor to load it's own gems on startup.

[monkstone]

That seems to work, so what I've done for convenience is to create a new linux user sid (on archlinux) with GEM_HOME unset.

$LOAD_PATH << File.expand_path('/home/sid/vecmath/lib', __FILE__)
require 'vecmath'
require 'forwardable'

# Here we use the JRubyArt Vec2D class, and not toxis Vec2D. We avoid using
# ToxicLibsSupport, by using our own GfxRender to translate Vec2D to vertices.
# Further we use the power of ruby (metaprogramming) to make Branch enumerable
# and use Forwardable to define which enumerable methods we want to use.
visor_class :Branch do
  include Enumerable
  extend Forwardable
  def_delegators(:@children, :<<, :each, :length)
  # variance angle for growth direction per time step
  THETA = Math::PI / 6
  # max segments per branch
  MAX_LEN = 100
  # max recursion limit
  MAX_GEN = 3
  # branch chance per time step
  BRANCH_CHANCE = 0.05
  # branch angle variance
  BRANCH_THETA = Math::PI / 3
  attr_reader :position, :dir, :path, :children, :xbound, :speed, :ybound, :app

  def initialize(pos, dir, speed)
    @position = pos
    @dir = dir
    @speed = speed
    @path = []
    @children = []
    @xbound = Boundary.new(0, 400)
    @ybound = Boundary.new(0, 400)
    path << pos
  end

  def run
    grow
    display
  end

  private

  # NB: use of both rotate! (changes original) rotate (returns a copy) of Vec2D
  def grow
    check_bounds(position + (dir * speed)) if path.length < MAX_LEN
    @position += (dir * speed)
    dir.rotate!(rand(-0.5..0.5) * THETA)
    path << position
    if (length < MAX_GEN) && (rand < BRANCH_CHANCE)
      branch_dir = dir.rotate(rand(-0.5..0.5) * BRANCH_THETA)
      self << Branch.new(position.copy, branch_dir, speed * 0.99)
    end
    each(&:grow)
  end

  def display
    @renderer ||= GfxRender.new(graphics)
    beginShape
    stroke(255)
    no_fill
    path.each { |vec| vec.to_vertex(@renderer) }
    endShape
    each(&:display)
  end

  def check_bounds(pos)
    dir.x *= -1 if xbound.exclude? pos.x
    dir.y *= -1 if ybound.exclude? pos.y
  end
end

# we are looking for excluded values
Boundary = Struct.new(:lower, :upper) do
  def exclude?(val)
    !(lower...upper).cover? val
  end
end

@root = Branch.new(
    Vec2D.new(0, height / 2),
    Vec2D.new(1, 0),
    10.0
)

def draw
  background(0)
  root.run
end

get vecmath here

[aprilcoffee]

@EmperorJack

Sorry for late replying, Here are the screenShots.

I'm now updated to macOS Mojave(10.14.4), and come across another problems. It pop out a JarMain error also.

Here's the screen shot when I haven't start running the sketch.

The errors on the console started showing during the process of "Starting up"

Later on after I click on the button "Sketch" this pops out.

And here are the overall error messages.

BTW, There's another small bug I would like to mention.
There's a well known bug in Chrome when hiding message via the right-click on console. If anyone wants to undo this action. There is no other way but to reset the entire debugger settings by clicking "Restore defaults and reload"

When I was trying the same thing in Visor to get a better screenshot. I've found myself in the same problem. I've got to Setting -> Preferences by clicking upper-right in the console menu, but the "Restore defaults and reload" button in the corner doesn't work. I went to reset my "Chrome", and everything is back to normal in Visor again.

[EmperorJack]

Hi @aprilcoffee, thank you for the detailed screenshots. Apologies for my late reply also. I've supplied technical details on my analysis below, but the tldr is that these issues will either be fixed in the next Visor version or there will be a way to work around them.

Firstly, I think you can ignore the TIS/TSM errors, I see them too. They should be removed once Visor's version of Processing is brought up to 3.5 (it's currently on 3.4). Read more about this here: https://github.com/processing/processing/issues/5462

Secondly, I think the errors and resulting crash are with respect to Mojave related bugs in the OpenJDK that Visor is shipped with. I will update this for the upcoming version of Visor. Though, it's possible that Processing is not fully compatible with the OpenJDK yet (https://github.com/processing/processing/pull/5753). For this reason, I'll aim to add an option in Visor to specify your own version of Java, which should avoid these kinds of issues.

With regards to the Chrome bug. I had a look for the "Restore defaults and reload" button and it also didn't work for me, at least initially. I found that if you now exit and re-open Visor, then the defaults have been reloaded. Does that work for you?

[jeremydouglass]

Processing is not fully compatible with the OpenJDK

It is not -- check out the build instructions:

https://github.com/processing/processing/wiki/Build-Instructions

• Install Java 8
  • On Windows and Linux, install the latest JRE 8 JRE 8u202 from Oracle.
  • On macOS, download and install JDK 8 JDK 8u202.
  • Other versions of Java are not supported. It must be 8u202. Later versions of Java (9, 10, 13, whatever) don't work either.
  • OpenJDK is also not supported. Really. Please don't use it (and then complain when things break).

[monkstone]

OpenJDK8 has always been fine on linux with JRubyArt, but for future builds of Visor it would be worth checking out @sampottinger version of processing. I expect you already know about @neilcsmith-net work. The current releases of propane and JRubyArt are built to work with OpenJDK12 without external dependency on vanilla processing apart from borrowing the jogl jars.

[neilcsmith-net]

@jeremydouglass Processing is fine with OpenJDK 8 on macOS from all testing I've done. The upstream insistence on making Processing not free is highly annoying and seriously outdated. PraxisLIVE currently ships with Azul's OpenJDK 8, but AdoptOpenJDK also a good option.

Unfortunately there are certain things that will consistently crash JOGL with OpenJDK 11 on macOS, hence me trying to revive the LWJGL backend currently.

[jeremydouglass]

That's all good to know--but Processing is cross-platform: mac, linux, windows--and so is Visor. I think the information I shared was relevant for EmporerJack. If OpenJDK works, great. If not, maybe try JDK 8u202, which PDE is developed and tested against -- and/or sam's OpenJDK 11 branch.

I honestly don't think the Processing Foundation wants to be on JDK instead of OpenJDK right now, it is just currently stuck there. No love lost there: https://github.com/processing/processing/blame/37108add372272d7b1fc23d2500dce911c4d1098/build/build.xml#L80

[neilcsmith-net]

@jeremydouglass you're talking like they're two separate projects, rather than Oracle JDK and the various OpenJDK releases being the same code base. And only the OpenJDK builds are actually still supported and maintained (unless paying). I wouldn't trust much of anything upstream Processing says about the situation! And Sam's OpenJDK 11 fork doesn't fix JOGL issues.

To bring back on-topic, Jack, what version and vendor of OpenJDK are you actually using here anyway?

[sampottinger]

Hey friends! Just checking... do y'all know if it's JOGL related? If so, it would be good to capture that over at https://github.com/sampottinger/processing/issues so that I can monitor the JOGL 2.4 trackers as they near a new release? 😅 🤞 Even if it isn't JOGL but there's something in processing, I'd be happy to investigate that from the perspective of https://github.com/sampottinger/processing. Just let me know if I can be of help!

[EmperorJack]

Hi all, thank you for comments!

@neilcsmith-net I'm currently shipping Visor with Azul's Zulu 8.36.0.*, which is OpenJDK 8u202. Is this the same or similar to what you are doing with PraxisLIVE? I noticed that Zulu goes up to 8u222 now. Regarding Processing, I'm currently using version 3.4 by shipping the core.jar that comes with Processing itself. Do you have any tips on this given your experience? Should I be using different versions, building Processing myself, or is there any other extra steps I might have missed?

Now I look at this in-depth, I think bumping Processing to 3.5 could help here. According to the Processing release notes, 3.5 was when 8u202 was brought in, while 3.4 was only up to 8u181.

This is my first attempt at shipping the JRE with Visor. I tried to stick as close to possible to what Processing used (8u202 - as Jeremy highlighted) as I'm not sure how involved or what the benefits would be for moving to 11 or 12. I suppose this probably doesn't help you then @sampottinger?

[neilcsmith-net]

@EmperorJack I'm also using Zulu for macOS, but actually still 8u172 at the moment. Might be worth you trying 8u222, but unlikely it's the issue. Some details of future OpenJDK 8 releases at https://wiki.openjdk.java.net/display/jdk8u/Main - might be worth checking release notes.

Processing is stuck with 8u202 while they remain against OpenJDK anyway as they can't legally distribute an Oracle JDK any higher. :roll_eyes:

I wouldn't look at OpenJDK 11+ yet - it's possible to hack processing core.jar to work with 11 on macOS, but JOGL is problematic. I would definitely look at Processing 3.5.3 though - am currently using that. IIRC there are differences in the patched JOGL that is shipped with 3.5.x.

(OT - on my Linux machine I'm currently AdoptOpenJDK's OpenJDK 11 with OpenJ9 (rather than HotSpot) for PraxisLIVE and NetBeans - working really well)

[EmperorJack]

Thank you for the advice @neilcsmith-net, I'm going to go ahead and bump the Processing and OpenJDK versions bundled with Visor to see if that helps. Also thanks for the heads up on Adopt, I'll take a look at that and see how it compares again Zulu!

[EmperorJack]

Heya @aprilcoffee, I've just released Visor version 0.5.0 which contains a bunch of changes that may hopefully get Visor going for you. I've tested it on macOS Mojave(10.14.6) and it seems to work well. If you try it and it doesn't work immediately, I have a couple of suggestions that might help (mainly to do with configuring Java, which you can now do from the File -> Settings -> Java menu). Let me know how you go!

[EmperorJack]

Have just released version 0.11.0, which updates to Processing 4.3 and Java 17, and may fix this issue. Going to close for now, but can reopen if still present.