Re: Unicode windows console output.
It is possible to output some non Latin1 symbols if you use the wide string API but not all of them. Basically the console supports all European language but nothing else - Latin, Cyrillic and Greek. 2010/11/2 David Sankel cam...@gmail.com: Is there a ghc wontfix bug ticket for this? Perhaps we can make a small C test case and send it to the Microsoft people. Some[1] are reporting success with Unicode console output. David [1] http://www.codeproject.com/KB/cpp/unicode_console_output.aspx On Tue, Nov 2, 2010 at 3:49 AM, Krasimir Angelov kr.ange...@gmail.com wrote: This is evidence for the broken Unicode support in the Windows terminal and not a problem with GHC. I experienced the same many times. 2010/11/2 David Sankel cam...@gmail.com: On Mon, Nov 1, 2010 at 10:20 PM, David Sankel cam...@gmail.com wrote: Hello all, I'm attempting to output some Unicode on the windows console. I set my windows console code page to utf-8 using chcp 65001. The program: -- Test.hs main = putStr λ.x→x The output of `runghc Test.hs`: λ.x→ From within ghci, typing `main`: λ*** Exception: stdout: hPutChar: permission denied (Permission denied) I suspect both of these outputs are evidence of bugs. Might I be doing something wrong? (aside from using windows ;)) I forgot to mention that I'm using Windows XP with ghc 6.12.3. -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: link problem under macosx
Am 02.11.2010 18:03, schrieb Thorkil Naur: Hello, On Tue, Nov 02, 2010 at 01:03:04PM +0100, Christian Maeder wrote: ... Are there better workarounds? I am not sure about that, I assume that you have looked at http://hackage.haskell.org/trac/ghc/ticket/4068? no, I found Simon Michael's message http://www.mail-archive.com/haskell-c...@haskell.org/msg81961.html by chance. I did not try out his extra-lib-dirs proposal, since all cabal packages were already installed. And I agree with him that it should be documented somewhere more prominent and that avoiding macports is no (good) solution. I'll add his proposal to your (closed) ticket to increase the hit rate. Cheers Christian ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: MonoLocalBinds and darcs
| Make sure you are using RC2 of the compiler, from what I remember RC1
| required signatures it shouldn't have, or enabled MonoLocalBinds more
| than it should - RC2 required less signatures. However, your code
| could well just be heavily using the relevant features.
|
| I was using RC2. But darcs uses GADTs globally so MonoLocalBinds is always
| on.
|
| I've now retested with NoMonoLocalBinds properly enabled and I just needed
| one extra signature.
OK that's better! I was surprised when you said it didn't work. If you had
type signatures to make GADTs work, you may be able to remove some of them, in
which case you'd be in profit :-)
| That's quite compelling, but I'm aware it's not
| considered a reliable feature so I'm not quite sure which way to go.
Well, I'm aware that it's a compromise. I don't know how to do a bang-up
principled job of typechecking local polymorphism, so GHC does a best-effort
job. In fact best effort is pretty good, and it's not hard to implement, so
a) I don't expect to remove NoLocalMonoBinds
b) I expect it will work fine 99% of the time
My suggestion would be to keep it as a {-# LANGUAGE NoLocalMonoBinds #-} in
each module that needs it for now. You can remove it gradually.
Concrete examples of where the absence of local polymorphism is painful would
also be a good thing; you could attach a comment to my blog post. Maybe there
are useful special cases or something.
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode windows console output.
On 2 November 2010 21:05, David Sankel cam...@gmail.com wrote: Is there a ghc wontfix bug ticket for this? Perhaps we can make a small C test case and send it to the Microsoft people. Some[1] are reporting success with Unicode console output. I confirmed that I can output Chinese unicode from Haskell. You can test this by using a program like: main = putStrLn 我学习电脑科学 When you run it: 1. You need to use chcp 65001 to set the console code page to UTF8 2. It is very likely that your Windows console won't have the fonts required to actually make sense of the output. Pipe the output to foo.txt. If you open this file in notepad you will see the correct characters show up. If you want to see the actual correct output in the console, there are some more issues: 1. You need to do some registry hacking to use e.g. SimSum Regular as the console font. 2. Even if you do this, my understanding is that it probably won't work (you will still get junk output in the form of the actual UTF-8 bytes). I think you would instead need to use chcp 936 (the Simplified Chinese GBK code page) which tells the Windows API to output GBK code points instead of the UTF-8 encoding. These should then render correctly. However, to install the code page so chcp works you need to have East Asian language support installed (so Windows 7 Professional users like me are out of luck, because it appears to have been dropped in favour of Language packs, which are only available for 7 Ultimate/Enterprise...) I don't know how all this would adapt to the lambda character. Maybe you need to use a Greek code page?? And I have no idea where that permission denied error is coming from. In summary, this will probably never work properly. This sort of rubbish is why I switched to OS X :-) Cheers, Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: Unicode windows console output.
Hello Max, Wednesday, November 3, 2010, 1:26:50 PM, you wrote: 1. You need to use chcp 65001 to set the console code page to UTF8 2. It is very likely that your Windows console won't have the fonts required to actually make sense of the output. Pipe the output to foo.txt. If you open this file in notepad you will see the correct characters show up. it will work even without chcp. afaik nor ghc nor windows adjusts text being output to current console codepage -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Loop optimisation with identical counters
Thanks, I'll do some measurements on this with ghc7.
Gruss,
Christian
On 11/02/2010 01:23 PM, Simon Marlow wrote:
On 02/11/2010 08:17, Christian Höner zu Siederdissen wrote:
Hi,
is the following problem a job for ghc or the code generation backend
(llvm)?
We are given this program:
{-# LANGUAGE BangPatterns #-}
module Main where
f :: Int - Int - Int - Int - Int
f !i !j !s !m
| i == 0= s+m
| otherwise = f (i-1) (j-1) (s + i+1) (m + j*5)
g :: Int - Int
g !k = f k k 0 0
ff :: Int - Int - Int - Int
ff !i !s !m
| i == 0= s+m
| otherwise = ff (i-1) (s + i+1) (m + i*5)
gg :: Int - Int
gg !k = ff k 0 0
main = do
print $ g 20
print $ gg 20
Here, 'f' and 'g' are a representation of the code I have. Both counters
'i' and 'j' in 'f' count from the same value with the same step size and
terminate at the same time but are not reduced to just one counter. Can
I reasonably expect this to be done by the code generator?
'ff' represents what I would like to see.
GHC doesn't have any optimisations that would do this currently,
although it's possible that LLVM's loop optimisations might do this on
the generated code for f.
Cheers,
Simon
Btw. look at the core, to see that indeed 'f' keep four arguments.
Functions like 'f' are a result of vector-fusion at work but can be
written by oneself as well. The point is that if 'f' gets reduced to
'ff' then I can have this:
fun k = zipWith (+) (map f1 $ mkIdxs k) (map f2 $ mkIdxs k)
which makes for nicer code sometimes; but before rewriting I wanted to
ask if that kills performance.
Thanks,
Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Loop optimisation with identical counters
On 3 Nov 2010, at 10:45, Christian Hoener zu Siederdissen
choe...@tbi.univie.ac.at wrote:
Thanks, I'll do some measurements on this with ghc7.
Gruss,
Christian
On 11/02/2010 01:23 PM, Simon Marlow wrote:
On 02/11/2010 08:17, Christian Höner zu Siederdissen wrote:
Hi,
is the following problem a job for ghc or the code generation backend
(llvm)?
We are given this program:
{-# LANGUAGE BangPatterns #-}
module Main where
f :: Int - Int - Int - Int - Int
f !i !j !s !m
| i == 0= s+m
| otherwise = f (i-1) (j-1) (s + i+1) (m + j*5)
g :: Int - Int
g !k = f k k 0 0
ff :: Int - Int - Int - Int
ff !i !s !m
| i == 0= s+m
| otherwise = ff (i-1) (s + i+1) (m + i*5)
gg :: Int - Int
gg !k = ff k 0 0
main = do
print $ g 20
print $ gg 20
Here, 'f' and 'g' are a representation of the code I have. Both counters
'i' and 'j' in 'f' count from the same value with the same step size and
terminate at the same time but are not reduced to just one counter. Can
I reasonably expect this to be done by the code generator?
'ff' represents what I would like to see.
GHC doesn't have any optimisations that would do this currently,
although it's possible that LLVM's loop optimisations might do this on
the generated code for f.
Cheers,
Simon
Btw. look at the core, to see that indeed 'f' keep four arguments.
Functions like 'f' are a result of vector-fusion at work but can be
written by oneself as well. The point is that if 'f' gets reduced to
'ff' then I can have this:
fun k = zipWith (+) (map f1 $ mkIdxs k) (map f2 $ mkIdxs k)
which makes for nicer code sometimes; but before rewriting I wanted to
ask if that kills performance.
Thanks,
Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: link problem under macosx
On Wed, Nov 3, 2010 at 9:55 AM, Christian Maeder christian.mae...@dfki.dewrote: Am 02.11.2010 18:03, schrieb Thorkil Naur: Hello, On Tue, Nov 02, 2010 at 01:03:04PM +0100, Christian Maeder wrote: ... Are there better workarounds? I am not sure about that, I assume that you have looked at http://hackage.haskell.org/trac/ghc/ticket/4068? no, I found Simon Michael's message http://www.mail-archive.com/haskell-c...@haskell.org/msg81961.html by chance. I did not try out his extra-lib-dirs proposal, since all cabal packages were already installed. And I agree with him that it should be documented somewhere more prominent and that avoiding macports is no (good) solution. I'll add his proposal to your (closed) ticket to increase the hit rate. Cheers Christian His proposed solution works until you try to link a Haskell project to a macports lib that requires libiconv. It's also inconvenient that you'll sometimes need to unpack hackage code and manually edit the .cabal file. If you want to use macports, the only real solution is to build a GHC+libs that prefers /opt/local/ to the system-installed locations. The macports GHC does this, or you can try to compile it yourself with appropriate flags to configure (whatever they may be). John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Loop optimisation with identical counters
LLVM doesn't eliminate the counters. FWIW, fixing this would improve
performance of stream fusion code quite a bit. It's very easy to do in Core.
Roman
On 3 Nov 2010, at 10:45, Christian Hoener zu Siederdissen
choe...@tbi.univie.ac.at wrote:
Thanks, I'll do some measurements on this with ghc7.
Gruss,
Christian
On 11/02/2010 01:23 PM, Simon Marlow wrote:
On 02/11/2010 08:17, Christian Höner zu Siederdissen wrote:
Hi,
is the following problem a job for ghc or the code generation backend
(llvm)?
We are given this program:
{-# LANGUAGE BangPatterns #-}
module Main where
f :: Int - Int - Int - Int - Int
f !i !j !s !m
| i == 0= s+m
| otherwise = f (i-1) (j-1) (s + i+1) (m + j*5)
g :: Int - Int
g !k = f k k 0 0
ff :: Int - Int - Int - Int
ff !i !s !m
| i == 0= s+m
| otherwise = ff (i-1) (s + i+1) (m + i*5)
gg :: Int - Int
gg !k = ff k 0 0
main = do
print $ g 20
print $ gg 20
Here, 'f' and 'g' are a representation of the code I have. Both counters
'i' and 'j' in 'f' count from the same value with the same step size and
terminate at the same time but are not reduced to just one counter. Can
I reasonably expect this to be done by the code generator?
'ff' represents what I would like to see.
GHC doesn't have any optimisations that would do this currently,
although it's possible that LLVM's loop optimisations might do this on
the generated code for f.
Cheers,
Simon
Btw. look at the core, to see that indeed 'f' keep four arguments.
Functions like 'f' are a result of vector-fusion at work but can be
written by oneself as well. The point is that if 'f' gets reduced to
'ff' then I can have this:
fun k = zipWith (+) (map f1 $ mkIdxs k) (map f2 $ mkIdxs k)
which makes for nicer code sometimes; but before rewriting I wanted to
ask if that kills performance.
Thanks,
Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: link problem under macosx
From: Simon Michael si...@joyful.com On 11/2/10 10:20 AM, John Lato wrote: Since Apple seems disinclined to fix the system's libiconv, and macports projects refuse to use it, the only real solution is to use either HP without macports or the macports GHC without HP. Personally I chose to use the HP and Not so, as mentioned you just need to make sure /usr/lib is in the link path before /opt/local/lib. Add -L/usr/lib to your build flags for ghc --make, and put: extra-lib-dirs: /usr/lib extra-lib-dirs: /opt/local/lib in that order in ~/.cabal/config for cabal build. This is a very FAQ and needs to be documented somewhere more obvious, I wonder where. cabal-install and GHC release notes ? As I mentioned in another reply, this worked for me until I tried to link to a macports lib (I think some regex lib) that actually used the macports libiconv (a lot of them don't even if they pull in the dependency). Then I was really stuck because I had dependencies on two different libiconv's, and neither one would link properly. As such, I consider this a pretty fragile solution. John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MonoLocalBinds and darcs
On Wed, Nov 03, 2010 at 10:10:53AM +, Simon Peyton-Jones wrote: Well, I'm aware that it's a compromise. I don't know how to do a bang-up principled job of typechecking local polymorphism, so GHC does a best-effort job. In fact best effort is pretty good, and it's not hard to implement, so a) I don't expect to remove NoLocalMonoBinds b) I expect it will work fine 99% of the time What happens in the other 1%? Does the program just get rejected for no apparent reason, or can more nefarious things happen? Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Loop optimisation with identical counters
Is there a ticket for this (didn't find one)? Or should there be?
For some reason, I'd like to see this in ghc ;-)
Gruss,
Christian
On 11/03/2010 11:54 AM, Roman Leshchinskiy wrote:
LLVM doesn't eliminate the counters. FWIW, fixing this would improve
performance of stream fusion code quite a bit. It's very easy to do in Core.
Roman
On 3 Nov 2010, at 10:45, Christian Hoener zu Siederdissen
choe...@tbi.univie.ac.at wrote:
Thanks, I'll do some measurements on this with ghc7.
Gruss,
Christian
On 11/02/2010 01:23 PM, Simon Marlow wrote:
On 02/11/2010 08:17, Christian Höner zu Siederdissen wrote:
Hi,
is the following problem a job for ghc or the code generation backend
(llvm)?
We are given this program:
{-# LANGUAGE BangPatterns #-}
module Main where
f :: Int - Int - Int - Int - Int
f !i !j !s !m
| i == 0= s+m
| otherwise = f (i-1) (j-1) (s + i+1) (m + j*5)
g :: Int - Int
g !k = f k k 0 0
ff :: Int - Int - Int - Int
ff !i !s !m
| i == 0= s+m
| otherwise = ff (i-1) (s + i+1) (m + i*5)
gg :: Int - Int
gg !k = ff k 0 0
main = do
print $ g 20
print $ gg 20
Here, 'f' and 'g' are a representation of the code I have. Both counters
'i' and 'j' in 'f' count from the same value with the same step size and
terminate at the same time but are not reduced to just one counter. Can
I reasonably expect this to be done by the code generator?
'ff' represents what I would like to see.
GHC doesn't have any optimisations that would do this currently,
although it's possible that LLVM's loop optimisations might do this on
the generated code for f.
Cheers,
Simon
Btw. look at the core, to see that indeed 'f' keep four arguments.
Functions like 'f' are a result of vector-fusion at work but can be
written by oneself as well. The point is that if 'f' gets reduced to
'ff' then I can have this:
fun k = zipWith (+) (map f1 $ mkIdxs k) (map f2 $ mkIdxs k)
which makes for nicer code sometimes; but before rewriting I wanted to
ask if that kills performance.
Thanks,
Christian
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
generating C stubs with GHC API
I would like to get access to functions exported from Haskell module and to generate custom stubs for them using GHC API. As I understand, I need to obtain a list of ForeignDecl's (data structure defined in HsDecls GHC module) for given source module. How to achieve this with GHC API? -- Victor Nazarov ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Fixing LDAP lib compilation on OpenBSD
Hi, Thank you very much, I managed to achieve the conditional compilation as you describe. Now I am investigating which macro named is most common. In this matter it seems that the OpenLDAP folks have renamed the macro themselves from version 2.4. The OpenBSD folks are still in 2.3 (after the 4.8 upgrade), so I will go for OpenBSD being the exception. Anyway thank you again for your help, -- Julien Dessaux On Tue, Nov 2, 2010 at 5:58 PM, Matthias Kilian k...@outback.escape.dewrote: On Sat, Oct 30, 2010 at 07:28:40PM +0200, Julien Dessaux wrote: I'm using the LDAP lib for one of my projects and I found a problem while building it on an OpenBSD system. It wouldn't compile because there is a macro named differently in the ldap.h include file. Under linux, this macro is named LDAP_X_PROXY_AUTHZ_FAILURE but on OpenBSD (and probably other BSD flavours), it's named LDAP_PROXY_AUTHZ_FAILURE. I attached the diff I wrote in order to compile the lib on OpenBSD, but it's not a patch I can submit cause it now won't compile on Linux. How can I amend this in order to have a code that would compile on both systems? How is it possible to specify such conditional system dependent stuff for a C binding? You can use different CC-Options in LDAP.cabal depending on the OS. For example if os(openbsd) CC-Options: -DLDAP_X_PROXY_AUTHZ_FAILURE=LDAP_PROXY_AUTHZ_FAILURE else CC-Options: -DLDAP_DEPRECATED=1 Or, if LDAP_X_PROXY_AUTHZ_FAILURE is only used on Linux, just do it reverse, i.e. patch the sources to use LDAP_PROXY_AUTHZ_FAILURE and conditionally define it as LDAP_X_PROXY_AUTHZ_FAILURE on Linux; whatever fits better. Ciao, Kili ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unicode windows console output.
On Wed, Nov 3, 2010 at 9:00 AM, Simon Marlow marlo...@gmail.com wrote: On 03/11/2010 10:36, Bulat Ziganshin wrote: Hello Max, Wednesday, November 3, 2010, 1:26:50 PM, you wrote: 1. You need to use chcp 65001 to set the console code page to UTF8 2. It is very likely that your Windows console won't have the fonts required to actually make sense of the output. Pipe the output to foo.txt. If you open this file in notepad you will see the correct characters show up. it will work even without chcp. afaik nor ghc nor windows adjusts text being output to current console codepage GHC certainly does. We use GetConsoleCP() when deciding what code page to use by default - see libraries/base/GHC/IO/Encoding/CodePage.hs. This can actually be quite helpful. I've discovered that if you have a console set to code page 65001 (UTF-8) and use WriteConsoleA (the non-wide version) with UTF-8 encoded strings, the console displays the text properly! So the solution seems to be, when outputting to a utf8 console use WriteConsoleA. David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
I would love to know the answer to this.
On Tue, Nov 2, 2010 at 3:36 PM, Jeremy Shaw jer...@n-heptane.com wrote:
Hello,
I have a module, XMLGenerator, which has some overlapping instances.
I have a second module, Test, which imports that module and also adds
some more overlapping instances.
Both modules contain {-# LANGUAGE OverlappingInstances #-} at the top.
Under some old version of 6.13 (and probably 6.12), if I put both
modules in the same directory and try to load Test.hs, it gets the
error:
Test.hs:16:15:
Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
arising from a use of `asChild' at Test.hs:16:15-21
Matching instances:
instance (m1 ~ m, EmbedAsChild m c) =
EmbedAsChild m (XMLGenT m1 c)
-- Defined at XMLGenerator.hs:16:10-68
instance (XML m ~ x, XMLGen m) = EmbedAsChild m x
-- Defined at XMLGenerator.hs:19:10-51
In the first argument of `($)', namely `asChild'
In the expression: asChild $ (genElement foo)
In the definition of `asChild':
asChild b = asChild $ (genElement foo)
If I put the XMLGenerator module in a separate package, dummy-hsx, and
the Test modules links against it, I still get the error.
*but* if I add:
Extensions: OverlappingInstances
to the dummy-hsx.cabal file, then Test.hs compiles just fine! So, for
starters, I do not understand why that happens.
Under GHC 7.0rc1, modifying the .cabal file has no effect. Instead I
always get the error:
Test.hs:16:15:
Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
arising from a use of `asChild'
Matching instances:
instance [overlap ok] (m1 ~ m, EmbedAsChild m c) =
EmbedAsChild m (XMLGenT m1 c)
-- Defined in XMLGenerator
(The choice depends on the instantiation of `m'
To pick the first instance above, use -XIncoherentInstances
when compiling the other instance declarations)
Adding the IncoherentInstances flag does make it compile -- but I have
never enabled that flag and not regretted it.
What changed between GHC 6.12 and GHC 7.0? Is there a some solution
besides using IncoherentInstances in every module that imports
XMLGenerator?
I have attached XMLGenerator.hs, Test.hs, and dummy-hsx.cabal.
thanks!
- jeremy
___
Haskell-Cafe mailing list
haskell-c...@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
