I'd be interested in any progress here -- we noticed issues with
optimisations in the stream fusion package across module boundaries
that we never tracked down. If there's some key things not firing,
that would be good to know.
I suspect that if all modules are compiled -O0, then you
With the upcoming switchover to git, has any thought gone into merging
in the libraries into the main ghc tree
The libraries are going to remain under darcs, because they are shared
with other haskell compilers.
Regards,
Malcolm
___
On 12 Aug 2008, at 01:35, Manuel M T Chakravarty wrote:
Ah, good point! Changing ghc to git means *all* developers of boot
libraries need to use git *regardless* of what repo format the boot
libraries are in. After all, they need to validate against the
current ghc head before pushing.
Manuel wrote:
| It is worth pointing out that I *never* validate against ghc head
when
| I commit to the core libraries.
Sorry, but I think the only reason its halfway acceptable is that
Malcolm didn't break the GHC build yet. If he does, I'll be
screaming as loudly as for anybody
I don't think that is the right policy. Everybody (including Malcolm)
should validate.
If you contribute code to the linux kernel, comprehensive testing of
the code is a requirement, too.
The analogy is flawed. It is like asking the developers of _gcc_ to
ensure that the Linux kernel
I think an even better analogy is probably comparing it to developer
of GCC changing the libc implementation of another compiler or vice
versa.
Our shared libraries do not belong to any one compiler. They are joint
creations, with a lot of community (non-compiler-hacker) involvement.
John Meacham [EMAIL PROTECTED] wrote:
(bring back hmake! :) ).
It never went away...
http://www.cs.york.ac.uk/fp/hmake
I even have the idea to allow hmake to read the .cabal file format for
configuration data (although that is waiting for a delivery of round
When the -XUnicodeSyntax option is specified, GHC accepts some Unicode
characters including left/right arrows. Unfortunately, the letter
greek lambda cannot be used. Are there any technical reasons to not
accept it?
The greek lambda is a normal lower-case alphabetic character - it can
be used
test2 :: Box a - a - [a]
test2 box x = go x
where
-- go :: a - [a]
go y = [(val box), y]
Couldn't match expected type `a1' against inferred type `a'
You need to turn on {-# ScopedTypedVariables #-}.
See
The suggested remedy of commenting out the
line reading SRC_HC_OPTS += -fvia-C in the Makefile won't work, as
that line isn't there anyway.
In case it is not obvious from what other people have said, way back
in the days of ghc-6.2, you got -fvia-C by default, whether it was
specified on
Had you deprecated the non-threaded RTS, we would probably have no
problems described in ticket #2848 :-/
I think you'll have to deprecate it anyway, because it will be more
and more difficult to maintain two versions of code,
we may conduct small survey on amount of usage of old RTS
basically, IMCROSS installs a couple new gccs with names like
/usr/local/bin/i386-mingw-gcc and so forth, is there some way to get
ghc to use said non-native compiler as its back end?
I don't know about IMCROSS specifically, but earlier this year Sylvain
Nahas adapted the build system of nhc98
Simon Marlow marlo...@gmail.com wrote:
Malcolm Wallace wrote:
For the only application I tried, using the threaded RTS imposes a
100% performance penalty - i.e. computation time doubles, compared
to the non-threaded RTS. This was with ghc-6.8.2, and maybe the
overhead has improved
It seems that the problem you have is that moving to the multithreaded
runtime imposes an overhead on the communication between your two
threads, when run on a *single CPU*. But performance on a single CPU
is not what you're interested in - you said you wanted parallelism,
and for that you
Kwanghoon Choi lazysw...@gmail.com wrote:
=
instance Arg a = Arg [a] where
pr _ = [ ++ pr (undefined :: a) ++ ]
=
You want to use `asTypeOf`, with a lazy
Currently, hsc2hs (as shipped with GHC) cannot be used with just
hsc2hs Foo.hsc
as it cannot find HsFFI.h
The hsc2hs repo includes a shell script (yes, I know, no good on Windows)
called hsc2hs.wrapper that already adds some default arguments.
(nhc98 has a modified version of the script,
Here is an apparent bug in ghc's specialisation rules. The rewrite rule
generated by a SPECIALISE pragma seems to want to pattern-match on exact
dictionaries (as well as types). But the compiler is not necessarily
able to fully resolve dictionaries before the rules are supposed to
fire.
First,
Simon Marlow marlo...@gmail.com wrote:
stdout should be flushed when the program exits, regardless of whether
it exits as a result of a clean exit or an exception. I've just
checked the code, and that's certainly what is supposed to happen.
If anyone has evidence to the contrary, please
Peter Hercek pher...@gmail.com wrote:
http://hackage.haskell.org/trac/ghc/wiki/ExplicitCallStack
I was writing about a way how to maintain the stack as described in
point 6 of the page (provided that point is about dynamic stack).
The whole page (including point 6) is about explicitly
Claus Reinke claus.rei...@talk21.com wrote:
A while ago, I needed lots of fairly small positive numbers,
together with a small number of flags for each, so I thought
I'd switch from Int to Word, and map the flags to bits.
Since there are few guarantees about the size of a Word (or Int),
Max Bolingbroke batterseapo...@hotmail.com wrote:
2009/3/27 Simon Marlow marlo...@gmail.com:
I have a fix for num012 (the test is broken), but I still don't know
what's going on with num009.
num009 has been broken on OS X for as long as I can remember :-).
If it is any help, I can
I would hereby like to propose that the
ExistentialQuantification extension is deprecated.
It is worth pointing out that all current Haskell implementations (to
my knowledge) have ExistentialQuantification, whilst there is only one
Haskell implementation that has the proposed replacement
In C code, I want to save a complex data strcuture defined in
haskell and pass it back to a haskell function at certain time.
Look up StablePtr in Haskell's FFI spec.
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Your function is not equivalent:
perm _|_ = _|_
permutations _|_ = _|_ : _|_
I have a vague memory that the library version diagonalises properly,
so that if you give it a lazy infinite input, it still generates
sensible output lazily. If so, this important property should be
noted in
i'm not an expert, but: once value of thunk is evaluated, it's
written
back by code called mutator
Whilst that is indeed mutation, it is not what is usually referred to
as the mutator in the context of garbage collection. Quite simply,
the mutator is the actual running program, as
Say you are
implementing a network server, for example -- you don't want
to have big spikes in the request latency due to GC.
We think
concurrent GC is unlikely to be practical in the Haskell
setting, due to the extra synchronisation needed in the
mutator.
-- Simon Marlow
It
The ghc documentation at
http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html
says the following:
-package-name foo
Tells GHC the the module being compiled forms part of package
foo. If this flag is omitted (a very common case) then the default
package main is
I've the 6.10.4 version installed on my MacOS X 10.6 OS. Have I to
uninstall this version of GHC before installing the Mac .pkg for the
6.12.1?
Most installer packages (_except_ for MacOS) allow you to have
multiple previous versions of ghc - they are simply left in place (but
must now
Too late. We had a stable link, I used it, Google used it, blog posts
were written that linked to it, I've emailed my wife links to it, I've
put them in Word documents, I've posted them on internal intranets.
You can't create a link, put content behind it, then move the content
- it just breaks
module Main where
import Foo (Bar.bar)
GHC apparently accepts this code, but I can find no mention of such a
feature in the GHC docs.
It certainly is an extension beyond Haskell'98 and Haskell 2010, which
do not permit qualified names in import lists. I cannot think for any
use for such
Would you find the extra information useful, or just noise?
i.e. should we show error spans by default?
I certainly wouldn't find it distracting, and I think it could be
quite useful in many cases. I vote for turning it on by default.
I agree.
+1.
It is a feature I have always found useful
The flag -P for traditional gnu cpp (or --noline for stand-alone
cpphs) should suppress the initial #line noise.
Does ghc still fail to recognise a module-start pragma, even if the
only characters preceding it are whitespace?
I intended to give an example.
file foo.h
#if
(ii) If [pads| is a lexeme, then some list comprehensions become
illegal,
I am not myself a TH or QQ user, but it has always bothered me
slightly that the syntax for them steals some valid list comprehensions.
Of the alternative syntaxes you suggest...
My gut feel is to go with [|pads|
You will be more likely to get an answer on the ghc-users mailing list
(cc'ed). The ghc developers rarely follow -cafe.
On 1 Jan 2011, at 20:36, Jane Ren wrote:
Hi,
Does anyone know what GHC module gets the AST and type info of some
source code? This is the GHC module that converts all
On 10 Jan 2011, at 14:02, Gregory Collins wrote:
+1. I don't have a lot of skin in this particular game (I'm not
currently a GHC contributor and am unlikely to become one in the near
future), but I can offer some anecdotal evidence:
As another non-GHC contributor, my opinion should probably
On 10 Jan 2011, at 22:37, Daniel Peebles wrote:
So the basic point seems to be: if you know how to use a tool, you
don't usually curse and swear when you use it. If you don't, you
tend to swear a lot!
There is a meta-point though - how easy is it to learn the tool?
Regards,
Malcolm
Ranjit,
I'd like to build a hoogle database that indexes the GHC source.
Can anyone point me to how I might do that? (Or better, to a
preexisting database?)
The author of Hoogle, Neil Mitchell, is currently on holiday, but I'm
sure he will have some good advice for you when he returns.
The final stumbling block is getting the local webserver (hoogle
server)
to also search the above database. I'm sure there must be some
simple way I
can pass the name of the database as an argument when I boot up the
server,
but I can't seem to find it...
Have you found the various
hsc2hs converts
(#const sizeof(struct stat))
(#peek struct stat, st_mtimespec)
to
108
36
but the correct values are
144
32.
Is this a bug of hsc2hs?
Not directly. hsc2hs calls the C compiler to determine these numbers. It
seems it is calling gcc-4.0 rather than gcc-4.2. It
On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote:
I would be fantastic if XCode wasn't a dependency. ...
Not to detract at all from the work of the wonderful GHC and Haskell
Platform contributors in any way. For me it would just make it that
much easier to convince mac-using friends to give
On 10 Jun 2011, at 02:15, Manuel M T Chakravarty wrote:
Anybody who is halfway serious about developing software on a Mac will have
Xcode installed anyway.
As the original poster clarified, the motivating use-case is education
(specifically a class of 12-13 year olds.) These are not
As one of the few people who has habitually used Haskell'98 wherever possible,
I favour plan A. As I recently discovered, in ghc 7 it is already very fragile
to attempt to depend on both the base and haskell98 packages simultaneously.
In most cases it simply doesn't work. Removing those few
I notice that ghci is loading integer-simple before loading base. This at
least explains why it cannot find a symbol from the base package - it hasn't
been loaded yet. So the question is why does integer-simple use any function
from the base package at all? I'm fairly sure that the dependency
Einar Karttunen [EMAIL PROTECTED] writes:
It appears that the console is not reset correctly with
System.Console.SimpleLineEditor. The terminal does not
echo characters until it is reset.
The issue here is the order in which the library makes calls to
hSetBuffering and system(stty icanon
Duncan Coutts [EMAIL PROTECTED] writes:
I'm looking for some advice on profiling and any suggestion on what
might be going on with this program.
One suggestion might be to serialise (key,value) pairs to file as
they are first encountered, rather than waiting until they are all
inside
Simon Marlow [EMAIL PROTECTED] writes:
We are finally at the release candidate stage for GHC 6.4. Snapshots
with versions 6.4.20050209 and later should be considered release
candidates for 6.4.
Using: ghc-6.4.20050209-i386-unknown-linux.tar.bz2
$ cat hello.hs
main = putStrLn hello
Simon Marlow [EMAIL PROTECTED] writes:
We are finally at the release candidate stage for GHC 6.4.
Please test if you're able to, and give us feedback.
In versions 5.00 = ghc = 6.2.2, the result of
ghc -v 21 | head -2
was something like
Glasgow Haskell Compiler, Version 6.2.2,
Simon Marlow [EMAIL PROTECTED] writes:
and how do you find out what $libdir refers to...?
ghc --print-libdir
Cool. Will fix hmake to use it.
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
$ ghc-pkg-6.4.20050209 --show-package=base --field=import_dirs
[/usr/malcolm/local/lib/ghc-6.4.20050209/imports]
yet
$ ghc-pkg-6.4.20050209 --show-package=base-1.0 --field=import_dirs
ghc-pkg: cannot find package base-1.0
$ ghc-pkg-6.4.20050209 --list-packages
Simon Marlow [EMAIL PROTECTED] writes:
$ ghc-pkg-6.4.20050209 --show-package=base-1.0 --field=import_dirs
ghc-pkg: cannot find package base-1.0
BTW, we recommend you migrate to using the new command-line syntax for
ghc-pkg at some point.
Documented where? The GHC user guide
Simon Marlow [EMAIL PROTECTED] writes:
I'm having some trouble with the XML docbook formatting tools right now.
If you have a source tree, 'make html' should work in
ghc/docs/users_guide.
Sadly, not.
$ cvs checkout ...
$ cd fptools
$ autoreconf
$ ./configure
[]
Please test if you're able to, and give us feedback.
It looks like GADTs (or something else new) conflict with normal
Haskell'98 type inference. The following example used to compile
just fine with all previous versions of ghc and nhc98.
$ ghc-6.4.20050210 -package lang-c -o Parse.o
Seth Kurtzberg [EMAIL PROTECTED] writes:
There has to be one, because the problem occurs when you compile gcc
with gcc. I'll look for a specific bug report. It happens much more
frequently with 3.x than with 2.95, in my testing, but that was not a
test of compiling Haskell, so I have no
Seth Kurtzberg [EMAIL PROTECTED] writes:
Simon, you'll never give up. The crashes are absolutely repeatable.
The fact that I haven't identified a deterministic way to reproduce them
does not in any way imply that a deterministic way to reproduce them
does not exist. And, as I've said,
Simon Marlow [EMAIL PROTECTED] writes:
It seems the ghc 6.4 release candidates' configure scripts fail if you
run them in a directory structure containing a space.
Quite possibly. No doubt we'd have to add a million quotes to the build
system to fix this; it's not going to happen any
Just a quick comment on a couple of things Brian Strand writes:
Or is ghc/Haskell established enough that
the existence of some Haskell compiler is taken for granted nowadays?
Ghc is not written in pure Haskell - it is written in Ghc Haskell,
i.e. it uses many extensions and internal libraries
Simon Peyton-Jones [EMAIL PROTECTED] writes:
I think I've fixed this (on the head anyway; simon will merge to branch
shortly). Care to try again?
Yup, the toplevel rigid type-variable problem seems to have been fixed,
thanks. nhc98 now builds as expected with ghc-6.4.
BTW, there seems to be
Ian Lynagh [EMAIL PROTECTED] writes:
ghc-6.4.20050228-src.tar.bz2
I think you have unswapped the first two lines of
ghc -v 21 | head -2 but not changed Reading back to Using, so
old hmakes are still broken (old includes the latest release, I
believe).
There are a couple of other
Wolfgang Thaller [EMAIL PROTECTED] wrote:
I've uploaded a Mac OS X installer based on the stable tree from March
2nd + the patches I committed yesterday at:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050302.pkg.zip
$ ghc --version
dyld: /usr/local/lib/ghc-6.4/ghc-6.4 can't
Another Mac OS X installer:
http://opeongo.cas.mcmaster.ca/~wolfgang/GHC-6.4.20050308.pkg.zip
Works fine for me too.
The double-clickable icons for GHCi are great,
When I double-click the icon, I get *two* Terminal windows started, one
running ghci, the other just an ordinary shell. Is
Andy Moran [EMAIL PROTECTED] writes:
With 3.4, changes were made to the
-traditional version of the C preprocessor that make it incompatible
with the way in which many of the Haskell modules in the GHC source tree
reify make/build variables as Haskell strings.
Andy Moran [EMAIL PROTECTED] writes:
I notice that cpphs understands CPP stringification (if invoked with
--hashes). Most of the gcc 3.4 failures (in fact, all of that I've seen)
have to do with fooling -traditional into turning macro constants into
Haskell strings, which can more readily
Andy Moran [EMAIL PROTECTED] writes:
-- hackery to convice cpp to splice GHC_PKG_VERSION into a string
version :: String
version = tail \
\ GHC_PKG_VERSION
OK, it turns out that this is pretty tricky to do in cpp, even with
full scope of -ansi or -traditional behaviour. In fact, the
Niklas Broberg [EMAIL PROTECTED] writes:
when I try to use runghc to execute cgi scripts in apache (on redhat
linux), they all fail with with the message HOME: getEnv: does not
exist. I assume this means that GHC is trying to find the HOME dir of
the user for some reason, and fails since
Is it true that on unix, tools like ghc-pkg-6.2.2 and ghc-pkg-6.4
may co-exist, but on Windows the version number is not present,
so a single executable is simply called ghc-pkg.exe?
If so, how do Windows users deal with having more than one version
of ghc installed simultaneously? Is this just
Frederik Eaton [EMAIL PROTECTED] writes:
By the way, can I make a request to have the hmake default be to use
the environment?
Ian Lynagh recently added this capability to hmake, but it wasn't
documented (until yesterday). The relevant option is
hmake-config add-dyn ghc
which causes the
Niels [EMAIL PROTECTED] writes:
since my application takes up way to much memory, i decided to profile it
(compile d it with -prof and -auto-all). After running it with +RTS -hc, it
shows a graph that reaches a peak at around 85mb.
However, when i check the memory usage with 'top' i see the
Henrik Nilsson [EMAIL PROTECTED] writes:
I get an error No instance for (Fractional a) arising from the use of
'/' This seems odd to me, since Div is constrained to have
fractional arguments. Is there something obvious I'm missing?
Unless GADTs are handled specially, and I don't
Marc A. Ziegert [EMAIL PROTECTED] writes:
I'm searching for a good mathematical oriented introduction to the
theory of lambda calculus or other theoretical foundations of Lisp/
Haskell, i.e. monads or such (of course in the web there are much
hints, but what is the best for
I know this will be going back a bit, but I have a problem with
compiling some code with ghc-5.04.3. The same code goes through
ghc-6.2 with no problems, and until recently there were no problems
with ghc-5.04.3 either. But a recent code change has caused the
following warning messages from
Frederik Eaton [EMAIL PROTECTED] writes:
I'm looking for a build system for my projects which will correctly
handle all of ghc's dependencies. I.e. every time I ask it to rebuild
an output file, it will only do the minimum amount of compilation
necessary.
'hmake' is pretty good at what you
I've imported all our SourceForge tracker data into a new Trac
installation:
Just one minor nit: the front page URL tells me a lot about Trac,
but nothing at all about ghc!
Eventually, I worked out that I needed to click on View tickets,
but it took a while to realise this.
Regards,
Jan-Willem Maessen [EMAIL PROTECTED] writes:
- Fetch elimination for imperative reads:
writeIORef r e acts readIORef r
=== writeIORef r e acts return e
This transformation is valid only on single-threaded systems.
If there is any possibility of an IORef being shared across
Simon Marlow [EMAIL PROTECTED] writes:
I should have said that if 'acts' blocks, then the transformation is
invalid.
Well that is exactly what I was assuming when I said that the
transformation is invalid. In the general case, for some arbitrary
actions between the write and the read
[previously sent by mistake to Simon only - new para at end]
Simon Marlow [EMAIL PROTECTED] writes:
Now, take the original program, but change the creation of m2 to
newMVar (), i.e. m2 starts off full. Is the transformation valid now?
Well maybe, because in some interleavings acts does not
Simon Marlow [EMAIL PROTECTED] writes:
In the general case, for some arbitrary
actions between the write and the read (excluding another write of
course), there is no guarantee that the IORef remains unmodified.
This is an analysis that's performed all the time
Simon Marlow [EMAIL PROTECTED] writes:
Malcolm, Ross - since you both also use the CVS libraries tree, is it
going to be possible for you to switch to using darcs to get the
libraries? Any idea how long you'll need?
I've been looking at the cvs configuration file CVSROOT/modules.
I /think/
Ross Paterson [EMAIL PROTECTED] writes:
No problem for me if you switch over at any time. But how about having
a separate repository for each library package?
Seconded.
Regards,
Malcolm
___
Glasgow-haskell-users mailing list
Simon Marlow [EMAIL PROTECTED] writes:
The aim is to eventually switch over to using darcs for our revision
control. The point of this message is to find out what constraints
people have that will affect when we can throw the switch.
One thing it occurs to me to ask is what will be happening
[EMAIL PROTECTED] (Donald Bruce Stewart) writes:
One thing it occurs to me to ask is what will be happening to CVS
commit messages, once the switchover to darcs happens?
I originally wrote this script as a temporary fix until darcs supported
post-apply hooks. If it does now, perhaps
Simon Marlow [EMAIL PROTECTED] writes:
But how about having a separate repository for each library
package?
The time to mention this would have been a few weeks ago when I proposed
the current scheme :-)
Err, I think I did...
I think it /would/ actually be nicer to split up the
Sven Panne [EMAIL PROTECTED] writes:
I've been looking at the cvs configuration file CVSROOT/modules.
I /think/ the procedure is something like changing this:
nhc98src-d nhc98 nhc98
nhc98libraries -d nhc98/src/libraries fptools/libraries
nhc98 -a
John Goerzen wrote:
* I will re-convert all of the top-level directories in the current
libraries darcs repo, except for: doc, mk, and Cabal
* Each new repo will be under darcs.haskell.org/packages
Inspired by the new browsable interface to the libraries repo at
John Goerzen [EMAIL PROTECTED] writes:
Meanwhile, I noted that the HaXml repo on darcs.haskell.org seems
to be a verbatim copy of the darcs repo at York.
Ahh. You are correct.
Re-converting now, since you've presumably committed patches to the
darcs side, is probably not going to be
Sven Moritz Hallberg [EMAIL PROTECTED] writes:
I'm running GHC and GCC head-to-head on the task of adding a bunch of
long IOUArray-Vectors really fast. My machine is a Linux-ppc PowerBook
and gets a runtime for the GHC-compiled binary that's about 10x as long
as for GCC.
Is it possible that
Chris Brown [EMAIL PROTECTED] writes:
ld: Undefined symbols:
_TypeRep_AClass_stauic_info
I have noticed that there are spelling mistakes in these error messages.
_TypeRep_AClass_stauic_info
should be
_TypeRep_AClass_static_info
Earlier there was something with
DISCASD
instead of
I think many would be grateful if a podcast were made of this event
such that those who missed it can still watch the presentations.
+1. A podcast would be perfect, posting minutes would be next in line.
If the Hackathon goes ahead, recording a video podcast of the event
should be
Christian Maeder [EMAIL PROTECTED] wrote:
It doesn't work under solaris and under linux [1] my nightly
compilation jobs are killed every tuesday morning (!) for some
reason that i cannot reproduce. I suspect the threaded RTS and heavy
load. I had no such problems with ghc-6.4.1 before.
A
[EMAIL PROTECTED] (Donald Bruce Stewart) wrote:
So what am I doing wrong? And is there any way to ask the compiler
to give a warning if the RULES pragma contains errors?
In this case, it's because it's missing -fglasgow-exts, I think.
Ah, thank you. The missing (and undocumented)
Malcolm Wallace [EMAIL PROTECTED] wrote:
Ah, thank you. The missing (and undocumented) option.
Actually, now I came to submit a patch to the manual, I discover that it
/is/ documented, but at the beginning of section 7. (But on the index
page on the web, the link to section 7 is two whole
Marc Weber [EMAIL PROTECTED] wrote:
My purpose: After having found the a function I want to use it without
having to search where does it belong to and where does it come from.
I want it beeing as up to date as the installed libraries.
You can download Hoogle as a command-line tool, and give
Joel Reymont [EMAIL PROTECTED] wrote:
Thanks for the tip! I'm _really_ interested in why it takes 55 min on
Linux and 3+ hours on Mac Intel, though. Any clues?
Building a compiler generally reads/touches/creates a very large number
of files. So one possibility is the relative efficiency of
Joel Reymont [EMAIL PROTECTED] wrote:
Thanks for the tip! I'm _really_ interested in why it takes 55 min on
Linux and 3+ hours on Mac Intel, though. Any clues?
Another thought. The ghc HACKING guide has this to say:
The GHC build tree is set up so that, by default, it builds a
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 think we can fix this while
staying with fold/build fusion,
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 (compatibility) implementation of Data.FiniteMap to the main
So does anyone have any objections if I go ahead and commit the
replacement (compatibility) implementation of Data.FiniteMap to the
main repository for packages/base?
I'd rather see HaXml updated to use Data.Map, perhaps with a
compatibility layer for older GHCs.
OK, I've looked more
Luke Worth [EMAIL PROTECTED] wrote:
I just installed GHC 6.6 using the PPC binary installer on Mac OS X.
I'm having some trouble getting debuggers to work; I have tried both
plargleflarp (buddha) and Hat. Neither of them will compile on GHC
6.6 on Mac yet.
As an interim measure, I have
Simon Marlow [EMAIL PROTECTED] wrote:
The difference is subtle. The semantics of seq and pseq are
identical; however, GHC can see that seq is strict in both its
arguments and hence could choose to evaluate them in either order,
whereas pseq is only strict in its first argument as far as
Deborah Goldsmith [EMAIL PROTECTED] wrote:
I checked and the Mac OS X PowerPC binary distribution does not have
this problem; only Mac OS X Intel.
Is it possible that the Intel distro built the OpenGL package using
Cabal, but the PowerPC distro used Makefiles? I seem to recall there
was
Simon Marlow [EMAIL PROTECTED] wrote:
The report is in general very careful to say absolutely *nothing*
about evaluation order, leaving the implementation free to choose,
Yes, this is a highly desirable goal.
However, having said all that, arguably an exception should be made in
this
1 - 100 of 189 matches
Mail list logo
