Commandline XML parser

[mahuti]

I need an external XML parser for an app I'm building (I know, I know... don't ask...)

Using the listxml file, all I need to do is pass out a value via command line, i.e. (whateverapp.exe listxml.txt pacman), and have the parser return the contents of the pacman node via stdout.

Can anyone suggest anything that might work for this?

[Buddabing]

I need an external XML parser for an app I'm building (I know, I know... don't ask...)

Using the listxml file, all I need to do is pass out a value via command line, i.e. (whateverapp.exe listxml.txt pacman), and have the parser return the contents of the pacman node via stdout.

Can anyone suggest anything that might work for this?

For a special-purpose XML parser, feel free to look at the parser I wrote for my ListGen utility.

For general purpose XML parsing, look to the free Expat library.

In fact, if all you're looking at is spitting out the game info for pacman, you probably could configure ListGen to do the entire task.

[SirPoonga]

maybe start with...
http://www.monmouth.com/~wstreett/lex-yacc/lex-yacc.html

[mahuti]

Thanks for the responses. I'll check them out.

Looks like flex and bison might be out, though. I'll look into the expat and listgen. I've heard of your listgen app before, but I never looked into it. It writes the output to a file, right?

Sure would be nice if I could do a mame.exe -listxml pacman to get back just the XML on pacman. That stupid 23mb file is too much for my app to parse right now, just for a few lines of info.

[nipsmg]

mahuti, what are you writing the app in (language?).

If you writing in any of the .NET languages, and you have access to SQL Server 2000 (or  maybe MDSE) you can easily take the -listxml XML file as input and dump that XML data into a table.  Your app can then query for a specific entry/entries.

If you store the version of MAME you imported the data from, you can choose to do the import when you detect a new version.

[Buddabing]

Thanks for the responses. I'll check them out.

Looks like flex and bison might be out, though. I'll look into the expat and listgen. I've heard of your listgen app before, but I never looked into it. It writes the output to a file, right?

Sure would be nice if I could do a mame.exe -listxml pacman to get back just the XML on pacman. That stupid 23mb file is too much for my app to parse right now, just for a few lines of info.

Yes, ListGen writes the output to a file.

Why are flex and bison out? That's how ListGen parses the XML. Then it uses the free SQLite engine to build and query an internal database.

[mahuti]

*might*

Just from casual perusal. that statement was nothing definitive. I had planned to take another more in-depth look, and I will... especially based on your comments.

[Howard_Casto]

The problem really lies in an oversight in mame.  Any other gamelist ouput for mame let's you specify a romname and just get data for that game.  Listxml is the only tag that lacks this feature. 

[PacManFan]

Ask and ye shall recieve.
Here's a link to something I just whipped up for you. It's 100% c/c++ with the full source code included.

The command line is xmlparse (xmlfile) (gamename)

For example:
xmlparse.exe listxml.txt pacman

I'm only dumping part of the information right now, but adding the rest should be easy enough. Check it out.
home.comcast.net/~shernandez1337/xmlparse.zip
-PMF

[mahuti]

wow.

This could be cool... for more than just me. Having a good xml option has kept me from finishing up my project for like a year or so.

This might give me more of a spring in my step.

[mahuti]

That's pretty much all I need... will eventually need a bit more information out of it, but I can cross that bridge when I get there.

Thanks so much, man. I really, really, appreciate it. I'll keep you updated.

[mahuti]

Well, it's 1:30 am... got the little app to read back the output from the xml parser and display it.

Not much... but enough for now.

[PacManFan]

No problem,

A good XML parser is something everyone should have in thier tool box. What kind of information about the rom do you need to output? All of the node? Or just some specific info? What I sent was the debug build. I can build you the release version(much faster) if needed. I was testing on a 23MB xml file, and on this computer, it loaded in about 3-4 seconds. I just tested the release version and it's more like 1-2 seconds to load and parse the file.

[mahuti]

Specific info needed:

<game name= cloneof
<description
<year>
<video orientation=
<input players= control= buttons=

Just need the data in a regular format, whether it be xml, or just text on a line. As long as everything comes in the same format (ie. always 5 lines... blanks if no information presented)

Not picky.

[PacManFan]

Alright,
   I had a few more minutes today to work on this.
I've updated the zip file on my site, so re-download it. It does everything you need it to do, and I built the release version which is much faster than the debug version. The entire 23 mb xml file is parsed and extracts the data elements in 1.23 seconds on average.
All the source is included if you need to make changes.

Let me know if you need anything else.
So, what kind of project are you working on?

-Steve (PacManFan)

[mahuti]

Nothing ground breaking, but perhaps useful for some. Until I could get over a few hurdles, I didn't really want to talk about it. The XML thing is the last big hurdle for an initial release.

As a quid pro quo, I'll let you know. I'm building a front end with support for flash swf files for layout design, and swf based plug-ins for functionality. The app will read rom folders and display games with little fuss. My goal is to require very little initial configuration on the users part.

Basically, the app reads & stores rom information, and passes information out. A front-end. Beyond that, it allows a user to control the presentation layer by external plug-ins in the form of swf files. Flash files can be edited to control not just static layout, but also animation & effects of the GUI.

Initially, a base package will be included, along with a default swf based layout, and will be somewhat limited... maybe to just MAME. Minor portions of the default layer can be adjusted... background images, etc, easily. A layout editor will not be included initially... anyone interested in designing a skin to take the place of the default can edit the provided FLA source files to create their own more advanced skin.

Configuration will initially be ini based, later support for internal gui based configuration may be added in with a plug-in. I may initially build in support for Mamewah's ini files, to make things simpler on those wishing to try it out.

The app itself is not a swf or projector exe... it runs swf files however. The advantage of using flash for the presentation layer are;

1. Vastly advanced layouts are possible.
2. Easy access to development tools & development aid.

among others. There will initially be some drawbacks to this applicaton... due to my lack of proficiency in traditional programming. Probably won't run too fast on older computers, won't be as full featured as other FEs in some respects. There are plenty of other good FEs... the world doesn't necessarily need one more. There's a lot of potential in this approach, though.

The base app won't be open-source, though all presentation files & any plug-ins will be. My attempt will be to keep the base app devoid of as much functionality as possible, to allow 3rd parties flexibility with how the app looks & works. The base app will just be used to read folder contents, ini files, and other system manipulation tasks. Users will be encouraged to develop swf files to access & display the information stored in the base application. Realistically, I don't imagine too much external development will take place with this app, but I will support it as much as I can.

There are some guys out there that really know how to do some crazy stuff with actionscrip OOP... and they could really stretch the bounds of a base app like this. 

Anyway, I have a few major projects to get out professionally, when I get them out... I may take a month or two off and work on this. We'll see. At a minimum, I will be publicly setting some long range goals for the app, and slowly work toward them. When I get closer to launch, I'll post the URL. Initially.. it'll be a bit rough around the edges. We'll see how it progresses.