Monkey + iOS 7 + New Apple Feb 2014 Requirements
Monkey Forums/Monkey Programming/Monkey + iOS 7 + New Apple Feb 2014 Requirements
| ||
| I thought I would post this in here to highlight it: http://www.monkeycoder.co.nz/Community/posts.php?topic=7738 |
| ||
| https://developer.apple.com/news/index.php?id=12172013a I don't know if it's just forcing XCode 5 compliance or forcing 64-bit as well. Nonetheless, looks like 64-bit is coming and Monkey should get on board. |
| ||
| Fixing ios 7 deployment is easy enough - it's just missing an #include <pthread.h>. Fixed for next release. Not sure what 'optimising for ios 7.0' is all about though. > Nonetheless, looks like 64-bit is coming and Monkey should get on board. Not sure what you mean. Glfw already creates universal binaries, but I've no objections to making the default project 64 bit only. Mac's have been 64bit for ages now. ios is a bit different, as I imagine there will still be quite a few 32 bit devices running ios 7 for a while yet. Either way, it's pretty easy to change 32/64bit in xcode. |
| ||
| Not sure what you mean. linux and windows is what i implied by that comment, but i should also point out that the cpp tool on osx forces -arch i386. |
| ||
| I'm OK with going 64 bit for Linux as it's pretty much the standard and has been for a while, but Windows *still* comes in separate 32/64 bit editions doesn't it? In particular, I think a lot of the new Windows 8 (not RT) tablet things are 32 bit - mine is. So 64 bit apps wont run on those...or any of the many 32 bit editions of Windows already out there. I also suspect there wont be much, if any, practical benefit in going 64 bit - all pointers suddenly become twice as big, so GC (which is largely just chasing pointers around) and general pointer handling become slower. On the other hand, 64 bit has more cpu registers available for use so it might even out. Most of the answers to this sound about right to me: http://stackoverflow.com/questions/2378399/are-64-bit-programs-bigger-and-faster-than-32-bit-versions I guess the best thing to do would be to add an app config setting if possible for Windows, or perhaps a new target if there are compilation problems with msvc. Will have a look into this. |
| ||
| I also suspect there wont be much, if any, practical benefit in going 64 bit Apple decided that 64-bit is now a marketing sell, so i suspect many people wanting that "me too" feature, whether it's practical for them or not. |
| ||
| @marksibly: There are some interesting articles at http://www.viva64.com/ in regards to 64bit application development etc. On Linux going 64bit maybe OK for the main distributions, but there are still some people out there that are still behind the times. So 32bit support shouldn't be removed completely. It would be worth your while to look into migrating any Monkey tools being built with BlitzMax sources into Qt source code so a user wouldn't have to rely on any 32bit libraries etc in the future for those tools, unless you make every user of BlitzMax happy and update it to be 64bit compliant. Monkey code seems to run OK as a 64bit application, but the displaying of floating point numbers show discrepancies on Linux ( and Windows the last time I checked ) e.g 1.2 displays as 1.2000000476837158. It also shows this discrepancy in Linux when built as a 32bit program on a 64bit system. |
   |