Running run_sketch.py on Windows

[tabreturn]

I get an error running run_sketch.py on Windows. I enter something like:

py C:\Users\user\Desktop\thonny\env\Lib\site-packages\py5_tools\tools\run_sketch.py C:\Users\user\Desktop\a.py

and I get --

Traceback (most recent call last):
  File "C:\Users\user\Desktop\thonny\env\Lib\site-packages\py5_tools\tools\run_sketch.py", line 41, in <module>
    main()
  File "C:\Users\user\Desktop\thonny\env\Lib\site-packages\py5_tools\tools\run_sketch.py", line 37, in main
    imported.run_code(args.sketch_path, classpath=args.classpath)
  File "C:\Users\user\Desktop\thonny\env\lib\site-packages\py5_tools\imported.py", line 116, in run_code
    _run_static_code(
  File "C:\Users\user\Desktop\thonny\env\lib\site-packages\py5_tools\imported.py", line 140, in _run_static_code
    _run_code(new_sketch_path, classpath, new_process, exit_if_error)
  File "C:\Users\user\Desktop\thonny\env\lib\site-packages\py5_tools\imported.py", line 191, in _run_code
    _run_sketch(sketch_path, classpath, exit_if_error)
  File "C:\Users\user\Desktop\thonny\env\lib\site-packages\py5_tools\imported.py", line 162, in _run_sketch
    sketch_ast = ast.parse(sketch_code, filename=sketch_path, mode='exec')
  File "C:\Users\user\AppData\Local\Programs\Python\Python39\lib\ast.py", line 50, in parse
    return compile(source, filename, mode, flags,
  File "C:\Users\user\AppData\Local\Temp\tmpx8li2fl7\_PY5_STATIC_FRAMEWORK_CODE_.py", line 12
    exec(
         ^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 2-3: truncated \UXXXXXXXX escape

Something to do with Windows paths, maybe? Or I'm doing something silly? Any ideas?

[hx2A]

@tabreturn no, I think this is a bug, assuming you are using the latest version. See #37

Thanks for spotting this issue

[hx2A]

#37 is fixed now

[hx2A]

@tabreturn while doing some testing on my Mac computer I tried using run_sketch and realized that it doesn't and can't work on Macs because py5 can only work on Macs through the Jupyter client with the %gui osx magic. It's not possible for me to fix this by inserting %gui osx somewhere in run_sketch because that magic works by making adjustments to the IPython kernel and the sketch animation thread. If there's no kernel, there's no kernel for the magic to operate on. I should have realized this before today. I mean, I do explicitly say this in the Special Notes for Mac Users, but I didn't realize how that would impact you and what you have done with Thonny. I do regret this.

Currently when I try to use this on my Mac, the terminal just hangs. Should I change it so it throws an exception instead? If it doesn't work, I should at least clearly state that to the user instead of hanging.

Theoretically a fix is possible. There are a few avenues.

• The best choice is to wait for jpype to fix the GUI issues on Mac computers. The problem might be on the py5/Processing side though.
• I can figure out what %gui osx does and somehow replicate it outside of the kernel. Previous attempts at this have failed though.
• There's an ugly solution where on Macs I can write code to a temporary notebook file and then launch a process that executes something like:

jupyter nbconvert --execute --to notebook --inplace "code.ipynb"

That would require Jupyter to be installed along with the py5 kernel. It is achievable though. But not by Sunday. :-( Even if I had 100% of my time available, I still couldn't do that. But I will look into it to see what can be done.

There might be other avenues to pursue. Java on Macs are a huge thorn in my side, but I will stick with it.

[tabreturn]

Fantastic work, @hx2A. I've tested on Linux (Mint 20.2) and Windows 10 without issue.

[hx2A]

@tabreturn The new release is live. The run_sketch utility should work correctly on all platforms.

While testing I noticed that py5bot has some odd issues on Windows when using an OpenGL renderer. The window doesn't seem to close when it is supposed to and there are odd exceptions in the Jupyter logs. I'm not sure if it is my computer or a real issue. Can you give it a try and open an issue if you experience it also?

[tabreturn]

Using Thonny+py5, static-mode P2D/P3D sketches work fine using the run_sketch.py on Linux. But on Windows, one has to use a draw() function (otherwise, shapes/forms disappear instantly, seemingly drawn over by the background fill).

Regarding Jupyter: I wasn't aware that it would open a window for OpenGL sketches. I tried a sketch with a size(200, 200, P3D) using the py5bot kernel, which renders fine (as an embedded notebook graphic). If you'd like me to try something else, let me know what steps I should carry out.

[hx2A]

But on Windows, one has to use a draw() function (otherwise, shapes/forms disappear instantly, seemingly drawn over by the background fill).

Hmmm, this appears to be a bug. On Windows, when using the P2D renderer, some draw commands don't work when they are in setup. So for example:

def setup():
    size(200, 200, P2D)
    background(0)
    fill(255)
    rect(10, 20, 130, 140) # this rectangle appears and gets overwritten

def draw():
    rect(mouse_x, mouse_y, 10, 10)

This doesn't happen on Linux or OSX or when using the default renderer on Windows. This is not limited to run_sketch either; it happens in the regular notebook kernel also.

This seemed too strange and I don't have any immediate ideas why this bug would happen like this only on Windows. I tested the analogous code on the latest Processing 4 release and it works correctly, so the problem is in py5 somewhere.

Can you experiment with this a bit more and open an issue? I will need to think about this some more to come up with ideas for how to investigate this.

While testing run_sketch I had been testing Sketches in functionless "static mode" or Sketches with both a setup and draw function. I tested with only a setup function and I see that run_sketch has an issue on OSX. When using the default renderer, if the setup function is defined and there is no draw function, the sketch window will appear but then close on its own after a few seconds. A few days ago I did discover this would happen for static mode sketches that used the default renderer, and I fixed it, but only for static mode sketches, not sketches with only a setup function. Fixing this would require me to fiddle with my newly written pyobjc code, which I will need to take my time with. It doesn't seem that critical though, so let's leave it be for now and I'll fix it in a future release.

[hx2A]

@tabreturn I now know the cause of this Windows issue (see #5) and I know how to fix it, but not in a way that does not break something else. But fixing this is achievable, and I'll work on it for the next release.

[villares]

Cool! No hurry!

Someone else had issues with the noise library and created vnoise
Might be worth a look! It could be too slow for our use case... it gets fast only when used in a "vectorized" numpyish call :(

[hx2A]

This is a great suggestion. Thank you for the research!

The current py5 noise functionality supports vectorized noise generation through use of np.vectorize. And generally I think vectorized operations are the way to go for py5, and Python in general. This replacement being slower only matters if someone uses it in a loop. If someone needs many noise values and cares about performance, they can use the vectorized approach instead.

From looking at that the vnoise author's twitter feed it seems they like using Python and Processing, so perhaps they would also be interested in using py5, and would be happy that we are using their library.

[villares]

WHOA! That's a great twitter catch you made, huh? Followed them!

[hx2A]

WHOA! That's a great twitter catch you made, huh? Followed them!

I'm slowly catching on to the twitter world...after this next release, I'll start using the py5coding account.