Re: Using mutable array after an unsafeFreezeArray, and GC details
On 10/05/2014 21:57, Brandon Simmons wrote: Another silly question: when card-marking happens after a write or CAS, does that indicate this segment maybe contains old-to-new generation references, so be sure to preserve (scavenge?) them from collection ? Yes, that's exactly right. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using mutable array after an unsafeFreezeArray, and GC details
On 09/05/2014 19:21, Brandon Simmons wrote: A couple of updates: Edward Yang responded here, confirming the sort of track I was thinking on: http://blog.ezyang.com/2014/05/ghc-and-mutable-arrays-a-dirty-little-secret/ And I can report that: 1) cloning a frozen array doesn't provide the benefits of creating a new array and freezing 2) and anyway, I'm seeing some segfaults when cloning, freezing, reading then writing in my library I'd love to learn if there are any other approaches I might take, e.g. maybe with my own CMM primop variants? I'm not sure exactly what your workload looks like, but if you have arrays that tend to be unmodified for long periods of time it's sometimes useful to keep them frozen but thaw before mutating. How large are your arrays? Perhaps the new small array type (in HEAD but not 7.8) would help? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using mutable array after an unsafeFreezeArray, and GC details
On Mon, May 12, 2014 at 4:32 AM, Simon Marlow marlo...@gmail.com wrote: On 09/05/2014 19:21, Brandon Simmons wrote: A couple of updates: Edward Yang responded here, confirming the sort of track I was thinking on: http://blog.ezyang.com/2014/05/ghc-and-mutable-arrays-a-dirty-little-secret/ And I can report that: 1) cloning a frozen array doesn't provide the benefits of creating a new array and freezing 2) and anyway, I'm seeing some segfaults when cloning, freezing, reading then writing in my library I'd love to learn if there are any other approaches I might take, e.g. maybe with my own CMM primop variants? I'm not sure exactly what your workload looks like, but if you have arrays that tend to be unmodified for long periods of time it's sometimes useful to keep them frozen but thaw before mutating. The idea is I'm using two atomic counters to coordinate concurrent readers and writers along an infinite array (a linked list of array segments that get allocated as needed and garbage collected as we go). So currently each cell in each array is written to only once, with a CAS. How large are your arrays? Perhaps the new small array type (in HEAD but not 7.8) would help? Thanks, maybe so! The arrays can be any size, but probably not smaller than length 64 (this will be static, at compile-time). I read through https://ghc.haskell.org/trac/ghc/ticket/5925, and it seems like the idea is to improve array creation. I'm pretty happy with the speed of cloning an array (but maybe cloneSmallArray will be even faster still). It also looks like stg_casSmallArrayzh (in PrimOps.cmm) omits the card marking (maybe the idea is if the array is already at ~128 elements or less, then the card-marking is all just overhead?). Brandon Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Using mutable array after an unsafeFreezeArray, and GC details
Excerpts from Brandon Simmons's message of 2014-05-10 13:57:40 -0700: Another silly question: when card-marking happens after a write or CAS, does that indicate this segment maybe contains old-to-new generation references, so be sure to preserve (scavenge?) them from collection ? In my initial question I was thinking of the cards as indicating here be garbage (e.g. a previous overwritten array value), but I think I had the wrong idea about how copying GC works generally (shouldn't it really be called Non-Garbage Preservation?). That's correct. Cheers, Edward ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] CFP: WFLP 2014 - Workshop on Functional and (Constraint) Logic Programming
23rd International Workshop on Functional and (Constraint) Logic Programming http://www.imn.htwk-leipzig.de/WFLP2014/ colocated with 28th Workshop on (Constraint) Logic Programming (WLP 2014) September 15 - 17, at Leucorea conference center in Lutherstadt Wittenberg, Germany. *** Dates: * submission closes: July 1, 2014 * notification: August 1, 2014 * final version due: September 1, 2014 * workshop: September 15 - 17, 2014 *** The international workshops on functional and logic programming aim at bringing together researchers interested in functional programming, logic programming, as well as their integration. The workshops on (constraint) logic programming serve as the scientific forum of the annual meeting of the Society of Logic Programming (GLP e.V.) and bring together researchers interested in logic programming, constraint programming, and related areas like databases, artificial intelligence, and operations research. In this year both workshops will be jointly organized and co-located, in order to promote the cross-fertilizing exchange of ideas and experiences among researchers and students from the different communities interested in the foundations, applications, and combinations of high-level, declarative programming languages and related areas. The technical program of the workshop will include invited talks, presentations of refereed papers and demo presentations. The joint workshop will consist of two tracks (WFLP and WLP). Sessions of these two tracks will be interleaved. Topics The topics of interest include (but are not limited to): Functional programming Logic programming Constraint programming Deductive databases, data mining Extensions of declarative languages, objects Multi-paradigm declarative programming Foundations, semantics, nonmonotonic reasoning, dynamics Parallelism, concurrency Program analysis, abstract interpretation Program transformation, partial evaluation, meta-programming Specification, verification, declarative debugging Knowledge representation, machine learning Interaction of declarative programming with other formalisms (e.g., agents, XML, Java) Implementation of declarative languages Advanced programming environments and tools Software technique for declarative programming Applications The primary focus is on new and original research results but submissions describing innovative products, prototypes under development, application systems, or interesting experiments (e.g., benchmarks) are also encouraged. Program Committee (WFLP track) Elvira Albert, Complutense University of Madrid, Spain Sergio Antoy, Portland State University Mauricio Ayala-Rincon, University of Brasilia, Brazil William Byrd, University of Utah Michael Hanus , Universität Kiel, Germany Herbert Kuchen, Universität Münster, Germany Carlos Olarte, DECC, Pontificia Universidad Javeriana Cali, Colombia Janis Voigtländer, Universität Bonn, Germany Johannes Waldmann (chair), HTWK Leipzig, Germany Peter J. Stuckey, NICTA and the University of Melbourne, Australia René Thiemann, University of Innsbruck, Austria Organising Committee Stefan Brass (chair) Universität Halle, Germany signature.asc Description: OpenPGP digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: jhc-0.8.1
Hello, I tried compiling jhc from source (compiled version doesn't work on my system) but after several attempts I just couldn't find a working set of libraries for it. Can you specify which versions of libraries are known to work for jhc? Best regards, Krzysztof Skrzętnicki On Sun, May 11, 2014 at 10:20 PM, John Meacham j...@repetae.net wrote: After a hiatus, jhc 0.8.1 is released. http://repetae.net/computer/jhc - New license, jhc is now released under a permissive BSD style licence rather than the GPL. The license is compatible with that of ghc allowing code mixing between them. - New library layout based around the standards, there are now haskell98 and haskell2010 packages that are guarenteed to be future proof strictly compatible with the respective standards. A package haskell-extras contains the additonal libraries from ghc's base. - Native support for complex and vector SIMD primitives, exposed via type functions. for instance 'foo :: Complex_ Float32_' for hardware accelerated complex 32 bit floats for instance. These are unboxed only for now, full library Num support in the works. - support for android as a target, you must install the android NDK to use this. - Support for embedded ARM architectures imported from Kiwamu Okabe's branch allowing targeting bare hardware with no OS. - user defined kinds, introduced with the 'kind' keyword otherwise looking like 'type' declarations. - export/import lists now allow namespace qualifiers kind, class, type, or data to explicitly only import or export the specific named entity. As an extension allowed by this, classes and types no longer are in the same namespace and can share names. - ForeignPtr's now have working finalizers when collected by the RTS. - CTYPE pragma to allow promoting arbitrary C types to FFIable entities. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: jhc-0.8.1
Hi, I need to update that page, I compile it with the ubuntu ghc and the ubuntu packaged ones. Can you tell me what libraries you are having issues with? the ./configure should tell you the names of any that I expected might be an issue, I'll actually update it to check and report on everything consistently. even ones I expect to come with ghc. If there are compatibility issues between versions that's a bug I can fix. (usually just a 'hiding' or explicit import will fix any such issue) as for the packages i've been testing with fgl,regex-compat,bytestring,binary,mtl,containers,unix,utf8-string,zlib,HsSyck,filepath,process,syb,old-time,pretty. Specific versions should not matter from anything back in ghc 7.2 days to now, if there is a bug where it won't compile with a version expected to be found in the wild, please feel free to report it. John On Mon, May 12, 2014 at 12:10 PM, Krzysztof Skrzętnicki gte...@gmail.com wrote: Hello, I tried compiling jhc from source (compiled version doesn't work on my system) but after several attempts I just couldn't find a working set of libraries for it. Can you specify which versions of libraries are known to work for jhc? Best regards, Krzysztof Skrzętnicki On Sun, May 11, 2014 at 10:20 PM, John Meacham j...@repetae.net wrote: After a hiatus, jhc 0.8.1 is released. http://repetae.net/computer/jhc - New license, jhc is now released under a permissive BSD style licence rather than the GPL. The license is compatible with that of ghc allowing code mixing between them. - New library layout based around the standards, there are now haskell98 and haskell2010 packages that are guarenteed to be future proof strictly compatible with the respective standards. A package haskell-extras contains the additonal libraries from ghc's base. - Native support for complex and vector SIMD primitives, exposed via type functions. for instance 'foo :: Complex_ Float32_' for hardware accelerated complex 32 bit floats for instance. These are unboxed only for now, full library Num support in the works. - support for android as a target, you must install the android NDK to use this. - Support for embedded ARM architectures imported from Kiwamu Okabe's branch allowing targeting bare hardware with no OS. - user defined kinds, introduced with the 'kind' keyword otherwise looking like 'type' declarations. - export/import lists now allow namespace qualifiers kind, class, type, or data to explicitly only import or export the specific named entity. As an extension allowed by this, classes and types no longer are in the same namespace and can share names. - ForeignPtr's now have working finalizers when collected by the RTS. - CTYPE pragma to allow promoting arbitrary C types to FFIable entities. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- John Meacham - http://notanumber.net/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: jhc-0.8.1
Thank you for the new release. :) On 13 May 2014 04:40, John Meacham j...@repetae.net wrote: as for the packages i've been testing with fgl,regex-compat,bytestring,binary,mtl,containers,unix,utf8-string,zlib,HsSyck,filepath,process,syb,old-time,pretty. and editline ? For me it fails to build on Fedora 20 with the readline package but completes with editline. Krzysztof: maybe try removing or hiding the readline package or posting your build error. :) Jens ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: jhc-0.8.1
Yeah, there was a bug in the way it detected editline/readline which has been fixed in the repo. You can run configure with --disable-line to work around it. or change the word USE_NOLINE to USE_READLINE in src/Util/Interact.hs always some silly typo that works its way in somewhere. I should stop the version number shift and declare it 1.0.0 and use the third digit for actual point releases rather than keep the perpetual 0.x.y wasting the first digit. but then I can't hide behind the 'beta' shield anymore. :) John On Mon, May 12, 2014 at 7:56 PM, Jens Petersen j...@community.haskell.org wrote: Thank you for the new release. :) On 13 May 2014 04:40, John Meacham j...@repetae.net wrote: as for the packages i've been testing with fgl,regex-compat,bytestring,binary,mtl,containers,unix,utf8-string,zlib,HsSyck,filepath,process,syb,old-time,pretty. and editline ? For me it fails to build on Fedora 20 with the readline package but completes with editline. Krzysztof: maybe try removing or hiding the readline package or posting your build error. :) Jens -- John Meacham - http://notanumber.net/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: jhc-0.8.1
Hmm, I'll give it a try, thanks! As for the other errors for sure there is missing Binary instance for strict ByteStrings in newest binary package. Another one is instance for Show (Identity a) which in turn needed to be commented out because it appeared in newer version of some other package, don't know which one. Lastly I get a lot of errors caused by mixing library versions. I *think* that the problem is that, unlike Cabal, the Makefile specifies -package foo without specific versions. The result is that, given the fact that I have more than 1 version of many libraries installed, it tries to build with two different versions of same library, or so would it seem: 1 is dependency of other library, the other is from -package specification. I think this is the case. This is why I asked for specific versions of all the libraries involved. The idea was to simply specify *all* of them on command line and/or Makefile. Right now I don't have time to replicate the errors, but I will try again building jhc later. Best regards, Krzysztof On Tue, May 13, 2014 at 5:09 AM, John Meacham j...@repetae.net wrote: Yeah, there was a bug in the way it detected editline/readline which has been fixed in the repo. You can run configure with --disable-line to work around it. or change the word USE_NOLINE to USE_READLINE in src/Util/Interact.hs always some silly typo that works its way in somewhere. I should stop the version number shift and declare it 1.0.0 and use the third digit for actual point releases rather than keep the perpetual 0.x.y wasting the first digit. but then I can't hide behind the 'beta' shield anymore. :) John On Mon, May 12, 2014 at 7:56 PM, Jens Petersen j...@community.haskell.org wrote: Thank you for the new release. :) On 13 May 2014 04:40, John Meacham j...@repetae.net wrote: as for the packages i've been testing with fgl,regex-compat,bytestring,binary,mtl,containers,unix,utf8-string,zlib,HsSyck,filepath,process,syb,old-time,pretty. and editline ? For me it fails to build on Fedora 20 with the readline package but completes with editline. Krzysztof: maybe try removing or hiding the readline package or posting your build error. :) Jens -- John Meacham - http://notanumber.net/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [arch-haskell] help upgrading packages
http-conduit and its dependencies moved from haskell-happstack to haskell-core and at that time the package release number reset to one. You have to manually uninstall and reinstall those packages. Nicola On Sun, May 11, 2014 at 11:49 PM, Michael Katelman katel...@gmail.comwrote: I was hoping someone might help me with an issuing I'm having doing a system upgrade. When I run pacman -Syu, I get: :: Synchronizing package databases... haskell-core is up to date haskell-happstack is up to date core is up to date extra is up to date community is up to date :: Starting full system upgrade... warning: haskell-asn1-encoding: local (0.8.1.3-4) is newer than haskell-core (0.8.1.3-2) warning: haskell-asn1-parse: local (0.8.1-5) is newer than haskell-core (0.8.1-2) warning: haskell-asn1-types: local (0.2.3-3) is newer than haskell-core (0.2.3-1) warning: haskell-cipher-aes: local (0.2.7-3) is newer than haskell-core (0.2.7-1) warning: haskell-cipher-rc4: local (0.1.4-4) is newer than haskell-core (0.1.4-1) warning: haskell-connection: local (0.2.1-3) is newer than haskell-core (0.2.1-2) warning: haskell-cprng-aes: local (0.5.2-8) is newer than haskell-core (0.5.2-1) warning: haskell-crypto-cipher-types: local (0.0.9-3) is newer than haskell-core (0.0.9-1) warning: haskell-crypto-numbers: local (0.2.3-3) is newer than haskell-core (0.2.3-1) warning: haskell-crypto-pubkey: local (0.2.4-6) is newer than haskell-core (0.2.4-1) warning: haskell-crypto-pubkey-types: local (0.4.2.2-3) is newer than haskell-core (0.4.2.2-1) warning: haskell-crypto-random: local (0.0.7-4) is newer than haskell-core (0.0.7-1) warning: haskell-http-client-tls: local (0.2.1.1-21) is newer than haskell-core (0.2.1.1-2) warning: haskell-http-conduit: local (2.1.2-4) is newer than haskell-core (2.1.2-2) warning: haskell-mime-types: local (0.1.0.4-3) is newer than haskell-core (0.1.0.4-2) warning: haskell-publicsuffixlist: local (0.1-7) is newer than haskell-core (0.1-2) warning: haskell-securemem: local (0.1.3-3) is newer than haskell-core (0.1.3-1) warning: haskell-socks: local (0.5.4-10) is newer than haskell-core (0.5.4-2) warning: haskell-x509: local (1.4.11-5) is newer than haskell-core (1.4.11-2) warning: haskell-x509-store: local (1.4.4-9) is newer than haskell-core (1.4.4-2) warning: haskell-x509-validation: local (1.5.0-9) is newer than haskell-core (1.5.0-2) resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: haskell-connection: requires haskell-network=2.4.2.2-60 :: haskell-connection: requires haskell-tls=1.2.6-5 :: haskell-connection: requires haskell-x509=1.4.11-5 :: haskell-connection: requires haskell-x509-store=1.4.4-9 :: haskell-connection: requires haskell-x509-validation=1.5.0-9 :: haskell-cookie: requires haskell-blaze-builder=0.3.3.2-59 :: haskell-cookie: requires haskell-text=1.1.1.1-1 :: haskell-cprng-aes: requires haskell-cipher-aes=0.2.7-3 :: haskell-cprng-aes: requires haskell-crypto-random=0.0.7-4 :: haskell-http-client-tls: requires haskell-http-client=0.3.2.1-2 :: haskell-http-client-tls: requires haskell-network=2.4.2.2-60 :: haskell-http-client-tls: requires haskell-tls=1.2.6-5 :: haskell-http-conduit: requires haskell-conduit=1.1.1.1-1 :: haskell-http-conduit: requires haskell-http-client=0.3.2.1-2 :: haskell-http-conduit: requires haskell-http-types=0.8.4-4 :: haskell-http-conduit: requires haskell-lifted-base=0.2.2.1-3 :: haskell-http-conduit: requires haskell-monad-control=0.3.2.3-5 :: haskell-http-conduit: requires haskell-resourcet=1.1.2-1 :: haskell-socks: requires haskell-network=2.4.2.2-60 :: haskell-x509-system: requires haskell-x509=1.4.11-5 :: haskell-x509-system: requires haskell-x509-store=1.4.4-9 I really have no idea what to do with this or what would have caused it. I'm sure it's some important misunderstanding on my part. Any help would be greatly appreciated. -Mike ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
I had a similar issue with a large number of packages. I ended up removing and re-installing my entire Haskell ecosystem, and now things work again. I note the absence of certain packages like haskell-buildwrapper (which EclipseFP tools needs) - and reading the wiki, it seems confusing at this time whether the Haskell tinkerer / developer should just be using cabal-install to install all required packages (even though I know that cabal is not a package management system) or... what? What are other Haskell developers here doing currently? kind regards, Dawid Loubser On 12/05/2014 08:49, Nicola Squartini wrote: http-conduit and its dependencies moved from haskell-happstack to haskell-core and at that time the package release number reset to one. You have to manually uninstall and reinstall those packages. Nicola On Sun, May 11, 2014 at 11:49 PM, Michael Katelman katel...@gmail.com mailto:katel...@gmail.com wrote: I was hoping someone might help me with an issuing I'm having doing a system upgrade. When I run pacman -Syu, I get: :: Synchronizing package databases... haskell-core is up to date haskell-happstack is up to date core is up to date extra is up to date community is up to date :: Starting full system upgrade... warning: haskell-asn1-encoding: local (0.8.1.3-4) is newer than haskell-core (0.8.1.3-2) warning: haskell-asn1-parse: local (0.8.1-5) is newer than haskell-core (0.8.1-2) warning: haskell-asn1-types: local (0.2.3-3) is newer than haskell-core (0.2.3-1) warning: haskell-cipher-aes: local (0.2.7-3) is newer than haskell-core (0.2.7-1) warning: haskell-cipher-rc4: local (0.1.4-4) is newer than haskell-core (0.1.4-1) warning: haskell-connection: local (0.2.1-3) is newer than haskell-core (0.2.1-2) warning: haskell-cprng-aes: local (0.5.2-8) is newer than haskell-core (0.5.2-1) warning: haskell-crypto-cipher-types: local (0.0.9-3) is newer than haskell-core (0.0.9-1) warning: haskell-crypto-numbers: local (0.2.3-3) is newer than haskell-core (0.2.3-1) warning: haskell-crypto-pubkey: local (0.2.4-6) is newer than haskell-core (0.2.4-1) warning: haskell-crypto-pubkey-types: local (0.4.2.2-3) is newer than haskell-core (0.4.2.2-1) warning: haskell-crypto-random: local (0.0.7-4) is newer than haskell-core (0.0.7-1) warning: haskell-http-client-tls: local (0.2.1.1-21) is newer than haskell-core (0.2.1.1-2) warning: haskell-http-conduit: local (2.1.2-4) is newer than haskell-core (2.1.2-2) warning: haskell-mime-types: local (0.1.0.4-3) is newer than haskell-core (0.1.0.4-2) warning: haskell-publicsuffixlist: local (0.1-7) is newer than haskell-core (0.1-2) warning: haskell-securemem: local (0.1.3-3) is newer than haskell-core (0.1.3-1) warning: haskell-socks: local (0.5.4-10) is newer than haskell-core (0.5.4-2) warning: haskell-x509: local (1.4.11-5) is newer than haskell-core (1.4.11-2) warning: haskell-x509-store: local (1.4.4-9) is newer than haskell-core (1.4.4-2) warning: haskell-x509-validation: local (1.5.0-9) is newer than haskell-core (1.5.0-2) resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: haskell-connection: requires haskell-network=2.4.2.2-60 :: haskell-connection: requires haskell-tls=1.2.6-5 :: haskell-connection: requires haskell-x509=1.4.11-5 :: haskell-connection: requires haskell-x509-store=1.4.4-9 :: haskell-connection: requires haskell-x509-validation=1.5.0-9 :: haskell-cookie: requires haskell-blaze-builder=0.3.3.2-59 :: haskell-cookie: requires haskell-text=1.1.1.1-1 :: haskell-cprng-aes: requires haskell-cipher-aes=0.2.7-3 :: haskell-cprng-aes: requires haskell-crypto-random=0.0.7-4 :: haskell-http-client-tls: requires haskell-http-client=0.3.2.1-2 :: haskell-http-client-tls: requires haskell-network=2.4.2.2-60 :: haskell-http-client-tls: requires haskell-tls=1.2.6-5 :: haskell-http-conduit: requires haskell-conduit=1.1.1.1-1 :: haskell-http-conduit: requires haskell-http-client=0.3.2.1-2 :: haskell-http-conduit: requires haskell-http-types=0.8.4-4 :: haskell-http-conduit: requires haskell-lifted-base=0.2.2.1-3 :: haskell-http-conduit: requires haskell-monad-control=0.3.2.3-5 :: haskell-http-conduit: requires haskell-resourcet=1.1.2-1 :: haskell-socks: requires haskell-network=2.4.2.2-60 :: haskell-x509-system: requires haskell-x509=1.4.11-5 :: haskell-x509-system: requires haskell-x509-store=1.4.4-9 I really have no idea what to do with this or what would have caused it. I'm sure it's some important misunderstanding on my part. Any help would be greatly appreciated. -Mike
Re: [arch-haskell] help upgrading packages
On Mon, May 12, 2014 at 2:24 PM, Dawid Loubser dawid.loub...@ibi.co.zawrote: I had a similar issue with a large number of packages. I ended up removing and re-installing my entire Haskell ecosystem, and now things work again. Normally this should never happen. It's because Haskell is very strict on dependencies (despite being lazy on other things). In this case the reason was that those packages were added to the repository [haskell-core] with initial release number set to 1, although they had been in [haskell-happstack] already for some time and their release number was higher. I removed those immediately from [haskell-happstack] to avoid duplicate work, but they must also be manually removed from local, since pacman always keeps the highest version-release. In order to avoid this kind of issues in the future we should either have a policy to coordinate work between different haskell repositories, or merge everything into a unique repository and call it simply [haskell]. I note the absence of certain packages like haskell-buildwrapper (which EclipseFP tools needs) - and reading the wiki, it seems confusing at this time whether the Haskell tinkerer / developer should just be using cabal-install to install all required packages (even though I know that cabal is not a package management system) or... what? Personally I don't like installing things using cabal-install because in my opinion the distro package manager should always be in charge. What are other Haskell developers here doing currently? kind regards, Dawid Loubser On 12/05/2014 08:49, Nicola Squartini wrote: http-conduit and its dependencies moved from haskell-happstack to haskell-core and at that time the package release number reset to one. You have to manually uninstall and reinstall those packages. Nicola On Sun, May 11, 2014 at 11:49 PM, Michael Katelman katel...@gmail.comwrote: I was hoping someone might help me with an issuing I'm having doing a system upgrade. When I run pacman -Syu, I get: :: Synchronizing package databases... haskell-core is up to date haskell-happstack is up to date core is up to date extra is up to date community is up to date :: Starting full system upgrade... warning: haskell-asn1-encoding: local (0.8.1.3-4) is newer than haskell-core (0.8.1.3-2) warning: haskell-asn1-parse: local (0.8.1-5) is newer than haskell-core (0.8.1-2) warning: haskell-asn1-types: local (0.2.3-3) is newer than haskell-core (0.2.3-1) warning: haskell-cipher-aes: local (0.2.7-3) is newer than haskell-core (0.2.7-1) warning: haskell-cipher-rc4: local (0.1.4-4) is newer than haskell-core (0.1.4-1) warning: haskell-connection: local (0.2.1-3) is newer than haskell-core (0.2.1-2) warning: haskell-cprng-aes: local (0.5.2-8) is newer than haskell-core (0.5.2-1) warning: haskell-crypto-cipher-types: local (0.0.9-3) is newer than haskell-core (0.0.9-1) warning: haskell-crypto-numbers: local (0.2.3-3) is newer than haskell-core (0.2.3-1) warning: haskell-crypto-pubkey: local (0.2.4-6) is newer than haskell-core (0.2.4-1) warning: haskell-crypto-pubkey-types: local (0.4.2.2-3) is newer than haskell-core (0.4.2.2-1) warning: haskell-crypto-random: local (0.0.7-4) is newer than haskell-core (0.0.7-1) warning: haskell-http-client-tls: local (0.2.1.1-21) is newer than haskell-core (0.2.1.1-2) warning: haskell-http-conduit: local (2.1.2-4) is newer than haskell-core (2.1.2-2) warning: haskell-mime-types: local (0.1.0.4-3) is newer than haskell-core (0.1.0.4-2) warning: haskell-publicsuffixlist: local (0.1-7) is newer than haskell-core (0.1-2) warning: haskell-securemem: local (0.1.3-3) is newer than haskell-core (0.1.3-1) warning: haskell-socks: local (0.5.4-10) is newer than haskell-core (0.5.4-2) warning: haskell-x509: local (1.4.11-5) is newer than haskell-core (1.4.11-2) warning: haskell-x509-store: local (1.4.4-9) is newer than haskell-core (1.4.4-2) warning: haskell-x509-validation: local (1.5.0-9) is newer than haskell-core (1.5.0-2) resolving dependencies... looking for inter-conflicts... error: failed to prepare transaction (could not satisfy dependencies) :: haskell-connection: requires haskell-network=2.4.2.2-60 :: haskell-connection: requires haskell-tls=1.2.6-5 :: haskell-connection: requires haskell-x509=1.4.11-5 :: haskell-connection: requires haskell-x509-store=1.4.4-9 :: haskell-connection: requires haskell-x509-validation=1.5.0-9 :: haskell-cookie: requires haskell-blaze-builder=0.3.3.2-59 :: haskell-cookie: requires haskell-text=1.1.1.1-1 :: haskell-cprng-aes: requires haskell-cipher-aes=0.2.7-3 :: haskell-cprng-aes: requires haskell-crypto-random=0.0.7-4 :: haskell-http-client-tls: requires haskell-http-client=0.3.2.1-2 :: haskell-http-client-tls: requires haskell-network=2.4.2.2-60 :: haskell-http-client-tls: requires haskell-tls=1.2.6-5 :: haskell-http-conduit: requires haskell-conduit=1.1.1.1-1 :: haskell-http-conduit: requires
Re: [arch-haskell] help upgrading packages
On Mon, May 12, 2014 at 3:33 PM, Nicola Squartini tens...@gmail.com wrote: On Mon, May 12, 2014 at 2:24 PM, Dawid Loubser dawid.loub...@ibi.co.za wrote: I had a similar issue with a large number of packages. I ended up removing and re-installing my entire Haskell ecosystem, and now things work again. Normally this should never happen. It's because Haskell is very strict on dependencies (despite being lazy on other things). In this case the reason was that those packages were added to the repository [haskell-core] with initial release number set to 1, although they had been in [haskell-happstack] already for some time and their release number was higher. I removed those immediately from [haskell-happstack] to avoid duplicate work, but they must also be manually removed from local, since pacman always keeps the highest version-release. In order to avoid this kind of issues in the future we should either have a policy to coordinate work between different haskell repositories, or merge everything into a unique repository and call it simply [haskell]. Indeed. This is entirely my fault! I have not been keeping track of what is available in any other repos at all. I was even under the impression that there were no other maintained repos at the moment. Clearly I am completely wrong :( I note the absence of certain packages like haskell-buildwrapper (which EclipseFP tools needs) - and reading the wiki, it seems confusing at this time whether the Haskell tinkerer / developer should just be using cabal-install to install all required packages (even though I know that cabal is not a package management system) or... what? Personally I don't like installing things using cabal-install because in my opinion the distro package manager should always be in charge. The same goes for me. Occasionally I revert to installing a package for the local user only, but not even then do I use `cabal install` to do that, I prefer running `./Setup.hs configure,build,install` myself. I do mean to look into using `cabal` myself at some point, because I keep on hearing good things about it. So far every time I've tried it I've run into something weird, most recently it was trying to install an older version of a lib than was needed, and I already had the newer version installed on my system too. A lot of terrifyingly clever people swear by it though, so there has to be something I'm missing out on! /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
I'm afraid that I am not one of those 'terrifyingly clever' people you speak of, Magnus, but in the past I have had a world of pain trying to use a mixture of packages between cabal and pacman. Had a very happy time using just pacman until *haskell-buildwrapper* disappeared recently, and I could no longer use my favourite Haskell IDE :-( I don't want to even try installing it using cabal, becuase then I'll be back in package-dependency hell. I have to say, I appreciate your efforts into making Haskell easy to use on Arch so very much - I don't mean to complain at all! regards, Dawid On 12/05/2014 15:47, Magnus Therning wrote: On Mon, May 12, 2014 at 3:33 PM, Nicola Squartini tens...@gmail.com wrote: On Mon, May 12, 2014 at 2:24 PM, Dawid Loubser dawid.loub...@ibi.co.za wrote: I had a similar issue with a large number of packages. I ended up removing and re-installing my entire Haskell ecosystem, and now things work again. Normally this should never happen. It's because Haskell is very strict on dependencies (despite being lazy on other things). In this case the reason was that those packages were added to the repository [haskell-core] with initial release number set to 1, although they had been in [haskell-happstack] already for some time and their release number was higher. I removed those immediately from [haskell-happstack] to avoid duplicate work, but they must also be manually removed from local, since pacman always keeps the highest version-release. In order to avoid this kind of issues in the future we should either have a policy to coordinate work between different haskell repositories, or merge everything into a unique repository and call it simply [haskell]. Indeed. This is entirely my fault! I have not been keeping track of what is available in any other repos at all. I was even under the impression that there were no other maintained repos at the moment. Clearly I am completely wrong :( I note the absence of certain packages like haskell-buildwrapper (which EclipseFP tools needs) - and reading the wiki, it seems confusing at this time whether the Haskell tinkerer / developer should just be using cabal-install to install all required packages (even though I know that cabal is not a package management system) or... what? Personally I don't like installing things using cabal-install because in my opinion the distro package manager should always be in charge. The same goes for me. Occasionally I revert to installing a package for the local user only, but not even then do I use `cabal install` to do that, I prefer running `./Setup.hs configure,build,install` myself. I do mean to look into using `cabal` myself at some point, because I keep on hearing good things about it. So far every time I've tried it I've run into something weird, most recently it was trying to install an older version of a lib than was needed, and I already had the newer version installed on my system too. A lot of terrifyingly clever people swear by it though, so there has to be something I'm missing out on! /M ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
Re: [arch-haskell] help upgrading packages
On Mon, May 12, 2014 at 4:02 PM, Dawid Loubser dawid.loub...@ibi.co.za wrote: I'm afraid that I am not one of those 'terrifyingly clever' people you speak of, Magnus, but in the past I have had a world of pain trying to use a mixture of packages between cabal and pacman. Had a very happy time using just pacman until haskell-buildwrapper disappeared recently, and I could no longer use my favourite Haskell IDE :-( I don't want to even try installing it using cabal, becuase then I'll be back in package-dependency hell. I have to say, I appreciate your efforts into making Haskell easy to use on Arch so very much - I don't mean to complain at all! Create a new issue for it on the github page[1], or even better dig into `cblrepo`, add it yourself, and send me a pull request ;) /M [1]: https://github.com/archhaskell/habs/issues -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus ___ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
