http://blog.gmane.org/gmane.comp.lang.haskell.glasgow.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15370 2008/10/7 Johannes Waldmann <waldmann< at >imn.htwk-leipzig.de>: catch \(e :: SomeException) -> ... This requires language ScopedTypeVariables (and perhaps PatternSignatures). Of cause, you should try to be more specific about which exceptions you want to catch as e.g., Ctrl-C and many other things are also reported as exceptions. Thomas Schilling 2008-10-07T14:25:50 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15369 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Johannes Waldmann 2008-10-07T12:59:13 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15368 For some reason it seems that Fedora and Debian are using different versions of the libedit shared library. Our binary installers are build on Fedora. For the release we'll probably have two binary distributions, one for Fedora and one for Debian(-based) systems. You might be able to get away with symlinking libedit.so.0 to libedit.so.2 in the meantime. Cheers, Simon Simon Marlow 2008-10-07T12:22:45 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15367 This is something we changed in GHC 6.10.1, incedentally. Now SIGPIPE doesn't silently exit the program, and it will get an exception instead. Cheers, Simon Simon Marlow 2008-10-07T12:20:52 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15366 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Johannes Waldmann 2008-10-07T10:55:39 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15365 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Johannes Waldmann 2008-10-06T15:03:06 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15364 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Johannes Waldmann 2008-10-06T14:13:04 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15362 What about shipping two versions? One with bundled MinGW and other without Good idea. leledumbo 2008-10-06T03:02:24 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15361 Can you try to work out which test is causing the problem, please? e.g. in testsuite/tests/ghc-regress/ghci/scripts run make fast CLEANUP=1 TEST=ghci001 replacing "ghci001" with each of the first arguments to test in all.T. Or alternatively, remove stanzas in all.T using binary search and running make fast CLEANUP=1 until you narrow down which one causes the problem. Thanks Ian Ian Lynagh 2008-10-05T14:14:36 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15360 People, I need to implement the functions isTypeId, isValueId :: String -> Bool which check whether the argument fits respectively the syntax of a type identifier and of a value identifier -- in the Haskell-98 syntax for a program. The argument is produced by lexLots. For example, my program applies lexLots "ab-(f_21 <Ab:c" --> -- I expect: ["ab", "-", "(", "f_21", "<", "Ab", ":", "c"] -- 1 2 3 4 Then, I think, only (1), (2), (3) and (4) are type or value identifiers ... What is the most regular expression for isTypeId, isValueId ? I presume to consider first the Standard library, and if fail, then the GHC library. Thank you in advance for your advice. Regards, ----------------- Serge Mechveliani mechvel< at >botik.ru Serge D. Mechveliani 2008-10-05T08:55:22 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15359 As Duncan said, I misspoke slightly. I was actually assuming something like the rules used for shared libraries: given a version X.Y.Z, X changes with API changes, Y with large non-API changes, Z with minor patches, and the resolution algorithm chooses the latest version with the same X (and, on some systems, tries to match Y as well), and older versions are never accepted. Brandon S. Allbery KF8NH 2008-10-03T23:44:31 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15358 Hello Brandon, Friday, October 3, 2008, 8:53:05 PM, you wrote: and bugfixed versions will be never used :) Bulat Ziganshin 2008-10-03T22:09:17 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15357 We should also use such a tool to check/generate "this was added in version n" to the haddock docs. Thanks Ian Ian Lynagh 2008-10-03T17:24:42 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15356 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users Juan Carlos Arevalo Baeza 2008-10-03T17:17:55 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15355 Unfortunately this is the opposite of people normal (mostly reasonable) expectations. Perhaps you mean the highest revision of the lowest major version. Again this requires giving a semantics to the version numbers, which is just what the versioning policy does (for packages that have opted in). Duncan Duncan Coutts 2008-10-03T16:56:00 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15354 On Fri, 2008-10-03 at 14:27 +0100, Claus Reinke wrote: Yes! Yes. Don and I are rather of the opinion that we need to look much more carefully at the package system. We're basically operating without the reassuring assistance of the type checker. There are some practical things we can do to make the current system work considerably better though. If we get the platform packages to opt into the package versioning policy and get cabal/hackage to warn about upwardly open version ranges then that'd go a long way to making things better. We should also write a tool using the ghc-api to compare apis of different versions of packages to inform people of changes and enforce the versioning policy for packages that have opted in. Having those interface specs around might also help a more robust package composition consistency checker or solver. Duncan Duncan Coutts 2008-10-03T16:54:12 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15353 Choose the lowest available version that satisfies all of the constraints? Brandon S. Allbery KF8NH 2008-10-03T16:53:05 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15352 The suggested version thing really turns out to be the same as saying we should satisfy base >= 3 using base-3 rather than base-4. We want that general mechanism anyway. So I think it's actually more general. We don't need to tell the resolver about base specially, it just extends an already existing notion of soft version preferences. The current resolver allows for soft preferences on the installed state, this just extends that to a general version preference. We want it anyway to better manage transitions like QC1 -> 2 or Parsec 2 -> 3. The biggest problem is really just that the resolver has to deal with two instances of the same package in its solution. It was designed from the beginning with the assumption that it was accumulating version constraints per-package name (and that all constraints on a package version should be simultaneously satisfiable). We should however have packages declare if they have opted into the package versioning policy. Base would be one of them. We could then warn users when they are using bad version ranges in dependencies on such packages. It'd have to be a field in the .cabal file. Any suggestions for a good name? package-version-policy: Yarr! Duncan Duncan Coutts 2008-10-03T16:12:11 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15351 Hello Simon, Friday, October 3, 2008, 12:55:34 PM, you wrote: this looks reasonable for any package yjat follows versioning policy since changing major number means that anything in api may change you may use this as "theoretical" foundation for such trick :) of course in the future it will be great if people will start to use intervals with both high and low bounds Bulat Ziganshin 2008-10-03T15:44:25 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15350 That sounds reasonable. All open-ended dependencies are lies.. Well, actually they are optimistic approximations (some programs will work with base 3 or base 4), and closed dependency ranges are pessimistic approximations (few programs need all of base 3). The problem is that there is no definite interface spec. At the moment, precise package versions are the only thing that Cabal knows about, on the understanding that package+version names (but not details) an API, and that the real API is some unidentified subset of the named API. In light of this, I've been wondering whether the complete list of precise package versions should really be part of the .cabal file: - they are little more than hints: I guess that a specific list of package+version names identifies a superset of the API my package needs, and if that guess turns out to be correct, I leave it in the .cabal file as the closest thing to an import API spec that Cabal allows me to write. - they can be inaccurate both upwards and downwards: my package rarely needs all of the import API named by the build-depends, and I'd often be happy if the import API for my package would be supplied by some other combination of packages (eg, base-4 + syb instead of base-3). - having precise build-depends means augmenting the package tarballs again and again, after testing with newer dependency versions. Wouldn't it make sense to keep only the initial hint in the .cabal file ("this is the precise combination of packages+versions that my package did build with"), and to let Cabal or Ghc or other tools figure out additional combinations that also allow the package to build successfully? These combinations could be tool-generated into a .cabal-configurations file, which could be stored outside the package tarball, and augmented whenever new dependency versions come out. Downloading the package and its successful configuration record would allow cabal-install to pick a combination that best matches locally installed packages. If a package doesn't have a successful configuration record, cabal-install can either try to generate one from the local packages, or insist on downloading the original configuration. If the former, cabal-install ought to report that back to hackage, to save itself work on the next installation. In any case, you wouldn't need to update all hackage package tarballs to add new dependency version numbers (just their .cabal-configurations records), and you could do that incrementally, when new dependency versions come out, and only once per package (instead of everytime someone tries to install it). Does that sound plausible? Claus Claus Reinke 2008-10-03T13:27:37 http://permalink.gmane.org/gmane.comp.lang.haskell.glasgow.user/15349 These warnings are from Haddock, and are emitted when it can't decide how to hyperlink a particular identifier. Sometimes they are cause for concern, and we should really take a look through them before the release. Cheers, Simon Simon Marlow 2008-10-03T09:02:57 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.haskell.glasgow.user