Graham Klyne wrote:
> I've been trying to compile the HXML toolbox, version 3.01 > (http://www.fh-wedel.de/~si/HXmlToolbox/HXmlToolbox-3.01.tar.gz), using the > experimental Unicode version of Hugs, and have encountered a few source > code problems that I think are maybe not specific to Hugs. > > (1) hdom/xmltreefilter.hs, incorrect section syntax: > line 555, changed to: > del1Attr an = processAttrl ((none `when` isAttr an) $$) > line 613, changed to: > = processAttrl ((modifyValue `when` isAttr an) $$)
we've changed this in our development version
OK, thanks.
(Someone mentioned that it wasn't incorrect, as I claimed, but a known oddity in Hugs)
Character Range
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]
/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
I thought so, but was being too lazy to check.
does not mean popen in ghc lib, but popen source from Jens Petersen for calling external program curl for better http support than with the http module
> (7) in POpen.hs: > Module Posix should be Text.Regex.Posix? > > At this point, I get: > [[ > Reading file "..\popen\POpen.hs": > ERROR "..\popen\POpen.hs":39 - Undefined type constructor "ProcessID" > ]] > and give up chasing down this problem. I'm wondering if the HXML toolbox > library has been tested under MS Windows?
we do not develop under MS, our internal coding rule for Haskell is: use ghc without any glasgow extensions and compile own modules with all warnings on and no warnings detected. this is a moving target, because ghc becomes better and better in emitting usefull warnings. this rule does not apply to http, nor to popen nor to parsec modules, there ghc detects a lot of warnings
My (limited, but increasing) experience seems to be that language incompatibilities are a rarity if one sticks to a few well-supported extensions. (My touchstone is both GHC and Hugs support.) It seems to be libraries where consistency is less certain.
the http access is a weak point with haskell, a portable library that supports stable access, timeouts, proxies, cookies, ... like e.g. the curl library would remove a lot of the problems found here.
So the requirement for inter-process communication here is to run an external program and receive any data that it may return?
HTTP access is not my immediate concern. I'll go back to the test harness that I'm trying to build, and seen if I can excise this feature for the moment -- it's the XML parser I'm after. I think it would be helpful if these elements of the toolkit could be clearly separated.
That said, I am interested in having a general URI-reader for my project, so I may have a deeper look at some stage.
Thanks.
#g
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
