Re: [GHC] #2790: Use -fregs-graph by default
#2790: Use -fregs-graph by default -+-- Reporter: igloo |Owner: benl Type: task | Status: assigned Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by igloo): Thanks, Ben! It was on amd64/Linux. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2790#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2790: Use -fregs-graph by default
#2790: Use -fregs-graph by default -+-- Reporter: igloo |Owner: benl Type: task | Status: assigned Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.8.3 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonpj): Thank you for taking this on, Ben. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2790#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
#1409: Allow recursively dependent modules transparently (without .hs-boot or
anything)
-+--
Reporter: Isaac Dupree |Owner:
Type: feature request | Status: new
Priority: normal|Milestone: _|_
Component: Compiler | Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Changes (by augustss):
* cc: lenn...@augustsson.net (added)
Comment:
I would settle for a solution where I annotate those entities in a module
that would go in the hs-boot file. So instead of me having to go through
the trouble of creating an extra file I could just say, e.g.,
{{{
{-# MODULE_MUTUAL_RECURSION_BREAKER T, foo #-}
data T = ...
foo :: ...
foo = ...
}}}
The values that have an annotation would have to have a type signature.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1409#comment:13
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3187: ghc-pkg -f new.package.conf register foo.conf fails if new.package.conf does not exist.
#3187: ghc-pkg -f new.package.conf register foo.conf fails if new.package.conf does not exist. -+-- Reporter: JeremyShaw|Owner: Type: bug | Status: reopened Priority: normal|Milestone: Component: Package system| Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * component: Compiler = Package system -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3187#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2924: createDirectory: permission denied
#2924: createDirectory: permission denied +--- Reporter: simonmar |Owner: Type: bug | Status: new Priority: normal |Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | +--- Changes (by simonmar): * milestone: 6.12 branch = 6.12.1 Comment: I don't have a good idea how to proceed on this. Can you supply a small test case based on your scenario that fails? The only thing I can think of on the GHC side that might be a factor here is our use of Win32 file sharing: we call `_sopen` with `SH_DENYRW` or `SH_DENYWR`, which translates into use of the `FILE_SHARING_READ`/`FILE_SHARING_WRITE` flags to `CreateFile`. This is to implement the Haskell 98 single-writer multi-reader (mis-)feature. Look at `libraries/base/includes/HsBase.h`, `__hscore_open()`. Of course we really ought to be using the Win32 API directly, but that's a separate issue; using crt functions should work. Once a Handle has been closed with `hClose` there's nothing left on the Haskell side of things - the finalizer will run a bit later, but it's a no-op on closed Handles, and doesn't make any OS calls. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2924#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2924: createDirectory: permission denied
#2924: createDirectory: permission denied +--- Reporter: simonmar |Owner: Type: bug | Status: new Priority: normal |Milestone: 6.12.1 Component: libraries/directory | Version: 6.10.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: x86 | +--- Comment (by NeilMitchell): I'm afraid I can't even consistently replicate this issue with my big test case - the bug always goes away as soon as I try and reduce the test case in any way. I might have a play for a test case next weekend on my home machine (more cores could increase the changes of getting it to fire), but no guarantees of success. I don't think it's a problem with the read/write flags. Between me and Lennart we've taken a look at most of the code from the Haskell down to the mingw, and it all looks sensible. Some places in mingw add wait delays between operations for unknown reasons, that could be related (but might not be). I suspect moving to native Win32 functions would cause the bug to disappear - which may be the right long term solution. The bug seems fairly important, but almost impossible to debug - not a great situation... -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2924#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
On 24/04/2009 23:04, Sigbjorn Finne wrote: I've been experiencing repeated woes over the past 4-5 months when trying to spin up build trees on Windows with the new build system. This is happening on the 3-4 boxes that I regularly develop on, which leads me to believe that this may not be limited to just me.. The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when compiled and linked via the 'ghc' that's configured against, will produce .exe's that crashes right out of the gates. gdb'ing the generated binaries, the crash is happening in the CRT startup code with some further poking around I've been able to determine that it is the explicit presence of -l options for 'kernel32' and 'msvcrt' when linking that's the cause. This is with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is well-behaved, but ghc is still using gcc-3.4.5. We have seen this problem here on Satnam Singh's machine, but we eventually put it down to a conflict between versions of certain MSYS bits. There may indeed be a real problem here, I don't know. On Satnam's machine we established that the problem was provoked by updating binutils, and the solution was don't do that (Satnam had originally done this because the windres that comes with MSYS was incompatible with GHC, but that can be worked around by just copying in a suitable windres). We also tracked it down as far as compiling a trivial C program with -lmsvcrt. Incedentally if you follow the instructions on the wiki exactly, you won't run into this problem: http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. There's a couple of things that are odd here: * base.cabal files have kernel32 and msvcrt as extra-libraries. This is clearly not required when doing invocations via ld(1), and causes considerable mischief, so it'd be good if there was a way in .cabal files to distinguish between stuff that goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's InstalledPackageInfos. (Is there? Couldn't locate anything appropriate while working with the Cabal sources..) * 'base' needing to include these two dependencies even for GHCi usage. A running RTS will have these loaded already, so it really ought to have primed the list of opened DLLs by explicitly loading them upon initialization of the linker. [I've got a trivial patch against rts/Linker.c that does this; can forward/commit if of interest..] I've no idea why these library dependencies are there. It might well be historical. I'm happy to defer to Windows experts such as yourself on whether we should have them or not (I guess not?). * In addition to the patch referred to above, to solve these problems, I had to scrub libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the package.conf's for the versions of ghc I'm building against had to be edited, limiting the use of 'kernel32' and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' packages. Long and rambling..hope you made it this far ;-) Is anyone else running into this issue should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. One open question is whether we should expect gcc foo.c -lmsvcrt to work. It works with older versions of MSYS/mingw, but apparently not with more recent versions. On the face of it this seems like it ought to be harmless, since msvcrt will eventually be linked in anyway. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -+-- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by guest): I *think* there are annoying situations involving recursive (or just lots of back-and-forth between modules) of `data`, `type` or `class` declarations that simply can't be solved with simple pragmas/hs-boots (possibly even some of those annoying situations would be non-terrible programming style :-) ). Maybe I should write a few examples? P.S. also a pragma like MODULE_MUTUAL_RECURSION_BREAKER would involve a limited bit of NOINLINE no strictness analysis (etc.) semantics, as we already have with hs-boot: just to be aware of. -Isaac Dupree -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1409#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3187: ghc-pkg -f new.package.conf register foo.conf fails if new.package.conf does not exist.
#3187: ghc-pkg -f new.package.conf register foo.conf fails if new.package.conf does not exist. -+-- Reporter: JeremyShaw|Owner: Type: bug | Status: closed Priority: normal|Milestone: Component: Package system| Version: 6.10.2 Severity: normal| Resolution: invalid Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * status: reopened = closed * resolution: = invalid Comment: Just `echo [] new.package.conf` to initialise `new.package.conf`. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3187#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2744: Missing requirement check for hsc2hs
#2744: Missing requirement check for hsc2hs -+-- Reporter: jputcu|Owner: Type: bug | Status: closed Priority: normal|Milestone: 6.12.1 Component: Build System | Version: 6.10.1 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Linux Architecture: x86 | -+-- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: The new build system doesn't use the installed `hsc2hs`, it always uses the one in the build tree. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2744#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3115: mark ghc.cabal so that unsuspecting newbies don't try to edit it
#3115: mark ghc.cabal so that unsuspecting newbies don't try to edit it
-+--
Reporter: nr|Owner:
Type: feature request | Status: closed
Priority: normal|Milestone: 6.12.1
Component: Build System | Version: 6.11
Severity: minor | Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Changes (by simonmar):
* status: new = closed
* resolution: = fixed
Comment:
In the new build system I did this (the patch isn't in HEAD, it came in as
part of the new build system megapatch):
{{{
Fri Apr 24 14:42:07 BST 2009 Simon Marlow marlo...@gmail.com
* Add warnings to the top of pre-processed files (#3115)
I tried adding a preamble to the generated versions of these files
using autoconf, but that turns out not to work very well. You have to
generate an intermediate file with the preamble, and then the
intermediate file doesn't get updated if the original file changes.
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3115#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2107: make install doesn't install local copy of manual
#2107: make install doesn't install local copy of manual -+-- Reporter: tim |Owner: Type: feature request | Status: closed Priority: high |Milestone: 6.12.1 Component: Build System | Version: 6.9 Severity: minor | Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * status: new = closed * resolution: = fixed -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2107#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
RE: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Since this is a tricky bug, would it be worth having a Trac ticket for it, and capturing the state of play thereon? S | -Original Message- | From: glasgow-haskell-bugs-boun...@haskell.org [mailto:glasgow-haskell-bugs- | boun...@haskell.org] On Behalf Of Simon Marlow | Sent: 27 April 2009 12:59 | To: Sigbjorn Finne | Cc: glasgow-haskell-bugs@haskell.org | Subject: Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..? | | On 24/04/2009 23:04, Sigbjorn Finne wrote: | I've been experiencing repeated woes over the past 4-5 months | when trying to spin up build trees on Windows with the new build | system. This is happening on the 3-4 boxes that I regularly develop on, | which leads me to believe that this may not be limited to just me.. | | The problem is that hsc2hs generated .c files (Foo_hsc_make.c) when | compiled and linked via the 'ghc' that's configured against, will produce | .exe's that crashes right out of the gates. gdb'ing the generated binaries, | the crash is happening in the CRT startup code with some further poking | around I've been able to determine that it is the explicit presence of -l | options for 'kernel32' and 'msvcrt' when linking that's the cause. This is | with a variety of versions of 'ld' and binutils snapshots (2.17.x -- 2.19). | Using the 2.19.1 version that ships with gcc4.3.3 snapshots for mingw is | well-behaved, but ghc is still using gcc-3.4.5. | | We have seen this problem here on Satnam Singh's machine, but we | eventually put it down to a conflict between versions of certain MSYS | bits. There may indeed be a real problem here, I don't know. | | On Satnam's machine we established that the problem was provoked by | updating binutils, and the solution was don't do that (Satnam had | originally done this because the windres that comes with MSYS was | incompatible with GHC, but that can be worked around by just copying in | a suitable windres). | | We also tracked it down as far as compiling a trivial C program with | -lmsvcrt. | | Incedentally if you follow the instructions on the wiki exactly, you | won't run into this problem: | http://hackage.haskell.org/trac/ghc/wiki/Building/Preparation/Windows. | | There's a couple of things that are odd here: | | * base.cabal files have kernel32 and msvcrt as extra-libraries. This is | clearly | not required when doing invocations via ld(1), and causes considerable | mischief, | so it'd be good if there was a way in .cabal files to distinguish | between stuff that | goes into 'extraLibraries' and 'extraGHCiLibraries' in package.conf's | InstalledPackageInfos. (Is there? Couldn't locate anything appropriate | while | working with the Cabal sources..) | | * 'base' needing to include these two dependencies even for GHCi usage. A | running RTS will have these loaded already, so it really ought to have | primed | the list of opened DLLs by explicitly loading them upon initialization | of the linker. | [I've got a trivial patch against rts/Linker.c that does this; can | forward/commit if | of interest..] | | I've no idea why these library dependencies are there. It might well be | historical. I'm happy to defer to Windows experts such as yourself on | whether we should have them or not (I guess not?). | | * In addition to the patch referred to above, to solve these problems, I | had to scrub | libraries/base/base.cabal of 'kernel32' and 'msvcrt' + the | package.conf's for the | versions of ghc I'm building against had to be edited, limiting the use | of 'kernel32' | and 'msvcrt' to extraGHCiLibraries for both the 'base' and 'Win32' | packages. | | Long and rambling..hope you made it this far ;-) Is anyone else running | into this issue | should we do something about it? If not, details of compilation | environment that | you've got that avoids running into this issue would be most welcome. | It's a bit of a | chore spinning up new builds, as is. | | One open question is whether we should expect gcc foo.c -lmsvcrt to | work. It works with older versions of MSYS/mingw, but apparently not | with more recent versions. On the face of it this seems like it ought | to be harmless, since msvcrt will eventually be linked in anyway. | | Cheers, | Simon | ___ | Glasgow-haskell-bugs mailing list | Glasgow-haskell-bugs@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2619: Can't build older compiler
#2619: Can't build older compiler
-+--
Reporter: judah |Owner:
Type: bug | Status: closed
Priority: normal|Milestone: 6.12.1
Component: Build System | Version: 6.11
Severity: normal| Resolution: fixed
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Changes (by simonmar):
* status: reopened = closed
* resolution: = fixed
Comment:
The new build system copes with bootstrapping using a newer GHC version,
or at least it no longer fails for bogus reasons like picking the wrong
version of the ghc package. Here's one I built earlier:
{{{
$ ./inplace/bin/ghc-stage2 --info
[(Project name,The Glorious Glasgow Haskell Compilation System)
,(Project version,6.11.20090423)
,(Booter version,6.11.20090424)
,(Stage,2)
,(Interface file version,6)
,(Have interpreter,YES)
,(Object splitting,YES)
,(Have native code generator,YES)
,(Support SMP,YES)
,(Unregisterised,NO)
,(Tables next to code,YES)
,(Win32 DLLs,)
,(RTS ways,l debug thr thr_debug thr_l )
,(Leading underscore,NO)
,(Debug on,False)
]
}}}
In order to build GHC using a snapshot (including a newer snapshot), you
have to configure using the new flag `--enable-bootstrap-with-devel-
snapshot`. We don't guarantee that bootstrapping with a development
snapshot will work, due to API changes during the development cycle.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2619#comment:18
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -+-- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonpj): Clearly a lot of people are interested in this ticket, but I'm not clear why: * Writing an `hs-boot` file is very like writing a module signature in ML; and that in turn is a bit like writing a type signature on a function. Why is that so bad? * At the moment I am very un-clear about the ''design'' of a viable alternative. Lennart's recent suggestion comes closest; but does that meet the goals of others. Once there is a clear motivation, and a clear design, it'll become easier to comment about how easy or difficult it is to implement. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1409#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -+-- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by augustss): For me the reason to get rid of the -boot files is that each of them is one more file. One more file that duplicates information that occurs somewhere else, so when I change something I have to change it in two places. There are also build system complications (not so much when using ghc --make), because there are new file types, new kinds of dependencies to figure out etc., etc. It just a medium pain, but enough of a pain that I sometimes go through unnatural contorions just to avoid mutually recursive modules when it would actually have been the natural solution. I have an alternate design proposal: Leave the pragma as is, i.e. SOURCE on some modules, but require an explicit list of imports when using SOURCE. Also get rid of the -boot file. I can just about write a sed script that will generate the correct -boot file from that information, so it feels like ghc might be able to do it too. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1409#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -+-- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonmar): Isn't the problem that you can't quite write a sed script to generate the hs-boot file, because you can't figure out what the imports should be? The point of the hs-boot file is that it lets GHC break the import recursion by specifying a smaller set of imports than the main .hs file has. In reply to Simon's question: I think people would like GHC to resolve mutually recursive modules automatically by using a fixed-point calculation in the module system, in the way that Diatchki/Jones/Hallgren did in their Haskell Workshop '02 paper: [http://portal.acm.org/citation.cfm?id=581692]. This would be a huge upheaval in GHC of course, and it seems to be completely at odds with separate compilation. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1409#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -+-- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by augustss): Well, I suggested that when using SOURCE you have to supply the import list. And I would also require the imported values to have type signatures in the other module. With those premises I can write a dodgy sed script that kinda does the work. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1409#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1502: GHC should integrate better with mingw
#1502: GHC should integrate better with mingw -+-- Reporter: eivuokko |Owner: Type: feature request | Status: closed Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.6.1 Severity: normal| Resolution: fixed Keywords: windows | Difficulty: Unknown Testcase:| Os: Windows Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * status: new = closed * resolution: = fixed Comment: Replying to [comment:5 claus]: Instead of including the mingw installer, how about preserving the internal directory layout of the bits of mingw that get included? GHC now does this, in the new build system. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1502#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -+-- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by guest): Replying to [comment:16 augustss]: For me the reason to get rid of the -boot files is that each of them is one more file. One more file that duplicates information that occurs somewhere else, so when I change something I have to change it in two places. There are also build system complications (not so much when using ghc --make), because there are new file types, new kinds of dependencies to figure out etc., etc. It just a medium pain, but enough of a pain that I sometimes go through unnatural contorions just to avoid mutually recursive modules when it would actually have been the natural solution. I agree, Why need another file to contain those information? Why GHC can't pick-up those information through analysis source file? Maybe it's a hard work to GHC developer, but i think it's worth to do. It's not problem just write .hs-boot file, it's not too hard to write .hs- boot file. But Haskell programmer will spend too *much* time to synchronous information between .hs file and .hs-boot file, and special to *big* project. And i think the *natural* way is GHC do those work automatically. Then save time and less problem (bug). -- Andy -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1409#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3016: Long compile times, large memory use with static data in 6.10
#3016: Long compile times, large memory use with static data in 6.10 ---+ Reporter: dons|Owner: igloo Type: bug | Status: new Priority: normal |Milestone: 6.12.1 Component: Compiler| Version: 6.10.1 Severity: normal | Resolution: Keywords: static data | Difficulty: Unknown Testcase: simplCore/should_compile/T3016 | Os: Unknown/Multiple Architecture: Unknown/Multiple| ---+ Comment (by awick): Ah-hah! It appears that some/most of this has to do with -fsplit-objs being set. I didn't notice this before because it's hidden in a Cabal file on our machines. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3016#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -+-- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by guest): * cc: ben.frank...@online.de (added) Comment: I absolutely hate it if I have to write a .hc-boot file. So I try to avoid mutually recursive modules if possible. This is bad because it makes me concentrate on boring things when I should be thinking about interesting things instead. Cheers Ben Franksen -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1409#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Linking hsc2hs .c output on Windows w/ build system: is it just me..?
Sigbjorn Finne wrote: Long and rambling..hope you made it this far ;-) Is anyone else running into this issue should we do something about it? If not, details of compilation environment that you've got that avoids running into this issue would be most welcome. It's a bit of a chore spinning up new builds, as is. Yes, I've experienced exactly these problems. And I believe we definitely should do something about it. Kyra ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2775: Type Family panic
#2775: Type Family panic -+-- Reporter: camio |Owner: chak Type: bug | Status: closed Priority: normal|Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: blocker | Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by chak): * status: new = closed * resolution: = fixed Comment: This works now in the head with the pure equality solver. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2775#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1409: Allow recursively dependent modules transparently (without .hs-boot or anything)
#1409: Allow recursively dependent modules transparently (without .hs-boot or anything) -+-- Reporter: Isaac Dupree |Owner: Type: feature request | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by nr): * cc: n...@cs.tufts.edu (added) Comment: I am quite interested in extending Haskell import lists to be more like ML signatures (don't worry, no ML functors, I promise!). With such an explicit signature, I hope it would be possible to eliminate the hs-boot file. Or as a further step, one could compile signatures separately, then use them instead of .hs-boot. Also, I think Derek Dreyer could be persuaded to have a look at this problem. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1409#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2796: GHC panic related to associated types
#2796: GHC panic related to associated types -+ Reporter: FSalad |Owner: chak Type: bug | Status: closed Priority: normal |Milestone: 6.12.1 Component: Compiler | Version: 6.10.1 Severity: normal | Resolution: fixed Keywords: associated types, associated type synonyms, type families, family, panic | Difficulty: Unknown Testcase: | Os: Linux Architecture: Unknown/Multiple | -+ Changes (by chak): * status: new = closed * resolution: = fixed Comment: This works now with the new pure equality solver. To be precise, the example program fails to compile due to a type error, but it doesn't lead to a compiler panic anymore. You may want to build a copy of the latest HEAD (or grab a snapshot) and check that the type error is what you expected. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2796#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2828: TcTyFuns.uMeta: normalisation shouldn't allow x ~ x
#2828: TcTyFuns.uMeta: normalisation shouldn't allow x ~ x -+-- Reporter: pizza |Owner: chak Type: bug | Status: closed Priority: normal|Milestone: 6.12 branch Component: Compiler | Version: 6.10.1 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Linux Architecture: x86 | -+-- Changes (by chak): * status: new = closed * resolution: = fixed Comment: Works with the new pure equality solver in the HEAD. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2828#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #2360: More information in occurs check message
#2360: More information in occurs check message -+-- Reporter: ajd |Owner: chak Type: feature request | Status: new Priority: normal|Milestone: 6.12 branch Component: Compiler | Version: 6.8.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by chak): See also #3169 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2360#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re[2]: Threads and memory management
Hello Simon, Monday, April 27, 2009, 2:13:26 PM, you wrote: This is a very strange result: the user time should not *decrease*, but rather should stay the same or increase a bit when adding cores. If ability to run two threads simultaneous may increase performance in some scenarios. one example is consumer+producer threads. with 2 OS threads all produced data are consumed immediately, so we live inside L2 cache. with 1 OS thread produced data overflow the cache before threads are switched, making execution much slower -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Threads and memory management
On 25/04/2009 13:31, j.waldmann wrote: Here is some more data. It seems the behaviour depends on 32/64 bit arch? ### waldm...@master:~/tmp$ uname -a Linux master 2.6.18-6-amd64 #1 SMP Fri Dec 12 05:49:32 UTC 2008 x86_64 GNU/Linux waldm...@master:~/tmp$ time ./Par +RTS -N1 496165411 496165411 real0m22.580s user0m22.541s sys 0m0.040s waldm...@master:~/tmp$ time ./Par +RTS -N2 496165411 496165411 real0m21.259s user0m26.678s sys 0m0.164s waldm...@box:~/tmp uname -a Linux box 2.6.27.21-0.1-pae #1 SMP 2009-03-31 14:50:44 +0200 i686 i686 i386 GNU/Linux waldm...@box:~/tmp time ./Par +RTS -N1 496165411 496165411 real0m29.802s user0m29.670s sys 0m0.028s waldm...@box:~/tmp time ./Par +RTS -N2 496165411 496165411 real0m11.219s user0m14.917s sys 0m0.164s This is a very strange result: the user time should not *decrease*, but rather should stay the same or increase a bit when adding cores. If your program is GC-bound, then using a 32-bit build will improve performance, simply because it is shoveling half as much memory around. Check whether it is GC-bound by using +RTS -sstderr. Anyway, the current situation is that with GHC 6.10.2 there are a lot of performance quirks and bottlenecks with respect to parallel programs, some of which have been squashed in HEAD. Try a recent HEAD snapshot if you can, or wait for 6.12.1. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.10.3 plans
On 27/04/2009 01:28, Sigbjorn Finne wrote:
On 4/25/2009 07:16, Ian Lynagh wrote:
On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote:
We do have a WARNING pragma, incedentally:
http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma
I don't think that using it for this would be a good idea, though. It
would mean that people who really do want
Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer}
would not be able to write warning-free code.
Repeating myself, I suppose :) , but I would be happy to take that hit
for 6.10.3 if it avoids other GHC users from spending unproductive
time getting on top of this change. ymmv.
As a compromise, how about expanding the runtime error message to make
it clear that this is a change in 6.10.2?
finalizer: error: a C finalizer called back into Haskell.
This was previously allowed, but is disallowed in GHC 6.10.2 and later.
To create finalizers that may call back into Haskll, use
Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Threads and memory management
I've added more notes to this page: http://haskell.org/haskellwiki/Performance/Parallel berthold: Message: 8 Date: Fri, 24 Apr 2009 19:20:46 +0200 From: Johannes Waldmann waldm...@imn.htwk-leipzig.de Subject: Threads and memory management To: glasgow-haskell-users@haskell.org glasgow-haskell-users@haskell.org Message-ID: 49f1f4ee.8070...@imn.htwk-leipzig.de Content-Type: text/plain; charset=iso-8859-1 Dear all, I was wondering what is the current status of the ghc RTS with respect to threading. Is it true that the allocator and deallocator (garbage collector) are still single-threaded? I made this example: ... Well, then, if the two Haskell threads are (nearly) completely independent like the above, it would be better to compile and run two separate executables and have them communicate via the OS (pipe or port). But that shouldn't be! (the OS being better than Haskell) Is there was a way of partitioning the memory (managed by the ghc RTS) in totally independent parts that each have their stand-alone memory management. Of course then all communication had to go via some Control.Concurrent.Chan, but that should be fine, if there is little of them. Well, just some thought. This idea can't be new? Tell me why it couldn't possibly work ... J.W. Hello everybody, Since I did not see any other replies, I thought I might give you some pointers to more information. Other people will perhaps follow up with more details. In all, quite a few things are recently going on about threading in the GHC world, and it is even difficult to keep the oversight. - GHC has undergone a big overhaul with respect to threading support since last September. I have started this work at Microsoft Research last summer, and a lot more has been done by Simon Marlow since. There are forthcoming papers (mainly one submitted to ICFP) about this work. The main focus here was the shared-heap implementation of the Glasgow-parallel Haskell programming model (see http://www.macs.hw.ac.uk/~dsg/gph/ , mainly the paper here: http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html). This programming model is supported in GHC versions since 2004 already, but should now deliver much better performance. That said, the vast majority of the latest GHC optimisations carried out in the GHC HEAD aim at improving thread performance (the explicit basis of the more implicit programming model), and thus relate directly to what you observe. The version you have tested with is GHC-6.10.2, which does not include substantial threading optimisations. - a related question is tool support for parallel performance tuning. Very recently, GHC (HEAD) supports a visual post-mortem analysis, and a graphical tool ThreadScope has been developed by Satnam Singh and others. http://raintown.org/?page_id=132 There is a related posting in glasgow-haskell-users (11 March). - GHC has parallel garbage collection since 2007 already. However, recent work showed that this parallel GC sometimes hampers performance, in particular on Linux systems. See this thread for more: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-April/017050.html - about your remark that separate OS processes should communicate, rather than having the Haskell RTS manage all threads: yes, there are programming models around which aim at parallel Haskell with distributed heap. Aside from the older GpH cluster implementations, you might have a look at the language Eden: http://www.mathematik.uni-marburg.de/~eden/?content=paper (and personally, I might apologise for the suboptimal web presence...) Using Eden (and its implementation) would be a way to realise the model you propose, communicating processes with separate heaps, but managed by a common parallel runtime system and programmed in one single program. Let me add that Eden also provides a tool with features very similar to what recently became ThreadScope. Interestingly, a number of recent experiments have shown that Eden has competitive performance to the shared heap GpH implementation when executed on multicores, delegating all communication to the underlying middleware (most commonly PVM). Early papers discussing alike results have been published recently or are in preparation. http://www-fp.cs.st-and.ac.uk/~kh/mainICPP09.pdf I strongly support the idea to collect all this related information systematically! Kickoff is already present here: http://haskell.org/haskellwiki/Performance/Parallel However, the question is where to start... the field is indeed very broad, and the page above will surely focus on GHC rather than general ideas. So I hesitate in dropping all this information into the wiki and rather send a mail for now. Cheers Jost Berthold ___ Glasgow-haskell-users mailing list
Re: 6.10.3 plans
Simon Marlow wrote: On 27/04/2009 01:28, Sigbjorn Finne wrote: ... As a compromise, how about expanding the runtime error message to make it clear that this is a change in 6.10.2? finalizer: error: a C finalizer called back into Haskell. This was previously allowed, but is disallowed in GHC 6.10.2 and later. To create finalizers that may call back into Haskll, use Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr. That's definitely helpful; I'm all for it. Hope there's time available to put it in. cheers --sigbjorn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 6.10.3 plans
Hi,
Perhaps it would make sense to add something along those lines to the
documentation for Foreign.newForeignPtr as well?
-Iavor
On Mon, Apr 27, 2009 at 5:32 AM, Simon Marlow marlo...@gmail.com wrote:
On 27/04/2009 01:28, Sigbjorn Finne wrote:
On 4/25/2009 07:16, Ian Lynagh wrote:
On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote:
We do have a WARNING pragma, incedentally:
http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma
I don't think that using it for this would be a good idea, though. It
would mean that people who really do want
Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer}
would not be able to write warning-free code.
Repeating myself, I suppose :) , but I would be happy to take that hit
for 6.10.3 if it avoids other GHC users from spending unproductive
time getting on top of this change. ymmv.
As a compromise, how about expanding the runtime error message to make it
clear that this is a change in 6.10.2?
finalizer: error: a C finalizer called back into Haskell.
This was previously allowed, but is disallowed in GHC 6.10.2 and later.
To create finalizers that may call back into Haskll, use
Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Chimeric syntax
I've been hacking along on a NetBeans Haskell plugin (*) Looking at
Parser.y.pp, because both Eclipse and NetBeans work with antlr, it
seems like there are interesting cases in which chimeric constructions
parse correctly. Here's an example:
class ParsedModule m where
let { a = 1; b = 2; } in a + b :: Int :: Int
This is mostly accepted by ghc, which complains with an invalid type signature.
This got me to thinking that either ghc has issues or I have some
fundamental misunderstanding of Haskell syntax. Or, maybe I should use
someone else's grammar.
-scooter
(*) Don't tell me about eclipsefp2: I know already. It's the Monty
Python parrot of Haskell IDE support. And the code is about as
Teutonic as one can get. :-)
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] LAST CALL: Haskell Communities and Activities Report
Dear Haskellers, It is not yet too late to contribute to the May 2009 edition of the Haskell Communities and Activities Report. If you haven't already, please write an entry for your new project, or update your old entry. Please mail your entries to h...@haskell.org in LaTeX format. More information can be found in the original Call for Contributions at http://www.haskell.org/pipermail/haskell/2009-April/021180.html I look forward to receiving your contributions. Thanks a lot, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:vo...@tcs.inf.tu-dresden.de ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Announce: GraphViz: Change of Maintainer
I no longer have the time to continue development of the (apparently, judging from the number of emails I'm getting, rather popular) graphviz package. Fortunately, Ivan Lazar Miljenovic who has extended it himself and sent me patches (some of which I did get round to folding in) has agreed to take on the package. Please direct all further queries to him! Many thanks Ivan! Matthew ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: Haskell File Manager
On Sun, 26 Apr 2009 18:40:57 +0100, Michael Dever michael.dev...@mail.dcu.ie wrote: FYI, The blog with a screenshot of it: http://www.mickinator.com/wordpress/?cat=5 The screenshot shows it running on Ubuntu. Does it also run on Windows XP? -- Benjamin L. Russell -- Benjamin L. Russell / DekuDekuplex at Yahoo dot com http://dekudekuplex.wordpress.com/ Translator/Interpreter / Mobile: +011 81 80-3603-6725 Furuike ya, kawazu tobikomu mizu no oto. -- Matsuo Basho^ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Typing efficient folds
Keith Battocchi wrote: data Nest a = Nil | Cons(a, (Nest (Pair a))) type Pair a = (a,a) pair f (a,b) = (f a, f b) efold :: forall n m b. (forall a. n a) - (forall a . (m a, n (Pair a)) - n a) - (forall a. Pair (m a) - m (Pair a)) - (forall l z. (l b - m (z b)) - Nest (l b) - n (z b)) efold e f g h Nil = e efold e f g h (Cons(x, xs)) = f(h x, efold e f g (g . pair h) xs) If the problem is just understanding the type error, it may help to manually check the types. You only need to look at the second branch of the function definition, since this is the case that generates the error. From the pattern-match, you get the type of xs: xs :: Nest (Pair (l b)) -- (1) Combining the type of f with the result type of the efold definition, you get the type of the result of the recursive call: efold e f g (g . pair h) xs :: n (Pair (z b)) -- (2) This function makes use of polymorphic recursion. To analyse the type of the recursive call, you need a fresh batch of type variables, so you can distinguish the types of the arguments to the recursive call from the types of the formal parameters of the function definition. Since the first three arguments to the recursive call are unchanged, you only need fresh variables for b, l and z. I'll use primed versions of these variables: efold e f g :: (l' b' - m (z' b')) - Nest (l' b') - n (z' b') -- (3) From (3), you get an alternative view of the type of xs: xs :: Nest (l' b') -- (4) You can now perform unification on these results. You need to be careful unifying with Pair types, since (Pair a) is really ((,) a a). Unifying (1) and (4), you get: Nest ((,) (l b) (l b)) ~ Nest (l' b') l' ~ (,) (l b) b' ~ (l b) -- (5) Unifying (2) and the result type from (3): n ((,) (z b) (z b)) ~ n (z' b') z' ~ (,) (z b) b' ~ (z b) -- (6) From (5) and (6), you require: l b ~ z b, and therefore l ~ z, but the forall l z in the type signature requires l and z to be independent. I'm no expert in nested data types, but I doubt there is any additional generality to be had from trying to distinguish l and z. In that case, you can write both l b and z b as a. You can also remove a superfluous tuple from the type definition: data Nest a = Nil | Cons a (Nest (Pair a)) type Pair a = (a,a) efold :: (forall a. n a) - (forall a. m a - n (Pair a) - n a) - (forall a. Pair (m a) - m (Pair a)) - (a - m a) - (Nest a - n a) efold e f g h Nil = e efold e f g h (Cons x xs) = f (h x) (efold e f g (g . pair h) xs) For example, to flatten a Nest to a simple list, you can take m to be Id and n to be [], something like this: nest = Cons 0 (Cons (1,2) (Cons ((3,4),(5,6)) Nil)) newtype Id a = Id a -- [0,1,2,3,4,5,6] flat_nest = efold [] (\(Id xs) ys - xs : concatMap (\(p,q) - [p,q]) ys) (\(Id x, Id y) - Id (x,y)) Id nest It's a little unpleasant having to use the Id type like this, but I can't see a way around it. I'd be interested to see an example with a non-trivial m. Regards, Matthew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: old-time conflict when installing phooey
Hi, Daryoush Mehrtash dmehrt...@gmail.com writes: When I try to install phooey I get conflict with old-time that I am not sure how to resolve. Any ideas? cabal install phooey Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires old-time ==1.0.0.2 however old-time-1.0.0.2 was excluded because ghc-6.10.1 requires old-time ==1.0.0.1 1. Use command ghc-pkg list list package-list, then you will get two package-list, remove same package that exist *two* package-list. (Use command ghc-pkg unregister PackageName -force remove pacakge). 2. And then remove pacakge old-time-1.0.0.2, use command ghc-pkg unregister old-time-1.0.0.2 --force. Then everything is okay. -- Andy Thanks Daryoush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] RE: [Haskell] ANN control-monad-exception-0.1: Explicitly typed exceptions
Is there a Haskell Wiki page on extensible exceptions? The paper is a fine reference, it'd be cool to have a wiki page giving programmer-oriented guidance, saying what comes with GHC what other packages are available and some simple examples of how to use them. Simon | -Original Message- | From: haskell-boun...@haskell.org [mailto:haskell-boun...@haskell.org] On Behalf Of | Pepe Iborra | Sent: 25 April 2009 19:52 | To: hask...@haskell.org | Subject: [Haskell] ANN control-monad-exception-0.1: Explicitly typed exceptions | | The control-monad-exception package [1] provides explicitly typed | exceptions for Haskell. | In other words, this is a perfect example of bundling in a Haskell | library what for other | programming languages is a native feature. | | The type of a computation in the EM monad carries a list of the exceptions that | the computation may throw. A exception is raised with 'throw', which | in addition adds it | to the type, and captured with 'catch', which correspondingly removes | it from the type. | Only safe computations (all exceptions handled) can escape from the monad. | | The encoding used for the exception list is based on a phantom type | variable carrying a | @Throws@ constraint for every exception type. Catching an exception | @e@ satifies the constraint | @Throws e@ thus removing it from the type. It is possible to teach | Throws about exception subtyping | by manually inserting new instances declaring the subtyping relations | between exceptions. I don't | believe there is a better way to handle this, as the existential | wrapper encoding used | for Control.Exception.SomeException does not reveal the subtyping | relations, but ideas are | welcome. | | Example | | GHCi infers the following types | | eval :: (Throws DivideByZero l, Throws SumOverflow l) = Expr - EM l Double | eval `catch` \ (e::DivideByZero) - return (-1) :: Throws | SumOverflow l = Expr - EM l Double | runEM (eval `catch` \ (e::SomeException) - return (-1)) :: Expr - Double | | for the code below. | | | import Control.Monad.Exception | import Data.Typeable | | data Expr = Add Expr Expr | Div Expr Expr | Val Double | eval (Val x) = return x | eval (Add a1 a2) = do | v1 - eval a1 | v2 - eval a2 | let sum = v1 + v2 | if sum v1 || sum v2 then throw SumOverflow else return sum | eval (Div a1 a2) = do | v1 - eval a1 | v2 - eval a2 | if v2 == 0 then throw DivideByZero else return (v1 / v2) | | data DivideByZero = DivideByZero deriving (Show, Typeable) | data SumOverflow = SumOverflow deriving (Show, Typeable) | | instance Exception DivideByZero | instance Exception SumOverflow | | | Comments and patches are welcome. | Cheers, | Pepe Iborra | | [1] - http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-monad- | exception | ___ | Haskell mailing list | hask...@haskell.org | http://www.haskell.org/mailman/listinfo/haskell ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Memory usage of cabal install
Hello Haskell-Café, I have a problem with high memory usage of cabal-install. Whenever I try to install or upgrade a package, cabal manages to consume 1,3G of memory before I killed it (on a 32-bit machine with 1 GB of memory). Increasing verbosity does not help, memory consumption goes up after the message Resolving dependencies... shows up. I use ghc 6.8.2 and cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library. Is there a workaround? I would like to avoid fetching building packages manually. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory usage of cabal install
Jakiej platformy dokładnie dotyczy Twój problem? Proponuję upgrade do najnowszej wersji - można ją ściągnąć ze strony GHC. Pozdrawiam Krzysztof Skrzętnicki 2009/4/27 Krzysztof Kościuszkiewicz k.kosciuszkiew...@gmail.com: Hello Haskell-Café, I have a problem with high memory usage of cabal-install. Whenever I try to install or upgrade a package, cabal manages to consume 1,3G of memory before I killed it (on a 32-bit machine with 1 GB of memory). Increasing verbosity does not help, memory consumption goes up after the message Resolving dependencies... shows up. I use ghc 6.8.2 and cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library. Is there a workaround? I would like to avoid fetching building packages manually. -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory usage of cabal install
On Mon, 2009-04-27 at 12:56 +0200, Krzysztof Kościuszkiewicz wrote: Hello Haskell-Café, I have a problem with high memory usage of cabal-install. Whenever I try to install or upgrade a package, cabal manages to consume 1,3G of memory before I killed it (on a 32-bit machine with 1 GB of memory). Increasing verbosity does not help, memory consumption goes up after the message Resolving dependencies... shows up. I use ghc 6.8.2 and cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library. The only instance of this behaviour that I know of involves using that version of cabal-install with ghc-6.10.1. http://haskell.org/cabal/FAQ.html#cabal-goes-into-an-infinite-loop--runs-out-of-memory The older version of cabal-install goes into an infinite loop when using ghc-6.10, when it is presented with two installed versions of the base package (and one depends on the other). In version 0.6.x cabal-install was updated to understand this situation. Are you absolutely sure you are using ghc 6.8 and not 6.10? Is there a workaround? I would like to avoid fetching building packages manually. If you're using ghc 6.10 then the solution is to update to cabal-install 0.6.x. If you're quite sure you are using 6.8 then the bug is unknown. It may still be worth trying upgrading to cabal-install 0.6.x. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] old-time conflict when installing phooey
On Sun, 2009-04-26 at 21:49 -0700, Daryoush Mehrtash wrote: When I try to install phooey I get conflict with old-time that I am not sure how to resolve. Any ideas? cabal install phooey Resolving dependencies... cabal: dependencies conflict: ghc-6.10.1 requires old-time ==1.0.0.2 however old-time-1.0.0.2 was excluded because ghc-6.10.1 requires old-time ==1.0.0.1 This looks very similar to: http://haskell.org/cabal/FAQ.html#dependencies-conflict but with a different core package. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Is 78 characters still a good option? Was: breaking too long lines
Richard O'Keefe wrote: On 25 Apr 2009, at 8:59 pm, Miguel Mitrofanov wrote: Something like newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) [...] For what it's worth, my personal Haskell style lines up data T = C1 ... | ... | Cn ... deriving (...) This has the clear advantage that indentation does not depend on the length of the type name as in the quite typical layout of Xiao-Yong Jin: http://www.haskell.org/pipermail/haskell-cafe/2009-April/060541.html so I'd have this as newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) where the longest line is 86 columns. (which is still too long as my reply-wrap proofs.) [...] However, indenting by 3 or 6 characters depending on data or newtype is also a bit arbitrary. Consider: newtype MyCoolMonad = MyCoolMonad (FirstTransformer (SecondTransformer (ThirdTransformer Whatever))) deriving ( Functor, Monad, FirstClass, SecondClass, ThirdClass , SomeOtherClass) Either all alternatives fit on one line or they go on separate lines each. The same should apply to all components of one alternative. Additionally, as above, a long type-application may need to be broken over several lines. (Breaking before = and having = above | looks also nice.) Pretty-printing a comma-separated list (following deriving) is an extra subject with a couple of variations: Putting commas in the front, better indicates the continuation, but the extra space following the open bracket ( looks a bit odd. (Surely one could also leave a space before the closing bracket, although I wouldn't like spaces around all brackets.) The alternative: (Functor, Monad, FirstClass, SecondClass, ThirdClass, SomeOtherClass) has the disadvantage, that the second line is only indented by one character (relative to the previous one), but intending further (+1 or +3 or even one less) is an alternative. (I'm no friend of putting the closing bracket on a separate line in the same column as the opening one. Too easily such indentations are messed up.) Cheers Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory usage of cabal install
On Mon, Apr 27, 2009 at 02:10:28PM +0100, Duncan Coutts wrote: [...] Increasing verbosity does not help, memory consumption goes up after the message Resolving dependencies... shows up. I use ghc 6.8.2 and cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library. The only instance of this behaviour that I know of involves using that version of cabal-install with ghc-6.10.1. http://haskell.org/cabal/FAQ.html#cabal-goes-into-an-infinite-loop--runs-out-of-memory [...] Are you absolutely sure you are using ghc 6.8 and not 6.10? Yes: k...@copper:~$ ghc -V ; cabal -V The Glorious Glasgow Haskell Compilation System, version 6.8.2 cabal-install version 0.5.1 using version 1.4.0.1 of the Cabal library Is there a workaround? I would like to avoid fetching building packages manually. If you're using ghc 6.10 then the solution is to update to cabal-install 0.6.x. If you're quite sure you are using 6.8 then the bug is unknown. It may still be worth trying upgrading to cabal-install 0.6.x. I'll try that and report success/failure. Thanks, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] subscribing to the comments, online Real World Haskell
Michael P Mossey wrote: Michael P Mossey wrote: However, I would like some ability to subscribe to specific comments. I want to see if people have replied to me or what the latest discussion is. Okay, to follow up my own post, I discovered the subscription button for each chapter. That's good. However, using Live Bookmarks in Firefox, I have a problem... the links that should bring me to the book itself (with the comment in context) are broken. Maybe this is the fault of Live Bookmarks. Anyone recommend another program for subscribing to comments? I recommend bloglines.com -- pretty nice interface and works well. -- John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] how can one load Prelude into ghci?
One reason it would be nice to be able to do this, is you could then
get lambdabot :src style listings of prelude function definitions by
using the ghci debugger and :list for prelude functions.
is this possible? so far I have tried
thart...@ubuntu:~/haskellInstalls/ghcInstalls/source/ghc-6.10.1/libraries/basehead
Prelude.hs
{-# OPTIONS_GHC -XNoImplicitPrelude #-}
-
thart...@ubuntu:~/haskellInstalls/ghcInstalls/source/ghc-6.10.1/libraries/baseghci
-i. Prelude.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
command line: module `Prelude' is not loaded
thart...@ubuntu:~/haskellInstalls/ghcInstalls/source/ghc-6.10.1/libraries/baseghci
Prelude.hs
GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
command line: module `Prelude' is not loaded
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: atom-0.0.2
tomahawkins: Atom is a DSL in Haskell for designed hard realtime embedded programs. At Eaton, we are using it to control hydraulic hybrid refuse trucks and shuttle buses. After my talk at CUFP (http://cufp.galois.com/2008/schedule.html), a few people inquired about atom -- I finally had a chance to upload it to Hackage. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/atom-0.0.2 Some new enhancements: - A simple rule scheduler for load balancing. - Signal probing for debug and data logging. - Functional coverage to monitor which rules have executed. - Started integration with the Yices SMT solver for bounded model checking. Experiences with our Eaton project: - 5K lines of Haskell/atom replaced 120K lines of matlab, simulink, and visual basic. - 2 months to port simulink design to atom. - 3K lines of atom generates 22K lines of embedded C. - Design composed of 450 atomic state transition rules. - Rules with execution periods from 1ms to 10s all scheduled at compile time to a 1 ms main loop. - 3 minute compilation time from atom source to ECU. - Atom design clears electronic/sw testing on first pass. - Currently in vehicle testing with no major issues. Congratulations on the release! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memory usage of cabal install
On Mon, Apr 27, 2009 at 02:10:28PM +0100, Duncan Coutts wrote: If you're using ghc 6.10 then the solution is to update to cabal-install 0.6.x. If you're quite sure you are using 6.8 then the bug is unknown. It may still be worth trying upgrading to cabal-install 0.6.x. I've upgraded to cabal-install 0.6.2 and the problem went away. Thanks for help! -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to install HOpenGL to Windows?
Am Montag, 27. April 2009 00:11:20 schrieb Duncan Coutts: On Sun, 2009-04-26 at 19:03 +0200, Sven Panne wrote: [...] * How to link programs using OpenGL This is because the GL libs are called different names on different platforms right? But they're consistent within each platform, it's just Windows vs everyone else isn't it? How about: if os(windows) extra-libraries: gl32 else extra-libraries: GL As usual, things are always a bit trickier than they appear initially: On non- Windows systems it is not always sufficient to link against libGL alone, sometimes you'll have to link against several X11 libs, too. I am not sure if this is still a widespread problem, but in the past it was. Hopefully most *nices get their dynamic library dependencies right nowadays... :-P Windows is, as always, a special beast, especially when you take Cygwin into account: On Cygwin you can either build against the native OpenGL or against Cygwin's X11 OpenGL. This can be configure via --without-x. How can we do this in .cabal files? And MacOS had some peculiarities which I can't fully remember anymore, too. * The Haskell types corresponding to the OpenGL types Does hsc2hs #type not help us with this? [...] I am not sure, because I haven't had a look at hsc2hs for a long time, and at the beginning of the OpenGL binding there were no such tools, not even the FFI in its current form. Perhaps I'll have a look at this, but to make this work, I am sure that we'll have to solve the next item: * To do the former: How to find the OpenGL C headers What's needed here? Are they not in standard locations? Cabal has support for users to specify non-standard locations. What is a standard location for headers on Windows? There is no such concept. On *nices you look into /usr/include and /usr/local/include, and that's it, unless the user tells you something different. And Apple is always a very creative company, so they decided to put *their* OpenGL headers in a completely different path where no -I flag can help... Having access to the OpenGL headers is crucial for finding out which C types are behind OpenGL types like GLint, GLenum, ... The OpenGL spec only specifies minimum requirements for these types and *not* their C mapping. * The library calling convention This is stdcall on Windows and ccall everywhere else right? How about: if os(windows) cpp-options: -DCALLCONV=stdcall else cpp-options: -DCALLCONV=ccall This should be fine, at least when we solve the Cygwin problem discussed above: The X11 OpenGL libraries on Windows do *not* use stdcall, only the native OpenGL libraries. (The whole calling convention story on Windows really, really sucks, IMHO...) Using CPP for this simple task doesn't look right, but with the current FFI I don't see a way around this, which is a shame. Any ideas/proposals for a FFI change? * How to load OpenGL extensions I don't know enough of the details here to comment. You'll have to know if wglGetProcAddress, NSAddressOfSymbol (+ a bit more code) or some variant of glXGetProcAddress has to be used, plus their necessary headers. This is probably doable via some platform switches in Cabal, too. A few general remarks: * Ignoring the (usual) Windows trouble, I like autoconf's approach of testing features instead of relying on extremely fragile platform conditionals. The latter are a constant source of troubles and from a SW engineering point of view, they are a clear step backwards. The I know my platform approach which you basically propose reminds me of the xmkmf hell from the last millennium: If X11 didn't know your platform, you had a *lot* of fun getting the platform description right. * We can go this autoconf-free route, but this is a part of my bindings which I definitely won't maintain in full time. I'll be happy to review and accept patches, but making things work on Windows, Cygwin, Linux, *BSD, MacOS X, ... is a lot of work, which is a fact I have painfully learned in the past few years. The autoconf code may be ugly, but the tons of platform differences are ugly, to. I want to work on the binding itself mainly, not on the build system, which currently works. To repeat myself: Patches are happily accepted, but I propose incremental changes and heavy testing on various platforms. * Most of the tasks my autoconf scripts perform are not specific to OpenGL at all. I guess that most bindings for non-trivial C libraries face the same challenges (Where are my libs? Where are my headers? What are my types?) Having good Cabal support for these would be very nice. Cheers, S. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Thread priority?
lane: Is there any interest or movement in developing thread priority or any other realtime support in Haskell? I think thread priorities would be really cool :) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Thread priority?
semanticphilosopher: Count me in too I've got a library that endeavours to deliver 'rate-equivalence' - i.e there may be some jitter in when the events should have occurred but their long term rate of progress is stable. Testing has shown that I can get events to occur at the right time within 1ms (99%+ of the time, with 50%+ of the events 0.5ms) - choose your O/S carefully though. And this is without resorting to marking the threads as real time with the kernel. If it matters you can tune the scheduling to further reduce the timer scheduling latency (at the cost of more CPU) and increase the fidelity of event timing another order of magnitude or more. As for 'garbage collection ruins my real time properties' argument - I've been pragmatic about this, you can configure the scheduler to go and perform a GC if it knows that it is going to sleep for a while (yes, this doesn't resolve the issues of external events arriving in that time but read on) but not perform that too often. Turning off GHCs timers (to stop it garbage collecting after it has actually been idle for a while) and having code that doesn't create vast amounts of garbage means that a GC takes 0.1ms. Now if I could see within Haskell the amount of heap that has been recently mutated and some other GC statistics when it was running I could even decide to schedule that more effectively. You could actually do this by importing symbols from Stats.c in the runtime (the same variables used for +RTS -sstderr output). I'm not sure anyone's ctually tried this yet though, but the effect would be a program that can monitor its own heap health. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Thread priority?
semanticphilosopher: Count me in too I've got a library that endeavours to deliver 'rate-equivalence' - i.e there may be some jitter in when the events should have occurred but their long term rate of progress is stable. Testing has shown that I can get events to occur at the right time within 1ms (99%+ of the time, with 50%+ of the events 0.5ms) - choose your O/S carefully though. And this is without resorting to marking the threads as real time with the kernel. If it matters you can tune the scheduling to further reduce the timer scheduling latency (at the cost of more CPU) and increase the fidelity of event timing another order of magnitude or more. As for 'garbage collection ruins my real time properties' argument - I've been pragmatic about this, you can configure the scheduler to go and perform a GC if it knows that it is going to sleep for a while (yes, this doesn't resolve the issues of external events arriving in that time but read on) but not perform that too often. Turning off GHCs timers (to stop it garbage collecting after it has actually been idle for a while) and having code that doesn't create vast amounts of garbage means that a GC takes 0.1ms. Now if I could see within Haskell the amount of heap that has been recently mutated and some other GC statistics when it was running I could even decide to schedule that more effectively. We use this to create synthetic network traffic sources and other timing/performance related activities in the wide area context - it serves our needs. This is very interesting. Do you have any further documentation / notes on controlling jitteriness? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Typing efficient folds
Matthew Brecknell haskell at brecknell.org writes: [...] Nest ((,) (l b) (l b)) ~ Nest (l' b') l' ~ (,) (l b) b' ~ (l b) -- (5) Unifying (2) and the result type from (3): n ((,) (z b) (z b)) ~ n (z' b') z' ~ (,) (z b) b' ~ (z b) -- (6) From (5) and (6), you require: l b ~ z b, and therefore l ~ z, but the forall l z in the type signature requires l and z to be independent. Thanks for explicitly writing out the unification steps; this makes it perfectly clear where things are going wrong. I was hoping to be able to have b' ~ b, l' b' ~ (l b, l b), and z' b' ~ (z b, z b). I guess it makes sense that these types can't be inferred - is there any way to explicitly add signatures somewhere so that these alternate interpretations will be used instead? This would allow l and z to remain independent. [...] efold :: (forall a. n a) - (forall a. m a - n (Pair a) - n a) - (forall a. Pair (m a) - m (Pair a)) - (a - m a) - (Nest a - n a) efold e f g h Nil = e efold e f g h (Cons x xs) = f (h x) (efold e f g (g . pair h) xs) For example, to flatten a Nest to a simple list, you can take m to be Id and n to be [], something like this: nest = Cons 0 (Cons (1,2) (Cons ((3,4),(5,6)) Nil)) newtype Id a = Id a -- [0,1,2,3,4,5,6] flat_nest = efold [] (\(Id xs) ys - xs : concatMap (\(p,q) - [p,q]) ys) (\(Id x, Id y) - Id (x,y)) Id nest It's a little unpleasant having to use the Id type like this, but I can't see a way around it. I'd be interested to see an example with a non-trivial m. It may depend on your notion of trivial, but if you've got a Nest [a] and want to get the sum of the lengths of the lists, you'd want m a to be something like K Int a where K t a = K t Thanks again for your help. Regards, Keith ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Converting IO [XmlTree] to [XmlTree]
Achim Schneider wrote: In other words: 1) Explain Pointed 2) Explain Functor 3) Explain Applicative 4) Explain Monad Why Pointed first? Functor seems more useful and more basic. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Converting IO [XmlTree] to [XmlTree]
Tillmann Rendel wrote: Achim Schneider wrote: In other words: 1) Explain Pointed 2) Explain Functor 3) Explain Applicative 4) Explain Monad Why Pointed first? Functor seems more useful and more basic. They are in order of power: every monad is an applicative; every applicative is a functor; every functor is pointed. Though I can't think of any non-functor pointiness at the moment. Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci debugger problem with :continue. is it broken, or is it me?
Most enlightening, thanks. The same effect can be seen with Debug.Trace.trace around the two versions of f. I suppose this means that the points-free/pattern binding-style version is a bit less work for ghc to execute (fewer reductions), whereas the version with lambda bound variables is easier to debug. On balance, I think I'll frequently write my functions with lambda bound variables then. Getting better use out of the ghc debugger seems worth the few extra cycles. 2009/4/26 Bernie Pope florbit...@gmail.com: 2009/4/25 Thomas Hartman tphya...@gmail.com In the program below, can someone explain the following debugger output to me? After :continue, shouldn't I hit the f breakpoint two more times? Why do I only hit the f breakpoint once? Is this a problem in the debugger? thart...@ubuntu:~/haskell-learning/debuggercat debugger.hs -- try this: -- ghci debugger.hs -- :break f -- :trace t -- :history -- should show you that f was called from h t = h . g . f $ hey! t2 = h . g . f $ heh! t3 = h . g . f $ wey! f = (f -- ++) g = (g -- ++) h = (h -- ++) ts = do putStrLn $ t putStrLn $ t2 putStrLn $ t3 What you are observing is really an artifact of the way breakpoints are attached to definitions in the debugger, and the way that GHCi evaluates code. f is clearly a function, but its definition style is a so-called pattern binding. The body contains no free (lambda bound) variables, so it is also a constant. GHCi arranges for f to be evaluated at most once. The breakpoint associated with the definition of f is fired if and when that evaluation takes place. Thus, in your case it fires exactly once. You can re-write f to use a so-called function binding instead, by eta-expansion (introduce a new fresh variable, and apply the function to it on both sides): f x = (f -- ++) x This denotes the same function, but the breakpoint on f works differently. In this case, a breakpoint attached to f will fire whenever an application of f is reduced. If you write it this way you will see that the program stops three times instead of one. You might ask: if both definitions denote the same function, why does the debugger behave differently? The short answer is that the debugger in GHCi is an operational debugger, so it exposes some of the operational details which may be invisible in a denotational semantics. In this case it revels that GHCi treats the two definitions of f differently. Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] how can one load Prelude into ghci?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 27, 2009, at 12:25 , Thomas Hartman wrote: One reason it would be nice to be able to do this, is you could then get lambdabot :src style listings of prelude function definitions by using the ghci debugger and :list for prelude functions. I think up-to-date binary versions are preferred over source versions (thus the debugger is limited in what it can do with the Prelude). You would have to copy all the Prelude sources and modify them to make them look newer. You don't need other hackery beyond that, but that's plenty enough; GHC's Prelude isn't a single file or even a small collection of files. (It might be possible to borrow the Online Report's Prelude... won't be optimum but if you're going to interpret it won't be anyway) - -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) iEYEARECAAYFAkn2GccACgkQIn7hlCsL25UOhQCgtaAgs5/bLmIJ0hM+Her7HmN3 aakAnRXKJpelTrPMfuGLf2Ro8obZET+K =UB0V -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can subclass override its super-class' default implementation of a function?
I'm not sure if this is possible at all. I'd like to do something like this: class A a where foo :: a - Double foo a = 5.0 class (A a) = B a where foo a = 7.0 data Blah = Blah data Bar = Bar instance A Blah instance B Bar let blah = Blah bar = Bar foo blah -- should print out 5 foo bar -- should print out 7 Basically, I have a bunch of instances that have a common functionality but I'd like to be able to group those instances and give each group a different default implementation of that functionality. It's so easy to do this in Java, for example, but I have no idea how to do it in Haskell. The above example will not compile, btw. Thanks a lot -- View this message in context: http://www.nabble.com/Can-subclass-override-its-super-class%27-default-implementation-of-a-function--tp23264975p23264975.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Converting IO [XmlTree] to [XmlTree]
2009/04/21 Manlio Perillo manlio_peri...@libero.it: Luke Palmer ha scritto: And many other permutations, with differing degrees of laziness and parametericity. As long as you stricly read a string from the socket, this is ok. But you can not read a string lazily. Why not? It changes the way in which the program fails (if it does) but it does not change the result. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can subclass override its super-class' default implementation of a function?
siki wrote: I'm not sure if this is possible at all. I'd like to do something like this: class A a where foo :: a - Double foo a = 5.0 class (A a) = B a where foo a = 7.0 This is currently not possible in Haskell. It's been proposed, though: http://haskell.org/haskellwiki/Class_system_extension_proposal If you have an actual example we might be able to come up with a different way of modelling it so that it does what you want, though. Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can subclass override its super-class' default implementation of a function?
No, but functionality similar to this has been proposed several times, under the name Class Aliases [1]. The big problem is in the definition of B: class (A a) = B a where ... In this case, you must make something an instance of A before it can be an instance of B, and, in order to make something an instance of A, you must provide an implementation of foo. Not providing an implementation is the same as providing the default. With the class alias proposal you would write class B a = A a where foo a = 7.0 In this case, (B a) and (A a) are the same class, but provide different default implementations for the methods. So you *cannot* declare something an instance of both B and A. But if you declare something an instance of B without providing an implementation of foo, it would use B's default, whereas instances of A would use A's default. Unfortunately, I don't believe anyone is working on implementing this proposal. It's high on my list of desired features, but I think that not all the details have been figured out with how it interacts with other features of the language. -- ryan [1] http://repetae.net/recent/out/classalias.html, http://haskell.org/haskellwiki/Class_alias On Mon, Apr 27, 2009 at 2:00 PM, siki ga...@karamaan.com wrote: I'm not sure if this is possible at all. I'd like to do something like this: class A a where foo :: a - Double foo a = 5.0 class (A a) = B a where foo a = 7.0 data Blah = Blah data Bar = Bar instance A Blah instance B Bar let blah = Blah bar = Bar foo blah -- should print out 5 foo bar -- should print out 7 Basically, I have a bunch of instances that have a common functionality but I'd like to be able to group those instances and give each group a different default implementation of that functionality. It's so easy to do this in Java, for example, but I have no idea how to do it in Haskell. The above example will not compile, btw. Thanks a lot -- View this message in context: http://www.nabble.com/Can-subclass-override-its-super-class%27-default-implementation-of-a-function--tp23264975p23264975.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can subclass override its super-class' default implementation of a function?
The actual problem is quite similar to the one that I provided or to the one in the description of the proposed extension that you linked. Someone on another forum suggested record functions but I'm not sure I understood correctly how that would work around this problem. Any suggestion is greatly appreciated! Thanks, -Gabor Martijn van Steenbergen-2 wrote: siki wrote: I'm not sure if this is possible at all. I'd like to do something like this: class A a where foo :: a - Double foo a = 5.0 class (A a) = B a where foo a = 7.0 This is currently not possible in Haskell. It's been proposed, though: http://haskell.org/haskellwiki/Class_system_extension_proposal If you have an actual example we might be able to come up with a different way of modelling it so that it does what you want, though. Martijn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://www.nabble.com/Can-subclass-override-its-super-class%27-default-implementation-of-a-function--tp23264975p23265759.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Question about implementing an off-side rule in Parsec 2
Hello everyone, I'm doing a bachelor project focused on comparing parsers. One of the parser libraries I'm using is Parsec (2) and I'm going to implement a very small subset of haskell with it, with as most important feature the off-side rule (indentation based parsing) used in function definitions and possibly in where clauses. But I'm still a bit stuck on how to implement this cleanly. I tried to search for some examples on blogs but I haven't found anything yet. As far as I can see the way to go would be using getState and updateState methods defined in Parsec.Prim and to use the methods in Parsec.Pos to compare the difference in indendation for tokens. But I haven't completely wrapped my head around any state monad yet and I don't understand Parsec enough yet to see how to use the methods Parsec.Pos and state easily. Some examples or pointers to something to read would really be helpful. Thanks in advance, Bas van Gijzel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about implementing an off-side rule in Parsec 2
On Mon, Apr 27, 2009 at 2:41 PM, Bas van Gijzel neneko...@gmail.com wrote: Hello everyone, I'm doing a bachelor project focused on comparing parsers. One of the parser libraries I'm using is Parsec (2) and I'm going to implement a very small subset of haskell with it, with as most important feature the off-side rule (indentation based parsing) used in function definitions and possibly in where clauses. But I'm still a bit stuck on how to implement this cleanly. I tried to search for some examples on blogs but I haven't found anything yet. As far as I can see the way to go would be using getState and updateState methods defined in Parsec.Prim and to use the methods in Parsec.Pos to compare the difference in indendation for tokens. I've never tried to implement a whitespace sensitive parser like you'd need for Haskell or Python, but my thought was that maybe you use a stack and you push/pop from it when the indentation level changes. That way, I think you could isolate the part of the parser that handles changes in indentation from the rest. Maybe I haven't thought about this enough yet because I'm not sure what I would store on the stack. In some sense, you want the indentation level change to determine which production(s) of the grammar you are looking for. You might also use it to track scope so that you know the scope of the names in the program source. But I haven't completely wrapped my head around any state monad yet and I don't understand Parsec enough yet to see how to use the methods Parsec.Pos and state easily. Some examples or pointers to something to read would really be helpful. I'd start by playing with some toy examples in the State monad, then try implementing a State monad. Only look at the real implementation when you get stuck. Once you get State, then go back to Parsec which is more complex. This way you'll be in over your head less. Good luck, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] LAST CALL: Haskell Communities and Activities Report
Dear Haskellers, It is not yet too late to contribute to the May 2009 edition of the Haskell Communities and Activities Report. If you haven't already, please write an entry for your new project, or update your old entry. Please mail your entries to h...@haskell.org in LaTeX format. More information can be found in the original Call for Contributions at http://www.haskell.org/pipermail/haskell/2009-April/021180.html I look forward to receiving your contributions. Thanks a lot, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:vo...@tcs.inf.tu-dresden.de ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can subclass override its super-class' defaultimplementation of a function?
Basically, I have a bunch of instances that have a common functionality but I'd like to be able to group those instances and give each group a different default implementation of that functionality. It's so easy to do this in Java, for example, but I have no idea how to do it in Haskell. The above example will not compile, btw. Before going into language extensions, is there anything wrong with: class C a where foo :: a - Double fooA a = 5.0 --default A fooB a = 7.0 -- default B data Blah = Blah data Bar = Bar instance C Blah where foo = fooA instance C Bar where foo = fooB blah = Blah bar = Bar main = do print $ foo blah -- should print out 5 print $ foo bar -- should print out 7 It seems to match your spec. Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announce: GraphViz: Change of Maintainer
I no longer have the time to continue development of the (apparently, judging from the number of emails I'm getting, rather popular) graphviz package. Fortunately, Ivan Lazar Miljenovic who has extended it himself and sent me patches (some of which I did get round to folding in) has agreed to take on the package. Please direct all further queries to him! Many thanks Ivan! Matthew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] createProcess problem
Hello, I am trying to use createProcess. Following is a small fragment. I am trying to run a program called blastall (a bio-informatics program). It is kind of like mv/cp/ln on Unix platforms (where the executable examines the program, i.e. arg[0], and then provides appropriate behavior/semantics). In the case of blastall, it alters its behavior based on the -p(program) CLI argument.WSo in the following it should provide nucleotide behavior ... that is what the 'n' on the end of blastn means. import System.Process main = do handle - runProcess blastall -- executable [-p blastn] -- CLI args Nothing-- optional cwd Nothing-- optional env Nothing-- optional stdin Nothing-- optional stdout Nothing-- optional stderr return () When I run this program with ghci, blastall is not a happy camper. It is complaining about -p blastn: [NULL_Caption] ERROR: Program name undefined: blastn the space between the double quote and 'b' is really there!!! [NULL_Caption] ERROR: Program name undefined: blastn Yet if I run 'blastall -p blastn' from the DOS prompt no errors(I will try tonight on my Linux machine). If I try 'blastall -p bozo from the DOS prompt I get the same two errors as when I run my test program using ghci. I feel that it has something to do with double quotes in Haskell ... probably something obviously silly that I am doing. Any ideas? Kind regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can subclass override its super-class' default implementation of a function?
Quoth siki ga...@karamaan.com,
The actual problem is quite similar to the one that I provided or to the one
in the description of the proposed extension that you linked.
Someone on another forum suggested record functions but I'm not sure I
understood correctly how that would work around this problem. Any suggestion
is greatly appreciated!
Maybe it was function records. That's kind of the poor man's OOP in
Haskell - no typeclasses needed.
data FileRec = FileRec {
fileRecRead :: Int - IO String
, fileRecWrite :: String - IO ()
}
socketFileRec socket = {
fileRecWrite = \ s - send socket s 0
, fileRecRead = \ i - recv socket i 0
}
pipeFileRec p0 p1 = {
fileRecWrite = writeFd p1
, fileRecRead = readFd p0
}
echoBlock file count = (fileRecRead file) count = fileRecWrite file
Maybe you could use that, maybe you couldn't. That's why Martin suggested
that you reveal the actual problem. Not the solution you had in mind,
but the thing you're trying to solve.
Donn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] createProcess problem
Hello, I am trying to use createProcess. Following is a small fragment. I am trying to run a program called blastall (a bio-informatics program). It is kind of like mv/cp/ln on Unix platforms (where the executable examines the program, i.e. arg[0], and then provides appropriate behavior/semantics). In the case of blastall, it alters its behavior based on the -p(program) CLI argument.WSo in the following it should provide nucleotide behavior ... that is what the 'n' on the end of blastn means. import System.Process main = do handle - runProcess blastall -- executable [-p blastn] -- CLI args Nothing-- optional cwd Nothing-- optional env Nothing-- optional stdin Nothing-- optional stdout Nothing-- optional stderr return () When I run this program with ghci, blastall is not a happy camper. It is complaining about -p blastn: [NULL_Caption] ERROR: Program name undefined: blastn the space between the double quote and 'b' is really there!!! [NULL_Caption] ERROR: Program name undefined: blastn Yet if I run 'blastall -p blastn' from the DOS prompt no errors(I will try tonight on my Linux machine). If I try 'blastall -p bozo from the DOS prompt I get the same two errors as when I run my test program using ghci. I feel that it has something to do with double quotes in Haskell ... probably something obviously silly that I am doing. Any ideas? Kind regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess problem
Hi Vasili, Vasili I. Galchin wrote: [snip] import System.Process main = do handle - runProcess blastall -- executable [-p blastn] -- CLI args Try: [-p, blastn] This passes multiple command line arguments instead of just one that contains a space. Most shells use spaces to separate arguments. [snip] Hope this helps, Claude -- http://claudiusmaximus.goto10.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess problem
On Mon, Apr 27, 2009 at 06:00:52PM -0500, Vasili I. Galchin wrote: I feel that it has something to do with double quotes in Haskell ... probably something obviously silly that I am doing. The problem is that [-p blastn] means that there's only one argument, while [-p, blastn] means what you want. In a Unix shell, what you're doing is the same as 'blastn -p blastn', which is clearly wrong. Why are things like this? Well, imagine that you wanted to pass a file as argument, and that file had a space in its name. Having a list of arguments leaves you unconcerned about these subtleties. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about implementing an off-side rule in Parsec 2
I don't have experience solving this problem, but I've read a few horror stories from people who had state affect the results of parsing in Parsec. Haskell's layout rules replace indentation levels with braces and semicolons; you could run an initial tokenizing parser that builds tokens including the indentation level of each line, then convert those tokens into the appropriate braces and semicolons (via a pure function) before feeding the results into the real Haskell parser. -- ryan On Mon, Apr 27, 2009 at 2:41 PM, Bas van Gijzel neneko...@gmail.com wrote: Hello everyone, I'm doing a bachelor project focused on comparing parsers. One of the parser libraries I'm using is Parsec (2) and I'm going to implement a very small subset of haskell with it, with as most important feature the off-side rule (indentation based parsing) used in function definitions and possibly in where clauses. But I'm still a bit stuck on how to implement this cleanly. I tried to search for some examples on blogs but I haven't found anything yet. As far as I can see the way to go would be using getState and updateState methods defined in Parsec.Prim and to use the methods in Parsec.Pos to compare the difference in indendation for tokens. But I haven't completely wrapped my head around any state monad yet and I don't understand Parsec enough yet to see how to use the methods Parsec.Pos and state easily. Some examples or pointers to something to read would really be helpful. Thanks in advance, Bas van Gijzel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] createProcess problem
On Apr 27, 2009, at 18:55 , Vasili I. Galchin wrote: [-p blastn] -- CLI args createProcess expects a list of individual argument strings. You're sending it a single argument [-p blastn]; you want to send it two arguments [-p, blastn] (or [-pblastn] without the space; like most commands you can combine the parameter with the option or pass it as the next argument). The command line equivalent of what you're doing would be: blastall '- p blastn' -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with installing phooey
When I try to install Phooey I get the following error: cabal install --constraint=Stream == 0.3 phooey Resolving dependencies... [1 of 1] Compiling Main ( /tmp/phooey-2.016943/phooey-2.0/Setup.lhs, /tmp/phooey-2.016943/phooey-2.0/dist/setup/Main.o ) Linking /tmp/phooey-2.016943/phooey-2.0/dist/setup/setup ... Configuring phooey-2.0... Warning: No 'build-type' specified. If you do not need a custom Setup.hs or ./configure script then use 'build-type: Simple'. Preprocessing library phooey-2.0... Building phooey-2.0... src/Graphics/UI/Phooey/WinEvents.hs:66:7: Could not find module `Data.Reactive': Use -v to see a list of the files searched for. It seems that the current version of reactive (0.10.5) no longer has Data.Reactive module (it seem to have been removed since 0.5 version of the reactive). Does Phooey really need 0.5 version of the reactive or is there a problem in my installation? Thanks Daryoush ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] LondonHUG talk: Engineering Large Projects in Haskell
Slides from last week's London HUG http://www.londonhug.net/ talk are now online. The talk attempts to document some of the tips and tricks Galois has accumulated using Haskell commercially for the past 10 years. You can now read the slides of the talk here: http://www.galois.com/blog/2009/04/27/engineering-large-projects-in-haskell-a-decade-of-fp-at-galois/ Cheers, Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
