Reassuring to know that Xojo will continue to only support 32-bit arrays.
-
2 months ago
-
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. -
@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.
-
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.
-
@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?
-
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.
-
@Greg OLone Could you point me to where you found that?
https://docs.xojo.com/UserGuide:64-Bit_Guidelines
Other 64-bit Information -
@Alberto D;Poo https://docs.xojo.com/UserGuide:64-Bit_Guidelines
Other 64-bit InformationThank you. I've created a case for adding that note to the relevant Language Reference pages.
Feedback Case #55969 -
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 -
5 days ago
@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
DoneBut 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?
