Major Clean-up
Moderator: PPS-Leaders
Major Clean-up
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.
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."
- Nowic
- Thanathon, God of the lower Planes
- Posts: 186
- Joined: Tue Oct 03, 2006 7:53 pm
- Location: Zürich
- Contact:
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.
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
Okay, I haven't seen that. And you're right: We gotta change that.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.
"I'm Commander Shepard and this is my favorite forum on the internet."
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 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.
Okay. I think the idea is more or less accepted.
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.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.
"I'm Commander Shepard and this is my favorite forum on the internet."
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....
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....
I am not totally finished with orxonox yet
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
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
-
- Baron Vladimir Harkonnen
- Posts: 258
- Joined: Wed Nov 01, 2006 7:58 pm
- Location: your mind
- Contact:
Wow.... Finally somebody came to his senses
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)
Cheers
nico
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)
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.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.
Count me in! I started cleaning up the mess I left behind.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.
Cheers
nico
BOFH Excuse #212: Of course is doesn't work. We've performed a software upgrade.
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 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."
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.1. Who does what?
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.
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.How do we determine which part of code is best to review by whom?
In my opinion there is the following rule to review code:2. What parts of the code have to be reviewed?
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...
As far as we have to to make everything work as we want it to.3. How far do we go with our changes?
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
We got the speed guys!
As bensch said:
PHASE 1
Collecting problems, segfaults, renicements, features requests and plan our activites.
The actual cleanup itself.
so let's take it down!
As bensch said:
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.As far as we have to, to make everything work as we want it to.
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:The best thing is to write Tickets for everything that must be done
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
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.
so let's take it down!
Added milestone CleanUp.
Puh... look at the "Due" Date... it's only one month to go
Puh... look at the "Due" Date... it's only one month to go
Who is online
Users browsing this forum: No registered users and 1 guest