Issues on Sway (Wayland) about reprocessing-example HOT 7 OPEN

Hey @smolck ! Thanks reporting. It's difficult for us to debug on linux, because we never have the exact same setup. Could you read through #13 and Schmavery/reprocessing#74 and see if there's anything that would help there?
We've never seen this error, but to the sound of it it might be related to some native package that isn't built correctly for your machine (so maybe SDL needs to be built with some specific flags, as @zploskey had found out in his issue).

from reprocessing-example.

If you do find some arch packages that work, we can add them to the reprocessing readme with the other known packages :)
https://github.com/Schmavery/reprocessing#getting-started

(we should add those fedora ones too)

from reprocessing-example.

@bsansouci Thanks for the quick response!

Could you read through #13 and Schmavery/reprocessing#74 and see if there's anything that would help there?

Schmavery/reprocessing#74 Looks almost exactly like my problem. Using SDL_VIDEODRIVER=wayland didn't do anything. I installed some packages which were mentioned there (they didn't fix it), but that is somewhat difficult to do since I am running Arch. Do you know the Arch equivalent for any of these packages mentioned in that issue (if not I can look around the Arch Wiki and such)?:

Ubuntu: libwayland-dev libxkbcommon-dev wayland-protocols

Fedora: builddep SDL2-devel

Not sure if those would make any difference, but trying the Arch equiv is probably worth a shot. I know that Arch doesn't use dev packages (at least for the most part), so I was able to guess the Arch packages for some of the ones mentioned there (e.g. fcitx and ibus which I can't install due to conflicts).

It's difficult for us to debug on linux, because we never have the exact same setup.

Yeah, I know what that's like. If you need any versions, debug logs, etc. let me know!

from reprocessing-example.

If you do find some arch packages that work, we can add them to the reprocessing readme with the other known packages :)
https://github.com/Schmavery/reprocessing#getting-started

Sounds good! Also, just an FYI, there appears to be a rogue parenthesis at the end of the first line of the Getting Started heading you linked ;)

Note: on linux, you may need to also install some libraries):
apt install libsdl2-dev fcitx-libs-dev libibus-1.0-dev

from reprocessing-example.

So, I installed the fcitx and ibus Arch packages (already had sdl2), and, while it will compile (as with the following output), it doesn't run:

Reloading hotloaded module
Successfully changed functions
>>>> Start compiling
ninja: no work to do.
>>>> Finish compiling
fish: “npm run start” terminated by signal SIGSEGV (Address boundary error)

Interestingly, when I try and type something into the terminal afterwards, this appears:

Uncaught Exception { Error: read EIO
    at TTY.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'EIO', code: 'EIO', syscall: 'read' }

Not sure if that helps at all?

from reprocessing-example.

Not sure, that seems weird. I'm assuming you cleaned everything and rebuild the project after installing those other libs.
Maybe you could try directly running the program with ./lib/bs/bytecode/indexhot.byte, since it seems like that error message is coming from node.

You could also try to build the native (non-hotreloading) target with npm run build:native to see if that works any better?

from reprocessing-example.

Not sure, that seems weird. I'm assuming you cleaned everything and rebuild the project after installing those other libs.

Just tried this by removing the node_modules folder, running npm clean-install, and still it compiles but doesn’t run.

Maybe you could try directly running the program with ./lib/bs/bytecode/indexhot.byte, since it seems like that error message is coming from node.

Same error message when run like this.

You could also try to build the native (non-hotreloading) target with npm run build:native to see if that works any better?

Same as above when running it with ./lib/bs/native/index.native after npm run build:native.

Note that after compiling the executable on Sway, they run just fine on Awesome; thus, Wayland compiles the executables as it should. Only when trying to execute the program does it crash on Wayland (but, again, not on Xorg).

from reprocessing-example.