Currently the JOODE SVN is not compilable. In the class net.java.dev.joode.metamorphic3D there’s the class net.java.dev.joode.util.ROVector imported and used. But referring to the SVN log this ROVector never existed. There’s only an ROVector2 class, which unfortunately doesn’t fit the requirements of ROVector. I was not able to get get reason for this bug nor the “author” from the SVN log.
@tom: Could you maybe have a look at it and fix it? Would be very cool.
Marvin
Hmmmm. I can’t access the subversion repository. ROVector is a superinterface of Vector, that has the float get(int) method defined. Earlier version of Vetor had the get and set interface methods defined in it. ROVector = Read only vector.
I will try and fix as soon as possible
In fact, I had added it since a few days, but forgot to commit.
It’s fixed now.
OK. I have committed all my latest stuff. Phew, turned out sourceforge have stopped supporting the old style of SVN access which my intelliJ system uses, and its a right pain switching once the project has been created. There might be glitches still, but keep me posted of any compilation problems and I will hand fix them.
Tom
Thanks, Tom. Thanks, Amos.
Hey
you changed exactly the correct files 
Marvin suggested to port joode code to the OpenMali vecmath lib (which also has MatrixNxMf and so on). So I started rewriting joode to that math-lib. But you exactly didn’t change the files I already changed very neat
about that ported joode code, should we put it in a seperate branch first? It’s simply loads of methods have different parameter orderings, so there might be bugs after the port. (Even while I’m trying to be extremely careful) + I could upload my changes too…even if it doesn’t compile yet.
Arne
Hey, Tom. Is it possible, that you forgot to commit the SegmentControllorFactory class? It is missing and JOODE therefore still doesn’t compile.
Marvin
ok - don’t bother overwriting files I already migrated to joode, because I think we will do that again, when we know on which things we have to pay attention to. I already found some really nasty differences, I probably didn’t pay any attentions at, when migrating the previous code.
The current list of differences can be found in doc/openmali-migration.txt.
Non the less, I will try to keep on doing the test migration, because there still will be nasty stuff with all that pointer thingies.
hmm - Tom, I think the next big thing in joode will be the migration to openmali. Marvin proposed to make a release before that, I think that’s a good idea, because then we can redirect everybody to the release, while we’re have time to modify the complete code, which will definitely make the code uncompileable for some weeks. Another idea would be to have an universal wrapper, so the code doesn’t brake and we can test all the changes we make, or which allows parallel execution of the old and new part, so errors get auto-detected.
Factory class is in there now. Aopologies for leaving it out. Things got a little tricky when I had to change the svn access URL.
Yeah, maybe we should move to openmali soon, I will commit a month or something to refactoring after I get this damn report in. I see its LGPL. That is good. I think I would like to port some code from MTJ. I can’t put it in JOODE, but openmali could accomidate the it.
We should probably try and coordinate the porting effort as much as possible. I will notify you when I get time (probably in about 2 weeks)
Tom
Hey, no problem.
Please tell me, when you want to start committing things to OpenMaLi. I will grant you dev-access to the project then. I think, it wuold also make sense, if you would PM me your Jabber or ICQ account, so I can explain you all the necessary things about OpenMaLi and we could better coordinate our work.
Hey, maybe you want to follow this thread.
Marvin