On Tue, 2008-02-26 at 13:22 +, Simon Marlow wrote:
So some alternatives that fix this are
1. all text I/O is in the locale encoding (what C and Hugs do)
2. stdin/stdout/stderr and terminals are always in the locale
encoding, everything else is UTF-8
I was initially
On Wed, 2008-02-27 at 00:31 +1100, Roman Leshchinskiy wrote:
Duncan Coutts wrote:
So here is a concrete proposal:
* Haskell98 file IO should always use UTF-8.
* Haskell98 IO to terminals should use the current locale
encoding.
Personally, I'd find this deeply
On Tue, 2008-02-26 at 07:28 -0800, John Meacham wrote:
On Tue, Feb 26, 2008 at 01:34:54PM +, Duncan Coutts wrote:
Personally I'm not really fussed about which compromise we pick. I think
the more important point is that all the Haskell implementations pick
the same compromise so
On Tue, 2008-02-26 at 14:18 +, Simon Marlow wrote:
Simon Marlow wrote:
Duncan Coutts wrote:
Let's call this one proposal 0:
* Haskell98 file IO should always use UTF-8.
* Haskell98 IO to terminals should use the current locale
encoding.
and the others
On Mon, 2008-01-21 at 00:14 +, Frederik Eaton wrote:
Hello all,
About two years ago, I wrote a web page for one of my projects, using
Network.CGI. I chose that over WASH because it had a simple interface
and I thought it would be more stable as a result. Now, Bjorn Bringert
has
On Fri, 2007-12-28 at 09:54 -0500, Gregory Wright wrote:
Hi Duncan,
(Cross-posting to ghc-users since some of the issues were brought up
there.)
On Dec 2, 2007, at 5:04 PM, Duncan Coutts wrote:
Sun Dec 2 14:06:20 PST 2007 Duncan Coutts [EMAIL PROTECTED]
* make rawSystemStdout
On Thu, 2007-12-20 at 16:54 +0300, Bulat Ziganshin wrote:
Hello Simon,
Thursday, December 20, 2007, 4:01:59 PM, you wrote:
Fixing it all properly means some fairly significant architectural changes,
and dropping the via-C backend
oh, thank you. from my POV, C backend still may be
On Thu, 2007-12-20 at 21:16 -0600, Spencer Janssen wrote:
If you're using Cabal, something like this should work:
if os(win32)
cpp-options: -DWIN32
To be precise:
if os(windows)
cpp-options: -DWIN32
See, Cabal is (mostly) Neil I hate mingw Mitchell compliant. :-)
On Mon, 2007-12-17 at 14:27 -0800, Deborah Goldsmith wrote:
I see this:
$ runhaskell ./Setup.lhs build
Preprocessing executables for haddock-0.8...
shift/reduce conflicts: 5
Building haddock-0.8...
src/Main.hs:49:7:
Could not find module `System.Directory':
it is a member
On Sun, 2007-12-16 at 03:21 +0200, Yitzchak Gale wrote:
The current behavior is not more WIndows native - it is
arguably much worse. The %HOMEPATH% variable
should definitely not be used.
It is not.
The folder that it points to is not a home directory and should not
be used that way. But
On Fri, 2007-12-14 at 16:09 +, Simon Marlow wrote:
Juanma Barranquero wrote:
On Dec 14, 2007 3:53 PM, Simon Marlow [EMAIL PROTECTED] wrote:
But do you really want getHomeDirectory to return $HOME?
Yes!
If I define %HOME, it is *exactly* because I don't want to use
Windows'
ghc itself.
--
Duncan Coutts : Gentoo Developer (Haskell team)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
On Thu, 2007-12-13 at 16:06 +, [EMAIL PROTECTED] wrote:
Duncan Coutts wrote:
Sadly not because portage is not clever enough to deal with the kind of
dependencies you end up with by doing that. Portage does not know that
some libs are installed for one ghc and some for another
On Thu, 2007-12-13 at 17:09 +, [EMAIL PROTECTED] wrote:
Until portage actually can do this in a better way,
you would have to multiply ebuilds
(probably each with common import and a one-line variable setting)
(I don't know the exact restrictions on portage version strings):
Right
I'd just like to float an idea that's related to the Class Alias
proposal[1] but is perhaps somewhat simpler.
We all know that Functor should have been a superclass of Monad, and
indeed we now know that Applicative should be too. Making such a change
would break lots of things however so the
On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote:
This is almost exactly the
http://haskell.org/haskellwiki/Class_system_extension_proposal; that
page has some discussion of implementation issues.
Oh yes, so it is. Did this proposal get discussed on any mailing list?
I'd like to see
On Tue, 2007-12-11 at 16:38 +, Ross Paterson wrote:
On Tue, Dec 11, 2007 at 04:26:52PM +, Simon Marlow wrote:
Duncan Coutts wrote:
On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote:
This is almost exactly the
http://haskell.org/haskellwiki/Class_system_extension_proposal
On Fri, 2007-12-07 at 14:24 -0800, Greg Fitzgerald wrote:
Please test as much as possible
One difference between 6.8.1 and 6.8.2 that I see is in running
runhaskell Setup.hs haddock with Haddock 0.8 on Windows XP. Haddock
is no longer able to resolve the names from the standard libraries.
On Wed, 2007-11-28 at 22:37 +, Alistair Bayley wrote:
More puzzling is that the files that Cabal runs through ghc's CPP
don't get the # n lines, so we end up with something like this:
(Answering my own message)
Having done some more testing with ghc-6.8.1 and ghc-6.6.1 and cabal's
On Fri, 2007-11-23 at 14:59 -0500, Alex Jacobson wrote:
Cabal is not a solution to this problem because
1. you want your code to work via ghci and runhaskell and perhaps via
searchpath.
2. you may want to move a module from one package to another and you
don't want to have to examine
On Fri, 2007-11-23 at 16:26 +0100, Wolfgang Jeltsch wrote:
Am Freitag, 23. November 2007 03:37 schrieben Sie:
On Fri, 2007-11-23 at 01:50 +0100, Wolfgang Jeltsch wrote:
Dont’t just think in terms of single modules. If I have a Cabal package,
I can declare used extensions in the Cabal
On Fri, 2007-11-23 at 01:50 +0100, Wolfgang Jeltsch wrote:
Dont’t just think in terms of single modules. If I have a Cabal package, I
can declare used extensions in the Cabal file. A user can decide not to
start building at all if he/she sees that the package uses an extension
On Wed, 2007-11-21 at 15:03 -0500, Alex Jacobson wrote:
Proof that the compiler knows which extensions are being used: it can
compile the program sucessfully when the extension is turned on and not
otherwise.
Counterexample (not my own):
http://hpaste.org/3855
{-# OPTIONS_GHC
On Wed, 2007-11-21 at 19:26 -0500, Alex Jacobson wrote:
Ok, I'm game to default to haskell98 in the presence of ambiguity, but
in most cases the extension involves new syntax and that should be enough.
In these cases ghc does generally give an error message which mentions
which extension it is
On Tue, 2007-11-20 at 13:25 -0800, Stefan O'Rear wrote:
(Would someone who is involved with the cabal web site PLEASE put this
up somewhere? FAQs do no good if they have to be typed by humans!)
What would you like the text to be and where would you like to see it?
Duncan
On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote:
When you want automated deriving of show/read etc., you need all the
components of your type also to be instances of show/read but you won't
want to *require* them to be automatically generated verions.
Standalone deriving does the
On Sat, 2007-11-10 at 21:45 +, Ian Lynagh wrote:
Hi Philip,
On Mon, Nov 05, 2007 at 09:58:40AM +0100, Philip K.F. Hölzenspies wrote:
Booting libraries/base
Booting libraries/directory
/usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of
On Wed, 2007-11-07 at 11:50 -0500, Seth Kurtzberg wrote:
Run:
ghc-pkg list
See what it thinks about the status of happy.
happy is a program. ghc-pkg doesn't know about it.
i'm having some difficulties compiling the 6.8.1 extralibs on a Mandriva
2007.0 box. Despite happy 1.15
On Wed, 2007-10-31 at 14:40 +0100, Cristian Perfumo wrote:
Hi,
I did some modifications to GHC in order to read hardware counters.
Many programs are compiled successfully, but with one of them, I have
a problem:
Too many local registers allocated by gcc at .../ghc-
All,
There is unfortunately some synchronisation between ghc releases and the
releases of various common libraries, the so-called extralibs
collection. So I'd like to look briefly at what the version numbers of
theses packages should be. It is important that we do increase the
version numbers if
Ian pointed out that most of these extralibs already have had releases
via hugs with greater version numbers than those we were proposing.
http://cvs.haskell.org/Hugs/downloads/2006-09/packages/
For example ALUT-2.0.20060921 which means we cannot use ALUT-2.0.2 as we
had been thinking. We'll have
On Mon, 2007-10-22 at 14:11 +0100, Ian Lynagh wrote:
If anyone sees any problems with my suggested version numbers below,
please shout.
I've CCed all addresses listed as Cabal maintainers of extralibs; please
let us know if you disagree with the versions we propose to use for your
On Mon, 2007-10-22 at 15:42 +0100, Ian Lynagh wrote:
Ah, sorry, my mistake, I hadn't pulled the latest patch. OK, so in
principle I'd be fine with 0.3, except if we want to move to 4-component
version numbers then we need to use 0.3.0.1 anyway (I don't think having
both 0.3 and 0.3.0.0 which
On Sat, 2007-10-20 at 21:11 +0400, Serge D. Mechveliani wrote:
On Sat, Oct 20, 2007 at 03:25:04PM +0100, Duncan Coutts wrote:
On Fri, 2007-10-19 at 10:54 -0300, Isaac Dupree wrote:
How can user who does not modify Cabal file choose between all three of
-O0, -O and -O2
On Thu, 2007-10-18 at 13:19 +0200, Johannes Waldmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Can ghc execute compilations in parallel?
(With GNU make, I'd say make -j 2
but how to achieve this with ghc --make ?)
We're also going to try and solve this in Cabal by having Cabal
On Wed, 2007-08-15 at 18:41 +0100, Brian Hulley wrote:
Hi,
I know this is a sensitive issue and I absolutely don't want to start
any kind of discussion about the merits or otherwise of LGPL, but I was
wondering if there are any plans to remove the GNU mp library from the
runtime so that it
On Thu, 2007-08-16 at 14:22 +0100, Brian Hulley wrote:
Sounds to me like the simlest solution for you would be if GHC could use
a dynamically linked gmp.dll on Windows. That also sounds like much less
work that replacing gmp completely.
This would certainly make things easier though it
On Thu, 2007-07-26 at 23:51 -0700, Sean Johnson wrote:
Hi Everyone,
Is there some way to install Visual Haskell with VS2005, Express?
Perhaps some workaround or hack?
I believe that free version of VS is specifically designed not to allow
any plugins, you have to pay for the the full version
On Tue, 2007-07-31 at 10:36 -0400, Jan-Willem Maessen wrote:
I think what's meant here is translating something like this:
{-# INLINE f #-}
f x y z = ... f x' y' z' ...
into this:
{-# INLINE f #-}
f x y z = f' x y z
where f' x y z = ... f' x' y' z' ...
That is, shoving (all
On Sat, 2007-07-21 at 16:25 +0200, Marc Weber wrote:
[EMAIL PROTECTED] /pr/source/wxh/wxhaskell-0.9.4 $ ghc-pkg-wrapper-6.6.1
unregister wx
ghc-pkg: cannot find package wx
[EMAIL PROTECTED] /pr/source/wxh/wxhaskell-0.9.4 $ ghc-pkg-wrapper-6.6.1
describe wx
name: wx
version: 0.10.1
On Fri, 2007-07-06 at 08:36 +0200, Ketil Malde wrote:
On Thu, 2007-07-05 at 12:11 -0400, Matthew Danish wrote:
On Thu, Jul 05, 2007 at 11:15:03AM +0200, Christian Maeder wrote:
Is there no way to provide all the extra libs in one debian package for
ghc?
It may be possible to create
On Tue, 2007-07-03 at 12:36 +0200, Srđan Stipić wrote:
I wanted to compile simple Haskell program (simple.hs) to .c and after
that to target platform (x86).
I did the following things:
ghc -C simple.hs
mv simple.hc simple.c
gcc -c simple.c -I/usr/lib/ghc-6.6/include/
And I got the
On Sat, 2007-06-16 at 11:33 +1000, skaller wrote:
However, the libs still aren't fully public if the interfaces
are only private details of the GHC tool chain. Hmmm.
Note of course that it's only been in the last few years that C++ has
stabilised to the point where different implementations
On Mon, 2007-06-04 at 12:31 +0100, Simon Peyton-Jones wrote:
| This is a bit disappointing of course, so how do we fix it. There are
| two possibilities as far as I can see. Either don't let float it, or
| have the rule matcher look through the indirection.
This is a tricky one. One
On Mon, 2007-06-04 at 12:44 +0100, Simon Peyton-Jones wrote:
| So it seems to me that NOINLINE should prevent inlining but not prevent
| calling the worker rather than the wrapper. I don't fully understand how
| NOINLINE interacts with the worker/wrapper transform (or I wouldn't have
| been
On Mon, 2007-06-04 at 14:01 +0100, Simon Peyton-Jones wrote:
| But that allows it to be inlined in phase 0, and that's exactly what I
| don't want. I really do not want this function inlined, I want it to be
| a join point.
Remind me why you really don't want it inlined, ever? Even if it's
Hia folks,
More performance bugs or misunderstandings. Yes, binary serialisation
again.
Consider this example from an instance for the Binary serialisation
class. We get lots and lots of code that looks like this:
data Foo a = Foo Int | Bar ...
instance Binary Foo where
put (Foo a) = putTag
On Sun, 2007-05-20 at 13:42 +0100, Neil Mitchell wrote:
Hi
Want to try also the
Data.ByteString.Base.isSpaceWord8 :: Word8 - Bool
isspace: 0.375
iswspace: 0.400
ByteString: 0.460
Char: 0.672
Not as fast as isspace/iswspace, but quite a bit faster than Char.
Perhaps someone
On Sun, 2007-05-13 at 14:23 +0100, Joel Reymont wrote:
Is there a way to enable all warnings but the following:
Hope/Item/DBDesc.hs:6:0:
Warning: Definition but no type signature for `item_db'
See the users guide section on warnings:
On Fri, 2007-05-11 at 16:05 -0400, Isaac Dupree wrote:
Simon Peyton-Jones wrote:
It's very difficult to get inlining right all the time. Even for a
function marked INLINE, there's really no point in inlining in some
contexts. E.g.
map f xs
(don't inline f).
Would it make
On Fri, 2007-05-04 at 19:28 +0100, Adrian Hey wrote:
Hello,
The GHC users guide says overloading is death to performance if
left to linger in an inner loop and one thing I noticed while
playing about with the AVL lib was that using a HOF and passing
the (overloaded) compare function as an
On Thu, 2007-05-03 at 16:24 +0100, Adrian Hey wrote:
Hello Folks,
Just wondering about this. Please understand I'm not asking why
programs use a lot of stack sometimes, but specifically why is
using a lot of stack (vs. using a lot of heap) generally regarded
as bad. Or at least it seems
On Wed, 2007-05-02 at 16:33 +0100, Neil Mitchell wrote:
Hi
Thanks to dcoutts, I have now come up with an answer. I don't
understand why it works now, but not before.
main = p_System_IO_hGetChar 1
`seq` p_System_IO_hGetChar 2
`seq` putStrLn done
This is fine (though note that
On Mon, 2007-04-30 at 10:05 +0400, Bulat Ziganshin wrote:
Hello Duncan,
Sunday, April 29, 2007, 8:00:56 PM, you wrote:
java/c# libs can't be used with current ghc, so 99% of
Making it possible to use Haskell in mixed language projects with C++
and Java
how ghc/mingw can be used
On Mon, 2007-04-30 at 11:02 +0400, Bulat Ziganshin wrote:
Hello Duncan,
Monday, April 30, 2007, 10:11:09 AM, you wrote:
how ghc/mingw can be used with java? :)
I expect it's quite tricky! :-)
I'm not claiming it works or is easy, I was just commenting that making
so, you agree
On Sun, 2007-04-29 at 10:38 +0400, Bulat Ziganshin wrote:
Hello Albert,
Sunday, April 29, 2007, 2:51:24 AM, you wrote:
Is it just me who thinks this is a silly idea? Why should GHC include a
C++ compiler?
.NET literates, will benefit from the many libraries available in .NET.
Can
On Thu, 2007-04-26 at 17:07 +0400, Bulat Ziganshin wrote:
Hello Ian,
Thursday, April 26, 2007, 3:22:23 PM, you wrote:
The (Interactive) Glasgow Haskell Compiler -- version 6.6.1
can you please include in win32 distro c++ compiler, as it was done
before and as it requested by trac
On Wed, 2007-04-25 at 08:56 +0100, Simon Peyton-Jones wrote:
Duncan,
I implemented this a couple of weeks ago but forgot to push it. Now
INLINE pragmas survive across interface files. I hope it's useful.
Fantastic, thanks Simon. I'll try it out in Data.Binary in the next few
days and
So I'm trying to program the GHC term rewriting system again (ie the
mighty simplifier) and it's not doing what I want it to do without me
using unnecessarily large hammers.
The crux is that I have a simple function that I want to be inlined
early so that my other rules can match on the thing it
On Fri, 2007-04-06 at 08:18 +0100, Simon Peyton-Jones wrote:
I wonder if this package.conf hacking would be a good topic for a GHC wiki
page? Somewhere here:
http://haskell.org/haskellwiki/GHC
Done.
___
Glasgow-haskell-users mailing list
On Thu, 2007-04-05 at 17:20 -0500, Chris McCraw wrote:
1) I'd like to embed an additional library search directory in ghc so
that it does the equivalent of -L/path/to/extra/dir every time it's
used to link something. Unfortunately, our libgmp resides in a nonstandard
directory and so *every
On Thu, 2007-03-01 at 11:04 -0800, Jeremy Shaw wrote:
Some open questions are:
a) how do you detect that you are running in the threaded RTS
Currently the nearest approximation is:
Control.Concurrent.rtsSupportsBoundThreads :: Bool
Duncan
___
On Mon, 2007-02-26 at 13:33 -0800, Chad Scherrer wrote:
The new Cray XMT seems to target exactly the same kind of analytic
problems where Haskell excels:
http://www.cray.com/products/xmt/
I'm not a hardware guy, but this seems like a natural fit with the
recent advances in SMP Haskell. I
Would you say this the same as the one described in the user guide?
http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs.html#bugs-ghc
GHC's inliner can be persuaded into non-termination using the
standard way to encode recursion via a data type:
data U
On Sun, 2006-11-19 at 17:54 +, Claus Reinke wrote:
I noticed that ByteString is drastically slower than String if I use
cons a lot. according to the source, that is expected because of
the memcpy for the second parameter.
but it seems to me that construction should be able to play the
On Fri, 2006-11-17 at 23:29 +, Manuel M T Chakravarty wrote:
This feature has been often requested, becuase it allows you to
package a dictionary into an ordinary (non-existential) data type, and
be able to use it.
NOTE: the Haskell 98 syntax for data type declarations
On Thu, 2006-10-19 at 21:10 +0400, Bulat Ziganshin wrote:
btw, writing this message i thought that
-fconvert-strings-to-ByteStrings option will give a significant boost
to many programs without rewriting them :)
This kind of data refinement has a side condition on the strictness of
the
Pinning the arrays gives the GC much less flexibility. Especially if
your objects are small. It means that the GC can't move things to
compact the heap and you'll end up with lots of holes in between heap
objects of things that were collected but the space couldn't be re-used
because other objects
On Wed, 2006-10-18 at 11:31 +0200, Andreas Marth wrote:
With ghc-6.6 there is a change in module Data.Array.MArray which now
includes a function
getBounds :: (MArray a e m, Ix i) = a i e - m (i,i) but it misses the good
old
bounds [which had type bounds :: (HasBounds a, Ix i) = aie - (i,i)].
Christian,
I've reported this bug here:
http://hackage.haskell.org/trac/ghc/ticket/951
Please add any further info you think necessary.
Duncan
On Wed, 2006-10-18 at 11:21 +0200, Christian Maeder wrote:
Duncan Coutts schrieb:
Try SRC_HC_OPTS = -optc-mcpu=ultrasparc -opta-mcpu=ultrasparc
On Mon, 2006-10-16 at 17:42 +0200, Bas van Dijk wrote:
On Monday 16 October 2006 12:41, Duncan Coutts wrote:
This is a problem with the way we have packaged it for Gentoo. We know
the source of the problem and will fix it soon.
Great, thanks.
On Monday 16 October 2006 12:46, Clemens
On Sun, 2006-10-15 at 18:05 +0400, Serge D. Mechveliani wrote:
Dear Haskell implementors,
I keep on facing a frightening problem of the laziness support.
[snip]
I wonder how to avoid these numerous cost pitfalls.
Maybe, the complier could do more optimization?
There are important
On Fri, 2006-10-13 at 09:30 +0200, Christian Maeder wrote:
Christian Maeder schrieb:
I've created ghc-6.6 under solaris. This did only work with SplitObj=No
in mk/build.mk. (There was an early split error, that I could reproduce.)
Here is the output of that split error:
On Thu, 2006-10-12 at 15:28 +0200, Christian Maeder wrote:
I've created ghc-6.6 under solaris. This did only work with SplitObj=No
in mk/build.mk. (There was an early split error, that I could reproduce.)
When trying out this compiler, I got the following error (that I only
post for the
On Mon, 2006-10-09 at 13:55 +0200, Christian Maeder wrote:
Duncan Coutts schrieb:
On Fri, 2006-09-22 at 17:19 +0200, Christian Maeder wrote:
A simple script for the pgmF command
The only disadvantage is that the filename in error and warning messages
is quite useless:
I think you
On Sun, 2006-10-08 at 18:55 -0500, Brian Smith wrote:
On 10/2/06, Ian Lynagh [EMAIL PROTECTED] wrote:
We are pleased to announce the Second Release Candidate phase
for GHC 6.6.
I am using release candidate 2. I noticed some problems with Cabal, so
I uninstalled
Hi all,
I've put up a tarball for the fourth 1.16 Cabal release candidate:
http://www.haskell.org/cabal/release/cabal-1.1.5.9.4/cabal-1.1.5.9.4.tar.gz
I had been hoping that this would be the final RC. One bug I've
uncovered is that building the haddock docs for HUnit when cpphs is
installed
On Thu, 2006-10-05 at 10:55 +0100, Simon Marlow wrote:
Ian Lynagh wrote:
On Tue, Oct 03, 2006 at 04:59:58PM -0400, Ravi Nanavati wrote:
If I understand the way things work, GHC decides whether or not to emit
the -fno-unit-at-a-time flag in -fvia-C compilation based on whether or
not the
On Mon, 2006-10-02 at 17:06 +0200, Rene de Visser wrote:
Ian Lynagh [EMAIL PROTECTED] schrieb im Newsbeitrag
news:[EMAIL PROTECTED]
http://www.haskell.org/ghc/dist/current/dist/
Hello Ian,
Is it on purpose that the lastest windows build does not include
cabal-install?
Yes that is
On Fri, 2006-09-29 at 11:02 +0200, Christian Maeder wrote:
Map (and Set) use (unboxed) Int internally. So bigger Maps and Sets are
not possible.
Furthermore, unlike lists which can be bigger than can fit in memory,
Data.Map and .Set are strict structures, so you can never have more than
2^32
On Sun, 2006-09-24 at 01:28 +0400, Bulat Ziganshin wrote:
Hello Duncan,
Sunday, September 24, 2006, 12:22:38 AM, you wrote:
after program prints 40 mb allocated look at Task Manager indication
- it shows that two times more memory actually in use. it seems that
problem is only with
On Sat, 2006-09-23 at 13:58 +0400, Bulat Ziganshin wrote:
Hello glasgow-haskell-users,
the attached program show up the bug in mallocForeignPtrBytes (and
newPinnedByteArray#) implementation - it allocates two times more
memory as requested. The bug seen both on 6.6rc and june 6.4 windows
On Fri, 2006-09-22 at 17:19 +0200, Christian Maeder wrote:
Christian Maeder schrieb:
Duncan Coutts schrieb:
There is iconv. It could be used as a pre-processor with ghc's -F -pgmF
-optF flags.
NB: -F is missing in the Flag reference
A simple script for the pgmF command
#!/bin
On Thu, 2006-09-21 at 10:15 +0200, Christian Maeder wrote:
Duncan Coutts schrieb:
On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote:
How can I convince ghc version 6.5.20060919 to accept latin1 characters
in literals?
I wish to keep source files (containing umlauts in strings
On Wed, 2006-09-20 at 18:14 +0200, Christian Maeder wrote:
How can I convince ghc version 6.5.20060919 to accept latin1 characters
in literals?
I wish to keep source files (containing umlauts in strings) that can be
compiled by either ghc-6.4.2 and ghc-6.6.
You can use numeric escapes like
On Wed, 2006-09-13 at 01:17 -0500, Brian Smith wrote:
After further review, I can see that the test suite also requires
'network,' 'html,' and 'mtl' for all the tests to pass.
Maybe we need to separate the packages into three groups: core, tests,
and extras, where all the packages required
Hi all,
I've put up a tarball for the third 1.16 Cabal release candidate:
http://www.haskell.org/cabal/release/cabal-1.1.5.9.3/cabal-1.1.5.9.3.tar.gz
This is also included with very recent GHC 6.5 snapshots.
Please test this with your packages and report any issues to
cabal-devel@haskell.org
On Mon, 2006-09-11 at 13:24 +0200, Johan Tibell wrote:
Niklas Broberg patched haskell-src-exts so it should work using the
latest version from darcs.
That's great.
Do you know if there will be a release with a tarball? Generally distros
only package released versions. Alternatively if the
Hi folks,
Over the weekend Lennart Kolmodin tested all of Gentoo's Haskell
packages with the latest GHC 6.6 RC snapshot. Here is his report of what
failed, and how:
http://www.haskell.org/~gentoo/gentoo-haskell/projects/GHC-6.5-failures.html
You'll note that there are some common ones, like
On Tue, 2006-09-05 at 12:12 +0100, Malcolm Wallace wrote:
HaXml (no longer builds)
In what way does HaXml fail to build for Hugs? Is it easily
fixable?
... and there's the famous Data.FiniteMap.
So does anyone have any objections if I go ahead and commit the
replacement
On Tue, 2006-09-05 at 12:19 +0100, Ross Paterson wrote:
On Tue, Sep 05, 2006 at 12:12:00PM +0100, Malcolm Wallace wrote:
HaXml (no longer builds)
In what way does HaXml fail to build for Hugs? Is it easily
fixable?
... and there's the famous Data.FiniteMap.
So
Is it too late to ask that Data.FiniteMap not die just yet?
There are a number of progs/libs that this affects. It's not that people
do not want to use the new Data.Map, but people are worried about having
to drop support for earlier compilers. Data.Map only appeared in 6.4
iirc. So this forces
On Mon, 2006-09-04 at 14:06 +0200, Duncan Coutts wrote:
Is it too late to ask that Data.FiniteMap not die just yet?
There are a number of progs/libs that this affects. It's not that people
do not want to use the new Data.Map, but people are worried about having
to drop support for earlier
On Thu, 2006-08-31 at 11:29 +0100, Malcolm Wallace wrote:
Bulat Ziganshin [EMAIL PROTECTED] wrote:
It makes sense to me that the above behaviour is seen: length is
now a good
consumer, but it generates 1+(1+(1+(1+... as it is consuming, and
this causes a stack overflow. I don't
Just in case anyone was wondering why you might want GHC to work well on
MIPS...
http://www.movidis.com/products/rev_spec.asp
A 16x core 600Mhz low-power MIPS machine pre-installed with Debian.
With the new smp-capable ghc, such a box might be rather good for some
Haskell server application.
On Mon, 2006-08-14 at 10:12 +0100, Simon Peyton-Jones wrote:
[Narrowing to ghc users only]
That's odd. I tried it (the HEAD) and it worked fine. Input and output
below
You'll notice that the binding for 'realloc' got floated into the branch
of the case (that's FloatIn), but it is never
This doesn't have the effect I expected:
loop xs =
case blah of
One thing - ... loop
The other - ... realloc ...
where
{-# NOINLINE realloc #-}
realloc = do
something
loop ...
My intention here was that the loop would not contain the code for
realloc and that
So now that GHC is so good at producing really fast low level code (see
ByteString benchmarks) we start to encounter low level gubbins where to
get the fastest possible code we need slightly more influence over
branch prediction.
In the code for ByteString's 'writeStrUp/Dn' functions we're doing
On Mon, 2006-08-07 at 09:04 -0400, Vyacheslav Akhmechet wrote:
The latest stable release seems to have some sort of a problem with
the graphics library (the general one as well as the wrapper used in
SOE). Opening a window takes more than a couple of minutes (on Windows
XP). When I run an
On Mon, 2006-08-07 at 16:12 +0100, Simon Peyton-Jones wrote:
By this code is currently broken, I'm sure you are right, but which
code you mean exactly? The Win32 binding for GHC? Or the Hugs Graphics
Library (HGL) implementation for GHC?
The HGL for GHC and therefore also the current SOE
201 - 300 of 394 matches
Mail list logo
