This topic contains 37 replies, has 4 voices, and was last updated by 
dawlane 2 years, 6 months ago.
-
Posts
-
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?
did you try using a c++ nullptr instead of the bb_array_null
No, but I doubt it would work as it’s still just a const 0.
The problem was my nasty habit of using -> with null ptrs. This officially became ‘undefined behaviour’ a few years back, so compilers are now starting to optimize out stuff like ‘this==0’, ‘!this’, ‘this==nullptr’ etc, because ‘this’ can/will never be null in a ‘well formed’ program.
So the ‘length()’ method, which used to be ‘return this ? this->length : 0’ was being optimized down to plain old ‘return this->length’.
The bb_array_null global fools/forces the compiler into always doing the ‘this’ comparison, since the compiler can’t know that nothing else changes bb_array_null (even though nothing does). But of course this involves an extra pointless read of the global.
I could make Length a static/extension method, but the real fix IMO is to turn arrays into ‘handles’ that contain the pointer to the array (which they have been on and off during mx2 dev) and I’m in the process of doing that now. It will break any native code that use bbArray (easily fixed though) but it needs to be done so the sooner the better.
Besides, it’ll make arrays much nicer to use with native code, eg: instead of “bbArray<bbInt> *p=bbArray<bbInt>::create( 100 )” it’ll just be “bbArray<bbInt> p( 100 )”. Also, you’ll be able to index via plain operator[] in native code instead of current ugly (*p)[] or p->at().
I managed to reproduce this by installing/building with gcc-6.
There’s a quick ‘n’ dirty fix up now at github, let me know if it works!
Yes, GCC version 6.2.1 here. Probably should have mentioned that earlier!
The fix works perfectly. Many many thanks.
I’m off now to see how Android support is coming on…
On a side note, another of Linux’s quirks annoys me every time I do a fresh Monkey install. All the *.sh files in /scripts, and the binary /bin/mx2cc all require the exec flag setting before I can run them(chmod a+x …).
If you download it as zip archive; then execute permissions are not saved. The same should be for cloning off of git.
Why would you make life difficult with the zip archive when git clone is so easy? Git *does* honour exec permissions, doesn’t it? At least it moans at me that the permissions have changed whenever I do a git pull.
@Mark would you like me to submit a pull request for this, assuming it is possible?
+1 for fixing the permissions for MacOS / Linux users
@arpie: Not everyone will want to use git. But I do believe that a git repository can store the file permissions. I think that you use git config core.filemode true or was it git bundle with a meta file? It been a while since I used git.
In any case I would just write a script to automate the task of cloning and setting permissions. If I want to be really lazy. I would just use the command line and use recursive option parameter with chmod, chgrp and chown.
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.
Well after a lot of swearing with installing the wrong nvidia drivers and fighting with the xorg config file. I’ve finally got ArchLinux installed on the old Sony AR laptop with all the hardware . So far 1.0.8 is working.
You must be logged in to reply to this topic.