Main > Software Forum
Aaron removes xml2info as of u12 (in other words, we are screwed)
<< < (3/16) > >>
krick:
Ok, I've got something working.  It's not optimal but it should get people at least playing games.  For the moment, I had to hard code input control to "unknown".  Eventually, I or someone else will figure out how to get correct data in there but for now, this is probably the best to hope for.  Enjoy...

http://mame.3feetunder.com/xml2info/
Howard_Casto:

--- Quote from: krick on July 16, 2006, 11:39:35 pm ---
--- Quote from: Howard_Casto on July 16, 2006, 11:24:09 pm ---Even so every other parser I try seems to have some issue with listxml.  I found one that works, but it's a manual parser, so it should. ;)

--- End quote ---

If you find parsers that complain, let me know what they complain about.  It's probably something legitimate that needs to be fixed.

--- End quote ---

I wouldn't know what to tell you.  They don't error out, it's just the parsers choke or enver finish ect. 

 :soapbox:
I think the abandonment of the listinfo format (regardless of how horribly flawed it is) is a mistake. 

The xml format is very simple and easy to understand, the xml parsers available aren't though. 

The list output is supposed to be for fe develpers right?  Then why in the world is the xml format used?  Aaron has to remember, most fe programmers are just hobbists. We shouldn't have to learn a whole new language just to interface with mame.  Xml is exteremelly difficult to parse with some of the older languages, even with tools (msxml, sax, whatever).  After looking at my choices that work with vb6 I am rather dis-heartened.  The official m$ stuff is so convoluted with all of it's classes and sub-classes that it takes knowledge of sql-like queries necessary even for looking up something as simple as a sub tag.  Most of the parsers I tried simply can't load the entire listxml output which is essential as front-ends need to load all the data and convert it to whatever type of list file they use.  The ones that did work took an hour to load it.  And I'm not exaggerating, I mean a whole hour. 


Your efforts trying to fix xml2info are appreciated, but the real solution (as it'll be hard to keep up a converter not officially in mame) is to get everyone off this xml kick and have mame output a real format.  What's wrong with ini files?  The ini format is easy to parse both manually and with help.  It's ascii too, the only difference is the lack of sub-nodes which aren't really needed in mame anyway.  Also it is rather small compared to xml.   

Xml is meant for tiny little storage files, not huge databases like mame generates.
krick:

--- Quote from: Howard_Casto on July 17, 2006, 01:02:40 am --- :soapbox:
I think the abandonment of the listinfo format (regardless of how horribly flawed it is) is a mistake. 

The xml format is very simple and easy to understand, the xml parsers available aren't though. 

The list output is supposed to be for fe develpers right?  Then why in the world is the xml format used?  Aaron has to remember, most fe programmers are just hobbists. We shouldn't have to learn a whole new language just to interface with mame.  Xml is exteremelly difficult to parse with some of the older languages, even with tools (msxml, sax, whatever).  After looking at my choices that work with vb6 I am rather dis-heartened.  The official m$ stuff is so convoluted with all of it's classes and sub-classes that it takes knowledge of sql-like queries necessary even for looking up something as simple as a sub tag.  Most of the parsers I tried simply can't load the entire listxml output which is essential as front-ends need to load all the data and convert it to whatever type of list file they use.  The ones that did work took an hour to load it.  And I'm not exaggerating, I mean a whole hour. 


Your efforts trying to fix xml2info are appreciated, but the real solution (as it'll be hard to keep up a converter not officially in mame) is to get everyone off this xml kick and have mame output a real format.  What's wrong with ini files?  The ini format is easy to parse both manually and with help.  It's ascii too, the only difference is the lack of sub-nodes which aren't really needed in mame anyway.  Also it is rather small compared to xml.   

--- End quote ---

There's two kinds of XML parsers.  DOM parsers that parse the entire file into memory at once, and SAX parsers that parse it sequentially and fire events as tags are encountered.

DOM parsers are nice when you need the whole file in memory, like when you're editing it.  However, they have the entire file in memory and parsed into a tree structure that is even larger than the original file.

SAX parsers are nice when XML is used for a configuration file and you just need to read it in sequentially and do stuff based on what you find.  SAX parsers are the most memory efficient way to go if you don't need the whole file at once.

You need to find the right tool for the job.

Much more info...

http://www.w3.org/DOM/faq.html#SAXandDOM


--- Quote from: Howard_Casto on July 17, 2006, 01:02:40 am ---Xml is meant for tiny little storage files, not huge databases like mame generates.

--- End quote ---

XML is meant to be a standardized method of describing non-binary data, especially when there are hierarchical aspects to it.  The benefit is that there are tons of off the shelf XML tools and libraries so you don't need to write custom code for every project.  The obvious drawbacks are what you pointed out, the file sizes are usually much larger than other solutions.  However, with the advent of 3+GHz systems with 2+GB of memory and 500+GB hard drives, the benefits of XML outweigh the size issues.

One could argue that each game should be described in its own XML file and have all the files dumped into the same directory.  That would make it somewhat more manageable chunks for memory limited computers.


Oh, and you might want to check out XPath.  It's awesome for dealing with "huge [XML]  databases like mame generates".  :)


Minwah:
I could be re-inventing the wheel (& I haven't tried it yet), but I'm tempted to write my own xml parser...
headkaze:

--- Quote from: Howard_Casto on July 17, 2006, 01:02:40 am ---I wouldn't know what to tell you.  They don't error out, it's just the parsers choke or enver finish ect. 
--- End quote ---

Let me guess VB6 custom written parsers? heh dosn't suprise me. If you coded in .NET System.Xml.XmlTextReader would make things alot more easier for you.


--- Quote from: Howard_Casto on July 17, 2006, 01:02:40 am --- :soapbox:
I think the abandonment of the listinfo format (regardless of how horribly flawed it is) is a mistake. 

The xml format is very simple and easy to understand, the xml parsers available aren't though.
--- End quote ---

A very bad mistake for breaking legacy support, I agree, but sometimes you have to go with the new and let go of the old. I know it's a ---smurf---, but it's the way the IT industry will always go. Part of being in this industry is keeping up with standards and keeping your skills up to date. This is the case for homebrew developers as well as professionals.

The registry was never supposed to be used as much as it has been for applications on Windows and .NET has dropped native support of reading & writing ini files because they are moving towards XML. It's a format that is being adopted everywhere.


--- Quote from: Howard_Casto on July 17, 2006, 01:02:40 am ---The list output is supposed to be for fe develpers right?  Then why in the world is the xml format used?  Aaron has to remember, most fe programmers are just hobbists. We shouldn't have to learn a whole new language just to interface with mame.  Xml is exteremelly difficult to parse with some of the older languages, even with tools (msxml, sax, whatever).  After looking at my choices that work with vb6 I am rather dis-heartened.  The official m$ stuff is so convoluted with all of it's classes and sub-classes that it takes knowledge of sql-like queries necessary even for looking up something as simple as a sub tag.  Most of the parsers I tried simply can't load the entire listxml output which is essential as front-ends need to load all the data and convert it to whatever type of list file they use.  The ones that did work took an hour to load it.  And I'm not exaggerating, I mean a whole hour. 
--- End quote ---

I would recommend looking at some XML parsing code written in C++ and compiled to a DLL that can be accessed through the LoadLibrary API or however else your access a library in VB6. The thing is, as one would expect string parsing functions in VB6 are slow as hell, your really need something written in C++ to get some decent parsing speed.

You comments on hobbiest coders mostly coding in old languages is a little off. Alot of people are moving to .NET, but I agree it is a mistake to take it out for the sake of it.


--- Quote from: Howard_Casto on July 17, 2006, 01:02:40 am ---Your efforts trying to fix xml2info are appreciated, but the real solution (as it'll be hard to keep up a converter not officially in mame) is to get everyone off this xml kick and have mame output a real format.  What's wrong with ini files?  The ini format is easy to parse both manually and with help.  It's ascii too, the only difference is the lack of sub-nodes which aren't really needed in mame anyway.  Also it is rather small compared to xml.
--- End quote ---

Yeah, the ini file format is being phased out by M$ so I guess it's important for coders to keep up with the times. Vista's XAML is an important part of that OS and will be used to separate the UI to the program code. It's a powerful language for something like that.


--- Quote from: Howard_Casto on July 17, 2006, 01:02:40 am ---Xml is meant for tiny little storage files, not huge databases like mame generates.
--- End quote ---

Good point, it should be an SQL database file, not data generated by Mame.exe on the fly. And even VB6 can read Access databases using ODBC. So that would be the ideal solution. If the authors sincerely wanted to keep up with the times, then they would put this information into a database.

I suggest another solution; a program written in .NET using it's native XML parsing support to read the XML data generated from Mame.exe and output it to an SQL database. Then re-write your applications to read the database.

EDIT: Hmm it seems the Microsoft Access application can import XML directly.
Navigation
Message Index
Next page
Previous page

Go to full version