Re: libedit-20080712-2.11 under x86 Solaris
On Thu, Oct 9, 2008 at 9:03 AM, Christian Maeder [EMAIL PROTECTED] wrote: Hi, I've installed libedit-20080712-2.11 (from sources) for ghc-6.10.0.20081007 under x86 Solaris. However, ghci comes up with: GHCi, version 6.10.0.20081007: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. No entry for terminal type xterm; using dumb terminal settings. Prelude The keys work, but how do I get rid of No entry for terminal type xterm; using dumb terminal settings. ? I have a file /usr/local/share/terminfo/x/xterm (but no terminfo under /usr/share/) Any ideas? Thanks Christian Strange; it seems like terminfo isn't looking in the right location for the xterm files. Incidentally, the dumb terminal settings may be deficient when you type a line longer than the terminal width. What OS is this? Did you download and install (n)curses manually? Can you use some program to monitor the filesystem (for example, fs_usage on OS X) and see where the program is looking for the terminfo databases? -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: libedit
On Thu, Oct 9, 2008 at 5:30 AM, Christian Maeder [EMAIL PROTECTED] wrote: Hi Judah, after installing rpm packages libedit0-2.10.snap20070831-5 libedit-devel-2.10.snap20070831-5 I get the error below for cabal install editline Cheers Christian checking editline/readline.h usability... yes checking editline/readline.h presence... yes checking for editline/readline.h... yes checking for sign of read_history result on error... positive configure: creating ./config.status config.status: creating editline.buildinfo config.status: creating include/HsEditlineConfig.h Preprocessing library editline-0.2... In file included from Editline.hsc:52:0: include/HsEditline.h:11:0: error: conflicting types for 'el_get' /usr/include/histedit.h:112:0: error: previous declaration of 'el_get' was here compiling dist/build/System/Console/Editline_hsc_make.c failed command was: /home/linux-bkb/ghc/ghc-6.8.3/bin/ghc -c -package base-3.0.2.0 -Iinclude dist/build/System/Console/Editline_hsc_make.c -o dist/build/System/Console/Editline_hsc_make.o cabal: Error: some packages failed to install: editline-0.2 failed during the building phase. The exception was: exit: ExitFailure 1 Hi Christian, I think this is fixed in darcs (http://code.haskell.org/editline); can you try seeing if that works for you? I'll work on getting the updated editline package onto hackage as well. Thanks, -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
cabal-1.6.0.0
I've tagged Cabal-1.6.0.0 and the tarball is on the cabal website. http://haskell.org/cabal/download.html Tomorrow I'll update the version of Cabal that hackage is using and upload Cabal-1.6.0.0 to hackage. We're also planning to bump and upload the extralib packages tomorrow. I also hope to release cabal-install-0.6.0 in the next couple days. In the mean time please use the darcs version and report any issues. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: breakage with Cabal-1.6
* Takusen-0.8.3 Imports writeHookedBuildInfo from Distribution.PackageDescription While the fix for these three packages' Setup scripts is trivial, there is not fix that will make them compile with old and new versions of the lib. For Takusen I'd be happy to fix the Setup and require the latest Cabal in order to build. That's what we've done in the past. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Backspace in ghci-6.10.1-candidate
On Thu, Oct 9, 2008 at 1:28 AM, Serge D. Mechveliani [EMAIL PROTECTED] wrote: This is about testing 6.10.0.20081007. 1. DoCon works with it. 2. The question is how to `install' Backspace and UpArrow in ghci. I make it from source by 6.10-candidate and also by itself -- on Debian Linux. And ghci does not process Backspace and UpArrow. ./configure reported configure:2303: checking whether ghc has editline package configure:2314: result: no And the Debian system area shows the files /usr/lib/libedit.so.2 /usr/lib/iceape/components/libeditor.so /usr/lib/libedit.so.2.9 The editline package requires the header files, not just the .so libraries. You can get those by installing the editline-dev package. (After which you'll need to rebuild ghc.) Best, -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: thread/socket behvior
Jeff Polakow wrote: Don Stewart [EMAIL PROTECTED] wrote on 10/09/2008 02:56:02 PM: jeff.polakow: We have a server that accepts messages over a socket, spawning threads to process them. Processing these messages may cause other, outgoing connections, to be spawned. Under sufficient load, the main server loop (i.e. the call to accept, followed by a forkIO), becomes nonresponsive. A smaller distilled testcase reveals that when sufficient socket activity is occurring, an incoming connection may not be responded to until other connections have been cleared out of the way, despite the fact that these other connections are being handled by separate threads. One issue that we've been trying to figure out is where this behavior arises from-- the GHC rts, the Network library, the underlying C libraries. Have other GHC users doing applications with large amounts of socket usage observed similar behavior and managed to trace back where it originates from? Are there any particular architectural solutions that people have found to work well for these situations? Hey Jeff, Can you say which GHC you used, and whether you used the threaded runtime or non-threaded runtime? Oops, forgot about that... We used both ghc-6.8.3 and ghc-6.10.rc1 and we used the threaded runtime. We are running on a 64 bit linux machine using openSUSE 10. The scheduler doesn't have a concept of priorities, so the accepting thread will get the same share of the CPU as the other threads. Another issue is that the accepting thread has to be woken up by the IO manager thread when a new connection is available, so we might have to wait for the IO manager thread to run too. But I wouldn't expect to see overly long delays. Maybe you could try network-alt which does its own IO multiplexing. If you have multiple cores, you might want to try fixing the thread affinity - e.g. put all the worker threads on one core, and the accepting thread on the other core. You can do this using GHC.Conc.forkOnIO, with the +RTS -qm -qw options. Other than that, I'm not sure what to try right now. We're hoping to get some better profiling for parallel/concurrent programs in the future, but it's not ready yet. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 RC 1
Judah Jacobson wrote: Once small thing I've noticed: UserInterrupt (ctr-c) exceptions are not thrown in ghci, probably because it installs its own signal handlers: Prelude Control.Exception Control.Concurrent handle (\UserInterrupt - putStrLn Caught!) (threadDelay 200) ^CInterrupted. For consistency between the compiled and interpreted environments, it would be nice if the above could catch the ctrl-c. But maybe there's a reason not to do this? If this change sounds OK, I can take a look at this and try to put together a patch over the weekend. Hmm, tricky one. I agree with the argument for consistency, but on the other hand you might also want a way to interrupt a computation regardless, and that almost works - as long as the program isn't discarding exceptions it knows nothing about. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacPorts will use _only_ a ghc built with port install ghc, no other
Hi, Denis wanted to install pandoc form MacPorts and got problems (below), because he has installed my ghc-6.8.3-powerpc binary. If my binary works you could download http://hackage.haskell.org/packages/archive/pandoc/1.0.0.1/pandoc-1.0.0.1.tar.gz unpack and do the runhaskell Setup configure runhaskell Setup build sudo runhaskell Setup install business (http://www.haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_package) also for all missing dependencies, i.e. http://hackage.haskell.org/packages/archive/zip-archive/0.1.1/zip-archive-0.1.1.tar.gz I don't know if or how this interferes with MacPorts. Cheers Christian port deps pandoc = pandoc has build dependencies on: ghc haddock pandoc has library dependencies on: gmp denis wrote: Thanks Greg, fair enough. Could you or Christian suggest to the owners of http://haskell.org/ghc/download_ghc_683.html something along the lines of MacPorts users note: MacPorts will use /only/ a ghc built with port install ghc, no other. so the next guy doesn't run into the same wall ? Hi, MacPorts uses a known good binary ghc bootstrap compiler to build ghc from source. We won't support building using another bootstrap compiler, which seems to be what you want to do. (ghc is hard enough to build with a known good compiler, and we don't have the resources to debug unsupported configurations.) Best Wishes, Greg ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC 6.10.1 RC 1
On Wed, Oct 8, 2008 at 1:09 PM, Ian Lynagh [EMAIL PROTECTED] wrote: We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the first release candidate for GHC 6.10.1. You can download the release candidate from here: http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html This page includes: * a Windows installer * an OS X installer * bindists for amd64/Linux and ix86/Linux * the sources There is also a status page here: http://hackage.haskell.org/trac/ghc/wiki/GHC-6.10.1 where we will keep track of where the RC works, and where it is known to have problems. This is a wiki page, so please feel free to update it if you are able to add or update the information on a particular platform. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope that we will be able to make the final release in around one weeks time, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team Once small thing I've noticed: UserInterrupt (ctr-c) exceptions are not thrown in ghci, probably because it installs its own signal handlers: Prelude Control.Exception Control.Concurrent handle (\UserInterrupt - putStrLn Caught!) (threadDelay 200) ^CInterrupted. For consistency between the compiled and interpreted environments, it would be nice if the above could catch the ctrl-c. But maybe there's a reason not to do this? If this change sounds OK, I can take a look at this and try to put together a patch over the weekend. Thanks, -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: libedit-20080712-2.11 under x86 Solaris
Judah Jacobson wrote: Strange; it seems like terminfo isn't looking in the right location for the xterm files. Incidentally, the dumb terminal settings may be deficient when you type a line longer than the terminal width. What OS is this? Did you download and install (n)curses manually? SunOS 5.10 Generic_137112-07 i86pc i386 i86pc In fact ncurses was the problem. My LD_LIBRARY_PATH pointed to a copied version of libncurses.so.5 (pointing to libncurses.so.5.6) that was later replaced by our admins (maybe they've noticed such a problem, too). Now it works. Thanks and sorry for the trouble. Can you use some program to monitor the filesystem (for example, fs_usage on OS X) and see where the program is looking for the terminfo databases? (I didn't find something) Cheers Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: breakage with Cabal-1.6
Duncan Coutts wrote: * alex-2.2 * happy-1.17 Imports buildVerbose from Distribution.Simple.Setup ( BuildFlags(..) ) however the flag has been renamed to buildVerbosity and with a different type. I would export a compat function but it would not help here since the Setup script expects it to be a record selector from BuildFlags. Cabal-1.4 contained a dodgy hack to make this continue to work, but I'm not doing that again. If I added a compat function then we could at least make it work with both ghc/cabal versions with a single implementation. So I might do that and do point releases of these packages, if Simon thinks that's ok. Really of course both packages should stop calling an external perl and other similar madness. I can stop calling Perl, but I still need to run CPP, so I still need the runProgram stuff, which means I still need buildVerbose/buildVerbosity. As far as I can see, you could export a compatibility shim called buildVerbose without any difficulty, all I have to do is remove the explicit import list. Or is there a better fix you had in mind? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Backspace in ghci-6.10.1-candidate
On Fri, Oct 10, 2008 at 1:42 AM, Judah Jacobson [EMAIL PROTECTED] wrote: On Thu, Oct 9, 2008 at 1:28 AM, Serge D. Mechveliani [EMAIL PROTECTED] wrote: This is about testing 6.10.0.20081007. 1. DoCon works with it. 2. The question is how to `install' Backspace and UpArrow in ghci. I make it from source by 6.10-candidate and also by itself -- on Debian Linux. And ghci does not process Backspace and UpArrow. ./configure reported configure:2303: checking whether ghc has editline package configure:2314: result: no And the Debian system area shows the files /usr/lib/libedit.so.2 /usr/lib/iceape/components/libeditor.so /usr/lib/libedit.so.2.9 The editline package requires the header files, not just the .so libraries. You can get those by installing the editline-dev package. (After which you'll need to rebuild ghc.) Correction: you probably want the Debian libedit-dev package. -Judah ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
readEither in ghc-6.10. ?
Hi, I've got errors when compiling with ghc-6.10.0.20081007 Not in scope: `readEither' It is imported via: import GHC.Read (readEither) and used to work with ghc-6.8. What should I use as replacement? Cheers Christian P.S. It is also not mentioned in the changes: http://www.haskell.org/ghc/dist/stable/docs/users_guide/release-6-10-1.html ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Breakage with ghc-6.10
This is a quick summary of the results of building most of hackage using
three combinations of ghc and Cabal.
I reported the breakage due to Cabal-1.6 previously. This is a brief
look at breakage introduced with ghc-6.10 and the associated library
changes.
I have build summary logs and individual package build logs. I will post
those later. Anyway, here's the summary of the summary:
ghc-6.8.2 Cabal-1.4.0.2
1 UnpackFailed
3 InstallFailed
20 ConfigureFailed
27 DependencyFailed
87 BuildFailed
547 InstallOk
ghc-6.8.2 Cabal-1.5.6
1 UnpackFailed
3 InstallFailed
26 ConfigureFailed
27 DependencyFailed
87 BuildFailed
541 InstallOk
ghc-6.10.0 (5th Oct version) Cabal-1.6.0.0
1 InstallFailed
21 ConfigureFailed
121 DependencyFailed
126 BuildFailed
422 InstallOk
If we look at a breakdown of the builds that caused three or more
knock-on failures (ie the causes of the 121 DependencyFailed above):
3 hxt-8.1.0
4 hsql-1.7
4 hsx-0.4.4
4 plugins-1.3
4 TypeCompose-0.5
6 arrows-0.4
24 hslogger-1.0.5
46 time-1.1.2.1
Hmm, time and hslogger are big ones there. Let's look at the individual
package build logs. First time:
Data/Time/Clock/CTimeval.hs:1:11:
Warning: -ffi is deprecated: use -XForeignFunctionInterface or
pragma {-# LANGUAGE ForeignFunctionInterface#-} instead
no location info:
Failing due to -Werror.
Nooo!!
This is the reason that hackage now rejects the use of -Werror in
released packages. It causes unnecessary breakage when new compilers add
new warnings.
Ok, lets look at hslogger:
src/System/Log/Logger.hs:333:20:
Couldn't match expected type `Maybe Logger'
against inferred type `IO Logger'
In a stmt of a 'do' expression: result - Map.lookup lname newlt
Ah ok, so that's the change in Map.lookup to return Maybe rather than in
any monad. So that's an easy source code fix:
result - maybe (fail Arrgh!) return (Map.lookup lname newlt)
Note of course this will also work with the previous implementation of
lookup.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Breakage with ghc-6.10
On Fri, 2008-10-10 at 09:08 -0700, Duncan Coutts wrote:
Data/Time/Clock/CTimeval.hs:1:11:
Warning: -ffi is deprecated: use -XForeignFunctionInterface or
pragma {-# LANGUAGE ForeignFunctionInterface#-} instead
no location info:
Failing due to -Werror.
Nooo!!
This is the reason that hackage now rejects the use of -Werror in
released packages. It causes unnecessary breakage when new compilers
add new warnings.
Warnings in a build process should be fixed, not ignored (and, I would
say, fixed by whoever introduced the warning or otherwise broke the
build).
Hackage, on the other hand, is right to reject -Werror in .cabal files,
as there the build is really part of the install process and should be
as lenient as possible. I pass --ghc-options=-Wall -Werror to cabal in
a Makefile in most of my projects, so that my development build process
is strict.
--
Ashley Yakeley
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Breakage with ghc-6.10
Duncan Coutts wrote: Ok, lets look at hslogger: src/System/Log/Logger.hs:333:20: Couldn't match expected type `Maybe Logger' against inferred type `IO Logger' In a stmt of a 'do' expression: result - Map.lookup lname newlt Ah ok, so that's the change in Map.lookup to return Maybe rather than in any monad. So that's an easy source code fix: result - maybe (fail Arrgh!) return (Map.lookup lname newlt) There are actually more instances than this in the code, but I already have fixed it in my git tree. I guess it's time to make a release. -- John Note of course this will also work with the previous implementation of lookup. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Breakage with ghc-6.10
Sorry Ashley, I hope you didn't feel I was picking on you in particular. I realise it might have looked that way. On Fri, 2008-10-10 at 11:08 -0700, Ashley Yakeley wrote: On Fri, 2008-10-10 at 09:08 -0700, Duncan Coutts wrote: Failing due to -Werror. Nooo!! This is the reason that hackage now rejects the use of -Werror in released packages. It causes unnecessary breakage when new compilers add new warnings. Warnings in a build process should be fixed, not ignored (and, I would say, fixed by whoever introduced the warning or otherwise broke the build). Yes indeed. So it's appropriate for development builds. Hackage, on the other hand, is right to reject -Werror in .cabal files, as there the build is really part of the install process and should be as lenient as possible. I pass --ghc-options=-Wall -Werror to cabal in a Makefile in most of my projects, so that my development build process is strict. Right. Putting -Wall in the ghc-options in the .cabal file is fine too of course. Lots of packages do that. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Breakage with ghc-6.10
Duncan Coutts wrote: There are actually more instances than this in the code, but I already have fixed it in my git tree. I guess it's time to make a release. Yay! Between that and a bump for the time lib we'll probably have another ~50 packages building with 6.10. And on that note, hslogger 1.0.6 is now in Hackage. -- John ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Breakage with ghc-6.10
jgoerzen: Duncan Coutts wrote: There are actually more instances than this in the code, but I already have fixed it in my git tree. I guess it's time to make a release. Yay! Between that and a bump for the time lib we'll probably have another ~50 packages building with 6.10. And on that note, hslogger 1.0.6 is now in Hackage. Great! I'll do a new hackage build test. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Breakage with 6.10
Quick summary of the latest hackage state, now hslogger has been amended. x86_64/linux/ghc-6.10/cabal-install 0.6/Cabal 1.6 1 UnpackFailed 2 DownloadFailed 2 InstallFailed 16 ConfigureFailed 71 DependencyFailed 138 BuildFailed 447 InstallOk So you can see that DependencyFailed is down 30, thanks to hslogger now working. InstallOk is up about 23. A breakdown of the remaing causes for DependencyFailed, 2 Win32-2.1.0.0 2 Yampa-0.9.2.2 2 hint-0.2.4.1 2 hsdns-1.3 2 plugins-1.3 3 pandoc-1.0.0.1 3 stringtable-atom-0.0.4 4 TypeCompose-0.5 4 hsql-1.7 4 hsx-0.4.4 5 hxt-8.1.0 6 HAppS-Data-0.9.2.1 6 arrows-0.4 6 wxcore-0.10.3 The main thing to fix there is 'arrows', an extra lib, we'll bump that. arrows fails due to: [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:24:29: Module `Control.Arrow' does not export `pure' Even though cabal-install decided to use base-3.0.3.0 So that means base-3 is *not* exporting quite the same interface as last time. Were we aware of this? -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Breakage with 6.10
On Fri, 2008-10-10 at 15:34 -0700, Don Stewart wrote: arrows fails due to: [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:24:29: Module `Control.Arrow' does not export `pure' Even though cabal-install decided to use base-3.0.3.0 So that means base-3 is *not* exporting quite the same interface as last time. Were we aware of this? Note that this means that base-3 should have the version number 3.1.x.y because there is at least one incompatible api change. We're promoting the versioning policy so we need to follow it ourselves in our base libs. On this issue, we've discussed before that packages should be able to opt-into the versioning policy and that if they do we can have our tools suggest that dependencies on such packages should take a particular form. For example depending on and api version ==1.1.* and not upward open ranges, or mistakes like parsec = 2.1.0.0. There's not time to implement these suggestions in the tools for 6.10 however we do have the opportunity to annotate the packages that we believe do follow the versioning policy. We can then get our tools make use of this information in the coming months. So my suggestion is that in time for 6.10.1 we add something like the following to the .cabal files for all the core and extra packages: x-follows-version-policy: This is free. It doesn't involve any api changes in Cabal or anything else. All such x- extension fields are allowed by cabal and collected into a name/value pair list. If it seems to work out then we can make it a proper field (and at that time we can argue what colour we should paint it). Sound sensible? We can send patches to add this to the core + extra packages. I think it'd be good to do this now because while the base 3 - 4 thing has gone fairly well this time, future changes would be much easier if we were using more sensible dependency constraints. I think the best way to communicate that to developers is through warnings generated by their tools. Yes that's right, cabal-install is a channel for package QA propaganda. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Illegal type synonym family application in instance (Was: Breakage with 6.10)
dons: A breakdown of the remaing causes for DependencyFailed, [...] 4 hsx-0.4.4 --- src/hsx$ runhaskell Setup build [snip warnings] src\HSX\XMLGenerator.hs:71:0 Illegal type synonym family application in instance: XML m In the instance declaration for `EmbedAsChild m (XML m)´ --- Could someone help me point out the problem here? The relevant code is: instance XMLGen m = EmbedAsChild m (XML m) where asChild = return . return . xmlToChild class XMLGen m = EmbedAsChild m c where asChild :: c - GenChildList m class Monad m = XMLGen m where type XML m This works fine with 6.8.3, so what's new in 6.10, and what would I do to solve it? Btw, I also have problems with the haskell-src-exts that imports Data.Generics.Instances (to generate Data and Typeable instances). Where would these have moved to in the new base? And how would I make the code work with both 6.8.3 and 6.10? Thanks, /Niklas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Illegal type synonym family application in instance (Was: Breakage with 6.10)
Could someone help me point out the problem here? The relevant code is: instance XMLGen m = EmbedAsChild m (XML m) where asChild = return . return . xmlToChild class XMLGen m = EmbedAsChild m c where asChild :: c - GenChildList m class Monad m = XMLGen m where type XML m Eh, reading that again I realize there's a bit code needed to understand the above. So here's *really* the relevant code: class Monad m = XMLGen m where type XML m data Child m xmlToChild :: XML m - Child m [] class XMLGen m = EmbedAsChild m c where asChild :: c - GenChildList m instance XMLGen m = EmbedAsChild m (XML m) where asChild = return . return . xmlToChild ... and just a note that GenChildList is a type synonym for a certain monad returning a list, hence the double returns. :-) Cheers, /Niklas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Illegal type synonym family application in instance (Was: Breakage with 6.10)
On Sat, 2008-10-11 at 02:40 +0200, Niklas Broberg wrote: Btw, I also have problems with the haskell-src-exts that imports Data.Generics.Instances (to generate Data and Typeable instances). Where would these have moved to in the new base? And how would I make the code work with both 6.8.3 and 6.10? By having it use base-3 rather than 4. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
base-3 vs base-4 (Was: Breakage with 6.10)
Btw, I also have problems with the haskell-src-exts that imports Data.Generics.Instances (to generate Data and Typeable instances). Where would these have moved to in the new base? And how would I make the code work with both 6.8.3 and 6.10? By having it use base-3 rather than 4. Right, and that's how I quickly fixed it up for now. But this doesn't sound like a long-term solution to me, I would prefer to use the new base-4 when possible. The cabal file already includes a conditional if flag(splitBase) to handle really old versions, I guess what I'm asking for is something similar for this case. Is there a splitSyb flag or some such? Though obviously this would only work if the module Data.Generics.Instances was preserved under that name somewhere else. If it was renamed or changed (which I suspect), then the hassle of keeping up to date with older versions will probably be too much, and I will want to update to the new agenda as soon as 6.10 is released for real. So what happened to this module? (Is there a migration quicksheet somewhere?) Cheers, /Niklas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Illegal type synonym family application in instance (Was: Breakage with 6.10)
On Fri, Oct 10, 2008 at 8:40 PM, Niklas Broberg [EMAIL PROTECTED] wrote: src\HSX\XMLGenerator.hs:71:0 Illegal type synonym family application in instance: XML m In the instance declaration for `EmbedAsChild m (XML m)´ --- Could someone help me point out the problem here? The relevant code is: instance XMLGen m = EmbedAsChild m (XML m) where asChild = return . return . xmlToChild class XMLGen m = EmbedAsChild m c where asChild :: c - GenChildList m class Monad m = XMLGen m where type XML m This works fine with 6.8.3, so what's new in 6.10, and what would I do to solve it? I'm guessing there was a bug in 6.8.3 that allowed this. (The implementation of type families is present but not supported in 6.8, presumably because of problems like this.) I don't have 6.10, so I can't test anything, but you might try rewriting the EmbedAsChild instances like so: instance (XMLGen m, XML m ~ x) = EmbedAsChild m x where ... Alternatively, you can make separate instances for every type in the range of XML. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Illegal type synonym family application in instance (Was: Breakage with 6.10)
On 10/11/08, David Menendez [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 8:40 PM, Niklas Broberg [EMAIL PROTECTED] wrote: src\HSX\XMLGenerator.hs:71:0 Illegal type synonym family application in instance: XML m In the instance declaration for `EmbedAsChild m (XML m)´ --- Could someone help me point out the problem here? The relevant code is: instance XMLGen m = EmbedAsChild m (XML m) where asChild = return . return . xmlToChild class XMLGen m = EmbedAsChild m c where asChild :: c - GenChildList m class Monad m = XMLGen m where type XML m This works fine with 6.8.3, so what's new in 6.10, and what would I do to solve it? I'm guessing there was a bug in 6.8.3 that allowed this. (The implementation of type families is present but not supported in 6.8, presumably because of problems like this.) I don't have 6.10, so I can't test anything, but you might try rewriting the EmbedAsChild instances like so: instance (XMLGen m, XML m ~ x) = EmbedAsChild m x where ... Thanks a lot David, that's indeed what I needed. I'm not sure I see why the style I used previously was illegal though, it seemed perfectly natural to me. And it works that way for `EmbedAsChild m (Child m)´, where `Child m´ is a data type family and not a synonym, so why not for a synonym too? But hey, as long as there's a way to do what I want. :-) Cheers, /Niklas ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Releasing extralibs
All, Don and I have looked through the extralibs set that came with ghc-6.8.3 and the set that will be associated with 6.10.1. I've attached a csv spreadsheet with the summary. For each package we looked at the difference between the last released version (whether that was in the 6.8.3 extralibs tarball or on hackage) and determined the extent of the changes. We assessed the changes against the package version policy to work out the new version (if necessary). These are the actions we need to take: * HUnit: bump version from 1.2.0.0 to 1.2.0.1 and release * QuickCheck: release 1.2.0.0 * haskell-src:bump version from 1.0.1.2 to 1.0.1.3 and release * html: bump version from 1.0.1.1 to 1.0.1.2 and release * mtl:bump version from 1.1.0.1 to 1.1.0.2 and release * network:bump version from 2.2.0.0 to 2.2.0.1 and release * parsec: nothing to do - no changes * parallel: nothing to do - no changes * regex-base: bump version from 0.72.0.1 to 0.72.0.2 and release * regex-compat: nothing to do - no changes * regex-posix:bump version from 0.72.0.2 to 0.72.0.3 and release * stm:bump version from 2.1.1.1 to 2.1.2.0 and release * time: bump version from 1.1.2.1 to 1.1.2.2 and release * xhtml: nothing to do - no changes By release we mean release on hackage. There's no need to wait until 6.10.1 is released to do this. Indeed we can get better testing done if we release now. Duncan Package,GHC-6.8.3 version,GHC-6.10 version,Hackage version,Next version number,Action,Notes HUnit,1.2.0.0,1.2.0.0,1.2.0.0,1.2.0.1,Bump Release,Changes internal imports QuickCheck,1.1.0.0,1.2.0.0,1.1.0.0,1.2.0.0,Release, haskell-src,1.0.1.2,1.0.1.2,1.0.1.2,1.0.1.3,Bump Release,Build changes html,1.0.1.1,1.0.1.1,1.0.1.1,1.0.1.2,Bump Release,Category added mtl,1.1.0.1,1.1.0.1,1.1.0.1,1.1.0.2,Bump Release,Doc changes, warnings network,2.2.0.0,2.2.0.0,2.2.0.0,2.2.0.1,Bump Release,Build changes parsec,2.1.0.1,2.1.0.1,2.1.0.1,,Done,No changes at all parallel,1.0.0.1,1.0.0.1,1.0.0.1,,Done,No changes at all regex-base,0.72.0.1,0.72.0.1,0.72.0.1,0.72.0.2,Bump Release,Warning fixes regex-compat,0.71.0.1,0.71.0.1,0.71.0.1,,Done,No changes at all regex-posix,0.72.0.2,0.72.0.2,0.72.0.2,0.72.0.3,Bump Release,Warning fixes stm,2.1.1.1,2.1.1.1,2.1.1.0,2.1.2.0,Bump Release,Exports more and generalises a type time,1.1.2.1,1.1.2.1,1.1.2.1,1.1.2.2,Bump Release,Only flag and doc changes xhtml,3000.2.0.0,3000.2.0.1,3000.2.0.1,,Done,No changes since release ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Releasing extralibs
On Fri, 2008-10-10 at 19:42 -0700, Duncan Coutts wrote: These are the actions we need to take: Note that the changes to the exception handling in this package means the following packages no longer build with ghc-6.8.x: * HUnit * network * stm (also imports a new function from GHC.*) All the others still work with 6.8.2. From the network.cabal file it looks like someone intended it to work with both. STM is not fixable due to the new function it needs from the GHC.* modules. We should decide if we want to fix HUnit and network or just adjust the dependencies to specify base 4. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
