From johan.tibell at gmail.com Sat Mar 1 07:55:03 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat, 1 Mar 2014 08:55:03 +0100 Subject: Cabal-1.18.1.3 and cabal-install-1.18.0.3 RCs Message-ID: Hi all, I've uploaded release candidates for Cabal-1.18.1.3 (to be shipped with GHC 7.8) and cabal-install-1.18.0.3. You can install the RCs like so: cabal install http://johantibell.com/files/Cabal-1.18.1.3-rc.tar.gz http://johantibell.com/files/cabal-install-1.18.0.3-rc.tar.gz It's especially important that Cabal-1.18.1.3 gets some testing on OS X using GHC 7.8, as there's a change in how linking is done (see https://github.com/haskell/cabal/issues/1660). These RCs correspond to commit d310d87c2c445f52987169a2ce4da03c14070918 on the 1.18 branch in the cabal repo [1]. Note that both Cabal and cabal-install are released from the same repo. If you want to check which commits are new since last release run: git log Cabal-v1.18.1.2.. -- Cabal/ git log cabal-install-v1.18.0.2 -- cabal-install/ -- Johan 1. https://github.com/haskell/cabal -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Sat Mar 1 12:58:14 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Sat, 1 Mar 2014 13:58:14 +0100 Subject: Cabal File Pretty Printer In-Reply-To: References: <20140226131551.GA27344@machine> Message-ID: <20140301125814.GA10232@machine> Hi all, is there a reason why the function 'fieldGet' of 'FieldDescr' in 'Distribution.ParseUtils' formats only the contents of the field and not also the field name? Having the field 'build-type: Simple', then 'fieldGet' only formats the part 'Simple' and the 'build-type: ' part is formated in 'Distribution.PackageDescription.PrettyPrint'. This makes it harder to give certain fields a nesting without special casing in 'Distribution.PackageDescription.PrettyPrint'. If the complete field would be formated by 'fieldGet', then nesting could be nicely integrated into the 'listField' and 'commaListField' functions of 'Distribution.ParseUtils'. Greetings, Daniel From daniel.trstenjak at gmail.com Sat Mar 1 15:12:32 2014 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Sat, 1 Mar 2014 16:12:32 +0100 Subject: Cabal File Pretty Printer In-Reply-To: <20140301125814.GA10232@machine> References: <20140226131551.GA27344@machine> <20140301125814.GA10232@machine> Message-ID: <20140301151232.GA17854@machine> On Sat, Mar 01, 2014 at 01:58:14PM +0100, Daniel Trstenjak wrote: > is there a reason why the function 'fieldGet' of 'FieldDescr' in > 'Distribution.ParseUtils' formats only the contents of the field > and not also the field name? > > Having the field 'build-type: Simple', then 'fieldGet' only formats > the part 'Simple' and the 'build-type: ' part is formated in > 'Distribution.PackageDescription.PrettyPrint'. > > This makes it harder to give certain fields a nesting without special > casing in 'Distribution.PackageDescription.PrettyPrint'. > > If the complete field would be formated by 'fieldGet', then nesting > could be nicely integrated into the 'listField' and 'commaListField' > functions of 'Distribution.ParseUtils'. I have now created a pull request for this change on github. Is github the right place for doing this for cabal? Greetings, Daniel From johan.tibell at gmail.com Sat Mar 1 15:13:02 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat, 1 Mar 2014 16:13:02 +0100 Subject: Cabal File Pretty Printer In-Reply-To: <20140301151232.GA17854@machine> References: <20140226131551.GA27344@machine> <20140301125814.GA10232@machine> <20140301151232.GA17854@machine> Message-ID: On Sat, Mar 1, 2014 at 4:12 PM, Daniel Trstenjak wrote: > > On Sat, Mar 01, 2014 at 01:58:14PM +0100, Daniel Trstenjak wrote: > > is there a reason why the function 'fieldGet' of 'FieldDescr' in > > 'Distribution.ParseUtils' formats only the contents of the field > > and not also the field name? > > > > Having the field 'build-type: Simple', then 'fieldGet' only formats > > the part 'Simple' and the 'build-type: ' part is formated in > > 'Distribution.PackageDescription.PrettyPrint'. > > > > This makes it harder to give certain fields a nesting without special > > casing in 'Distribution.PackageDescription.PrettyPrint'. > > > > If the complete field would be formated by 'fieldGet', then nesting > > could be nicely integrated into the 'listField' and 'commaListField' > > functions of 'Distribution.ParseUtils'. > > I have now created a pull request for this change on github. > > Is github the right place for doing this for cabal? GitHub is the right place. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Mar 1 15:57:56 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 01 Mar 2014 16:57:56 +0100 Subject: check-pvp In-Reply-To: <20140228220055.GA28226@sniper> References: <5310EBD6.1060505@henning-thielemann.de> <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> Message-ID: <53120384.8010508@henning-thielemann.de> Am 28.02.2014 23:00, schrieb Roman Cheplyaka: > * Henning Thielemann [2014-02-28 22:48:59+0100] >> Nice! Is there a recommended way to transfer CPP options from the >> Cabal file to the CpphsOptions record? > > Yes, haskell-packages[2] lets you easily create a cabal-integrated > "compiler". See the compile method[3] in particular. > > For an example of how this all glues together, see [4]. > > [2]: http://hackage.haskell.org/package/haskell-packages > [3]: http://hackage.haskell.org/package/haskell-packages-0.2.3.4/docs/Distribution-HaskellSuite-Compiler.html#v:compile > [4]: https://github.com/haskell-suite/haskell-names/blob/master/hs-gen-iface/src/hs-gen-iface.hs#L70 Treating check-pvp as compiler driven by Cabal sounds reasonable, since this would do all the preprocessing stuff and would also work on tarballs etc. However the haskell-name framework seems to expect a binary executable as compiler. According to http://documentup.com/haskell-suite/haskell-names I would have to design the checker as a tool that only reads modules, not the package description, called maybe 'check-modules-pvp' and then run $ cabal install --haskell-suite -w check-modules-pvp mypkg My problem is: The checker needs to read the package description in order to classify the dependency ranges. The compiler has no access to the package description. If it tries to load the package description manually, that will fail on tarballs. I can also not see how I define my own command line options in the Compiler interface. From lemming at henning-thielemann.de Sat Mar 1 18:02:35 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 01 Mar 2014 19:02:35 +0100 Subject: check-pvp In-Reply-To: <53120384.8010508@henning-thielemann.de> References: <5310EBD6.1060505@henning-thielemann.de> <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> <53120384.8010508@henning-thielemann.de> Message-ID: <531220BB.3000601@henning-thielemann.de> Am 01.03.2014 16:57, schrieb Henning Thielemann: > Treating check-pvp as compiler driven by Cabal sounds reasonable, since > this would do all the preprocessing stuff and would also work on > tarballs etc. However the haskell-name framework seems to expect a > binary executable as compiler. According to > > http://documentup.com/haskell-suite/haskell-names > > I would have to design the checker as a tool that only reads modules, > not the package description, called maybe 'check-modules-pvp' and then run > > $ cabal install --haskell-suite -w check-modules-pvp mypkg I have pushed a new version to the repo that contains two executables: The stand-alone executable check-pvp and the haskell-suite compiler check-pvp-compiler: http://code.haskell.org/~thielema/check-pvp/ You can run the compiler with $ cabal install --haskell-suite -w check-pvp-compiler I got some problems. Using NamesDB as in hs-gen-iface works, but I guess, I do not need NamesDB and thus haskell-names. I tried to define a StandardDB type with a custom name type: data CheckPVPName = CheckPVPName instance IsDBName CheckPVPName where getDBName = Tagged "check-pvp" theTool :: Compiler.Simple (StandardDB CheckPVPName) However with this definition the above 'cabal install' fails in configuration phase utility$ cabal install --haskell-suite -w check-pvp-compiler Resolving dependencies... cabal: Could not resolve dependencies: trying: utility-ht-0.0.10 (user goal) next goal: base (dependency of utility-ht-0.0.10) rejecting: base-4.6.0.1, 4.6.0.0, 4.5.1.0, 4.5.0.0, 4.4.1.0, 4.4.0.0, 4.3.1.0, 4.3.0.0, 4.2.0.2, 4.2.0.1, 4.2.0.0, 4.1.0.0, 4.0.0.0 (only already installed instances can be used) rejecting: base-3.0.3.2 (conflict: base => base>=4.0 && <4.3) rejecting: base-3.0.3.1 (conflict: base => base>=4.0 && <4.2) Dependency tree exhaustively searched. I guess I do not understand the purpose of the StandardDB type and its associated name type. There is another problem: With NamesDB it worked, but the final installation phase fails, because check-pvp-compiler does not generate files. What is the recommended way to cope with compilers that do not write something to files? From roma at ro-che.info Sat Mar 1 21:11:17 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat, 1 Mar 2014 23:11:17 +0200 Subject: check-pvp In-Reply-To: <53120384.8010508@henning-thielemann.de> References: <5310EBD6.1060505@henning-thielemann.de> <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> <53120384.8010508@henning-thielemann.de> Message-ID: <20140301211117.GA20128@sniper> * Henning Thielemann [2014-03-01 16:57:56+0100] > Am 28.02.2014 23:00, schrieb Roman Cheplyaka: > > >* Henning Thielemann [2014-02-28 22:48:59+0100] > > >>Nice! Is there a recommended way to transfer CPP options from the > >>Cabal file to the CpphsOptions record? > > > >Yes, haskell-packages[2] lets you easily create a cabal-integrated > >"compiler". See the compile method[3] in particular. > > > >For an example of how this all glues together, see [4]. > > > >[2]: http://hackage.haskell.org/package/haskell-packages > >[3]: http://hackage.haskell.org/package/haskell-packages-0.2.3.4/docs/Distribution-HaskellSuite-Compiler.html#v:compile > >[4]: https://github.com/haskell-suite/haskell-names/blob/master/hs-gen-iface/src/hs-gen-iface.hs#L70 > > Treating check-pvp as compiler driven by Cabal sounds reasonable, > since this would do all the preprocessing stuff and would also work > on tarballs etc. However the haskell-name framework seems to expect a > binary executable as compiler. According to > > http://documentup.com/haskell-suite/haskell-names > > I would have to design the checker as a tool that only reads modules, > not the package description, called maybe 'check-modules-pvp' and > then run > > $ cabal install --haskell-suite -w check-modules-pvp mypkg > > My problem is: The checker needs to read the package description in > order to classify the dependency ranges. The compiler has no access > to the package description. Right, ? similar to how ghc doesn't access package description either. I guess there's no reason not to add such a feature, if you're willing to write a patch (to both haskell-packages and Cabal). > If it tries to load the package > description manually, that will fail on tarballs. Not sure what you mean here. What tarballs? > I can also not see how I define my own command line options in the > Compiler interface. Good point. I've added 'customMain' to git repo. Let me know if it works for you. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From lemming at henning-thielemann.de Sat Mar 1 21:22:27 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 01 Mar 2014 22:22:27 +0100 Subject: check-pvp In-Reply-To: <20140301211117.GA20128@sniper> References: <5310EBD6.1060505@henning-thielemann.de> <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> <53120384.8010508@henning-thielemann.de> <20140301211117.GA20128@sniper> Message-ID: <53124F93.2080705@henning-thielemann.de> Am 01.03.2014 22:11, schrieb Roman Cheplyaka: > * Henning Thielemann [2014-03-01 16:57:56+0100] >> >> My problem is: The checker needs to read the package description in >> order to classify the dependency ranges. The compiler has no access >> to the package description. > > Right, ? similar to how ghc doesn't access package description either. > I guess there's no reason not to add such a feature, if you're willing > to write a patch (to both haskell-packages and Cabal). > >> If it tries to load the package >> description manually, that will fail on tarballs. > > Not sure what you mean here. What tarballs? If foobar-0.2.tar.gz contains a tarball created by "cabal sdist", then I can install it via $ cabal install foobar-0.2.tar.gz In this case, cabal-install unpacks the archive, configures, builds and installs the package. It would be neat to run the pvp check in the same way: $ cabal install --haskellsuite -w check-pvp-compiler foobar-0.2.tar.gz However, this requires that check-pvp-compiler gets the path to the package description as parameter and does not try to load it from the current directory. >> I can also not see how I define my own command line options in the >> Compiler interface. > > Good point. I've added 'customMain' to git repo. Let me know if it works > for you. I'll try that. From roma at ro-che.info Sat Mar 1 21:29:58 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sat, 1 Mar 2014 23:29:58 +0200 Subject: check-pvp In-Reply-To: <531220BB.3000601@henning-thielemann.de> References: <5310EBD6.1060505@henning-thielemann.de> <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> <53120384.8010508@henning-thielemann.de> <531220BB.3000601@henning-thielemann.de> Message-ID: <20140301212958.GA23362@sniper> * Henning Thielemann [2014-03-01 19:02:35+0100] > Am 01.03.2014 16:57, schrieb Henning Thielemann: > > >Treating check-pvp as compiler driven by Cabal sounds reasonable, since > >this would do all the preprocessing stuff and would also work on > >tarballs etc. However the haskell-name framework seems to expect a > >binary executable as compiler. According to > > > > http://documentup.com/haskell-suite/haskell-names > > > >I would have to design the checker as a tool that only reads modules, > >not the package description, called maybe 'check-modules-pvp' and then run > > > >$ cabal install --haskell-suite -w check-modules-pvp mypkg > > I have pushed a new version to the repo that contains two > executables: The stand-alone executable check-pvp and the > haskell-suite compiler check-pvp-compiler: > http://code.haskell.org/~thielema/check-pvp/ > > You can run the compiler with > $ cabal install --haskell-suite -w check-pvp-compiler > > I got some problems. Using NamesDB as in hs-gen-iface works, but I > guess, I do not need NamesDB and thus haskell-names. Certainly not. Perhaps the compiler abstraction is not such a good fit for check-pvp. For a usual compiler, you need your dependencies to be installed. For check-pvp, you don't. And, as you note, check-pvp doesn't produce any artifacts either. I guess a new abstraction (and a new command, similar to build) should be added to haskell-packages to support such use cases. I have to think about this. (TBH I'm too concerned with what's happening to my country right now to think clearly.) If you have any suggestions, let me know. Are there any similar use cases to this one, or is it too different from anything else? In other words, is it worth it to create an abstraction for this? > I tried to define a StandardDB type with a custom name type: > > > data CheckPVPName = CheckPVPName > > instance IsDBName CheckPVPName where getDBName = Tagged "check-pvp" > > theTool :: Compiler.Simple (StandardDB CheckPVPName) > > > However with this definition the above 'cabal install' fails in > configuration phase > > utility$ cabal install --haskell-suite -w check-pvp-compiler > Resolving dependencies... > cabal: Could not resolve dependencies: > trying: utility-ht-0.0.10 (user goal) > next goal: base (dependency of utility-ht-0.0.10) > rejecting: base-4.6.0.1, 4.6.0.0, 4.5.1.0, 4.5.0.0, 4.4.1.0, 4.4.0.0, > 4.3.1.0, > 4.3.0.0, 4.2.0.2, 4.2.0.1, 4.2.0.0, 4.1.0.0, 4.0.0.0 (only already installed > instances can be used) > rejecting: base-3.0.3.2 (conflict: base => base>=4.0 && <4.3) > rejecting: base-3.0.3.1 (conflict: base => base>=4.0 && <4.2) > Dependency tree exhaustively searched. > > > I guess I do not understand the purpose of the StandardDB type and > its associated name type. > > > There is another problem: With NamesDB it worked, but the final > installation phase fails, because check-pvp-compiler does not > generate files. What is the recommended way to cope with compilers > that do not write something to files? > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From lemming at henning-thielemann.de Sat Mar 1 21:31:56 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 01 Mar 2014 22:31:56 +0100 Subject: check-pvp In-Reply-To: <20140301211117.GA20128@sniper> References: <5310EBD6.1060505@henning-thielemann.de> <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> <53120384.8010508@henning-thielemann.de> <20140301211117.GA20128@sniper> Message-ID: <531251CC.8020708@henning-thielemann.de> Am 01.03.2014 22:11, schrieb Roman Cheplyaka: > Good point. I've added 'customMain' to git repo. Let me know if it works > for you. I can't find Distribution.HaskellSuite.Compiler.customMain. :-( I pulled from master of git://github.com/haskell-suite/haskell-packages.git From lemming at henning-thielemann.de Sat Mar 1 21:40:46 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 01 Mar 2014 22:40:46 +0100 Subject: check-pvp In-Reply-To: <20140301212958.GA23362@sniper> References: <5310EBD6.1060505@henning-thielemann.de> <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> <53120384.8010508@henning-thielemann.de> <531220BB.3000601@henning-thielemann.de> <20140301212958.GA23362@sniper> Message-ID: <531253DE.4040703@henning-thielemann.de> Am 01.03.2014 22:29, schrieb Roman Cheplyaka: > * Henning Thielemann [2014-03-01 19:02:35+0100] >> I got some problems. Using NamesDB as in hs-gen-iface works, but I >> guess, I do not need NamesDB and thus haskell-names. > > Certainly not. > > Perhaps the compiler abstraction is not such a good fit for check-pvp. > > For a usual compiler, you need your dependencies to be installed. For > check-pvp, you don't. I need the packages installed, since if I find the dependency containers >=0.5 && <0.6 I need to know the modules belonging to "containers" in order to check imports of them. However, there is no need to run "check-pvp" on the imported packages - this is what cabal-install with check-pvp-compiler currently tries to do. > And, as you note, check-pvp doesn't produce any artifacts either. That's true. However, if haskell-package insists on a result per module I could write a test report for each module into a corresponding file. > I guess a new abstraction (and a new command, similar to build) > should be added to haskell-packages to support such use cases. I have to > think about this. (TBH I'm too concerned with what's happening to my > country right now to think clearly.) I see. > If you have any suggestions, let me know. Are there any similar use > cases to this one, or is it too different from anything else? In other > words, is it worth it to create an abstraction for this? So far I find the idea appealing to use the infrastructure for doing all the preprocessing. There might be more analysis tools that work the same way, but I have no concrete plans. From roma at ro-che.info Sat Mar 1 22:37:55 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 2 Mar 2014 00:37:55 +0200 Subject: check-pvp In-Reply-To: <531251CC.8020708@henning-thielemann.de> References: <5310EBD6.1060505@henning-thielemann.de> <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> <53120384.8010508@henning-thielemann.de> <20140301211117.GA20128@sniper> <531251CC.8020708@henning-thielemann.de> Message-ID: <20140301223755.GA24459@sniper> * Henning Thielemann [2014-03-01 22:31:56+0100] > Am 01.03.2014 22:11, schrieb Roman Cheplyaka: > > >Good point. I've added 'customMain' to git repo. Let me know if it works > >for you. > > I can't find Distribution.HaskellSuite.Compiler.customMain. :-( > I pulled from master of git://github.com/haskell-suite/haskell-packages.git D'oh, I forgot to export it. Should be fixed now. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From lemming at henning-thielemann.de Sat Mar 1 22:48:11 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 01 Mar 2014 23:48:11 +0100 Subject: check-pvp In-Reply-To: <20140301223755.GA24459@sniper> References: <5310EBD6.1060505@henning-thielemann.de> <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> <53120384.8010508@henning-thielemann.de> <20140301211117.GA20128@sniper> <531251CC.8020708@henning-thielemann.de> <20140301223755.GA24459@sniper> Message-ID: <531263AB.6030703@henning-thielemann.de> Am 01.03.2014 23:37, schrieb Roman Cheplyaka: > * Henning Thielemann [2014-03-01 22:31:56+0100] >> Am 01.03.2014 22:11, schrieb Roman Cheplyaka: >> >>> Good point. I've added 'customMain' to git repo. Let me know if it works >>> for you. >> >> I can't find Distribution.HaskellSuite.Compiler.customMain. :-( >> I pulled from master of git://github.com/haskell-suite/haskell-packages.git > > D'oh, I forgot to export it. Should be fixed now. [6 of 8] Compiling Distribution.HaskellSuite.Compiler ( src/Distribution/HaskellSuite/Compiler.hs, dist/build/Distribution/HaskellSuite/Compiler.o ) src/Distribution/HaskellSuite/Compiler.hs:21:5: Not in scope: `customMain' I guess this is because it is missing from Cabal. Seems that I have to provide options via the optparser interface. For check-pvp I have chosen the GetOpt module for portability reasons. Can I convert GetOpt stuff to optparser? From lemming at henning-thielemann.de Sat Mar 1 22:52:17 2014 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 01 Mar 2014 23:52:17 +0100 Subject: check-pvp In-Reply-To: <531263AB.6030703@henning-thielemann.de> References: <5310EBD6.1060505@henning-thielemann.de> <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> <53120384.8010508@henning-thielemann.de> <20140301211117.GA20128@sniper> <531251CC.8020708@henning-thielemann.de> <20140301223755.GA24459@sniper> <531263AB.6030703@henning-thielemann.de> Message-ID: <531264A1.2010906@henning-thielemann.de> Am 01.03.2014 23:48, schrieb Henning Thielemann: > [6 of 8] Compiling Distribution.HaskellSuite.Compiler ( > src/Distribution/HaskellSuite/Compiler.hs, > dist/build/Distribution/HaskellSuite/Compiler.o ) > > src/Distribution/HaskellSuite/Compiler.hs:21:5: > Not in scope: `customMain' > I guess this is because it is missing from Cabal. haskell-packages$ git diff --unified src/Distribution/HaskellSuite/Cabal.hs-boot diff --git a/src/Distribution/HaskellSuite/Cabal.hs-boot b/src/Distribution/HaskellSuite/Cabal.hs-boot index bc9bdfb..b45cbe5 100644 --- a/src/Distribution/HaskellSuite/Cabal.hs-boot +++ b/src/Distribution/HaskellSuite/Cabal.hs-boot @@ -1,7 +1,13 @@ module Distribution.HaskellSuite.Cabal where import {-# SOURCE #-} qualified Distribution.HaskellSuite.Compiler as Compiler +import Options.Applicative main :: Compiler.Is c => c -> IO () + +customMain + :: Compiler.Is c + => Parser (IO ()) + -> c -> IO () From roma at ro-che.info Sat Mar 1 23:04:38 2014 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 2 Mar 2014 01:04:38 +0200 Subject: check-pvp In-Reply-To: <531263AB.6030703@henning-thielemann.de> References: <20140228210646.GA26579@sniper> <5310FDE3.4020903@henning-thielemann.de> <20140228213119.GA26994@sniper> <5311044B.5020704@henning-thielemann.de> <20140228220055.GA28226@sniper> <53120384.8010508@henning-thielemann.de> <20140301211117.GA20128@sniper> <531251CC.8020708@henning-thielemann.de> <20140301223755.GA24459@sniper> <531263AB.6030703@henning-thielemann.de> Message-ID: <20140301230438.GA25029@sniper> * Henning Thielemann [2014-03-01 23:48:11+0100] > Am 01.03.2014 23:37, schrieb Roman Cheplyaka: > >* Henning Thielemann [2014-03-01 22:31:56+0100] > >>Am 01.03.2014 22:11, schrieb Roman Cheplyaka: > >> > >>>Good point. I've added 'customMain' to git repo. Let me know if it works > >>>for you. > >> > >>I can't find Distribution.HaskellSuite.Compiler.customMain. :-( > >>I pulled from master of git://github.com/haskell-suite/haskell-packages.git > > > >D'oh, I forgot to export it. Should be fixed now. > > [6 of 8] Compiling Distribution.HaskellSuite.Compiler ( > src/Distribution/HaskellSuite/Compiler.hs, > dist/build/Distribution/HaskellSuite/Compiler.o ) > > src/Distribution/HaskellSuite/Compiler.hs:21:5: > Not in scope: `customMain' > > > I guess this is because it is missing from Cabal. I applied your patch, thanks. > Seems that I have to provide options via the optparser interface. For > check-pvp I have chosen the GetOpt module for portability reasons. > Can I convert GetOpt stuff to optparser? I guess you could trick optparse-applicative into giving you the full argument list (see the argument' parser), and then parse that using GetOpt. If you ask Paolo maybe he'll show a more direct way to get hold of the argument list. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From fuuzetsu at fuuzetsu.co.uk Tue Mar 4 06:20:55 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 04 Mar 2014 06:20:55 +0000 Subject: Haddock fails with "Module defined in multiple files" Message-ID: <531570C7.10506@fuuzetsu.co.uk> Hi, We just got a bug report over at Haddock Trac[1]. What's not mentioned is that it works fine for the user on GHC 7.6.3 with Haddock 2.13.1. I can't think of any Haddock changes that could have potentially caused the reported breakage. This e-mail is to ask whether any Cabal(-install) devs can think of anything that might have changed on your end of things that could cause this before we go off chasing a bug in the wrong project. I don't follow the changes in cabal (even though I should) so it might be something really obvious that changed recently that we aren't aware of. Thanks [1]: http://trac.haskell.org/haddock/ticket/284 -- Mateusz K. From the.dead.shall.rise at gmail.com Tue Mar 4 06:38:00 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Tue, 4 Mar 2014 07:38:00 +0100 Subject: Haddock fails with "Module defined in multiple files" In-Reply-To: <531570C7.10506@fuuzetsu.co.uk> References: <531570C7.10506@fuuzetsu.co.uk> Message-ID: Hi, On 4 March 2014 07:20, Mateusz Kowalczyk wrote: > > I don't follow the changes in cabal (even though I should) so it might > be something really obvious that changed recently that we aren't aware of. Can this be related to https://github.com/haskell/cabal/pull/1374 ? I don't think that documentation for tests and benchmarks is enabled by default, though... From fuuzetsu at fuuzetsu.co.uk Tue Mar 4 07:28:39 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 04 Mar 2014 07:28:39 +0000 Subject: Haddock fails with "Module defined in multiple files" In-Reply-To: References: <531570C7.10506@fuuzetsu.co.uk> Message-ID: <531580A7.8090706@fuuzetsu.co.uk> On 04/03/14 06:38, Mikhail Glushenkov wrote: > Hi, > > On 4 March 2014 07:20, Mateusz Kowalczyk wrote: >> >> I don't follow the changes in cabal (even though I should) so it might >> be something really obvious that changed recently that we aren't aware of. > > Can this be related to https://github.com/haskell/cabal/pull/1374 ? I > don't think that documentation for tests and benchmarks is enabled by > default, though... > Hm, perhaps it could be this but as you mention, I don't think it's a default (but what do I know, maybe it --all or something was made a default in the bindist). I imagine that this problem would have come up 9 months ago, when the commit was merged however. I will of course investigate further over the next few days but any help is appreciated, especially if this turns out to be a big problem considering GHC rc2 is out of the door. -- Mateusz K. From johan.tibell at gmail.com Tue Mar 4 21:28:06 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 4 Mar 2014 22:28:06 +0100 Subject: Cabal-1.18.1.3 and cabal-install-1.18.0.3 releases made Message-ID: Hi, I've just made a release of Cabal/cabal-install, for the benefit of GHC 7.8. People have in the past expressed a desire for having prebuilt binaries of cabal-install. I'm happy to upload such binaries if people send them to me. Please specify for which arch/OS the binary is built. -- Johan From johan.tibell at gmail.com Tue Mar 4 21:29:52 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Tue, 4 Mar 2014 22:29:52 +0100 Subject: The 1.18 branch is reaching end-of-life Message-ID: Hi, With the 1.18 releases for GHC 7.8 out of the way, I'm going to retire the 1.18 branch* so please don't push any more commits to it. * Except if there are any late minute fixes *required* for GHC 7.8 to work well. -- Johan From johan.tibell at gmail.com Wed Mar 5 20:04:39 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Wed, 5 Mar 2014 21:04:39 +0100 Subject: Gearing up for 1.20 Message-ID: Hi, I'd like to get 1.20 out by the end of the month. There's enough interesting stuff in there to be worth making a release. Here are the current open issues for the 1.20 milestone: https://github.com/haskell/cabal/issues?milestone=21 These are mostly feature requests so we could technically do without any of them, but it would be nice to knock some off if people have some free weekend hacking time. Thoughts? -- Johan From juhp at community.haskell.org Fri Mar 7 04:41:51 2014 From: juhp at community.haskell.org (Jens Petersen) Date: Fri, 7 Mar 2014 13:41:51 +0900 Subject: Cabal-1.18.1.3 and cabal-install-1.18.0.3 releases made In-Reply-To: References: Message-ID: On 5 March 2014 06:28, Johan Tibell wrote: > I've just made a release of Cabal/cabal-install, for the benefit of GHC > 7.8. > Thanks!! I have now built them for Fedora 19 and 20 in my Fedora Copr repos: https://copr.fedoraproject.org/coprs/petersen/cabal-install/ https://copr.fedoraproject.org/coprs/petersen/Cabal (static only) You can also browse the repo at < http://copr-be.cloud.fedoraproject.org/results/petersen/cabal-install/> for example. Some notes: since the ghc-Cabal-devel package conflicts with the one in the Fedora repos I built it in a separate copr repo and then built cabal-install separately on top of that in its own repo so cabal-install can be updated without having to touch the system Cabal library (since other Fedora packages are linked to it), but I think some of the newer cabal-install features will not work unless one installs Cabal-1.18. Let me know if you have any problems or feedback on the packages/repos. Jens -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed Mar 12 16:51:50 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Wed, 12 Mar 2014 12:51:50 -0400 Subject: cabal doesn't explore the none manual flags very well Message-ID: Hey all, i'm repeatedly seeing many examples where a Manual : False flag is used to encode an "OR" in the cabal configuration, and where cabal "gives up" on finding the "right" build plan i know it can find if it has to flip the flag in a dependency its building... Is this a known issue? how can i mitigate it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From andres at well-typed.com Wed Mar 12 17:55:09 2014 From: andres at well-typed.com (=?ISO-8859-1?Q?Andres_L=F6h?=) Date: Wed, 12 Mar 2014 18:55:09 +0100 Subject: cabal doesn't explore the none manual flags very well In-Reply-To: References: Message-ID: Hi there. > i'm repeatedly seeing many examples where a Manual : False flag is used to > encode an "OR" in the cabal configuration, and where cabal "gives up" on > finding the "right" build plan i know it can find if it has to flip the flag > in a dependency its building... > > Is this a known issue? how can i mitigate it? It wasn't really known to me until recently. I'm currently looking at this issue, but I unfortunately don't have much time to work on it. As a workaround, it might help to add a package for which a suboptimal version is chosen because the flag is set to the wrong value explicitly as a target on the command line. Cheers, Andres -- Andres L?h, Haskell Consultant Well-Typed LLP, http://www.well-typed.com From leon.p.smith at gmail.com Wed Mar 12 18:16:43 2014 From: leon.p.smith at gmail.com (Leon Smith) Date: Wed, 12 Mar 2014 14:16:43 -0400 Subject: cabal doesn't explore the none manual flags very well In-Reply-To: References: Message-ID: Here's one example, and a comment for a possible long-term solution from Duncan Coutts: https://github.com/bos/aeson/issues/177 Best, Leon On Wed, Mar 12, 2014 at 1:55 PM, Andres L?h wrote: > Hi there. > > > i'm repeatedly seeing many examples where a Manual : False flag is used > to > > encode an "OR" in the cabal configuration, and where cabal "gives up" on > > finding the "right" build plan i know it can find if it has to flip the > flag > > in a dependency its building... > > > > Is this a known issue? how can i mitigate it? > > It wasn't really known to me until recently. > > I'm currently looking at this issue, but I unfortunately don't have > much time to work on it. As a workaround, it might help to add a > package for which a suboptimal version is chosen because the flag is > set to the wrong value explicitly as a target on the command line. > > Cheers, > Andres > > -- > Andres L?h, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andres at well-typed.com Wed Mar 12 18:35:36 2014 From: andres at well-typed.com (=?ISO-8859-1?Q?Andres_L=F6h?=) Date: Wed, 12 Mar 2014 19:35:36 +0100 Subject: cabal doesn't explore the none manual flags very well In-Reply-To: References: Message-ID: Hi. On Wed, Mar 12, 2014 at 7:16 PM, Leon Smith wrote: > Here's one example, and a comment for a possible long-term solution from > Duncan Coutts: > > https://github.com/bos/aeson/issues/177 Yes, thanks. This is in fact what prompted me looking at it. I think we can probably do a bit better by default even without adding a new kind of flags. But it'll require a (hopefully small) change to the solver, and as it's a heuristic, there's always a risk some other situations might get worse. Cheers, Andres -- Andres L?h, Haskell Consultant Well-Typed LLP, http://www.well-typed.com From andres at well-typed.com Wed Mar 12 20:04:35 2014 From: andres at well-typed.com (=?ISO-8859-1?Q?Andres_L=F6h?=) Date: Wed, 12 Mar 2014 21:04:35 +0100 Subject: cabal doesn't explore the none manual flags very well In-Reply-To: References: Message-ID: Hi there. I've pushed an experimental quick fix to https://github.com/kosmikus/cabal/tree/defer-flags I've briefly verified that it seems to fix the aeson issue mentioned in https://github.com/kosmikus/cabal/tree/defer-flags and one other test case I had lying around, but I haven't tested anything else. This change needs much more testing and experimentation. But if you'd like to try it, I'd welcome feedback on whether it at least solves a few concrete instances of this problem. Cheers, Andres On Wed, Mar 12, 2014 at 7:35 PM, Andres L?h wrote: > Hi. > > On Wed, Mar 12, 2014 at 7:16 PM, Leon Smith wrote: >> Here's one example, and a comment for a possible long-term solution from >> Duncan Coutts: >> >> https://github.com/bos/aeson/issues/177 > > Yes, thanks. This is in fact what prompted me looking at it. I think > we can probably do a bit better by default even without adding a new > kind of flags. But it'll require a (hopefully small) change to the > solver, and as it's a heuristic, there's always a risk some other > situations might get worse. > > Cheers, > Andres > > -- > Andres L?h, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com -- Andres L?h, Haskell Consultant Well-Typed LLP, http://www.well-typed.com From bos at serpentine.com Fri Mar 14 23:50:07 2014 From: bos at serpentine.com (Bryan O'Sullivan) Date: Fri, 14 Mar 2014 16:50:07 -0700 Subject: Github issues database really needs a cleanup Message-ID: There are literally hundreds of issues in there that I imported during the migration from trac that have never been touched since. Having the issue tracker be a graveyard of ancient junk that will never be touched does not strike me as a healthy state of affairs. Would anyone mind if I were to triage some of the old stuff and kill it off? -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.tibell at gmail.com Sat Mar 15 09:58:38 2014 From: johan.tibell at gmail.com (Johan Tibell) Date: Sat, 15 Mar 2014 10:58:38 +0100 Subject: Github issues database really needs a cleanup In-Reply-To: References: Message-ID: Please do. Gregory Collins and I took a stab at it at some point too, but there are lots and lots of bugs. Feel free to mark bugs as obsolete and close them if there haven't been any action in a long time. On Sat, Mar 15, 2014 at 12:50 AM, Bryan O'Sullivan wrote: > There are literally hundreds of issues in there that I imported during the > migration from trac that have never been touched since. > > Having the issue tracker be a graveyard of ancient junk that will never be > touched does not strike me as a healthy state of affairs. Would anyone mind > if I were to triage some of the old stuff and kill it off? > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at gregorycollins.net Sun Mar 16 23:30:39 2014 From: greg at gregorycollins.net (Gregory Collins) Date: Mon, 17 Mar 2014 00:30:39 +0100 Subject: Github issues database really needs a cleanup In-Reply-To: References: Message-ID: If I recall we closed something like 200 of them one night, but like you said that's a drop in the bucket. :( If we want to just do an expunge, I have an idea of what should happen: we give people a week to tag bugs that they care about and then kill the ones nobody loves, tagging them as being closed for this reason so people don't think they're resolved. Do you remember what the import date was? We should probably only delete bugs older than this. G On Sat, Mar 15, 2014 at 10:58 AM, Johan Tibell wrote: > Please do. Gregory Collins and I took a stab at it at some point too, but > there are lots and lots of bugs. Feel free to mark bugs as obsolete and > close them if there haven't been any action in a long time. > > > On Sat, Mar 15, 2014 at 12:50 AM, Bryan O'Sullivan wrote: > >> There are literally hundreds of issues in there that I imported during >> the migration from trac that have never been touched since. >> >> Having the issue tracker be a graveyard of ancient junk that will never >> be touched does not strike me as a healthy state of affairs. Would anyone >> mind if I were to triage some of the old stuff and kill it off? >> >> _______________________________________________ >> cabal-devel mailing list >> cabal-devel at haskell.org >> http://www.haskell.org/mailman/listinfo/cabal-devel >> >> > > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > > -- Gregory Collins -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlen at mlen.pl Fri Mar 21 00:09:04 2014 From: mlen at mlen.pl (Mateusz Lenik) Date: Fri, 21 Mar 2014 01:09:04 +0100 Subject: [Hackage] [GSoC] Improving authentication system in Hackage -- student looking for a mentor Message-ID: <20140321000904.GC63469@polaris.local> Hello everyone, I'm a student interested in improving the authentication system in Hackage during Google Summer of Code, but currently I don't have a mentor. Current version of my proposal is attached to this email. It can also be found on google-melange.com. Please contact me if you're interested in mentoring this project. Thank you, Mateusz -------------- next part -------------- Title: Improved Hackage login About the proposed project: The goal of this project is to refactor Hackage login/authentication system, improve UX using cookie-based approach and to replace outdated password hashing scheme with a secure one. I propose to use scrypt for password hashing scheme as it is not supported by oclhashcat password cracker. Another good choice would be bcrypt, as it also allows to specify a parameter to adjust the time complexity of hashing. For cookie-based approach I propose to use encrypted and signed cookies (similar approach Ruby on Rails uses), but with a small difference: cookies would be also tagged with expiration time before encryption and signing -- this should prevent reply attacks. Timeline of the project: 1. Switch Hackage to HTTPS -- parts of Hackage visible for logged in users and login forms should be available only over TLS. It would be even better if it is possible to switch Hackage to HTTPS only. 2. Disable Digest Authentication -- this step is necessary to replace MD5 hashing scheme. Care should be also taken of all projects that rely on Digest Auth. 3. Replace MD5 with scrypt -- the main goal of this project. A solution to switch over from MD5 to scrypt as user logs in for the first time should be implemented. 4. Implement cookie-based authentication -- Basic Auth can be left enabled after this step is implemented to allow automatic tools to access Hackage. From this point there are two ways to enhance Hackage: 5a. Implement token based authentication -- libraries and automatic tools would be able to use a token or an API key to access Hackage instead of Basic Auth. 5b. Adapt the UI for the logged in user. Currently I'm looking into Hackage source code to be able to provide estimates on how long each of these steps would take. About the author: My name is Mateusz Lenik and I?m studying computer science at Technical University in Wroc?aw, Poland. My major during BSc was internet engineering and now my major is software and network security. I work half-time as Ruby developer and I help to organise annual Ruby conference in Wroc?aw. I got interested in Haskell a year ago, mostly because tools I used at that time made it really hard to write safe and secure code that it is easy to reason about. Unfortunately I still have to use Ruby for most of the code I write. My Haskell experience seems to be sufficient to finish this project (and I expect to learn a lot more than I know now during the project). Additionally I?ve got decent knowledge about system administration (Debian, ArchLinux), provisioning tools (Chef, Puppet), web security practices (OWASP Top 10 et al) and general web development. I expect to be able to work on the project up to 20 hours per week (with an exception of one week in may). After the project I?d love to contribute more to Haskell community, but I can?t promise that -- I?m graduating this year and I can not predict how my life is going to change after the graduation. Email: mlen at mlen.pl GPG fingerprint: B865 E86A D36C 11A5 C1F8 C1D9 AAD4 CEC9 6B94 92C4 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From fuuzetsu at fuuzetsu.co.uk Mon Mar 24 17:54:25 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 24 Mar 2014 17:54:25 +0000 Subject: module =?windows-1252?Q?=91free-4=2E6=2E1=3AMain=92_is_defin?= =?windows-1252?Q?ed_in_multiple_files?= Message-ID: <53307151.9010800@fuuzetsu.co.uk> Greetings, First of all to people reading this at ghc-devs, I don't expect this to be a direct problem caused by GHC but who knows, so I'm CC'ing it anyway. As you might know, GHC 7.8.1 is scheduled to release Very Soon? (later today?). We got a report at Haddock Trac few weeks ago about a strange error, see http://trac.haskell.org/haddock/ticket/284. I have asked about this on cabal-devel before and Mikhail said that maybe it's https://github.com/haskell/cabal/pull/1374 but it's unlikely because the changes aren't ran by default. Today I got new reports of this problem and so far everyone on OSX seems to be affected! This suddenly became a big problem. To replicate: 1. Find OSX machine 2. Get GHC 7.8 rc2 package (which includes Haddock at that stage) 3. git clone git at github.com:ekmett/free.git && cd free 4. cabal install --only-dependencies --enable-documentation && cabal configure && cabal haddock The reason I'm barking up cabal-devel and ghc-devs is because I honestly can not think of anything that has changed since Haddock 2.13.2.1 that could possibly cause this. Does anyone have any idea at all? I think it would be very bad to release now and have everyone on OSX unable to build docs. FYI I get build docs on 32-bit Linux. No idea about Windows. Thanks, I hope to hear back soon. PS: How does one go about downgrading Cabal and cabal-install? If we wanted to check whether cabal is the problem, how? -- Mateusz K. From the.dead.shall.rise at gmail.com Mon Mar 24 21:26:42 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon, 24 Mar 2014 22:26:42 +0100 Subject: module 'free-4.6.1:Main' is defined in multiple files In-Reply-To: <53307151.9010800@fuuzetsu.co.uk> References: <53307151.9010800@fuuzetsu.co.uk> Message-ID: Hi, On 24 March 2014 18:54, Mateusz Kowalczyk wrote: > > PS: How does one go about downgrading Cabal and cabal-install? If we > wanted to check whether cabal is the problem, how? You can force the Cabal lib version to use (in case you have multiple versions installed) with 'install --cabal-lib-version'. To downgrade cabal-install itself to some older version you need to compile and install that version. From fuuzetsu at fuuzetsu.co.uk Mon Mar 24 21:33:44 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Mon, 24 Mar 2014 21:33:44 +0000 Subject: module 'free-4.6.1:Main' is defined in multiple files In-Reply-To: References: <53307151.9010800@fuuzetsu.co.uk> Message-ID: <5330A4B8.2010802@fuuzetsu.co.uk> On 24/03/14 21:26, Mikhail Glushenkov wrote: > Hi, > > On 24 March 2014 18:54, Mateusz Kowalczyk wrote: >> >> PS: How does one go about downgrading Cabal and cabal-install? If we >> wanted to check whether cabal is the problem, how? > > You can force the Cabal lib version to use (in case you have multiple > versions installed) with 'install --cabal-lib-version'. To downgrade > cabal-install itself to some older version you need to compile and > install that version. > About cabal-install, I'm mostly concerned about not breaking my whole existing system by installing an old version. Are there any steps I can take to retain sane setup? I don't have an OSX machine and I can't exactly ask people volunteering to break their Haskell environments. Are there any catches to having multiple Cabal libs installed or will the latest one always be used if not specified? -- Mateusz K. From the.dead.shall.rise at gmail.com Mon Mar 24 21:47:46 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Mon, 24 Mar 2014 22:47:46 +0100 Subject: module 'free-4.6.1:Main' is defined in multiple files In-Reply-To: <5330A4B8.2010802@fuuzetsu.co.uk> References: <53307151.9010800@fuuzetsu.co.uk> <5330A4B8.2010802@fuuzetsu.co.uk> Message-ID: Hi, On 24 March 2014 22:33, Mateusz Kowalczyk wrote: > On 24/03/14 21:26, Mikhail Glushenkov wrote: >> Hi, >> >> On 24 March 2014 18:54, Mateusz Kowalczyk wrote: >>> >>> PS: How does one go about downgrading Cabal and cabal-install? If we >>> wanted to check whether cabal is the problem, how? >> >> You can force the Cabal lib version to use (in case you have multiple >> versions installed) with 'install --cabal-lib-version'. To downgrade >> cabal-install itself to some older version you need to compile and >> install that version. >> > > About cabal-install, I'm mostly concerned about not breaking my whole > existing system by installing an old version. Are there any steps I can > take to retain sane setup? I don't have an OSX machine and I can't > exactly ask people volunteering to break their Haskell environments. Use a sandbox to compile the cabal-install executable: $ cd cabal/cabal-install $ cabal sandbox init $ cabal sandbox add-source ../Cabal $ cabal install --dependencies-only && cabal build And then copy it to somewhere in PATH: $ cp dist/build/cabal/cabal ~/bin/cabal-1.18 > Are there any catches to having multiple Cabal libs installed or will > the latest one always be used if not specified? Yes, the latest one is always used. From Pierre-etienne.Meunier at lif.univ-mrs.fr Wed Mar 26 10:18:22 2014 From: Pierre-etienne.Meunier at lif.univ-mrs.fr (=?iso-8859-1?Q?Pierre-=C9tienne_Meunier?=) Date: Wed, 26 Mar 2014 11:18:22 +0100 Subject: Bug on lhs files Message-ID: <41EF8213-201E-4349-914D-CAB599C5B4F2@lif.univ-mrs.fr> Hi, There is a bug in cabal haddock, when lines in an lhs file start with a $, which is quite common when writing a paper with large TeX fragments in the programs. For instance, cabal haddock fails on the following lhs file: blabla, blibli $a+b$ \begin{code} main=putStrLn "Hello" \end{code} I first thought it was a haddock bug, but the haddock maintainers disagree:http://trac.haskell.org/haddock/ticket/293 Pierre-?tienne Meunier From the.dead.shall.rise at gmail.com Wed Mar 26 10:42:31 2014 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 26 Mar 2014 11:42:31 +0100 Subject: Bug on lhs files In-Reply-To: <41EF8213-201E-4349-914D-CAB599C5B4F2@lif.univ-mrs.fr> References: <41EF8213-201E-4349-914D-CAB599C5B4F2@lif.univ-mrs.fr> Message-ID: Hi, On 26 March 2014 11:18, Pierre-?tienne Meunier wrote: > Hi, > > There is a bug in cabal haddock, when lines in an lhs file start with a $, which is quite common when writing a paper with large TeX fragments in the programs. Can you please file an issue at https://github.com/haskell/cabal/issues/new ? I'll look into this when I'll have time. From lambda.fairy at gmail.com Fri Mar 28 08:17:39 2014 From: lambda.fairy at gmail.com (Chris Wong) Date: Fri, 28 Mar 2014 21:17:39 +1300 Subject: GSoC - request for mentor Message-ID: Hi all, Like Mateusz Lenik, I am looking for a mentor for the Google Summer of Code. The project aims to make various improvements to Hackage, such as exposing build reports and documentation uploads. An initial proposal is here [1], though as Greg Weber notes, the details may change if the project is accepted. Feel free to ping me if mentoring interests you. Chris [1] http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/lambda_fairy/5741031244955648 From fuuzetsu at fuuzetsu.co.uk Fri Mar 28 13:55:21 2014 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Fri, 28 Mar 2014 13:55:21 +0000 Subject: GSoC - request for mentor In-Reply-To: References: Message-ID: <53357F49.40900@fuuzetsu.co.uk> On 28/03/14 08:17, Chris Wong wrote: > Hi all, > > Like Mateusz Lenik, I am looking for a mentor for the Google Summer of > Code. The project aims to make various improvements to Hackage, such > as exposing build reports and documentation uploads. > > An initial proposal is here [1], though as Greg Weber notes, the > details may change if the project is accepted. > > Feel free to ping me if mentoring interests you. > > Chris > > [1] http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/lambda_fairy/5741031244955648 > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > Hi, I can't read the proposal, I get You are not logged in as the user in the URL. Perhaps you should try giving us a different URL? -- Mateusz K. From lambda.fairy at gmail.com Fri Mar 28 22:12:43 2014 From: lambda.fairy at gmail.com (Chris Wong) Date: Sat, 29 Mar 2014 11:12:43 +1300 Subject: GSoC - request for mentor In-Reply-To: <53357F49.40900@fuuzetsu.co.uk> References: <53357F49.40900@fuuzetsu.co.uk> Message-ID: Sorry -- I thought the GSoC link was public! Here's another copy: https://docs.google.com/document/d/1bcDiudULtaz3NFCqTHXD2WU6Ighsm199D7ojfS8quVI/edit?usp=sharing On Sat, Mar 29, 2014 at 2:55 AM, Mateusz Kowalczyk wrote: > On 28/03/14 08:17, Chris Wong wrote: >> Hi all, >> >> Like Mateusz Lenik, I am looking for a mentor for the Google Summer of >> Code. The project aims to make various improvements to Hackage, such >> as exposing build reports and documentation uploads. >> >> An initial proposal is here [1], though as Greg Weber notes, the >> details may change if the project is accepted. >> >> Feel free to ping me if mentoring interests you. >> >> Chris >> >> [1] http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/lambda_fairy/5741031244955648 >> _______________________________________________ >> cabal-devel mailing list >> cabal-devel at haskell.org >> http://www.haskell.org/mailman/listinfo/cabal-devel >> > > Hi, > > I can't read the proposal, I get > > You are not logged in as the user in the URL. > > Perhaps you should try giving us a different URL? > > -- > Mateusz K. > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel From carter.schonwald at gmail.com Fri Mar 28 22:33:06 2014 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 28 Mar 2014 18:33:06 -0400 Subject: GSoC - request for mentor In-Reply-To: References: <53357F49.40900@fuuzetsu.co.uk> Message-ID: I believe duncan coutts is going to wind up being the mentor if he has time, he's currently moving into his new apt this week, so I suspect you'll hear from him next week :) try emailing him directly, and or ping edwardk on #haskell-gsoc on freenode for help with mentor matching. I seem to be assigned to mentor another hackage project as is.... so i'm open to being a backup if its really needed (mind you i'm also slated to potentially mentor 2 other projects as is... :) ) On Fri, Mar 28, 2014 at 6:12 PM, Chris Wong wrote: > Sorry -- I thought the GSoC link was public! > > Here's another copy: > > https://docs.google.com/document/d/1bcDiudULtaz3NFCqTHXD2WU6Ighsm199D7ojfS8quVI/edit?usp=sharing > > On Sat, Mar 29, 2014 at 2:55 AM, Mateusz Kowalczyk > wrote: > > On 28/03/14 08:17, Chris Wong wrote: > >> Hi all, > >> > >> Like Mateusz Lenik, I am looking for a mentor for the Google Summer of > >> Code. The project aims to make various improvements to Hackage, such > >> as exposing build reports and documentation uploads. > >> > >> An initial proposal is here [1], though as Greg Weber notes, the > >> details may change if the project is accepted. > >> > >> Feel free to ping me if mentoring interests you. > >> > >> Chris > >> > >> [1] > http://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014/lambda_fairy/5741031244955648 > >> _______________________________________________ > >> cabal-devel mailing list > >> cabal-devel at haskell.org > >> http://www.haskell.org/mailman/listinfo/cabal-devel > >> > > > > Hi, > > > > I can't read the proposal, I get > > > > You are not logged in as the user in the URL. > > > > Perhaps you should try giving us a different URL? > > > > -- > > Mateusz K. > > _______________________________________________ > > cabal-devel mailing list > > cabal-devel at haskell.org > > http://www.haskell.org/mailman/listinfo/cabal-devel > _______________________________________________ > cabal-devel mailing list > cabal-devel at haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: