Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-19 Thread Gerard Krol
Per Inge Mathisen wrote:
 I would like to suggest that we start refactoring the Warzone codebase
 so that it can more easily be unit tested aggressively. 
   
Would it be an idea to wait for the merge from the terrain and the lua 
branch? That's going to be one hell of a job after we refactor the code. 
I might be repeating myself, but I'd like to branch and release asap, 
and merge the terrain and lua branches in. We can then to all the nice 
refactoring we want.

- Gerard

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-19 Thread Per Inge Mathisen
On Thu, Feb 19, 2009 at 12:47 PM, Gerard Krol
g.c.k...@student.tudelft.nl wrote:
 Per Inge Mathisen wrote:
 I would like to suggest that we start refactoring the Warzone codebase
 so that it can more easily be unit tested aggressively.

 Would it be an idea to wait for the merge from the terrain and the lua
 branch? That's going to be one hell of a job after we refactor the code.
 I might be repeating myself, but I'd like to branch and release asap,
 and merge the terrain and lua branches in. We can then to all the nice
 refactoring we want.

No problem. I agree we should branch for 2.2 now. Anyone see any
reasons why not?

What is the state of the lua branch, though? I got the impression it
still had a way to go before it was playable.

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-19 Thread Dennis Schridde
Am Donnerstag, 19. Februar 2009 15:03:59 schrieb Per Inge Mathisen:
 What is the state of the lua branch, though? I got the impression it
 still had a way to go before it was playable.
Last time I tried, the AI was just sitting there on Rush. Console spammed 
something about nils.
(I tested that this was *not* caused by my merge, but till now I found no one 
to confirm or confute.)

--DevU


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-19 Thread Zarel
2009/2/19 Per Inge Mathisen per.mathi...@gmail.com:
 No problem. I agree we should branch for 2.2 now. Anyone see any
 reasons why not?

Now that I've figured out how to commit to branches other than trunk,
I'm fine with this, too.

It seems everyone's in support of branching immediately? (I count me,
Buggy, Gerard, Per for, and no one against)

- Zarel

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-18 Thread Dennis Schridde
Am Mittwoch, 18. Februar 2009 09:54:59 schrieb Giel van Schijndel:
 On Tue, Feb 17, 2009 at 07:10:22PM +0100, Per Inge Mathisen wrote:
  2) has *at least* one unit test,
  3) uses *no* globals,
BTW: libtagfile violates this.
I have a branch here were I fixed that, but I do not remember whether it was 
complete. (Can put it on the tracker if you want, and do not mind some maybe 
half-finished work.)

--DevU


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-18 Thread Per Inge Mathisen
On Wed, Feb 18, 2009 at 11:03 AM, Dennis Schridde devuran...@gmx.net wrote:
 Am Mittwoch, 18. Februar 2009 09:54:59 schrieb Giel van Schijndel:
 On Tue, Feb 17, 2009 at 07:10:22PM +0100, Per Inge Mathisen wrote:
  2) has *at least* one unit test,
  3) uses *no* globals,
 BTW: libtagfile violates this.
 I have a branch here were I fixed that, but I do not remember whether it was
 complete. (Can put it on the tracker if you want, and do not mind some maybe
 half-finished work.)

Please do put it on the tracker.

I will post a patch that cleans up, moves, reuses and unit tests
mapLoad() later, then we can use that as a sort of test case for
figuring out the details of where we go from here.

 -  Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-18 Thread Kamaze
This might be a good time to bump the major version number?

Per Inge Mathisen schrieb:
 Hello devs,
 
 We all know that the current and past state of the Warzone codebase is
 a rather sorry excuse for something. There are so many globals all
 over the place, that it is almost impossible to separate out code for
 proper unit testing or reuse. The code is buggy, and we do not have a
 process in place to ensure that it gets better. I dare say that if the
 only thing that keeps Warzone from sliding from bad to worse in terms
 of bugs is hard work, there is no chance that we will not get to the
 point of stability where we want to be.
 
 To try to keep the addition of new bugs less than the number of fixed
 bugs, we added commit rules. I still think they are important, but I
 can't say they have been a great success.
 
 I would like to suggest that we start refactoring the Warzone codebase
 so that it can more easily be unit tested aggressively. That way we
 can steadily add test upon test to ensure that the codebase gets
 increasingly robust. In addition, it will help with code reuse between
 different future applications that may want it (map editor, qwzm,
 warzone studio, utilities, etc.). And we can clean up code while we're
 at it. The plan I would suggest is to start moving code into a new
 directory, lib/base/, where we put functions that can pass the
 following criteria:
 1) can be relevant for more than one application,
 2) has *at least* one unit test,
 3) uses *no* globals,
 4) and follows the coding style guide.
 
 I would like to start porting the map loading code there. If you like
 the idea. Then hopefully we could all pitch in and port the functions
 you are more familiar with and soon we will have a new, shiny and
 improved Warzone codebase that everyone loves working with.
 
   - Per
 
 ___
 Warzone-dev mailing list
 Warzone-dev@gna.org
 https://mail.gna.org/listinfo/warzone-dev

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-18 Thread Dennis Schridde
Am Mittwoch, 18. Februar 2009 17:15:45 schrieb Kamaze:
 This might be a good time to bump the major version number?
I do not think someone said something about a major rewrite.
Additionaly the version number should represent user visible changes, and so 
far I see no proposal for even on in this thread...

--DevU


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


[Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-17 Thread Per Inge Mathisen
Hello devs,

We all know that the current and past state of the Warzone codebase is
a rather sorry excuse for something. There are so many globals all
over the place, that it is almost impossible to separate out code for
proper unit testing or reuse. The code is buggy, and we do not have a
process in place to ensure that it gets better. I dare say that if the
only thing that keeps Warzone from sliding from bad to worse in terms
of bugs is hard work, there is no chance that we will not get to the
point of stability where we want to be.

To try to keep the addition of new bugs less than the number of fixed
bugs, we added commit rules. I still think they are important, but I
can't say they have been a great success.

I would like to suggest that we start refactoring the Warzone codebase
so that it can more easily be unit tested aggressively. That way we
can steadily add test upon test to ensure that the codebase gets
increasingly robust. In addition, it will help with code reuse between
different future applications that may want it (map editor, qwzm,
warzone studio, utilities, etc.). And we can clean up code while we're
at it. The plan I would suggest is to start moving code into a new
directory, lib/base/, where we put functions that can pass the
following criteria:
1) can be relevant for more than one application,
2) has *at least* one unit test,
3) uses *no* globals,
4) and follows the coding style guide.

I would like to start porting the map loading code there. If you like
the idea. Then hopefully we could all pitch in and port the functions
you are more familiar with and soon we will have a new, shiny and
improved Warzone codebase that everyone loves working with.

  - Per

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-17 Thread Kreuvf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Per Inge Mathisen wrote:
 I would like to start porting the map loading code there. If you like
 the idea. Then hopefully we could all pitch in and port the functions
 you are more familiar with and soon we will have a new, shiny and
 improved Warzone codebase that everyone loves working with.
Although I cannot be of a great help, I appreciate this idea. If things go well,
I'll be there for an interview ;)

- - Kreuvf
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJmv6Y4y86f1GXLDwRAnvpAKC0hoU2PShFHLALQ1ZyoQ/8h6aXjgCfaKHZ
3hoAKaMTmge9/5PgY4aA0v8=
=tto2
-END PGP SIGNATURE-

___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev


Re: [Warzone-dev] A plan to refactor and clean up the warzone code base

2009-02-17 Thread Dennis Schridde
Hello!

Sounds like a good idea, though I will not have enough time to actively 
participate in the near future.


Maybe I may still propose something:
Move the current code into /dirty/ and selectively pick cleaned files from 
there and move them into a sensible location / directory-layout in the main 
tree.


I would also propose (thought probably quite unrelated and off-topic) to move 
3rd party (library) code into distinct directory like /external/. I think this 
will be nice to distributors, help ourselves to maintain the code, prevent 
confusion about who is responsible for compiler warnings/errors or even 
misfeatures.
Candidates I see right now are glee and sqlite.
Proposed naming: /external/${LIBRARY}-${VERSION}

--DevU


signature.asc
Description: This is a digitally signed message part.
___
Warzone-dev mailing list
Warzone-dev@gna.org
https://mail.gna.org/listinfo/warzone-dev