Complete.Org: Mailing Lists: Archives: freeciv-dev: October 2003:
[Freeciv-Dev] Re: (PR#6585) Delta version 5
Home

[Freeciv-Dev] Re: (PR#6585) Delta version 5

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: undisclosed-recipients: ;
Subject: [Freeciv-Dev] Re: (PR#6585) Delta version 5
From: "Raimar Falke" <i-freeciv-lists@xxxxxxxxxxxxx>
Date: Tue, 28 Oct 2003 11:32:44 -0800
Reply-to: rt@xxxxxxxxxxxxxx

On Fri, Oct 24, 2003 at 05:17:23AM -0700, Per I. Mathisen wrote:
> 
> The generate_packets.py python script is too ugly.

Yes it is ugly. It is the most ugly python script I wrote so
far. Still I don't know how to make it better. The worst offenders are
the multi-line strings and some special cases.

> I suspect it does too much, but I am unable to read it to figure out if
> this is the case or no. I suspect it tries to cater to too many expections
> and kludges. Instead, these kludges should be straightened out and
> removed.

I agree with the kludges. However theren't any big ones anymore.

Just an example what bloats the code. The get_put returns the C-code
fragment which put a field (all delta stuff is done one layer above):

    def get_put(self):
        if self.dataio_type=="bitvector":
            return "DIO_BV_PUT(&dout, packet->%(name)s);"%self.__dict__

        if self.struct_type=="float" and not self.is_array:
            return "  dio_put_uint32(&dout, (int)(real_packet->%(name)s * 
%(float_factor)d));"%self.__dict__
        
        if self.dataio_type in ["worklist"]:
            return "  dio_put_%(dataio_type)s(&dout, 
&real_packet->%(name)s);"%self.__dict__

        if self.dataio_type in ["memory"]:
            return "  dio_put_%(dataio_type)s(&dout, &real_packet->%(name)s, 
%(array_size_u)s);"%self.__dict__
        ....

So a bitvector function doesn't follow the usual lowercase function
names. We need to convert floats to 4 byte integer values. And
worklists and raw memory have a generic function name but different
arguments.

I have no real idea here. We want to support all these different types
and with the dio_* functions we have already abstracted a lot of the
ugly details away.

I'm still working on the capability stuff and have to an idea and a
first version available. But it enlarges both the generator and the
generated source by quite some amount. So there is a chance that you
say that we don't need non-mandatory capabilities for now. This will
make the generator a bit easier.

> It does not conform to freeciv style guide, to the extent that this
> would apply. This it should.

The generator or the generated source? I know that the generated
source doesn't wrap at 80 chars. But I didn't know that the style
guide also applies to non-C source.

> It lacks comments. This is critical.

I will add some.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "> WHY?! Isn't it better to put $(shell cat cscope.files) on the list of
  I only have a yellow belt in makefile kungfu.  These fancy gnu make things
  are relatively new to some of us..."
    -- Mark Frazer to Vassilii Khachaturov in linux-kernel



[Prev in Thread] Current Thread [Next in Thread]