Code center > Darwinbots Program Source Code
C++ refactoring
frankle:
--- Quote from: Numsgil ---Pretty soon I'm going to be placing the VB and C# code into SVNs along with the C++ code (which already is), so all the code will be in the same place. Then it should be pretty easy to look at changes to any of the code.
--- End quote ---
I <3 SVN, I use it for everything. Well, not everything... but you know what I mean.
Numsgil:
"It slices, it dices, it makes julian fries."
Jez:
Your 2c is always welcome, I'm not a programmer so I hope you don't mind if I ask whether, as it seems, you have relevant skills in this field and whether you are considering playing a part in this project.
--- Quote from: frankle ---I'm curious at this point why the VB fork hasn't been feature frozen?
Lastly, documentation is ABSOLUTELY ESSENTIAL to fostering community involvement.
--- End quote ---
My little potted history on DB programing,
First created by Carlo, PY took the banner and teaching himself VB made many improvements to it, next came Nums' who has now been sidetracked by the C++ transfer and finally Eric who has been a bit of a superstar when it comes to addressing problems and new features in the current program. (My appologies to anyone I've missed, I know other people have taken an active part in fixing the code and I have only watched from the sidelines.)
Firstly, I think the VB fork hasn't been frozen because the C++ idea is a 'figure in the wings'. It would seem wrong to many peeps that a proto-idea, that hasn't been implemented yet, stops the DB program evolving. I totally agree that the continual evolution of the program will create inumerable problems for Nums' but until the C++ project is 'ipso facto' it remains a pipe dream for many of us. All credit to those to whom it's due, but all the programming is done by volunteers when and if they can make the time available.
Secondly, documentation, the Wiki part of the forum is scarcely more than a out of date guide to DB, if people, including me, had more time to spend creating documentation for the program or less important parts of DB to address, then I'm sure it would be done. Instead, as DB is always a work in progress and generally designed/modded by one person at a time, the documentation comes last. Often only added because of questions from someone else.
If you can sketch out a plan for how we might get programmers working in symbiosis, something we have been trying to achieve with the bots as well for quite a while, then I am sure Eric would be happy to consider it, after all it might lighten his workload and allow him more time to play with the program rather than just fix and amend it.
EDIT
and Nums' got there before me...
Numsgil:
I think getting the VB source into an SVN will allow simoltaneous efforts. Originally, when I first joined, almost all of the code was in a single file. It was almost impossible for two people to work on it at the same time.
As Jez says, until there's a real and finalized final product for "the next generation", people are going to want smaller bug fixes for the VB source. And it's almost impossible to fix bugs in DB without adding features
EricL:
Here's my $0.02.
The first 90% of a software project takes 90% of the time. The last 10% takes the other 90% of the time. While the current C++ may limp along and almost certainly has many architectural advantages over the VB source, I predict many months of stabalization ahead just to get it to the level of the VB source w.r.t. day to day usability much less feature set. Just take a look at the topics in the bug forums for the last 6 months. 2.4 was working pretty much when I came on board. I've made hundreds of bug fixes since then and we don't even have everyone off of 2.37.6!
In my experience, the way to port code is to take baby steps and change as few things as possible at any point in time, maintaining or at least recapturing stability at each stage before embarking upon the next. People have to be able to use the code at each stage and you don't dare go too long between stable, usable versions. In particular, changing programming languages and making major architectural changes at the same time is a sure reciepe for instabiliy and discouragement.
Don't get me wrong. I'm all for porting to C++ or C# (though I make arguements below against many of the reasons put forward for doing so). Hell, I used to teach C in grad school and most of my own recent work has been in C#, so I'm all over moving to one of those languages. But IMHO, the proper way to go about it is as follows:
1) Move the current VB source into a source code management system. I'm happy to have people help or add features if there is a structured way to do it.
2) At some point, agree to freeze at a certain version where the only changes tot eh VB version from that ponin forward are major bug fixes which must get checked into both forks from that point on until the VB version is suplanted and obsoleted.
3) Do a staight across port to C# or whatever with absolutely no architectural changes. I mean none. Get it stable first. We use the same lousy data structures, the same update loops, all in a single thread. No getting nuts with classes and methods and all that crap. Straight across. I'd even suggest we fake out some of the VB methods like Circle() to preserve the investment in code at least for the initial port. We get it stable and usable and everyone using it before we make ANY major architectural changes. This includes threading. The current architecture will be easy enough to thread where it counts when the time comes.
4) We make architactural changes bit by bit, gaining stability back each time we do something major. This is where Num's work on his C++ fork becomes very useful. It's a prototype, a proof of concept demostrating many new archtiectural concepts and a new set of physics. We take what we want, bit by bit, but we start from the current VB source instead or I predict we will have a very long climb to get stable.
An alternative order would be to back port some or all of Num's new physics into the VB source before freezing and porting.
Now, my $0.02 would not be complete unless I pointed out that a port is a lot of work. A lot of work, a lot of sideways work. We have to be very very sure we want to do it and we want to be very very sure of the reasons why we are doing it. Let me play devils advocate for a moment. Why do we want to do it? So we can have multiple code authors? We can do that on the VB source by moving it to SVN or some other source code management system. For performance reasons? Don't be so sure. I could probably double the perfromance of the current VB code with a couple of weeks of focused work without losing stability. If perf is the main goal, some serious profiling and code reviews would reap more gains for less pain. For scalability across multiple CPUs? Yes, VB is single threaded, but DB is processor bound and does basically no I/O. That one thread is always busy, making maximum use of a single processor. You think moving to multiple threads will speed things up? Not on a single processor machine it won't. All else being equal, the added context switching will slow it down on single proc machines by maybe 10% or so. Got a dual core box you say? Use teleporters, run two connected sims and utilize 100% of both processors. Don't get me wrong, I love theads. Hell, I even like fibers when used right. DB would love threads and scale well, but only on machines with the processors to take advantage of a threaded architecture. Better physics maybe? Look, code is code. If you want elastic collisions or bouncy walls, back port the algorthims. Moving to a differet programming language is no panacia. It's the algorthms that count, not the programming language as far as physics go. Separating the UI from the engine? Future client-server versions? Graphics packages? All good stuff and admittably, harder to do from VB. But we need to be realistic about why we are porting. Those things are nice, but not near term and not the first reasons many people site for porting.
Okay, all that said, I'm still all up for porting to a 'better' language or at least a newer version of VB (with threads). I just want us to do it with our eyes open. It's a lot of work.
EDIT - Oh, I should point out we will take a perf hit with C#. Managed code is wonderful, you don't have to worry (as much) about memory leaks and such, but the garbage collection costs you maybe 10% on the client.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version