On 12/03/10 16:38, Donn Cave wrote:
I have been working on a Haskell interface to the platform API
for Haiku (was BeOS.) It's C++, but the interesting thing at
the moment is the use of threads - a UI window gets its own
thread, and whatever Haskell code will be executed by callbacks
from that th
On 13/03/2010 22:54, Donn Cave wrote:
Quoth Simon Marlow,
...
So it was surprising when this turned out to be incompatible
with the -threaded link option. With that option, I get one
callback from a non-main thread, and then that native thread
will die, shortly after return from the callback
IO
manager-related, and one caused by an interaction between the scheduler
and GC. It's likely that one of these is your problem. All of them are
fixed in 6.12.2, so if you are able to grab a snapshot and test it that
would be very helpful.
Tue Mar 9 09:58:31 GMT 2010 Simon Marlow
*
On 15/03/2010 12:06, Michael Lesniak wrote:
Hello Simon,
GC. It's likely that one of these is your problem. All of them are fixed
in 6.12.2, so if you are able to grab a snapshot and test it that would be
very helpful.
Where can I get version is 6.12.2? According to [1], there are both
6.13.
On 14/03/2010 07:50, Yitzchak Gale wrote:
In the thread "strictness of unused arguments",
Max Bolingbroke wrote:
There is nothing *published* (Simon has a half-written one lying
around though)...
Unfortunately the weird behaviour you are seeing is due to...
one of the unpublished bits...
There
On 13/03/2010 20:39, Dan Knapp wrote:
There doesn't seem to be a mailing list for Cabal itself, so I'm
posting here. I came up with an idea for a small feature that I
believe would make a useful addition to ghc-pkg and Cabal. I'm
willing to implement it myself, but I have had some previous
expe
On 15/03/10 16:02, Michael Lesniak wrote:
Hello Simon,
with 6.12.1.20100313 the behaviour is worse: even when using $! in the
appropiate lines (see [2] in my original message) the programs hangs
quite often. Hence, 6.12.1 works better in this (special?) case.
Ok, I'll look into it, thanks for
On 15/03/2010 22:03, Simon Marlow wrote:
On 15/03/10 16:02, Michael Lesniak wrote:
Hello Simon,
with 6.12.1.20100313 the behaviour is worse: even when using $! in the
appropiate lines (see [2] in my original message) the programs hangs
quite often. Hence, 6.12.1 works better in this (special
On 16/03/2010 14:34, Michael Lesniak wrote:
Hello Simon,
I reproduced the deadlock, and it looks like a new one: a lock order
reversal between Schedule.c:checkBlackHoles() and RtsAPI.c:rts_unlock(). It
turns out I've already fixed it in the HEAD as a side effect of some other
improvements, so
On 15/03/10 23:54, Iavor Diatchki wrote:
Hi,
I think that one may view a "static_wrapper" import as a pair of an
export like the one you wrote and an import of the address of the
exported function (this is useful because usually it is convenient to
install the handler on the Haskell side). Perha
On 16/03/10 23:38, Iavor Diatchki wrote:
Hello,
On Tue, Mar 16, 2010 at 3:22 PM, Simon Marlow wrote:
It seems hard to justify adding this to GHC, since it's really just
syntactic convenience for a particular case. Traditionally syntactic sugar
for FFI declarations has been implement
On 17/03/2010 00:17, Louis Wasserman wrote:
I tested, and this implementation actually performs better if the spine
is maintained lazily, so we'll test that version.
May I request that, unless there's a significant speedup from using a
strict spine, that you use a lazy spine where possible.
On 17/03/2010 23:13, Iavor Diatchki wrote:
Hello,
My point was that in many cases we can simply avoid run-time code
generation, rather then trying to work around the system's SE Linux
policy. While I believe that using the foreign "export" gives us the
same functional behavior, the generated co
On 24/03/2010 22:04, Thanos Tsouanas wrote:
Hello list.
I'm trying to compile ghc 6.12.1, but the documentation part fails because
dblatex can't escape all the backslashes that it should. (I've tried
dblatex-2.10, -2.11 and -2.12.)
A similar problem has been discussed earlier [1], but even wit
On 29/03/2010 14:54, Peter Hercek wrote:
Hi,
I got this deprecation warning:
Warning: Module `GHC.Handle' is deprecated:
use GHC.IO.Handle.Base instead
But I think it should have been:
Warning: Module `GHC.Handle' is deprecated:
use GHC.IO.Handle instead
I'll fix that, thanks for letting u
On 01/04/2010 02:10, Gregory Wright wrote:
On 3/31/10 11:44 AM, Ian Lynagh wrote:
On Mon, Mar 22, 2010 at 02:54:26PM -0400, Gregory Wright wrote:
Now they seem to both be correct. The key value is at the bottom of
column 8. This should be 2.386e-1
(which means that 23.86 percent of the protons
If you aren't using anything unsafe, then it is a bug. Even if you are
using something unsafe, it might still be a bug; either way if you can
narrow down to the smallest program (+data) that crashes that would be
immensely helpful.
Does the result change if you use different GC settings? I l
On 14/04/10 06:02, Denys Rtveliashvili wrote:
Good morning,
Yesterday I did a few tests to measure the performance of FFI calls and
found that the calls themselves are very quick (1-2 nanosecond).
However, there is a kind of FFI calls when one have to allocate a
temporary memory block (for a str
On 15/04/2010 18:12, Yitzchak Gale wrote:
My opinion is that we should either use TWO DOT LEADER,
or just leave it as it is now, two FULL STOP characters.
Just to be clear, you're suggesting *removing* the Unicode alternative
for '..' from GHC's UnicodeSyntax extension?
I have no strong opin
On 18/04/2010 10:28, Denys Rtveliashvili wrote:
While alloca is not as cheap as, say, C's alloca, you should find that
it is much quicker than C's malloc. I'm sure there's room for
optimisation if it's critical for you. There may well be low-hanging
fruit: take a look at the Core for alloca.
On 18/04/2010 19:22, Matthias Kilian wrote:
Hi,
On Sun, Apr 18, 2010 at 10:53:22AM -0700, Judah Jacobson wrote:
Anyway, the short story is that I have to either hard-code the
character set to something like utf-8, or ghc will start to behave
really strange (for example, ghci would terminate imm
On 22/04/10 21:25, Denys Rtveliashvili wrote:
Thank you, Simon
I have identified a number of problems and have created patches for a
couple of them. A ticket #4004 was raised in trac and I hope that
someone would take a look and put it into repository if the patches look
good.
Things I did:
* I
, where I've already fixed this by moving
pinned_object_block into the Capability and hence making it CPU-local.
The patch that fixed it was
Tue Dec 1 16:03:21 GMT 2009 Simon Marlow
* Make allocatePinned use local storage, and other refactorings
As for locking, here is one one
On 23/04/2010 11:47, Jens Petersen wrote:
Hi,
FYI I just ran the full testsuite (my first time) on a fedora devel
build for Fedora 14 and got the following results:
* i686 (all)
OVERALL SUMMARY for test run started at gum agd 23 7:20:47 saaku UTC 2010
2375 total tests, which gave rise to
On 21/04/2010 09:45, Roman Leshchinskiy wrote:
After thinking about this for a while, I came up with two possible solutions. One is to
provide a "pure" version of touch#:
use# :: o -> o' -> o'
such that use# x y = y. This would change the code above to:
I# (use# arr# (indexIntOffAddr
Our GHC repositories on darcs.haskell.org have now been upgraded to
"hashed" format, with some nice consequences:
- Using --lazy, getting a GHC repo over the network only takes a
few minutes
- No need to download tarballs any more
- No complicated instructions about how to avoid case-ins
On 26/04/2010 15:31, Max Bolingbroke wrote:
On 26 April 2010 13:42, Simon Marlow wrote:
comments welcome!
This is great news. However, I had some problems:
1) darcs-all does not add --lazy by default, which contradicts the wiki:
"""
$ ./darcs-all --testsuite get
warning: a
On 23/04/2010 19:03, Denys Rtveliashvili wrote:
Tue Dec 1 16:03:21 GMT 2009 Simon Marlowmailto:marlo...@gmail.com>>
* Make allocatePinned use local storage, and other refactorings
The version I have checked out is 6.12 and that's why I haven't seen
this patch.
Are there any plans for i
On 27/04/2010 01:58, Jens Petersen wrote:
On 22 April 2010 10:19, Ian Lynagh wrote:
Release notes are here:
http://haskell.org/ghc/docs/6.12.1/html/users_guide/release-6-12-2.html
No mention of it, but is utf8-string now only an internal library?
It was always supposed to be internal, we
On 28/04/2010 03:02, Dimitry Golubovsky wrote:
Hi,
Interesting: my program is compiled with -threaded, and when I run it
with +RTS -N I get:
: forking not supported with +RTS -N greater than 1
This is probably about forkProcess rather than forkIO/forkOS, but why
this limitation? rawSystem wor
On 28/04/2010 10:25, Dimitry Golubovsky wrote:
Can the documentation for forkProcess be fixed then? Instead of
"forkProcess comes with a giant warning..." it could say: "forkProcess
is not supported by GHC in multicore setting".
Yes, will do.
Cheers,
Simon
On 02/05/10 12:10, Sebastian Fischer wrote:
Is the above output intended?
Yes.
Interesting.
Note that catching all exceptions is rarely the right thing to do. See
http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Control-Exception.html#4
for more details.
I should have w
On 05/05/2010 12:24, 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 users.
This finally g
On 06/05/2010 09:15, Axel Simon wrote:
Good morning,
I'm looking at ticket http://hackage.haskell.org/trac/ghc/ticket/4038
and wonder who is to blame:
- this segmentation fault occurs in Gtk2Hs' callbacks (i.e. a Haskell
function pointer is being passed to C land) and in a signal (where a
gener
We had planned to switch to using a dynamically-linked GHCi for 6.14.1
(see http://hackage.haskell.org/trac/ghc/ticket/3658), which on the
whole seems like the right direction to be heading in, since we reduce
the dependence on our own RTS linker.
The dynamically-linked GHCi works, and passes
On 10/05/2010 03:43, Roman Leshchinskiy wrote:
On 09/05/2010, at 07:50, Duncan Coutts wrote:
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. Ch
Hi folks,
I'm sorry to say that in GHC 6.12.2, as a result of fixing a couple of
bugs in 6.12.1, we (well, I) managed to introduce some more serious ones:
http://hackage.haskell.org/trac/ghc/ticket/4038
http://hackage.haskell.org/trac/ghc/ticket/4041
The first causes gtk2hs programs to crash,
On 17/05/2010 04:48, PHO wrote:
From: Simon Marlow
Subject: Dynamic libraries and GHCi
Date: Mon, 10 May 2010 10:06:21 +0100
We had planned to switch to using a dynamically-linked GHCi for 6.14.1
(see http://hackage.haskell.org/trac/ghc/ticket/3658), which on the
whole seems like the right
On 16/05/2010 20:49, Ian Lynagh wrote:
On Mon, May 10, 2010 at 10:06:21AM +0100, Simon Marlow wrote:
- we make -dynamic the default.
It's perhaps worth investigating the consequences of the first option,
making -dynamic the default. Cabal would have to --enable-dynamic by
default - pe
On 18/05/2010 17:48, John Lato wrote:
From: Simon Marlow
But currently there is one problem with "GhcShared=YES": with this
option, the stage-2 compiler gets linked dynamically but the
corresponding inplace shell wrapper does not set (DY)LD_LIBRARY_PATH,
thus ./inplace/bin/
On 27/05/10 20:35, Matthias Kilian wrote:
Unexpected failures:
concprog001(ghci)
==> out of memory (probably harmless)
getUserEntryForName(normal,optc,hpc,optasm,ghci)
==> known (by me) issue. probably a bug/incompatibility in OpenBSD
hClose003(normal,optc,hpc,opt
On 29/05/2010 15:07, Matthias Kilian wrote:
On Fri, May 28, 2010 at 10:05:36PM +0100, Simon Marlow wrote:
hReady002(ghci)
==> did not investigate yet. failure details below
This one is a known failure right now (I need to clean it up).
Good to know. Thanks for the i
On 03/06/2010 07:29, Evan Laforge wrote:
On Sun, May 30, 2010 at 5:15 PM, Antoine Latter wrote:
Hi GHC,
Is there a reason that Foreign.Marshall.Array.allocaArray calls into
allocaBytes instead of allocaBytesAligned? Since alloca needs the
alignment, wouldn't allocaArray also need it?
I'm not
[ glasgow-haskell-users CC'd, as requested ]
Hi Hamish,
Sorry for the delay in replying, things have been busy over the last few
days with paper deadlines and suchlike.
On 05/06/2010 15:14, Hamish Mackenzie wrote:
We want to try to add Haskell to TakeoffGW (a new Windows
distribution like cy
On 13/06/2010 07:26, austin seipp wrote:
Hello,
I am running GHC on x86_64 debian linux, and recently I have
discovered that the executables generated by my GHC segfault when the
linking step is not dynamic.
I discovered this while attempting to install haskell-src-exts, which
requires a linked
On 14/06/2010 17:00, Christian Maeder wrote:
Hi,
I've successfully compiled ghc-6.12.3 under x86 solaris.
However, for the testsuite I had to add '-lz' to the threaded1 entry of
config.way_flags in file testsuite/config/ghc:
'threaded1' : ['-lz', '-threaded', '-debug'],
Otherwise I
On 15/06/2010 09:00, Bas van Dijk wrote:
On Mon, Jun 14, 2010 at 11:20 PM, Don Stewart wrote:
v.dijk.bas:
Hello,
I've a short question about interruptible operations. In the following
program is it possible for 'putMVar' to re-throw asynchronous
exceptions even when asynchronous exception ar
On 16/06/2010 01:52, Evan Laforge wrote:
I've been trying to profile my program and having some trouble. I
imagine other people have stumbled across these same issues, so
hopefully I can benefit from someone else's experience. In return, if
I can figure out some of these things, I'll put it up
On 16/06/2010 15:38, MH wrote:
I have installed SUSE-10.2 with all mingw packages in my Virtualbox and
ready to start working. Would it be possible to provide a quick step by
step overview of what should be done? I've never done anything of that
sort and have no idea where to start.
You would s
On 16/06/2010 14:04, Jesper Louis Andersen wrote:
Finally, you can tune the eden/nursery generation by providing +RTS
-A5m for instance. The default is 0.5 megabytes which I think is way
too low for most work. Increasing it blindly will hurt though as you
will hit L1/L2 cache limits and get wors
On 18/06/2010 08:29, Evan Laforge wrote:
oh, that happens a lot. e.g. in f (g x), if f doesn't demand the value of
its argument for a long time, then the heap closure for (g x) is lagging.
If the value of (g x) is never demanded, but is nevertheless stored in some
data structure for a while,
On 21/06/2010 03:51, Dimitry Golubovsky wrote:
I am experimenting with the new feature in GHC such as custom Handles.
I use GHC 6.12.2, base 4.2.0.1
I have pasted the code in question as
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=26413#a26413
I am trying to create a Handle using a thread as
On 22/06/10 12:43, Dimitry Golubovsky wrote:
Simon,
On Tue, Jun 22, 2010 at 4:31 AM, Simon Marlow wrote:
So the problem is that fillReadBuffer has to return 0 to indicate EOF, but
you are killing the slave thread as soon as it has reached the end of the
stream. So you get one call to
On 26/06/10 12:28, Neil Mitchell wrote:
I have a very big and highly threaded program that generates a
BlockedIndefinitelyOnMVar exception when run. I have spent a
reasonable amount of time pouring over the source code, as has Max
Bolingbroke. Neither of us have the slightest idea why it raises t
On 25/06/10 16:06, Dimitry Golubovsky wrote:
Should an implementation of GHC.IO.Device expect the `ready' method to
be called from a thread different than one waiting for an I/O
operation on a handle to complete, while that operation is in
progress?
As a more general question, are GHC Handles (a
On 30/06/2010 18:13, Yitzchak Gale wrote:
Henning Thielemann wrote on Haskell Cafe:
Attached is a program with a space leak...
I have coded a simple 'map' function, once using unsafePerformIO and
once without. UnsafePerformIO has a space leak in some circumstances.
In the main program I demonstr
On 30/06/2010 22:15, George Brewster wrote:
Hey,
I'd really like to see ghc working on 64-bit Windows, so I've decided to
take at least a quick stab at getting it going.
Having talked to some of the people on #ghc, it sounds like the first
thing to do is get an unregisterised build going, which s
On 01/07/2010 21:10, Neil Mitchell wrote:
Hi Simon,
Thanks for the excellent information. I've now debugged my problem,
and think I've got the last of the MVar blocking problems out.
* How confident are people that this exception does really mean that
it is in a blocked state? Is there any cha
On 04/07/10 10:30, Neil Mitchell wrote:
Hi Simon,
My suspicion for the root cause of the problem is that Concurrent.Chan
is incorrect. In the course of debugging this problem we found 2 bugs
in Chan, and while I never tracked down any other bugs in Chan, I no
longer trust it. By rewriting parts
On 04/07/2010 21:51, Neil Mitchell wrote:
http://hackage.haskell.org/trac/ghc/ticket/4154
Yup, that's a bug. Not clear if it's fixable.
http://hackage.haskell.org/trac/ghc/ticket/3527
That too. A very similar bug in fact, if there is a fix it will probably
fix both of them. The problem i
On 08/07/2010 17:56, Daniel Fischer wrote:
On Thursday 08 July 2010 18:15:44, Ian Lynagh wrote:
On Thu, Jul 08, 2010 at 04:49:00PM +0200, Daniel Fischer wrote:
unsafeCoerce# :: Word64# -> Double# ?
By the docs, that isn't supposed to work. Is it not supposed to work
only because it's not valu
On 08/07/2010 23:25, J. Garrett Morris wrote:
Hello everyone,
I'm currently in the process of wrapping a C API, and I've run across
an interesting possibility. Basically, the C API exposes non-blocking
versions of some potentially long-running operations, and will invoke
a callback to indicate
On 13/07/2010 05:49, Evan Laforge wrote:
On Mon, Jul 12, 2010 at 6:54 PM, John Meacham wrote:
Hi, is a StablePtr what you are after?
Indeed, it looks like StablePtr will get me what I want. It's a
little less convenient than FunPtr because I'm already doing some
finalization of FunPtrs and I
On 16/07/2010 12:36, Axel Simon wrote:
Dear Haskell maintainers,
I've progressed a little and found that the problem is down to
accessing global variables that are declared in dynamic libraries. In
a nutshell, this doesn't as the addresses of these global variables
are all wrong when ghci is exe
On 16/07/2010 14:04, Axel Simon wrote:
Hi Simon,
On 16.07.2010, at 14:29, Simon Marlow wrote:
On 16/07/2010 12:36, Axel Simon wrote:
Dear Haskell maintainers,
I've progressed a little and found that the problem is down to
accessing global variables that are declared in dynamic librarie
On 15/07/2010 13:46, Christian Maeder wrote:
Hi,
seeing
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/syntax-extns.html#new-qualified-operators
Could you add:
"Spaces are not allowed in new qualified operators!"
For
{-# LANGUAGE NewQualifiedOperators #-}
f1 = (+)
f2 = ( +)
f3 =
On 15/07/2010 23:41, Albert Y. C. Lai wrote:
Suppose I start ghci, use a value from a package, causing it to be
linked, then I modify the package and reinstall, same version number,
without quitting my ghci session. Is there a way to tell the ghci
session to refresh and use the modified package?
On 20/07/10 22:08, Ian Lynagh wrote:
On Tue, Jul 20, 2010 at 10:45:36PM +0200, Johan Tibell wrote:
Building from a clean checkout of HEAD (from today) I get:
ghc-stage2: internal error: Invalid Mach-O file:Address out of bounds while
relocating object file
(GHC version 6.13.20100720 for i3
On 06/08/2010 21:16, Edward Z. Yang wrote:
Excerpts from Corey O'Connor's message of Fri Aug 06 16:15:21 -0400 2010:
In your test cases that fail are your C computations foreign unsafe imports?
First thing I checked. :-) They were safe imports, and the Haskell code
did get called--just the C c
On 11/08/2010 17:03, Johan Tibell wrote:
Inspired by the generic maps example at
http://www.haskell.org/haskellwiki/GHC/Indexed_types
I tried to use associated data types to create a generic finite map that
unpacks both the key and value into the leaf data constructor.
What you're trying to d
On 11/08/2010 22:31, Greg Fitzgerald wrote:
Is there any documentation or examples available that shows what needs
to be linked to get a haskell executable to print "hello world"?
Instead of using GHC to link, I'm interested in using gcc, ar, or link
directly. For starters, what implements the
On 12/08/2010 11:13, Johan Tibell wrote:
There needs to be some amount of code generation, but much of the
implementation can still be shared. I previously tried to defined the
type class as
{-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-}
module Ex2 where
import Prelude hid
On 12/08/2010 12:28, Johan Tibell wrote:
This doesn't quite work though as two MapIntDouble defined in two
different libraries are incompatible. This is essentially the same
problem as with instance collisions.
But you get to choose the module name, so you can avoi
On 20/08/2010 20:13, Christian Höner zu Siederdissen wrote:
Hi,
using:
http://www.haskell.org/ghc/dist/current/dist/ghc-6.13.20100819-x86_64-unknown-linux.tar.bz2
parallel-3.1.0.0
and the most-common test program ... ever:
module Main where
import Control.Parallel.Strategies
fib :: Int -> In
On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/23/10 11:57 , Christian Maeder wrote:
However, when I try to compile the simplest source with on older
gcc-3.4.4 I get the link error below, but only for the threaded rts!
With ghc-6.12.1 and
On 25/08/2010 16:37, Christian Maeder wrote:
Christian Maeder schrieb:
Simon Marlow schrieb:
On 23/08/2010 17:45, Brandon S Allbery KF8NH wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/23/10 11:57 , Christian Maeder wrote:
However, when I try to compile the simplest source with
On 26/08/2010 06:57, Edward Z. Yang wrote:
Excerpts from Edward Z. Yang's message of Thu Aug 26 01:22:22 -0400 2010:
I spent some time looking at the code, and I've been having a difficult
time finding the thread ID of the worker thread that is performing the
safe FFI call. The target TSO is th
On 26/08/2010 08:10, Edward Z. Yang wrote:
Here is a possible implementation:
Task *task = NULL;
blockedThrowTo(cap,target,msg);
if (target->bound) {
// maybe not supposed to kill bound threads, but it
// seems to work ok (as long as they don't want to try
On 26/08/2010 18:20, Edward Z. Yang wrote:
Ahem, the logic in that last iteration was not quite correct.
Here is the more correct version:
case BlockedOnCCall:
case BlockedOnCCall_NoUnblockExc:
{
#ifdef THREADED_RTS
Task *task = NULL;
if (!target->bound) {
On 28/08/2010 07:45, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of Fri Aug 27 04:05:46 -0400 2010:
You should walk cap->suspended_ccalls instead, no lock is required for that.
For stress testing, you want to construct an example that has lots of
threads making foreign cals and o
On 01/09/2010 04:22, Edward Z. Yang wrote:
Not sure what you mean here: what's a bound FFI call?
Good point: we don’t distinguish between FFI calls that require thread
local state and which ones don’t: this might be a good thing to allow
annotating. If we did know, then we could simply arrang
On 03/09/2010 22:00, Bryan O'Sullivan wrote:
I spent some time this morning trying to use HDBC-mysql to talk to a
database. It uses the C mysql bindings, which talks over a blocking
socket to the database server. Not surprisingly, it fails reliably when
the thread it's running in is hit by an RTS
ity of GHC with native libraries, and if this approach actually turns
out to be safe in practice, that would be wonderful.
I think the primary downside is that it's not portable (yet) to Windows. Simon
Marlow and I have been working on "interruptible FFI calls", and one of the
things th
On 01/09/2010 12:08, Victor Nazarov wrote:
I have some custom compilation script that uses GHC API
The aim is to extract some info from every module in dependency graph
and to write this information to the file lying near module-file.
Script goes like this:
main :: IO ()
main =
do args<- getA
On 06/09/10 19:16, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of Mon Sep 06 05:57:59 -0400 2010:
What did you have in mind with respect to "portable equivalents of
pthread functions"? I'm not sure we need to do anything along these
lines at all, and I'd much rather we didn't enf
On 08/09/2010 15:57, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of Wed Sep 08 03:40:42 -0400 2010:
Maybe. As a first step I think we could just document what happens when
a call is interrupted (pthread_cancel() on POSIX, ??? on Windows) and
let the user handle it. Is there even
On 06/09/2010 19:03, Evan Laforge wrote:
So a long time ago (I think when 6.10 first came out, the problem
didn't happen with the previous version, and I think 6.10 changed how
the FFI used alignment) I filed a ghc ticket about a gc assertion
failure. Unfortunately it was so hard to reproduce an
On 09/09/2010 00:28, Daniel Fischer wrote:
On Wednesday 08 September 2010 23:55:35, Don Stewart wrote:
simonpj:
|> ghc-6.12.3:
|>89,330,672 bytes allocated in the heap
|>15,092 bytes copied during GC
|>35,980 bytes maximum residency (1 sample(s))
|>2
On 09/09/2010 10:39, Christian Maeder wrote:
Christian Maeder schrieb:
Hi,
we call from our haskell application the metis prover via
System.Process.readProcessWithExitCode "metis" filename ""
However, we are not able to get rid of this process if metis does not
terminate by itself. In parti
On 09/09/2010 15:08, Daniel Fischer wrote:
On Thursday 09 September 2010 13:19:23, Simon Marlow wrote:
I think I've found the problem, GHC.IO.Handle.Text:
bufReadNBEmpty :: Handle__ -> Buffer Word8 -> Ptr Word8 -> Int -> Int ->
IO Int
bufReadNBEmpty h...@handle__{..}
On 09/09/2010 17:18, Christian Maeder wrote:
David Peixotto schrieb:
On Sep 9, 2010, at 6:37 AM, Simon Marlow wrote:
On 09/09/2010 10:39, Christian Maeder wrote:
Christian Maeder schrieb:
Hi,
we call from our haskell application the metis prover via
On 11/09/2010 07:59, Edward Z. Yang wrote:
So I did a writeup of what I thought might be the next direction to
go with the interruptible patch:
http://blog.ezyang.com/2010/09/towards-platform-agnostic-interruptibility/
The really interesting bit (which I didn't cover) is what information
t
On 15/09/2010 03:33, Edward Z. Yang wrote:
Excerpts from Simon Marlow's message of Mon Sep 13 05:10:13 -0400 2010:
The idea of having user-definable cancellation mechanisms seems quite
sensible, given that we have so many ways to do this. However it seems
quite hard in practice: for pthread_can
On 15/09/2010 03:49, Bruno Martínez Aguerre wrote:
To understand better whether ghc is taking advantage of my UNPACK
pragmas, I want to profile my program and sort the allocations by type.
I couldn't find an option to do this. -p is only by cost-center, and -hy
only works for live data, and I wa
On 14/09/2010 02:09, Thomas DuBuisson wrote:
All,
A recent SO question [1] led me to do a quick test on hard-coding RTS
options as suggested in the manual rts-hooks section [2].
Unfortunately the timing tests indicate "ghc_rts_opts" isn't being
used; tests with flags besides -N (ex: "-H1024m") a
On 14/09/2010 20:00, Dimitry Golubovsky wrote:
In the GHC I/O system, a Handle may be backed by a "device" (IODevice
instance) with IODeviceType = Directory
There doesn't seem to be any (at least Google search did not give
anything) code that uses this; however, what is supposed to be read
from
On 19/09/2010 13:11, Stefan Wehr wrote:
Hi all,
I'm profiling a Haskell program and now getting that the program
spents 56% of its individual time in the cost centre MAIN (note the
capital letters).
I searched the documentation for this cost centre, with no success. In
all profiling results so
On 18/09/2010 03:03, Alex Suraci wrote:
Context: My language uses hint to interpret Haskell code at runtime,
via `load: "path/to/file.hs"`. Hint works similar to ":load foo.hs"
in GHCi (it uses the GHC API). After the source is interpreted the
module's `load` function is executed in the language'
On 22/09/2010 01:19, Alex Suraci wrote:
On Tue, Sep 21, 2010 at 10:30 AM, Daniel Gorín wrote:
Hi
What I make of this is that you should run a new interpreter (i.e. use
runInterpreter(T)) instead of calling reset.
Could you try this this approach and see if it works?
Daniel
Every "load:" c
output in order to get proper
Unicode encoding. Since then, the IO library has gained support for
Unicode encoding, so we don't need to do this any more. It looks like I
tried to modify GHCi to bypass Haskeline for output, but didn't do a
complete job:
Fri Sep 18 15:40:41 BST 2
1 - 100 of 3277 matches
Mail list logo
