macOS Catalina: 32-bit is Dead!

  1. 6 months ago

    Adrian P

    7 Jun 2019 Montreal, Quebec

    Reassuring to know that Xojo will continue to only support 32-bit arrays.

  2. Christian S

    7 Jun 2019 Pre-Release Testers, Xojo Pro, XDC Speakers, Third Party Store Germany

    32bit arrays?

    the question is how long we keep a checkbox for building 32-bit apps.
    Not sure how many people still have not ported to 64-bit, e.g. due to use of old APIs or old libraries.

  3. Gavin S

    7 Jun 2019 Pre-Release Testers, Xojo Pro UK

    @ChristianSchmitz 32bit arrays?

    the question is how long we keep a checkbox for building 32-bit apps.
    Not sure how many people still have not ported to 64-bit, e.g. due to use of old APIs or old libraries.

    They can keep building with older releases.

  4. Alberto D

    7 Jun 2019 Pre-Release Testers, Xojo Pro

    I think Adrian read the blog post https://blog.xojo.com/2019/06/07/macos-catalina-32-bit-is-dead/
    From it:

    Xojo will only support building 64-bit Mac apps in a future release

    I hope that includes building from Windows/Linux, but I know that LLVM is not 100% ready.

  5. Adrian P

    7 Jun 2019 Montreal, Quebec

    Hi Christian,

    Sorry, the sarcasm at my end may have been misplaced. Are you saying that newer versions of RB/Xojo do now allow for 64-bit sized arrays? I was still basing this on the online notes:

    >Arrays are limited to 32-bit size in 64-bit apps.

  6. Greg O

    7 Jun 2019 Xojo Inc scout.galaxy.barn

    @Adrian P Hi Christian,

    Sorry, the sarcasm at my end may have been misplaced. Are you saying that newer versions of RB/Xojo do now allow for 64-bit sized arrays? I was still basing this on the online notes:

    >Arrays are limited to 32-bit size in 64-bit apps.

    Could you point me to where you found that?

  7. Christian S

    7 Jun 2019 Pre-Release Testers, Xojo Pro, XDC Speakers, Third Party Store Germany

    It may be that arrays are limited to 32-bit for the index, so only 2 or 4 billion entries. That should not be a problem for you.

    The data type is not limited.

  8. Alberto D

    7 Jun 2019 Pre-Release Testers, Xojo Pro
    Edited 6 months ago

    @Greg OLone Could you point me to where you found that?

    https://docs.xojo.com/UserGuide:64-Bit_Guidelines
    Other 64-bit Information

  9. Greg O

    7 Jun 2019 Xojo Inc scout.galaxy.barn

    @Alberto D;Poo https://docs.xojo.com/UserGuide:64-Bit_Guidelines
    Other 64-bit Information

    Thank you. I've created a case for adding that note to the relevant Language Reference pages.
    Feedback Case #55969

  10. Greg O

    7 Jun 2019 Xojo Inc scout.galaxy.barn

    It's worth noting that Arrays are not actually limited to 32-bit in size, it is the array indexes that are limited to 32-bit. I would argue that if you have a need to for an array that has two billion items in it, you should probably be using a MemoryBlock anyway.

  11. Norman P

    7 Jun 2019 Pre-Release Testers, Xojo Pro under a bus
    Edited 6 months ago

    there's a funky edge case right around the max of a signed int32

    Const i As Integer = &h7FFFFFFF
    Dim i1 As Integer = i
    Dim d(i) As UInt8
    d(i) = 1
    
    Break

    wont work
    but changing the const to &h7FFFFFFE (1 less) does

    Feedback Case #55970

  12. 4 months ago

    Adrian P

    Aug 15 Montreal, Quebec

    @ChristianSchmitz It may be that arrays are limited to 32-bit for the index, so only 2 or 4 billion entries. That should not be a problem for you.

    The data type is not limited.

    I think I'm running into this same issue again, and it appears to me that its not the index that's 32-bit limited. I'm compiling on MacOS for linux 64-bit using 2019 release 1.1 with the executable running on an Ubuntu machine with 32GB of RAM. If I do a RAM check and then run the simple loop below with a byte datatype which uses in theory 585MB of memory for the array, all works fine:

    dim gnm(12,45000000) as byte
    dim x,y as integer
    
    for x=0 to 12 
      print str(x)
      for y=0 to 45000000
        gnm(x,y)=1
      next
    next
    
    print "Done"

    ~$ free -g
    total used free shared buff/cache available
    Mem: 31 0 29 0 1 30
    Swap: 0 0 0

    ~$ ./test1
    0
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    Done

    But if I change the datatype to double pushing the amount of memory needed to 4.7GB then I get a very different result:

    dim gnm(12,45000000) as double
    dim x,y as integer
    
    for x=0 to 12 
      print str(x)
      for y=0 to 45000000
        gnm(x,y)=1000
      next
    next
    
    print "Done"

    ~$ free -g
    total used free shared buff/cache available
    Mem: 31 0 29 0 1 30
    Swap: 0 0 0

    ~$ ./test1
    0
    Segmentation fault (core dumped)

    It looks like the inner look gets just past 3.7million when it seg faults. I've repeated this on a CentOS machine with 300GB of RAM and had the same result. Any clues to what may be going wrong?

or Sign Up to reply!