Compiling HXML toolbox under Hugs/Windows
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) $$) (2) hparser/unicode.hs, questionable range of unicode characters in: [[ -- | -- test for a legal multi byte XML char isMultiByteXmlChar :: Unicode -> Bool isMultiByteXmlChar i = ( i >= '\x00000080' && i <= '\x0000D7FF' ) || ( i >= '\x0000E000' && i <= '\x0000FFFD' ) || ( i >= '\x00010000' && i <= '\x0010FFFF' ) ]] Should that be \x0010FFFF or \x0010FFFD? (The Hugs Unicode code had \x0010FFFD for the upper bound.) (3) hparser/xmlinput.hs, line 38: spurious ',' (4) Missing module 'Socket'. [[ Reading file "..\hparser\XmlInput.hs": Parsing ERROR "..\hparser\XmlInput.hs" - Can't find imported module "Socket" ]] Is this a GHC/Hugs library difference? Should this be Network.Socket? I tried using that and it seemed to be accepted. (5) Ditto for module URI. (6) I think a probem with the build instructions in README: [[ Just add the modules from the directories "hdom", "hparser", "hvalidator", "hxpath", "http" and "parsec" to the path of your compiler or interpreter, the Makefile contains an example. It is planned to provide a GHC package of the Haskell XML Toolbox in the near future. An example ghci project file ".ghci" can be found in the examples directory. ]] does not mention directory popen. (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? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
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
(2) hparser/unicode.hs, questionable range of unicode characters in: [[ -- | -- test for a legal multi byte XML char
isMultiByteXmlChar :: Unicode -> Bool isMultiByteXmlChar i = ( i >= '\x00000080' && i <= '\x0000D7FF' )
( i >= '\x0000E000' && i <= '\x0000FFFD' )
( i >= '\x00010000' && i <= '\x0010FFFF' ) ]] Should that be \x0010FFFF or \x0010FFFD? (The Hugs Unicode code had \x0010FFFD for the upper bound.)
the XML 1.0 Standard says: "http://www.w3.org/TR/REC-xml#charsets" 2.2 Characters [Definition: A parsed entity contains text, a sequence of characters, which may represent markup or character data.] [Definition: A character is an atomic unit of text as specified by ISO/IEC 10646 [ISO/IEC 10646] (see also [ISO/IEC 10646-2000]). Legal characters are tab, carriage return, line feed, and the legal characters of Unicode and ISO/IEC 10646. The versions of these standards cited in A.1 Normative References were current at the time this document was prepared. New characters may be added to these standards by amendments or new editions. Consequently, XML processors must accept any character in the range specified for Char. The use of "compatibility characters", as defined in section 6.8 of [Unicode] (see also D21 in section 3.6 of [Unicode3]), is discouraged.] Character Range [2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
(3) hparser/xmlinput.hs, line 38: spurious ','
removed
(4) Missing module 'Socket'. [[ Reading file "..\hparser\XmlInput.hs": Parsing ERROR "..\hparser\XmlInput.hs" - Can't find imported module "Socket" ]] Is this a GHC/Hugs library difference? Should this be Network.Socket? I tried using that and it seemed to be accepted.
we've never tried sockets with Hugs
(5) Ditto for module URI.
(6) I think a probem with the build instructions in README: [[ Just add the modules from the directories "hdom", "hparser", "hvalidator", "hxpath", "http" and
sorry, and "popen"
"parsec" to the path of your compiler or interpreter, the Makefile contains an example. It is planned to provide a GHC package of the Haskell XML Toolbox in the near future. An example ghci project file ".ghci" can be found in the examples directory. ]] does not mention directory popen.
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 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. thanks for your hints uwe schmidt
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
Graham Klyne wrote:
So the requirement for inter-process communication here is to run an external program and receive any data that it may return?
exactly, the one and only reason
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.
yes, we should separate the protocol handlers from the XmlInput.hs module. but this is not a complete solution for your problem, you still need to introduce some kind of condtional compilation for inclusion or exclusion of the none portable stuff for http access. uwe schmidt p.s. why not ghci instead of hugs? -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html
Uwe, Answering just one of your questions... At 14:46 21/01/04 +0100, Uwe Schmidt wrote:
p.s. why not ghci instead of hugs?
Actually, I want to be able to use both: (a) in developing my own software, I find I am using extensions to the Haskell 98 language; I'm using the criterion of support in both GHC and Hugs to determine if an extension is one with community consensus. (b) Because I'm trying to develop software which may be useful to people who haven't previously used Haskell, I wish it to be as easy to get started with as I can manage. It seems that Hugs is an easier package to get started with than GHC and GHCi, and appears to be the initial implementation choice for many people initially approaching Haskell. (I am not saying the GHC is difficult, and I do find it quite easy to install and use, but Hugs somehow seems easier.) I note that the availability of multiple implementations over multiple platforms was an important factor in my decision to use Haskell. In general, I think it is helpful if general purpose Haskell libraries can be used with multiple implementations. #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
At 14:46 21/01/04 +0100, Uwe Schmidt wrote:
So the requirement for inter-process communication here is to run an external program and receive any data that it may return?
exactly, the one and only reason
I'm looking through the GHC source distribution kit for the implementation of the Posix stuff used by POpen, with a view to possibly using that as a source of clues for implementing similar functionality (to POpen) under MS Windows, but so far I'm struggling. I have found an implementation of popen in the GHC dustribution, in hslibs/posix (but not, apparently, in the hierachical library tree), which appears to be functionally the same as that distributed with HXML Toolbox. I see what appears to be a forkProcess primitive implemented in a file ghc/rts/Schedule.c (but not for Windows, of course), but I don't see any corresponding Haskell source file with a corresponding declaration. I cannot find *any* reference to fdClose (another function that is used by popen). I'm mainly looking for examples of interfacing from Haskell to low-level C code on Windows. Also useful would be sample Windows code that executes a program and captures its stdout, etc., but I guess I'm more likely to find that elsewhere. Does anyone have any helpful pointers to offer? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Graham Klyne wrote:
I'm looking through the GHC source distribution kit for the implementation of the Posix stuff used by POpen, with a view to possibly using that as a source of clues for implementing similar functionality (to POpen) under MS Windows, but so far I'm struggling.
I have found an implementation of popen in the GHC dustribution, in hslibs/posix (but not, apparently, in the hierachical library tree), which appears to be functionally the same as that distributed with HXML Toolbox.
I see what appears to be a forkProcess primitive implemented in a file ghc/rts/Schedule.c (but not for Windows, of course), but I don't see any corresponding Haskell source file with a corresponding declaration.
hslibs/posix/PosixProcPrim.lhs
I cannot find *any* reference to fdClose (another function that is used by popen).
hslibs/posix/PosixIO.lhs
I'm mainly looking for examples of interfacing from Haskell to low-level C code on Windows. Also useful would be sample Windows code that executes a program and captures its stdout, etc., but I guess I'm more likely to find that elsewhere.
Does anyone have any helpful pointers to offer?
hslibs/win32/Win32Spawn.hs [These are all from 5.04.2; the paths may have changed to somewhere beneath libraries/ in 6.x, but the filenames will probably be the same.] -- Glynn Clements <glynn.clements@virgin.net>
At 13:53 22/01/04 +0000, Glynn Clements wrote:
hslibs/posix/PosixProcPrim.lhs
hslibs/posix/PosixIO.lhs
Thanks, I see them now. For some reason, the Windows Explorer search function doesn't find them.
I'm mainly looking for examples of interfacing from Haskell to low-level C code on Windows. Also useful would be sample Windows code that executes a program and captures its stdout, etc., but I guess I'm more likely to find that elsewhere.
Does anyone have any helpful pointers to offer?
hslibs/win32/Win32Spawn.hs
Ah, excellent (also spawnProc.c) -- just what I was looking for. Thanks! #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Still struggling; please see question about MD5 at end... At 14:46 21/01/04 +0100, Uwe Schmidt wrote:
Graham Klyne wrote:
So the requirement for inter-process communication here is to run an external program and receive any data that it may return?
exactly, the one and only reason
I think I have a solution for this.
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.
yes, we should separate the protocol handlers from the XmlInput.hs module.
but this is not a complete solution for your problem, you still need to introduce some kind of condtional compilation for inclusion or exclusion of the none portable stuff for http access.
I've think figured a batch file to preprocess the source files. But I think the real need here is for some kind of portable HTTP access library.
uwe schmidt
p.s. why not ghci instead of hugs?
Well, further to my previous response, it appears that there's a problem with GHC as well... The XmlInput module imports a module called MD5, and uses a maethod 'digest' from that module. I cannot find a copy of that module either in the HXML toolbox distribution, or in the GHC distribution. I did find this in the GHC 6.2 release notes: [[ The MD5 library in the util package has been removed. We'll include a replacement in the hierarchical libraries if someone would like to send us one! ]] Is your software tested under GHC 6.2? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Graham Klyne <GK@ninebynine.org> writes:
Well, further to my previous response, it appears that there's a problem with GHC as well... The XmlInput module imports a module called MD5, and uses a maethod 'digest' from that module. I cannot find a copy of that module either in the HXML toolbox distribution, or in the GHC distribution. I did find this in the GHC 6.2 release notes:
[[ The MD5 library in the util package has been removed. We'll include a replacement in the hierarchical libraries if someone would like to send us one! ]]
Is your software tested under GHC 6.2?
The software is not mine, but I committed the following hack to have it compile: h x = MD5.md5s (MD5.Str x) {- h = IOExts.unsafePerformIO . MD5.digest -} ie. commented out the second line instead of the first. I don't care about authentication, so I don't know if it actually works... Feri.
participants (5)
-
Ferenc Wagner -
Glynn Clements -
Graham Klyne -
Graham Klyne
-
Uwe Schmidt