|
prj
|
 |
« Reply #15 on: January 17, 2012, 12:33:13 PM »
|
|
|
As a c/c++ guy its always driven me crazy that you can't build dependency information for java files. And ant is a mess.
Dependency information? Maven does that or Ant in conjunction with Ivy. Ant is no more a mess than a shell script. It's just an alternative for a shell script. So yes, you can have dependency information for Java libraries, the entire world does that all the time. Also, the IDE and the build system are not connected together. You are stating these things as facts, even though they are not true - know thy tools. Anyway, this discussion has no place on this forum. Sorry for slightly criticizing your work. My main concern about an IDE was that your code was not formatted/organized to conventions, so it made it hard to read, but if not for your code, I'd have to code it from scratch. This would probably take me quite a bit more time than the 6 hours it took to put this together with your stuff as reference, so thanks for that, your code was useful. |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #16 on: January 17, 2012, 12:39:59 PM »
|
|
|
I'm open to suggestions. What formatting changes would an IDE fix?
Also, I'd welcome patches (or a whole new repo) for both an ant/ivy build system, or maven system. Like I said, I'm a c/c++ guy who uses makefiles, and rarely uses windows to do any building, since cmd.exe is a joke, and cygwin is a fat bloated slow mess.
Also, I'd like to extend it to be able to output the "new" (xml) format xdfs.
Please consider putting your source under github or something similar so I can take a look.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #17 on: January 17, 2012, 12:43:23 PM »
|
|
|
Will do soon.
Also, I made an XDF XML writer before in Java.
I think we can take large chunks of that and re-use it.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #18 on: January 17, 2012, 05:54:38 PM »
|
|
|
I got it generating XDF XML's now. I need to make it generate tables for axes as well and link them to the tables. Everything else works. It also makes a single jar using this: http://code.google.com/p/onejar-maven-plugin/I'll try to finish this tomorrow, and will post the source up. I'll lack folder support at start, so that'll have to be done as well... I don't want to post something completely half baked that does not work properly, it at least needs to take a .kp and output a usable .xdf from it. I am thinking to just output the .xdf to stdout and let users redirect it to wherever they want. It wouldn't be really doing anything that your parser isn't doing now though, aside from having perhaps a refactored codebase, which is not really all that relevant. |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #19 on: January 17, 2012, 06:12:25 PM »
|
|
|
Don't forget to swap axis for tables with >256 columns... tuner pro still crashes on those..
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #20 on: January 18, 2012, 03:01:05 AM »
|
|
|
Don't forget to swap axis for tables with >256 columns... tuner pro still crashes on those..
I know, don't worry  |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #21 on: January 18, 2012, 07:59:09 PM »
|
|
|
Probably should make a separate thread for it, but: https://github.com/prj/me7-toolsmvn install (or mvn package) to build it. You need Maven 3. one jar plugin will tell you where it has generated the jar, just run with java -jar path/to/jar path/to/kpfile. This stuff is pretty basic atm, it needs folder support, all the axes need to go into one category in tuner pro, it doesn't really support inverse stuff, doesn't support non-eprom stuff etc. But it generates an XML XDF, and from here it's just some polishing to do, as the basic framework is in place. |
|
|
|
|
Logged
|
|
|
|
|
s5fourdoor
|
|
« Reply #22 on: January 19, 2012, 12:21:41 PM »
|
|
|
dope thread. subscribed.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #23 on: January 19, 2012, 12:23:36 PM »
|
|
|
I'll try to add folder support tonight. But so far not bad for 2 days work  |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #24 on: January 19, 2012, 01:26:42 PM »
|
|
|
Thanks!
Looking forwards to checking it out (pun intended) time permitting.
A few other features from my program you might want to look into
1) CSV output of tables
2) feature to read in a binary to generate max/min values for CSV output so you can compare various values from different boxes (e.g. KRKTE from RS4 vs S4 etc)
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #25 on: January 19, 2012, 01:52:34 PM »
|
|
|
Thanks!
Looking forwards to checking it out (pun intended) time permitting.
A few other features from my program you might want to look into
1) CSV output of tables
2) feature to read in a binary to generate max/min values for CSV output so you can compare various values from different boxes (e.g. KRKTE from RS4 vs S4 etc)
I don't really want to rewrite your whole tool. I'm not going to add CSV support, I have no need for it personally, and it'd take a bunch of my time. It's open source though, so if you want to re-use my code, you always can. Or I can give you committer if you want to try working on this as well. As for comparing values - that little compare program I made does that for me and outputs the differences. I'll have to go through every change it found manually and learn about everything anyway. I can speak German fluently, so that helps. I'm very familiar with tuning, older motronics, ASM, etc (more than 100 cars tuned at this point), but I am just starting with ME7. So I am just developing the tools I need. Because this forum has a wealth of knowledge, I feel it is correct to contribute back, and not do this quietly. |
|
|
|
« Last Edit: January 19, 2012, 01:54:33 PM by prj »
|
Logged
|
|
|
|
|
prj
|
|
« Reply #26 on: January 19, 2012, 02:12:50 PM »
|
|
|
Btw, another thought...
Since we have the English funktionsrahmen for ME7.3, and some acronym definitions, what about including a filter on parsing the map pack, and then looking up the map names in a sort of dictionary file?
So we could have an English dictionary file, and any map ID's that match it, would automatically be translated?
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #27 on: January 19, 2012, 02:36:26 PM »
|
|
|
Or I can give you committer if you want to try working on this as well.
no need, ill just make another github repo and send pull requests for stuff i think you might find useful. I've been meaning to separate out the mesim tool from ecuxplot anyway. This would be a good excuse. Because this forum has a wealth of knowledge, I feel it is correct to contribute back, and not do this quietly.
helllll yea. thank you. btw im looking forwards to learning how to properly architect java projects from you (again, since im a c/c++ guy). hopefully you'll be kind enough to mentor me (at least with the maven/ant stuff). I have a TON of questions about dependency based building, and ant/maven still don't seem to do what (for example) gcc -M does |
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #28 on: January 19, 2012, 04:16:06 PM »
|
|
|
I think Maven should do most of of the dependency stuff you'd need.
Just need to use it more I guess. It's all pretty daunting at start.
I do C/C++ myself as well, but I am not as good at it as I am at Java. I don't see the use of trying to enforce the habits of one language on another though.
The majority of the world is pretty happy with using Maven. If you check my project you can see an example where I have separated out the module for parsing the map pack, which is not executable by itself (it's just a library) and added another module, which depends on the map pack parser and actually generates an executable jar that emits XDF from the parsed map pack data.
In a broad way of thinking a maven module project can be something like the gcc -M that you are used to, but it is different as well.
I also used JAXB for XML generation, instead of printing strings or DOM. Maybe something of interest as well.
You could easily make a CSV creating module, which depends on my map pack parser for example. Though, I would need to set up a repository for it, if you wanted to do it separately outside the multi-module project, so that it can pull it down automatically.
Anyway, you could indeed use my codebase as an excuse to separate ecuxplot from the rest of the stuff.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #29 on: January 19, 2012, 04:19:54 PM »
|
|
|
Oh and as for setting up Java projects. Take a look at my code, it should give an example of how to do all this.
Most of the config files (pom.xml) are auto generated by the IDE though, there's very little work done by hand.
|
|
|
|
|
Logged
|
|
|
|
|
