/
--
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On 23 January 2013 05:41, Nathan Hüsken nathan.hues...@posteo.de wrote:
Hey,
I am working on getting ghc to cross compile to android.
When trying to get haskeline to compile. I want to change the cabal file
such that it sets a flag when compiling for android.
For that I changed cabal so
On 12 January 2013 16:05, Ian Lynagh i...@well-typed.com wrote:
On Tue, Jan 08, 2013 at 08:10:18PM +, Duncan Coutts wrote:
Either way, lemme know if this is all fine, and I'll make the 0.10.0.2
release.
Looks good, thanks! I've updated the GHC 7.6 repo to match the tag.
Ta muchly
On 28 May 2012 05:36, Tim Cuthbertson t...@gfxmonk.net wrote:
- ghc doesn't seem to support ${pkgroot} prefixes. I thought it did,
but I'm new to this so I may be misunderstanding where they can be
used.
I thought it did too since I think I wrote the code for it. I don't
recall exactly what
On 18 May 2012 20:20, Joe Buehler as...@cox.net wrote:
I built GHC 7.2.2 on a LINUX box running RHEL 3. When compiling a package
using
this GHC it is trying to invoke ar thus:
execve(/usr/bin/ar, [/usr/bin/ar, -r, -c,
dist/build/libHSregex-base-0.93, dist/build/Text/Regex/Base.o,
On 18 May 2012 22:03, Joe Buehler as...@cox.net wrote:
Duncan Coutts wrote:
I'm very surprised it's not working on some version of Red Hat. This
has worked on many varieties of linux for many years. You don't have
some non-standard ar installed do you? What version of gnu binutils?
(ar -V
On 8 February 2012 10:24, Joachim Breitner nome...@debian.org wrote:
Dear interested parties :-),
GHC 7.4.1 started to ship and expose the binary library, version
0.5.0.3. On hackage is binary-0.5.1.0.
It was firmly my opinion that shipping and exposing binary in GHC was
and is a mistake.
On Tue, 2011-11-08 at 15:43 +, Simon Marlow wrote:
Hmm, but there is something you could do. Suppose a thread could be in
a mode in which instead of blocking on a BLACKHOLE it would just throw
an asynchronous exception WouldBlock. Any computation in progress would
be safely abandoned
9, 2011 at 3:18 AM, Duncan Coutts duncan.cou...@googlemail.com
wrote:
On 9 November 2011 00:17, Felipe Almeida Lessa felipe.le...@gmail.com
wrote:
On Tue, Nov 8, 2011 at 3:01 PM, Daniel Fischer
daniel.is.fisc...@googlemail.com wrote:
On Tuesday 08 November 2011, 17:16:27, Simon Marlow
On Thu, 2011-04-28 at 23:31 +0200, Johan Tibell wrote:
The RTS would invoke listeners every time a new event is written. This
design has many benefits:
- We don't need to introduce the serialization, deserialization, and
I/O overhead of first writing the eventlog to file and then parsing it
On Tue, 2011-04-26 at 14:05 -0700, Brandon Moore wrote:
Based on my own misadventures and Albert Y. C. Lai's SICP
(http://www.vex.net/~trebla/haskell/sicp.xhtml)
it seems the that root of all install problems is that reinstalling a
particular version of a particular package deletes any other
On 16 December 2010 10:02, Simon Marlow marlo...@gmail.com wrote:
ghc-cabal: Missing dependency on a foreign library:
* Missing header file: HsBase.h
This problem can usually be solved by installing the system package that
provides this library (you may need the -dev version). If the library
On 8 November 2010 13:28, Simon Marlow marlo...@gmail.com wrote:
There's another approach in Jan Sparud's paper here:
http://portal.acm.org/citation.cfm?id=165196
although it's not clear that this interacts very well with inlining either,
and it has a suspicious-looking side-effecting
On 12 August 2010 02:20, Greg Fitzgerald gari...@gmail.com wrote:
Is there a way for a package.conf file to contain paths that are relative to
the directory containing the .conf file? GHC 6.12.1 chokes on relative
paths. I see the problem is solved for GHC's core libraries with the
$topdir
On Tue, 2010-05-18 at 17:31 -0400, Anthony LODI wrote:
Hello,
I'm trying to build some haskell code as a .so/.dll so that it can
ultimately be used by msvc. I have it working when I compile by hand
(listed below) but I can't get the exact same thing built/linked with
cabal. On linux
On Wed, 2010-05-05 at 21:24 +1000, Roman Leshchinskiy wrote:
Whenever I do cabal sdist on one of my projects, I get this warning:
Distribution quality warnings:
'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit
and not just imposing longer compile times on your
organisations and the Simons at GHC HQ. If you think your
organisation may be interested then get in touch with me, Duncan Coutts,
via i...@well-typed.com.
--
Duncan Coutts, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/
___
Glasgow-haskell
On Fri, 2010-04-30 at 10:25 -0400, Tyson Whitehead wrote:
On April 30, 2010 06:32:55 Duncan Coutts wrote:
In the last few years GHC has gained impressive support for parallel
programming on commodity multi-core systems. In addition to traditional
threads and shared variables, it supports
On Thu, 2009-12-24 at 18:18 -0500, Antoine Latter wrote:
Folks,
I found some of the documentation in GHC.Prim confusing - so I thought
I'd share. The documentation for the ByteArray# type[1] explains
that's it's a raw region in memory that also remembers it's size.
Consequently I expected
On Wed, 2009-12-23 at 21:49 +, Simon Marlow wrote:
I personally think we should revert to using the standard config.guess
and normalising the result as we used to.
Aye.
It was changed due to this:
http://hackage.haskell.org/trac/ghc/ticket/1717
so we should find another way around
On Mon, 2009-12-21 at 11:34 +, Gracjan Polak wrote:
Duncan Coutts duncan.coutts at googlemail.com writes:
if flag(test)
Buildable: True
Build-depends: base5, bytestring, HUnit, directory
else
Buildable: False
Is this solution good for the time being
On Mon, 2009-12-21 at 12:44 +, Simon Marlow wrote:
The current Cabal code takes a slightly different approach. It says at
the end oh this exe isn't buildable, so its deps do not contribute to
the deps of the package.
The problem is what it was doing before that. It sees the
All,
Conor's problems on OSX with libiconv reminds me of something I've been
thinking about for a little while.
So the problem is that the semantics of static linking does not at all
match what we really want. We can easily accidentally interpose a
wrong library in place of the one we wanted.
On Fri, 2009-12-18 at 19:44 -0800, Dave Bayer wrote:
Hi Duncan,
Installation was easy (I typed cabal-install HTTP zlib
cabal-install ;-).
Thanks for testing it. I've uploaded it to hackage.
Overall, seems to work fine. I couldn't build darcs, but I couldn't do
that by hand either; I used
On Thu, 2009-12-17 at 14:00 -0800, Dave Bayer wrote:
Background: I never got cabal install to work on OS X 10.5 with GHC
6.10.4, basically because zlib wouldn't work. Odd, because a perfectly
good version of gunzip already exists on most platforms, and the code
doesn't fall back to this
All,
If you'd like to help test the new cabal-install-0.8 release then grab
it here:
http://haskell.org/cabal/release/cabal-install-0.8.0/
It should work with ghc-6.10 and 6.12 (and indeed 6.8 and 6.6).
If nobody reports any major show stoppers then I'll upload this to
hackage.
Duncan
On Tue, 2009-12-15 at 12:48 -0800, Bryan O'Sullivan wrote:
Yes, that would amount to double-buffering, and would work nicely,
only the current buffers go through foreign pointers while text uses
an unpinned array. I can see why this is (so iconv can actually work),
but it does introduce a
All,
I've tried building 1324 out of the ~1700 packages from hackage using
ghc-6.10.4 and ghc-6.12.0. This is the subset of packages that I could
build in one go.
Compared to the subset that I could build with ghc-6.10.4, I had to
chuck out 125 packages because their build dependency constraints
On Mon, 2009-12-14 at 22:49 +0100, Daniel Fischer wrote:
Oh great, that's not what I expected:
$ cabal install cabal-install
cabal: This version of the cabal program is too old to work with ghc-6.12+.
You will need to install the 'cabal-install' package version 0.8 or higher.
If you still
On Mon, 2009-11-30 at 08:44 +, Simon Peyton-Jones wrote:
Should this go in a FAQ? For GHC? Or for a particular architecture?
For ghc-6.10, yes. It'd should be a section GHC on OSX 10.6 (Snow
Leopard) and should describe the changes required to the shell script
wrappers of ghc and hsc2hs. It
On Wed, 2009-11-25 at 04:56 +, Malcolm Wallace wrote:
Moreover, when I attempt to use the flag, like so:
$ ghc -package-name hat-2.06 ...
command line: cannot parse 'hat-2.06' as a package identifier
This used to work with ghc-6.6.x and ghc-6.8.x, but seems to have
stopped
On Sun, 2009-11-22 at 22:00 -0600, Tom Tobin wrote:
On Nov 22, 2009, at 11:53 AM, Ian Lynagh wrote:
Hi all,
We are pleased to announce the second release candidate for GHC 6.12.1:
http://www.haskell.org/ghc/dist/6.12.1-rc2/
IIRC, an earlier 6.12 RC announcement mentioned that
On Fri, 2009-11-13 at 17:18 +0300, Daniil Elovkov wrote:
Did you use -auto-all, to automatically create cost centers for all
top-level functions? I find that I get very verbose cost info for
definitions under imported libraries.
Yeah, I've got it. Modules in packages were done by cabal
On Thu, 2009-11-12 at 10:46 +0100, Daniel Kahlenberg wrote:
to answer this question myself how the use of another gcc is specified
with effect, I used the following options with the 'cabal install' call:
--ghc-options=-pgmc e:/programme/ghc/mingw-gcc4/bin/gcc.exe -pgml
On Fri, 2009-11-06 at 01:13 +0100, Niklas Broberg wrote:
Can someone please comment on these two proposed changes. I agree with
Niklas but I'm a bit reluctant to apply the patches without at least
some sign of agreement from someone else.
Deprecating PatternSignatures seems
On Fri, 2009-10-30 at 17:17 +, Neil Brown wrote:
Hi,
The GHC manual says that if you pass -cpp to GHC, it runs the C
preprocessor, cpp on your code before compilation
(http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#c-pre-processor).
But why, in that case,
On Wed, 2009-10-28 at 22:55 +, Simon Peyton-Jones wrote:
SECOND, we have produced Release Candidate 1 for GHC 6.12.1, and are
about to produce RC2. However, before releasing 6.12 we'd like to
compile all of Hackage, in case doing so reveals bugs in GHC's APIs
(which are not supposed to
On Sun, 2009-10-18 at 16:01 -0200, Marco Túlio Gontijo e Silva wrote:
Hi.
I sent a mail to gtk2hs-devel about this bug, and I'm forwarding it's
response to here.
This limitation might be different now that ghc is using libffi.
Duncan
I don't have a clue about this bug:
On Mon, 2009-10-12 at 19:29 +0400, Bulat Ziganshin wrote:
Hello Duncan,
Monday, October 12, 2009, 6:58:43 PM, you wrote:
also, i propose to enable +RTS -N by default. Haskell is very popular
as multithreaded language, don't fool novices!
Note that you'd also have to enable -threaded
On Mon, 2009-10-12 at 16:04 -0400, Brent Yorgey wrote:
What's the canonical way to install a version of ghc but not have it
be the default? i.e., I'd like to try testing this release candidate
but I want to have to call it explicitly; I want 'ghc', 'ghc-pkg'
etc. to still be aliases to
On Mon, 2009-10-12 at 18:43 +0200, Christian Maeder wrote:
P.S. I wonder why Registering is done twice
It's Cabal's fault. It's a new feature to let components within a
package depend on each other. To do that it needs to register the lib
into a local inplace package db. At the moment it's
On Thu, 2009-10-08 at 19:27 +0100, Colin Paul Adams wrote:
I've been using ghc 6.10.3 on 64-bit Linux to compile my application,
and it runs OK, modulo bugs.
I want to debug a problem, so I load it in ghci, but when i type main
I get:
Loading package network-2.2.1.1 ...
GHCi runtime
On Thu, 2009-10-08 at 18:32 +1100, Manuel M T Chakravarty wrote:
David Menendez:
Is there any consensus about what needs to be done to get a working
ghc installation on a Snow Leopard (Mac OS X 10.6) system? The Mac OS
X wiki page[1] currently links to a blog post[2] that recommends
On Tue, 2009-09-15 at 16:56 +0200, Karel Gardas wrote:
Hello,
recently I've found out that my solaris-based GHC buildbot is completely
unusable since it always (when it get to, which means it does not fail
with usual magic number mismatch: old/corrupt interface file?) fails with:
On Mon, 2009-09-07 at 11:24 -0700, Judah Jacobson wrote:
I'm not sure I understand. Are you saying that you can't use
backspace/arrows/etc when the getLine command itself is waiting for
input? But otherwise at the Prelude prompt, where you type in the
commands, everything behaves fine?
On Fri, 2009-08-28 at 11:42 +0100, Simon Marlow wrote:
Can anyone think of a good reason not to upgrade darcs to 2.3.0 on
darcs.haskell.org? I can think of 3 reasons to do so:
- this script, for preventing accidental divergence from upstream
- faster pushes, due to transfer-mode
-
On Wed, 2009-08-26 at 17:15 +0100, Simon Marlow wrote:
* Sometimes we want to make local modifications to INDEPENDENT
libraries:
- when GHC adds a new warning, we need to fix instances of the
warning in the library to keep the GHC build warning-free.
I have to say I think
On Sat, 2009-08-22 at 15:52 +1000, John Lask wrote:
in declaring fixity for an operator (\\) to get it to compile using ghc
6.10.4, I needed to use the following code
infixl 9 \\\
(\\) a b = etc ...
where I assume the first \ escapes the second \, using infixl 9 \\ generates
a syntax
On Fri, 2009-08-07 at 10:55 +0200, Christian Maeder wrote:
Duncan Coutts wrote:
I should also note that there is a GHC 6.10.4 binary for Sparc/Linux
that is now included with Gentoo. It's got all features turned on except
for split objects (which fails due to mixing ld -r and --relax flags
On Fri, 2009-08-07 at 13:14 +0200, Christian Maeder wrote:
Christian Maeder wrote:
Matthias Kilian wrote:
However, to create an archive, you can use something like
$ pax -wf foo.tar directory
Do you think gtar --format=posix would be different from pax?
I would expect they are the
On Thu, 2009-07-30 at 15:12 +0200, Christian Maeder wrote:
Don Stewart wrote:
Heads up lads, we're about 24 hours from Haskell Platform 2009.2.0.2
http://code.haskell.org/haskell-platform/haskell-platform.cabal
I still see
time ==1.1.2.4,
although ghc-6.10.4 comes
On Tue, 2009-08-04 at 10:15 +0200, Christian Maeder wrote:
Hi,
I've just been informed that unpacking the binary (i386) solaris
distribution using bunzip2 and tar:
It may work better in future if you use a non-GNU tar to pack it up in
the first place. GNU tar uses a non-standard tar format
On Thu, 2009-08-06 at 10:04 +0200, Christian Maeder wrote:
Hi Ian,
could you add a note on the download page that
GCC version 4.3.x is not suited for:
http://www.haskell.org/ghc/dist/6.10.4/maeder/ghc-6.10.4-sparc-sun-solaris2.tar.bz2
The binary-dist was compiled using gcc-4.2.2 (but
On Thu, 2009-08-06 at 12:30 +0100, Duncan Coutts wrote:
On Tue, 2009-08-04 at 10:15 +0200, Christian Maeder wrote:
Hi,
I've just been informed that unpacking the binary (i386) solaris
distribution using bunzip2 and tar:
It may work better in future if you use a non-GNU tar to pack
On Tue, 2009-06-30 at 14:45 +0100, Simon Peyton-Jones wrote:
I've dumped all this on a release plans wiki page:
http://hackage.haskell.org/trac/ghc/wiki/Status/Releases
Manuel, Duncan: maybe you can modify the wiki directly?
Done. Fortunately there's not much left to do for shared
On Wed, 2009-06-03 at 16:41 +0200, Niklas Broberg wrote:
Second there's the constructor NoMonoPatBinds, which actually
describes the default Haskell 98 behavior, even if GHC has a different
default. It's GHC's behavior that is the extension, so the constructor
in cabal should really be named
On Wed, 2009-06-03 at 15:59 -0400, David Menendez wrote:
On Tue, Jun 2, 2009 at 5:38 AM, Duncan Coutts
duncan.cou...@worc.ox.ac.uk wrote:
OSX users,
please could you try out Gregory's Haskell Platform package below and
send commentary to the platform list, or file tickets in the platform
On Thu, 2009-06-04 at 08:43 +0100, Simon Peyton-Jones wrote:
I'd be quite happy to rename the flag to GeneralisedisedListComp, and
clarify the user manual. Would that suit everyone?
I suppose the alternative is to leave it as TransformListComp, and
document that fact. But I rather agree
On Wed, 2009-06-03 at 16:33 +0100, Max Bolingbroke wrote:
2009/6/3 Niklas Broberg niklas.brob...@gmail.com:
First there's the constructor called TransformListComp, which should
really be named GeneralizedListComp, since the constructor should
describe the extension and not the
OSX users,
please could you try out Gregory's Haskell Platform package below and
send commentary to the platform list, or file tickets in the platform
trac, that'd be great.
http://trac.haskell.org/haskell-platform/newticket?component=OSX%20installer
The plan is that for ghc-6.12 and onwards,
On Thu, 2009-05-28 at 23:40 +0100, Claus Reinke wrote:
If you don't want to move from absolute paths for non-core packages,
the current system should just work, right?
Yes.
The current system being the $topdir one.
Yep. It works, it's just not nice, it's ghc-specific and only make
All,
This is a draft proposal for a common mechanism for implementing
relative paths in installed package descriptions.
Comments and feedback are welcome. I'm cc'ing this to the cabal and
ghc-users lists but let's keep the discussion on the libraries list.
There has been some discussion of this
On Thu, 2009-05-28 at 11:16 +0100, Claus Reinke wrote:
How about this: a way to specify paths in the package registration info
that
are relative to the location of the package db they are in.
ahem. That sounds like a backwards step, being dependent on two
locations instead of one.
On Thu, 2009-05-28 at 14:12 +0100, Claus Reinke wrote:
But if you're registering global packages that are installed outside of
the GHC tree then you wouldn't register them using relative paths. I'm
not saying everything must use relative paths.
Please don't move your windmills while I'm
On Wed, 2009-05-27 at 15:10 +0100, Alistair Bayley wrote:
Andrea,
2009/3/19 Andrea Vezzosi sanzhi...@gmail.com:
It turns out that those variables are there to allow relocation, in
fact $topdir is expanded by
Distribution.Simple.GHC.getInstalledPackages, it seems that
$httptopdir has
On Fri, 2009-05-22 at 05:30 -0700, Don Stewart wrote:
Answer recorded at:
http://haskell.org/haskellwiki/Performance/Parallel
I have to complain, this answer doesn't explain anything. This isn't
like straight-line performance, there's no reason as far as I can see
that inlining should
On Fri, 2009-05-22 at 16:34 +0200, Daniel Fischer wrote:
That's great, thank you. I am still baffled, though.
I'm baffled too! I don't see the same behaviour at all (see the other
email).
Must every exported function that uses `par' be INLINEd? Does every
exported caller of such a
On Sat, 2009-05-16 at 11:07 +0100, Neil Mitchell wrote:
I don't, although having that option wouldn't be a bad thing - having
a minimal .lib is perfectly reasonable as a default. Having a massive
.lib seems crazy. (The fact that .lib is named .dll.a isn't too much
of an issue)
It's possible
On Sat, 2009-05-16 at 22:31 +0400, Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
http://www.nongnu.org/cinvoke/faq.html
From the page:
How does C/Invoke compare to libFFI?
At the C API level they're pretty similar, aside from some minor
quibbles. libFFI
On Fri, 2009-05-15 at 15:31 +0100, Neil Mitchell wrote:
Hi,
I've just built a Haskell dll on Windows. As part of the process it
generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags
passed to ld I see --out-implib=foo.dll.a. What is the purpose of the
.a file? What might it
On Tue, 2009-05-05 at 00:43 +0100, Geraint Jones wrote:
Sorry to revive a year-old thread, but...
On Fri, 25 Apr 2008 at 20:17:53 +0100 Duncan Coutts wrote:
On Fri, 2008-04-25 at 09:08 -0700, Don Stewart wrote:
Geraint.Jones:
Are there well-known differences in the implementations
On Thu, 2009-05-07 at 15:12 +0100, Neil Mitchell wrote:
This is a test framework that spawns system commands. My guess is the
Haskell accounts for a few milliseconds of execution per hour. Running
two system commands in parallel gives a massive boost.
That still doesn't explain why you
On Fri, 2009-04-24 at 12:56 +0200, Philip K.F. Hölzenspies wrote:
Dear GHCers,
I am trying to write a wrapper library for lab work to give to students.
My problem is, that the libraries I use require initialization that I
really want to hide from our students. The wrapper I'm writing is
On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote:
Hi Ian,
thanks for the update on plans and the willingness to jump in and do another
release cycle so soon after 6.10.2. The suggested fixes seem agreeable to
me, but I have one _minor_ additional request for 6.10.3 if you end having
On Thu, 2009-04-23 at 05:59 -0700, Sigbjorn Finne wrote:
On 4/23/2009 02:05, Duncan Coutts wrote:
On Wed, 2009-04-22 at 18:55 -0700, Sigbjorn Finne wrote:
Hi Ian,
thanks for the update on plans and the willingness to jump in and do
another
release cycle so soon after 6.10.2
On Sat, 2009-04-11 at 21:07 +0400, Bulat Ziganshin wrote:
Hello Bertram,
Saturday, April 11, 2009, 8:09:46 PM, you wrote:
What does same thread mean? I'll risk a guess.
well, that's possible - i'll ask on gtk2hs list too
currently, i believe that mainGUI just runs endless loop
On Thu, 2009-04-02 at 13:47 +0900, Benjamin L.Russell wrote:
On Wed, 1 Apr 2009 18:48:13 -0700, Lyle Kopnicky li...@qseep.net
wrote:
Great! But what happened to the time package? It was in 6.10.1. Has it been
intentionally excluded from 6.10.2?
Yes, the maintainer of the time package asked
On Wed, 2009-03-25 at 09:18 +, Simon Peyton-Jones wrote:
* More promising might be to say this is the hot branch. That information
about frequency could in principle be used by the back end to generate better
code. However, I am unsure how
a) to express this info in source
On Thu, 2009-03-19 at 16:34 -0700, Don Stewart wrote:
We must have the gtk2hs team invovled in this discussion. They were
using an undocumented feature. It may be trivial to fix.
This will need to be fixed in gtk2hs. Previously GHC allowed finalizers
to call back into Haskell, but this
On Tue, 2009-03-17 at 21:12 -0400, Brandon S. Allbery KF8NH wrote:
On 2009 Mar 17, at 20:28, Duncan Coutts wrote:
It works for me under Solaris 10. Perhaps Solaris 9 or older do not
have a standard compliant /bin/sh program. What do you suggest we use
instead as a workaround
On Tue, 2009-03-17 at 08:53 +, Simon Marlow wrote:
Duncan Coutts wrote:
On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote:
Yes, if we know we're using it. If we specify -package blah on the
command line then we do know we're using it and everything works
(because ghc uses
On Tue, 2009-03-17 at 11:09 +0100, Christian Maeder wrote:
GHC 6.10.2 will have a problem with cabal-install-0.6.2!
When I tried to install cabal-install-0.6.2 for ghc-6.10.1.20090314
I needed to change #!/bin/sh to #!/bin/bash in bootstrap.sh to avoid the
following errors:
-bash-3.00$
On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote:
This sounds like a chicken and egg problem. To know which package
include directories to use GHCi needs to know which packages your module
uses. However to work out which packages it needs it has to load the
module which means
On Mon, 2009-03-16 at 16:04 -0700, Conal Elliott wrote:
On Mon, Mar 16, 2009 at 2:47 PM, Duncan Coutts
duncan.cou...@worc.ox.ac.uk wrote:
On Mon, 2009-03-16 at 12:13 +, Simon Marlow wrote:
Perhaps I'm missing something, but if applicative-numbers is
an exposed
On Sat, 2009-03-14 at 23:43 -0700, Conal Elliott wrote:
The applicative-numbers package [1] provides an include file. With
ghci, the include file isn't being found, though with cabal+ghc it is
found.
My test source is just two lines:
{-# LANGUAGE CPP #-}
#include
On Sun, 2009-03-15 at 09:13 -0700, Conal Elliott wrote:
That did it. I've added :set -package applicative-numbers to
my .ghci and am back in business. Thanks!
IIUC, there's an inconsistency in ghci's treatment of modules vs
include files, in that modules will be found without -package, but
On Sun, 2009-03-08 at 12:29 +, Tuomo Valkonen wrote:
I want a _real_ cygwin version of darcs. The non-deterministic
pseudo-cygwin *nix/Windows hybrid currently available has just
too many problems integrating into cygwin, that I want to use as
my TeXing and minor coding environment. A
On Tue, 2009-02-10 at 17:15 +, Ian Lynagh wrote:
Hi all,
Currently, hsc2hs (as shipped with GHC) cannot be used with just
hsc2hs Foo.hsc
as it cannot find HsFFI.h (http://hackage.haskell.org/trac/ghc/ticket/2897).
To make it work you need to run something like
hsc2hs -I
On Tue, 2009-02-17 at 08:47 +, Simon Marlow wrote:
Duncan Coutts wrote:
Maybe. Dealing with linker scripts properly is probably rather tricky
and we get it for free when we switch to shared libraries.
I don't follow this last point - how does switching to shared libraries
On Sun, 2009-02-15 at 11:06 +, Duncan Coutts wrote:
On Sun, 2009-02-15 at 09:24 +, Neil Mitchell wrote:
Hi
What have I done wrong? Did createProcess close the handle, and is
there a way round this?
The docs for runProcess says:
Any Handles passed
On Thu, 2009-02-12 at 10:11 +0100, Christian Maeder wrote:
Duncan Coutts wrote:
On Wed, 2009-02-11 at 15:49 +0100, Lennart Augustsson wrote:
Does this version work from ghci?
-- Lennart
Specifically I believe Lennart is asking about Windows. It's worked in
ghci in Linux for ages
On Tue, 2009-02-10 at 13:43 +, Simon Marlow wrote:
Simon Peyton-Jones wrote:
I'm guessing a bit here, but it looks as if you intend this:
* GHC should read Foo.hs, and see {-# LANGUAGE CPP #-}
* Then it should run cpp
* Then it should look *again* in the result of running cpp,
On Thu, 2009-02-05 at 00:11 +0100, Deniz Dogan wrote:
I'm currently working on hacking Data.Generics for my master thesis.
I'm basically trying to find out whether it can be made any faster
using e.g. rewrite rules. The problem I'm having is that I need an
easy way to import my own modified
mentioned this already, but utf16 (as opposed to
utf16be/le) will use the BOM if its present.
I'm not quite sure what happens when you switch encoding, presumably
it'll accept and consider a BOM at that point.
Thanks to suggestions from Duncan Coutts, it's possible to call
hSetEncoding even
On Tue, 2009-02-03 at 17:39 -0600, John Goerzen wrote:
On Tue, Feb 03, 2009 at 10:56:13PM +, Duncan Coutts wrote:
Thanks to suggestions from Duncan Coutts, it's possible to call
hSetEncoding even on buffered read Handles, and the right thing
happens. So we can read from text
All,
We need to think about a new better permissions api for the
System.Directory module. The current api and also the implementation are
at best useless and possibly harmful.
I've been trying to debug various permission problems related to
installing files with Cabal on Unix and Windows. Half
On Wed, 2009-01-28 at 14:57 +0100, Johan Tibell wrote:
On Wed, Jan 28, 2009 at 2:13 PM, Duncan Coutts
duncan.cou...@worc.ox.ac.uk wrote:
We need to think about a new better permissions api for the
System.Directory module. The current api and also the implementation are
at best useless
On Sun, 2009-01-11 at 14:48 +, Duncan Coutts wrote:
I built four versions of gcc and used them to build ghc-6.8.3.
While on the subject, the annoyances I bumped into while doing this are:
discovering a ghc/gcc combination does not work is not obvious. The
first symptom is ./configure
On Sun, 2009-01-11 at 10:29 -0500, Brandon S. Allbery KF8NH wrote:
On 2009 Jan 11, at 9:48, Duncan Coutts wrote:
On Fri, 2009-01-02 at 21:06 +1100, Ben Lippmeier wrote:
I'm running into some huge compile times that I'm hoping someone will
have some suggestions about. When compiling
Just cleaning out my inbox and realised I meant to reply to this about 4
months ago :-)
On Thu, 2008-09-04 at 23:15 -0700, Iavor Diatchki wrote:
On Thu, Sep 4, 2008 at 1:30 PM, Duncan Coutts
Packages are not supposed to expose different APIs with different
flags
so I don't think that's
1 - 100 of 394 matches
Mail list logo
