Compiling HXML toolbox under Hugs/Windows

[Graham Klyne]

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

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