On 31 August 2010 02:34, David Gowers <[email protected]> wrote: > On Mon, Aug 30, 2010 at 9:52 PM, Ralph Versteegen <[email protected]> wrote: >> I tried it out, discovered it was broken, and eventually discovered >> that this was due (only) to errors in the RELOAD documentation. Nice >> work! Patch attached. > > Thanks! Pushed to git master + fixed the doctests that had broken due > to the stringtable changes.
Ah, since I don't have nose I forgot about the doctests. > (also I had added a reload_from_dict function since then. That's > available now too FWIW) Looks useful. But I'm not sure just what is or is not useful until I actually sit down and build a real program using nohrio.reload. No ideas for one yet. >> It now correctly reads and writes all RELOAD >> documents that I threw at it, including the unittest.rld that >> reloadtest produces. Also, I reimplemented reload2xml in a couple >> lines (MUCH nicer than the 'real' thing :) ), > lxml2 is pretty nice :) I had it's model in mind vaguely when > implementing my system. I might take a look at lxml2. The official reload interface still feels unfinished to me. >> to check that it really >> was reading things correctly, and not just that writing was undoing >> some kind of error in the read code. >> >> And the string table optimisation really works, it trimmed 1kB off a 15kB >> file! > > Great - I figured the canonical code didn't do that, and I thought it > would be worthwhile for repetitious documents :) > >> >> I noticed that when testing nodes/trees for equality, you don't >> actually look at their values. > > kinda slow, and creates more temporary data (get the names, sort them, > copy the list of children, sort according to name order) > > Anyway, implementation is in my local git checkout; not tested/pushed > yet. (probably do that tomorrow.. my clock says 12.04) > > This means it's no longer assumed that children are in the same order > (eg. sorted). This will probably avoid considerably weird breakage in > some circumstances. The node compare implementation in reloadext.bas assumes children are in the same order, and I can't really be bothered fixing that: it's only used for debugging, and working with arrays in FB is really really awful. It drives me up the wall. FB doesn't even support zero-length arrays, and they are not first class types. FB arrays are far worse than C arrays, which is why we are writing so much pointer-laden code lately. Anyway, point being that I'll just switch to using nohrio for comparing reload documents. However, I notice you're still assuming children with the same name are in the same order. Their order may or may not matter depending on the document. It's not very pleasant to fix, but I assume that Python uses hashes when comparing objects, so it could be done fairly efficiently? Or does defining a __eq__ method override any use of hashes? >> I suggest comparing the textual >> representation of data, so that None == "", and maybe an option for >> exact comparison like reloadutil's --pedantic option. Not quite how I >> would have designed things, but that's how things worked out: the >> official implementation's interface doesn't distinguish between null >> and zero-length string nodes. > That seems slightly evil. I'll have to consider it. I'm not sure it's needed, since AFAIK the only way that a node would actually change type to something textually equivalent is through being converted to XML and back. > (for the purposes of conditionals in python, '' is equivalent to None; > that is, 'not 0', 'not None' "not '' " all evaluate to True (meaning > that if you remove the Not, they all evaluate to False.). > That may or may not help, though.) > > >> >> BTW, why don't the FB packages for your system work? What system is it? > > Arch Linux. > > It can't find its include files (crt.bi, for example). > It seems to have part of itself installed in /usr > and the other part in /usr/local > (it claims to be compiled with prefix=/usr/local; the includes are in > there IIRC but it doesn't find them) I just looked at the archlinux script for that package, and can see that someone really screwed it up. If you don't want to move installed files around, you could download a standalone build instead, and throw it in a folder in ~. _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
