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
h
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
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 va
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 expec
Mar 01 05: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 la
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 eve
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 eve
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 wrote:
> > No, you have to use the 'interruptible' keyword.
>
> Good, I need them to be uninterruptible. So I guess I can apply
> uninterruptibleMask_
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-
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
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 current
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
d add 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 '
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
http://www.haskell.org/mailma
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
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,
> That is, it is demand centric while written code is production
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 onl
sage of Tue Feb 01 03: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)]; // CmmA
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[(young + 4)] = c1jh; // CmmStore
foreign
Test 4221 (under the ffi folder) segfaults with the new codegen turned on.
Before:
0xb7a68c78: 0x822fadc
0xb7a68c74: 0xb7ab8f94
0xb7a68c70: 0xb7ab8fa4
0xb7a68c6c: 0x8134dc0
0xb7a68c68: 0xb7ab8f94
0xb7a68c64: 0x822f9f4
0xb7a68c60: 0xb7ab8f48
0xb7a68c5c: 0xb7ab8f8
*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
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)
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
> inline
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
_sQT:
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
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'),
(I32[_sRi
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 look
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 n
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
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)
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
whe
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.
libraries/hoopl/src/Compiler/Hoopl/Util.h
Ian, I'd love a little guidance with this patch:
Thu Oct 21 13:08:53 BST 2010 Ian Lynagh
* Use takeUniqFromSupply in emitProcWithConvention
We were using the supply's unique, and then passing the same supply to
initUs_, which sounds like a bug waiting to happen.
{
hunk ./compiler/c
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
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/
___
Gl
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
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
Gla
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
Excerpts from David Terei's message of Fri Dec 03 23:44:33 -0500 2010:
> http://darcs.haskell.org/ghc-cmm-03Sep10/
This branch fails to build for me:
"inplace/bin/ghc-stage1" -M -dep-makefile
libraries/dph/dph-par/dist-install/build/.depend-v.haskell.tmp
-include-pkg-deps -H64m -O -fasm -packa
I'm working off HEAD, so this is good info to know.
Cheers,
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)
e
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
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. :-)
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 ni
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
___
Glasgow-haske
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 langu
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
_
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 R
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 old-ghc-clean/rt
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 mai
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
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");
stg_exit(EX
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 maili
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
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 pe
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 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
> di
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 o
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
> t
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 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 actuall
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 exp
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
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
> int
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 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
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 = target->bound->ta
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
> afai
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 rts/RaiseAsyn
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
___
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 sig
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
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 Evan Laforge's message of Mon Jul 12 16:43:45 -0400 2010:
> Yeah, that's definitely the safest and simplest. But the copying
> defeats the purpose of passing a pointer in the first place, which was
> to not have to copy the giant array just to pass it.
Well, if your C code wasn't sq
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 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 with
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 s
101 - 177 of 177 matches
Mail list logo
