Mads Lindstrøm wrote:
For those interested I figured out how to avoid the RunBreak -returns.
Use RunToCompletion in stead of SingleStep in the application of runStmt.
I guess Interactive-6.8.hs should also use SingleStep.
SingleStep is what GHCi uses to implement :step - that is, it runs
Matthias Kilian wrote:
On Wed, Jan 30, 2008 at 08:13:01PM +1100, Manuel M T Chakravarty wrote:
[...]
This is due to a change of the configure stage that AFAIK was made to
easy building on windows. Instead, of using shell commands/scripts
(as GHC did previously) to obtain some
hsing-chou chen wrote:
Thank you for porting GHC 6.8.2 to solaris, I am assigned a
job to make sure GHC run 64 bits on solaris. Is your
solaris port 64 bits. Or it only 32 BITS. I know 32 bits
GHC can still run on 64 bits solaris. However company want
to run really 64 bits GHC on solaris.
Bernd Brassel wrote:
Consider the following program:
module Stack where
import System.IO.Unsafe
main = print (sim (replicate 1299959 ()))
sim [] = True
sim (_:xs) = goodStack (sim xs)
goodStack x = fromJust (Just x) --no stack overflow
badStack x = unsafePerformIO (return x)
Manuel M T Chakravarty wrote:
Things are complicated because
- on Cygwin, pwd gives you /cygdrive/c/...
- on MSYS, pwd gives you /c/...
(remember we still support MSYS), and we want c:/...
So we used to use cygpath on cygwin, and some horrible sed command on
MSYS, IIRC. It was a mess, and
Christian Maeder wrote:
Simon Marlow wrote:
hsing-chou chen wrote:
Thank you for porting GHC 6.8.2 to solaris, I am assigned a
job to make sure GHC run 64 bits on solaris. Is your
solaris port 64 bits. Or it only 32 BITS. I know 32 bits
GHC can still run on 64 bits solaris. However company
Bernd Brassel wrote:
Thanks for your answer Simon.
Simon Marlow wrote:
Bernd Brassel wrote:
Consider the following program:
module Stack where
import System.IO.Unsafe
main = print (sim (replicate 1299959 ()))
sim [] = True
sim (_:xs) = goodStack (sim xs)
goodStack x = fromJust (Just
Bernd Brassel wrote:
Sorry to ask a C question here, but I could not find an answer on the net.
How do I create a library that can be used in ghci?
This is the situation:
I have a c file coracle.c. I do
/tmp$ cc -c -o coracle.o coracle.c
/tmp$ ar rc libcoracle.a coracle.o
/tmp$ ranlib
Bernd Brassel wrote:
There is another point that makes me wonder now. If the update frame for
the recursive call is the problem then my solution with foreign C
functions would produce a bad stack also. But this is not the case.
The code looks now like this:
sim [] = True
sim (_:xs) = yags
Chris Kuklewicz wrote:
So my theory now is:
I do a large number of lookups.
Try using Data.Array.Base.unsafeRead (and maybe
ata.Array.Base.unsafeWrite). These avoid the bounds checking on the
index each time you lookup something in the array.
Right. Also keep an eye on the GC time
Robert van Herk wrote:
Hi all,
So my theory now is:
I do a large number of lookups.
Try using Data.Array.Base.unsafeRead (and maybe
ata.Array.Base.unsafeWrite). These avoid the bounds checking on the
index each time you lookup something in the array.
Right. Also keep an
Bernd Brassel wrote:
Simon Peyton-Jones wrote:
Any chance of documenting your experience on the GHC user documentation page?
http://haskell.org/haskellwiki/GHC (under collaborative documentation)
A kind of how-to that worked for you, with pointers to relevant manual parts
etc.
Simon
John Vogel wrote:
I am running my program in WinXP with ghc 2.6.8
If you install netstat and change the parameters it should still work in
linux.
Why does thread # 3 dominate over the over threads int the output?
Why does thread # 4 never seem to run?
I can't use the sleep function in
John Vogel wrote:
Thankyou both Don Stewart and Simon Marlow for your responses.
By adding yield and threadDelay in certain spots I have at least prevented
some of the threads from being starved of CPU time.
The only issue now is that terminateProcess doesn't always terminate
netstat.exe
Marc Weber wrote:
I've hacked on hasktags again
http://mawercer.de/hasktags.hs
I'd like to merge changes into the ghc distribution or ask someone to do
so.
changes:
a) full qualified module names are added as well now
b) hack: removed empty tokens so that getcons finds
Bayley, Alistair wrote:
From: Neil Mitchell [mailto:[EMAIL PROTECTED]
Bummer. I was hoping to be able to use 6.8.1 with gtk2hs
(AFAIUI, gtk2hs
doesn't work with/hasn't been compiled against 6.8.2 yet).
Is there a
workaround or something I can tweak in my 6.8.1 installation?
It's much
Frederik Eaton wrote:
Thanks, I may try that. I'm currently trying to get my GNU-make-based
build to install profiling versions of package modules, in the hope
that -xc might give more useful information than it did a year ago...
I would think the chances of that are fairly low, there haven't
Frederik Eaton wrote:
P.S. Here are some suggestions for the GHCi debugger documentation:
http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html
There is one major restriction: breakpoints and single-stepping are only available
in interpreted modules; compiled code is
Andrei Formiga wrote:
Hello,
The Visual Haskell 0.2 release notes [1] say that sources are
available, but the download page only has binaries available. Where
are the sources? Also, does it use the Visual Studio SDK, and is it
compatible with VS 2008? Thanks.
[1]
Duncan Coutts wrote:
From the H98 report:
All I/O functions defined here are character oriented. [...]
These functions cannot be used portably for binary I/O.
In the following, recall that String is a synonym for [Char]
(Section 6.1.2).
So ordinary
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:
1. all text I/O is in the locale encoding (what C and Hugs do
Roman Leshchinskiy wrote:
Duncan Coutts wrote:
On Wed, 2008-02-27 at 00:31 +1100, Roman Leshchinskiy wrote:
Also, would this affect the encoding used for file names? If so, how?
No, that's a separate issue.
Hmm, so how do I reliably read a list of file names from a file?
You didn't say
Remi Turk wrote:
during the past semester I followed a seminar on the Efficient
implementation of functional languages by Jeroen Fokker at the
University Utrecht. During that course we worked on a feedback
directed GHC optimisation, but that got me interested in another
possible GHC backend
John Meacham wrote:
On Thu, Mar 06, 2008 at 12:23:35AM +, Duncan Coutts wrote:
Which is really annoying :-) I'd like greater control over it, in
particular a way to limit headers to package scope so that dependent
code does not need the headers.
Ideally there would be no need for headers
Duncan Coutts wrote:
I was under the impression that with ghc, ffi import declarations like
this do not escape the module:
foreign import ccall unsafe foo.h foo foo :: IO ()
However it seems that this one does:
foreign import ccall unsafe curses.h stdscr stdscrp :: Ptr WINDOWptr
from:
John Meacham wrote:
On Tue, Mar 11, 2008 at 02:47:37PM -0700, Simon Marlow wrote:
Yeah, I'd like -fvia-C to be headerless. We talked about it a while back
(on the haskell-prime list I think). The main issue is that GHC would have
to generate prototypes based on the FFI declaration, and since
Bruce, Joseph R (Joe) wrote:
When I run 'ghc -v ...', the linking is done via gcc-ld with a large
list of -u flags passed in. I'm hoping to find a way to link my object
files without those flags, but first I need to understand what they are
doing. Can someone explain it to me? Or point me to
Gregory Wright wrote:
This morning (13 March 2008) the ghc trac wedged reporting
Trac detected an internal error:
with the python traceback
Traceback (most recent call last):
File /var/lib/python-support/python2.4/trac/web/main.py, line 387,
in dispatch_request
.a. You shouldn't
run into namespace collisions, as the symbol namespace is global anyway.
Cheers,
Simon
Joe
-Original Message-
From: Simon Marlow [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2008 3:18 PM
To: Bruce, Joseph R (Joe)
Cc: glasgow-haskell-users@haskell.org
Tristan Allwood wrote:
I've been playing around with hs-curses and utf8, and have discovered
that I need to use an ffi call at the top of my main to
setlocale(LC_ALL, ) in order to get the hscurses bindings to display
utf8-encoded strings correctly.
If I understand correctly, the fact that I
Christian Maeder wrote:
Ian Lynagh wrote:
I'm not sure why we have both HAVE_TIMER_CREATE and USE_TIMER_CREATE.
I'd like to know, too.
It's because the configure script checks for more than just the
existence of timer_create() (HAVE_TIMER_CREATE), it checks that it works
well enough to
Jay Scott wrote:
I have a MacBook (which is a Core 2 Duo) running Mac OS X 10.4. On this
platform, gcc makes 32-bit executables by default, but if you give it -
m64 it makes them 64-bit. I've tried it, and it works. gcc gives its
version as i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple
Simon Marlow wrote:
John Meacham wrote:
On Tue, Mar 11, 2008 at 02:47:37PM -0700, Simon Marlow wrote:
Yeah, I'd like -fvia-C to be headerless. We talked about it a while
back (on the haskell-prime list I think). The main issue is that GHC
would have to generate prototypes based on the FFI
C.M.Brown wrote:
Hello,
I am trying to use the API to interpret a Main module and get some type
information from it. However, everytime I try to load a Main.hs module
using the API I get the following error message:
/usr/local/packages/ghc-6.8.2/lib/ghc-6.8.2/libHSrts.a(Main.o): In
function
Simon Peyton-Jones wrote:
| Would it also be appropriate to modify that wiki page to reflect some of
| the changes between 6.6.1 and 6.8.2? I don't mind doing this at some point
| today or tomorrow...
Yes please, that would be vv helpful.
Right; the page currently has a mixture of 6.6 and
HP Wei wrote:
I cut and paste the code from
http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in-haskell
And compiled the resulting portscan.hs
with both ghc-6.8.2 and ghc-6.6.1
on a host with Sun-Sparc [SunOS 5.10].
Besides the issue of binary-code-size blow-up with
Matthias Kilian wrote:
Hi,
for an unregisterised ghc-6.8.2 (or newer), are the .hi files
dependent (except for the 32 vs. 64 bit word size)? I had a quick
look at the stuff in compiler/iface, but the only MD part I found
was that 32/64 bit difference.
The word size is probably the only
Scott Dillard wrote:
Simon, Don,
You're right. -fno-state-hack fixed it. I've opened a trac ticket.
Program and test data are there.
http://hackage.haskell.org/trac/ghc/ticket/2284
Ok, but do we really need two tickets for this? Why open a new ticket
rather than adding the information to
Richard Kelsall wrote:
Hello Glasgow-Haskell Users,
It was suggested to me in this thread in Haskell-Cafe
http://www.haskell.org/pipermail/haskell-cafe/2008-May/042797.html
which was a subsidiary of a previous thread
http://www.haskell.org/pipermail/haskell-cafe/2008-April/042155.html
that
Matthias Kilian wrote:
On Wed, May 14, 2008 at 11:35:36AM +0100, Simon Marlow wrote:
for an unregisterised ghc-6.8.2 (or newer), are the .hi files
dependent (except for the 32 vs. 64 bit word size)? I had a quick
look at the stuff in compiler/iface, but the only MD part I found
was that 32/64
Don Stewart wrote:
duncan.coutts:
On Thu, 2008-05-15 at 23:00 +0400, Bulat Ziganshin wrote:
Hello Don,
Thursday, May 15, 2008, 10:47:20 PM, you wrote:
I discovered something today I didn't know.
gcc -O2 can optimise out the computed jumps GHC produces in tight loops.
seems that decision to
Bertram Felgenhauer wrote:
I've made an experiment compiling ghc-api with --split-objs. To
summarize, while this is not worthwhile for the compiler itself,
it could be a huge win for plugin libraries.
A fairly detailed description can be found here,
Don Stewart wrote:
what causes ghc to emit a stub.c file? - Conal
the use of 'foreign export' - Don
or 'foreign import wrapper'
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Christian Maeder wrote:
Don Stewart wrote:
hp:
I convinced myself that the ~500kbytes for the 'hello' code is
'correct' in version 6.6.1.
[ The exact size on the platform mentioned below
is 422k. ]
Looks like version 6.8.2 blows up the binary code size
significantly --- 3.9Mbytes vs
Hi Folks,
6.8.3 is nearing release, and we have an outstanding bug affecting the GHCi
on the BSDs:
http://hackage.haskell.org/trac/ghc/ticket/2013
We need someone to help out with this. The patch in the ticket apparently
works, but can't be committed as is because it isn't correctly
Peter Gammie wrote:
Hello,
Further on my static linking woes:
debian ~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.8.2
-debian ~$ cat T.hs
main :: IO ()
main = putStrLn Hello world
-debian ~$ ghc -optl-static -static --make T.hs
Linking T ...
Don Stewart wrote:
marlowsd:
Hi Folks,
6.8.3 is nearing release, and we have an outstanding bug affecting the
GHCi on the BSDs:
http://hackage.haskell.org/trac/ghc/ticket/2013
We need someone to help out with this. The patch in the ticket apparently
works, but can't be committed as is
Ok, I've now modified the patch and attached a new version to the ticket:
http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch
*BSD folks please test.
Wilhelm B. Kloke wrote:
Simon Marlow [EMAIL PROTECTED] schrieb:
So, try the patch to get the patch to compile against ghc
Donn Cave wrote:
On Fri, 30 May 2008 10:43:22 -0400
Gregory Wright [EMAIL PROTECTED] wrote:
http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch
*BSD folks please test.
I built the 20080529 snapshot with this patch and my light testing of
ghci
showed no problems (FreeBSD
Gregory Wright wrote:
Hi,
On May 29, 2008, at 11:19 AM, Simon Marlow wrote:
Ok, I've now modified the patch and attached a new version to the
ticket:
http://hackage.haskell.org/trac/ghc/attachment/ticket/2013/2013.patch
*BSD folks please test.
I built the 20080529 snapshot
Donn Cave wrote:
I'm building GHC on NetBSD-amd64, and among other things
need to deal with the problem described in #2305 - native
code misses the __RENAME (__asm) directive in NetBSD include
files, and ends up linking to the wrong externals. The
author of #2305 reports that -fvia-C avoids
Bryan O'Sullivan wrote:
Simon Peyton-Jones wrote:
There's a 6.8.3 release candidate you might be able to try.
Yes, I reported a bug and Simon mentioned that it ought to be fixed
already. I've been trying to build snapshots for about a week :-)
And we appreciate the bug reports. Is it
Donn Cave wrote:
On Thu, 5 Jun 2008 09:23:36 -0700
Donn Cave [EMAIL PROTECTED] wrote:
... It looks like, in base anyway, this actually goes in a .h file,
to a pattern like
... ah, never mind that, I see those wrappers are not the sort I need.
Yes, those are the kind of wrappers I mean.
Judah Jacobson wrote:
Hi all,
I'm writing a program that reads input from the user but should also
handle a ctrl-c. My attempt is below; the program forks a thread to
read one character of input, and kills that thread upon receiving a
sigINT. It works fine compiled without -threaded, but with
Brandon S. Allbery KF8NH wrote:
On 2008 Jun 11, at 0:43, Simon Marlow wrote:
Unix semantics just isn't the right thing when it comes to
non-blocking I/O. If only there were non-blocking read()/write()
system calls, we'd be fine.
Have you considered using aio_read() and company?
aio
Yitzchak Gale wrote:
Judah Jacobson wrote:
I'm writing a program that reads input from the user but should also
handle a ctrl-c...
It works fine compiled without -threaded, but with -threaded
it blocks forever after a ctrl-c.
Simon Marlow wrote:
Ah, this is a consequence of the change we
Dan Doel wrote:
Issue 2: Reading from/writing to a MutableByteArray# is slower than an Addr#
This is, I think, the crux of the issue. The main content of the benchmark is
reversing/shifting items in an array. To get a somewhat easier look at the
core, I boiled things down to a benchmark that
Bryan O'Sullivan wrote:
Here's something I just stumbled upon by accident: at least on Linux,
GHC emits huge numbers of symbols into the binaries it generates.
Here's Haddock, which I compiled without any funny debug options:
$ du -h haddock-0.9
4.1M haddock-0.9
$ nm haddock-0.9 | wc -l
37938
Christian Maeder wrote:
Hi,
I've created the following binary distributions, but -- like Serge
Mechveliani -- I'm not very happy with the results, because the created
binaries are much bigger.
http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-i386-unknown-solaris2.tar.bz2
Serge D. Mechveliani wrote:
What is the difference between ghc-6.8.2 and ghc-6.8.3 ?
Compile times were improved by 4.3% over the nofib suite between 6.8.2 and
6.8.3. Code size was unaffected (down 0.2%). Runtime and allocation were
also about the same.
That's not to say that we don't
Hi folks,
I've been wondering whether it would be useful to have a weekly IRC meeting
to discuss GHC. The idea would be that this is a scheduled time when the
developers turn up on #ghc, we'll discuss current topics around GHC, and
users can chime in with questions, points for discussion,
Ok, the first weekly IRC meeting is scheduled for Wednesday 16 July
(tomorrow) at
1600 BST (UTC+1)
0800 PDT (UTC-7)
1100 EDT (UTC-4)
0100 Thursday in Sydney (sorry guys :-)
If it turns out to be useful, we'll make it a regular thing. See you in
#ghc on chat.freenode.net. More
Duncan Coutts wrote:
On Wed, 2008-07-16 at 16:08 +0100, Neil Mitchell wrote:
Hi
Another option is a conference call, but personally I prefer the IRC medium
for this kind of meeting. A conference call could work too, though.
i propose to sent every meeting log into cvs-ghc
I second
Johan Tibell wrote:
On Thu, Jul 17, 2008 at 1:33 PM, Simon Marlow [EMAIL PROTECTED] wrote:
Thanks to everyone who turned up and joined in, we had an interesting
discussion about the HLP. On this basis I think we should try making it a
weekly event.
Thanks for arranging the meeting. I
Thomas M. DuBuisson wrote:
Ian and I talked about possibly trying a different time - 9pm UK time,
which would be slightly less friendly to us in the UK (I have my work/life
balance to think about you know :-) but more friendly to people in the US.
I, for one, am happy with the current time;
Yu Di wrote:
Hi, I am trying to build ghc 6.8.3 from source release, my currently
installed version is ghc 6.4.2 (x86 linux binary release version), and I
got:
/usr/local/ghc/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall
-fno-warn-name-shadowing -fno-warn-unused-matches -DUSING_COMPAT
Tim Chevalier wrote:
Hi all,
Are there any known problems with retainer profiling in GHC 6.8.2? I
have a program that takes 3 minutes to run with normal profiling
enabled (+RTS -P -RTS), but with +RTS -P -hr -RTS, it's 20 minutes and
counting. I can tell that progress is being made since the
Daniel Gorín wrote:
On Jul 29, 2008, at 2:43 PM, Johannes Waldmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
data Target = Target TargetId (Maybe (StringBuffer,ClockTime))
looks great. How is this intended to be used,
i.e. what should happen if there is an edit/save event in
The IRC meeting will be held today at 16:00 UK time as usual (there wasn't
any support for moving it to 21:00). Simon PJ is back from holiday and
should make it this time.
Any suggestions for discussion topics? One idea we have is to talk about
the GHC API.
Cheers,
Simon
We can talk about the general issues on IRC. But I thought I'd answer a
few of the specific questions quickly:
Roman Leschinskiy wrote:
I don't think I understand how GHC itself is built any longer, either.
What does cabal-bin do?
It's effectively a pre-compiled Setup.hs for packages that
Claus Reinke wrote:
For infrequent updaters like myself, it would also be nice just to have
a HEADS UP before and after periods of larger than usual instability
(such as build system replacements).
And, talking about #ghc, I've got the suspicion that this channel is
partly to blame for the
Following lots of useful discussion and evaluation of the available DVCSs
out there, the GHC team have made a decision: we're going to switch to git.
It came down to two things: the degree of support available, and
flexibility of the tools (git is much happier to let you modify the history
Alexander Dunlap wrote:
On Tue, Aug 5, 2008 at 2:23 AM, Simon Marlow [EMAIL PROTECTED] wrote:
(notice how fast that is :-)
git clone has gone about 45 minutes so far without finishing...is that
an improvement over darcs?
I think http is still bandwidth-throttled on darcs.haskell.org. You
Ian Lynagh wrote:
On Wed, Aug 06, 2008 at 12:44:35PM +0200, Felix Martini wrote:
and Windows support is less of an issue: git appears to work reasonably well on
Windows these days.
Congratulations on the switch, but isn't the decision a bit premature?
I have read the log of last week's GHC
IRC Meeting today at 1600 UK time as usual (1500 UTC, 0800 PDT, 1100 EDT).
A couple of suggestions for topics;
- HEAD stability (re previous disccusion on cvs-ghc)
- mechanics of the git switchover
Cheers,
Simon
___
Glasgow-haskell-users
Duncan Coutts wrote:
It's not clear to me that we've really bothered to find out. The last
evaluation in relation to ghc that I'm aware of was prior to the 2.0
release. My impression is that we've all complained about the darcs v1
problems (justly) but spent the most effort investigating things
Manuel M T Chakravarty wrote:
As far as I am concerned, building GHC is turning into a big mess. We
discussed ways to improve it again, BUT I'd rather not see it getting
any messier before it gets better. Hence, please let's have a complete
plan that we are convinced will work before making
Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] wrote:
This means we still get to use 'make', we still get to use the .cabal
files as metadata, but the build system is more private to GHC, more
extensible, and hopefully more understandable and modifiable.
This is essentially the same
Manuel M T Chakravarty wrote:
Everybody who contributes to the boot/core libraries needs to validate
their patches. If the GHC version of the libraries is in git, then all
library code needs to be validated against the git version of the
libraries before it can enter the master repository.
Roman Leshchinskiy wrote:
On 12/08/2008, at 20:11, Simon Marlow wrote:
- Extract the code from Cabal that generates Makefiles, and treat it as
part of the GHC build system. Rather than generating a Makefile
complete with build rules, we generate a Makefile that just
has the package
Norman Ramsey wrote:
I also see repeatedly that the distinction between the build system
and packaging system is blurry: both have to know about build targets,
dependencies, and so on.
At the time of the wonderful GHC Hackathon in Portland, where the GHC
API was first introduced to the public,
Matthias Kilian wrote:
I mean the GHC-specific template used for building the Makefile
(Distribution/Simple/GHC/Makefile.in) and the function `makefile`
in Distribution/Simple/GHC.hs (this function even spills out some
some make rules in addition to what's in Makefile.in, which looks
very wrong
Claus Reinke wrote:
Perhaps it would be useful for GHC HQ to have a GHC project
blog,
Actually we have talked about doing that, and it's highly likely we'll set
one up in due course. I think it's worth letting the current discussion(s)
run their course and then we'll have a set of
Roman Leshchinskiy wrote:
Of course there should be a standard build system for simple packages.
It could be part of Cabal or a separate tool (for which Cabal could,
again, act as a preprocessor).
GHC is a special case: we already need a build system for other reasons.
I agree. I just
Roman Leshchinskiy wrote:
But that is precisely my (other) point. A lot of that work is really
unnecessary and could be done by Cabal since it only or mostly depends
on the package information. Instead, it is implemented somewhere in
Distribution.Simple and not really usable from the outside.
Duncan Coutts wrote:
Turns out that the reason for slow darcs whatsnew is ghc bug #2093
http://hackage.haskell.org/trac/ghc/ticket/2093
because getSymbolicLinkStatus is broken on 32bit systems in 6.8.2 it
means that the 'stat' optimisation does not work so darcs has to read
the actual
Manuel M T Chakravarty wrote:
From what you are saying, it seems that one advantage of git
(in-place branch switching) is not going to be useful to GHC in any case
(because we use nested repositories).
As far as I can tell, in-place branches are not a lot of use to us compared
to just
Duncan Coutts wrote:
On Fri, 2008-08-15 at 15:12 +0100, Ian Lynagh wrote:
On Fri, Aug 15, 2008 at 11:12:20AM +1000, Manuel M T Chakravarty wrote:
Moreover, as I wrote a few times before, some reasons for switching in
the first place are invalidated by not having the core libraries in
git,
this last, Simon Marlow planned to run benchmarks to
determine how much performance the layout optimisation gains us these
days. Simon, did you ever get around to that?
I didn't get around to benchmarking it, but since the layout optimisation
is easily switched off (it's called tablesNextToCode inside
John Meacham wrote:
unfortunately the cabal approach doesn't work. note, I am not saying a
declarative configuration manager won't work. in fact, I have sketched a
design for one on occasion. but cabal's particular choices are broken.
It is treading the same waters that made 'imake' fail.
the
Roman Leshchinskiy wrote:
On 28/08/2008, at 23:59, Simon Marlow wrote:
The important thing about Cabal's way of specifying dependencies is
that they can be made sound with not much difficulty. If I say that
my package depends on base==3.0 and network==1.0, then I can guarantee
that as long
John Meacham wrote:
On Thu, Aug 28, 2008 at 02:59:16PM +0100, Simon Marlow wrote:
The important thing about Cabal's way of specifying dependencies is that
they can be made sound with not much difficulty. If I say that my
package depends on base==3.0 and network==1.0, then I can guarantee
Brandon S. Allbery KF8NH wrote:
On 2008 Aug 28, at 22:00, Sterling Clover wrote:
We do have, although not with easy access, an additional declarative
layer built in 90% of the time as configuration as type signature.
Sure? I think it's easier than you think: someone's already written
code
Sterling Clover wrote:
This email is inspired by the discussion here:
http://hackage.haskell.org/trac/ghc/ticket/2401
As the ticket discusses, unsafeIOToSTM is, unlike unsafePerformIO or
unsafeInterleaveIO, genuinely completely unsafe in that there is no way
to use it such that a segfault or
While perusing the tickets in the 6.10.1 milestone I spotted 3 that look to
be FreeBSD-specific:
2476internal error: awaitEvent: descriptor out of range
2502segfault with GHC.Handle.fdToHandle'
2511unix package doesnt load in ghci on freebsd/amd64
It's unlikely that we'll get
Donn Cave wrote:
| ... and one that I think applies to all the *BSDs:
|
| 2063Breackage on OpenBSD due to mmap remap
|
| (actually the latter one is a top priority, because without it GHCi can't
| work, so we need it fixed for 6.10.1).
Is this a change from 6.8.3? NetBSD currently
Peter Hercek wrote:
Hi,
There is an example of +RTS -s output at the end.
I have few simple questions:
What does 9 Mb total memory in use mean?
Is it in mega bytes (MB) or in mega bits (Mb)?
I would expect memory usage to be in bytes (B)
but a unit for bits (b) seems to be used.
Looks like
Bulat Ziganshin wrote:
Hello Don,
Friday, September 12, 2008, 12:54:22 PM, you wrote:
when GHC builds executable, it adds debug info by default. since this
You can also achieve this by making sure your deployed programs build
with Cabal,
Serge D. Mechveliani wrote:
5. The same is for -O2. But this does not gain more performance.
-O2 -fvia-C also does not gain more performance, but leads to 7 times
longer compilation.
Just to be sure: are you saying that with -O2 the compile time is ok,
but when you add -fvia-C it
Serge D. Mechveliani wrote:
On Fri, Sep 19, 2008 at 08:17:12PM +0100, Ian Lynagh wrote:
On Tue, Sep 16, 2008 at 10:44:53AM +0100, Simon Peyton-Jones wrote:
|
| And still ghc-6.8.3 builds itself from source.
I have no idea how -- Happy has been needed for some time. Maybe someone else
does.
1 - 100 of 2671 matches
Mail list logo
