Compiling HXML toolbox under Hugs/Windows
GK at ninebynine.org
Tue Jan 20 10:49:20 EST 2004
At 16:12 16/01/04 +0100, Uwe Schmidt wrote:
>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
(Someone mentioned that it wasn't incorrect, as I claimed, but a known
oddity in Hugs)
> 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
> > (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.
More information about the Haskell