I'm already using it for repair then extract (with delete par2s and rars when done). Just no GUI info/progress updates at this point.
Done:
* Added basic support for handling progress update callbacks from move, copy, delete, and extract. (None for repair yet since I rely on par2cli at this point.
* A number of minor bugs fixed in dealing with files, filenames, and file parts (extensions, roots, etc.)
Todo in the next couple of days:
* Fix/figure out how to deal with xml_attribute(_structs) causing occasional exceptions, because it uses pointers internally(and my hacks aren't working).
* Handle Context Menu dynamic generation from xml config.
* Handle context menu generated tasks.
When that's done:
* Hook up the Gui to the task q.
* Debug, debug, debug. Memory check, performance profile if necessary (AQTime, Boundschecker).
* Check into CVS
Finally:
* Create installer.
* Profit. Oh wait...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Argh. I'm stuck trying to figure out the best way to 'fix' pugxml for my uses. So maybe a little talk therapy will help.
The problem is that I need to be able to make an assignment to an xml_attribute that is NOT in the document.
XQs supports putting values in both the value="something" attribute of the tag, and in the PCDATA.
So for example both:
<Name value="myname"/>
and
<Name>myname</Name>
are supported.
The problem is that xml_attribute uses a pointer to an xml_attribute_struct internally, and simply copies that pointer when assigning one xml_attribute to another. Which is fine when you actually have an attribute to back the value up with, but doesn't work when you are using PCDATA and need to return that as an xml_attribute.
Creating an xml_attribute by itself, doesn't allow you to add any values, so you need to then assign an xml_attribute_struct to the xml_attribute. But where do I get that struct from? If I use a local instance of
xml_attribute_struct s;
xml_attribute att(&s);
then I have scoping problems if the xml_attribute is passed back as a return value, because the xml_attribute_struct gets destroyed.
If I use xml_attribute att(new xml_attribute_struct); then I have a memory leak. If I use
xml_attribute att(new xml_attribute_struct, /* _delete_attr = */ true); then I have the same scoping problem from before.
The code in pugxml talsk about using append_attribute to handle this situation, but this is no good either, as it is essentially a memory leak too, since I will never be able to delete the value, since I don't know if it's based on PCDATA (deletable) or an actual attribute (not deleteable).
So here are my possible solutions:
* Figure out if/how to add an auto_ptr<xml_attribute_struct*> to the xml_attribute so that assignment doesn't destroy my return values.
[HARD but elegant?]
* Add some other kind of flag when creating an xml_attribute, inidicating that the user should delete the xml_attribute_struct when done. [Easy, ugly?]
* Wrap the wrapper? Create a new class that wraps xml_attribute, an xml_result class. This xml_result would then copy any results from an xml_attribute on assignment, or could be modified directly by PCDATA ssignment. [MEDIUM]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Okay, so I solved my problem. What a pain in the...
I ended up not doing any of the above three ideas, though I played around with #3 yesterday.
What I did instead is completely rewrote xml_attribute to use an xml_attribute_struct instead of a xml_attribute_struct*. I also got rid of all of the non-segmenting stuff, and memory file support, and insitu support.
So performance is nowhere near what the original is, but it now just works...and performance isn't really an issue for XQs as it does relatively little parsing (basically it only does any parsing when a user actually does something, which is very infrequent in reality, and the parsing is failry straightforward). The fact that it might take another 10ms to parse the xml file means nothing up against the 10+ minutes it actually takes a large repair/extract to complete.
If performance really becomes a concern I can actually change my code to use xml_attribute ptrs now. Before it would have been a disaster IMO.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm already using it for repair then extract (with delete par2s and rars when done). Just no GUI info/progress updates at this point.
Done:
* Added basic support for handling progress update callbacks from move, copy, delete, and extract. (None for repair yet since I rely on par2cli at this point.
* A number of minor bugs fixed in dealing with files, filenames, and file parts (extensions, roots, etc.)
Todo in the next couple of days:
* Fix/figure out how to deal with xml_attribute(_structs) causing occasional exceptions, because it uses pointers internally(and my hacks aren't working).
* Handle Context Menu dynamic generation from xml config.
* Handle context menu generated tasks.
When that's done:
* Hook up the Gui to the task q.
* Debug, debug, debug. Memory check, performance profile if necessary (AQTime, Boundschecker).
* Check into CVS
Finally:
* Create installer.
* Profit. Oh wait...
* Added Configurable Recycle Bin Support on deletion (WORKS)
Argh. I'm stuck trying to figure out the best way to 'fix' pugxml for my uses. So maybe a little talk therapy will help.
The problem is that I need to be able to make an assignment to an xml_attribute that is NOT in the document.
XQs supports putting values in both the value="something" attribute of the tag, and in the PCDATA.
So for example both:
<Name value="myname"/>
and
<Name>myname</Name>
are supported.
The problem is that xml_attribute uses a pointer to an xml_attribute_struct internally, and simply copies that pointer when assigning one xml_attribute to another. Which is fine when you actually have an attribute to back the value up with, but doesn't work when you are using PCDATA and need to return that as an xml_attribute.
Creating an xml_attribute by itself, doesn't allow you to add any values, so you need to then assign an xml_attribute_struct to the xml_attribute. But where do I get that struct from? If I use a local instance of
xml_attribute_struct s;
xml_attribute att(&s);
then I have scoping problems if the xml_attribute is passed back as a return value, because the xml_attribute_struct gets destroyed.
If I use xml_attribute att(new xml_attribute_struct); then I have a memory leak. If I use
xml_attribute att(new xml_attribute_struct, /* _delete_attr = */ true); then I have the same scoping problem from before.
The code in pugxml talsk about using append_attribute to handle this situation, but this is no good either, as it is essentially a memory leak too, since I will never be able to delete the value, since I don't know if it's based on PCDATA (deletable) or an actual attribute (not deleteable).
So here are my possible solutions:
* Figure out if/how to add an auto_ptr<xml_attribute_struct*> to the xml_attribute so that assignment doesn't destroy my return values.
[HARD but elegant?]
* Add some other kind of flag when creating an xml_attribute, inidicating that the user should delete the xml_attribute_struct when done. [Easy, ugly?]
* Wrap the wrapper? Create a new class that wraps xml_attribute, an xml_result class. This xml_result would then copy any results from an xml_attribute on assignment, or could be modified directly by PCDATA ssignment. [MEDIUM]
Okay, so I solved my problem. What a pain in the...
I ended up not doing any of the above three ideas, though I played around with #3 yesterday.
What I did instead is completely rewrote xml_attribute to use an xml_attribute_struct instead of a xml_attribute_struct*. I also got rid of all of the non-segmenting stuff, and memory file support, and insitu support.
So performance is nowhere near what the original is, but it now just works...and performance isn't really an issue for XQs as it does relatively little parsing (basically it only does any parsing when a user actually does something, which is very infrequent in reality, and the parsing is failry straightforward). The fact that it might take another 10ms to parse the xml file means nothing up against the 10+ minutes it actually takes a large repair/extract to complete.
If performance really becomes a concern I can actually change my code to use xml_attribute ptrs now. Before it would have been a disaster IMO.