fp Plugin 64-bit probem

I’m upgrading my fp Plugin to be 64-bit compatible. In the 32-bit version I wanted this to work in Xojo source code:

Dim x As BigInteger
x = 1234

so I used “Operator_Convert(x As Double)” which worked well. The Xojo side converted 1234 to a Double, and my plugin converted the Double to a BigInteger. And if x = 43.21, that Double would truncate to 43 as a BigInteger. So no problem arose in 32 bits.

But in 64 bits a Double cannot contain some large values of a 64-bit signed integer. For example with a 64-bit build, noting that 2^63 - 1 = 9223372036854775807 is the largest value for a signed 64-bit integer and using a smaller value:

Dim x As Double
x = 9223372036854712345
TextField1.text = Format(x, “####################”)
// output = 9223372036854712320

So the Double value is wrong in the last two digits, and my Operator_Convert method can fail for some values of a 64-bit Integer.

To try to correct that I added "Operator_Convert(x As Integer)”. But now for even x = 5 I get the error:

There is more than one item with this name and it’s not clear to which this refers
x = 5

So either I keep only ”Operator_Convert(x As Double)" for which some 64-bit integers give incorrect BigIntegers or I keep only ”Operator_Convert(x As Integer)” for which some Doubles give an incorrect result. Or I can tell my users that if in doubt use the more awkward:

x = new BigInteger(“9223372036854712345”)

I think it’s a bug that Xojo can’t tell the difference between an Integer entry or a Double entry in source code and use the proper Operator_Convert.


It could make either one “work” and it has no way to divine which one you intended with the limited information at hand

C has the hinting (L, l etc) that you can add to a literal to resolve this kind of ambiguity

You may need to have something like 20 Operator_Convert, one for each possible data type for numbers, so it’s not ambiguous.

I’d love to have a compiler attribute to give the Operator_Convert for int64 a higher priority in this matching than the one for double.
But that may need some changes on the compiler.

I’d need to see an example project before claiming it’s a bug or not.

See <https://xojo.com/issue/41697>

Thank you Jason.


Hello guys,

It seems that there is a problem with the fp plugin or maybe i`m using the things wrong here :

i do a codesign -f -s "Developer ID Application: ID" App_x64.app

And as a response i get :

App_x64.app: code object is not signed at all
In subcomponent: /path to app/App_x64.app/Contents/Frameworks/fp Plugin64.dylib

I`m doing anything wrong or the plugin itself has to be signed by the developer in a way ?

i downloaded the plugin from here http://delaneyrm.com/fpPlugin.html


First sign everything inside the app.
Than the app itself.

… and don’t hijack threads. Your question should be in its own thread.

Im sorry i was no hijacking any threads im just trying to find all the issues related to that 64 bit problem in the same place as it is quite messy sometimes.

Thanks Christian for the reply i`ll try it and see how it goes.