Re: RFC: migrating to git
On 01/13/2011 12:49 AM, Simon Marlow wrote: > I spent quite some time yesterday playing with submodules to see if they > would work for GHC. I'm fairly sure there are no fundamental reasons that > we couldn't use them, but there are enough gotchas to put me off. I wrote > down what I discovered here: > > http://hackage.haskell.org/trac/ghc/wiki/DarcsConversion#Submodules I think the "what works" section of there is already pretty compelling -- for example, it's an annoyance that "darcs-all diff" produces a diff file which mashes together all the subrepos and can't be applied at the top level. It's another annoyance that "darcs diff" doesn't produce unified diffs by default, what's the point of a diff that can't be |patch-ed? It seems from your discussion that subrepos are intended for your category "the rest of libraries (e.g. filepath, containers, bytestring, editline)" i.e. things that you expect to passively track and occasionally pick up new patches from. What's the argument against using subrepos for those? To me, the major gotcha is "git submodule update" detaching the changes, however changing the default to be a --merge would fix that for me. What about that don't you like? Would you rather want a "git submodule update --just-complain-and-exit"? The last 2 drawbacks you mention (pushing to submodules first and needing to commit to GHC for every subrepo commit) is IMHO the price to pay for a guarantee that you're always able to check out a coherent set of changes. If that's too onerous, maybe some of those libraries just belong in the main GHC repo. I'm another interested bystander who thinks that git would be a step forward, btw. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [darcs-users] How to develop on a (GHC) branch with darcs
Hi Simon, On 12/08/2010 12:45 AM, Simon Peyton-Jones wrote: > I have personal experience of git, because I co-author papers with git > users. I am not very technologically savvy, but my failure rate with git > is close to 100%. Ie I can do the equivalent of 'pull' or 'push' but I > fail at everything else with an incomprehensible error message. Maybe I > just need practice (or more diligence), but I really don't understand > git's underlying model, despite trying, and reading several tutorials. > If anyone has a favourite "how to understand git" doc, do point me at > it. If you still are looking for git docs (or christmas gifts, for that matter ;), I've heard good things about Pro Git: http://www.amazon.com/Pro-Git-Scott-Chacon/dp/1430218339/ref=sr_1_1?ie=UTF8&qid=1293052240&sr=8-1 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: os x 64-bit?
On 11/09/2010 02:36 AM, John Lato wrote: > I was wondering if there is a status report anywhere of progress towards > making ghc compile 64-bit on Snow Leopard. There are a few trac tickets > that seem related: I think http://hackage.haskell.org/trac/ghc/ticket/3472 is related if you haven't seen it. I'm not working on this, though I am interested in helping enable cross-compilation of GHC in general. I have been working on one facet though: hsc2hs. hsc2hs is one of barriers to cross-compilation because it requires compiling and running a .c file on the target machine (because it needs target-specific information like the layout of structures; GHC's mkDerivedConstants also has the same problem). I have a proof-of-concept patch which can do hsc2hs codegeneration without running anything. This uses the same approach that autoconf uses for cross-compilation. I'll try to post it within the next few days -- if anybody finds this approach interesting please let me know. Thanks, -Brian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: SIGPIPE in the GHC runtime
On 08/23/2010 07:15 AM, Ian Lynagh wrote: > Could someone summarise this thread in a ticket in the GHC trac? http://hackage.haskell.org/trac/ghc/ticket/4274 HTH, Brian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: SIGPIPE in the GHC runtime
On 08/23/2010 07:15 AM, Ian Lynagh wrote: > Could someone summarise this thread in a ticket in the GHC trac? > http://hackage.haskell.org/trac/ghc/ I'd be happy to, I'll follow up as soon as I can find time. Thanks, -Brian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: SIGPIPE in the GHC runtime
On 08/18/2010 07:06 PM, Donn Cave wrote: > Quoth Brian Bloniarz , > ... >> I just tested linux in this scenario, it gives EPIPE as I'd expect. >> Linux's SA_RESTART has been reliable in my limited experience. Do >> you have an OpenSolaris install to test by any chance? The code is >> below. > > No, sorry! But I don't doubt that with the right compile options > and so forth, that test would work fine on OpenSolaris. Without > knowing what really caused the problem I mentioned, I can't guess > how to duplicate the problem or test for it. (Cf. "hGetContents: > resource exhausted", Haskell Cafe, lally.si...@gmail.com.) I know > that's rather unhelpful. I hate unnecessary signals. Thanks for the pointer! I can try to dig around, but yeah I'd be tempted to just hope for the best given that the patch I posted won't make matters worse. > A less elegant variaton on that would be to block SIGPIPE, instead > of ignoring it. I don't have a great deal of practical experience > with that, nor have I looked at how it would fit with GHC runtime > code, but execve(2) does reset the signal mask, so it would have > the inheritance properties you want. I think the signal mask is retained across exec (!). http://www.opengroup.org/onlinepubs/009695399/functions/execl.html Search for "the new process will inherit"; experimentally, linux retains it. -Brian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: SIGPIPE in the GHC runtime
On 08/18/2010 04:55 PM, Donn Cave wrote:
> Quoth Brian Bloniarz ,
>
>> IMHO the simplest fix is the patch below: simply
>> avoid SIG_IGN, instead install a handler which does nothing.
>> This way, an exec() restores the handler to SIG_DFL. I've
>> included a testcase too.
>
> I don't know enough to make a case for or against this, but the
> side effects are different: whether the handler does anything
> or not, it will interrupt some system calls. Since there are
> already may be a regular barrage of SIGALRMs from the GHC runtime,
> maybe one more such interruption can't hurt anything ... but
> note that we recently heard from someone in Australia with a
> problem on OpenSolaris where evidently these SIGALRMs were in
> fact interrupting hGetContents from a pipe, and no one seemed
> to have any notion why.
Shouldn't enabling SA_RESTART be enough to restart the syscall?
I don't know all the Unices enough to guarantee that it'd be
transparent, but I hope it should be. I see the SIGALRM
code uses SA_RESTART too, though judging by the #ifdefs in
Itimer.c, SA_RESTART must not be available everywhere.
Note that unlike SIGALRM, the SIGPIPE will be sent to the thread
which caused it (i.e. the caller of write()), not any other thread.
So any possible damage would be limited to the calling thread.
> At any rate, the affected system calls would set EAGAIN, possibly
> including the write(2) that's supposed to set EPIPE (though
> I think that would be an unusual implementation.)
I just tested linux in this scenario, it gives EPIPE as I'd expect.
Linux's SA_RESTART has been reliable in my limited experience. Do
you have an OpenSolaris install to test by any chance? The code is
below.
#include
#include
#include
#include
int count = 0;
void handler(int sig)
{
++count;
}
int main()
{
int fd[2];
struct sigaction act;
act.sa_handler = handler;
sigemptyset(&act.sa_mask);
act.sa_flags = SA_RESTART;
sigaction(SIGPIPE, &act, NULL);
pipe(fd);
close(fd[0]);
int arg = 0;
int e = write(fd[1], &arg, sizeof(arg));
printf("count:%d, ret:%d, errno:%d was_epipe:%d\n", count, e, errno, errno
== EPIPE);
return 0;
}
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
SIGPIPE in the GHC runtime
The GHC runtime ignores SIGPIPE by setting the signal
to SIG_IGN. This means that any subprocesses (created via
System.Process or otherwise) will also have their
SIGPIPE handler set to SIG_IGN; I think this might be
a bug. The Python runtime does the same thing,
there's a good explanation of the drawbacks in:
http://bugs.python.org/issue1652
IMHO the simplest fix is the patch below: simply
avoid SIG_IGN, instead install a handler which does nothing.
This way, an exec() restores the handler to SIG_DFL. I've
included a testcase too.
Do people think this is the way to go? I think the alternative
is the approach Python took: patch the various bits of code
that fork&exec and have them restore the signal handler
manually.
---
diff -rN old-ghc/rts/posix/Signals.c new-ghc/rts/posix/Signals.c
472a473,477
> static void
> ignoreSigPipe(int sig)
> {
> }
>
528,529c533,535
< // ignore SIGPIPE; see #1619
< action.sa_handler = SIG_IGN;
---
> // ignore SIGPIPE; see #1619. Don't use SIG_IGN since that'd
> // be inherited by any children that get fork&exec'd.
> action.sa_handler = &ignoreSigPipe;
531c537
< action.sa_flags = 0;
---
> action.sa_flags = SA_RESTART;
---
Testcase:
diff -rN old-testsuite/tests/ghc-regress/rts/all.T
new-testsuite/tests/ghc-regress/rts/all.T
86a87,88
>
> test('exec_signals', [cmd_prefix('$MAKE exec_signals-prep &&
> ./exec_signals_prepare')], compile_and_run, [''])
diff -rN old-testsuite/tests/ghc-regress/rts/exec_signals_child.c
new-testsuite/tests/ghc-regress/rts/exec_signals_child.c
0a1,47
> #include
> #include
> #include
>
> // Prints the state of the signal handlers to stdout
> int main()
> {
> int open = 0, i;
> sigset_t blockedsigs;
>
> printf("ChildInfo { masked = [");
>
> sigprocmask(SIG_BLOCK, NULL, &blockedsigs);
> for(i = 0; i < NSIG; ++i)
> {
> int ret = sigismember(&blockedsigs, i);
> if(ret >= 0)
> {
> if(!open)
> open=1;
> else
> printf(",");
> printf("(%d,%s)", i, ret == 1 ? "True" : "False");
> }
> }
> printf("], handlers = [");
>
> open = 0;
> for(i = 0; i < NSIG; ++i)
> {
> struct sigaction old;
> if(sigaction(i, NULL, &old) >= 0)
> {
> if(!open)
> open=1;
> else
> printf(",");
>
> printf("(%d,%s)", i,
> old.sa_handler == SIG_IGN ? "Ignored" :
> (old.sa_handler == SIG_DFL ? "Default" : "Handled"));
> }
> }
> printf("]}");
>
> return 0;
> }
diff -rN old-testsuite/tests/ghc-regress/rts/exec_signals.hs
new-testsuite/tests/ghc-regress/rts/exec_signals.hs
0a1,20
> import System.Process
> import System.Posix.Signals
> import Control.Monad(when)
>
> data SigState = Ignored | Default | Handled
> deriving (Eq, Read, Show)
>
> data ChildInfo = ChildInfo {
> masked :: [(Int,Bool)],
> handlers :: [(Int, SigState)] }
> deriving (Read, Show)
>
> main = do out <- readProcess "./exec_signals_child" [] ""
> let ci = read out :: ChildInfo
> blockedSigs = [x | (x, True) <- masked ci]
> ignoredSigs = [x | (x, Ignored) <- handlers ci]
> when (not $ null blockedSigs) $
> putStrLn ("signals " ++ show blockedSigs ++ " are blocked")
> when (not $ null ignoredSigs) $
> putStrLn ("signals " ++ show ignoredSigs ++ " are ignored")
diff -rN old-testsuite/tests/ghc-regress/rts/exec_signals_prepare.c
new-testsuite/tests/ghc-regress/rts/exec_signals_prepare.c
0a1,29
> #include
> #include
> #include
> #include
>
> // Invokes a process, making sure that the state of the signal
> // handlers has all been set back to the unix default.
> int main(int argc, char **argv)
> {
> int i;
> sigset_t blockedsigs;
> struct sigaction action;
>
> // unblock all signals
> sigemptyset(&blockedsigs);
> sigprocmask(SIG_BLOCK, NULL, NULL);
>
> // reset all signals to SIG_DFL
> memset(&action, 0, sizeof(action));
> action.sa_handler = SIG_DFL;
> action.sa_flags = 0;
> sigemptyset(&action.sa_mask);
> for(i = 0; i < NSIG; ++i)
> sigaction(i, &action, NULL);
>
> execv(argv[1], argv+1);
> fprintf(stderr, "failed to execv %s\n", argv[1]);
> return 0;
> }
diff -rN old-testsuite/tests/ghc-regress/rts/Makefile
new-testsuite/tests/ghc-regress/rts/Makefile
29a30,32
> exec_signals-prep::
> $(CC) -o exec_signals_child exec_signals_child.c
> $(CC) -o exec_signals_prepare exec_signals_prepare.c
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Suggestion for bang patterns documentation
I got confused by the GHC documentation recently, I was wondering how it could be improved. From: http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.html > A bang only really has an effect if it precedes a variable or wild-card > pattern: > f3 !(x,y) = [x,y] > f4 (x,y) = [x,y] > Here, f3 and f4 are identical; putting a bang before a pattern that > forces evaluation anyway does nothing. The first sentence is true, but only in settings where the pattern is being evaluated eagerly -- the bang in: > f3 a = let !(x,y) = a in [1,x,y] > f4 a = let (x,y) = a in [1,x,y] has an effect. The first time I read this, I took the first sentence to be a unqualified truth and ended up thinking that !(x,y) was equivalent to (x,y) everywhere. Stuff that comes later actually clarifies this, but I missed it. What about making the distinction clear upfront? Something like: > A bang in an eager pattern match only really has an effect if it precedes a > variable > or wild-card pattern: > f3 !(x,y) = [x,y] > f4 (x,y) = [x,y] > Because f4 _|_ will force the evaluation of the pattern match anyway, f3 and > f4 > are identical; the bang does nothing. It also might be a good idea to immediately follow this with the let/where usage: > A bang can also preceed a let/where binding to make the pattern match strict. > For example: > let ![x,y] = e in b > is a strict pattern... (in the existing docs, let comes a bit later): Just a thought. Hopefully someone can come up with a better way of wording what I'm getting at. Thanks, -Brian _ Windows Live™ Hotmail®…more than just e-mail. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_hm_justgotbetter_howitworks_022009___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Display of associated types in GHCi
This feature is mentioned as a todo on the GHC wiki: http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsStatus (under "additional features"). I think it's just something that'd be nice but hasn't made it to the top of the implementers' priorities yet. The next step is probably to submit a feature request and add yourself on the CC: list (to "vote" for this feature). http://hackage.haskell.org/trac/ghc/wiki/ReportABug Thanks, Brian Bloniarz I have a question about the display of names for associated types in GHCi. I have a module with a matrix type constructor: > data (Natural r, Natural c) => Matrix r c t = Matrix [[t]] deriving (Eq) which uses type-level naturals to provide dimension checking. A type class for multiplication: > class Multiply a b where > type Product a b > times :: a -> b -> Product a b and an instance for matrix multiplication: > instance (Natural a, Natural b, Natural c, Num t) => Multiply (Matrix a b t) > (Matrix b c t) where > type Product (Matrix a b t) (Matrix b c t) = Matrix a c t > times m1 m2 = ... All of this works really well, I get dimension checking (and inference), and lot of other goodies. My question has to do with the following GHCi session: *Main> let a = matrix two two [[1,1],[2,6]] *Main> :t a a :: Matrix Two Two Integer *Main> :t a `times` a a `times` a :: Product (Matrix Two Two Integer) (Matrix Two Two Integer) Am I correct that the type denoted by "Product (Matrix Two Two Integer) (Matrix Two Two Integer)" is always "Matrix Two Two Integer"? It certainly behaves that way in more complicated expressions, which is desirable. If so, could someone explain the reason why GHCi chooses not to simplify such types for display? Could it? Is there a reason why such simplification would be undesirable (when it is possible, I understand that it wouldn't be if type variables were present)? Thanks, Doug McClean _ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
