- Haskell-Cafe - Haskell.org

Hiding platform packages in Cabal sandboxes
by Sven Panne 15 Oct '14

15 Oct '14

As a maintainer of the various OpenGL-related packages I have the following problem: The Haskell platform has those packages (OpenGLRaw, GLURaw, ...) exposed, which is the right thing to do in general. When I want to work on those packages, I'd like to use Cabal sandboxes to avoid screwing up the platform versions of them, but things get a bit tricky then. Consider e.g. the GLURaw package, which depends on the OpenGLRaw package. Assume that I'd like to add some stuff to the OpenGLRaw package and use that in GLURaw. With cabal sandboxes I'll have to fight a little bit, because versions of these packages are already exposed: ----------------------------------------------------------------------------------------------------------------------- svenpanne@svenpanne[master]:~/repos/haskell-packages/GLURaw$ cabal sandbox init Writing a default package environment file to /usr/local/google/home/svenpanne/repos/haskell-packages/GLURaw/cabal.sandbox.config Creating a new sandbox at /usr/local/google/home/svenpanne/repos/haskell-packages/GLURaw/.cabal-sandbox svenpanne@svenpanne[master]:~/repos/haskell-packages/GLURaw$ cabal sandbox add-source ../OpenGLRaw ----------------------------------------------------------------------------------------------------------------------- No problem so far. But the next step is not so OK: ----------------------------------------------------------------------------------------------------------------------- svenpanne@svenpanne[master]:~/repos/haskell-packages/GLURaw$ cabal install --only-dependencies Resolving dependencies... All the requested packages are already installed: Use --reinstall if you want to reinstall anyway. ----------------------------------------------------------------------------------------------------------------------- Hmmm, obviously cabal sees the globally exposed OpenGLRaw and ignores that I've done add-source above. OK, next try with --constraint added: ----------------------------------------------------------------------------------------------------------------------- svenpanne@svenpanne[master]:~/repos/haskell-packages/GLURaw$ cabal install --only-dependencies --constraint='OpenGLRaw source' Resolving dependencies... In order, the following would be installed: OpenGLRaw-1.5.0.0 (reinstall) cabal: The following packages are likely to be broken by the reinstalls: OpenGL-2.9.2.0 GLUT-2.5.1.1 GLURaw-1.4.0.1 Use --force-reinstalls if you want to install anyway. ----------------------------------------------------------------------------------------------------------------------- (Is there any documentation about --constraint? I figured that out by actually reading the cabal sources. :-/ ) Better, but still not OK, so let's add --force-reinstalls: ----------------------------------------------------------------------------------------------------------------------- svenpanne@svenpanne[master]:~/repos/haskell-packages/GLURaw$ cabal install --only-dependencies --constraint='OpenGLRaw source' --force-reinstalls Resolving dependencies... Warning: The following packages are likely to be broken by the reinstalls: OpenGL-2.9.2.0 GLUT-2.5.1.1 GLURaw-1.4.0.1 Continuing even though the plan contains dangerous reinstalls. Notice: installing into a sandbox located at /usr/local/google/home/svenpanne/repos/haskell-packages/GLURaw/.cabal-sandbox Configuring OpenGLRaw-1.5.0.0... Building OpenGLRaw-1.5.0.0... Installed OpenGLRaw-1.5.0.0 ----------------------------------------------------------------------------------------------------------------------- That works, so after that I could actually build/install GLURaw. So in a nutshell what I have to do is: cabal sandbox init cabal sandbox add-source ../OpenGLRaw cabal install --constraint='OpenGLRaw source' --force-reinstalls --enable-documentation --haddock-hyperlink-source And for other packages I even have to add several --constraint flags, because they depend on several locally modified packages. This seems a bit weird. Is this the recommended workflow? How do other maintainers of platform packages handle this? What one *actually* wants is hiding some of the globally exposed packages while being in the sandbox (--constraint and --force-reinstalls could go away then), but I've found no way to do that. Cheers, S.

5 4

Deriving vs. type constructors
by Michael Sperber 15 Oct '14

15 Oct '14

I'm struggling with a problem related to generic programming, boiling down to this: ----snip---- {-# LANGUAGE StandaloneDeriving, KindSignatures, UndecidableInstances #-} data Foo (v :: * -> *) = Foo (v Bar) deriving instance (Show (v Bar)) => Show (Foo v) data Bar = Bar deriving Show ----snip---- So the Show instance for Foo v wants the rather specific Show instance for v Bar. But now imagine that v is always something like Maybe, itself done using something like this presumably: instance Show a => Show (Maybe a) where ... Can I somehow state as a constraint that Foo v has a Show instance if v is a type constructor like Maybe, i.e. once with a Show instances for any arguments that has a Show instance? (You can't see *why* I want to do this in this example - I actually have something like 100 nested datatypes which thread v through, and *every single one of them* adds to the context I need for every one of them.) I feel I want to write something like this: deriving instance (Show a => Show (v a)) => Show (Foo v) Is there a way to do this? Help would be much appreciated! -- Regards, Mike

3 3

Missing or undocumented ARM architecture controls
by Jon Schneider 15 Oct '14

15 Oct '14

I worked around a problem of a build of a simple cross ghc not finding (shared) libraries by setting the LIBRARY_PATH environment variable. Not ideal. Then I came to a problem with StcCRun.c using vldmia and related instructions which are part of ARMv6. I worked around this by putting #defines for arm_HOST_ARCH_PRE_ARMv6 and arm_HOST_ARCH_PRE_ARMv7 in mk/config.h Now it seems to make use of llvm at a later stage and that fails with "inplace/bin/ghc-stage1" -static -H64m -O0 -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/Exception.cmm -o rts/dist/build/Exception.o '+v7' is not a recognized feature for this target (ignoring feature) UNREACHABLE executed! UNREACHABLE executed! Stack dump: 0. Program arguments: /usr/bin/llc -O3 -relocation-model=static /tmp/ghc20998_0/ghc20998_4.bc -o /tmp/ghc20998_0/ghc20998_5.lm_s --enable-tbaa=true -mattr=+v7,+vfp3 1. Running pass 'Function Pass Manager' on module '/tmp/ghc20998_0/ghc20998_4.bc'. 2. Running pass 'ARM Instruction Selection' on function '@stg_unmaskAsyncExceptionszh_ret_info' Now the thing that sticks out there is the +v7,+vfp3 option. Again it seems to be making incorrect assumptions about the exact ARM architecture. Ours is a v5TE/926. What is the correct way to specify this ? Thanks, Jon

2 1

Building cross compiler fails
by Jon Schneider 15 Oct '14

15 Oct '14

I am after a ghc cross compiler. I have been cross compiling stuff for years and also built cross-compiling gcc from time to time but am having trouble building a cross-compiling ghc. I have read https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation and associated pages. In the ghc-7.8.3 directory I do ./configure --target=arm-linux-gnueabi -with-gcc=arm-linux-gnueabi-gcc but make eventually fails (in stage 1) configure: error: in `/home/jon/build/ghc-7.8.3/libraries/terminfo': configure:3386: arm-linux-gnueabi-gcc -o conftest -fno-stack-protector conftest.c -lncurses >&5 /usr/lib/gcc/arm-linux-gnueabi/4.6/../../../../arm-linux-gnueabi/bin/ld: cannot find -lncurses Firstly the requirement for termcap is surely unnecessary. We don't need it as the target will just be processing data. We do have an libncurses kicking about and I know _exactly_ what -L option to pass to (in this case) arm-linux-gnueabi-gcc to make this work but where to specify it to ghc's build system escapes me. I have tried setting CFLAGS, LDFLAGS, CONF_GCC_LINKER_OPTS_STAGE1 the configure commandline and also mk/build.mk . >From searching it is clear this has tripped people up time and time again and that there is something missing from the documentation. So in summary please could https://ghc.haskell.org/trac/ghc/wiki/CrossCompilation be updated to show where to specify the CFLAGS and LDFLAGS that should accompany the compiler specified with -with-gcc (or derived from --target). Also more generally could the build documentation show how to omit frills like curses and termcap if at all possible. Jon

2 1

Optimizing Haskell games with minimal changes.
by Ivan Perez 15 Oct '14

15 Oct '14

Hi Café, As you know, we are building Android games in Haskell, and efficiency is crucial. I often find myself trying to explain to other game programmers that the price to be paid in speed in exchange for the robustness and the clarity of the language is minimal; and that optimising and parallelising can be very easy. In our game we only had to apply very basic techniques (RWH, Chapter 25; Parallel & Concurrent Haskell, Chapter 2) to obtain a x7 speedup and reduce memory consumption from hundreds to 3MB on desktop. The number of changes to the codebase was minimal. I hope it helps support the case that using Haskell even for CPU demanding code is worth it. Our game now also runs smoothly on Android. Hopefully this will also help others trying to achieve the same thing. http://keera.co.uk/blog/2014/10/15/from-60-fps-to-500/ Cheers Ivan -- Facebook: https://www.facebook.com/keerastudios Twitter: https://twitter.com/KeeraStudios Web: http://www.keera.co.uk

1 0

foreign libraries, dylibs, OS X Mavericks and GHC 7.8.3 woes
by Alfredo Di Napoli 15 Oct '14

15 Oct '14

Hello Cafe, I will let this gist talk for me: https://gist.github.com/adinapoli/d4c33a9d1ea85bcaebdf Even though there is a solution, it seems extremely unsatisfying having to specify such paths manually. I always had very good experiences with FFI, OS X and GHC in the past, so this strikes me as a surprise. I have read a bit here and there about GHC 7.8.3 introducing the -dynamic flag (not sure about the specific problem it aims to solve, though) and changing some internal when it comes to library linking, but information is scattered and fragmented. I would like to: 1) Shed some light on my specific use case: Can I do better here? (aka have GHC figure out automatically all the nitty gritty details) 2) Any sort of pointers to documentation, tutorials, papers, everything to "teach me to fish”? Many thanks, Alfredo

4 6

Slides for "Adventures with Types" @ Functional Programming Exchange 2013?
by Erik Rantapaa 15 Oct '14

15 Oct '14

Hi, Does anyone know if the slides for Simon Peyton Jones' keynote talk at the Skillsmatter Functional Programming Exchange 2013 are available somewhere? Link to the video: https://skillsmatter.com/skillscasts/3842-keynote-3842 Thanks!

4 3

value vs object orientation
by Rustom Mody 15 Oct '14

15 Oct '14

I was trying to explain to a colleague the difference in outlook between value and object orientation. I find some references like C#'s 'value-objects' vs the more usual 'reference-objects' But these kinds of references are very OOP-tilted. OTOH there are a few writings eg by Peter Wegner argung that the millennial philosophy divide between 'rationalism' and 'empiricism' corresponds to the division in programming between FP and OOP. Im looking for some more middle ground stuff -- not too stuck on one technological platform and yet not overly philosophical

3 6

Re: [Haskell-cafe] Getting the haddocks back
by Carter Schonwald 14 Oct '14

14 Oct '14

you have to add your acls curl -X DELETE https://$username:$ pwd@hackage.haskell.org/package/linear-1.10.1.2/docs something like that, suitably adjusted for the libs in question On Tue, Oct 14, 2014 at 3:00 PM, Johannes Waldmann < johannes.waldmann(a)htwk-leipzig.de> wrote: > Hi Carter, > > > https://hackage.haskell.org/api > > Aha. How do I authenticate? I'm getting this (no surprise) > > [waldmann@R630 ~]$ curl -i -X DELETE -H "Accept: application/json" > https://hackage.haskell.org/package/satchmo-2.8.1/docs > > HTTP/1.1 401 Unauthorized > > - J. > >

1 0

ANN: yi-0.10.0 , the text editor written in Haskell
by Mateusz Kowalczyk 14 Oct '14

14 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We're glad to announce Yi 0.10.0. Yi is 10 years old today! Our main repository is at [1]. Yi compiles with GHC 7.6.3 all the way up to GHC 7.8.3. There have been many changes since the latest Hackage release (0.8.2). I inline the relevant part of the changelog at the bottom. We are slowly trying to populate the documentation pages: we have recently started using GitHub pages[2] for this purpose. Please have a look! On top of the issues listed in the changelog, a lot of issues were closed separately. If you had a pending issue, please check the issue tracker. As always we're looking for contributors: we have tasks in just about any area. Note that you don't even need to know Haskell to help us. Visit us on #yi on Freenode: be prepared to stay for more than 5 minutes. Installation instructions are available at [2]. If you're using nix, Yi 0.10.0 will be packaged shortly. 0.10.0 - ------ * Unicode syntax highlighting fixed (issue #82) * Hook to GTK Window exposed (#557) * Multiple components moved out to separate packages (oo-prototypes, word-trie, yi-languages, yi-string) * Replace a lot of the API to use YiString/Text instead of String improving performance * Greatly improve performance in the pango front-end as long as line-wrapping is on (default) * Recognise read-only files (#145) * Various Vim keymap improvements and fixes * Use lens instead of uniplate, replace some boilerplate with lens * Improve test framework to handle windows interactions, e.g. scrolling. * Use GHC.Generics instead of derive on GHC 7.8 * Remove bitrotten ghcapi and scion flags. * Support non-qwerty vim users * Support eventlog profiling with -feventlog * Eliminate idle CPU consumption in vty frontend * General cleanup * Make C-w closer to actual emacs behaviour (#612) * Make M-h behave more like emacs (#611) * Hint with buffer names when using C-k with emacs keymap (#606) * Fix display of paths starting with / (#528) * Don't mark buffer as changed if nothing was killed (#618) * Nicer findFile &c behaviour in dired buffers (#149) * Implement C-a for CUA (#167) * Fix dired for directories with unicode files/dirs (#445) * Fix vim indenting under some circumstances (#621) * Allow the font size to be changed per buffer (#608) * Double-click and triple-click selection in pango (#100 and #101) * Count columns properly in presence of tabs (#440) * Extra marking operations in dired Contributors: Alan Zimmerman, Anders Papitto, Anthony Quizon, Ben Armston, Benno Fünfstück, Carter Charbonneau, Corey O'Connor, Cray Elliott, Dmitry Ivanov, fiendfan1, Ilya Smelkov, Jakub Arnold, Jared Hance, jetho, Mateusz Kowalczyk, Richard Goulter, Ryan Desfosses, Siddhanathan Shanmugam 0.9.0 - ----- * Vim keymap removed. Vim2 is now called Vim. [1]: https://github.com/yi-editor/yi [2]: http://yi-editor.github.io/ - -- Mateusz K. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJUPWXYAAoJEM1mucMq2pqXgzcP/0iljWag1qweflSYIqKa+FOc n/NYTqUV3HIYSGxolUvnm5HMfJ1uFFYmV7BVEtC7VcdntdP/bUCxu2gdOA9XxIrL JFwV3tzvLFqPYsm0bBVwq+lqRaBF2ICK95gmZpE+Osw7lrIK0SwibGAuLL+niRoo Qf5duTZXMBw0gQxay47zAb1XPwUhLYQUThSnbcOAG1raRI3OCV/eyMky+l5WMLTy 3RK5j2ZsWnps9k1XOFBVR/pQ6kJiFrButfLY7c3RBbfY9+uHQDN1ba3hr3wHsXUP fw4PiM6WmHecezH1Q7TSzH0XL+Mh5miM+g2QGphKAjeACOzskiCYRGcBpUCHSPsO EdxHe62oUvonEPAP747lCMRcYURknvoyVCDKjYzNKFBHJPFAizWW+tlv82QKKT1j CKECN7Lkra3nlLKzi11TdLHMUDGmatJeNHUMp4W1EDGG/hRbobrmD+2U2Yt/pRKH f/tSeE5Azk0xjDMNmYZBprqf1O1Q9tve4NrIHgQK0EXRWhkcFAsGIdqQBHP27Z0s JdCXdlMaRs4u2IfYoDevnFadMGF10oqQ1wUJPtIzcVvghgBkZEIMswsqbD5fTtPf Y/DFe2YcJl+lxPqgm/fq3aDnJABGYLftfJ05Rs1BGA909bnW29YqK0Si8JxAoH4R K6YQBTpqWULfHXh/ZQ68 =CAHP -----END PGP SIGNATURE-----

1 0