t_larkworthy, could you clean up the feature requests on the Sourceforge page. I think that except of the trimesh request the requests are not appropriate anymore.
the testcase looks ok
it should slide down on the slider, right? What is happening?
The box is “jumping” out of sight within two or three iteration steps.
The tasks are now moved from the webpage to Sourceforge.
OK, cleaned up feature requests. Subversion migration has failed, and I have run out of time tonight to try and get it working. Will have to wait till the weekend I am afraid, as I am going on a team building exercise for 3 days 
Speak to you all soon.
Tom
Could you please make an announcement before you migrate to Subversion. I think it will take some time until the code is moved to Subversion. I do not want to have code changes I have to merge afterwards.
Another thing I’d like to know is what is your idea of how JOODE will go on. You are the project leader and administrator, but I see no directions from your side how JOODE will go on. Since I have joinde JOODE only arne and me are really working on the project. I am afraid JOODE will get stuck, as long as no one will have the ambition and vision in getting JOODE on. We need directions in this project.
yeah fair comments. I am just trying to finish off a masters at the moment before starting my PhD in Sept. I will be using JOODE for the PhD. Since Chrismas I have been really busy doing other stuff. So all I can say is bear with me for the time being. Anyways, exams are over. Most of the labour intensive elements of my course are over, I will be doing an image proccessing Summer project requireing a certain amount of programming effort but I plan to split my time between JOODE and that. I am also about to quit my part time job to give me a bit more time to play with.
I said when I started this project I could commit 5 hours a week to it. I put in alot more than that initially but since Jan I have not done anything. I will be getting back to that minimum figure imminently. I am going to Berlin next weekend though :-\ … so I am about to do a few hours now and maybe not a full week next week but should be back in full swing the week after.
I did say I was planning to do the Subversion switch on Tue, but as it happened it did not work. Sourceforge have not got their migration from sourceforge repository feature working yet so I will wait for that.
I need to see how everything is working at the moment before I can really say what direction things should go. But my current gut feeling is that we have plenty of features, enough for a version 1 release. So what needs doing is:
Make sure all the users methods have javadoc’s.
Make sure there is methods for everything that is expected to be interacted with, (so no direct interaction with the force accumulator, for instance).
Intergrate the properties system with the code flow. i.e. which step method that should be used should be chosen via the properties file etc.
Write a logging system. I don’t like extra dependancies like log4J. I am thinking something very simple. Maybe 3 levels, which all require the C style IO. (to avoid string concatinations)
Bigger things that need a bit more discussion are general architecture improvements. I was mentioning this at chrismas. I think it would be good if we could have an interceptor pattern for step events on Bodies and contruction of bodies and geometries etc. This will allow extra simulation behaviours to be snapped in easily. We could even refactor some of our existing ones out like gravity.
Anohter thing we should be thinking about is profiling. I am open to suggestions on a stratergy for this. I don’t have much experience of proper profiling. AOP seems like a good general purpose maintainable solution.
I am gonna catch up on the code base now…
That’s right. But there is still a lot of work for a release. I already mentioned some time ago that I want to do a release, but there are still too many open things that should be finalized before we can have a release. I tried to add some to the tasks already. A roadmap would be fine, so if someone is willing to do something he can find subjects to do in a list.
All that is not that important for a release. The only really relevant thing for a first release (let’s call it 0.5 before doing a 1.0 release) is that the code is stable und working. The API should not change dramatically anymore and of course everything must be working. And that’s where I see the problems for a release right now. The API is not stable and I still have problems getting everything running. As soon as I start implementing more complex applications the physic system is exploding.
Why not use the JAVA logging API? I would really discourage from an own logging API.
Yeah, I’ve got lots of ideas as well. But let’s get the current code clean and running and it should be no problem to make improvements in the future.
Sorry if you find this junk but I agree with t_larkworthy. The Wine project (http://www.winehq.org) do has a lot of feature and yet they began their X.Y numbering with 0.9. They’re actually at 0.9.14 (which I’m actually upgrading to). A 1.0 release is not a small thing, see ODE which is still at 0.5 !
[quote="<MagicSpark.org [ BlueSky ]>,post:29,topic:27244"]
Sorry if you find this junk but I agree with t_larkworthy. The Wine project (http://www.winehq.org) do has a lot of feature and yet they began their X.Y numbering with 0.9. They’re actually at 0.9.14 (which I’m actually upgrading to). A 1.0 release is not a small thing, see ODE which is still at 0.5 !
[/quote]
If you read the whole mail you will see that I suggest to start with 0.5 before heading towards a 1.0 release.
Hmmmmm. So don’t worry about changing anything then. We need some real tests that actually predict what the results should be rather than just eye balled tests. Some proper JUnits for instance. Thats gonna be hard to come up with becuase all the intergration is not a precise art.
Anyway, I will just start attacking the tasks you have up at the moment then as you are more in the code than I for the time being.
Most important thing would be, that you migrate the project to Subversion. We need this for repackaging. Otherwise we will not be able to change the visibility of fields. Would be nice if you get this done 
Hmmmm, its kind of difficult to get working. I have tried. Get your code up in CVS. At the very least I can just put in the existing code as is. We lose our change history, but I do not think that is very important anyway.
I will upgrade to subversion one way or another by the end of the day 2morrow (Wed)
goes ok with me
OK, I won’t do any changes until we are on Subversion
What is the problem with the migration? Are you using this page https://sourceforge.net/project/admin/svn_migration.php?group_id=151965?
Oh wow, the migrate directly from CVS on sourceforge option is now available. It wasn’t when I tried earlier. I made my own CVS tar ball but that failed. Looks like you allready tried the direct method and it has also failed.
Anyway I will just upload the source tree fresh. Should be easier that debugging what when wrong without any kind of error messages from the server.
STOP!!! Please try to keep the history, it could be useful if we looking for bugs. If you just delete the history we could have made all changes to CVS as well.
If you have any problems wioth importing the history please tell me and I will try to help you. I can provide an archive containing an SVN dump of JOODE. This should be the prefered way of setting up an Subversion repository.
By the way. Do we really need the ODE code in our porject? It seems to be quite old. I would prefer to put a pointer to the ODE repository containing the latest code in the project.
OK. Have not moved to Subversion yet. Yeah this is the problem. I can’t get any of the instructions to work for migrating the CVS repository in the proper fasion. Have not tried a SVN dump yet. Can you send me one (I think you have my email)
[quote]By the way. Do we really need the ODE code in our porject?
[/quote]
Its all the ODE code in a single directory for easy browsing. By taking a snapshot in time at least I know everyone is porting the same version. Trying to port a dynamically changing source tree could potentially be difficult.
Well, the compressed file still has a size of over 6MB. I will put the file on the shell server, where it has to be for the import anyway.