Major Clean-up

Propose and discuss new features yet to come.

Moderator: PPS-Leaders

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Major Clean-up

Post by beni » Sat Feb 03, 2007 1:26 pm

We started a clean up with the data already. Launched by Nowic, we made a data-trunk with only the data we used for our presentation version of Orxonox. Of course we will never discard any data just like that. Some data we are not allowed to use of course, because we are bound to licenses and copy ights, but anything else will be stored somewhere for a day in the future when we can use any of it.

What we did with the data should also be doable with the code, a lot more difficult though. I'm not talking about unimplement old features we're not using at the moment, but there are code segments which are so old and have never been used again, but are still compiled. Those parts of the code, sometimes use the processor to do something we don't need at all.
One example would be the track system. It's very old and we haven't used it in one year.
My suggestion is to take out code we don't use and to document the stuff left.
This requires a major review of most parts of the code of Orxonox.

I know something like this is not really fun to do. Also it needs a lot of time. But there are a lot of good things. Since Patrick and Bensch won't be leading a PPS next year (if there will be one) the new leaders of the PPS should know a lot about Orxonox. So while doing this review we learn a lot more about Orxonox.
Also we will be able to document our project. This includes doxygen (which is really out of date) and Wiki-pages. This will help other developers to understand Orxonox better and faster.
Next to our understanding of the code and the documentation of the project, there is one more advantage: While reviewing the code, we can alter it to work more efficiently.

I suggest we do this review over the holidays between and after the exams. The job is not really difficult because we won't have to change a lot of code and have to think of new ways to implement a feature. What we do is: Learn how the core of Orxonox works and probably find ways to make Orxonox work faster. We take out redundant and old code and make a good documentation of the rest.

Before I think of ways to achieve the goal in a good way I'd like to hear your opinion on this matter.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
Nowic
Thanathon, God of the lower Planes
Posts: 186
Joined: Tue Oct 03, 2006 7:53 pm
Location: Zürich
Contact:

Post by Nowic » Sat Feb 03, 2007 5:24 pm

It's a good idea!
What I want to add: There are some files where the copyright, the license text (GPL) and the autor(s) are missing. For example medium_blaster.cc and light_blaster.cc. We should fix that too and tell the students in the next pps to include them.
"I've always lived cheaply. I live like a student, basically. And I like that because it means that money is not telling me what to do. I can do what I think is important for me to do. It freed me to do what seemed worth doing." -- Richard Stallman

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Sat Feb 03, 2007 6:56 pm

Nowic wrote:It's a good idea!
What I want to add: There are some files where the copyright, the license text (GPL) and the autor(s) are missing. For example medium_blaster.cc and light_blaster.cc. We should fix that too and tell the students in the next pps to include them.
Okay, I haven't seen that. And you're right: We gotta change that.
"I'm Commander Shepard and this is my favorite forum on the internet."

silvan
Noxonian Brolghormeg
Posts: 37
Joined: Wed Oct 11, 2006 7:43 am

Post by silvan » Sun Feb 04, 2007 9:04 am

Getting to know the framework by writing documentation is certainly a great idea. It will help not only us to understand the code, but it will also make things a lot easier for those who follow. (i.e. our PPS-Students)

The hardest part is to distinguish between the necessary and the unnecessary code. Since we are not perfect, we will introduce bugs while cleaning the code.
I suggest we do the cleanup in a seperate branch together with the documentation.
The light on the end of the tunnel is a train.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Sun Feb 04, 2007 11:34 am

Okay. I think the idea is more or less accepted.
silvan wrote:The hardest part is to distinguish between the necessary and the unnecessary code. Since we are not perfect, we will introduce bugs while cleaning the code.
I suggest we do the cleanup in a seperate branch together with the documentation.
That's true and I think that the cleaning up shouldn't be aggressive at all. If you want, you can start a clean up branch right away.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
patrick
Baron Vladimir Harkonnen
Posts: 350
Joined: Mon Oct 02, 2006 6:03 pm
Location: Bern

Post by patrick » Sun Feb 04, 2007 10:51 pm

I will be there to answer your questions. And I will also help cleaning up some stuff. I think I will focus on more complex modules like the GUI that bensch has started but not finished.
If I am able to understand the GUI code completely, I will try to finish it. Without finishing touches, it won't be very helpful....

User avatar
bensch
Admiral Alexi Sarkhov
Posts: 101
Joined: Tue Oct 03, 2006 2:28 pm
Contact:

Post by bensch » Wed Feb 07, 2007 2:08 pm

I am not totally finished with orxonox yet :D
So maybe there will be a rush of emotion, and I finish the GUI myself.
I do understand, that it is no use to pass the development of the entire GUI to another person.

But there are also some questions on the most important topics:

1. Boxes and GUI-layouts:
For all those who used the GUI here a question about how Gui-Elements should be scaled
a) Pack all the Widgets into a Special Layout like Qt::Layout
b) Pack all the Widgets into Special Boxes-Widget, and the boxes scale themselves

2. Most Important Widgets
What Widgets do you think are most important. These Widgets will be updated. My suggestion:
a) Layout
b) PushButton
c) TextLine
d) CheckButton
e) TextElement

3. Rotation: How should a Widget that is rotated be packed into the layout.
a) with the sin/cos rotated Size
b) Normal as before (x-size stays as x-size)
c) some other more intuitive method.

Thanks for any advice

nicolasc
Baron Vladimir Harkonnen
Posts: 258
Joined: Wed Nov 01, 2006 7:58 pm
Location: your mind
Contact:

Post by nicolasc » Wed Feb 07, 2007 3:43 pm

Wow.... Finally somebody came to his senses :D

To be honest, a code cleanup is more than appropriate. I haven't done much in that direction, but from what I've heard from Marc, some parts are quite a mess (mostly speaking of multiple implementations of the CR)
Nowic wrote:What I want to add: There are some files where the copyright, the license text (GPL) and the autor(s) are missing. For example medium_blaster.cc and light_blaster.cc. We should fix that too and tell the students in the next pps to include them.
I know, I know... This is also a problem of copy/pasting things... I might be a good idea to create handout for programmers, as there is for modelers: A few Dos and Don'ts, and some reminders (fix file author, add docu including how). There are tons of nice keywords/tags (e.g. TODO, FIXME...), which just wait to be used.
Silvan wrote:The hardest part is to distinguish between the necessary and the unnecessary code. Since we are not perfect, we will introduce bugs while cleaning the code.
I suggest we do the cleanup in a seperate branch together with the documentation.
Count me in! I started cleaning up the mess I left behind.

Cheers
nico
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Post by beni » Wed Feb 07, 2007 5:57 pm

Thanks bensch for the short explenation how to handle the GUI. I never worked with it, so I cannot give you any advice on it.

I'm that my idea for the clean up is accepted so easily and that all of you want to help with it. I thought a lot of people wouldn't like the idea because it looks like work, the results are rather not so spectaculiar and also time consuming.

We'll definitely work on a branch of the current trunk to make this clean up. Yet I didn't think about how to work on this. Question which have to be answered are the following:

1. Who does what? How do we determine which part of code is best to review by whom?
We don't want to review code twice or that one person doesn't get his piece because he has to look on other code to understand.

2. What parts of the code have to be reviewed?
I guess not all parts of the code need a review, because they are either very well documented and very efficent implemented. We also do not have to review the libraries of course.

3. How far do we go with our changes?
Reimplementation? Just documentation even if the implemented stuff is stupid? What are we going to do with the stuff which is commented out? Clean it out? Save it somewhere?

I'm happy to hear any suggestion on how we can do the clean up in the most efficent way.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
bensch
Admiral Alexi Sarkhov
Posts: 101
Joined: Tue Oct 03, 2006 2:28 pm
Contact:

Post by bensch » Wed Feb 07, 2007 7:31 pm

1. Who does what?
The best thing is to write Tickets for everything that must be done. This is already done partly, but can be even more extended. Like this the people that are interested in fixing a topic are working on it.
Even if people are not interested, it is important to fix the most important glitches.

I suggest, that we make a special Milestone, where the topics are ordered by magnitude of interference with the current goal of Orxonox.
How do we determine which part of code is best to review by whom?
I for my part will fix some GUI issues, if they arise, and are really dramatic. Then Patrick told me, that there are problems with the ClassID and some strange update-phenomena with the PNode implementation, as it is a delayed mechanism.
2. What parts of the code have to be reviewed?
In my opinion there is the following rule to review code:
1. Segfault -> MUST REVIEW
2. HACK/FIXME -> look through them, check and resolve
3. TODO -> if it is minor, leave it. If it is mayor write a Ticket
4. Remove Unused Functions -> As described by nicolas as the CR-overload
5. Code Extensions -> Make the GUI better and stuff...
3. How far do we go with our changes?
As far as we have to to make everything work as we want it to.

I think for a clean-up it should also be considered to make some sacrifices, and deleting long unused objects and functions such as the obsolete Rotation, Animation-classes the tList and everything else marked as OBSOLETE

User avatar
patrick
Baron Vladimir Harkonnen
Posts: 350
Joined: Mon Oct 02, 2006 6:03 pm
Location: Bern

Post by patrick » Wed Feb 07, 2007 8:26 pm

We got the speed guys!

As bensch said:
As far as we have to, to make everything work as we want it to.
That's the music! Let's also define a time frame for this operation: We should try to get all the cleanup done within our holidays.
The best thing is to write Tickets for everything that must be done
I think it's lots of pre-work but it surely is worth to do this since it will give a good overview for everyone of what needs to be done. So let's organize it like this - in several phases:

PHASE 1
Collecting problems, segfaults, renicements, features requests and plan our activites.
  • a ticket for each module
  • and a ticket for every new feature request
  • as bensch said: Let's add them all under one milestone
  • persons that like to work on a ticket subscribe to it with their name
PHASE 2
The actual cleanup itself.
  • the persons need to create/update a wiki docu page for every module they work on. I will create a template wiki page for this.
  • for each module: the doxygen documentation need to be updated, a link needs to refer to the wiki page on the web
  • for each module: the code has to be reformated (e.g: indentation), compiler warnings removed, unused code cleaned out.
  • for each module that is worked on a new branche will be created, after cleanup the branche needs to be tested to be sure, that no new bugs have been introduced.
Cleaning up a framework always gives me a nice and cosy feeling :D
so let's take it down!

User avatar
patrick
Baron Vladimir Harkonnen
Posts: 350
Joined: Mon Oct 02, 2006 6:03 pm
Location: Bern

Post by patrick » Wed Feb 07, 2007 8:32 pm

Let's make Phase I + Phase II in parallel since we already have started cleaning up :D

User avatar
bensch
Admiral Alexi Sarkhov
Posts: 101
Joined: Tue Oct 03, 2006 2:28 pm
Contact:

Post by bensch » Wed Feb 07, 2007 8:45 pm

Added milestone CleanUp.
Puh... look at the "Due" Date... it's only one month to go :shock:

User avatar
patrick
Baron Vladimir Harkonnen
Posts: 350
Joined: Mon Oct 02, 2006 6:03 pm
Location: Bern

Post by patrick » Sun Feb 11, 2007 5:45 pm

I added many tickets to the cleanup milestone. Choose a topic, subscribe to it and resolve it.

gg hf!

User avatar
bensch
Admiral Alexi Sarkhov
Posts: 101
Joined: Tue Oct 03, 2006 2:28 pm
Contact:

Post by bensch » Sun Feb 11, 2007 5:52 pm

Yeah, that's what I am talking about :)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest