Profile cover photo
Profile photo
Mikhail Glushenkov
Student, Haskell programmer.
Student, Haskell programmer.
About
Mikhail's interests
View all
Mikhail's posts

Post has attachment

Post has attachment

"Generally, denotational semantics gets into a somewhat hairy world of comparative linguistics since ultimately the domain of your denotation can usually be thought of as not much more than a "nicer" language than the one who's syntax you're studying." - tel@reddit, https://www.reddit.com/r/haskell/comments/2qvbhp/denotational_design_does_not_work/cnaawmv

Post has attachment
Thanks to GHCJS developers, Cabal is getting some new features to better support compilers that target JavaScript. If you maintain such a compiler, you may want to leave a comment in this thread: http://thread.gmane.org/gmane.comp.lang.haskell.cabal.devel/10020

Gmail tip of the day: Settings > General > Default reply behaviour > Reply all.

Post has attachment

Post has attachment
Possible lessons for Hackage here?

Post has attachment
cabal-install now has a '--require-sandbox' option that makes all sandbox-aware commands ('install'/'build'/etc.) exit with error if there is no sandbox present. This makes it harder to accidentally modify the user package database by e.g. forgetting to initialise a sandbox and then using 'cabal install' on a project with many dependencies. The option can be turned on via the per-user configuration file ('~/.cabal/config') or the per-project one ('$PROJECT_DIR/cabal.config'). Use '--no-require-sandbox' if you want to override the config setting temporarily.

Post has attachment
I've implemented a new option '--allow-newer' for 'cabal install' / 'cabal configure' that allows to relax upper bounds in dependencies without editing the package description.

In plain English: if you want to install a package A that depends on B >= 1.0 && < 2.0, but you have the version 2.0 of B installed, you can now compile A against B 2.0 by using 'cabal install --allow-newer=B A'. This works for the whole package index: if A also depends on C that in turn depends on B < 2.0, C's dependency on B will be also relaxed.

Example:

    $ cd foo
    $ cabal configure
    Resolving dependencies...
    cabal: Could not resolve dependencies:
    [...]

    $ cabal configure --allow-newer
    Resolving dependencies...
    Configuring foo...

Additional examples:

    # Relax upper bounds in all dependencies.
    $ cabal install --allow-newer foo

    # Relax upper bounds only in dependencies on bar, baz and quux.
    $ cabal install --allow-newer=bar,baz,quux foo

    # Relax the upper bound on bar and force bar==2.1.
    $ cabal install --allow-newer=bar --constraint="bar==2.1" foo

It's also possible to enable '--allow-newer' permanently by setting 'allow-newer: True' in the '~/.cabal/config' file.

Hopefully, this feature will alleviate at least some of the problems people have been having with strict upper bounds on Hackage.

Post has shared content
Cabal 1.18.0 is out: https://groups.google.com/forum/#!topic/haskell-cafe/SFoNwaq8wdc

Here's the typical workflow we expect people to use with this cabal release. First you create the sandbox and install all dependencies:

    cd my-pkg
    cabal sandbox init  # only once
    cabal install --only-dependencies --enable-tests

While installing dependencies take a while, it only needs to be done once (unless you add dependencies). If you put

    jobs: $ncpus

in your ~/.cabal/config file, all builds will be done in parallel, speeding up dependency installation.

For your day-to-day development you run either `cabal build` or `cabal test` (both now imply `cabal configure`).

    cabal build  # or:
    cabal test

If you need to e.g. debug a function, you can play with it from within GHCi:

    cabal repl

`cabal repl` automatically passes the right flags to ghci and also re-runs any preprocessors (e.g. hsc2hs) so you don't have to do that manually. We're still working on making `cabal repl` better, but even the first version should be a big improvement to what we had before.

Note how we're trying to move away from global (or user) installs of packages. There are still use cases for that, but by default we try to keep each project's dependencies separate (by using a sandbox). For a bit more on the philosophy behind the development behind the current UI read my blog post:

http://blog.johantibell.com/2012/03/cabal-of-my-dreams.html
Wait while more posts are being loaded