September 2016 - Haskell-Cafe

Looking for a source level debugger
by Nikita Karetnikov 17 Sep '16

17 Sep '16

Originally sent this to /r/haskell, but it doesn't show up there for some reason, so re-sending here. Is anyone aware of a source level debugger that can be used with GHC? That is, something integrated into an editor (as a plugin, perhaps) that can highlight the line being executed, show locals, etc. (Think of WinDbg without the registers window.) I'm mostly interested in something that can work on a Linux-based system, but solutions for other platforms are welcome, too! I've heard that Sublime can run on 3 OSes, is there a solution for it, for instance? P.S. I'm not looking for opinions on whether you think a debugger is necessary or not when programming in Haskell.

3 2

ANN: stack-1.2.0
by Emanuel Borsboom 17 Sep '16

17 Sep '16

See https://haskellstack.org for installation and upgrade instructions. Release notes: * On many Un*x systems, Stack can now be installed with a simple one-liner: wget -qO- https://get.haskellstack.org/ | sh * The fix for [#2175](https://github.com/commercialhaskell/stack/issues/2175) entails that stack must perform a full clone of a large Git repo of Hackage meta-information. The total download size is about 200 MB. Please be aware of this when upgrading your stack installation. * If you use Mac OS X, you may want to delay upgrading to macOS Sierra as there are reports of GHC panics when building some packages (including Stack itself). See [#2577]( https://github.com/commercialhaskell/stack/issues/2577) * This version of Stack does not build on ARM or PowerPC systems (see [store#37](https://github.com/fpco/store/issues/37)) Please stay with version 1.1.2 for now on those architectures. This will be rectified soon! * We are now releasing a [statically linked Stack binary for 64-bit Linux]( https://www.stackage.org/stack/linux-x86_64-static) Please try it and let us know if you run into any trouble on your platform. * We are planning some changes to our Linux releases, including dropping our Ubuntu, Debian, CentOS, and Fedora package repositories and switching to statically linked binaries. We would value your feedback in [#2534](https://github.com/commercialhaskell/stack/issues/2534). Major changes: * Add `stack hoogle` command. [#55](https://github.com/commercialhaskell/stack/issues/55) * Support for absolute file path in `url` field of `setup-info` or `--ghc-bindist` * Add support for rendering GHCi scripts targeting different GHCi like applications [#2457](https://github.com/commercialhaskell/stack/pull/2457) Behavior changes: * Remove `stack ide start` and `stack ide load-targets` commands. [#2178](https://github.com/commercialhaskell/stack/issues/2178) * Support .buildinfo files in `stack ghci`. [#2242](https://github.com/commercialhaskell/stack/pull/2242) * Support -ferror-spans syntax in GHC error messages. * Avoid unpacking ghc to `/tmp` [#996](https://github.com/commercialhaskell/stack/issues/996) * The Linux `gmp4` GHC bindist is no longer considered a full-fledged GHC variant and can no longer be specified using the `ghc-variant` option, and instead is treated more like a slightly different platform. Other enhancements: * Use the `store` package for binary serialization of most caches. * Only require minor version match for Docker stack exe. This way, we can make patch releases for version bounds and similar build issues without needing to upload new binaries for Docker. * Stack/Nix: Passes the right ghc derivation as an argument to the `shell.nix` when a custom `shell.nix` is used See [#2243](https://github.com/commercialhaskell/stack/issues/2243) * Stack/Nix: Sets `LD_LIBRARY_PATH` so packages using C libs for Template Haskell can work (See _e.g._ [this HaskellR issue]( https://github.com/tweag/HaskellR/issues/253)) * Parse CLI arguments and configuration files into less permissive types, improving error messages for bad inputs. [#2267](https://github.com/commercialhaskell/stack/issues/2267) * Add the ability to explictly specify a gcc executable. [#593](https://github.com/commercialhaskell/stack/issues/593) * Nix: No longer uses LTS mirroring in nixpkgs. Gives to nix-shell a derivation like `haskell.compiler.ghc801` See [#2259](https://github.com/commercialhaskell/stack/issues/2259) * Perform some subprocesses during setup concurrently, slightly speeding up most commands. [#2346](https://github.com/commercialhaskell/stack/pull/2346) * `stack setup` no longer unpacks to the system temp dir on posix systems. [#996](https://github.com/commercialhaskell/stack/issues/996) * `stack setup` detects libtinfo6 and ncurses6 and can download alternate GHC bindists [#257](https://github.com/commercialhaskell/stack/issues/257) [#2302](https://github.com/commercialhaskell/stack/issues/2302). * `stack setup` detects Linux ARMv7 downloads appropriate GHC bindist [#2103](https://github.com/commercialhaskell/stack/issues/2103) * Custom `stack` binaries list dependency versions in output for `--version`. See [#2222](https://github.com/commercialhaskell/stack/issues/2222) and [#2450](https://github.com/commercialhaskell/stack/issues/2450). * Use a pretty printer to output dependency resolution errors. [#1912](https://github.com/commercialhaskell/stack/issues/1912) * Remove the `--os` flag [#2227](https://github.com/commercialhaskell/stack/issues/2227) * Add 'netbase' and 'ca-certificates' as dependency for .deb packages. [#2293](https://github.com/commercialhaskell/stack/issues/2293). * Add `stack ide targets` command. * Enhance debug logging with subprocess timings. * Pretty-print YAML parse errors [#2374](https://github.com/commercialhaskell/stack/issues/2374) * Clarify confusing `stack setup` output [#2314](https://github.com/commercialhaskell/stack/issues/2314) * Delete `Stack.Types` multimodule to improve build times [#2405](https://github.com/commercialhaskell/stack/issues/2405) * Remove spurious newlines in build logs [#2418](https://github.com/commercialhaskell/stack/issues/2418) * Interpreter: Provide a way to hide implicit packages [#1208](https://github.com/commercialhaskell/stack/issues/1208) * Check executability in exec lookup [#2489](https://github.com/commercialhaskell/stack/issues/2489) Bug fixes: * Fix cabal warning about use of a deprecated cabal flag [#2350](https://github.com/commercialhaskell/stack/issues/2350) * Support most executable extensions on Windows [#2225](https://github.com/commercialhaskell/stack/issues/2225) * Detect resolver change in `stack solver` [#2252](https://github.com/commercialhaskell/stack/issues/2252) * Fix a bug in docker image creation where the wrong base image was selected [#2376](https://github.com/commercialhaskell/stack/issues/2376) * Ignore special entries when unpacking tarballs [#2361](https://github.com/commercialhaskell/stack/issues/2361) * Fixes src directory pollution of `style.css` and `highlight.js` with GHC 8's haddock [#2429](https://github.com/commercialhaskell/stack/issues/2429) * Handle filepaths with spaces in `stack ghci` [#2266](https://github.com/commercialhaskell/stack/issues/2266) * Apply ghc-options to snapshot packages [#2289](https://github.com/commercialhaskell/stack/issues/2289) * stack sdist: Fix timestamp in tarball [#2394](https://github.com/commercialhaskell/stack/pull/2394) * Allow global Stack arguments with a script [#2316](https://github.com/commercialhaskell/stack/issues/2316) * Inconsistency between ToJSON and FromJSON instances of PackageLocation [#2412](https://github.com/commercialhaskell/stack/pull/2412) * Perform Unicode normalization on filepaths [#1810](https://github.com/commercialhaskell/stack/issues/1810) * Solver: always keep ghc wired-in as hard constraints [#2453](https://github.com/commercialhaskell/stack/issues/2453) * Support OpenBSD's tar where possible, require GNU tar for xz support [#2283](https://github.com/commercialhaskell/stack/issues/2283) * Fix using --coverage with Cabal-1.24 [#2424](https://github.com/commercialhaskell/stack/issues/2424) * When marking exe installed, remove old version [#2373](https://github.com/commercialhaskell/stack/issues/2373) * Stop truncating all-cabal-hashes git repo [#2175](https://github.com/commercialhaskell/stack/issues/2175) * Handle non-ASCII filenames on Windows [#2491](https://github.com/commercialhaskell/stack/issues/2491) * Avoid using multiple versions of a package in script interpreter by passing package-id to ghc/runghc [#1957](https://github.com/commercialhaskell/stack/issues/1957) * Only pre-load compiler version when using nix integration [#2459](https://github.com/commercialhaskell/stack/issues/2459) * Solver: parse cabal errors also on Windows [#2502](https://github.com/commercialhaskell/stack/issues/2502) * Allow exec and ghci commands in interpreter mode. Scripts can now automatically open in the repl by using `exec ghci` instead of `runghc` in the shebang command. [#2510](https://github.com/commercialhaskell/stack/issues/2510) * Now consider a package to be dirty when an extra-source-file is changed. See [#2040](https://github.com/commercialhaskell/stack/issues/2040) Thanks to all our contributors for this release: * Aaron Friel * Andrew Cowie * AndrewRademacher * Anton Felix Lorenzen * Brian McKenna * Chris Done * Dan Aloni * danald * Daniel Casanueva * Denis * Denis Kasak * Emanuel Borsboom * erewok * Gabor Greif * Gurkenglas * Harendra Kumar * hesiod * Judah Jacobson * Khan Thompson * Mathieu Boespflug * Michael Sloan * Michael Snoyman * Mohit Agarwal * Moritz Angermann * Oleg Grenrus * Paolo G. Giarrusso * Philipp Kant * Ryan Desfosses * Sid Kapur * Sidharth Kapur * Simon Jakobi * Tim Dysinger * Tim Düsterhus * Tobias Markus * YPares * Yuriy Syrovetskiy * Yves Parès (Ywen) * ___

2 2

Re: [Haskell-cafe] Standard package file format
by Chris Kahn 17 Sep '16

17 Sep '16

I would like to second this thought. Using Haskell for package descriptions needs to be thought out and executed with great care and attention. It's really easy to go off the rails. Scala's build system lets you do very powerful things, but it also makes things unnecessarily complicated and mystifying for beginners. At my previous work where we used Scala extensively, there were many times where the team simply resorted to external tools because figuring out how to make some seemingly trivial change to an SBT module was too time consuming. On September 16, 2016 8:39:15 AM EDT, David McBride <toad3k(a)gmail.com> wrote: > While I would personally love having a package description in haskell, > I don't think it is a good idea. > > If you can't start or modify a package without already knowing > haskell, it is a huge barrier to entry. I remember trying to get > started in scala and having a lot of trouble with sbt because I didn't > know their operators for lists and arrays or hash tables or whatever > it is that they use in their files. > > On Fri, Sep 16, 2016 at 4:57 AM, yogsototh > <yann.esposito(a)gmail.com> wrote: >> >>> I guess the overriding question I have here is: what is the PROBLEM >>> being solved? >> >> Let me share my experience with Clojure and lein. They use a clojure >> hash-map for their configuration. So yes arbitrary code could be >> executed and I believe this is a _very good thing_. >> >> Why? Because it makes it very easy to add sub-configuration that can >> be used by third party plugin. For example: >> >> - a plugin that help the use of environment variables (lein-environ) >> which is really helpful for application development (not so much >> for library development) >> - a plugin that use S3 for our private dependencies (not supported by >> default by lein) >> >> >> For deployment: we were able to add request to our API server that >> provide not only the written version but also the git commit hash. So >> we could be certain of the version of the server. Too much time there >> were sys/admin deployment errors. And that could only be achieved >> because we were able to run arbitrary command in the project >> description file. >> >> I certainly forget many other advantages of having a package >> description format which is simply a data structure in the hosted >> language. But this has by far my preference. >> >> - cabal is ok, but very imperfect, I generally need to have a lot of >> copy/paste, I need to change it very often while writing >> application with many dependencies >> - JSON/YAML/TOML are simply not powerful enough to match all >> semantics we might need to configure a project. For example we >> might want to have Set instead of List for some properties. Or I >> don't know maybe ternary tree structures. >> >> The point is: we pay a price by adding a step between the semantic >> and the syntax. >> While if our configuration format was in Haskell we could express the >> semantic more directly. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. >

8 8

Issue with building executables using Cabal on Travis
by Geraldus 17 Sep '16

17 Sep '16

Hi Café! Recently we added an executable section to our Transient-Universe package and now Travis cabal builds always failing. The error message is: In-place registering transient-universe-0.3.4... Preprocessing executable 'monitorService' for transient-universe-0.3.4... [1 of 1] Compiling Main ( src/server/Transient/Monitor/Services/MonitorService.hs, dist/build/monitorService/monitorService-tmp/Main.o ) Linking dist/build/monitorService/monitorService ... No errors or warnings could be found in the package. Re-configuring with test suites enabled. If this fails, please run configure manually. Resolving dependencies... Configuring transient-universe-0.3.4... Package has no buildable test suites. Building source dist for transient-universe-0.3.4... Preprocessing library transient-universe-0.3.4... Preprocessing executable 'monitorService' for transient-universe-0.3.4... cabal: src/client/Transient/Move/Services/MonitorService.hs: does not exist Installing library in /home/travis/.cabal/lib/x86_64-linux-ghc-7.10.2/transient-universe-0.3.4-2OztnD6ZM7W2H3eixltaJX Installing executable(s) in /home/travis/.cabal/bin Warning: The directory /home/travis/.cabal/bin is not in the system search path. cabal: The file does not exist 'transient-universe-0.3.4.tar.gz'. (Full log — https://travis-ci.org/agocorona/transient-universe/jobs/160441018, you can see that other Cabal builds fail with same error, however all Stack builds are fine). This is a chunk of cabal file: extra-source-files: src/client/Transient/Move/Services/MonitorService.hs src/server/Transient/Move/Services/MonitorService.hs executable monitorService build-depends: base >4 && <5 if !impl(ghcjs >=0.1) hs-source-dirs: src/server/Transient/Monitor/Services build-depends: transformers , transient >=0.4.4 , transient-universe else hs-source-dirs: src/client/Transient/Monitor/Services main-is: MonitorService.hs default-language: Haskell2010 ghc-options: -threaded -rtsopts Have anyone faced similar issue?

2 2

Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10
by Phyx 17 Sep '16

17 Sep '16

> Is anybody else experiencing really slow compilations with GHC 7.10.2 on > Windows 10? The problem comes down to these lines https://github.com/ghc/ghc/blob/e5ecb2010514405ac1b9b1285a8a65c00a5fd4e0/li… The issue is that the entire Windows support in GHC Is mostly provided through POSIX support. Windows however isn't a POSIX system, and these APIs were implemented for compatibility and not performance. This is the reason why any I/O operation on GHC Windows will be significantly slower. This is the same reason why Console I/O is also much slower. Why Unicode support is a bit wonky etc. GHC Is currently just not using native Windows syscalls, because by large most developers of GHC don't use Windows. There are other issues (but I won't go in detail on the user list). We are trying to fix this, there are multiple tickets open such as https://ghc.haskell.org/trac/ghc/ticket/11394 but it's a big task and there are very limited resources so priority is given to things currently broken rather than just slow.

1 0

Very _very_ slow compiles on Windows 10
by Nicu Ionita 17 Sep '16

17 Sep '16

Is anybody else experiencing really slow compilations with GHC 7.10.2 on Windows 10? I use stack to compile the project and run it under a mingw64 environment provided by Github bash. The CPU usage is very low all the time (meaning: GHC does barely use the CPU). On same computer with Ubuntu 16.04 it just compiles normally, but under Windows it is for sure 10x slower, maybe even more. Nicu

3 3

Re: [Haskell-cafe] [Haskell-community] Standard package file format
by Paolo Giarrusso 16 Sep '16

16 Sep '16

On 16 September 2016 at 12:13, Patrick Pelletier <ppelleti(a)funwithsoftware.org> wrote: > On 9/16/16 2:36 AM, Paolo Giarrusso wrote: >> >> (Resending from right address) >> >> We're talking about *three* options: >> 1. syntax for pure Haskell values, which I'll call HSON (Haskell >> jSON). That's just an alternative to YAML/TOML/... That would need >> extensions to allow omitting optional fields entirely. >> 2. a pure Haskell embedded domain-specific language (EDSL) that simply >> generates cabal description records (GenericPackageDescription >> values). That would allow abstraction over some patterns but not much >> more. But that alone is already an argument for EDSLs—the one Harendra >> already presented. >> 3. a Haskell embedded domain-specific language (EDSL) designed for an >> extensible build tool, like Clojure's (apparently), SBT for Scala or >> many others. That would potentially be a rabbit hole leading to a >> rather *different* tool—with a different package format to boot. That >> can't work as long as all libraries have to be built using the same >> tool. But stack and cabal are really about how to manage package >> databases/GHC/external environments, while extensible build tools are >> about (a more powerful form) of writing custom setup scripts. I >> suspect some extensions might be easier if more of the actual building >> was done by the setup script, but I'm not sure. > > > Options 2 and 3 both require running Haskell code at build time. > But if all packages had to use the new EDSL, then cross-compilation would essentially become impossible. "All packages migrate to new format" doesn't seem really a plausible option, as I already hinted in the text you quote. There are multiple JVM build tools because they're interoperable (like cabal-install and Stack): each library picks its own build tool, but they can still be linked together. Hpack generates cabal files, stack reuses cabal or hpack files. In principle, option 2 just needs a non-cross-compiled program to produce a package description—say by producing a cabal file. You just need to runghc it, either via ghci or by compiling and running a binary. Option 3 can be trickier depending on details, but the as long as you account for cross-compilation in the design it should be doable. For Template Haskell the problem is deeper (see http://blog.ezyang.com/2016/07/what-template-haskell-gets-wrong-and-racket-…) so let's *not* use it here. -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

2 3

[Haskell-community] Standard package file format
by Paolo Giarrusso 16 Sep '16

16 Sep '16

(Resending from right address) We're talking about *three* options: 1. syntax for pure Haskell values, which I'll call HSON (Haskell jSON). That's just an alternative to YAML/TOML/... That would need extensions to allow omitting optional fields entirely. 2. a pure Haskell embedded domain-specific language (EDSL) that simply generates cabal description records (GenericPackageDescription values). That would allow abstraction over some patterns but not much more. But that alone is already an argument for EDSLs—the one Harendra already presented. 3. a Haskell embedded domain-specific language (EDSL) designed for an extensible build tool, like Clojure's (apparently), SBT for Scala or many others. That would potentially be a rabbit hole leading to a rather *different* tool—with a different package format to boot. That can't work as long as all libraries have to be built using the same tool. But stack and cabal are really about how to manage package databases/GHC/external environments, while extensible build tools are about (a more powerful form) of writing custom setup scripts. I suspect some extensions might be easier if more of the actual building was done by the setup script, but I'm not sure. On 16 September 2016 at 10:57, yogsototh <yann.esposito(a)gmail.com> wrote: > >> I guess the overriding question I have here is: what is the PROBLEM being >> solved? > > > Let me share my experience with Clojure and lein. They use a clojure > hash-map for their configuration. So yes arbitrary code could be executed > and I believe this is a _very good thing_. > > Why? Because it makes it very easy to add sub-configuration that can be used > by third party plugin. For example: > > - a plugin that help the use of environment variables (lein-environ) which > is really helpful for application development (not so much for library > development) > - a plugin that use S3 for our private dependencies (not supported by > default by lein) > > > For deployment: we were able to add request to our API server that provide > not only the written version but also the git commit hash. So we could be > certain of the version of the server. Too much time there were sys/admin > deployment errors. And that could only be achieved because we were able to > run arbitrary command in the project description file. > > I certainly forget many other advantages of having a package description > format which is simply a data structure in the hosted language. But this has > by far my preference. > > - cabal is ok, but very imperfect, I generally need to have a lot of > copy/paste, I need to change it very often while writing application with > many dependencies > - JSON/YAML/TOML are simply not powerful enough to match all semantics we > might need to configure a project. For example we might want to have Set > instead of List for some properties. Or I don't know maybe ternary tree > structures. > > The point is: we pay a price by adding a step between the semantic and the > syntax. > While if our configuration format was in Haskell we could express the > semantic more directly. > > _______________________________________________ > Haskell-community mailing list > Haskell-community(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community > -- Paolo G. Giarrusso - Ph.D. Student, Tübingen University http://ps.informatik.uni-tuebingen.de/team/giarrusso/

2 1

Porting Haskell/C on Windows
by Harendra Kumar 15 Sep '16

15 Sep '16

Hi, When porting a package with C source in it which C compilers should it be portable to? Can we just assume gcc (MinGW) or are there any other compilers as well that work with ghc? -harendra

1 0

Data constructor ‘Minus’ comes from an un-promotable type ‘Ints’
by Nicholls, Mark 15 Sep '16

15 Sep '16

Hello, I clearly don’t really know what I’m doing…but at least I know it…. Here we defined the Naturals…and then attempt to construct the Integers…. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P naturals > data Nat where > Z :: Nat > S :: Nat -> Nat I can now define + and * and prove things about them…1 * x == x etc….nice..but lets put that on one side. Borrow bits and bobs from singletons > data family Sing (a :: k) Borrow bits and bobs from singletons..i.e. the isomorphic values…my proofs in nat now map to SNat…double nice. > type SNat = (Sing :: Nat -> *) Create the integers by following my nose……(the integers are the equivalence class of pairs of naturals….) i.e. we have “positive” or “negative” or “zero”… > data Ints (a :: Nat) (b :: Nat) where > Minus :: SNat a -> Ints 'Z a > Zero :: Ints 'Z 'Z > Plus :: SNat a -> Ints a 'Z > Ok….this works as a set of values….but…. I can’t prove anything about these because the data constructors for my integers aren’t “promotable”…..so I cant do the same trick I did with Nat. “:k Zero” ….. Data constructor ‘Zero’ comes from an un-promotable type ‘Ints’ In a type in a GHCi command: Zero I’ve tried rejigging this in various futile and ignorant manners….but the bottom line is its…”un-promotable”…..look at the docs, and it says something vague about GADT’s…but that isnt the problem directly. Is there a nifty way around this log jam? (I can start proving things about ‘(Nat,Nat)….but this will soon become a bit clumsy….) Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-café (which appears to be a very nice place somewhere in finland….hmmmm…I think that’s something different). (I’ve already allegedly descended into cabal hell following my nose with an agda install… setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is version 1.19). computer science would be good, if it wasn’t for the computers. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT.

5 11