Re: [Haskell-cafe] ANN: Cabal v1.18.0 released
I ran into another oddity due to old build artifacts today -- it was easy to fix, but very confusing; cabal repl was exiting with unrecognised command: repl. tl/dr; if you see this, delete the old 'dist' dir and re-run 'cabal configure'. Here's a snippit of my shell session to explain in more detail: $ cabal sandbox init ... $ cabal --version cabal-install version 1.18.0 using version 1.18.0 of the Cabal library $ cabal configure Resolving dependencies... Configuring pgftransform-0.0.0.1... $ cabal repl unrecognised command: repl (try --help) $ cabal --help ... Commands: ... buildCompile all targets or specific targets. repl Open an interpreter session for the given target. sandbox Create/modify/delete a sandbox. ... Note that cabal --version and cabal --help indicated that repl /was/ a valid command. The issue appears to be that an old dist directory was still hanging around, and (I suspect) the compiled setup.hs build program (which would have been built with an old Cabal) was causing the actual error. Deleting the dist dir and re-running cabal configure set everything right. --Rogan On Thu, Sep 5, 2013 at 6:18 AM, Yuri de Wit yde...@gmail.com wrote: It is easy enough to recreate the link manually or as easy to run cabal install again, but that is not the point here. The point is that it will bite the next dozen of unsuspecting users since, at first, they have no idea of what is going on. In any case, apologies for sending this in this thread as it doesn't seem the right forum to discuss it. On Thu, Sep 5, 2013 at 7:53 AM, Paolo Giarrusso p.giarru...@gmail.comwrote: On Wednesday, September 4, 2013 11:41:33 PM UTC+2, Yuri de Wit wrote: Thanks for all the hard work! If you see this in OSX (#1009) while installing cabal 1.18: *Warning: could not create a symlink in /Users/lemao/Library/Haskell/bin for* *cabal because the file exists there already but is not managed by cabal. You* *can create a symlink for this executable manually if you wish. The executable* *file has been installed at* */Users/user/Library/Haskell/ghc-7.6.3/lib/cabal-install-1. 18.0/bin/cabal* You will need to manually remove the pre-existing 1.16 links in ~/Library/Haskell/bin before installing again. Instead of installing again, you can even just recreate the symlink as mentioned by the message (if you know how to do that). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Hackage's packages should be seperated by buildable
On Sun, Aug 25, 2013 at 12:48 AM, He-chien Tsai depot...@gmail.com wrote: I'm sick for checking whether package is obsolete or not. I think packages build failed long time ago should be collected and moved to another page until someone fix them, or hackage pages should have a filter for checking obsolete packages. I don't believe hackage can (currently) do this with a sufficient level of precision. *Many* packages fail to build on hackage because they depend on c-libraries that need to be installed externally from cabal. There are some mitigations for this in the works (although, it's been that way for some time now...). Hackage 2 should have some community-involvement features (such as ratings, tags, etc..) that can enable better rankings of packages, and there is a hackage reverse-dependencies database that can also be used as a rough indicator of stability. That said, I do firmly believe that we should have multiple instances of hackage at various levels of stability (and at corresponding levels of scrutiny). At the moment, we have the Haskell Platform on one end of this continuum of stability, and hackage at the other. It would be useful to have something in the middle. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PPC binaries for GHC 7.x?
Does anyone have PPC binaries for GHC 7.x? I've been trying to help a PPC user compile a large haskell application, and it (and it's dependencies) require a newer ghc; the latest ppc binaries we've found are for 6.10, and we have been unable to compile a never ghc from source (6.12 /almost/ worked, but eventually failed with a linker error that appears to be unsolvable in the near-term). Thanks! Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PPC binaries for GHC 7.x?
On Wed, Aug 21, 2013 at 2:29 AM, Joey Adams joeyadams3.14...@gmail.comwrote: What operating system? Oh, I should have specified -- OS X (I'm not certain which version of OS X; probably not particularly new) --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform and Leksah on Windows
On Thu, Aug 8, 2013 at 11:58 AM, Dorin Lazar dorin.la...@gmail.com wrote: I was also in awe of the fact that nobody really says anything about these difficulties, and felt like an estranged child that messed things up badly; however, it seems that the real issue is that nobody really does it that way, and I was wrong to actually try it like that. There's nothing wrong with trying that -- it's a very common temptation for developers coming from other languages. I use Eclipse extensively when writing Java, for the reason's you've mentioned and I was dissapointed when I couldn't find anything similar for Haskell, unfortunately, there still just isn't such an IDE for Haskell yet. Leskah, EclipseFP, FP Haskell Center, etc... are starting points, but they are still lacking in some areas. I think most of us just use a (relatively fancy) text editor, and cabal (or cabal-dev, cab, capri, etc...). You're not likely to find features like refactoring tools or content assist in an easy-to-install Haskell environment right now. --Rogan As I said (or haven't, but will) once I will get the hang of it I will recount my experience for others to follow, hopefully in better terms than this frustrating first experience. Many thanks for everyone's advice on the list, Dorin On Thu, Aug 8, 2013 at 9:48 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey Dorin, I don't understand your claims. 1) haskell has worked perfectly well on windows for quite some time. I used HUGs nearly a decade ago, and in more recent time (2-3 years ago) I helped teach an introductory first computer science class using GHC where many students were doing great work using notepad++ and ghci. I don't understand your focus on emacs and make files. 2) if you want an IDE experience, Sublime Text with the right plugins, or perhaps EclipseFP are worth checking out. 3) likewise, if you're finding tooling on windows unsatisfactory, help fix it! Bug reports, patches, or new tools and libraries are always welcome. Haskell is a relatively small community, and thusly limited manpower (we're all volunteers), so way to fix any problem is help out! cheers On Thu, Aug 8, 2013 at 3:30 AM, Dorin Lazar dorin.la...@gmail.com wrote: Hello, I am the original author of the post, and I finally received the emails from the mailman (probably there was an issue with the automated requests). My answers are inlined. 1) Leksah should not be considered an official haskell ide, but merely one of many community supported editing tools. And frankly one of the less widely used ones at that! Leksah is not used much at all by anyone, though theres probably a handful of folks who do use it. Many folks use editors like Sublime Tex (2/3), Emacs, Vi(m), textmate, and many more. Its worth noting that the sublime-haskell plugin for sublime text, and analogous packages for many other editors, provide haskell IDE-like powers, or at least a nice subset thereof. Unfortunately, I think the problem with this is that we have a different vision on how development should be done. I have extensive experience of working from console, with a simple text editor and hand-made Makefiles or anything similar. However, an IDE should be a productivity tool, that can help you improve your understanding of the language, and can assist you in following the proper syntax for a new language. While learning by doing 'write, save, compile, examine error message' is ok with me, it is slow, and it limits the time I can dedicate to learning the language itself. A better cycle is the current 'write, examine error message' of most IDEs, since it's faster and requires no context switch. Sure, editors can help there. IDEs do this by default. So it's normal of me to search for an IDE to better learn the language, I'll leave the emacs + console version for when I am productive in the language. 2) There are people working on building better easily portable native gui toolkits, but in many respects, a nice haskelly gui toolkit is still something people are experimetning with how to do well. theres lots of great tools out as of the past year or two, many more in progress on various time scales, and gtk2hs is great for linux (and thats fine). Unfortunately, this is not what's advertised. In fact, on the leksah site, the recommended method is to have the IDE installed via cabal. In another mail Mihai calls me unreasonable, but I think it's reasonable to think that the recommended method should be the one that works. But the easy to tell truth is that the Haskell Platform for Windows is not mature enough yet. That is something I can understand, and I can recommend other beginners to install a Linux VM for Haskell. That is perfectly fine, zero cost, 100% gain. However, the mistakes from the Haskell Platform as it
Re: [Haskell-cafe] List Monads and non-determinism
On Fri, Jul 19, 2013 at 3:23 PM, Matt Ford m...@dancingfrog.co.uk wrote: I started by putting brackets in ([1,2] = \n - [3,4]) = \m - return (n,m) This immediately fails when evaluated: I expect it's something to do with the n value now not being seen by the final return. You're bracketing from the wrong end, which your intuition about n's visibility hints at. Try this as your first set of parens: [1,2] = (\n - [3,4] = \m - return (n,m)) --Rogan It seems to me that the return function is doing something more than it's definition (return x = [x]). If ignore the error introduced by the brackets I have and continue to simplify I get. [3,4,3,4] = \m - return (n,m) Now this obviously won't work as there is no 'n' value. So what's happening here? Return seems to be doing way more work than lifting the result to a list, how does Haskell know to do this? Why's it not in the function definition? Are lists somehow a special case? Any pointers appreciated. Cheers, -- Matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] List Monads and non-determinism
On Fri, Jul 19, 2013 at 3:58 PM, Matt Ford m...@dancingfrog.co.uk wrote: Hi, Thanks for the help. I thought = was left associative? It seems to be in the examples from Learn You A Haskell. I tried to use the associative law to bracket from the right but it didn't like that either... [1,2] = (\x - (\n - [3,4])) x = \m - return (n,m)) I think the issue is that you need to first take into account the lambdas *then* use what you know about the properties of (=). I found this stackoverflow answer helpful ( http://stackoverflow.com/a/11237469) The rule for lambdas is pretty simple: the body of the lambda extends as far to the right as possible without hitting an unbalanced parenthesis. So, the first lambda runs to the end of the expression: [1,2] = (\n - [3,4] = \m - return (n,m)) Now, there is still a lambda nested inside the first lambda: \m - return (n,m) [1,2] = (\n - [3,4] = (\m - return (n,m))) You violated the implied grouping that these new parentheses make explicit when you tried to apply the associative law above. Timon's post continues from this point to show the full deconstruction. --Rogan Any thoughts? Matt On 19 Jul 2013, at 23:35, Rogan Creswick cresw...@gmail.com wrote: On Fri, Jul 19, 2013 at 3:23 PM, Matt Ford m...@dancingfrog.co.uk wrote: I started by putting brackets in ([1,2] = \n - [3,4]) = \m - return (n,m) This immediately fails when evaluated: I expect it's something to do with the n value now not being seen by the final return. You're bracketing from the wrong end, which your intuition about n's visibility hints at. Try this as your first set of parens: [1,2] = (\n - [3,4] = \m - return (n,m)) --Rogan It seems to me that the return function is doing something more than it's definition (return x = [x]). If ignore the error introduced by the brackets I have and continue to simplify I get. [3,4,3,4] = \m - return (n,m) Now this obviously won't work as there is no 'n' value. So what's happening here? Return seems to be doing way more work than lifting the result to a list, how does Haskell know to do this? Why's it not in the function definition? Are lists somehow a special case? Any pointers appreciated. Cheers, -- Matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal-dev: installing/running with profiling enabled
Hi Ömer, I've replied in-line below. On Mon, Jul 1, 2013 at 2:34 PM, Ömer Sinan Ağacan omeraga...@gmail.comwrote: So I tried installing the program in a fresh cabal-dev environment with profiling enabled, so that all dependencies would be also installed with profiling enabled. But for some reason even after installing with `cabal-dev install --enable-executable-profiling -prof` I still can't run this program with `caba-dev/bin/program +RTS -p`, it fails with 'program: the flag -p requires the program to be built with -prof'. Because you're installing libraries (into the cabal-dev sandbox) you'll also need to add the --enable-library-profiling flag, in addition to the --enable-executable-profiling flag. Cabal-dev could infer the former from the later, but we haven't done that (this doesn't seem to come up very often). I don'th think the -prof flag is necessary; but if it is, then it may also be misinterpreted by cabal-dev; generally, you need to pass flags that only use a single leading - to cabal-dev with the --flags=... option. (eg: 'cabal-dev install --enable-library-profiling --enable-executable-profiling --flags=-prof' This command worked for me: $ cabal-dev install --enable-library-profiling --enable-executable-profiling Note that you must remove the existing cabal-dev sandbox directory before running that command (or the installed dependencies that were built without library profiling can cause the build to fail. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC Project Proposal: Markdown support for Haddock
On Fri, Apr 5, 2013 at 10:12 AM, Petr Pudlák petr@gmail.com wrote:
While I like the idea of allowing any markup language (let's say supported
by Pandoc) and freedom it gives to developers, it also has also drawbacks:
It makes contributing more difficult, if a project uses some wierd,
non-standard markup language.
I feel pretty strongly about this; I don't think we gain much by allowing
arbitrary formats. I think the same argument for coding conventions
applies here -- consistency is much more important for readability than
flexibility.
--Rogan
Concerning math expressions, what about using Markdown with MathJAX, like
math.stackexchange.com does?
Best regards,
Petr Pudlak
2013/4/5 Andrew Butterfield andrew.butterfi...@scss.tcd.ie
I'm not proposing the LaTeX is used for hyperlinking the
reference - hence my comment about nicely integrating
Perhaps a \begin{haddock} ... \end{haddock} environment* ?
* This would only affect those using LaTeX/lhs - everyone else could
haddock** as usual
** haddock = whatever markdow/up/sideways scheme you guys come up with...
On 5 Apr 2013, at 16:22, Aleksey Khudyakov wrote:
On 5 April 2013 12:20, Andrew Butterfield
andrew.butterfi...@scss.tcd.ie wrote:
On 4 Apr 2013, at 22:53, Aleksey Khudyakov wrote:
If we are going to change haddock syntax we should add ability to add
math formulae to documentation. It's not currently possible and it
makes
documenting numeric code properly difficult.
How about support for .lhs files?
- both those with bird-tracks (which I don't use anymore)
and \begin{code}...\end{code} (which I do use).
My .lhs files are also LaTeX sources - I guess some way to nicely
integrate
haddock markup/down/whatever with LaTeX stuff would be needed
I'm not sure that it would help. If we to use haddock markup it need to
support math typesetting. And LaTeX IMHO isn't right tool for creating
hyperlinked API reference
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Foundations Methods Research Group
Director of Teaching and Learning - Undergraduate,
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
http://www.scss.tcd.ie/Andrew.Butterfield/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: cabal-dev 0.9.2 - sandboxed haskell builds
The (ever growing) cabal-dev team is happy to announce v. 0.9.2! Cabal-dev is a tool to test development libraries by creating a sandboxed package and dependency build environment. Executing `cabal-dev install` will create a sandbox, named cabal-dev in the current directory, and populate it with the project dependencies, which are built and installed into a package database within the sandbox. This is a bug-fix/maintenance release, but it's worth noting that it is now possible to build cabal-dev from hackage with a recent GHC. We've also decided to focus our efforts to provide support for the current release of GHC, the current Haskell Platform, and the previous Haskell Platform. This is the long-awaited version that actually builds with recent GHC's (7.6, in particular). A great deal of thanks for this release to go to active members of the community who've patiently directed other Haskell users to the github repo for a working cabal-dev, and in particular to the dozens (!) of you who've submitted bug reports and patches that resulted in this release (in particular: Bob Ippolito for not only fixing a race condition that caused the test suite to fail. Thanks Bob!)). Urls: * Hackage: http://hackage.haskell.org/package/cabal-dev * Issue tracker: http://github.com/creswick/cabal-dev/issues * Github repo: http://github.com/creswick/cabal-dev --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best approach to avoid dependency hells
On Wed, Dec 5, 2012 at 11:13 AM, Jason Dagit dag...@gmail.com wrote: Let's say you are working in a directory foo that contains a cabal file for package foo. When you type 'cabal-dev install', cabal-dev looks at foo.cabal in the current directory, it uses it to calculate constraints and then installs the dependencies locally that satisfy those constraints. It also has an install-deps command if you just want to install the deps but not build/install foo. Additionally, if you want to use locally modified versions of the dependencies use 'cabal add-source path to dep' from the foo directory to add your locally modified package to foo's index so that subsequent cabal-dev operations can find it and install it. (minor clarity note: I don't believe there is a cabal add-source, but there is a cabal-dev add-source, which I think Jason meant above) cabal-dev add-source can cause problems, and it is not always clear what it does. Since ~cabal-install-0.10.2, it's also not (usually) necessary. A simpler workflow is to 'cabal-dev install' a list of packages, eg: $ cabal-dev install path to dep path to dep path to foo That should run the solver once, finding a global solution, and installing the required dependencies (and foo) into the local sandbox. You should only need this for packages that are not on hackage, or that you've modified and want to use local versions. --Rogan Basically, don't install the deps by hand. Let cabal-dev figure out the mutually compatible versions and install that *locally* to where you're building foo. As for the problem of recursively rebuilding the deps, I think 'cab' [1] solves this but I haven't tried it. [1] http://hackage.haskell.org/package/cab I also thought about adding process, bytestring and other global packages to the list of constraints in ~/.cabal/config. Would this be a good approach, or will it lead to bigger headaches in the future (for instance, in the form of programs that just cannot be installed at all)? Adding these constraints will come back to bite you. That's been my experience. Also, is there any way to detect potential dependency hells without having to install a package? (Some tool that will analyse the dependency information (statically) and determine more strict or incorrect upper and lower bounds for the dependencies of a package.) --dry-run? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Install a script with Cabal?
On Tue, Jun 5, 2012 at 4:28 AM, Ketil Malde ke...@malde.org wrote:
Rogan Creswick cresw...@gmail.com writes:
I have a small project that installs a couple of Haskell tools and a
script that uses these. Cabal will of course build and install the
Haskell programs, but how can I get Cabal to install the script as
well? There's a host of UserHooks available¹, but it'd probably be
better to have an example than to try to experiment with the right
configuration.
I don't have an example handy, but I think you'll want preInts,
instHook, or postInst. I'd probably go with postInst unless you need
data provided by instHook's type that isn't passed to preInst or
postInst.
I found an example¹ using copyHook. However, this seems to be the wrong
thing, at least I am unable to get cabal to ever call this hook (or
preCopy, etc).
I'm not sure if/when copy hooks are used during the typical cabal
configure/build/install process; I suspect they are not used. There
is, however, a `cabal copy` command, which I believe does. Not that
that helps you right now, but that may explain the behavior you saw.
LocalBuildInfo /probably/ has the details you need (eg: installDirTemplates).
This was harder than I thought.
Here's an example (I hacked an example on to the cabal-dev Setup.hs,
so there are extra imports you won't necessarily need -- full Setup.hs
is in the linked gist, the email only contains the relevant exceprts):
Gist: https://gist.github.com/2876277
main = defaultMainWithHooks $
simpleUserHooks { hookedPrograms = [cabalInstallProgram]
, postInst = postInstCp (postInst simpleUserHooks)
}
type PostInstHook = Args - InstallFlags - PackageDescription -
LocalBuildInfo - IO ()
postInstCp :: PostInstHook - Args - InstallFlags -
PackageDescription - LocalBuildInfo - IO ()
postInstCp oldHook args iflags pDesc lbi = do
let -- The filename to copy from:
inFile :: FilePath
inFile = srcFileName.sh
-- The filename to copy to:
outFile :: FilePath
outFile = destFileName.sh
prefix = fromFlag $ installDistPref iflags
-- Make a concrete binDir from the LocalBuildInfo PackageDescription:
instBinDir :: FilePath
instBinDir = bindir $ absoluteInstallDirs pDesc lbi
(fromFlag $ copyDest
defaultCopyFlags)
-- layer of indirection, in case we wanted to get a specific
-- src directory from the cabal file:
src :: FilePath
src = inFile
-- qualify the destination.
dest :: FilePath
dest = instBinDir / outFile
-- Do the copy, creating outFile in the bin dir:
copyFile src dest
-- now invoke the old hook:
oldHook args iflags pDesc lbi
--Rogan
I just printed out the contents of LocalBuildInfo, but that's 33 pages
(I counted) of output. Redirected to a file, it makes it easier to
search to find the relevant needles in this haystack.
Okay, looking at installDirTemplates, I see `bindir` can extract this
data member. It's of course an InstallDirTemplate, not a FilePath, but
I found 'fromPathTemplate', which has the right type. Except it only
dumps the template, with $prefix and all.
Hoogle doesn't seem to know about any of the Cabal stuff, Hayoo has a *very*
annoying behavior where it cleans out everything you did if you use the
back button, and the source links it advertises seem to point into
the wide blue 404. But using the latter, I managed to find a link to
'substPathTemplate', worked out that the PackageIdentifier it needs is a
member of PackageDescription, and tried to use that. Except it gives
the same result, and doesn't appear to substitute anything. I guess the
fact that it is undocumented is a hint that it's the wrong thing to use.
Reading some more, maybe 'absoluteInstallDirs' is what I'm looking for?
In addition to the usual heap of huge config structs, it needs a
CopyDest, though. Since I have no idea what to use, I just put
NoCopyDest there. Does that make sense? Okay, it works now, in the
sense that I ran it once on my laptop, and it copied the file to
~/.cabal/bin. Here is the code, comments welcome:
#!/usr/bin/env runhaskell
import Distribution.Simple (defaultMainWithHooks,
simpleUserHooks,UserHooks(..))
import Distribution.Simple.Setup (InstallFlags,CopyDest(..))
import Distribution.Simple.Utils (rawSystemExit)
import Distribution.PackageDescription (PackageDescription())
import Distribution.Simple.LocalBuildInfo (LocalBuildInfo(..),
InstallDirs(..), absoluteInstallDirs)
import Distribution.Verbosity (normal)
main :: IO ()
main = defaultMainWithHooks simpleUserHooks
{ instHook = \pd lbi uh ifs - myinst pd lbi uh ifs instHook
simpleUserHooks pd lbi uh ifs }
myinst :: PackageDescription - LocalBuildInfo - UserHooks - InstallFlags
- IO ()
myinst pd lbi _uh _fs = do
let bin = bindir $ absoluteInstallDirs pd lbi NoCopyDest
Re: [Haskell-cafe] Installing REPA
On Fri, Apr 6, 2012 at 7:02 AM, Dominic Steinitz idontgetoutm...@googlemail.com wrote: Hi, I'm trying to install REPA but getting the following. Do I just install base? The only safe way to upgrade base is to upgrade GHC -- I'm not sure which ghc has base-4.4 though (Based on Dmitry's comment, maybe 7.2?) --Rogan Thanks, Dominic. Tests-MacBook-Pro:PDE Test$ cabal install repa Resolving dependencies... cabal: cannot configure repa-2.2.0.1. It requires base ==4.4.* For the dependency on base ==4.4.* there are these packages: base-4.4.0.0 and base-4.4.1.0. However none of them are available. base-4.4.0.0 was excluded because of the top level dependency base -any base-4.4.1.0 was excluded because of the top level dependency base -any Tests-MacBook-Pro:PDE Test$ cabal --version cabal-install version 0.10.2 using version 1.10.1.0 of the Cabal library Tests-MacBook-Pro:PDE Test$ Tests-MacBook-Pro:PDE Test$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.0.3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Install a script with Cabal?
On Tue, Mar 20, 2012 at 1:45 AM, Ketil Malde ke...@malde.org wrote: I have a small project that installs a couple of Haskell tools and a script that uses these. Cabal will of course build and install the Haskell programs, but how can I get Cabal to install the script as well? There's a host of UserHooks available¹, but it'd probably be better to have an example than to try to experiment with the right configuration. I don't have an example handy, but I think you'll want preInts, instHook, or postInst. I'd probably go with postInst unless you need data provided by instHook's type that isn't passed to preInst or postInst. LocalBuildInfo /probably/ has the details you need (eg: installDirTemplates). Don't forget to invoke the default hook as part of your re-implementation -- if you override instHook, for example, you need to invoke the instHook that *would have* happened, or no installation will take place. --Rogan -k ¹ http://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distribution-Simple.html#t%3AUserHooks -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal-install problem with alex dependency in bytestring-lexing
On Mar 16, 2012 3:12 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 17 March 2012 09:02, Erik de Castro Lopo mle...@mega-nerd.com wrote: Ivan Lazar Miljenovic wrote: One trivial solution is to assume ~/.cabal/bin is on the PATH and to ignore system-wide packages, which I think is even *more* sub-optimal (why install a new version of alex when it's already available?). The tool should only install alex in ~/.cabal/bin if alex is not already available. So how does it know whether the *correct version* is available? Add --version parsers for every single possible build-tool to cabal-install? That is (probably) how it knows that the necessary version of alex is not available. There actually is a standard format for checking version numbers of the core haskell build tools: --numeric-version produces output that is easily parsed (and matches the default parser for cabal Program values). I'm not at a computer to check alex specifically right now, but I'm fairly certain it is one of the builtin Programs that cabal can check. (you can also write your own, and put them in setup.hs if you need a special build tool.) There is, of course, nothing that says ask the build tools are going to be available on hackage (or even in haskell). I'm not sure how to fix this, really. We could make the build tools section produce more detailed instructions for installing missing tools in the case that cabal can't install them. -Rogan -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building a Haskell project which depends on an old version of base
On Tue, Feb 14, 2012 at 12:14 PM, Steven J. Murdoch steven.murd...@cl.cam.ac.uk wrote: $ ghc-pkg list base /Users/ghc6/homebrew/Cellar/ghc/6.12.3/lib/ghc/package.conf.d base-3.0.3.2 base-4.2.0.2 I'm a bit fuzzy on the details when it comes to the core packages that are distributed with ghc, but my understanding is that the compiler is /very/ needy about which base it can use. As far as I know, the only way to change versions of Base is by changing the compiler to the version that uses the desired base. With that in mind, having two base libraries installed in the same package database seems like a recipe for disaster. Can you install the older ghc in a separate (fresh) location, and try again with either a sandbox, or after moving your local package db too? If you're confident with ghc-pkg, you can probably fix up the existing package databases, but it's not for the faint of heart. (although, depending on which base came with ghc 6.12.3, that may not be fruitful anyway.) --Rogan /Users/ghc6/.ghc/i386-darwin-6.12.3/package.conf.d However, when I try to cabal build the package, I get the following error: $ cabal -v build Creating dist/build (and its parents) Creating dist/build/autogen (and its parents) Preprocessing executables for TorDNSEL-0.1.1... Building TorDNSEL-0.1.1... Building executable tordnsel... Creating dist/build/tordnsel (and its parents) Creating dist/build/tordnsel/tordnsel-tmp (and its parents) /Users/ghc6/homebrew/bin/ghc --make -o dist/build/tordnsel/tordnsel -hide-all-packages -fbuilding-cabal-package -package-conf dist/package.conf.inplace -i -idist/build/tordnsel/tordnsel-tmp -isrc -idist/build/autogen -Idist/build/autogen -Idist/build/tordnsel/tordnsel-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -odir dist/build/tordnsel/tordnsel-tmp -hidir dist/build/tordnsel/tordnsel-tmp -stubdir dist/build/tordnsel/tordnsel-tmp -package-id HUnit-1.2.2.1-6237339c6ad5673d3cd8f82c4c7f6343 -package-id array-0.3.0.1-438000c197b51c147f229b54edbf632e -package-id base-3.0.3.2-260693a92016991a03206b5a55f6a411 -package-id binary-0.5.1.0-b72d4a82a5aecd9243ff0f50456b3d47 -package-id bytestring-0.9.1.7-64b858f95ff0dacc8acf396bb53cf4b9 -package-id containers-0.3.0.0-ee442470d8dcc9e45f31677c400c5379 -package-id directory-1.0.1.1-fa3418f21f42269537be694d5922dd6d -package-id mtl-1.1.0.2-336254fecf8a77054f76cb33671a5177 -package-id network-2.2.1.7-2eb3746f71ba30c3e4940b75df5ea8b8 -package-id stm-2.1.2.1-95639ea16e2e2cbf4accbabda98a1809 -package-id time-1.1.4-d9f7b7932dc3a4863006ed6b1d525856 -package-id unix-2.4.0.2-94ca14c8a73570f9d75aca642b4de0c6 -O -O2 -Wall -DVERSION=0.1.1-dev src/tordnsel.hs -lcrypto [ 4 of 39] Compiling TorDNSEL.Util ( dist/build/tordnsel/tordnsel-tmp/TorDNSEL/Util.hs, dist/build/tordnsel/tordnsel-tmp/TorDNSEL/Util.o ) src/TorDNSEL/Util.hsc:143:23: Module `GHC.Handle' does not export `fillReadBuffer' src/TorDNSEL/Util.hsc:143:39: Module `GHC.Handle' does not export `readCharFromBuffer' src/TorDNSEL/Util.hsc:145:26: Module `GHC.IOBase' does not export `Buffer(..)' The flags to ghc indicate that base-3.0.3.2 is being requested, and the documentation for base-3.0.3.2 indicates that GHC.Handle.fillReadBuffer exists[2]. Can anyone explain why I am getting this error message? Could it be because Util is a .hsc rather than .hs file? In tordnsel.cabal I've made two changes: set Build-Depends to include base=2.0 4 to tell ghc that I really want base-3 and removed -Werror from GHC-Options (to ignore the deprecation warnings). Otherwise it is as provided in this distribution[3]. Building manually has the same result (though oddly I get a deprecation warning from building the .hs files but not the .hsc file, which led to my suspicion about hsc being an issue. $ hsc2hs TorDNSEL/Util.hsc $ ghc -package-id base-3.0.3.2-260693a92016991a03206b5a55f6a411 --make TorDNSEL/Util.hs [1 of 3] Compiling TorDNSEL.DeepSeq ( TorDNSEL/DeepSeq.hs, TorDNSEL/DeepSeq.o ) TorDNSEL/DeepSeq.hs:1:0: Warning: Module `Prelude' is deprecated: You are using the old package `base' version 3.x. Future GHC versions will not support base version 3.x. You should update your code to use the new base version 4.x. TorDNSEL/Util.hs:1:11: Warning: -#include and INCLUDE pragmas are deprecated: They no longer have any effect [2 of 3] Compiling TorDNSEL.Compat.Exception ( TorDNSEL/Compat/Exception.hs, TorDNSEL/Compat/Exception.o ) TorDNSEL/Compat/Exception.hs:1:0: Warning: Module `Prelude' is deprecated: You are using the old package `base' version 3.x. Future GHC versions will not support base version 3.x. You should update your code to use the new base version 4.x. [3 of 3] Compiling TorDNSEL.Util ( TorDNSEL/Util.hs, TorDNSEL/Util.o ) TorDNSEL/Util.hsc:143:23: Module `GHC.Handle' does not export `fillReadBuffer'
Re: [Haskell-cafe] Google Summer of Code 2012 Announced
On Mon, Feb 6, 2012 at 12:54 PM, Johan Tibell johan.tib...@gmail.com wrote: 2. Advertise the projects on haskell-cafe, reddit, twitter, Google+ Does anyone know if the GSOC trac is in use this year? (or will be?). I started advocating for an extension to cabal to specify Setup.hs build dependencies last year, with this ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1602 I think the idea still has merit :) If anyone has comments, that would be a great place to put them (to clarify anything I've overlooked, point out shortcomings, suggest implementations, etc...). --Rogan 3. Profit. * The students tend to not know what makes a good GSoC project and often aim for something too difficult, like writing a new project from scratch instead of contributing to an old one. Contributing to widely used libraries or infrastructure usually results in * a larger benefit for the community, and * the students sticking around. My guess is that the student tend to stick around after the project is done if they contribute to infrastructure projects, as they'll see their stuff get used and will get feature requests/bug reports that will make them continue working on the project. -- Johan -- Forwarded message -- From: Carol Smith car...@google.com Date: Sat, Feb 4, 2012 at 8:43 AM Subject: Google Summer of Code 2012 Announced To: Google Summer of Code Announce google-summer-of-code-annou...@googlegroups.com Hi all, We're pleased to announce that Google Summer of Code will be happening for its eighth year this year. Please check out the blog post [1] about the program and read the FAQs [2] and Timeline [3] on Melange for more information. [1] - http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html [2] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs [3] - http://www.google-melange.com/gsoc/events/google/gsoc2012 Cheers, Carol -- You received this message because you are subscribed to the Google Groups Google Summer of Code Announce group. To post to this group, send email to google-summer-of-code-annou...@googlegroups.com. To unsubscribe from this group, send email to google-summer-of-code-announce+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-summer-of-code-announce?hl=en. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need advice: Haskell in Web Client
On Tue, Jan 17, 2012 at 3:07 AM, C K Kashyap ckkash...@gmail.com wrote: Perhaps HTML5's canvas element would meet your requirement. There a few JS chart implementation for HTML5 floating on the internet. The Google Charting API *might* be sufficient: http://code.google.com/apis/chart/ --Rogan Regards, Kashap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] buildDepends syntax and checks
On Wed, Jan 4, 2012 at 2:29 AM, Shakthi Kannan shakthim...@gmail.com wrote: #2 Is there a way to cross-check if the defined dependencies are in fact correct, or is it left to the package owner to write them? Generally speaking, this is undecidable (if I remember my complexity classes correctly...). The semantics of a function may change between versions without altering any aspect of the API. (eg: imagine succ x = x + 2 changing to succ x = x + 1 during a bug fix). Someone did write a tool that checks a library against the package version policy, though (based on changes to the API, exposed functions, etc.). I can't recall the name, but someone else on here might. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform for OSX ?
On Wed, Nov 9, 2011 at 3:37 AM, dokondr doko...@gmail.com wrote: In case I upgrade to the latest Haskell Platform, what will happen to packages already installed in my ~/.cabal folder? Some of these are quite old and most probably will be incompatible with GHC 7 Does upgrade process remove old and create anew ~/.cabal folder? The compiled packages are stored in a directory that is specific to the version of GHC that was used to build them, so you don't need to worry about that. Indeed, you can switch between GHCs (eg: by tweaking your $PATH, or using a tool like virthualenv) as much as you want and they won't interfere with most packages. (There may be issues with respect to /executables/ but that /should/ also be OK. Executables and cabal are a whole different problem, but most of the time things work out.) --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] capri cabal-dev virtualenv cab
On Tue, Nov 8, 2011 at 1:43 AM, Paul R paul.r...@gmail.com wrote: At the moment, my strategy to swap GHC is purely based on the PATH environment, and that works well if you don't forget to set this env before hacking a project. This is the best solution I'm currently aware of, but there are ways we could improve on this (involving new sandboxing tools; similar to NixOS). My strategy for cabal is a bit more convoluted, because I had *so many* troubles with multiple databases (AKA system db and user db), I decided that everything would go in the 'system' one, which is actually just in my user-local GHC install, for which my user obviously have required permissions. I strongly caution against doing this. My advice is: (explanations below) 1) /never/ install anything into your system db: 2) /never/ explicitly install packages that come with ghc (the packages that are in your system db) 3) don't rely on your user package db for development -- it's a convenient place to put things you want to use in ghci, and it's the simplest thing to use when installing Haskell applications (such as cabal, cabal-dev, cab, etc...) 4) use cabal-dev for all development. Explanations: (1): Installing to your system package db will prevent you from sandboxing builds in the context of the Haskell package system. You can restrict to individual ghcs, since each ghc has it's own system db, but you can't prevent your installed package versions from causing your builds to behave differently than my builds -- as a result, you may not realize that your package version bounds are broken, for example. You'll also not notice when new versions of dependencies cause your build to break, and you may experience failures when building other packages because you have a different set of installed dependencies than the developer expected. (1 2): These things, together, will prevent you from having version conflicts between the system and user dbs. Furthermore, cabal-dev doesn't hide the system db (the tools cabal-dev uses don't expose an api that enables that in the way that the user db can be hidden, and the libraries installed in the system db by ghc usually can't be upgraded/reinstalled without upgrading ghc anyway). (3) It's impractical to keep your user db clean enough to accomplish the same objectives of sandboxed builds -- you /can/ do it, but I don't think it's worth the effort when other tools exist to help (cabal-dev being my current hammer, capri should also do it, but I haven't personally had success with capri). (4) I'm sorry that cabal-dev adds computational overhead -- this generally isn't an issue when compared to the long-term issues that come up as a result of dependency resolution /without/ a sandbox, but I realize that there are situations where cabal-dev can cause build times to take significantly longer. Ideas / suggestions / patches / etc. are happily considered :) --Rogan Things seem to work a bit better that way, I guess because cabal has easier time handling dependencies. So far I avoided the project-local database strategy because my system does not have much computational power, and I'm bored of waiting for ubiquitous packages to compile in all my folders. Arguably, that would be the only safe and simple way to avoid clashes, but I'd appreciate some shared cache to avoid recompiling the same stuff multiple times. Is there some wrappers that can take care of that ? Cheers, -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] capri cabal-dev virtualenv cab
On Mon, Nov 7, 2011 at 11:40 PM, Rustom Mody rustompm...@gmail.com wrote: Does anyone give me a little comparison of these? capri cabal-dev: Capri and cabal-dev both sandbox Haskell builds by restricting the set of packages that cabal can see -- I haven't had much luck with capri personally, and it appears to take a bit more doing to get a project instantiated, but it does seem to restrict access to the system package db, which cabal-dev does not do. It doesn't look like capri is under active development (only one release, roughly 18 months ago). cabal-dev was created and is primarily maintained by Galois (I'm one of the maintainers), and it's used extensively for day-to-day development. cabal-dev works by wrapping invocations of cabal with the necessary configuration files and command line arguments to restrict cabal's access to package databases to the system package db and a per-project db. In practice, this solves the vast majority of version conflict issues, and it also allows you to confidently state that your software will build with the software currently on Hackage. However, it does /not/ provide any facilities for restricting or switching the versions of ghc, and it also doesn't sandbox any other external build tools (such as alex / happy). That's not necessarily out of scope, but we haven't needed it enough yet to implement. virtualenv: I'm not familiar with virtualenv, but from skimming the site, it looks like it does something very similar to cabal-dev, but focused on python. I'm not sure if it can be used with other languages / arbitrary tools or not. cab: Others know cab much better than I do, but I'll take a shot. I think cab primarily provides a set of higher-level commands for managing a ghc package database. Amongst other things, it will show the complete dependency tree for a package that is installed, and I think it wraps 'ghc-pkg unregister' more nicely, so you can unregister a package and the packages that depend on it with one command. It also wraps cabal-dev, I think, but I haven't used that bit, so I don't know if it covers all the cabal-dev functionality yet. --Rogan What would all my requirements be? Not sure... these seem important for me 1. Need to sandbox not just haskell-projects but ghc (different compilations/versions) itself 2. Stability of the (sandboxing) tool 3. Correcting the deficiencies of cabal (eg inability to uninstall, quarrels between cabal and apt etc) OS: Debian/testing System haskell: 7.0.4 My question on beginners for a little more context: http://www.haskell.org/pipermail/beginners/2011-November/008943.html capri: http://www.haskell.org/haskellwiki/Capri virtualenv: https://github.com/Paczesiowa/virthualenv cabal-dev: http://corp.galois.com/blog/2010/12/20/cabal-dev-sandboxed-development-builds-for-haskell.html cab: http://www.mew.org/~kazu/proj/cab/en/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] capri cabal-dev virtualenv cab
On Tue, Nov 8, 2011 at 10:57 AM, Brent Yorgey byor...@seas.upenn.edu wrote: I'm guessing the OP was actually referring to 'virthualenv', which was recently released and works with Haskell (but is similar to virtualenv for python). It seems that virthualenv lets you set up independent environments including sandboxed builds and custom versions of GHC, etc., and switch between them. Ah! Thanks, I wasn't aware of virthualenv. So far, it looks cool. I have a bit of a knee-jerk reaction to the statefull approach it takes (heavily tweaking your active shell environment to do the sandboxing), but it does do things that cabal-dev doesn't. Playing with it more now. --Rogan -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Platform for OSX ?
On Tue, Nov 8, 2011 at 4:30 PM, Giovanni Tirloni gtirl...@sysdroid.com wrote: 3) How to install it into a separate location so it would not ruin my current platform? You can install it under a different username. You can also use a sandboxed build tool like cabal-dev or virthualenv -- both of which are on hackage. (While the HP provides a great way to install Haskell, and it defines a set of mature packages, it is not necessary for development -- cabal install doesn't pay any special attention to HP packages, for example.). Having the HP installed is convenient, particularly if you run ghci a lot, but all you need is ghc, cabal-install, and a connection to hackage. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] control-c only caught once -- bug?
On Fri, Oct 28, 2011 at 12:47 PM, Brian Johnson brianjohnsonhaskellc...@gmail.com wrote: Hi, The second time I press control-c, it isn't caught -- the program exits instead. Why? Interesting -- this works as you want with runghc, but it works as you describe when compiled with ghc --make. (under ghc 7.0.3 here as well.) --Rogan (The context is, I'm writing an interactive program where calculations may take a long time. Control-c during a calculation should return the user to a prompt. As things stand, this can only be done once -- the second calculation so interrupted causes the whole program to exit.) $ ./ctrlctest ^Cuser interrupt ^C -- program exits! $ cat ctrlctest.hs module Main where import Control.Concurrent (threadDelay) import qualified Control.Exception as C main :: IO () main = do (threadDelay 100 return ()) `C.catch` (\e - print (e::C.AsyncException)) main $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.0.3 $ uname -mrsv Darwin 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64 $ file ctrlctest ctrlctest: Mach-O executable i386 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The best way to call Java from Haskell?
On Tue, Oct 11, 2011 at 1:56 AM, dokondr doko...@gmail.com wrote: On Tue, Oct 11, 2011 at 12:42 PM, Yitzchak Gale g...@sefer.org wrote: Just out of curiosity, why do you not consider GF at all similar? To an outsider like me, there does appear to be quite a bit of similarity. As I understand GF is well suited for parsing well defined formal languages. Not sure that GF can be used as NLP parser for blog messages that I need. That is correct - more or less. GF is a very expressive language, and it can handle a great deal of natural language, but it /does/ require that the input be grammatically correct, and it is difficult to work in unexpected vocabulary. GF is fantastic for making flexible Controlled Natural Languages, and it excels at producing human-readable text, but it is an entirely different beast from a statistical natural language parser, such as Stanford's. re: the original question -- The best method I've found for interfacing Haskell / Java for NLP is to share data with some common format, such as UIMAs CAS serialization. We really ought to start up a group of people interested in that over on the Haskell NLP list and see what we have if we pool all our efforts. --Rogan Please correct me if I am wrong. As a general note, Java has tons of useful libraries that will take infinite time to re-implement in Haskell. To my mind it makes a lot of sense to have a reliable mechanism to call Java from Haskell. BTW, yet another way to do this: wrap Java library in RESTFUL web service ) -- All the best, Dmitri O. Kondratiev This is what keeps me going: discovery doko...@gmail.com http://sites.google.com/site/dokondr/welcome ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell i18n best practices
On Thu, Sep 29, 2011 at 3:54 PM, Paulo Pocinho poci...@gmail.com wrote: Hello list. I've been trying to figure a nice method to provide localisation. An The grammatical framework excels at translation and localization -- it probably has the highest learning curve of the options; but it will generate the best / most accurate text depending on the target language: * http://www.grammaticalframework.org At first brush, it may seem like extreme overkill; but it is able to handle many, many infuriating corner cases (eg: properly forming discontinuous constituents, updating case / tense and number to agree with potentially variable quantities and genders, addressing the absence of yes and no in some languages, etc...) The language processing bits are expressed in a PMCFG grammar, which uses a syntax similar to haskell. The PMCFG compiles to a PGF file that can be loaded and used by a haskell module that implements the runtime, so it doesn't change your run-time requirements (if you already rely on haskell, there are also runtime implementations in javascript, java, c and python). --Rogan application is deployed using a conventional installer. The end-user is not required to have the Haskell runtimes, compiler or platform. The application should bundle ready to use translation data. What I am after is simple; an intuitive way that an interested translator, with little knowledge of Haskell, can look at and create valid translation data. This is what I've been looking at lately. The first thing I noticed was the GNU gettext implementation for Haskell. The wiki page [1] has a nice explanation by Aufheben. The hgettext package is found here [2]. I don't know if this is a bad habit, but I had already separated the dialogue text in the code with variables holding the respective strings. At this time, I thought there could be some other way than gettext. Then I figured how to import localisation data, that the program loads, from external files. The data type is basically a tuple with variable-names associated with strings. This is bit like the file-embed package [3]. Still uncomfortable with i18n, I learned about the article I18N in Haskell in yesod blog [4]. I'd like to hear more about it. What is considered the best practice for localisation? -- [1] http://www.haskell.org/haskellwiki/Internationalization_of_Haskell_programs [2] http://hackage.haskell.org/packages/archive/hgettext/ [3] http://hackage.haskell.org/package/file-embed [4] http://www.yesodweb.com/blog/2011/01/i18n-in-haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell i18n best practices
On Fri, Sep 30, 2011 at 2:09 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Fri, Sep 30, 2011 at 5:44 PM, Rogan Creswick cresw...@gmail.com wrote: The grammatical framework excels at translation and localization -- it probably has the highest learning curve of the options; but it will generate the best / most accurate text depending on the target language: * http://www.grammaticalframework.org At first brush, it may seem like extreme overkill; but it is able to handle many, many infuriating corner cases (eg: properly forming discontinuous constituents, updating case / tense and number to agree with potentially variable quantities and genders, addressing the absence of yes and no in some languages, etc...) The language processing bits are expressed in a PMCFG grammar, which uses a syntax similar to haskell. The PMCFG compiles to a PGF file that can be loaded and used by a haskell module that implements the runtime, so it doesn't change your run-time requirements (if you already rely on haskell, there are also runtime implementations in javascript, java, c and python). I've seen GF before, but I can't actually see how one would use it for localization. Are there any simple examples? Here's a *very* simple example I just threw together, based on the Foods grammar (so it's quite contrived), but hopefully it's sufficient for the moment: https://github.com/creswick/gfI8N Updating it to use the Phrasebook example would make it much more interesting... I think there are numbers in there, and iirc, it uses the actual resource grammars, which is what you really want for a real system. Usage details in the README.md, and I've commented the important function in the haskell source. The rest of the magic is in the (also ugly) Setup.hs. You will also need to manually install gf, I believe, even if you use cabal-dev, due to some annoyingly complex (but solveable) build-order and PATH complications. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] emacs literate haskell mode
On Tue, Sep 27, 2011 at 11:24 AM, Mathijs Kwik math...@bluescreen303.nl wrote: Hi all, I'm using haskell-mode for emacs and I'm using it to open a literate haskell file which uses latex. This works fine, haskell code has syntax highlighting, and special symbols like lambda get used. However, the latex itself is dull and gree, no highlighting/coloring there. Does anyone know if it's possible to turn on latex highlighting in literate haskell mode? I tried switching to latex-mode, which does the trick (but it chokes on the haskell code inbetween), so I'm pretty sure emacs has everything it needs, but haskell-mode needs to enable this somehow. I'm not certain this /is/ easily in Emacs capabilities. Emacs isn't really set up to support more than one major mode at a time -- there is, however, an extension that can do this. The challenge is defining the start and end of the areas of each 'mode' in the buffer; I've never had very much success, but depending on the delimiters used in the literal haskell syntax you're working with, you may be able to set it up: http://www.emacswiki.org/emacs/MultipleModes --Rogan Any help would be great. Greetings, Mathijs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error in Installing Data.deriveTH
On Thu, Sep 15, 2011 at 12:37 PM, mukesh tiwari mukeshtiwari.ii...@gmail.com wrote: Hello all I am trying to install Data.deriveTH . When i tried cabal install derive , i got this error. Many errors of this type can be avoided by using cabal-dev [1] instead of cabal-install for development -- cabal-dev keeps package databases for each project separate, although everything still also uses the global package db (so you shouldn't install anything there). cabal-install is still necessary (and ideal) for installing applications for use in normal activities, and for installing libraries into your user-package database for use in general ghci sessions. If nothing else, cabal-dev will ignore your user package db, which might be enough to get you going on whatever you're really doing instead of fixing your user package db right this moment :) --Rogan [1] cabal-dev: http://github.com/creswick/cabal-dev and on hackage. ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/assignment_haskell/work$ cabal install derive Resolving dependencies... command line: cannot satisfy -package Cabal-1.10.2.0: Cabal-1.10.2.0-072fce39d68f011c6a364057a3d15270 is unusable due to missing or recursive dependencies: containers-0.3.0.0-ee442470d8dcc9e45f31677c400c5379 (use -v for more information) cabal: Error: some packages failed to install: derive-2.5.4 depends on haskell-src-exts-1.11.1 which failed to install. haskell-src-exts-1.11.1 failed during the configure step. The exception was: ExitFailure 1 ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/assignment_haskell/work$ cabal install haskell-src-exts Resolving dependencies... command line: cannot satisfy -package Cabal-1.10.2.0: Cabal-1.10.2.0-072fce39d68f011c6a364057a3d15270 is unusable due to missing or recursive dependencies: containers-0.3.0.0-ee442470d8dcc9e45f31677c400c5379 (use -v for more information) cabal: Error: some packages failed to install: haskell-src-exts-1.11.1 failed during the configure step. The exception was: ExitFailure 1 ntro@ntro-HP-dx2480-MT-NA121PA:~/Mukesh/assignment_haskell/work$ cabal install containers Resolving dependencies... No packages to be installed. All the requested packages are already installed. If you want to reinstall anyway then use the --reinstall flag. I tried to resolve this issue on #haskell and i got suggestion that it was due to conflict in global and local namespace [ see here for more detail http://hpaste.org/51376 ]. One idea is i should wipe ~/.ghc and install all the libraries individually. Could some one please suggest if there is another idea to resolve this issue. Currently i have ghc-6.12.3 and installing ghc-7.0 will resolve the issue ? Thank you Mukesh Tiwari . ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: numerals
2011/9/16 Roel van Dijk vandijk.r...@gmail.com: Hello everyone, I would like to announce the release of the numerals and numerals-base packages. * Numerals The numerals package contains functions to convert numbers to number words in a number of languages. For now the package only supports cardinal numbers. Cool! Are you familiar with the Grammatical Framework [1]? It is a Haskell library and language for natural language parsing and translation -- If you need to do a lot of translation or string localization, you should take a look at it as much of the complexity has been addressed there. That said, the numeral libraries for GF are somewhat limited (and/or somewhat undocumented) so there is probably a lot your experience and library could bring to that project. [1] http://www.grammaticalframework.org --Rogan Example: import qualified Text.Numeral.Language.EN as EN EN.uk_cardinal 123 :: Maybe String Just one hundred and twenty-three You can also inspect the underlying structure of a number word: import Text.Numerals EN.shortScaleStruct 123 :: Exp Add (Mul (Lit 1) (Lit 100)) (Add (Mul (Lit 2) (Lit 10)) (Lit 3)) Compare this structure with the number word: 1 (one) * 100 (hundred) + (and) 2 (twen) * 10 (ty) + 3 (three) The package also comes with a test suite: cabal configure --enable-tests cabal build ./dist/build/test-numerals/test-numerals --hide-successes I recommend the --hide-successes option of test-framework (=0.4) because there are many tests (3383). * Numerals-base The numerals-base package contains all the machinery upon which numerals is build. Using this package you can write conversion functions for your own language(s). It is documented, although the documentation can be improved. For now the numerals package is probably the best documentation. * Resources: Hackage: http://hackage.haskell.org/package/numerals http://hackage.haskell.org/package/numerals-base Github: http://github.com/roelvandijk/numerals http://github.com/roelvandijk/numerals-base * Help wanted Currently I support 24 languages. But I only have some experience with 4 of them. The rest is scraped together with information I found online. For most languages I can find online how to form the first 100 cardinal numbers. But after that information is sparse. You can help by checking and expanding the test suite. This is very simple because the test suite consists only of numbers combined with the expected cardinal number word. Regards, Roel van Dijk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] conditionally exposing modules in cabal
I would like to conditionally expose a number of internal modules in a
library depending on a cabal flag - the idea is that new features
could be implemented externally to the library without contaminating
the source with undesirable changes. However, I've been unable to
find a way to structure a cabal file that does not require repeating
the list of modules. For example, this works:
exposed-modules:
Public.Stable.Module
if flag(exposeInternals)
exposed-modules:
long list of internal modules
else
other-modules:
long list of internal modules, identical to above
But I don't want to maintain two identical lists of modules in the cabal file.
I've tried putting the section headers in the if's, but this doesn't
appear to work (cabal doesn't complain, but the modules to be exposed
are not available as expected):
exposed-modules:
Public.Stable.Module
if flag(exposeInternals) {
exposed-modules:
} else {
other-modules:
}
long list of internal modules
Does anyone have suggestions?
Thanks!
Rogan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conditionally exposing modules in cabal
On Thu, Aug 18, 2011 at 4:41 AM, Antoine Latter aslat...@gmail.com wrote: One problem to consider - a downstream user of the new features won't know that they need to pass special flags to your module, and may not even know that they are using your module if the dependency is a few steps removed. The situation is more that I have a number of independent changes that I'd like to experiment with locally, without ever releasing them individually -- if/when they're released, they would build without the need to set the flag. The net effect is very similar to maintaining multiple branches of the primary project, but with more separation between the stable project and the experimental code. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] writing a good Setup.hs is *hard* (was: broken on install encoding 0.6.6)
On Wed, Aug 17, 2011 at 6:29 AM, Gang yugang...@gmail.com wrote: sorry to bother Not in the least! I was trying to figure out what problem you were encountering, and I learned a lot. I never did recreate your problem, but in the process I ran into a whole host of other annoyances and strange situations relating to slightly broken cabal files and cabal build intricacies that confound our existing tools. I don't mean to pick on encoding or HaXml - I've seen the same kinds of issues in many, many Haskell packages (including most of the packages I've written myself) these are just the ones I ran into today. (and I am quite serious when I say that writing a good Setup.hs is very, very, difficult). My objective is just to motivate a minor change to cabal that would help to make this easier. On to the build problems: encoding-0.6.6 uses it's own source during the build process! It actually has to be partially compiled before the build tool can build encoding (!). I'm *amazed* that this actually works at all (impressed, too), and indeed, it doesn't work with cabal-dev, which is unfortunate: cabal-dev would have identified one of the dependency issues in HaXml 1.19 (pretty is an undocumented dependency, although I am unsure if that was true at the time 1.19 and encoding-0.6.6 were released. I haven't tracked the pretty dependency down to the exact source - it could be a transitive dep introduced by a recent version of something HaXml 1.19 needs. Per my subject line - this is amazingly difficult - keep in mind that we're not talking about building *packages*, this is just to build the *build tool*, and none of this is documented. How long before it is effectively impossible to recreate the circumstances that result in a successful encoding-0.6.6 build?). cabal-dev can't build encoding-0.6.6 because the encoding source that is referenced from encoding's Setup.hs depends on (at least) HaXml = 1.19 1.22.5; this is OK with cabal, since cabal-install installs a necessary HaXml into your user package db prior to building encoding's Setup.hs (modulo the missing upper version bound). Therefore HaXml just happens to be visible when cabal builds Setup.hs -- a build step that cabal-dev isn't capable of controlling (and probably never will be -- we could intercept system calls, but that's difficult when only supporting one OS, much less three). You can, of course, manually install HaXml to your local package db and then cabal-dev install encodings, but that's somewhat of a hack (and you'll find that the current HaXml won't work for the current encodings release, as Gang Yu did). Adding a section to the cabal file that specifies build dependencies for Setup.hs would make some very important parts of this process obvious - and it would *greatly* assist in debugging failing builds, not to mention allowing us to make use of the extensive libraries on hackage to write more expressive build systems. (We could actually use openshake in Setup.hs, once it's released, for example!) I've floated the idea past a number of Haskell programmers with positive responses, and there is a GSOC ticket that provides some more details (the project was not selected - no students proposed to work on it): http://hackage.haskell.org/trac/summer-of-code/ticket/1602 --Rogan Regards Gang On 08/17/2011 04:59 PM, Gang Yu wrote: hi, cafe: I go through to the encoding package installation problem again. cabal install encoding Resolving dependencies... /tmp/encoding-0.6.68093/encoding-0.6.6/dist/setup/setup: 4: Syntax error: ; unexpected when I have a check on the this issue, I get: file ~/.cabal/packages/hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup /home/gang/.cabal/packages/hackage.haskell.org/encoding/0.6.6/encoding-0.6.6/dist/setup/setup: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, not stripped My machine is: gang@gang-laptop:~$ uname -a Linux gang-laptop 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux is this related? How can I manually install the package from scratch? Any helps or directs will be appreciated Thanks Gang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: cabal-dev 0.8
We're happy to announce the release of cabal-dev 0.8! This version is available on hackage now, and contains many bug fixes and improvements, as outlined in the full release notes below. --Rogan cabal-dev release 0.8 == The 0.8 release of `cabal-dev` fixes many of the bugs that have been reported by `cabal-dev` users. It also provides more flexible, easier configuration and improves tool support for working within the `cabal-dev` sandbox (ghc-pkg suport and better ghci support). Upgrading is recommended for all users. Please report any bugs or submit enhancement requests to https://github.com/creswick/cabal-dev/issues. Much of the work on this release (and previous releases) of `cabal-dev` was funded by Galois, Inc. http://www.galois.com/ About cabal-dev == `cabal-dev` is a Haskell build tool that augments Cabal and cabal-install to make it convenient to work with a sandboxed set of packages. It limits the effect of your build on unrelated parts of your system. Among other things, `cabal-dev` satisfies the following needs: * Avoid conflicts between libraries by working only with the set of packages that are needed for the current project. * Enable depending on a patched dependency without that patched dependency accidentally being used by another project's build. * Enable the simultaneous development of multiple interdependent packages without the development versions leaking to other project build environments. Significant effort has been made to ensure that `cabal-dev` works across platforms (Mac, Windows, and Linux) and with the versions of GHC that are most commonly in use (6.10-7.0). What's new == Details can be found on github at https://github.com/creswick/cabal-dev. Bugs fixed: * `cabal-dev` no longer passes `--verbose` to cabal-install commands that do not accept it. https://github.com/creswick/cabal-dev/issues/18 * `cabal-dev` now recognizes and passes through short flags to cabal-install. In particular, this bug frequently came up when attempting to pass a flag (`-f`) to `cabal-dev install`. https://github.com/creswick/cabal-dev/issues/6 * `cabal-dev` now supports all cabal-install commands, including `test`. https://github.com/creswick/cabal-dev/issues/10 * We also made changes that should address inconsistencies with the remote repository (Hackage) cache location, but those issues remain open until we have confirmation from end users (you!) that these changes actually fix those issues. https://github.com/creswick/cabal-dev/issues/15 and https://github.com/creswick/cabal-dev/issues/14 Enhancements and new features: * `cabal-dev ghci` now invokes ghci with the exact same set of flags that would be used in a cabal-install build (using a trick copied from Leksah). This means that it will now have the appropriate package visibility, language settings, and source directories set when it is invoked. Note that in order for `cabal-dev ghci` to work, all dependencies must already be installed in the sandbox, and the package must already be configured. * `cabal-dev buildopts` will print the set of build options that would be passed to GHC when invoking `cabal build`. You can then use these flags for other tools that invoke GHC (e.g. the doctest package http://hackage.haskell.org/package/doctest). * `cabal-dev ghc-pkg` will invoke `ghc-pkg` with the appropriate flags to examine or alter the package database inside the `cabal-dev` sandbox. * `cabal-dev` now has more flexible support for cabal-install configuration: * By default `cabal-dev` will now use any settings from your cabal-install configuration file, except those that must be overridden in order to sandbox the build. This makes it more convenient to e.g. use an alternate remote repository with `cabal-dev`. * `cabal-dev` now supports merging of additional cabal-install configuration settings, to make it easy to work with multiple cabal-install configurations (`--extra-config-file=...`). * `cabal-dev` now has a flag to pass explicit options to cabal-install in case there are any conflicts between `cabal-dev` flags (`--cabal-install-arg`). * `cabal-dev` now has a flag to specify a particular cabal-install executable to use (`--with-cabal-install=...`). smime.p7s Description: S/MIME Cryptographic Signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] NLP libraries and tools?
On Wed, Jul 6, 2011 at 3:03 PM, Aleksandar Dimitrov aleks.dimit...@googlemail.com wrote: So you'd use, say, UIMA+OpenNLP to do sentence boundaries, tokens, tags, named-entities whatnot, then spit out some annotated format, read it in with Haskell, and do the logic/magic there. Have you used that particular combination yet? I'd like to know the details of how you hooked everything together if that's something you can share. (We're working on a similar Frankenstein at the moment.) --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] NLP libraries and tools?
On Fri, Jul 1, 2011 at 3:31 AM, Dmitri O.Kondratiev doko...@gmail.com wrote: Hi, Please advise on NLP libraries similar to Natural Language Toolkit There is a (slowly?) growing NLP community for haskell over at: http://projects.haskell.org/nlp/ The nlp mailing list may be a better place to ask for details. To the best of my knowledge, most of the NLTK / OpenNLP capabilities have yet to be implemented/ported to Haskell, but there are some packages to take a look at on Hackage. First of all I need: - tools to construct 'bag of words' (http://en.wikipedia.org/wiki/Bag_of_words_model), which is a list of words in the article. This is trivially implemented if you have a natural language tokenizer you're happy with. Toktok might be worth looking at: http://hackage.haskell.org/package/toktok but I *think* it takes a pretty simple view of tokens (assume it is the tokenizer I've been using within the GF). Eric Kow (?) has a tokenizer implementation, which I can't seem to find at the moment - if I recall correctly, it is also very simple, but it would be a great place to implement a more complex tokenizer :) - tools to prune common words, such as prepositions and conjunctions, as well as extremely rare words, such as the ones with typos. I'm not sure what you mean by 'prune'. Are you looking for a stopword list to remove irrelevant / confusing words from something like a search query? (that's not hard to do with a stemmer and a set) - stemming tools There is an implementation of the porter stemmer on Hackage: - http://hackage.haskell.org/package/porter - Naive Bayes classifier I'm not aware of a general-purpose bayesian classifier lib. for haskell, but it *would* be great to have :) There are probably some general-purpose statistical packages that I'm unaware of that offer a larger set of capabilities... - SVM classifier There are a few of these. Take a look at the AI category on hackage: - http://hackage.haskell.org/packages/archive/pkg-list.html#cat:ai --Rogan - k-means clustering ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] NLP libraries and tools?
On Fri, Jul 1, 2011 at 12:38 PM, Dmitri O.Kondratiev doko...@gmail.com wrote: On Fri, Jul 1, 2011 at 9:34 PM, Rogan Creswick cresw...@gmail.com wrote: On Fri, Jul 1, 2011 at 3:31 AM, Dmitri O.Kondratiev doko...@gmail.com wrote: First of all I need: Unfortunately 'cabal install' fails with toktok: tools/ExtractLexicon.hs:5:35: Module `PGF' does not export `getLexicon' cabal: Error: some packages failed to install: toktok-0.5 failed during the building phase. The exception was: ExitFailure 1 Oh, right - I ran into this problem too, and forgot about it (I should have reported a bug...) I think this fails because of (relatively) recent changes in GF, which isn't constrained to specific versions in the toktok cabal file... --Rogan Any ideas how to solve this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsing cabal files to calculate average number of dependencies
On Fri, Jul 1, 2011 at 1:43 PM, Gwern Branwen gwe...@gmail.com wrote:
Athas on #haskell wondered how many dependencies the average Haskell
package had. I commented that it seemed like some fairly simple
scripting to find out, and as these things tend to go, I wound up
doing a complete solution myself.
First, we get most/all of Hackage locally to examine, as tarballs:
for package in `cabal list | grep '\*' | tr -d '\*'`; do cabal
fetch $package; done
I think the index tarball has all the info you need, and would be
faster to retrieve / process, if you or anyone else needs to get the
.cabal files again:
http://hackage.haskell.org/packages/archive/00-index.tar.gz (2.2mb)
The set of the latest package sdists is also available:
http://hackage.haskell.org/cgi-bin/hackage-scripts/archive.tar (~150mb)
--Rogan
Then we cd .cabal/packages/hackage.haskell.org
Now we can run a command which extracts the .cabal file from each
tarball to standard output:
find . -name *.tar.gz -exec tar --wildcards *.cabal -Oxf {} \;
We could grep for 'build-depends' or something, but that gives
unreliable dirty results. (80k items, resulting in a hard to believe
87k total deps and an average of 27 deps.) So instead, we use the
Cabal library and write a program to parse Cabal files spit out the
dependencies, and we feed each .cabal into that:
find . -name *.tar.gz -exec sh -c 'tar --wildcards *.cabal
-Oxf {} | runhaskell ~/deps.hs' \;
And what is deps.hs? Turns out to be surprisingly easy to parse a
String, extract the Library and Executable AST, and grab the
[Dependency] field, and then print it out (code is not particularly
clean):
import Distribution.Package
import Distribution.PackageDescription
import Distribution.PackageDescription.Parse
main :: IO ()
main = do cbl - getContents
let desc = parsePackageDescription cbl
case desc of
ParseFailed _ - return ()
ParseOk _ d - putStr $ unlines $ map show $ map
(\(Dependency x _) - x) $ extractDeps d
extractDeps :: GenericPackageDescription - [Dependency]
extractDeps d = ldeps ++ edeps
where ldeps = case (condLibrary d) of
Nothing - []
Just c - condTreeConstraints c
edeps = concat $ map (condTreeConstraints . snd) $ condExecutables d
So what are the results? (The output of one run is attached.) I get
18,134 dependencies, having run on 3,137 files, or 5.8 dependencies
per package.
--
gwern
http://www.gwern.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] NLP libraries and tools?
On Fri, Jul 1, 2011 at 2:52 PM, Dmitri O.Kondratiev doko...@gmail.com wrote: Any other then 'toktok' Haskell word tokenizer that compiles and works? I need something like: http://nltk.googlecode.com/svn/trunk/doc/api/nltk.tokenize.regexp.WordPunctTokenizer-class.html I don't think this exists out of the box, but since it appears to be a basic regex tokenizer, you could use Data.List.Split to create one. (or one of the regex libraries may be able to do this more simply). If you go the Data.List.Split route, I suspect you'll want to create a Splitter based on the whenElt Splitter: http://hackage.haskell.org/packages/archive/split/0.1.1/doc/html/Data-List-Split.html#v:whenElt which takes a function from an element to a bool. (which you can implement however you wish, possibly with a regular expression, although it will have to be pure.) If you want something like a maxent tokenizer, then you're currently out of luck :( (as far as I know). --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News: Issue 187
On Thu, Jun 23, 2011 at 11:16 AM, Simon Michael si...@joyful.com wrote: On 6/23/11 10:49 AM, Iustin Pop wrote: FYI, a regular link (though longer) seems more appropriate to me. Don't know if other people feel the same though. I prefer the short links, since it is much easier to keep track of what's going on when reading on a small screen (much of my email reading these days is done on my phone.) If we switch to long links, could they be forward referenced in the footer, so as to not disrupt the flow of the text, as the HWN used to be? (if I remember correctly.) --Rogan +1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News: Issue 187
On Thu, Jun 23, 2011 at 2:26 PM, Albert Y. C. Lai tre...@vex.net wrote: I hate the borrowed academic practice of saying [0] and giving the URL two hundred lines later. It worked great on paper in hands because I could stick my finger to the paper to remember where to return. It also works great on real HTML documents because browsers have a back button for the same. It completely fails in plain text email because I can't stick a finger and I can't press the back button. Which one is the bigger disruption: This depends entirely on why you are reading the content -- something that there is no consensus on :) in-situ long URL that makes me skip oh two lines to continue with the main text? This is substantially more disruptive than two lines when reading on a cell phone. Lines that are not intended to wrap in the textual layout end up wrapping with longer URLs, making it more difficult to figure out where the next line of actual text continues. Longer URLs also create larger areas that you can't touch to scroll a message. Short, obfsucated, urls may direct you places you don't want to go, but I fail to see how that concern applies to HWN: since each url is accompanied by a description of its content, that seems to obviate the need to see the actual url. In most cases, the text also indicates the domain that you will visit, so you can avoid supporting stackoverflow with page impressions if you wish (for example). Eventually this should just be a client-side rendering preference, but we aren't quite there yet. In any case, I think that's a pretty complete description of my perspective/motivation (not that I'm strongly motivated), so I'm bowing out to watch :) --Rogan or the URL postponed by two hundred lines so I have to first remember it is [1] not [0] this time, then scroll down several pages to hunt for the URL, and then... I forget where to return to? If people want short URLs, I don't mind that either, but I'm picky on how they are shortened. The shortener should offer the option of showing me the original URL and waiting for me to go ahead or abort. As far as I know this means tinyurl.com only. Thank you for bearing with my rant. [0] No URL for this. [1] No URL for this either. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yi + cabal-dev
On Tue, Jun 21, 2011 at 6:55 PM, Alex Rozenshteyn rpglove...@gmail.com wrote: More precisely, I'm trying to run yi in its own sandbox, created by cabal-dev. yi uses dyre to recompile its config file. Unsurprisingly, this fails, since ghc doesn't know anything about the yi install unless pointed to a separate package database. I'm not familiar with dyre, is there any way to tell it to use a specific package database? That *sounds* like it's the problem (since that's the bulk of what cabal-dev does... it establishes a fresh package db and hides the user db). --Rogan Has anyone gotten a similar setup to work, or does anyone have any suggestions? -- Alex R ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] yi + cabal-dev
On Tue, Jun 21, 2011 at 11:59 PM, Alex Rozenshteyn rpglove...@gmail.com wrote: From looking at Yi's code, there seems to be a hard-coded list of arguments to pass to ghc. A hack would be to recompile Yi with the arguments to use a different package database... You may be able to create a 'ghc' shell script that invokes (the real) ghc with the correct --package-conf for Yi, then make a Yi script that sets up a custom path so that it finds your ghc script first. Lots of ifs, but at least you wouldn't have to maintain a Yi fork :) --Rogan On Wed, Jun 22, 2011 at 2:32 AM, Rogan Creswick cresw...@gmail.com wrote: On Tue, Jun 21, 2011 at 6:55 PM, Alex Rozenshteyn rpglove...@gmail.com wrote: More precisely, I'm trying to run yi in its own sandbox, created by cabal-dev. yi uses dyre to recompile its config file. Unsurprisingly, this fails, since ghc doesn't know anything about the yi install unless pointed to a separate package database. I'm not familiar with dyre, is there any way to tell it to use a specific package database? That *sounds* like it's the problem (since that's the bulk of what cabal-dev does... it establishes a fresh package db and hides the user db). --Rogan Has anyone gotten a similar setup to work, or does anyone have any suggestions? -- Alex R ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alex R ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with linker
On Fri, Jun 3, 2011 at 4:17 PM, Alejandro Serrano Mena trup...@gmail.com wrote: I've been looking for some information and it seems to be related with the fact that Hoogle first builds a library and then build an executable using the library, but all files get recompiled in that second pass. Is there any way to workaround this problem? Upgrading Cabal / cabal-install is a good place to start, if you're not already using the 0.10's. I also suggest using cabal-dev, since issues like this can be caused by combinations of dependencies that conflict. There's a good chance that you just have a weird mix of compiled libraries that don't all work together, and cabal isn't able/willing to rebuild everything necessary to make all the things in your user package db work together. I very recently installed Hoogle locally, on a fresh system, so I'm fairly confident it's still possible without too many headaches :). --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Imports in complex Setup.hs -- should we encourage/require PackageImports?
On Mon, May 23, 2011 at 3:08 PM, John Millikin jmilli...@gmail.com wrote: Any ideas/comments? Has anyone by chance found a good solution to this? I suggested a SoC project to implement a dependencies section for Setup.hs: http://hackage.haskell.org/trac/summer-of-code/ticket/1602 I wasn't aware of PackageImports -- I personally think that it's better to move the dependencies into a single place to reduce conflicts and to make it easier to identify the dependencies, but I'm open to arguments to the contrary :) In any case, this has frustrated and bitten me numerous times. I frequently want to share code between setup.hs files and I know of no clean way to do so. (apologies if this is delivered twice.. I got a mailer daemon failure the first time, so I'm manually entering the address now...) --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using cmake with haskell
On Sun, May 15, 2011 at 8:21 AM, Malcolm Wallace malcolm.wall...@me.com wrote: On 5/14/11 6:12 PM, Nathan Howell wrote: Waf supports parallel builds and works with GHC without too much trouble. I'm surprised no-one has yet mentioned Shake, a build tool/library written in Haskell. It does parallel builds, multi-language working, accurate dependencies, etc etc. I use it every day at work, and it is robust, scalable, and relatively easy to use. I didn't realize Shake had been released! Thanks for pointing that out! --Rogan Introductory video here: http://vimeo.com/15465133 Open source implementation here: https://github.com/batterseapower/openshake Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Newt - command-line template instantiation tool library
On Mon, May 9, 2011 at 8:25 AM, Rogan Creswick cresw...@gmail.com wrote:
Indeed :) The tag syntax is controlled by two command-line flags:
--prefix=... and --suffix=...
It can be difficult to get the desired strings past both the shell and
the regular expression compiler (although that last bit is changing...
Josh Hoyt sent a patch that switches to basic string inspection, which
should make this much simpler to use.)
I've just released newt-0.0.3.0, which has the patch from Josh (It
also uses a much nicer command-line syntaxt - it's backwards
compatible, but you can leave off the --source / --dest specifiers
now.)
With Josh's patch, things like this just work:
$ newt --prefix=*** --suffix=***
You can also look at the configuration structure with --verbose to
help debug problems with these flags:
$ newt --list some input file --prefix=*** --suffix=*** --verbose
Using configuration: Config {source = Just
tests/testFiles/simpleTest/alternate1.txt, dest = Nothing, rawTable
= [], list = True, inplace = False, prefix = Just ***, suffix = Just
***, verb = Loud}
This release also fixes a pretty important bug relating to binary
files... you couldn't have any binary content in your templates --
0.0.3.0 doesn't try to perform template replacements on binary files
now (which failed immediately in hGetContents in the previous
version).
Feedback / suggestions are always appreciated :)
Thanks!
--Rogan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Newt - command-line template instantiation tool library
On Sun, May 8, 2011 at 10:38 PM, bri...@aracnet.com wrote:
This is a useful tool !
I'm glad you think so too!
I would like to suggest allowing customization of the syntax to indicate a
tag, e.g. {# #} instead of (You just knew someone was going to say
that, right ? :-)
Indeed :) The tag syntax is controlled by two command-line flags:
--prefix=... and --suffix=...
It can be difficult to get the desired strings past both the shell and
the regular expression compiler (although that last bit is changing...
Josh Hoyt sent a patch that switches to basic string inspection, which
should make this much simpler to use.)
--Rogan
I only mention this in the hopes that it still early enough for you to write
the code in such a way to allow this even if you don't implement it right
away.
Brian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Newt - command-line template instantiation tool library
I'm happy to announce Newt: a trivial tool for creating boilerplate. I frequently need to create projects with slight customizations -- I have a particular layout for cabal projects, and make files for LaTeX papers, etc... However, there are often fields that need to be updated in many places. (At times, even file or directory names need changed.) Newt makes this trivial. My objective was to provide a tool that allows you to very quickly take a project, mark the portions that must change with angle brackets, and use that as a source for myriad derivations of that project, or share the project for others to create their own instances. Newt scans the input (either a file, directory or stdin) for tags marked with tagName [1], then replaces those entries with values specified on the command line, producing either a new file, modifying the input template in place (--inplace), writing to stdout, or writing to a directory. A newt template for a cabal project is available on github: - http://github.com/creswick/Newt/tree/master/tests/testFiles/dirTemplates/cabalProject Newt is available on hackage[2], and the source is hosted on github[3]. The readme provides more details and examples: - http://github.com/creswick/Newt/blob/master/README.md --Rogan [1] The tag syntax can be changed with command-line flags, or by creating an instance of the Tag typeclass. See --help. [2] http://hackage.haskell.org/package/newt [3] http://github.com/creswick/Newt/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] versioning of Haskell packages
On Fri, Apr 29, 2011 at 3:05 PM, Daniil Elovkov daniil.elov...@gmail.com wrote: Hello list I have an idea on versioning of Haskell packages and a small question about release model of Haskell Platform. Since the latter is shorter let's start with it. So, what is the release model of Haskell Platform? Is it released every N months and frozen at that point? Or some intermediate package/compiler updates can make the new version to appear out of schedule? Now, about package versioning. Haskell packages are flourishing and evolving at a high speed. Packages depend on other package and they evolve asynchronously. In result it is easy to end up in need of multiple versions of the same package in one program or maybe stumble upon other conflicts/problems. I'm expressing myself a little vaguely because I don't have a good example in my head right now. However, the idea is to maintain not just multi-digit version names that don't carry any semantics except that 1.1.3 is later than 1.1.2, but also somehow describe compatibility between versions. This way, even if the package A has jumped from 1.0 to 1.5 and the dependent package B has been stagnant all this time (and B depends on A 1.0), if we have information that 1.5 is compatible with 1.0, then we can safely use A 1.5 while building B. Or we could use whatever version of A is found in the system as long as its compatible with A 1.0 that B depends on. I think the PVP (Package Versioning Policy) covers a lot of what you're discussing, but I may misunderstand: http://www.haskell.org/haskellwiki/Package_versioning_policy We *do* still have some trouble maintaining / enforcing the PVP in general, and there are a few things that it doesn't cover (I don't believe exception behavior is covered, for example, although I'd argue that throwing more exceptions than a previous version introduces a substantial API change. Anyhow, that's a different rant. ;). Finer granularity would be great -- if it can be done autonomously. I think that raising awareness of the PVP and refining the tools to check for necessary version bumps would be a great step in the right direction. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to keep cabal and ghci package versions in sync?
On Tue, Apr 26, 2011 at 2:10 AM, Gracjan Polak gracjanpo...@gmail.com wrote: I kind of expected 'cabal-dev ghci' to do this for me. At the moment, cabal-dev ghci just uses the -package-conf and -no-user-package-conf flags to restrict ghci to the sandboxed and global package dbs. It's difficult to do more without parsing the content of the project's cabal file, and that parser isn't exposed through a library api (it's in cabal-install), which makes it a little difficult to use. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] errors while installing yesod 0.8
On Mon, Apr 25, 2011 at 2:44 PM, Michael Litchard mich...@schmong.org wrote: So it appears this is a bug with JSONb-1.0.2. There's a new version out. IS the answer to use that, or to patch this version? If there is a new version, and you indeed need JSONb for something, then you should use the newer version (yesod doesn't depend on it, so I'm a bit unsure why it came up...). --Rogan On Mon, Apr 25, 2011 at 1:48 PM, Michael Litchard mich...@schmong.org wrote: Following the install trail I run into this problem mlitchard@apotheosis:~$ cab install JSONb-1.0.2 Resolving dependencies... Configuring JSONb-1.0.2... Preprocessing library JSONb-1.0.2... Preprocessing executables for JSONb-1.0.2... Building JSONb-1.0.2... [1 of 7] Compiling Text.JSON.Escape ( Text/JSON/Escape.hs, dist/build/Text/JSON/Escape.o ) [2 of 7] Compiling Text.JSONb.Simple ( Text/JSONb/Simple.hs, dist/build/Text/JSONb/Simple.o ) [3 of 7] Compiling Text.JSONb.Decode ( Text/JSONb/Decode.hs, dist/build/Text/JSONb/Decode.o ) Text/JSONb/Decode.hs:56:33: Ambiguous occurrence `number' It could refer to either `Text.JSONb.Decode.number', defined at Text/JSONb/Decode.hs:118:0 or `Attoparsec.number', imported from Data.Attoparsec.Char8 at Text/JSONb/Decode.hs:25:0-52 cabal: Error: some packages failed to install: JSONb-1.0.2 failed during the building phase. The exception was: ExitFailure 1 How do I clear up this ambiguity? On Mon, Apr 25, 2011 at 1:24 PM, Michael Litchard mich...@schmong.org wrote: I started mindlessly pasting in the output, and the following lept out at me: , package authenticate-0.8.2.2-cc3ed2c523ecbf1ad123c3468785149e is unusable due to missing or recursive dependencies: http-enumerator-0.3.1-719bcd77e1dcb62efc9cf9b4f0b72271 package http-enumerator-0.3.1-719bcd77e1dcb62efc9cf9b4f0b72271 is unusable due to missing or recursive dependencies: attoparsec-enumerator-0.2.0.3-4978ab2dc4d87b7b724534bbfdcb07f1 package json-enumerator-0.0.1-7d4b724ae8c9b5ffa92da26856c4e1f1 is unusable due to missing or recursive dependencies: blaze-builder-enumerator-0.2.0.1-23e6e1f270358d3329f627e3a5ce8838 package wai-extra-0.3.2-f8378ad4a5cc6f375d96b718876384fa is unusable due to missing or recursive dependencies: There's more of the same I'm leaving out. I'm going to see if I can go somewhere with these error messages. If I totally hose things, I'll let you guys know. On Tue, Apr 19, 2011 at 4:45 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Wednesday 20 April 2011 01:22:20, Michael Litchard wrote: So what else can I try? $ cabal install -v3 monad-control That should give some hints at which point exactly things fail. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] errors while installing yesod 0.8
On Mon, Apr 25, 2011 at 3:10 PM, Michael Litchard mich...@schmong.org wrote: I think something that yesod uses, uses JSONb. Odd. I just checked the transitive dependencies of yesod-0.8.0 (with cab) and it doesn't seem to have that dependency. It could be system-specific, though. It would be nice to figure out what is depending on that version of JSONb so we could better determine if upgrading will break anything. --Rogan Also, I think I have borked my haskell environment to the point where it may be best to zap it and start over. On Mon, Apr 25, 2011 at 3:05 PM, Rogan Creswick cresw...@gmail.com wrote: On Mon, Apr 25, 2011 at 2:44 PM, Michael Litchard mich...@schmong.org wrote: So it appears this is a bug with JSONb-1.0.2. There's a new version out. IS the answer to use that, or to patch this version? If there is a new version, and you indeed need JSONb for something, then you should use the newer version (yesod doesn't depend on it, so I'm a bit unsure why it came up...). --Rogan On Mon, Apr 25, 2011 at 1:48 PM, Michael Litchard mich...@schmong.org wrote: Following the install trail I run into this problem mlitchard@apotheosis:~$ cab install JSONb-1.0.2 Resolving dependencies... Configuring JSONb-1.0.2... Preprocessing library JSONb-1.0.2... Preprocessing executables for JSONb-1.0.2... Building JSONb-1.0.2... [1 of 7] Compiling Text.JSON.Escape ( Text/JSON/Escape.hs, dist/build/Text/JSON/Escape.o ) [2 of 7] Compiling Text.JSONb.Simple ( Text/JSONb/Simple.hs, dist/build/Text/JSONb/Simple.o ) [3 of 7] Compiling Text.JSONb.Decode ( Text/JSONb/Decode.hs, dist/build/Text/JSONb/Decode.o ) Text/JSONb/Decode.hs:56:33: Ambiguous occurrence `number' It could refer to either `Text.JSONb.Decode.number', defined at Text/JSONb/Decode.hs:118:0 or `Attoparsec.number', imported from Data.Attoparsec.Char8 at Text/JSONb/Decode.hs:25:0-52 cabal: Error: some packages failed to install: JSONb-1.0.2 failed during the building phase. The exception was: ExitFailure 1 How do I clear up this ambiguity? On Mon, Apr 25, 2011 at 1:24 PM, Michael Litchard mich...@schmong.org wrote: I started mindlessly pasting in the output, and the following lept out at me: , package authenticate-0.8.2.2-cc3ed2c523ecbf1ad123c3468785149e is unusable due to missing or recursive dependencies: http-enumerator-0.3.1-719bcd77e1dcb62efc9cf9b4f0b72271 package http-enumerator-0.3.1-719bcd77e1dcb62efc9cf9b4f0b72271 is unusable due to missing or recursive dependencies: attoparsec-enumerator-0.2.0.3-4978ab2dc4d87b7b724534bbfdcb07f1 package json-enumerator-0.0.1-7d4b724ae8c9b5ffa92da26856c4e1f1 is unusable due to missing or recursive dependencies: blaze-builder-enumerator-0.2.0.1-23e6e1f270358d3329f627e3a5ce8838 package wai-extra-0.3.2-f8378ad4a5cc6f375d96b718876384fa is unusable due to missing or recursive dependencies: There's more of the same I'm leaving out. I'm going to see if I can go somewhere with these error messages. If I totally hose things, I'll let you guys know. On Tue, Apr 19, 2011 at 4:45 PM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: On Wednesday 20 April 2011 01:22:20, Michael Litchard wrote: So what else can I try? $ cabal install -v3 monad-control That should give some hints at which point exactly things fail. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to keep cabal and ghci package versions in sync?
On Sun, Apr 24, 2011 at 11:13 AM, Gracjan Polak gracjanpo...@gmail.com wrote: I have a project with a .cabal file listing package dependencies using the usual version constraints ==X.Y.* Z.W or =K.J syntax. Standard route cabal configure; cabal build works correctly as it is able to select working set of package versions. I have also a .ghci file. When I run GHCi it uses all latest installed packages in the system. This prevents the project from loading. I tried to use 'cabal-dev ghci', but this still selects latest global packages. This should only arise for the base ghc packages, which are tied closely enough to ghc that you should probably switch ghc versions if you want to work with different versions of those core packages. If you're installing additional packages globally, my only advice is: Beware, there be dragons! I strongly recommend that you ghc-pkg unregister all the non-essential packages from your global package db because: (1) cabal-dev will not bring you any benefit. (2) you will eventually run into ugly unsatisfiable dependency issues between your local and global package databases. (3) you may inadvertently cause a base package to be upgraded, which is somewhat easier to fix if it's installed to a local package db. cabal-dev ghci should be able to do what you want, but it has no control over the global db. I'd be happy to send you a list of the packages that ghc comes with, if you choose to unregister packages from the global db (assuming you're using one of the OS/arch/ghc combinations I have available :) --Rogan So, how to I load up ghci with the same package versions as selected by cabal? Thanks! -- Gracjan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] impoosible dependencies
On Thu, Apr 21, 2011 at 8:20 AM, KQ qu...@sparq.org wrote: On Wed, 20 Apr 2011 16:45:27 -0700, Carter Schonwald car...@cs.dartmouth.edu wrote: Kevin, what version of cabal install are you using? cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library snip Is it safe to upgrade cabal-install and the cabal library or are those part of the GHC package and I'll end up making things even worse? It is safe to do this. You will probably need to specify the full version, since despite being included in the latest haskell platform, cabal-install-0.10.x is in the list of things that cabal won't install automatically. (in the same way that it selects versions of parsec...) $ cabal-install Cabal-1.10.1.0 then $ cabal-install cabal-install-0.10.2 should do it. (I haven't had a chance to look at the detailed output you sent yet.) --Rogan I may have corrupted libraries; I think a re-install is in order soon, but I've been avoiding that until I get to the end of my current activities. -KQ P.S. I send Rogan the output he requested below privately to avoid spamming this list. On Wed, Apr 20, 2011 at 7:34 PM, Rogan Creswick cresw...@gmail.com wrote: On Wed, Apr 20, 2011 at 4:18 PM, Kevin Quick qu...@sparq.org wrote: With --verbose=3 this appears to be post-link running cabal-dev itself: $ cabal install cabal-dev --verbose=3 Could you send me (or post to hpaste) the complete output of 'cabal install cabal-dev --verbose=3' ? --Rogan ... *** Deleting temp files: Deleting: link: linkables are ... LinkableM (Wed Apr 20 16:14:58 MST 2011) main:Main [DotO /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/Main.o] Linking /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/setup ... *** Linker: ...[verbose GCC output elided]... rtend.o /nix/store/l8x3fdy1r6zf441vnqa87lzsvxrjbdz9-glibc-2.11.1/lib/crtn.o link: done *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: /tmp/ghc13224_0 /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/setup configure --verbose=3 --ghc --prefix=/home/kquick/.cabal --user --flags=-build-tests --flags=-no-cabal-dev --extra-include-dirs=/home/kquick/.nix-profile/include --extra-lib-dirs=/home/kquick/.nix-profile/lib --constraint=Cabal ==1.10.1.0 --constraint=HTTP ==4000.1.1 --constraint=base ==4.2.0.2 --constraint=bytestring ==0.9.1.9 --constraint=directory ==1.0.1.1 --constraint=filepath ==1.1.0.4 --constraint=mtl ==2.0.1.0 --constraint=network ==2.3.0.2 --constraint=pretty ==1.0.1.1 --constraint=process ==1.0.1.3 --constraint=tar ==0.3.1.0 --constraint=zlib ==0.5.3.1 cabal: Error: some packages failed to install: cabal-dev-0.7.4.1 failed during the configure step. The exception was: ExitFailure 11 $ -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] impoosible dependencies
On Thu, Apr 21, 2011 at 11:37 AM, Erik Hesselink hessel...@gmail.com wrote: It doesn't seem to do this anymore for parsec. The preferred-versions now look like this: base 4 cabal-install 0.10 network 2.2.3 || = 2.2.4 Or am I looking at the wrong thing? Oh, interesting. I think you're looking at the right thing. I haven't checked it since cabal-install-0.10 came out (I have the hardest time finding that url...). --Rogan Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] impoosible dependencies
On Wed, Apr 20, 2011 at 2:51 PM, Kevin Quick qu...@sparq.org wrote: $ cabal update $ cabal install hakyll Resolving dependencies... cabal: dependencies conflict: ghc-6.12.3 requires unix ==2.4.0.2 however unix-2.4.0.2 was excluded because ghc-6.12.3 requires unix ==2.4.1.0 $ Any advice (other than upgrading to 7.0.3, which is not an option at the moment)? You can run the build with verbose output (--verbose=3) and get more details about why the impossible dependencies were required, or you can build your application (whatever relies on hakyll) with cabal-dev -- I've been able to build hakyll that way on my machine with ghc-6.12.3, so I suspect there is some unexpected dependency in your local package db that is causing cabal to make a series of undesirable version selections. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] impoosible dependencies
On Wed, Apr 20, 2011 at 4:18 PM, Kevin Quick qu...@sparq.org wrote: With --verbose=3 this appears to be post-link running cabal-dev itself: $ cabal install cabal-dev --verbose=3 Could you send me (or post to hpaste) the complete output of 'cabal install cabal-dev --verbose=3' ? --Rogan ... *** Deleting temp files: Deleting: link: linkables are ... LinkableM (Wed Apr 20 16:14:58 MST 2011) main:Main [DotO /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/Main.o] Linking /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/setup ... *** Linker: ...[verbose GCC output elided]... rtend.o /nix/store/l8x3fdy1r6zf441vnqa87lzsvxrjbdz9-glibc-2.11.1/lib/crtn.o link: done *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: /tmp/ghc13224_0 /tmp/cabal-dev-0.7.4.113193/cabal-dev-0.7.4.1/dist/setup/setup configure --verbose=3 --ghc --prefix=/home/kquick/.cabal --user --flags=-build-tests --flags=-no-cabal-dev --extra-include-dirs=/home/kquick/.nix-profile/include --extra-lib-dirs=/home/kquick/.nix-profile/lib --constraint=Cabal ==1.10.1.0 --constraint=HTTP ==4000.1.1 --constraint=base ==4.2.0.2 --constraint=bytestring ==0.9.1.9 --constraint=directory ==1.0.1.1 --constraint=filepath ==1.1.0.4 --constraint=mtl ==2.0.1.0 --constraint=network ==2.3.0.2 --constraint=pretty ==1.0.1.1 --constraint=process ==1.0.1.3 --constraint=tar ==0.3.1.0 --constraint=zlib ==0.5.3.1 cabal: Error: some packages failed to install: cabal-dev-0.7.4.1 failed during the configure step. The exception was: ExitFailure 11 $ -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] errors while installing yesod 0.8
On Tue, Apr 19, 2011 at 2:18 PM, Michael Litchard mich...@schmong.org wrote: mlitchard@apotheosis:~/monad-control$ cabal install Resolving dependencies... Configuring monad-control-0.2.0.1... cabal: Error: some packages failed to install: monad-control-0.2.0.1 failed during the configure step. The exception was: ExitFailure 11 note: I've been trying to use the cab command to manage my packages, I get the same error as above when I use cab instead of cabal.I mention this just in case there is some unforseen problem having to do with cab/cabal interaction. Has anyone experienced this problem, or know what I can do to get more useful error messages that might reveal the cause of the breakage? You might learn more by issuing the configure / build steps manually (I think `cabal configure` will produce an error). Upping the verbosity will also help: # get pages and pages of details: $ cabal install --verbose=3 I would first suggest trying cabal-dev, though (cab can delegate to cabal-dev now too, but I haven't played with it yet). $ cabal-dev install yesod-0.8 will either work or fail in a way that we can more easily reproduce. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] errors while installing yesod 0.8
On Tue, Apr 19, 2011 at 3:10 PM, Michael Litchard mich...@schmong.org wrote: New information, may be helpful. I manually installed hamlet 0.8 with cabal-dev, and it seemed to install. Here is the message Registering hamlet-0.8.0... Installing library in /home/mlitchard/hamlet-0.8.0/cabal-dev//lib/hamlet-0.8.0/ghc-6.12.3 Registering hamlet-0.8.0... It looks like you manually downloaded the hamlet-0.8.0.tar.gz, unpacked it, and ran cabal-dev install from inside there -- is that right? (There's nothing wrong with doing it that way, but it doesn't quite do what you expected, based on the rest of your email. Also, if my assumption is wrong, then the rest of my advice may not help.) First, it's important to know that cabal-dev sandboxes everything it can. If you want to install hamlet into your .cabal directory, then you need to use cabal, not cabal-dev. Cabal-dev is meant to keep everything for a given project separate from everything else -- in this way you can have multiple projects that depend on conflicting libraries building at the same time, and it also means that coincidental changes to your user package database won't cause spurious *successes* when you build something, which is a surprisingly common problem. Unfortunately this means that the first time you build a project with cabal-dev, it tends to take a long time (it has to build everything it depends on). Now, there are (at least) two important take-away points / implications of using cabal-dev: (1) cabal-dev won't install a library into a standard location. That's by design, so you don't usually want to cabal-dev install dependencies manually. (2) cabal-dev uses the local hackage cache to select packages in the same way cabal does (cabal-dev actually just uses cabal to do this). mlitchard@apotheosis:~/yesod-0.8.0$ cabal-dev install Resolving dependencies... cabal: cannot configure yesod-0.8.0. It requires hamlet ==0.8.* There is no available version of hamlet that satisfies ==0.8.* I think you just need to run 'cabal update' so cabal-dev can see the latest version of hamlet, after which you can cabal-dev install yesod. There are a couple other things to try if that doesn't work for some reason. --Rogan I noticed it did not install in the $HOME/.cabal/ path. How do make sure it does that? I think if I can get it to install in the right place this will work out. On Tue, Apr 19, 2011 at 2:52 PM, Rogan Creswick cresw...@gmail.com wrote: On Tue, Apr 19, 2011 at 2:18 PM, Michael Litchard mich...@schmong.org wrote: mlitchard@apotheosis:~/monad-control$ cabal install Resolving dependencies... Configuring monad-control-0.2.0.1... cabal: Error: some packages failed to install: monad-control-0.2.0.1 failed during the configure step. The exception was: ExitFailure 11 note: I've been trying to use the cab command to manage my packages, I get the same error as above when I use cab instead of cabal.I mention this just in case there is some unforseen problem having to do with cab/cabal interaction. Has anyone experienced this problem, or know what I can do to get more useful error messages that might reveal the cause of the breakage? You might learn more by issuing the configure / build steps manually (I think `cabal configure` will produce an error). Upping the verbosity will also help: # get pages and pages of details: $ cabal install --verbose=3 I would first suggest trying cabal-dev, though (cab can delegate to cabal-dev now too, but I haven't played with it yet). $ cabal-dev install yesod-0.8 will either work or fail in a way that we can more easily reproduce. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] errors while installing yesod 0.8
On Tue, Apr 19, 2011 at 4:22 PM, Michael Litchard mich...@schmong.org wrote: yesod-static-0.1.0 depends on monad-control-0.2.0.1 which failed to install. This is what happened after I did cabal update, then cabal-dev install yesod. This is the original error I received. Just for a point of reference - I just tried this and monad-control-0.2.0.1 build just fine. (The build failed overall because I didn't have the correct unix-compat c library deps installed.) I poked into the monad-control build system, and the only thing that strikes me as at all unusual is that it uses unicode symbols for :: and - in Setup.hs. --Rogan So what else can I try? On Tue, Apr 19, 2011 at 3:30 PM, Rogan Creswick cresw...@gmail.com wrote: On Tue, Apr 19, 2011 at 3:10 PM, Michael Litchard mich...@schmong.org wrote: New information, may be helpful. I manually installed hamlet 0.8 with cabal-dev, and it seemed to install. Here is the message Registering hamlet-0.8.0... Installing library in /home/mlitchard/hamlet-0.8.0/cabal-dev//lib/hamlet-0.8.0/ghc-6.12.3 Registering hamlet-0.8.0... It looks like you manually downloaded the hamlet-0.8.0.tar.gz, unpacked it, and ran cabal-dev install from inside there -- is that right? (There's nothing wrong with doing it that way, but it doesn't quite do what you expected, based on the rest of your email. Also, if my assumption is wrong, then the rest of my advice may not help.) First, it's important to know that cabal-dev sandboxes everything it can. If you want to install hamlet into your .cabal directory, then you need to use cabal, not cabal-dev. Cabal-dev is meant to keep everything for a given project separate from everything else -- in this way you can have multiple projects that depend on conflicting libraries building at the same time, and it also means that coincidental changes to your user package database won't cause spurious *successes* when you build something, which is a surprisingly common problem. Unfortunately this means that the first time you build a project with cabal-dev, it tends to take a long time (it has to build everything it depends on). Now, there are (at least) two important take-away points / implications of using cabal-dev: (1) cabal-dev won't install a library into a standard location. That's by design, so you don't usually want to cabal-dev install dependencies manually. (2) cabal-dev uses the local hackage cache to select packages in the same way cabal does (cabal-dev actually just uses cabal to do this). mlitchard@apotheosis:~/yesod-0.8.0$ cabal-dev install Resolving dependencies... cabal: cannot configure yesod-0.8.0. It requires hamlet ==0.8.* There is no available version of hamlet that satisfies ==0.8.* I think you just need to run 'cabal update' so cabal-dev can see the latest version of hamlet, after which you can cabal-dev install yesod. There are a couple other things to try if that doesn't work for some reason. --Rogan I noticed it did not install in the $HOME/.cabal/ path. How do make sure it does that? I think if I can get it to install in the right place this will work out. On Tue, Apr 19, 2011 at 2:52 PM, Rogan Creswick cresw...@gmail.com wrote: On Tue, Apr 19, 2011 at 2:18 PM, Michael Litchard mich...@schmong.org wrote: mlitchard@apotheosis:~/monad-control$ cabal install Resolving dependencies... Configuring monad-control-0.2.0.1... cabal: Error: some packages failed to install: monad-control-0.2.0.1 failed during the configure step. The exception was: ExitFailure 11 note: I've been trying to use the cab command to manage my packages, I get the same error as above when I use cab instead of cabal.I mention this just in case there is some unforseen problem having to do with cab/cabal interaction. Has anyone experienced this problem, or know what I can do to get more useful error messages that might reveal the cause of the breakage? You might learn more by issuing the configure / build steps manually (I think `cabal configure` will produce an error). Upping the verbosity will also help: # get pages and pages of details: $ cabal install --verbose=3 I would first suggest trying cabal-dev, though (cab can delegate to cabal-dev now too, but I haven't played with it yet). $ cabal-dev install yesod-0.8 will either work or fail in a way that we can more easily reproduce. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A maintenance command of Haskell cabal packages
On Thu, Mar 31, 2011 at 7:19 PM, Kazu Yamamoto k...@iij.ad.jp wrote: cabal-dev is a wrapper around cabal. It creates the directory cabal-dev in your current directory when you run commands. Yes, I know. But when I typed cabal-devel install on a package directory, nothing happened. Can you give a specific example? Surely *something* happened :) I read its source but I could not found the code where cabal-dev passes GHC_PACKAGE_PATH to ghc. I don't know how cabal-dev can implement the sandbox featrue. running cabal-dev with --verbose=3 will show you all the cabal and ghc-pkg commands, which is probably the best way to see what's going on. Cabal-dev uses a custom cabal.config file that's (by default) located in the sandbox directory. That file specifies a package-db to use (amongst a few other things), and cabal-install is invoked with that config. --Rogan --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] SoC / Cabal project proposal: specify Setup.hs dependencies
I've been wanting to share code between cabal projects for some time, and I finally had a chance to write up the rough idea as a simple proposal. Here's the description, with links to the SoC trac and reddit haskell_proposals pages. SoC ticket: http://hackage.haskell.org/trac/summer-of-code/ticket/1602 Reddit: http://www.reddit.com/r/haskell_proposals/comments/ge1zp/cabal_dependency_specifications_for_setuphs/ Non-standard builds often need to implement specific build steps in Setup.hs, specifying a build-type: Custom in the project cabal file. The user hook system works reasonably well for modifying or replacing the specific sub steps of a build, but *implementing* anything more than the simplest logic in Setup.hs is very difficult. A great deal of this difficulty stems from the lack of library support for code in Setup.hs. Adding a cabal section that specifies a build-depends: for Custom (and possibly other) build types would allow developers to reuse build code between projects, to share build system modifications on hackage more easily, and to prototype new additions to cabal. Setup.hs *can* allow arbitrarily complex build system manipulations; however, it is not practical to do so because the infrastructure surrounding Setup.hs doesn't promote code reuse. The addition of dependencies that cabal-install would install prior to building setup.hs and issuing the build would enable developers to produce custom builds that perform complex operations that utilize the high-quality libraries available on hackage. Furthermore, this would provide the means to prototype (and distribute) new cabal / cabal-install features before integrating experimental code into the stable tools. I'm interested in thoughts / feedback about the idea, as well as hearing from anyone interested in pursuing this as a summer of code project :) Thanks! --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Saving changes to cabal config in cabal-dev
On Sat, Mar 26, 2011 at 2:28 PM, Yitzchak Gale g...@sefer.org wrote: Thanks for the fantastic cabal-dev tool! You're welcome! Is there any convenient way to save changes to the package-specific cabal config file in cabal-dev? The only solution I have found so far is to run cabal-dev install once (ignoring the errors) to create the cabal-dev directory and cabal.config, make a copy of cabal.config with a different name, edit it as needed, and then use a long-winded --config=... option for every subsequent run cabal-dev. That is currently the only way to do this :(. One workaround is to create an alias for cabal-dev that adds that flag. e.g., in Bash: alias cabal-dev = 'cabal-dev --config=cabal.config ' Then you can have a cabal.config next to your project cabal file and it will use that. To bypass the alias, just prefix it with \, e.g.: $ \cabal-dev We're working on the first problem -- it's just a matter of finding the time. Unfortunately, that's probably not going to happen for another week or two. The ticket is here: https://github.com/creswick/cabal-dev/issues#issue/15 --Rogan The changes I need to make are as follows: - remote-repo-cache is wrong for Mac OS X - add more remote-repo lines for our local yackage servers. Note that the first is global, so it would be nice to have a way to make that change once globally for all packages. Whereas the second is, in general, package specific. We find local yackage servers much simpler to use and far more powerful than using add-source. You can organize packages by project, team, specific developers, etc. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 7/Cabal request for help
On Thu, Mar 24, 2011 at 9:30 AM, Erik Hesselink hessel...@gmail.com wrote: I've just tested this, and with GHC 7, cabal chooses QuickCheck 2.4, whereas with GHC 6.12, it chooses 2.1. I believe that the behavior you're seeing is because the package selection is biased by the state of your local package databases (plural, because there is a separate db for each version of GHC). If quickcheck 2.1 was installed with ghc 6.12, and satisfies the package requirements, then cabal won't select a newer version on its own (at least, that's my understanding). If you either didn't have QuickCheck installed in your ghc7 package db, or had v.2.4 installed, then ghc 7 would use that version. Building with cabal-dev instead of cabal will use the most recent set of satisfying dependencies according to your local hackage index, rather than the compiled versions of packages you happen to have around. Alternatively, you can ghc-pkg unregister all the dependencies from your local package db. (in this case, ghc-pkg unregister QuickCheck-2.1, with ghc-pkg from 6.12, then cabal-install testpack and you should see the failure). --Rogan If I specify that 6.12 should choose 2.4 as well, I get the same issue there. This is to be expected, because I don't see the CPP checks you mentioned in Test/QuickCheck/Instances.hs in testpack-2.0.1. Perhaps you haven't released a version with those checks yet? Erik On Thu, Mar 24, 2011 at 14:18, John Goerzen jgoer...@complete.org wrote: Hi folks, I don't have a GHC 7 environment running yet (it's on my list...) but I received a bug report pointing me at this build failure: http://hackage.haskell.org/packages/archive/testpack/2.0.1/logs/failure/ghc-7.0 Among other things, this noted: Dependency QuickCheck =2.1.0.3: using QuickCheck-2.4.0.1 and the errors were: [1 of 3] Compiling Test.QuickCheck.Instances ( src/Test/QuickCheck/Instances.hs, dist/build/Test/QuickCheck/Instances.o ) src/Test/QuickCheck/Instances.hs:39:10: Duplicate instance declarations: instance Arbitrary Word8 -- Defined at src/Test/QuickCheck/Instances.hs:39:10-24 instance Arbitrary Word8 -- Defined in Test.QuickCheck.Arbitrary src/Test/QuickCheck/Instances.hs:42:10: Duplicate instance declarations: instance CoArbitrary Word8 -- Defined at src/Test/QuickCheck/Instances.hs:42:10-26 instance CoArbitrary Word8 -- Defined in Test.QuickCheck.Arbitrary Now, that's fairly standard, and in fact, in my code, is wrapped with: #if MIN_VERSION_QuickCheck(2,3,0) -- we have Word8 instances here #else instance Arbitrary Word8 where arbitrary = sized $ \n - choose (0, min (fromIntegral n) maxBound) instance CoArbitrary Word8 where coarbitrary n = variant (if n = 0 then 2 * x else 2 * x + 1) where x = abs . fromIntegral $ n #endif And that code has been working to support modern QuickCheck versions for some time. It would appear that something in Cabal, GHC 7, or QuickCheck is breaking this check. Ideas? -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: cabal-dev-0.7.4.0
We're happy to announce that cabal-dev-0.7.4.0 is now on hackage. We strongly suggest that everyone upgrade to this release, since this release specifically addresses changes in Cabal-1.10 and newer, which the latest cabal-install now uses. The ticket for the bug is here, for anyone interested: https://github.com/creswick/cabal-dev/issues/2 --Rogan smime.p7s Description: S/MIME Cryptographic Signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Abstracting a Genetic Algorithm
On Tue, Feb 15, 2011 at 3:35 PM, Alex Good alexjsg...@gmail.com wrote: One bonus question, just a thing that's been bothering me, is there any way to create something like a type synonym for a function so that if I'm writing a function which takes functions as arguments I can write the synonym rather than the whole type signature of the function i.e so that something like the following would work. type someFunc = [Int] - [Int] - Int someOtherFunc :: someFunc - [Int] - Int I think you just about have it right. Type names must still begin with a leading capitol letter though. See: http://www.haskell.org/haskellwiki/Type#Type_and_newtype for examples, but I this should work: type SomeFunc = [Int] - [Int] - Int someOtherFunc :: SomeFunc - [Int] - Int -- same as: -- someOtherFunc :: ([Int] - [Int] - Int) - [Int] - Int --Rogan Right, hopefully that's a lucid enough explanation of the problem, feel like I've missed the really obvious answer but it hasn't jumped out at me. Cheers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Packages all screwed up
On Mon, Jan 31, 2011 at 11:16 PM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hi, Thanks for your answers. I did cabal upgrade yesod I think 'upgrade' is deprecated, and known to break things on occasion (or at least have unexpected behavior--I'm not clear on the details). You can use 'cabal install' to upgrade packages. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building lambdabot
On Tue, Jan 4, 2011 at 5:16 PM, Joe Bruce bruce.jo...@gmail.com wrote: I've had a bit of an adventure trying to build and run lambdabot on my box. 'cabal install lambdabot' does not work. It states it's not GHC 6.12 (and certainly not 7.0) compatible, but I tried 6.12 anyway and got nowhere. I'm assuming you ran into the mtl-2.0 api changes with respect to State. I didn't have any trouble building lambdabot after setting an upper version bound on the mtl dependency in lambdabot.cabal: Library build-depends: base, mtl = 2.0, bytestring, unix I used ghc-6.12.3, and cabal-dev. --Rogan Next, I tried 6.10 but failed on the unix dependency (in the same manner as this thread). The thread is unresolved, so I've not tried modifying the cabal build-depends. I'm hoping to find someone who has a working lambdabot setup who can point me in the right direction. What further information about my struggles should I provide? Thanks, Joe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building lambdabot
On Wed, Jan 5, 2011 at 12:53 PM, Rogan Creswick cresw...@gmail.com wrote: State. I didn't have any trouble building lambdabot after setting an upper version bound on the mtl dependency in lambdabot.cabal: Library build-depends: base, mtl = 2.0, bytestring, unix My mistake, that should be strictly less-than: Library build-depends: base, mtl 2.0, bytestring, unix --Rogan I used ghc-6.12.3, and cabal-dev. --Rogan Next, I tried 6.10 but failed on the unix dependency (in the same manner as this thread). The thread is unresolved, so I've not tried modifying the cabal build-depends. I'm hoping to find someone who has a working lambdabot setup who can point me in the right direction. What further information about my struggles should I provide? Thanks, Joe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: cabal-dev 0.7.3.1 -- now with ghci!
Cabal-dev is now capable of launching ghci with the project's package database and local modules (if the package under development exposes a library). For example: # First, invoke cabal-dev install the package to populate the # package database: $ cabal-dev install snip $ cabal-dev ghci GHCi, version 6.12.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Prelude The ghci shell should have access to all the libraries your application/library is using, as well as any modules that your library exposes. Note that this is not quite as natural as your traditional ghci shell, namely: Source modifications are not visible without exiting, re-issuing `cabal-dev install` *and* `cabal-dev ghci`. This will eventually get better, but that's where things are right now. The reason for this is that `cabal-dev ghci` just issues ghci with the cabal-dev package database (and excluding the user package db, to best reflect what cabal-dev does when it causes compilation). Cabal-dev is available on hackage and github: - http://hackage.haskell.org/package/cabal-dev - https://github.com/creswick/cabal-dev There is a short write-up with a (slightly) longer example here: - http://blog.ciscavate.org/2010/12/cabal-dev-sandboxing-your-haskell-development-and-now-with-ghci.html --Rogan smime.p7s Description: S/MIME Cryptographic Signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: cabal-dev - sandboxed haskell development
Galois is happy to announce cabal-dev: a tool for managing development builds of Haskell projects within sandboxes. Performing consistent builds is critical in software development, but the current system in GHC/Haskell of per-user and per-system GHC package databases interferes with this need for consistency. It is difficult to precisely identify the dependencies of a given project, and changes necessary to enable one project to build may render another project inoperable. If each project had a separate package database, each project could be built in a sandbox. Cabal-dev manages cabal-install repositories and sandboxed ghc package databases to prevent interactions between disparate projects or user package databases. Cabal-dev is similar to capri, which was coincidentally developed concurrently, but the two projects take slightly different approaches to sandboxing and exhibit slightly different behaviors depending on the state of the global package database and the versions of the tools installed. For most packages, just use cabal-dev instead of cabal, and you will get a sandboxed build that will not install anything (even automatically installed dependencies) into the user or global ghc package databases. If your build depends on patched or unreleased libraries, you can add them to your sandboxed build environment so they can be installed by cabal-dev or cabal by running: cabal-dev add-source /path/to/source/code Where /path/to/source/code is either a path to a source directory containing a .cabal file, or an sdist tarball. Cabal-dev has been in use at Galois for roughly six months now, but it should currently be treated as alpha software: we've exercised a few execution paths heavily, but it still has a number of rough edges (the rough edges we know about are documented in the TODO file: https://github.com/creswick/cabal-dev/blob/master/TODO.md). Cabal-dev is hosted on hackage and git-hub: - http://hackage.haskell.org/package/cabal-dev - https://github.com/creswick/cabal-dev A brief tutorial can be found in the README.md: - https://github.com/creswick/cabal-dev/blob/master/README.md We're looking forward to your feedback! --Rogan Creswick smime.p7s Description: S/MIME Cryptographic Signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] non-hackage cabal repos? unpacking non-repo package tarballs?
On Tue, Nov 2, 2010 at 11:02 AM, Claus Reinke claus.rei...@talk21.com wrote: I often find myself writing example code that I'd like to distribute via cabal, but without further burdening hackage with not generally useful packages. 1. The simplest approach would be if cabal could expose its internal 'unpackPackage' as a command, so that author: cabal sdist user: cabal unpackPackage Example.tar.gz This is possible with cabal-dev (http://goo.gl/RkLGx), but it's somewhat of an accidental feature, so it's not quite as simple as your ideal: Author: $ cabal sdist The user's side of things changes a bit depending on what the package is. If it's an executable, this works: User: $ cabal-dev add-source Example.tar.gz $ cabal-dev install Example $ ./cabal-dev/bin/example-program If you're distributing a binary, then the add-source is really all it takes, if you're happy using cabal-dev for the whole build. It will create a local sandbox with the new library, and subsequent cabal-dev commands can use that sandbox for all non-global packages. --Rogan would work (the point being that cabal handles .tar.gz, which not all users have installed separately; distributing the .tar.gz would be handled via the usual channels; and after unpacking, cabal can build the source package). Note that 'cabal unpack' does not seem helpful here, as it touches the package index instead of just looking at the tarball. Could this be made possible, please? Or is it already? 2. Failing that, I remembered that cabal used to be designed without a fixed package repo address, and a little digging found options --remote-repo and --local-repo, as well as the directory layout for package repositories: http://hackage.haskell.org/trac/hackage/wiki/HackageDB So this scenario seems possible, in principle: author: expose a package repo http://myrepo user: cabal --remote-repo=http://myrepo fetch Example Is it possible to add a (temporary) repo location like this, especially for 'cabal fetch'/'cabal unpack'? I've managed to get 'cabal --local-repo=myrepo list Example' to work (needs uncompressed 00-index.tar), but not the remote variant, and fetching from the local repo doesn't work, either. Are there any usage examples of these features? Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiler constraints in cabal
On Sun, Nov 7, 2010 at 3:58 PM, wren ng thornton w...@freegeek.org wrote:
On 11/7/10 11:54 AM, Henning Thielemann wrote:
Awful - I would not like to complicate my Cabal files this way. This is
like copying the Build-Depends enumeration to all depending packages.
Oh, I agree :)
I wonder if you can include ghc in the build-tools: field and whether
cabal-install bases its decisions on that field...
You can include ghc in that list, but I haven't been able to test to
see if it changes the way cabal decides on installable packages. I
doubt it.
Tangentially -- you can add any program you wish to that field, but a
little setup.hs hacking is necessary to get the version requirements
check to work properly.
Here's an example that checks for bnfc:
main = do
defaultMainWithHooks simpleUserHooks
{ hookedPrograms = [bnfcProgram] }
bnfcProgram :: Program
bnfcProgram = (simpleProgram bnfc) {
-- this assumes that --numeric-version prints *only* the
dot-separated version id (eg: 6.12.0)
programFindVersion = findProgramVersion --numeric-version id
}
With that in Setup.hs, you can specify version requirements in your
cabal file as you normally would:
eg:
Build-tools:
bnfc = 2.4.2.0 = 2.5
Unfortunately, I don't know of any good way to share that Setup.hs
code across multiple projects.
--Rogan
Another option might be to have users set the preference: field in
~/.cabal/config. Though that requires user action again...
Why is the package ghc version specific anyways? Is it just a language
extension thing?
Does the LanguageExtensions field prevent building a package, if the
installed compiler cannot handle that? I'm afraid, LanguageExtensions is
just a list of flags that is passed to GHC. But it sounds like a good
idea, if Cabal would also check, whether the used compiler supports the
required LanguageExtensions at all.
If you just wanted to ensure that things don't build on the wrong version,
then you could always use a custom Setup.hs and use CPP to choose between
exitSuccess and exitFailure somewhere along the way.
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] packaging a cgi binary using cabal
On Wed, Sep 22, 2010 at 7:53 AM, Pedro Baltazar Vasconcelos p...@dcc.fc.up.pt wrote: I wrote a simple interactive tableaux theorem prover as a cgi in Haskell (http://www.ncc.up.pt/~pbv/cgi/tableaux.cgi) and would like to submit to hackage but need some advice on how to package it using cabal. In particular, the binary, CSS and bitmap files need to be installed under the web server directory (public_html or alike) rather than system or user directories. Any thoughts on how to do this? You could probably use a post-install (postInst) user hook to do it, but that can get a little hairy. (I'm not certain what modules you can reasonably use from code invoked via Setup.hs, and you'll have to worry about tracking down/detecting/creating a public_html directory) To use user hooks with cabal-install, you will also have to set the build-type to Custom. The list of user hooks is here: http://hackage.haskell.org/packages/archive/Cabal/1.8.0.6/doc/html/Distribution-Simple-UserHooks.html Ed Yang has a blog post that discusses using user hooks to do relatively complex build tasks. While the context and objective are a bit different, his examples may help to understand the syntax and interactions between the cabal file and Setup.hs: http://blog.ezyang.com/2010/06/setting-up-cabal-the-ffi-and-c2hs/ --Rogan Regards, Pedro Vasconcelos ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graphics.Drawing
On Mon, Sep 6, 2010 at 5:29 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 6 September 2010 21:57, han e...@xtendo.org wrote: So the question is: Do you agree that Graphics.Rendering.OpenGL actually should have been Graphics.OpenGL (or just OpenGL) for wieldiness? I think Graphics.OpenGL would have sufficed, unless there was sufficient reason to want to group it with other rendering-specific modules. I'm relatively new to the Haskell community, and one thing that's bugged me a bit is that there doesn't seem to be a convention (aside from common sense) for segmenting the module namespace as there is with Java (my other primary language). If you're not familiar with Java's conventions: Each package producer is encouraged to prefix all their released packages with a reversed dns name (more or less, I don't recall the exact term). For example, if Galois were to release a Java OpenGL package, it would be named something like com.galois.graphics.opengl. This makes it fairly easy to differentiate between different implementations of similar things -- or just to reduce namespace collisions. This comes at the expense of typing a bit more, but no one particularly cares in the java community because the IDEs take care of that. Anyway, I'm curious how module namespace collisions/pollution will be handled in Haskell over the next 5-10 years. Package hiding works in some cases, but it seems like that will fail if you ever need to use capabilities from packages that conflict within the same project. Is this actually a problem, or am I worried about nothing? --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] iPhone/Android and Haskell [Was: Embedded funcional programming?]
On Tue, Aug 10, 2010 at 4:23 PM, Mathew de Detrich dete...@gmail.com wrote: There still however leaves the problem with what to do with Java, because a proper Android app (not a linux app compiled for ARM) needs to link with Java to interface with Android I'm interested in getting jvm-bridge working again, but I've run into problems with understanding how it interfaces with 3rd party source. I would welcome the help if anyone else is also interested :) (are the original authors still around?). The basic capabilities seem to work fine with minor build fixes -- the examples that only use the core java libraries were easy to use. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] can Haskell do everyting as we want?
On Tue, Aug 3, 2010 at 4:12 PM, Qi Qi qiqi...@gmail.com wrote: Is there anyone happen to come into any tasks that haskell is not able to achieve? Haskell has very limited support for high-level Natural Language Processing (tokenization, sentence splitting, Named-entity recognition, etc...). NLTK (python), OpenNLP (java), and FleeLing (C++) all have quite a lot to offer here, but there aren't currently any bindings to those implementations from Haskell. FreeLing is the best choice from a pure languages standpoint, but it is GPL, which would infect the resulting bindings and reduce the utility of the result. I have some hope that jvm-bridge can be resurrected to bind to OpenNLP, but that's something I've only spent a few days thinking about. (I'd love to have some pointers / help / documentation on jvm-bridge, if anyone has insights :) --Rogan Thanks. -- Qi Qi ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new Cabal user question -- installing to Haskell Platform on Windows network drive?
On Tue, Jul 27, 2010 at 2:43 PM, Peter Schmitz ps.hask...@gmail.com wrote: So, by default, cabal wants to put its config and updates on C:. I looked at C:\Documents and Settings\pschmitz\Application Data\cabal\config It has various references to C:, some commented out. E.g.: remote-repo-cache: C:\Documents and Settings\pschmitz\Application Data\cabal\packages build-summary: C:\Documents and Settings\pschmitz\Application Data\cabal\logs\build.log install-dirs user -- prefix: C:\\Documents and Settings\\pschmitz\\Application Data\\cabal You can change these to whatever you want, and cabal should just start using those locations, if that helps. Given that I want to keep everything on H:, and assuming that I don't want to place the Cabal configs and updates in the Platform tree (H:\proc\tools\Haskell Platform), I would _like_ to create a dir such as H:\proc\tools\cabal to hold everything that Cabal would normally put on C:. *** I'm afraid I'm having trouble figuring out how to accomplish this. Is there (hopefully) a combination of cabal command line switches that will create a new config file over on H: for me, or must I edit the config file directly and move it to H:? There are others on this list that know cabal much better than I, but I have been working with it a bit recently, so I'll take a stab.. I don't believe you can configure *cabal* to look on H: for the cabal config, without specifying . I believe it uses the windows Application Data directory for your current user to locate the cabal config (there is a windows system (?) call that returns something akin to c:\Documents and Settings\username\Application Data\ ). You *can* change the location of your Application Data directory by hacking the windows registry, but that is likely to cause more pain than it is worth. I think you will be best served by just editing the entries in your cabal config (if that, even) unless you have a very good reason to relocate the cabal config itself. (Ok, so I think I lied a little -- iirc, there is an undocumented cabal flag that will let you specify the path to the cabal config file to use. I think it has to be the first parameter to cabal, and I think it's --cabal-config=file, but I've only used it once and I don't think it's really worth the trouble in your case. Application Data is a pretty standard place for things like this.) --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] new Cabal user question -- installing to Haskell Platform on Windows network drive?
On Mon, Jul 26, 2010 at 2:06 PM, Peter Schmitz ps.hask...@gmail.com wrote: I have recently installed the Haskell Platform (for the first time) to a MS Windows network drive; e.g.: H:\aaa\bbb\Haskell Platform\2010.1.0.0\ I did so without admin privs. It has ghc-6.12.1 I need to not install to C:. I would like to install and use Gtk2Hs and Glade on the Platform also. There are instructions in the INSTALL doc here: * http://code.haskell.org/gtk2hs/INSTALL Generally, you don't need to (explicitly) download anything when using cabal-install, cabal install does that for you. However, when libraries implemented in other languages are used, such as with gtk2hs, you will need to manually install something. That's where the windows gtk+ libraries come in. You can download them from here: http://www.gtk.org/download-windows.html That url is mentioned in the INSTALL document linked to above, and the document also describes what you need to download and install. I don't know if it is possible to do that without admin access though (I've never tried). Once you have the gtk+ libraries installed it should just be a matter of running 'cabal update' (to get the latest updates from hackage) and then running a handfull of 'cabal install foo' commands. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, Setup.lhs example
On Wed, Jul 21, 2010 at 3:00 AM, Magnus Therning mag...@therning.org wrote:
I am successfully using hooks with the following in my .cabal file:
Build-Type : Simple
and my main in Setup.hs looks like this:
main = defaultMainWithHooks $ simpleUserHooks
{ cleanHook = profileClean
, runTests = runTestsBuild
}
I've been unable to reproduce this -- flipping the build type to
Custom has been necessary in every configuration I've tried. I'd like
to see what I'm doing differently -- is this used in a publicly
available package I could take a look at?
Thanks!
Rogan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, Setup.lhs example
On Tue, Jul 20, 2010 at 8:50 PM, Tom Hawkins tomahawk...@gmail.com wrote: Thanks. I tried this, but it appears cabal-install ignores the Setup.hs file. The only way I could get it to take is if I run 'runhaskell Setup.hs configure' directly. I always assumed cabal-install runs Setup.hs under the hood, but apparently not. Why is this? I believe you must set Build-type: Custom in your cabal file to use user hooks in Setup.hs. I don't fully understand the implications of using Custom, though. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Running tests in Cabal
On Sun, Jul 18, 2010 at 12:23 PM, Magnus Therning mag...@therning.org wrote:
In my Cabal file I have defined a flag that controls whether tests are
built or not. Now I'd like to hook it up a bit more so that './Setup.hs
test' actually runs the tests.
This will allow you to issue 'cabal test' to run the test suite, but
it may introduce other issues. I suspect that this won't work well
with dependencies or language extensions defined in the cabal file --
I'm really not sure, as I haven't actually done this in real code.
I just wanted to see if it would work a few months back.
In the cabal file, set:
Build-type: Custom
Then, set the runTests user hook to the function that invokes your test suite:
Setup.hs:---
#!/usr/bin/env runhaskell
import Distribution.Simple
-- The module with your test function, eg: 'testSuite' (see below)
import Tests
main = do
putStrLn in Main\n
defaultMainWithHooks userHooks
-- I think the @testSuite@ function should have type Args - Bool -
PackageDescription - LocalBuildInfo - IO (), but I'm not 100% sure
of that. (it does take 4 args, which my sample just ignores)
userHooks :: UserHooks
userHooks = simpleUserHooks { runTests=testSuite }
--
Here's my Tests.testSuite fn:
testSuite _ _ _ _ = do
runTestTT $ TestList
[ testSimple1
, testSimple2
]
return ()
You should now be able to issue 'cabal test' to run the testSuite fn
after configuring. I can send the whole sample project if you'd like.
--Rogan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exception: : changeWorkingDirectory: does not exist (No such file or directory)
On Fri, May 21, 2010 at 11:50 AM, Anatoly Yakovenko aeyakove...@gmail.com wrote: anato...@anatolyy-linux ~ $ ghci GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. 1/2 0.5 *** Exception: : changeWorkingDirectory: does not exist (No such file or directory) Can you check the current directory via shell commands from ghci (:! pwd) , or perhaps :cd to another location that you know to exist? --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support
On Wed, Apr 28, 2010 at 1:24 AM, Richard G. richa...@richardg.name wrote: I think that formatted plain-text output would be much better than XML, something that is human-readable and relatively easy to parse via machine. Something similar to the GHC error output would work well because developers are familiar with it. I don't think we need to be limited to a single output format. It's a simple thing to have continuous integration (or cabal) invoke tests with a flag/option to output in a specific format. XML is useful because there are a number of mature tools that already expect xml -- we don't need to reinvent the wheel to get some of the capabilities that developers in other languages are enjoying if our tools use some of the same formats (despite the issues that may exist with those formats..). I like your suggestion for an emacs/dev-readable format, and it can coexist with xml and other snazzier outputs (such as the default format for test-framework, which uses many little tricks to draw and erase progress bars / etc.) --Rogan Test n:Result Location Error message E.g., Test 1:Passed src/Some/File.hs:23 Test 2:Failed src/Some/File.hs:27 Expecting `4'; received `5'. Test 3:Error src/Some/OtherFile.hs:39 Unexpected exception. This would keep the complexity low in Cabal and allow for easy transformation to XML. Richard G. On 10-04-08 8:30 PM, Rogan Creswick wrote: On Thu, Apr 8, 2010 at 5:53 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: I think it's important to be able to convert into standard or custom formats. I've no idea if JUnit XML would make sense as the native format. It's plausible. I hadn't really thought about cabal, itself, being a consumer for test results -- but I like your (Duncan's) points about defining a testing interface, and keeping it extensible. For the record: I don't think junit xml is a good choice for a native format :), but I do think it's a good format to start with simply because there are many tools that can consume it already. --Rogan Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support
On Wed, Apr 28, 2010 at 8:19 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: Yes, it means the testing agent (cabal-install or some other program/system) can do more than simply run all the tests. It means it can enumerate them and not run them (think a GUI or web interface), run a subset of tests, run them in parallel etc. I'm not convinced that this should be cabal's responsibility. I think we would be better served by leaving this up to the test frameworks (indeed, test-framework has test filtering capabilities already). If 'cabal test' simply acts as a thin layer between the user/invoking system and the test framework, then we could pass arguments through to the underlying test binary and perform these tasks using whatever interface that test binary provides. This will buy us more flexibility in the long run. (I think this is at least a good place to start -- and matches my interpretation of Thomas's proposal.) If Cabal takes on these responsibilities, then the testing api will be more constrained -- we won't be able to experiment with new test formats/methodologies as easily, since any tests will have to meet a specific API. While I agree that we need standardization, I think that we should achieve that by using compatible output formats and compatible (user) interfaces (and enforcing those with tests, schema checkers, etc..). I don't see many benefits to baking this functionality into cabal when it could be done separately. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The instability of Haskell libraries
On Fri, Apr 23, 2010 at 12:17 PM, John Goerzen jgoer...@complete.org wrote: Out of those 2023, there are certain libraries where small changes impact a lot of people (say base, time, etc.) I certainly don't expect all 2023 to be held to the same standard as base and time. We certainly need to have room in the community for libraries that change rapidly too. I'd really like to see hackage separated into a couple of separate instances based on general stability. I think it's wonderful that anyone can easily push a new app/library, and have it available to virtually everyone via cabal-install. However, that ability caters to a completely different use case than John's maintenance / production dev. scenario. Something akin to the Debian stable / unstable / testing division would be nice, so that production code can avoid dependencies on packages that are very quickly evolving, and so that those evolving packages have the freedom to move through a series of breaking API changes before settling on the right solution and moving to a more stable package store. --Rogan I'd propose a very rough measuring stick: anything in the platform ought to be carefully considered for introducing incompatibilities. Other commonly-used libraries, such as HaXML and HDBC, perhaps should fit in that criteria as well. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support
On Thu, Apr 8, 2010 at 5:53 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: I think it's important to be able to convert into standard or custom formats. I've no idea if JUnit XML would make sense as the native format. It's plausible. I hadn't really thought about cabal, itself, being a consumer for test results -- but I like your (Duncan's) points about defining a testing interface, and keeping it extensible. For the record: I don't think junit xml is a good choice for a native format :), but I do think it's a good format to start with simply because there are many tools that can consume it already. --Rogan Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support
On Tue, Apr 6, 2010 at 4:03 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: Rather that starting from scratch, you should strongly consider adapting something like test-framework to this task, as it already has done the heavy work of creating a way to combine tests from different frameworks into a single suite I want to second this -- test-framework would be a good place to start, and you would be able to accomplish quite a lot more during the summer. Your proposal addresses (at least!) two different problems: * updating cabal so that it can handle the build/test process; and, * combining HUnit / QuickCheck / etc. to present a uniform interface. test-framework and test-runner both address the second problem, and those solutions can be kept separate, at least for now. Figuring out the best way to specify test commands, dependencies, build/execution order, etc. is going to take some substantial effort, and I think that should be the first goal of the project. More comments in-line below... On Apr 6, 2010, at 3:51 PM, Thomas Tuegel wrote: Package Description File Syntax The syntax for designating test executables in package description files will be based on the existing syntax for describing executables. Such a stanza in the hypothetical package's description file would look like: Test foo-tests main-is: foo-tests.hs build-depends: haskell-foo, Cabal, QuickCheck This example is obviously minimal; this is really an 'Executable' stanza by another name, so any options recognized there would also be valid here. Cabal allows for multiple executable sections -- are multiple test sections allowed? If so, how are they handled when 'cabal test' is invoked? If not, will there be any support for running multiple test suites? (more on this below). While the test executable could be configured to run different sets of tests (at runtime? hm.. we may need more flags to 'cabal test'), there are some situations it's necessary to build multiple test suites because of odd library dependencies. (for example, testing certain combinations of libraries--imagine supporting multiple versions of ghc.) The existing Executable sections may serve the need fine, if we could specify how to run the tests in a different way. Perhaps a list of test commands could be specified instead, eg: TestCommands: foo-test-ghc6.6, foo-test-ghc6.8, foo-props --all Anyhow, just food for thought. described by 'Executable' stanzas. With tests enabled, the test programs will be executed and their results collected by Cabal during the 'test' stage. Where are the results collected, and in what format? My preference is to choose a sensible default (dist/test-results?) and allow it to be overridden in the cabal file. module Distribution.Test where type Name = String type Result = Maybe Bool I think you're reinventing the wheel a bit here, (see comments above about test-framework). That aside, Result is still too restrictive. Ignored tests may well need justification (why were they not run?). There may also be multiple ways to ignore tests, and it isn't clear to me what those are, or which are important. I also feel pretty strongly that Result should distinguish between test failures and tests that failed due to exceptional circumstances. I don't know of any frameworks that do this in Haskell yet, but it has proven to be a useful distinction in other languages. I'm not commenting on the rest of the framework proposal because I don't think the point of this SoC project is to write another testing framework. The 'cabal test' command will run tests by default, but support two other options: 1. '--report [file]', which will produce a nicely formatted report of the test results stored in the named file, or of the last run of the package's test suite if no file is specified, and 2. '--diff file1 file2', which will show the differences between the test results stored it two different files. See my comments about running multiple test suites, and parameterized test suites above. I think richer parameters are necessary. (possibly just a --pass-through flag that hands all the subsequent parameters off to the test executable(s)) --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support
On Tue, Apr 6, 2010 at 5:49 PM, Thomas Tuegel ttue...@gmail.com wrote: Suppose we adopt your suggestion and let test programs be ordinary executables in ordinary 'Executable' sections, and make 'Test' sections that look like: Test foo-1 exe-is: foo options: --enable-bar --disable-baz Test foo-2 exe-is: foo options: --enable-bar --enable-baz Test some-other-test exe-is: some-other-test options: --something-completely-different Now we get named sets of options but don't have to worry about parsing through to find the executable names! It also solves the problem of running test suites with multiple sets of options at runtime. Ah, I like this too, as well as Gregory's suggestion re: Automatic options. --Rogan -- Thomas Tuegel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC: Improving Cabal's Test Support
On Thu, Apr 1, 2010 at 3:52 PM, Thomas Tuegel ttue...@gmail.com wrote: I propose to build a test suite as its own executable, but to avoid the problem of granularity by producing an output file detailing the success or failure of individual tests and any relevant error messages. The format of the file would be standardized through library routines I propose to write; these routines would run tests with HUnit or QuickCheck and process them into a common format. Cabal, or any other utility, could read this file to determine the state of the test suite. Perhaps Cabal could even warn the user about installing packages with failing tests. There are a few frameworks that provide limited degrees of this functionality. I've recently added to test-framework so that the results can be gathered into an xml format that complies with at least some (maybe all?) junit xml parsers. I specifically targeted junit xml so it would be easy to use existing continuous integration systems as-is, but the format is not for haskell tests. It would be nice, for example, to see how many successful quickcheck inputs were run; and the concept of packages and classes had to be munged to work with Haskell modules and test groupings. I need to clean up the code and get it over to Max for review before it'll be widely available, but that's just a matter of finding the time (possibly next week). module Main where import Foo import Test.QuickCheck import Distribution.Test -- This module is part of the project I propose main = runTests [ (testBar, wrap $ testBar), (testBaz, wrap $ testBaz) ] -- (name, test) 'runTests' and 'wrap' would be provided by 'Distribution.Test'. 'wrap' would standardize the output of test routines. For QuickCheck tests, it would probably look like: This is very similar to what test-framework (and other libs.) are doing -- it's well worth looking into them. wrap :: Testable a = a - IO (Bool, String) where the Bool indicates success and the String can be an error message the test produced. 'runTests' would take the list of tests, format their results, and write the output to a file: Keep in mind that there are at least two ways a test can fail -- through errors or false assertions, and it's useful to distinguish between those. As indicated above, I think this bit of the problem has been largely solved -- at the least, there has been a lot of work on designing test frameworks for most languages, and we should be able to take advantage of that here. The test suite would be included in the package description file with a stanza such as: Test main-is: Test.hs build-depends: foo, QuickCheck, Cabal I've been thinking about this as well, and I like this general idea, but I'm not (yet) convinced it's the best. That's probably just because I'm cautious though :) This would take all the same options as an 'Executable' stanza, but would tell Cabal to run this executable when './Setup test' is invoked. This of course requires Cabal to support building executables that depend on the library in the same package. Since version 1.8, Cabal supposedly supports this, but my experiments indicate the support is a little broken. (GHC is invoked with the '-package-id' option, but Cabal only gives it the package name. Fixing this would naturally be on the agenda for this project.) At this point, the package author need only run: $ ./Setup configure $ ./Setup build $ ./Setup test My general feeling has been that Setup is being discouraged in favor of using 'cabal foo', but I don't have any solid evidence for that (and I could very well be wrong!). They do do slightly different things, so I think it's wise to figure out which idiom is most likely to be used and work with that. --Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Cabal dependency hell
On Mon, Mar 8, 2010 at 2:31 PM, Maciej Piechotka uzytkown...@gmail.com wrote: On Mon, 2010-03-08 at 15:37 +0100, Marc Weber wrote: We can't expect package maintainers to test everything. So it must be people like you and me who fixes those changes. Well. Except that it require bumping versions. Which according to hackage policy requires to fork a project (which makes it pointless in the first place) This isn't quite that dire -- I've adopted the following practice when I encounter a cabal dependency issue: (a) identify the problem (eg: observing `cabal install foo` fails) (b) get the source via hackage: `cabal unpack foo` (c) fix the unpacked version, and increment the version number by adding a new level of detail (so, 3.1.0 becomes 3.1.0.1). This version number never leaves my system -- it only exists to keep my cabal/ghc-pkg consistent! (d) if possible, verify that the problem still exists in the project's actual source control (e) email the maintainer, and if possible, including a patch to the current head of the revision control system for the project. So far, it's worked pretty well :) Everyone I've sent patches to has been very responsive and helpful, often pushing updated versions to hackage by the end of the day. The way to go is make hackage allow changing constraints on the fly notifying the author that he can update his repository. You can, at times, do this by forcing constraints via cabal command line flags, or by installing packages with a version specification. $ cabal install foo-1.2.3 will install that specific version of foo. --Rogan This will work in most cases. Bumping versions because a dependency has changed is bad as well. This will cause to much overhead (and it dosen't solve the problem because the old package is still wrong). Specifying dependencies must be decoupled from bumping versions. It's because dep specs do depend on the world which can change.. At least that's what I think. Hmm. When I was returning home I thought about some wiki-like system that would allow to say 'Package X is compatible/not compatible with Y'. Possibly something like: - Only the 'sure' deps are installed in default mode - When in 'expert' mode I can install any package which has not been marked as incompatible Then I can say that I tested built and: - It failed to built - It failed the automatic tests (if they exists)/does not work - It success So if there is versions: 0.7 0.8 0.9 1.0 1.0.1 1.1 1.2 1.3 1.4 And: - 0.8 failed to built - =1.0 1.1 was marked by author - 1.1 was marked as success - 1.3 failed to build Then - In default/normal mode it can be used with 1.0, 1.0.1 and 1.1 - In expert mode 0.9 and 1.2 can be installed in addition to above - Any version can be installed in 'I'm feeling lucky' mode when I explicitly say package to ignore some restriction Possibly it is needed to collect user karma (or possibly already account verification is sufficient). If you're interested in Nix and hack-nix I can show you how everything works using an SSH session. Ekhm... SSH? Marc Weber Regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Notes on migrating from uvector to vector
On Mon, Feb 15, 2010 at 1:35 PM, Don Stewart d...@galois.com wrote:
And I'll take this opportunity to declare that uvector is now in
official maintainance-only mode.
Would it make sense to add a note to that effect to the package
description / cabal file, so it shows up on hackage? ('Stability:
Experimental' seems particularly odd ;)
--Rogan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Video for Linux (v4l) library for Haskell
On Sun, Dec 27, 2009 at 2:17 PM, Christopher Done chrisd...@googlemail.com wrote: Hackage and Google turn up nothing¹, so I am asking here; has anyone written a v4l library for Haskell? I have been reading the v4l documentation² and I am ready to implement a Haskell interface for webcams, but it would be a waste of effort if someone's already got one knocking about. I could hack on theirs! If you end up starting from scratch, I'd suggest looking into Xuggler (http://xuggle.com) as a starting point. I was recently considering V4L for a java project, but I found that Xuggler was better (unfortunately I really can't remember what the definition of better was in that case...). Xuggler uses FFMPEG, which (as far as I could tell..) gave it a lot more capabilities than V4L. I'm no expert, and Xuggle may simply not do what you want, but it's worth a look. --Rogan Cheers! Christopher Done ¹ In fact, the only Google result is a posting to this mailing list asking if there is a v4l library to which the single response is no, write an FFI interface. ² http://pages.cpsc.ucalgary.ca/~sayles/VFL_HowTo/ and http://pages.cpsc.ucalgary.ca/~sayles/VFL_HowTo/Video4LinuxAPI.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re: [Haskell-cafe] Generating Haskell From a XSD
On Wed, Dec 23, 2009 at 1:27 PM, jonathangfisch...@gmail.com wrote: Cool, glad to hear there is interest. I'm talking to a few other people that are expressing interest to. I still don't have access to the haskell wiki, but putting a page up there seems like a start. Any other suggestions for wiki page sites? I'm fond of Google Code. The vcs / wiki / bug-tracker integration is nice. --Rogan -Jonathan On Dec 23, 2009 11:57am, Keith Sheppard keiths...@gmail.com wrote: Yes I'm interested in helping too. It's hard for me to know how much time I'll have but my other side proj is starting to wind down now. Maybe a wiki planning page and a patch-tag (or any other repo site really) workspace is a good starting point? Sent from my iPhone On Dec 23, 2009, at 1:19 PM, Hector Guilarte hector...@gmail.com wrote: I'd like to help... I'm not an expert in Haskell, but I guess I could help somehow... Hector Guilarte -Original Message- From: jonathangfisch...@gmail.com Date: Wed, 23 Dec 2009 18:11:21 To: Keith sheppardkeiths...@gmail.com; jonathangfisch...@gmail.com Cc: haskell-cafe@haskell.org Subject: Re: Re: [Haskell-cafe] Generating Haskell From a XSD ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to fulfill the code-reuse destiny of OOP?
On Thu, Oct 29, 2009 at 6:54 PM, Magicloud Magiclouds
magicloud.magiclo...@gmail.com wrote:
My concern here is about the data member inheriting. In OOP, when I
inherit a class, I also got the members of it. But in haskell, how to
inherit a data?
In my experience (almost entirely with Java), it is usually a bad idea
to inherit from a class in order to reuse data storage that the parent
class provides. Encapsulation (or a decorator, if you prefer) is
often a safer choice. If you really do need to meet the interface
provided by the parent class, while adding functionality (*and* you
can't just implement that interface independently of extending the
parent class), then it's often possible to still use a decorator, and
provide limited visibility accessors to the encapsulated field you
need (say, to pass into some unmodifiable legacy API). When you get
down to it, it's extremely hard to design a full-fledged class so that
extending it actually makes sense, and can be done in a useful and
safe manner. Extending concrete classes also brings along some
non-trivial maintenance headaches as well, since you now need to be
aware of changes to (some of) the non-public APIs when libraries are
upgraded, etc... it's a mess. This is a large part of why the
majority of the concrete classes in the Google Collections library are
final -- the limited benefit of extensibility isn't worth the design
and maintenance.
The point of that whole rant is that extending data-bearing classes
isn't necessarily a good idea, so before trying to find a way to do it
with haskell, it may be better to just encapsulate another data type,
which is trivial:
data InnerThing = A | B | C
data OuterThing = Outer { innerThing :: InnerThing, otherField :: Int }
--Rogan
--
竹密岂妨流水过
山高哪阻野云飞
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announcing: PastePipe -- a CLI for hpaste instances
I'm happy to announce PastePipe (v1.3)! PastePipe reads from stdin and publishes whatever it reads to the hpaste instance of your choice (defaulting to hpaste.org). This makes it trivial to. * post a file to hpaste.org: `cat file | pastepipe' * turn a terminal into a pastebin window: 'pastepipe' (ctrl-d to close send) * upload error output as a paste: 'faultyProgram | pastepipe -t faultyProgram error output -l bash' * paste to a local hpaste instance: 'pastepipe --uri http://my.local.hpaste/fastcgi/hpaste.fgci/' * add a title, select different languages, specify a user name, etc... see pastepipe --help for details. PastePipe will output the resulting url for your new paste to stdout, so you can script it, or just copy / paste that as you need. Availability: --- It is available on Hackage (so you can 'cabal install PastePipe'): http://hackage.haskell.org/package/PastePipe The project for pastepipe is hosted at Google Code, with the source in mercurial: Homepage (issue tracker, etc): http://code.google.com/p/pastepipe/ Mercurial repo: hg clone https://pastepipe.googlecode.com/hg/ pastepipe --- Please let me know of any bugs / feature requests / etc. (or just post them to the issue tracker.) Thanks! Rogan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
