[Martin, on ftp://ftp.jclark.com/pub/xml/expat.zip] > ... > That gives some clue, yes. Unfortunately, that URL itself is a symlink > that was expat1_1.zip (157936 bytes) at some point, That's the one I've been using. > and now is expat1_2.zip (153591 bytes). I'm assuming you're recommending that one! Based on that assumption, I've downloaded a new one and will put that in the 2.1a1 Windows release. Scream if that's not what you want. > ... > Anyway, I was using 1.1 in my own tests, and 1.2 in PyXML - either > works for me. I never tested 1.95.x (which is also not available from > jclark.com). If you do and love it, let me know where to get it and I'll ship that instead. >> The tests passed in the wee hours (EST; UTC -0500) this morning. >> They began failing after I updated around 1pm EST today. > I just merged pyexpat changes from PyXML into Python 2 so that could > be the cause. However, this very code has been used for some time by > PyXML users, why it crashes for you is a mystery to me. Perhaps gc, perhaps uninitialized vars, ..., hard to say. Unfortunately, it's not unusual for flawed code to display different behavior across platforms; or, from the long-term QA perspective, it's *great* that flawed code doesn't always appear to work on all platforms <wink>. > Any chance of producing a C backtrace? Sent that before; doesn't look like much help; we're seeing a NULL type pointer, but at that stage there's no telling when or where or why it *became* NULL. I'm going to rebuild the world from scratch, and use the new DLLs. You should assume that didn't help unless I say otherwise within 15 minutes.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4