Hello all,
I was asking this question on #haskell and thoughtpolice directed me
here for a possibly more up-to-date information.
Some of the important primitives offered by Data Parallel Haskell are
reduction primitives such as sumP and prodP, which take a data parallel
array and reduce it to a
Excerpts from Evan Laforge's message of Mon Jul 12 14:56:11 -0400 2010:
But I'm not convinced that's actually enough because the C code is
still running outside of a withForeignPtr. I would have to do
something really hairy like call back to C from the haskell callback,
wrapping it in
Excerpts from Evan Laforge's message of Mon Jul 12 16:23:39 -0400 2010:
Well, what I'm worried about is that withForeignPtr says you should
only use the pointer from inside it. The situation here is that I've
passed a pointer to C. C wants to share ownership of the pointer, so
even if all
Excerpts from Axel Simon's message of Tue Jul 13 16:03:01 -0400 2010:
If your C code has a way to properly unref a pointer then you could
wrap your ForeignPtr in a StablePtr and pass that to C land. Once C
has freed the StablePtr the ForeignPtr can become dead when Haskell
has dropped
Excerpts from Axel Simon's message of Tue Jul 13 16:28:29 -0400 2010:
Well, if the C code hangs on to the StablePtr that wraps the
ForeignPtr, its finalizer won't be run. But can run again once the
StablePtr is freed. So you can take out the Ptr in the ForeignPtr and
use it in C land as
Hello all,
I am currently investigating techniques to nicely handle SIGINTs when
FFI code is running. Yes, I know it sounds kind of crazy.
Ignoring the problems of cleaning up the unceremoniously terminated C
computation, I'm having difficulty getting the FFI to /stop/ running
when I get the
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 code kept marching on.
Cheers,
Edward
Excerpts from Simon Marlow's message of Mon Aug 09 11:23:42 -0400 2010:
That might be quite interesting to try, actually. You'll need to modify the
RTS: the place where we decide what to do when a throwTo is received for a
thread involved in a foreign call is around line 396 of
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 the suspended Haskell thread, which
afaict
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
// to recover!)
task =
Excerpts from Simon Marlow's message of Thu Aug 26 04:08:06 -0400 2010:
You don't want to do this for a bound thread (when target-bound !=
NULL), because the OS thread will have interesting things on its C stack
and pthread_cancel discards the entire stack. A worker thread on the
other
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) {
// walk all_tasks to find the correct worker
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 other threads calling throwTo to
Excerpts from Simon Marlow's message of Tue Aug 31 05:02:13 -0400 2010:
I think the idea of annotating interruptible calls should be good
enough. Simple blocking system calls like read can all be annotated
as interruptible without any problems. Also, pthread_cancel() provides
ways to
I cooked up a Darcs patch implementing the new language keyword 'interruptible'
sans tests, Windows support and avoiding executing interruptible calls on bound
worker threads. However, being a Darcs newbie I ended up sending the patch to
cvs-ghc, not this list. Let me know if you'd like me to
Excerpts from Bryan O'Sullivan's message of Fri Sep 03 17:00:03 -0400 2010:
What I am wondering is if there's a practical downside to doing this. Am I
going to accidentally kill something? This is a very important gap in the
usability of GHC with native libraries, and if this approach actually
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 enforce any threading
abstraction on
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 a good lowest-common-denominator
that
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
to give to the user functioSo I did a writeup
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_cancel, the RTS has to behave quite
A possible cute solution would be to ulimit the processes
permitted cpu time.
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Excerpts from Simon Marlow's message of Wed Sep 15 04:34:06 -0400 2010:
It's not clear to me when to emit the warning: the system we're
compiling on is not necessarily the one we're going to run on. This is
more often the case for us where we're building distributions, than for
other
There are some invariants that are being violated by pthread_kill(id, SIGINT)
and I'm having difficulty understanding them. I get the following errors:
cd ./concurrent/should_run '/home/ezyang/Dev/ghc/inplace/bin/ghc-stage2'
-fforce-recomp -dcore-lint -dcmm-lint -no-user-package-conf -rtsopts
It looks like the problem was that the default handler for SIGINT
was scheduling code to run, when we really just wanted to get EINTR.
I'm sketchily using SIGPIPE right now; maybe we should use SIGUSR1
or something.
Edward
___
Glasgow-haskell-users
Here's what the Windows version would look like (if I could get HEAD
to build, that is :-)
void
interruptOSThread (OSThreadId id)
{
HANDLE hdl;
PCSIO pCSIO;
if (!(hdl = OpenThread(THREAD_TERMINATE,FALSE,id))) {
sysErrorBelch(interruptOSThread: OpenThread);
I wasted an afternoon compiling GHC with GhcDebugged = YES in my
mk/build.mk, only to have ghc-stage2 tell me it wasn't compiled
with -debug. Looking at mk/config.mk.in, it seems that GhcDebugged
is unconditionally set to NO. What am I doing wrong?
Edward
Excerpts from Ian Lynagh's message of Tue Sep 28 13:18:17 -0400 2010:
Yes, unless you make clean.
(it works by putting Validating=YES in mk/are-validating.mk)
Oof, ok, I bet that was what I was seeing.
Thanks,
Edward
___
Glasgow-haskell-users
I finally got some spare time to do some GHC hacking, and after feeling my
way around http://hackage.haskell.org/trac/ghc/ticket/4262 I came up with the
following patch, which appears to work (that is, bound the number of worker
threads hanging around after FFI calls):
diff -rN -u
I've been poking the bad behavior Brian described here:
http://blog.ezyang.com/2010/08/interrupting-ghc/comment-page-1/#comment-1334
and in the process noticed something kind of interesting about
thread scheduling in non-multithreaded mode (i.e. without -threaded).
When the single-threaded
Relatedly, it seems that it takes a nontrivial amount of time for
the multithreaded RTS to realize that a thread has emitted a
signal. I wonder if there's a more direct way an FFI call can say
when I get back to Haskell, immediately start propagating an exception.
Edward
Excerpts from Donn Cave's message of Thu Nov 11 17:07:20 -0500 2010:
ghc: 6.12.1
linux: 2.6.32
ncurses: 5.7
Someone probably should. It's tempting to conclude that the bug
is in ncurses, and perhaps it is, and maybe there's nothing to be
done about it anyway, but a language
Oh, there's quite a simple fix for this: don't have the FFI call
handle the SIGINT; only handle a signal the RTS generates. I guess
we should do a little more legwork to make sure interruptible(?) user threads
don't see signals.
Edward
___
Excerpts from Simon Marlow's message of Wed Nov 17 06:15:46 -0500 2010:
I suggest keeping track of the number of items in the queue.
Ok, I added a spare_workers_no field to the Capability struct.
So I think the main thing missing is a call to workerTaskStop().
Added.
It would be really nice
Hello Ryan,
Adding the extra spare_workers_no field bookkeeping doesn't add very much
overhead, since whenever spare_worker's is changing we already have
taken out the lock.
As for using a lock-free data structures, I can't say I have a good
feel for how performance might change in that case.
Great news and great stuff! Looking forward to playing around with it.
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I fired up the new codegen and ran make fast on the regression suite
and the following new tests started failing:
3207(normal)
4030(normal)
cgrun016(normal)
cgrun045(normal)
cgrun051(normal)
dsrun005(normal)
dsrun007(normal)
dsrun008(normal)
exceptionsrun001(normal)
I get the same error for the other branch too.
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
When I revert the PArr - ParallelArray changes in those directories,
I then get:
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.1.20101126 for i386-unknown-linux):
match_co
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Oh, that explains the co error! Thanks a bunch.
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I like Git for Computer Scientists [1] and Git in pictures [2]. It also
sounds like a Git for Darcs users might be in order.
Edward
[1] http://eagain.net/articles/git-for-computer-scientists/
[2] http://blog.nelhage.com/2010/01/git-in-pictures/
___
I've done a bit more chewing away at the branch and have gotten to
19Sep10.
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Final status report for tonight, before I crash in bed;
I've managed to make it compile all the way to hoopl.
It seems like hoopl doesn't typecheck anymore? I haven't
been following the typechecker changes too closely so
some guidance would be appreciated.
Hello all,
Here's an experience report for porting hoopl to manage MonoLocalBinds. The
Compiler.Hoop.XUtil module has a rather interesting (but probably common) style
of code
writing, along the lines of this:
fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block
Here is the new set of failing test-cases on the shiny new branch.
I should stick the merged branch somewhere; any suggestions?
4030(normal)
4221(normal)
IndTypesPerf(normal)
T1969(normal)
T3064(normal)
T3294(normal)
T3736(normal)
T3807(normal)
T4003(normal)
Ok, looking at 4030, which is this simple program:
main = do tid - block $ forkIO $ let x = x in x
killThread tid
It segfaults in stg_BLACKHOLE_info when attempting to
dereference... something (I haven't quite figured out
what yet; what's usually stored in 0x4(%esi) on 32-bit x86
when
Ok, I've got a patch that fixes this segfault. In the process I looked
at all patches to Cg* modules after Nov 2009 and looked for changes that
weren't applied to the new codegen. I skipped the LLVM patch, but picked
up the rest of the blackhole changes. There are, however, two hunks that
I am
Hello Simon,
Have you gotten a chance to look at these two hunks? (see below)
Thanks,
Edward
Excerpts from Edward Z. Yang's message of Fri Dec 10 10:59:26 -0500 2010:
Ok, I've got a patch that fixes this segfault. In the process I looked
at all patches to Cg* modules after Nov 2009 and
I appear to have tracked down the bug for ffi021: the new
code generator doesn't appear to clear the tag bit for the
pointer to heap before:
// outOfLine should follow:
(_sR1::I32,) = foreign ccall
_sQR::I32((I32[_sRi::I32 + 7], `signed'),
Excerpts from Roman Leshchinskiy's message of Wed Jan 12 18:20:25 -0500 2011:
How would we get the current functionality of darcs-all pull? Is it even
possible?
Here is the rebase-y workflow. Untested, so I might have gotten one or two
details wrong.
Suppose I want to hack on GHC and base
With further poking, I think the new codegen is actually tickling
an existing bug in the native code generator optimizations, since
the cmmz output looks ok:
cSH:
_sQR::I32 = I32[_sRi::I32 + 3]; // CmmAssign
_sQS::I32 = I32[_sRi::I32 + 7]; // CmmAssign
Yep, switching
inlineStmt u a (CmmCall target regs es srt ret)
= CmmCall (infn target) regs es' srt ret
where infn (CmmCallee fn cconv) = CmmCallee fn cconv
infn (CmmPrim p) = CmmPrim p
es' = [ (CmmHinted (inlineExpr u a e) hint) | (CmmHinted e hint) - es
to
inlineStmt u
Ok, I have a stage2 compiler built with the new codegen all
the way, and here are the new failing cases:
1372(normal)
2047(normal)
4030(normal)
OldException001(normal)
async001(normal)
bug1465(normal)
cabal01(normal)
cabal03(normal)
cgrun016(normal)
cgrun045(normal)
*you feel a sudden sense of deja vu*
Here is my current play on things:
- I can probably get a devel2 build with the new codegen turned on for
everything. This list of errors is from that build. However, this
build was originally failing, so I'm going to do a fresh devel2
Test 4221 (under the ffi folder) segfaults with the new codegen turned on.
Before:
0xb7a68c78: 0x822fadc stg_ap_v_info
0xb7a68c74: 0xb7ab8f94
0xb7a68c70: 0xb7ab8fa4
0xb7a68c6c: 0x8134dc0 stT_info
0xb7a68c68: 0xb7ab8f94
0xb7a68c64: 0x822f9f4 stg_marked_upd_frame_info
Current theory:
c1jj:
_s1ep::I32 = I32[(slot_s1ep::I32 + 4)]; // CmmAssign
_s1fP::I32 = I32[(slot_s1fP::I32 + 4)]; // CmmAssign
// outOfLine should follow:
_s1eq::F64 = F64[_s1fP::I32 + 3]; // CmmAssign
I32[(youngc1jh + 4)] = c1jh; // CmmStore
foreign
:44:41 -0500 2011:
On 01/02/2011 00:01, Edward Z. Yang wrote:
Current theory:
c1jj:
_s1ep::I32 = I32[(slot_s1ep::I32 + 4)]; // CmmAssign
_s1fP::I32 = I32[(slot_s1fP::I32 + 4)]; // CmmAssign
// outOfLine should follow:
_s1eq::F64 = F64[_s1fP::I32 + 3
I was thinking it might be useful if we had a per-thread circular buffer in
memory for which we pushed a pointer to the info table we had just entered. In
the event of a crash, you could dump the contents of the buffer to see what
code had been recently executed. To reduce overhead, one might
The main thing about FFI support is calling conventions, and LLVM supports
a variety of them, so if your LLVM code is using a calling convention
GHC supports, you should be able to manage it (there probably isn't any
toolchain support though, so you'll have to build the LLVM bits manually
and then
Hello all,
If I run 'make fast' in the testsuite, with a stage2 compiler that has been
built with -DDEBUG, should I be getting extra failures?
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
checks for -dno-debug-output, though if some
tests are checking for debug output, that might be tricky.
Edward
Excerpts from Simon Marlow's message of Tue Apr 05 15:35:45 -0400 2011:
On 05/04/11 17:50, Edward Z. Yang wrote:
Hello all,
If I run 'make fast' in the testsuite, with a stage2
Excerpts from Karel Gardas's message of Thu Apr 07 13:14:46 -0400 2011:
OK! Thanks for the information. So this -fnew-codegen is this famous
codegen which is using hoopl for data-dependency tracking or something
like that if I understand correctly
Yep.
And which is producing just C-- in
Hello all,
I'm interested in improving GHC's C-- parser's support (and also making
accomodations for the parser in our C-- pretty-printer) to the point
where we can round-trip output from -ddump-opt-cmm with no semantic
change. There are several roadblocks on the way here, but the one
I'm
Hello William,
You can find the state of the art (which isn't very advanced :-)
in debugging GHC compiled code with GDB here:
http://hackage.haskell.org/trac/ghc/wiki/Debugging/CompiledCode
Maybe others can give more specific advice.
Cheers,
Edward
Excerpts from William Knop's message of
No, you have to use the 'interruptible' keyword.
Cheers,
Edward
Excerpts from Bas van Dijk's message of Sat Apr 23 20:07:05 -0400 2011:
Hello,
Quick question: are safe/unsafe FFI calls interruptible?
Thanks,
Bas
___
Glasgow-haskell-users
Excerpts from Bas van Dijk's message of Sun Apr 24 12:23:19 -0400 2011:
On 24 April 2011 10:26, Edward Z. Yang ezy...@mit.edu wrote:
No, you have to use the 'interruptible' keyword.
Good, I need them to be uninterruptible. So I guess I can apply
uninterruptibleMask_ only to the 'acquire lock
Excerpts from Bas van Dijk's message of Sun Apr 24 16:10:46 -0400 2011:
Well the whole block of code is under a mask_ so if FFI calls are not
interruptible the queued up exceptions should not be fired.
Ah, I didn't know that. I think it would be extremely surprising
for users if FFI calls ever
Excerpts from Denys Rtveliashvili's message of Thu Apr 28 04:41:48 -0400 2011:
Well.. I found some places in C-- compiler which are supposed to convert
division and multiplication by 2^n into shifts. And I believe these work
sometimes.
However in this case I am a bit puzzled because even if
:46:01 -0500 2011:
On 21/02/2011 01:08, Edward Z. Yang wrote:
Excerpts from Tyson Whitehead's message of Sun Feb 20 07:14:56 -0500 2011:
I believe a back trace on the actual call stack is generally considered not
that useful in a lazy language as it corresponds to the evaluation
sequence
To chime in, latest validate for me on x86-32 had two fails:
OVERALL SUMMARY for test run started at Sun May 15 16:16:28 BST 2011
2773 total tests, which gave rise to
10058 test cases, of which
0 caused framework failures
7598 were skipped
2377 expected passes
81
I ran into some more code like this, and I realized there was something
pretty important: the majority of let-bindings do not have any free varaibles.
They could very well be floated to the top level without having to make any
source level changes.
So maybe let should be generalized, if no free
In case it wasn't clear, I'd very much be in favor of implementing
this refinement.
Cheers,
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
All of the GHC repos are mirrored to Github, which offers similar
facilities. Of course, it wouldn't be too much work to setup
gitweb on darcs.haskell.org, I don't think.
Edward
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
Yay! This is very exciting :-)
Edward
Excerpts from Simon Peyton-Jones's message of Wed Jun 22 12:57:28 -0400 2011:
Friends
I have long advertised a plan to allow so-called superclass equalities. I've
just pushed patches to implement them. So now you can write
class (F a ~ b) = C a
Hello Justin,
If you grep Hoopl's source code for wrapFR and wrapBR, you can find
uses of the methods. For example:
thenFwdRw :: forall m n f. Monad m
= FwdRewrite m n f
- FwdRewrite m n f
- FwdRewrite m n f
-- @ end comb1.tex
thenFwdRw
Not currently, but I am planning on adding this functionality in the near
future.
Excerpts from Tim Docker's message of Wed Jul 20 13:44:41 -0400 2011:
The +RTS -s runtime arguments give some useful details the memory
usage of a program on exit. eg:
102,536 bytes allocated in the
Excerpts from Felipe Almeida Lessa's message of Sun Jul 24 22:02:36 -0400 2011:
Does anything change if you somehow force a GC sometime after good2?
Perhaps with some calculation generating garbage, perhaps with
performGC. IIRC, the runtime detects BlockedIndefinitelyOnMVar on GC.
But I'm
Hello Brandon,
The answer is subtle, and has to do with what references are kept in code,
which make an object considered reachable. Essentially, the main thread
itself keeps the MVar live while it still has forking to do, so that
it cannot get garbage collected and trigger these errors.
Here
This is supposed to get defined as a command line argument to the preprocessor,
see compiler/main/DriverPipeline.hs. Are you saying you don't see it when you
run hsc2hs? Maybe someone else is calling a preprocessor but missing some of
these arguments...
Edward
PM, Edward Z. Yang ezy...@mit.edu wrote:
This is supposed to get defined as a command line argument to the
preprocessor,
see compiler/main/DriverPipeline.hs. Are you saying you don't see it when
you
run hsc2hs? Maybe someone else is calling a preprocessor but missing some
Excerpts from Victor Nazarov's message of Tue Aug 02 19:12:55 -0400 2011:
I can parse arguments myself
and throw the rest of them to parseDynamicFlags, but GHC's flags are
really complicated and I'm not aware
of any argument parsing library that can be used to filter out some
specified flags
And no sooner do I send this email do I realize we have 'inline' built-in,
so I can probably experiment with this right now...
Edward
Excerpts from Edward Z. Yang's message of Sun Aug 21 14:18:23 -0400 2011:
Hello all,
It occurred to me that it might not be too difficult to use GHC's
stg_newArrayzh in rts/PrimOps.cmm doesn't appear to give any indication,
so this might be a good patch to add. But I'm curious: what would
allocating Array#s of size 0 do? Null pointers? That sounds dangerous...
Edward
Excerpts from Johan Tibell's message of Fri Aug 19 11:04:48 -0400 2011:
Hi,
I think this ticket sums it up very nicely!
Cheers,
Edward
Excerpts from Max Bolingbroke's message of Mon Aug 22 04:07:59 -0400 2011:
On 21 August 2011 19:20, Edward Z. Yang ezy...@mit.edu wrote:
And no sooner do I send this email do I realize we have 'inline' built-in,
so I can probably
at 8:48 AM, Edward Z. Yang ezy...@mit.edu wrote:
I think this ticket sums it up very nicely!
Cheers,
Edward
Excerpts from Max Bolingbroke's message of Mon Aug 22 04:07:59 -0400 2011:
On 21 August 2011 19:20, Edward Z. Yang ezy...@mit.edu wrote:
And no sooner do I send this email
I think it would be a pretty interesting project. :^)
Edward
Excerpts from Ryan Newton's message of Wed Aug 24 15:18:48 -0400 2011:
Ah, and there's no core-haskell facility presently? Thanks.
On Wed, Aug 24, 2011 at 12:14 AM, Edward Z. Yang ezy...@mit.edu wrote:
Since most of GHC's
Excerpts from Greg Weber's message of Sun Oct 09 12:39:03 -0400 2011:
So first of all I am wondering if a sum type comparison does in fact scale
linearly or if there are optimizations in place to make the lookup constant
or logarithmic. Second, I as wondering (for the routing case) if Haskell
Hmm, this kind of sounds like GHC is assuming that it has control over
all of the threads, and when this assumption fails bad things happen.
(We use lightweight threads, and use the operating system threads that
map to pthreads sparingly.) I'm sure Simon Marlow could give a more accurate
Hello Sanket,
What happens if you run this experiment with 5 threads in the C function,
and have GHC run RTS with -N7? (e.g. five C threads + seven GHC threads = 12
threads on your 12-core box.)
Edward
Excerpts from Sanket Agrawal's message of Tue Jan 17 23:31:38 -0500 2012:
I posted this
Hello all,
I was wondering if the following style of register assignment ever
shows up in C-- code generated by GHC:
a = R1
I32[a] = 1
a = R2
I32[a] = 2
That is to say, there are two disjoint live ranges of a: we could rename
all instances of a in the first and second lines to
Excerpts from Edward Z. Yang's message of Fri Jan 20 23:44:02 -0500 2012:
If multiple assignment is rare enough in straight line code, I might
be able to take the conservative approach and just say
a - used multiple times
Which I don't think will cause any problems in the inlining step
Excerpts from Heka Treep's message of Mon Jan 23 13:56:47 -0500 2012:
adding the message queue (with Chan, MVar or STM) for each process will not
help in this kind of imitation.
Why not? Instead of returning a thread ID, send the write end of a Chan
which the thread is waiting on. You can send
Excerpts from Heka Treep's message of Mon Jan 23 15:11:51 -0500 2012:
import Control.Monad.STM
import Control.Concurrent
import Control.Concurrent.STM.TChan
spawn f = do
mbox - newTChanIO
forkIO $ f mbox
Excerpts from Heka Treep's message of Mon Jan 23 16:20:51 -0500 2012:
actor :: TChan String - IO ()
actor mbox = forever $ do
putStrLn call to actor...
msg - atomically $ do
isEmpty - isEmptyTChan mbox
if isEmpty then return Nothing else readTChan mbox = return . Just
when
Check out compiler/basicTypes/Demand.lhs
Cheers,
Edward
Excerpts from Johan Tibell's message of Wed Mar 07 18:21:56 -0500 2012:
Hi,
If someone could clearly specify the exact interpretation of these
LLSL(ULL) strictness/demand annotations shown by ghc --show-iface I'd
like to try to write
This is the important bit of code in the file:
instance Outputable Demand where
ppr Top = char 'T'
ppr Abs = char 'A'
ppr Bot = char 'B'
ppr (Defer ds) = char 'D' ppr ds
ppr (Eval ds) = char 'U' ppr ds
ppr (Box (Eval ds)) =
Arguably, what should happen is we redo the format for machine-parseability
and use that in future versions of GHC.
Edward
Excerpts from Johan Tibell's message of Wed Mar 07 23:38:06 -0500 2012:
Thanks Edward. I'll try to summarize this in human readable form and
publish it on the wiki.
--
Hello all,
I recently ran into a rather reproduceable bug where I would
get this error from the event manager:
/dev/null: hClose: user error (Pattern match failure in do expression at
libraries/base/System/Event/Thread.hs:83:3-10)
The program was doing some rather strange things:
- It
So, it would be pretty interesting if we could have an ST s style
mechanism, where the data structure is not allowed to escape.
But I wonder if this would be too cumbersome for anyone to use.
Edward
Excerpts from Simon Marlow's message of Fri Apr 20 06:07:20 -0400 2012:
On 19/04/2012 11:45,
Excerpts from Brandon Allbery's message of Fri Apr 20 19:31:54 -0400 2012:
So, it would be pretty interesting if we could have an ST s style
mechanism, where the data structure is not allowed to escape.
But I wonder if this would be too cumbersome for anyone to use.
Isn't this what
Excerpts from Bas van Dijk's message of Thu May 03 11:10:38 -0400 2012:
As can be seen, the putMVar is executed successfully. So why do I get
the message: thread blocked indefinitely in an MVar operation?
GHC will send BlockedIndefinitelyOnMVar to all threads involved
in the deadlock, so it's
1 - 100 of 166 matches
Mail list logo
