Forum Replies Created
-
Posts
-
Hey Richard,
I too feel personally assaulted after reading some of that stuff from the less than stellar.
I thought your posts were spot on, well done on the restraint I can only imagine was required to maintain your tact.
Oops. It should be viewable now.
If you abandon mojo and it’s GL2 requirement and build pure SDL2 apps you could in theory use monkey2 to build DirectX7 apps, but yeh, nah…
I was hoping monkey2 would follow Java and adopt final variables (const). Maybe not immediately but perhaps somewhere in the future before threading which I realise is not a given.
Sorry about the delay, it should be there now.
The only reason the permissions are not set correctly is Mark’s work flow.
I don’t mind fixing them personally but I think it is a pretty poor impression for git skilled new comers evaluating monkey2 on MacOS / Linux platforms.
+1 for fixing the permissions for MacOS / Linux users
Crikey! As a “fix” did you try using a c++ nullptr instead of the bb_array_null to replace the integral zeros in that code or did that fail also?
A few thoughts (sorry not set up to actually help atm).
- I’m not sure sanitize will work on a vm, the way I understand it, it severely abuses the PMMU to do it’s thing
- I’m not sure a monkey2 app can be trusted to close down corrctly on linux without cleaning up the audio context and closing the device correctly
- the killed scenario and valgrind issues sounds to me like there is something amiss… (will look into it on my work machine on monday)
- both valgrind and asan may not be compatible / usable with monkey2 fibers
If valgrind doesn’t reveal the issue Address Sanitizer might.
We have been using it at work and typically involves using recent gcc (or clang) and -fsanitize=address flag for both compile and link.
It will slow down your program 2x (not as bad as valgrind) but manages to trap most bad memory operations.
The zenity issue has been a deal breaker for others causing complete crash.
Your crash probably needs a release with debug symbols style build so gdb can be used to backtrace the cause.
It looks like there are two issues there for maybe Mark to take a look at.
- audio.monkey2 calls alcOpenDevice but there is no matching CloseDevice to be found
2. the zenity system monkey2 uses for requesters may have issues, the thread here suggests an environment variable can fix it
I think monkey2 on Linux uses OpenAL configured as it finds it so you probably want to start with some plain openal tests.
According to this page OpenAL Soft should use PulseAudio by default, but can be explicitly configured to do so:
1/etc/openal/alsoft.conf1drivers=pulse,alsaSorry I missed your post.
This is the code I knocked together for the machine translation pass:
https://github.com/nitrologic/m2/blob/master/autoimport/listimports.monkey2