[crossfire] some bugs

[Andreas Kirschbaum]

Todd Mitchell wrote:
>
     
      5. Python Bank system not working-  trying to deposit money results in:
     
     >
     
     
     >
     
      Traceback (most recent call last):
     
     >
     
        File "/usr/local/CFS/share/crossfire/maps/python/IPO/banksay.py", line 64, in ?
     
     >
     
          if (CFPython.PayAmount(activator, (int(text[1])*exchange_rate)*fees)):
     
     >
     
      SystemError: ../Objects/longobject.c:391: bad argument to internal function
     
     >
     
     
     >
     
      -is this because im still using python 2.1 for CF server or do the
     
     >
     
      bank scripts need to be modified?
     
     
It is because I changed the Python plugin to use an uint64 for all
variables holding money. This data type is not supported by Python below
version 2.2.


>
     
      Should there be a warning of something during the ./configure if
     
     >
     
      python < 2.2 is used?
     
     
IMHO, it should not even compile the plugin in that case. (Not too good
to have a plugin that fails for some (random) functions/scripts.)

I did not find an acceptable solution yet. My possible alternatives
would be:

 1. Just check the Python version and reject versions below 2.2.

    This alternative would be very easy to implement, but I'm not sure
    if that would be the right way to go: the Python documentation
    (version 2.3) says:

    | "L" (integer) [PY_LONG_LONG]
    |
    |     Convert a Python integer to a C long long. This format is only
    |     available on platforms that support long long (or _int64 on
    |     Windows).

    Therefore it may be possible that this format specifier is not
    available even if the Python version is >=2.2.


 2. Add a (compile-time) check to the configure script: run a small
    test-program to check if the "L" format specifier is supported.

    I did implement this alternative, but then realized that it would
    prevent cross-compiling: you just can't check the Python version of
    the target system while compiling on the host system.


 3. Add a (runtime) check to the server: try to use the "L" format
    specifier when the plugin loads and fail if it is not supported.

    Problems here is that it would add some complexity to the plugin
    just to fail in some cases and that it fails not until runtime.


My preferred solution would be both alternatives 1 and 3: compile-time
check for Python >=2.2 and runtime check for working "L" format
specifier.


>
     
      The slots don't work either - perhaps same reason.
     
     
I think so: they are using money, too?