civil-devel Mailing List for Civil

On Tue, 27 Jan 2004, Jean von Oertzen wrote:

> > That should do the trick. Newest stuff from CVS has fixed that part,
> > although the code is otherwise in a huge flux right now and b0rken be=
yond
> > belief. :)
> I changed it but unfortunally I didn't the trick
> <snip>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D Installation results
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
> make -C src all
> make[1]: Entering directory `/home/simb/tmp/civil/src'
> cd map/los && \
> python2.3 setup.py build && \
> cp build/*/ccivil.so .
> running build
> running build_ext
> cp: Neu erstelltes =BB./ccivil.so=AB wird nicht mit
> =BBbuild/lib.linux-i686-2.3/ccivil.so=AB =FCberschrieben.
> make[1]: *** [all] Fehler 1
> make[1]: Leaving directory `/home/simb/tmp/civil/src'
> make: *** [all] Fehler 2
>=20
> ****  Installation failed. Aborting package creation.
> <snap>
>=20
> Should I give up and wait for the next release (as I'm not very common
> with CVS)?
> Or are there any other clues?

Hello again Jean,

it *looks* like it couldn't overwrite the ccivil.so file with a new=20
version. (My German is a bit rusty, you could try saying
"LC_ALL=3DC ./configure ..." to get English). And this would be the case=20
if you e.g. first tried configuring as root, and then later as an=20
ordinary user.

So check the file owners, and try changing with
"chown -R yourname:yourgroup ." in civil's top-level directory.

Marcus

Linux is great, but software installation need some improvement.
My next one will be Debian. There it seems to be much easier...

Am Di, 2004-01-27 um 08.51 schrieb Jan Ekholm:
> Hm, did my mail I sent yesterday actually get anywhere? I don't seem to
> have got it myself at all. Maybe SF is just randomly dropping messages?
>=20
I got it. ?:/

> No problem, it's not that much anyway and bits are cheap nowadays.
>=20
So, once again in this mail.

> Well, obviously it would not work. It tries to include
> "python2.2/Python.h", and that one most likely is not available. I think
> that 0.82 had a hardcoded python2.2 part in the include.
>=20
> Please have a look in the file src/map/los/ccivil.c and see what header
> file it tries to include. If there is something like:
>=20
> #include <python2.2/Python.h>
>=20
> change it to one of:
>=20
> #include <python2.3/Python.h>
> #include <Python.h>
You where right. It was hardcoded, like you described.

> That should do the trick. Newest stuff from CVS has fixed that part,
> although the code is otherwise in a huge flux right now and b0rken beyond
> belief. :)
I changed it but unfortunally I didn't the trick
<snip>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 Installation results
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
make -C src all
make[1]: Entering directory `/home/simb/tmp/civil/src'
cd map/los && \
python2.3 setup.py build && \
cp build/*/ccivil.so .
running build
running build_ext
cp: Neu erstelltes =BB./ccivil.so=AB wird nicht mit
=BBbuild/lib.linux-i686-2.3/ccivil.so=AB =FCberschrieben.
make[1]: *** [all] Fehler 1
make[1]: Leaving directory `/home/simb/tmp/civil/src'
make: *** [all] Fehler 2

****  Installation failed. Aborting package creation.
<snap>

Should I give up and wait for the next release (as I'm not very common
with CVS)?
Or are there any other clues?

greets
Jean

Hm, did my mail I sent yesterday actually get anywhere? I don't seem to
have got it myself at all. Maybe SF is just randomly dropping messages?


On Mon, 26 Jan 2004, Jean von Oertzen wrote:

>First of all, thank you for your warm welcome!
>
>Am Mo, 2004-01-26 um 13.09 schrieb Marcus Alanen:

>As I dont know exactly what to post, I post all (sorry for everybody
>else anoying with this):

No problem, it's not that much anyway and bits are cheap nowadays.

><snip>
>bruchtal:/home/simb/tmp/civil # ./configure --with-python=python2.3
>--with-python-includes=/usr/lib/python2.3
>checking for a BSD-compatible install... /usr/bin/install -c
>checking Python version... python2.3
>configure: creating ./config.status
>config.status: creating civil
>config.status: creating civil-ai
>config.status: creating civil-lounge
>config.status: creating civil-editor
>config.status: creating Makefile
>config.status: creating src/Makefile
>config.status: creating src/version.py
>config.status: creating src/paths.py
>config.status: creating gfx/Makefile
>config.status: creating doc/Makefile
>config.status: creating fonts/Makefile
>config.status: creating sound/Makefile
>config.status: creating scenarios/Makefile
>bruchtal:/home/simb/tmp/civil # checkinstall --type=rpm --install=no
>--pkgname=civil --pkgversion=0.82-2 --pkgarch=i586
>--pkgsource=civil_0.82-2.tar.gz
>
>checkinstall 1.6.0beta2, Copyright 2002 Felipe Eduardo Sanchez Diaz
>Duran
>           This software is released under the GNU GPL.
>
>
>The package documentation directory ./doc-pak does not exist.
>Should I create a default set of package docs? [y]: n
>
>Installing with "make install"...
>
>========================= Installation results
>===========================
>make -C src all
>make[1]: Entering directory `/home/simb/tmp/civil/src'
>cd map/los && \
>python2.3 setup.py build && \
>cp build/*/ccivil.so .
>running build
>running build_ext
>building 'ccivil' extension
>gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64
>-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0
>-fPIC -Wall -fPIC -I/usr/include/python2.3 -c ccivil.c -o
>build/temp.linux-i686-2.3/ccivil.o
>ccivil.c:1:30: python2.2/Python.h: Datei oder Verzeichnis nicht gefunden
>ccivil.c:6: error: parse error before '*' token
>ccivil.c: In function `rdlosmap':
>ccivil.c:8: error: `PyObject' undeclared (first use in this function)

Well, obviously it would not work. It tries to include
"python2.2/Python.h", and that one most likely is not available. I think
that 0.82 had a hardcoded python2.2 part in the include.

Please have a look in the file src/map/los/ccivil.c and see what header
file it tries to include. If there is something like:

#include <python2.2/Python.h>

change it to one of:

#include <python2.3/Python.h>
#include <Python.h>

That should do the trick. Newest stuff from CVS has fixed that part,
although the code is otherwise in a huge flux right now and b0rken beyond
belief. :)



-- 

                  - "What're quantum mechanics?"
        - "I don't know. People who repair quantums, I suppose."
                                               -- Terry Pratchett, in Eric

First of all, thank you for your warm welcome!

Am Mo, 2004-01-26 um 13.09 schrieb Marcus Alanen:
> Hello Jean,
> 
> sometimes it's quite frustrating to make projects compile. There are 
> lot's of things that need to be taken into consideration. 
> Unfortunately nobody of us has SuSE linux (as far as I know), and so 
> there could be some problems.
I told you, that I'm a bloody noob but this is what I learned first.
:)

> 
> However, it looks like the build has problems finding the Python 
> include files. These might be in e.g. /usr/include/python2.3, or 
> /usr/lib/python2.3/include. You can set this with the configure switch
> "--with-python-includes=/usr/....." If you want to create RPM files, 
> you need to change the civil.spec to reflect this ./configure 
> change.
Used it. Found the libs under /usr/lib/python2.3 but there is a link for
/usr/lib/python too. Yes, I installed the python-devel rpm.

> 
> If this fails, could you please send the output starting from 
> your "./configure "... to the first errors. This is useful since the 
> first errors usually are the culprits and are useful in determining 
> the error, whereas giving the errors "from the middle" doesn't always 
> reveal enough information. Thanks!
> 
> Marcus
As I dont know exactly what to post, I post all (sorry for everybody
else anoying with this):
<snip>
bruchtal:/home/simb/tmp/civil # ./configure --with-python=python2.3
--with-python-includes=/usr/lib/python2.3
checking for a BSD-compatible install... /usr/bin/install -c
checking Python version... python2.3
configure: creating ./config.status
config.status: creating civil
config.status: creating civil-ai
config.status: creating civil-lounge
config.status: creating civil-editor
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating src/version.py
config.status: creating src/paths.py
config.status: creating gfx/Makefile
config.status: creating doc/Makefile
config.status: creating fonts/Makefile
config.status: creating sound/Makefile
config.status: creating scenarios/Makefile
bruchtal:/home/simb/tmp/civil # checkinstall --type=rpm --install=no
--pkgname=civil --pkgversion=0.82-2 --pkgarch=i586
--pkgsource=civil_0.82-2.tar.gz

checkinstall 1.6.0beta2, Copyright 2002 Felipe Eduardo Sanchez Diaz
Duran
           This software is released under the GNU GPL.


The package documentation directory ./doc-pak does not exist.
Should I create a default set of package docs? [y]: n

Installing with "make install"...

========================= Installation results
===========================
make -C src all
make[1]: Entering directory `/home/simb/tmp/civil/src'
cd map/los && \
python2.3 setup.py build && \
cp build/*/ccivil.so .
running build
running build_ext
building 'ccivil' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -D_FILE_OFFSET_BITS=64
-DHAVE_LARGEFILE_SUPPORT -O2 -march=i586 -mcpu=i686 -fmessage-length=0
-fPIC -Wall -fPIC -I/usr/include/python2.3 -c ccivil.c -o
build/temp.linux-i686-2.3/ccivil.o
ccivil.c:1:30: python2.2/Python.h: Datei oder Verzeichnis nicht gefunden
ccivil.c:6: error: parse error before '*' token
ccivil.c: In function `rdlosmap':
ccivil.c:8: error: `PyObject' undeclared (first use in this function)
ccivil.c:8: error: (Each undeclared identifier is reported only once
ccivil.c:8: error: for each function it appears in.)
ccivil.c:8: error: `lx' undeclared (first use in this function)
ccivil.c:8: error: `v' undeclared (first use in this function)
ccivil.c:8: Warnung: left-hand operand of comma expression has no effect
ccivil.c:11: error: `h' undeclared (first use in this function)
ccivil.c:11: Warnung: implicit declaration of function `PyList_Size'
ccivil.c:11: error: `ly' undeclared (first use in this function)
ccivil.c:12: Warnung: implicit declaration of function `PyList_GetItem'
ccivil.c:13: error: `w' undeclared (first use in this function)
ccivil.c:15: error: `mem' undeclared (first use in this function)
ccivil.c:15: Warnung: implicit declaration of function `malloc'
ccivil.c:15: error: `NULL' undeclared (first use in this function)
ccivil.c:16: Warnung: implicit declaration of function `printf'
ccivil.c:25: Warnung: implicit declaration of function `PyInt_AsLong'
ccivil.c: At top level:
ccivil.c:33: error: parse error before '*' token
ccivil.c: In function `rdpixline':
ccivil.c:35: error: `PyObject' undeclared (first use in this function)
ccivil.c:35: error: `v' undeclared (first use in this function)
ccivil.c:37: error: `pw' undeclared (first use in this function)
ccivil.c:38: error: `pixlist' undeclared (first use in this function)
ccivil.c:41: Warnung: implicit declaration of function `PyTuple_GetItem'
ccivil.c:42: error: `mem' undeclared (first use in this function)
ccivil.c: At top level:
ccivil.c:51: error: parse error before '*' token
ccivil.c:51: error: parse error before '*' token
ccivil.c:52: Warnung: return type defaults to `int'
ccivil.c: In function `setlosmap':
ccivil.c:53: error: `PyObject' undeclared (first use in this function)
ccivil.c:53: error: `l' undeclared (first use in this function)
ccivil.c:55: Warnung: implicit declaration of function
`PyArg_ParseTuple'
ccivil.c:55: error: `args' undeclared (first use in this function)
ccivil.c:56: error: `NULL' undeclared (first use in this function)
ccivil.c:58: Warnung: implicit declaration of function `free'
ccivil.c:63: Warnung: implicit declaration of function `Py_BuildValue'
ccivil.c:63: Warnung: return makes pointer from integer without a cast
ccivil.c: In function `trlos':
ccivil.c:103: Warnung: implicit declaration of function `abs'
ccivil.c: At top level:
ccivil.c:162: error: parse error before '*' token
ccivil.c:162: error: parse error before '*' token
ccivil.c:163: Warnung: return type defaults to `int'
ccivil.c: In function `tracelos':
ccivil.c:166: error: `args' undeclared (first use in this function)
ccivil.c:167: error: `NULL' undeclared (first use in this function)
ccivil.c:174: Warnung: return makes pointer from integer without a cast
ccivil.c:178: Warnung: return makes pointer from integer without a cast
ccivil.c: At top level:
ccivil.c:184: error: parse error before '*' token
ccivil.c:184: error: parse error before '*' token
ccivil.c:185: Warnung: return type defaults to `int'
ccivil.c: In function `loslimit':
ccivil.c:189: error: `args' undeclared (first use in this function)
ccivil.c:190: error: `NULL' undeclared (first use in this function)
ccivil.c:192: Warnung: return makes pointer from integer without a cast
ccivil.c:193: Warnung: return makes pointer from integer without a cast
ccivil.c: At top level:
ccivil.c:204: error: parse error before '*' token
ccivil.c:205: Warnung: return type defaults to `int'
ccivil.c: In function `newline':
ccivil.c:207: Warnung: return makes pointer from integer without a cast
ccivil.c: At top level:
ccivil.c:215: error: parse error before '*' token
ccivil.c:215: error: parse error before '*' token
ccivil.c:216: Warnung: return type defaults to `int'
ccivil.c: In function `getlosarea':
ccivil.c:220: error: `PyObject' undeclared (first use in this function)
ccivil.c:220: error: `l' undeclared (first use in this function)
ccivil.c:222: error: `args' undeclared (first use in this function)
ccivil.c:223: error: `NULL' undeclared (first use in this function)
ccivil.c:229: Warnung: implicit declaration of function `PyList_New'
ccivil.c:229: Warnung: return makes pointer from integer without a cast
ccivil.c:253: Warnung: implicit declaration of function `PyList_Append'
ccivil.c: At top level:
ccivil.c:358: error: parse error before '*' token
ccivil.c:358: error: parse error before '*' token
ccivil.c:359: Warnung: return type defaults to `int'
ccivil.c: In function `createlosmap':
ccivil.c:360: error: `PyObject' undeclared (first use in this function)
ccivil.c:360: error: `ly' undeclared (first use in this function)
ccivil.c:360: error: `lx' undeclared (first use in this function)
ccivil.c:360: Warnung: left-hand operand of comma expression has no
effect
ccivil.c:367: error: `args' undeclared (first use in this function)
ccivil.c:368: error: `NULL' undeclared (first use in this function)
ccivil.c:378: Warnung: return makes pointer from integer without a cast
ccivil.c:383: Warnung: return makes pointer from integer without a cast
ccivil.c:428: Warnung: implicit declaration of function `PyList_SetItem'
ccivil.c:433: Warnung: return makes pointer from integer without a cast
ccivil.c: At top level:
ccivil.c:436: error: parse error before "ccivilMethods"
ccivil.c:436: Warnung: type defaults to `int' in declaration of
`ccivilMethods'
ccivil.c:437: Warnung: braces around scalar initializer
ccivil.c:437: Warnung: (near initialization for `ccivilMethods[0]')
ccivil.c:437: Warnung: initialization makes integer from pointer without
a cast
ccivil.c:437: Warnung: excess elements in scalar initializer
ccivil.c:437: Warnung: (near initialization for `ccivilMethods[0]')
ccivil.c:437: error: `METH_VARARGS' undeclared here (not in a function)
ccivil.c:437: Warnung: excess elements in scalar initializer
ccivil.c:437: Warnung: (near initialization for `ccivilMethods[0]')
ccivil.c:437: Warnung: excess elements in scalar initializer
ccivil.c:437: Warnung: (near initialization for `ccivilMethods[0]')
ccivil.c:438: Warnung: braces around scalar initializer
ccivil.c:438: Warnung: (near initialization for `ccivilMethods[1]')
ccivil.c:438: Warnung: initialization makes integer from pointer without
a cast
ccivil.c:438: Warnung: excess elements in scalar initializer
ccivil.c:438: Warnung: (near initialization for `ccivilMethods[1]')
ccivil.c:438: error: `METH_VARARGS' undeclared here (not in a function)
ccivil.c:438: Warnung: excess elements in scalar initializer
ccivil.c:438: Warnung: (near initialization for `ccivilMethods[1]')
ccivil.c:438: Warnung: excess elements in scalar initializer
ccivil.c:438: Warnung: (near initialization for `ccivilMethods[1]')
ccivil.c:439: Warnung: braces around scalar initializer
ccivil.c:439: Warnung: (near initialization for `ccivilMethods[2]')
ccivil.c:439: Warnung: initialization makes integer from pointer without
a cast
ccivil.c:439: Warnung: excess elements in scalar initializer
ccivil.c:439: Warnung: (near initialization for `ccivilMethods[2]')
ccivil.c:439: error: `METH_VARARGS' undeclared here (not in a function)
ccivil.c:439: Warnung: excess elements in scalar initializer
ccivil.c:439: Warnung: (near initialization for `ccivilMethods[2]')
ccivil.c:439: Warnung: excess elements in scalar initializer
ccivil.c:439: Warnung: (near initialization for `ccivilMethods[2]')
ccivil.c:440: Warnung: braces around scalar initializer
ccivil.c:440: Warnung: (near initialization for `ccivilMethods[3]')
ccivil.c:440: Warnung: initialization makes integer from pointer without
a cast
ccivil.c:440: Warnung: excess elements in scalar initializer
ccivil.c:440: Warnung: (near initialization for `ccivilMethods[3]')
ccivil.c:440: error: `METH_VARARGS' undeclared here (not in a function)
ccivil.c:440: Warnung: excess elements in scalar initializer
ccivil.c:440: Warnung: (near initialization for `ccivilMethods[3]')
ccivil.c:440: Warnung: excess elements in scalar initializer
ccivil.c:440: Warnung: (near initialization for `ccivilMethods[3]')
ccivil.c:441: Warnung: braces around scalar initializer
ccivil.c:441: Warnung: (near initialization for `ccivilMethods[4]')
ccivil.c:441: Warnung: initialization makes integer from pointer without
a cast
ccivil.c:441: Warnung: excess elements in scalar initializer
ccivil.c:441: Warnung: (near initialization for `ccivilMethods[4]')
ccivil.c:441: error: `METH_VARARGS' undeclared here (not in a function)
ccivil.c:441: Warnung: excess elements in scalar initializer
ccivil.c:441: Warnung: (near initialization for `ccivilMethods[4]')
ccivil.c:441: Warnung: excess elements in scalar initializer
ccivil.c:441: Warnung: (near initialization for `ccivilMethods[4]')
ccivil.c:443: Warnung: braces around scalar initializer
ccivil.c:443: Warnung: (near initialization for `ccivilMethods[5]')
ccivil.c:443: error: `NULL' undeclared here (not in a function)
ccivil.c:443: error: initializer element is not constant
ccivil.c:443: error: (near initialization for `ccivilMethods[5]')
ccivil.c:443: error: `NULL' undeclared here (not in a function)
ccivil.c:443: Warnung: excess elements in scalar initializer
ccivil.c:443: Warnung: (near initialization for `ccivilMethods[5]')
ccivil.c:443: Warnung: excess elements in scalar initializer
ccivil.c:443: Warnung: (near initialization for `ccivilMethods[5]')
ccivil.c:443: error: `NULL' undeclared here (not in a function)
ccivil.c:443: Warnung: excess elements in scalar initializer
ccivil.c:443: Warnung: (near initialization for `ccivilMethods[5]')
ccivil.c:443: error: initializer element is not constant
ccivil.c:443: error: (near initialization for `ccivilMethods[5]')
ccivil.c:444: Warnung: data definition has no type or storage class
ccivil.c: In function `initccivil':
ccivil.c:448: error: `NULL' undeclared (first use in this function)
ccivil.c:449: Warnung: implicit declaration of function `Py_InitModule'
error: command 'gcc' failed with exit status 1
make[1]: *** [all] Fehler 1
make[1]: Leaving directory `/home/simb/tmp/civil/src'
make: *** [all] Fehler 2

****  Installation failed. Aborting package creation.

Restoring overwritten files from backup...OK

Cleaning up...OK

Bye.
<snap> 

Again, thank you for your support.
Jean

Hi Jean,

I don't myself use checkinstall, but it doesn't seem to be a problem with
that tool. There is one small module written in C which does not seem to
get compiled properly. I'd assume that the build process does not find the
development headers for Python 2.3, do you have those installed? Something
like python2.3-devel or similar. Without these you can't compile the C
extension.

If that is not the case could you please post the complete compilation
log so that we can look for clues?

Regards,
    Chakie


On Sun, 25 Jan 2004, Jean von Oertzen wrote:

>I usually build rpm's with checkinstall.
>I found the option for the configure file --with-python which I used as
>--with-python=python2.3
>No I get a many warnings like
><snip>
>ccivil.c:444: Warnung: data definition has no type or storage class
>ccivil.c: In function `initccivil':
>ccivil.c:448: error: `NULL' undeclared (first use in this function)
>ccivil.c:449: Warnung: implicit declaration of function `Py_InitModule'
><snap>
>and the compilation stops with
><snip>
>error: command 'gcc' failed with exit status 1
><snap>
>I have gcc (GCC) 3.3.1 (SuSE Linux)
>
>Can someone help me to make a rpm with checkinstall?
>Thanks in advance.
>
>Jean
>
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by EclipseCon 2004
>Premiere Conference on Open Tools Development and Integration
>See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
>http://www.eclipsecon.org/osdn
>_______________________________________________
>Civil-devel mailing list
>Civ...@li...
>https://lists.sourceforge.net/lists/listinfo/civil-devel
>

-- 
          "Yes, bugger all that." said Nanny. "Let's curse somebody."
                                            -- Terry Pratchett, Wyrd Sisters

On Sun, 25 Jan 2004, Jean von Oertzen wrote:

> I'm a bloody noob on pygames. So as civil looks quite beautyfull, I
> downloaded the .tar.gz from sourceforge.
> 
> I usually build rpm's with checkinstall. 
> I found the option for the configure file --with-python which I used as
> --with-python=python2.3 
> No I get a many warnings like
> <snip>
> ccivil.c:444: Warnung: data definition has no type or storage class
> ccivil.c: In function `initccivil':
> ccivil.c:448: error: `NULL' undeclared (first use in this function)
> ccivil.c:449: Warnung: implicit declaration of function `Py_InitModule'
> <snap>
> and the compilation stops with
> <snip>
> error: command 'gcc' failed with exit status 1
> <snap>
> I have gcc (GCC) 3.3.1 (SuSE Linux)
> 
> Can someone help me to make a rpm with checkinstall?
> Thanks in advance.

Hello Jean,

sometimes it's quite frustrating to make projects compile. There are 
lot's of things that need to be taken into consideration. 
Unfortunately nobody of us has SuSE linux (as far as I know), and so 
there could be some problems.

However, it looks like the build has problems finding the Python 
include files. These might be in e.g. /usr/include/python2.3, or 
/usr/lib/python2.3/include. You can set this with the configure switch
"--with-python-includes=/usr/....." If you want to create RPM files, 
you need to change the civil.spec to reflect this ./configure 
change.

If this fails, could you please send the output starting from 
your "./configure "... to the first errors. This is useful since the 
first errors usually are the culprits and are useful in determining 
the error, whereas giving the errors "from the middle" doesn't always 
reveal enough information. Thanks!

Marcus

Hi,

I'm a bloody noob on pygames. So as civil looks quite beautyfull, I
downloaded the .tar.gz from sourceforge.

I usually build rpm's with checkinstall. 
I found the option for the configure file --with-python which I used as
--with-python=python2.3 
No I get a many warnings like
<snip>
ccivil.c:444: Warnung: data definition has no type or storage class
ccivil.c: In function `initccivil':
ccivil.c:448: error: `NULL' undeclared (first use in this function)
ccivil.c:449: Warnung: implicit declaration of function `Py_InitModule'
<snap>
and the compilation stops with
<snip>
error: command 'gcc' failed with exit status 1
<snap>
I have gcc (GCC) 3.3.1 (SuSE Linux)

Can someone help me to make a rpm with checkinstall?
Thanks in advance.

Jean

E-mail is the fastest growing marketing tool.

We offer E-mail Marketing with quality service and the lowest prices.

1. Targeted E-mail Addresses

We can provide targeted e-mail addresses you need, which are compiled 
only on your order. We will customize your customer e-mail addresses.

* We have millions of e-mail addresses in a wide variety of categories.

2. Send out Targeted E-mails for you

We can send your e-mail message to your targeted customers! We will
customize your email addresses and send your message for you.

* We can Bullet-Proof your Web Site.

We also offer a wide variety of marketing software. For more details, you
can refer to:  Http://www.Marketing-Savant.com

Looking forward to serving you, and your business needs!


Regards!

Tony Madu
Marketing Support
www.Marketing-Savant.com
Sa...@Ma...

*************************************************************************
To remove your address from list:
http://quicktell.net/responder/delist.cgi/q/3/17134747/142960
*************************************************************************

korruptor wrote:

> >>>Blimey, everyone's still alive! :D
> >>
> >>You wouldn't know it from the list... but I'm still alive as well.
> >>Tired (4 month old daughter :), but breathing.
> 
> 
> Sorry, but that makes it official. Civil still lives, and we're all 
> still here!
> 
> Congrats, John!

Thanks Gareth.

-- 

John Eikenberry
[ja...@zh... - http://zhar.net]
______________________________________________________________
"Perfection (in design) is achieved not when there is nothing more to add,
 but rather when there is nothing more to take away."
                                        -- Antoine de Saint-Exupery

Jan Ekholm wrote:

> On Tue, 13 Jan 2004, John Eikenberry wrote:
> 
> >You wouldn't know it from the list... but I'm still alive as well.
> >Tired (4 month old daughter :), but breathing.
> 
> Oo, congratulations! You're not getting too much sleep then, apparently
> she doesn't yet sleep through the nights? You have to teach her about the
> virtues of hacking early on, small children are quite good at writing
> code. The 2 month old kid of a friend wrote code that looked a bit like
> obfuscated C, but much better than Perl. And the energy he put into the
> hacking was amazing. :)

Thanks. She (Fiona) can sleep for about 5 hours at a time. Which 5 hours
is another matter...

I hope to get her started with computers as soon as she shows an
interest. Given the amount of time my wife and I are on our computers,
she's going to be banging on those keys soon. Just need to find a
slobber proof keyboard. :)
 
> >I've been gone so long I'm not sure what excuse to use for my
> >disappearing. Just assume all of them. ;)
> 
> It's probably called Life...

Never thought someone would accuse me of having one of those...

-- 

John Eikenberry
[ja...@zh... - http://zhar.net]
______________________________________________________________
"Perfection (in design) is achieved not when there is nothing more to add,
 but rather when there is nothing more to take away."
                                        -- Antoine de Saint-Exupery

Hi,

A short update. Time now works on the server and the main engine seems to
be ticking ok. The clients also receive the time data and show it just
fine. So something is progressing at least. :)

Next step is to modify the order handling so that every given plan is sent
to the server for calculations. I'll start with movement plans, I think.
This should be no big problem, and after that other plans can be added and
soon we'll be back with the same functionality that we had prior to this
"genius idea" of mine.

I hope you've had a good weekend. We just saw "The Core", and the
scientist in me had a good laugh. :)

-- 
         In the Beginning there was nothing, which exploded.
                                        -- Terry Pratchett, Lords and Ladies

On Fri, 16 Jan 2004, korruptor wrote:

>> When players give orders to units a Plan is created and sent off to the
>> server. The plan is also stored locally at the unit in question and
>> immediately used for visualization to give the player a feeling of
>> immediate response. The server will when it receive the plan start
>> processing it immediately if the unit has no other current plan, or
>> append
>> to the unit's plans if it already has some other plans. If the plan for
>> some reason is not acceptably according to the server then an action is
>> sent to the player that cancels the plan.
>
>Ok, speak slowly for the English.

Ah, yeah, I forgot that you don't always grok as fast as the rest of us.
:)

>The client is parsing the plan as the player builds it? So only options
>that make sense in that tree (from a given state) are available. Are
>you then throwing this information away so only the server knows the
>true/full 'plan' of the unit?

Hm, yes. Is that a bad idea? Alternatively it could be stored locally and
considered ok until the server ASAP sends back something to say it's not.
The client knows what the unit can do at each point in time, and it
already won't accept movement orders that are impossible (into water etc),
so there shouldn't really be any cases when the server needs to deny an
order. Another issue is when a unit, say, gets fired upon and that makes
it freak out and forget about any previous plans. But that's ok.

Ok, after some reasoning I think it's best to do as you suggest.

>What are the cases where the plan is not acceptable to the server?

Shouldn't really be any. Plans will get cancelled due to combat etc, but
that's another issue.

>> 2. keep at the client a "state" for the unit as it would be after all
>> orders are executed. This way the "mount" order would change the
>> temporary
>> state to "mounted" and the "move fast" would be allowed. We do
>> something
>> similar right now, although using deep copies of all units.
>
>Surely the client has to keep some state, even if it's only the
>end-state of the plan previously sent to the server? How would the
>client present an accurate list of options to the player, otherwise? Or
>is it always assumed from some base state?

It has to keep some state. I think it will only need to keep track of the
mode of the unit (mounted, column etc) in some temporary variable.

>I'm ignoring anything that may or may not already exist, as I can't
>remember the last time I looked at the source. Sorry :)

Oh, no worries mate.

-- 
                 "Students?" barked the Archchancellor.
    "Yes, Master. You know? They're the thinner ones with the pale faces?
  Because we're a university? They come with the whole thing, like rats --"
                                         -- Terry Pratchett, Moving Pictures

> When players give orders to units a Plan is created and sent off to the
> server. The plan is also stored locally at the unit in question and
> immediately used for visualization to give the player a feeling of
> immediate response. The server will when it receive the plan start
> processing it immediately if the unit has no other current plan, or 
> append
> to the unit's plans if it already has some other plans. If the plan for
> some reason is not acceptably according to the server then an action is
> sent to the player that cancels the plan.

Ok, speak slowly for the English.

The client is parsing the plan as the player builds it? So only options 
that make sense in that tree (from a given state) are available. Are 
you then throwing this information away so only the server knows the 
true/full 'plan' of the unit?

What are the cases where the plan is not acceptable to the server?

> 2. keep at the client a "state" for the unit as it would be after all
> orders are executed. This way the "mount" order would change the 
> temporary
> state to "mounted" and the "move fast" would be allowed. We do 
> something
> similar right now, although using deep copies of all units.

Surely the client has to keep some state, even if it's only the 
end-state of the plan previously sent to the server? How would the 
client present an accurate list of options to the player, otherwise? Or 
is it always assumed from some base state?

I'm ignoring anything that may or may not already exist, as I can't 
remember the last time I looked at the source. Sorry :)

G

--
gawk; talk; date; wine; grep; touch; unzip; strip; touch; gasp; finger; 
gasp; mount; fsck; more; yes; fsck; gasp; eject; umount; make clean; 
make mrproper; sleep;

   -- Unknown Unix Barry White
--

>>> Blimey, everyone's still alive! :D
>>
>> You wouldn't know it from the list... but I'm still alive as well.
>> Tired (4 month old daughter :), but breathing.


Sorry, but that makes it official. Civil still lives, and we're all 
still here!

Congrats, John!


>>> Just noticed the flurry of activity, so thought I'd pop my head 
>>> through
>>> the door. Sorry for my disappearance, but the new job is taking up 
>>> most
>>> of my time - I've been pulling mental hours. :)
>>
>> I've been gone so long I'm not sure what excuse to use for my
>> disappearing. Just assume all of them. ;)
>
> It's probably called Life...

I'll drink to that. :)

G

> --
"There are only 10 types of people in the world. Those that understand 
binary, and those that don't"
     -- Dan Smith, Edge, Issue 113.
--

On Thu, 15 Jan 2004, Mike Earl wrote:

>On Wed, 2004-01-14 at 05:14, Jan Ekholm wrote:
>> 1. disallow all mode changed while moving, the unit must be standing still
>> for those to work. This means that only movement orders can be queued up,
>> al others affect the unit immediately.
>
>This would be pretty annoying, I think.  There probably shouldn't be a
>1-1 correspondence between player orders and unit actions.   Let the
>player just order the unit "Move fast to position X; Then Dismount", and
>have the unit figure out whether it needs to mount before moving, what
>path to use, etc. etc.

Yes, it would be annoying, I agree. The problem is keeping internally
track of what state the unit will be in after it has executed all orders
it has and what orders the player then can give to it. Well, thinking a
bit about it, it's not that hard actually. Quite simple, we only need to
store the mode the unit would be in somewhere, and always base all
possible orders on that last mode. Yeah.

>FWIW, the RTS's I'm familiar with tend to have player movement orders
>all go through the pathfinder, with at least "Move only", "Move to and
>attack a specific enemy unit", and "Move, attacking any enemy units
>sighted along the way", and maybe "Move, firing only if fired upon." or
>"Move in formation with other selected units", with an option of queuing
>orders.   If Civil is running a bit slower than the usual clickfest
>options for finer control might make sense.

Good idea. I'm not too familiar with modern RTS games, but from what I've
seen on the TV and videos they are all far too fast for me. I want to win
a game by good thinking, not by faster clicking.

These extra orders could be a good think to implement at some time,
although they are already partially covered by the "combat policy" system
which determines how aggressive an unit should be. It can simple be
extended a bit and made to apply when moving the unit too, not just when
only standing still.

-- 

  That's right," he said. "We're philosophers. We think, therefore we am.
                                             -- Terry Pratchett, Small Gods

On Wed, 2004-01-14 at 05:14, Jan Ekholm wrote:
> 1. disallow all mode changed while moving, the unit must be standing still
> for those to work. This means that only movement orders can be queued up,
> al others affect the unit immediately.

This would be pretty annoying, I think.  There probably shouldn't be a
1-1 correspondence between player orders and unit actions.   Let the
player just order the unit "Move fast to position X; Then Dismount", and
have the unit figure out whether it needs to mount before moving, what
path to use, etc. etc.

FWIW, the RTS's I'm familiar with tend to have player movement orders
all go through the pathfinder, with at least "Move only", "Move to and
attack a specific enemy unit", and "Move, attacking any enemy units
sighted along the way", and maybe "Move, firing only if fired upon." or
"Move in formation with other selected units", with an option of queuing
orders.   If Civil is running a bit slower than the usual clickfest
options for finer control might make sense.

- mikee

Hi,

Just to make it clear to myself and open up for some discussion I thought
I would define the idea I have for how orders are given to units and how
they work. I have very limited RTS experience as I haven't played a RTS
game since Dune2, and that was a while ago. :)

The basic idea is that the clients are just dumb visualizing clients as
far as possible, all calculations that affect the units are performed by
the server.

When players give orders to units a Plan is created and sent off to the
server. The plan is also stored locally at the unit in question and
immediately used for visualization to give the player a feeling of
immediate response. The server will when it receive the plan start
processing it immediately if the unit has no other current plan, or append
to the unit's plans if it already has some other plans. If the plan for
some reason is not acceptably according to the server then an action is
sent to the player that cancels the plan.

I would like to give the player a possibility to give several movement
orders to a unit, ie. plot a path. Allowing only one movement order is
very limiting and a bit silly as our current framework already handles
multiple orders just fine. Movement orders are actualy no problem at all,
but how to handle mode changes is a bit harder. Think but the following:

	cavalry is dismounted
	move to pos1
	mount
	move fast to pos2

The first move order is just fine, the plan is created, sent and stored
locally. The server starts executing it and sends back updates. The player
now decides that once the unit has reached pos1 it should mount. Fine,
same procedure, plan is created, sent etc. Now the player wants to move
fast to pos2. This is however currently not possible, as the cavalry is
most likely still dismounted (dismounted cavalry can't move fast) and the
move fast order isn't even available. How should this be solved?

A few solutions:

1. disallow all mode changed while moving, the unit must be standing still
for those to work. This means that only movement orders can be queued up,
al others affect the unit immediately.

2. keep at the client a "state" for the unit as it would be after all
orders are executed. This way the "mount" order would change the temporary
state to "mounted" and the "move fast" would be allowed. We do something
similar right now, although using deep copies of all units.

3. something totally different and much better?

Ideas?

-- 

        Most gods find it hard to walk and think at the same time.
                                             -- Terry Pratchett, Small Gods

On Tue, 13 Jan 2004, John Eikenberry wrote:

>korruptor wrote:
>
>> Blimey, everyone's still alive! :D
>
>You wouldn't know it from the list... but I'm still alive as well.
>Tired (4 month old daughter :), but breathing.

Oo, congratulations! You're not getting too much sleep then, apparently
she doesn't yet sleep through the nights? You have to teach her about the
virtues of hacking early on, small children are quite good at writing
code. The 2 month old kid of a friend wrote code that looked a bit like
obfuscated C, but much better than Perl. And the energy he put into the
hacking was amazing. :)

>> Just noticed the flurry of activity, so thought I'd pop my head through
>> the door. Sorry for my disappearance, but the new job is taking up most
>> of my time - I've been pulling mental hours. :)
>
>I've been gone so long I'm not sure what excuse to use for my
>disappearing. Just assume all of them. ;)

It's probably called Life...

-- 
  And it came to pass that in time the Great God Om spake unto Brutha,
    the Chosen One: "Psst!"
                                        -- Terry Pratchett, Small Gods

On Wed, 13 Jan 2004, Mike Earl wrote:

>On Tue, 2004-01-13 at 16:03, Jan Ekholm wrote:
>> I planned on running that internal simulator once each second. Does that
>> sound too little? Each second would be five game seconds, so a speedup of
>> five would be achieved. Or it could be made variable somehow, or just a
>> bit faster, say 10s.
>
>Yah, sounds about right.  There was some discussion of this quite a
>while ago; I think the conclusion was that the limiting factor on size
>of timeslices was movement keeping the movement of fast-moving units
>(cavalry?) small per slice.

Ah, true. I must dig out my old stored civil-devel archives and have a
look.

>Top running speed of a horse would amount to about... um (grumble silly
>metric nonsense)...  10-15 m/s?  How big a position delta can we have
>between slices?

Heh, most people do understand feet too, it's just a matter of feet/3 to
get the ISO international standard unit meters. :)

However, I'm pretty sure that even charging cavalry doesn't run the horses
at full speed, as that makes it harder to keep the ranks intact. But maybe
10m/s is a good approximation. This will mean that the leaps that charging
cavalry does are pretty long. Speeding up the engine speed to say 0.25s
means a lot more traffic, as every moving unit will require one more
update. This can be cured by having the server only send big movements,
and have the clients interpolate along a straight line. I'd rather have as
little calculations as possible in the clients to avoid situations where
they are not synchronized. If this happens there will be a jerk of some
kind when the client synchronizes the unit to where the server says
it should be.

-- 
  And it came to pass that in time the Great God Om spake unto Brutha,
    the Chosen One: "Psst!"
                                        -- Terry Pratchett, Small Gods

On Tue, 2004-01-13 at 16:03, Jan Ekholm wrote:
> I planned on running that internal simulator once each second. Does that
> sound too little? Each second would be five game seconds, so a speedup of
> five would be achieved. Or it could be made variable somehow, or just a
> bit faster, say 10s.

Yah, sounds about right.  There was some discussion of this quite a
while ago; I think the conclusion was that the limiting factor on size
of timeslices was movement keeping the movement of fast-moving units
(cavalry?) small per slice.  

Top running speed of a horse would amount to about... um (grumble silly 
metric nonsense)...  10-15 m/s?  How big a position delta can we have
between slices?

- mikee

On Tue, 13 Jan 2004, Marcus Alanen wrote:

>
>
>Jan Ekholm wrote:
>> Two ways as I see it:
>>
>> 1. a fixed number of turns like we have now and the server just decides
>> when it is time to go turn++. Then the current time is calculated based on
>> the starting time + current turn * acceleration factor.
>>
>> 2. starting date as a firm date and time as now, but the server instead
>> adds seconds to the date for each "turn", and when the date reaches a
>> certain given ending date the game is over. This is maybe more logical for
>> the scenario designers, and you can say "the battle starts at 09:30 and
>> progresses until 18:00", no need to worry about turns etc. This requires a
>> small scenario format change, but it's pretty minor to implement.
>
>Definitely the second thing, since it keeps things more in the real
>world. Turns aren't a useful concept any longer, one timeslice inside
>the server "simulator" should be very small.

I planned on running that internal simulator once each second. Does that
sound too little? Each second would be five game seconds, so a speedup of
five would be achieved. Or it could be made variable somehow, or just a
bit faster, say 10s.

-- 
                 "Students?" barked the Archchancellor.
    "Yes, Master. You know? They're the thinner ones with the pale faces?
  Because we're a university? They come with the whole thing, like rats --"
                                         -- Terry Pratchett, Moving Pictures

On Tue, 13 Jan 2004, Brandon J. Van Every wrote:

>Ok... I advised you because you tried to advise me, and it seems you are
>not not receptive to the advice.  But the seed has been planted and
>maybe you'll think seriously about MAIN POINTS in the future.

Ok.

Now, to get back to what this list is about, do you have any technical
ideas for improvements?

-- 
                 "Students?" barked the Archchancellor.
    "Yes, Master. You know? They're the thinner ones with the pale faces?
  Because we're a university? They come with the whole thing, like rats --"
                                         -- Terry Pratchett, Moving Pictures

korruptor wrote:

> Blimey, everyone's still alive! :D

You wouldn't know it from the list... but I'm still alive as well.
Tired (4 month old daughter :), but breathing.

> Just noticed the flurry of activity, so thought I'd pop my head through 
> the door. Sorry for my disappearance, but the new job is taking up most 
> of my time - I've been pulling mental hours. :)

I've been gone so long I'm not sure what excuse to use for my
disappearing. Just assume all of them. ;)


-- 

John Eikenberry
[ja...@zh... - http://zhar.net]
______________________________________________________________
"Perfection (in design) is achieved not when there is nothing more to add,
 but rather when there is nothing more to take away."
                                        -- Antoine de Saint-Exupery

Jan Ekholm wrote:
> Two ways as I see it:
> 
> 1. a fixed number of turns like we have now and the server just decides
> when it is time to go turn++. Then the current time is calculated based on
> the starting time + current turn * acceleration factor.
> 
> 2. starting date as a firm date and time as now, but the server instead
> adds seconds to the date for each "turn", and when the date reaches a
> certain given ending date the game is over. This is maybe more logical for
> the scenario designers, and you can say "the battle starts at 09:30 and
> progresses until 18:00", no need to worry about turns etc. This requires a
> small scenario format change, but it's pretty minor to implement.

Definitely the second thing, since it keeps things more in the real 
world. Turns aren't a useful concept any longer, one timeslice inside 
the server "simulator" should be very small.

Ok... I advised you because you tried to advise me, and it seems you are
not not receptive to the advice.  But the seed has been planted and
maybe you'll think seriously about MAIN POINTS in the future.


Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"Desperation is the motherfucker of Invention." - Robert Prestridge