Re: [GHC] #3226: please eliminate error message from Make on every build
#3226: please eliminate error message from Make on every build
-+--
Reporter: nr|Owner:
Type: feature request | Status: new
Priority: normal|Milestone:
Component: Build System | Version: 6.11
Severity: trivial | Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by simonpj):
Try
{{{
make 1
}}}
http://hackage.haskell.org/trac/ghc/wiki/Building/Using#RebuildingtheGHCbinaryaftermakingchanges
Does that do it? If the above documentation isn't clear enough, or isn't
easy enough to find, could you modify it so that it is? It's a wiki.
Thanks.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3226#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] #3223: please detect multiple kind errors in one run
#3223: please detect multiple kind errors in one run -+-- Reporter: nr|Owner: Type: feature request | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.10.1 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonpj): But the first comment (as opposed to the initial report) confirmed that the bug is present in 6.10.1. That's what's puzzling me. I don't want to lose a good bug! Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3223#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] #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets
#2927: Bug in network library, uncaught exception when dealing with ipv6 sockets --+- Reporter: tphyahoo |Owner: bos Type: bug| Status: closed Priority: normal |Milestone: Not GHC Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: ipv6 | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --+- Changes (by tibbe): * status: assigned = closed * resolution: = invalid Comment: Moved to http://trac.haskell.org/network/ticket/11 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2927#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] #2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6
#2391: Network.listenOn (PortNumber n) Sometimes Picks IPv6 --+- Reporter: cjs|Owner: bos Type: bug| Status: closed Priority: normal |Milestone: Not GHC Component: libraries/network | Version: 6.8.3 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --+- Changes (by tibbe): * status: assigned = closed * resolution: = invalid Comment: Moved to http://trac.haskell.org/network/ticket/11 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2391#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] #2927: Bug in network library, uncaught exception when dealing with ipv6 sockets
#2927: Bug in network library, uncaught exception when dealing with ipv6 sockets --+- Reporter: tphyahoo |Owner: bos Type: bug| Status: closed Priority: normal |Milestone: Not GHC Component: libraries/network | Version: 6.10.1 Severity: normal | Resolution: invalid Keywords: ipv6 | Difficulty: Unknown Testcase: | Os: Unknown/Multiple Architecture: Unknown/Multiple | --+- Comment (by tibbe): Correction, moved to http://trac.haskell.org/network/ticket/12 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2927#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: [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 as sure as I can be that I'm not leaking handles. I've gone through their bug reports, and I think their issue was their fault (not releasing resources), but mine is the fault of some combination of Cygwin/Mingw/GHC/Windows. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2924#comment:8 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've also seen problems similar to this on Linux, so it's possible the bug is actually cross platform. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2924#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
[GHC] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile
-+--
Reporter: NeilMitchell | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 6.10.2| Severity: normal
Keywords:| Testcase:
Os: Windows | Architecture: Unknown/Multiple
-+--
Given this program:
{{{
module Main() where
import Control.Concurrent
import System.IO
import System.Process
main = do
hSetBuffering stdout NoBuffering
forkIO $ f foo1.txt
forkIO $ f foo2.txt
threadDelay $ 100*100
putStrLn Finished successfully
f file = do
h - openFile file AppendMode
hPutStrLn h fakdjsklj
putChar '.'
pid - runProcess sh [-c,sleep 0.1s] Nothing Nothing Nothing
(Just h) (Just h)
waitForProcess pid
f file
}}}
Running under Cygwin, in GHC 6.10.2, I get:
{{{
$ runhaskell Test.hs
..Test.hs: foo1.txt: openFile: permission denied (Permission denied)
}}}
It shouldn't - the {{{openFile}}} calls should always succeed. This bug is
a reduced test case from a real system, which I papered over with:
{{{
retryIO :: IO a - IO a
retryIO act = catchIO act $ \x - do
threadDelay $ 1 * 100 -- 1 second
performGC
act
}}}
Now calling {{{retryIO $ openFile ...}}} works reliably. These problems
are occurring sufficiently often that {{{retryIO}}} is about to go in to
our standard library :-)
This may be related to #2924, but has the advantage of replicating easily.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231
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] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile --+- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.10.2 Severity: normal| Resolution: Keywords:| Testcase: Os: Windows | Architecture: Unknown/Multiple --+- Changes (by NeilMitchell): * cc: ndmitch...@gmail.com (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#comment:1 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] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile --+- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.10.2 Severity: normal| Resolution: Keywords:| Testcase: Os: Windows | Architecture: Unknown/Multiple --+- Comment (by NeilMitchell): I have just tested, and this bug does not occur under Linux. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#comment:2 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] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile
--+-
Reporter: NeilMitchell | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Testcase:
Os: Windows | Architecture: Unknown/Multiple
--+-
Comment (by NeilMitchell):
Another version, this time not tying the process to a handle:
{{{
module Main() where
import Control.Concurrent
import System.IO
import System.Cmd
import System.Directory
main = do
hSetBuffering stdout NoBuffering
forkIO $ f foo1.txt
forkIO $ f foo2.txt
threadDelay $ 100*100
putStrLn Finished successfully
f file = do
h - openFile file WriteMode
hPutStrLn h fjkladsf
system sleep 1s
putChar '.'
hClose h
removeFile file
f file
}}}
This version fails under both Cygwin and from the Windows command prompt
with:
{{{
$ runhaskell Test.hs
.Test.hs: DeleteFile: permission denied (The process cannot access the
file beca
use it is being used by another process.)
}}}
This version works fine if the {{{system}}} call is removed. That call
shouldn't have any difference to the usage of any handles. It seems that
system calls mess with handles and resources in painful ways. This is now
almost certainly the same underlying cause as the problems I reported in
bug #2924.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#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] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile
--+-
Reporter: NeilMitchell | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Testcase:
Os: Windows | Architecture: Unknown/Multiple
--+-
Comment (by NeilMitchell):
The {{{removeFile}}} call is actually redundant. Without it I get:
{{{
$ runhaskell Test.hs
.Test.hs: foo1.txt: openFile: permission denied (Permission denied)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#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] #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):
See also #3231. Most likely my reports relate to that bug, and there is a
separate issue with the {{{createDirectory}}} call, as replicated above.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2924#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] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile
--+-
Reporter: NeilMitchell | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Testcase:
Os: Windows | Architecture: Unknown/Multiple
--+-
Comment (by duncan):
Replying to [comment:3 NeilMitchell]:
This version works fine if the {{{system}}} call is removed. That call
shouldn't have any difference to the usage of any handles. It seems that
system calls mess with handles and resources in painful ways. This is now
almost certainly the same underlying cause as the problems I reported in
bug #2924.
Presumably it is the system call that is crucial. Delaying by one second
in Haskell code presumably works ok?
If so, my guess is that it's related to the open file handles being
inherited by the child process and then the use of the handle in the child
conflicts with attempts to remove or re-open the same file in the parent.
Of course we wait for the child process to terminate so in principle this
should not be a problem, the handles used in the child process should now
be closed. However I have a strong suspicion that Windows is using delayed
deallocation/unlocking of handles when a process terminates.
I've seen behaviour in cabal-install where we wait for a program to
terminate, which had an open file in the directory we're about to delete,
and when we try to remove the file we often get a permission error.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#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] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile --+- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.10.2 Severity: normal| Resolution: Keywords:| Testcase: Os: Windows | Architecture: Unknown/Multiple --+- Comment (by NeilMitchell): Yes, the system call is crucial - a similar threadDelay has no problems. I only used sleep because it's a simple process that was available, I have no reason to think it's the delay causing a problem. In the sleep example, the child process isn't actually using the open file handle - it was in the original example but that turned out to be irrelevant. BTW, this error is pretty severe for certain users - threads+windows+files+system is a combination that crops up everywhere when using Haskell as a powerful scripting language. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#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] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile --+- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.10.2 Severity: normal| Resolution: Keywords:| Testcase: Os: Windows | Architecture: Unknown/Multiple --+- Comment (by duncan): Replying to [comment:6 NeilMitchell]: In the sleep example, the child process isn't actually using the open file handle - it was in the original example but that turned out to be irrelevant. It doesn't matter if it uses it or not. If the handle is set to be inheritable then all child processes will get it and hold it open. So there are apparently two problems: * waiting for a process to terminate does not appear to be enough to ensure that handles it had open are now closed. * `openFile` appears to create handles that are inheritable. The default should almost certainly be non-inheritable (we have similar issues on unix but they're less severe because unix lacks strong file locking). I suggest that both of these need confirming or refuting. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#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: [GHC] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile
--+-
Reporter: NeilMitchell | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
Component: Compiler |Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Testcase:
Os: Windows | Architecture: Unknown/Multiple
--+-
Comment (by claus):
Thanks for bringing this from rumour to concrete code. Sounded like a good
example to try out ProcessExplorer on!-) I tried the following variation,
to give me some control and time to see the open handles:
{{{
module Main() where
import Control.Concurrent
import System.IO
import System.Directory
import System.Process
import Control.Exception(bracket)
my_system str = do
(_,_,_,p) - createProcess c
waitForProcess p
where c = CreateProcess { cmdspec = ShellCommand str,
cwd = Nothing,
env = Nothing,
std_in = Inherit,
std_out = Inherit,
std_err = Inherit,
close_fds = True }
main = do
v - newEmptyMVar
hSetBuffering stdout NoBuffering
forkIO $ f v foo1.txt
forkIO $ f v foo2.txt
threadDelay $ 100*100
putStrLn Finished successfully
f v file = do
bracket (openFile file WriteMode)
(hClose)
(\h-do hPutStrLn h file
hPutStr stderr (++file++ )
my_system sleep 5s
)
-- takeMVar v
hPutStr stderr (++file++ )
my_system sleep 5s
removeFile file
f v file
}}}
It seems that no matter what I set `close_fds` to (default `False`?), both
GHC and one of its two children sometimes hang on to both files, while the
other child hangs on to `foo1` only?? Also, there is occasionally a new
pair of children, before the old pair is gone (this tends to preceed the
access error). Are these just ProcessExplorer sampling artifacts, am I
misreading the data, or is there something else going on (ghc
6.11.20090320)?
Btw, after Duncan's remark, I looked up [http://msdn.microsoft.com/en-
us/library/aa363915(VS.85).aspx DeleteFile] and found these two -seemingly
contradictory- remarks:
The DeleteFile function fails if an application attempts to delete a file
that is open for normal I/O or as a memory-mapped file.
The DeleteFile function marks a file for deletion on close. Therefore,
the file deletion does not occur until the last handle to the file is
closed. Subsequent calls to CreateFile to open the file fail with
ERROR_ACCESS_DENIED.
Could anyone please explain what that second remark means, given the
first? What is the non-normal I/O it seems to apply to?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#comment:8
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] #3207: readMutVar# is inlined/duplicated
#3207: readMutVar# is inlined/duplicated -+-- Reporter: simonmar |Owner: simonmar Type: bug | Status: new Priority: normal|Milestone: 6.12.1 Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = simonmar -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3207#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] #3217: Make GHCi have separate flags for interactive Haskell expressions
#3217: Make GHCi have separate flags for interactive Haskell expressions -+-- Reporter: simonpj |Owner: Type: feature request | Status: new Priority: normal|Milestone: 6.12 branch Component: Compiler | Version: 6.10.2 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonmar): Replying to [comment:7 claus]: Thanks. I think I could live with only one `*`-ed module, if that was necessary to get this consistency, but there's no telling what wonderful uses other GHCi users have come up with, or what their preferences are.. So permitting multiple `*`-ed modules sounds safer - just adding the requirement that they have to be compatible. Can you precisely define compatibility? Can you imagine implementing (or even describing) it in a simple way? (I can't) I have to admit, this sounds way overkill to me. If this is really a necessary feature, can you describe a compelling use case? One that doesn't have an easy workaround? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3217#comment:8 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
[GHC] #3232: Remove registerised -fvia-C
#3232: Remove registerised -fvia-C ---+ Reporter: igloo | Owner: Type: task | Status: new Priority: high | Milestone: 6.12.1 Component: Compiler |Version: 6.11 Severity: normal| Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ Remove registerised `-fvia-C`. The following should be looked at before doing so: * x86 floating point performance is bad with `-fasm` -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3232 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] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile --+- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.10.2 Severity: normal| Resolution: Keywords:| Testcase: Os: Windows | Architecture: Unknown/Multiple --+- Comment (by Deewiant): This appears to be a duplicate of #2650? I have some partial fixes for the issue there. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#comment:11 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] #2650: Child processes always unwantedly inherit Handles on Windows
#2650: Child processes always unwantedly inherit Handles on Windows --+- Reporter: Deewiant |Owner: simonmar Type: bug| Status: new Priority: high |Milestone: 6.12.1 Component: libraries (other) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | --+- Changes (by NeilMitchell): * cc: ndmitch...@gmail.com (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2650#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] #2058: Ghci tab-completion cannot handle Unicode
#2058: Ghci tab-completion cannot handle Unicode -+-- Reporter: desegnis |Owner: Type: bug | Status: closed Priority: normal|Milestone: 6.12.1 Component: GHCi | Version: 6.9 Severity: normal| Resolution: duplicate Keywords:| Difficulty: Unknown Testcase:| Os: Linux Architecture: Unknown/Multiple | -+-- Changes (by cmcq): * status: new = closed * resolution: = duplicate Comment: See #2812. Those Unicode examples work for me in 6.10.3. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2058#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] #3026: GHCi segfault
#3026: GHCi segfault ---+ Reporter: porges |Owner: Type: bug | Status: closed Priority: normal |Milestone: 6.12.1 Component: GHCi| Version: 6.10.1 Severity: major | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---+ Changes (by cmcq): * status: new = closed * resolution: = duplicate Comment: See #2812. I don't get a segfault in 6.10.3. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3026#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] #3157: ghci segmentation fault when computation is interrupted
#3157: ghci segmentation fault when computation is interrupted ---+ Reporter: fft1976 |Owner: Type: bug | Status: closed Priority: normal |Milestone: 6.10 branch Component: Runtime System | Version: 6.10.2 Severity: critical| Resolution: duplicate Keywords: ghci| Difficulty: Unknown Testcase: | Os: Linux Architecture: x86 | ---+ Changes (by cmcq): * status: new = closed * resolution: = duplicate Comment: See #2812. I don't get a segfault in 6.10.3. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3157#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
[GHC] #3233: Cleaning on Windows currently fails
#3233: Cleaning on Windows currently fails
---+
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: high | Milestone: 6.12.1
Component: Build System |Version: 6.11
Severity: normal| Keywords:
Difficulty: Unknown | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
---+
Cleaning on Windows currently fails, due to this:
{{{
$ cat Makefile
bar/baz/%.hc : bar/baz/%.hs
echo wibble
foo:
rm -rf bar
$ mkdir -p bar/baz
$ make foo
rm -rf bar
rm: cannot remove directory `bar': Directory not empty
make: *** [foo] Error 1
$
}}}
To work around the problem, we can not load all of the make rules when the
target is `clean` (or `maintainer-clean` or `distclean`).
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3233
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] #3230: Build fails with cabal-bin complaining
#3230: Build fails with cabal-bin complaining --+- Reporter: guest | Owner: Type: bug | Status: new Priority: normal| Milestone: Component: Build System |Version: 6.10.3 Severity: normal| Resolution: Keywords:| Testcase: Os: Linux | Architecture: x86_64 (amd64) --+- Comment (by guest): ghc-6.8.3 builds fine, and 6.10.3 builds from it, so maybe this is just a matter of changing the comments at http://www.haskell.org/ghc/download_ghc_6_10_3.html (and related pages) to say it requires version 6.8 instead of 6.6 to compile? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3230#comment:1 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] #3128: hClose leaves file descriptor open if it fails
#3128: hClose leaves file descriptor open if it fails -+-- Reporter: Baughn|Owner: simonmar Type: bug | Status: new Priority: normal|Milestone: 6.12.1 Component: libraries/base| Version: 6.10.1 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by Baughn): Ah. Of course; my invocations of hClose were failing anyway, so it probably just never got that far, and I didn't see the code. Say, about that rewrite - is the API going to be the same as the current one? If not, is there any way I could have a look? I really need a functional network library for my thesis, but at the moment I was resigning myself to writing my own based on the C functions when I get started, in a few weeks' time. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3128#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] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile
-+--
Reporter: NeilMitchell |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Runtime System| Version: 6.10.2
Severity: major | Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Windows
Architecture: Unknown/Multiple |
-+--
Comment (by claus):
This appears to be a duplicate of #2650? I have some partial fixes for
the issue there.
So the fix to add `_O_NOINHERIT` when opening files could be applied,
but I'm not sure whether it will have any undesirable consequences.
Anyone?
If there is no way to implement the `close_fds` parameter to
`createProcess` properly on Windows, that should at least be mentioned in
the documentation! Since the parameter is there, I'd prefer to have it
implemented, rather than ignored, though.
Anyway, that means we can simplify the example, right?
{{{
module Main() where
import Control.Concurrent
import System.IO
import System.Process
my_system str = do
(_,_,_,p) - createProcess c
waitForProcess p
where c = CreateProcess { cmdspec = ShellCommand str,
cwd = Nothing,
env = Nothing,
std_in = Inherit,
std_out = Inherit,
std_err = Inherit,
close_fds = True } -- close_fds is ignored on
windows!-(
main = do
va - newEmptyMVar
vb - newEmptyMVar
forkIO $ p va vb foo1.txt
takeMVar va
forkIO $ my_system sleep 60s return ()
putMVar vb ()
putStrLn Finished
p va vb file = do
h - openFile file WriteMode
putMVar va ()
takeMVar vb
hClose h
h - openFile file WriteMode
putStrLn Success?
hClose h
}}}
Seems to fail quite reliably here, while it works when the system call is
commented out.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#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] #3230: Build fails with cabal-bin complaining
#3230: Build fails with cabal-bin complaining
---+
Reporter: guest |Owner:
Type: bug | Status: closed
Priority: normal |Milestone:
Component: Build System| Version: 6.10.3
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: | Os: Linux
Architecture: x86_64 (amd64) |
---+
Changes (by igloo):
* status: new = closed
* difficulty: = Unknown
* resolution: = fixed
Comment:
Thanks for the report.
There are actually earlier failures than that, e.g.:
{{{
/usr/bin/ghc -package-conf
/tmp/zi/ghc/ghc-6.10.3/libraries/bootstrapping.conf --make Setup -package
Cabal-1.6.0.3 -o Setup
Setup.hs:16:7:
Could not find module `System.FilePath':
it was found in multiple packages: filepath-1.1.0.2 FilePath-0.11
}}}
GHC 6.6 doesn't come with `FilePath`, so it looks like you have installed
it, and that has confused the build system. The build should work with a
vanilla GHC 6.6 installation.
The real bug here is that the build should have stopped after the first
failure. However, given this is all done differently in the new build
system in the HEAD, I'm going to close this ticket.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3230#comment:2
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] #2650: Child processes always unwantedly inherit Handles on Windows
#2650: Child processes always unwantedly inherit Handles on Windows --+- Reporter: Deewiant |Owner: simonmar Type: bug| Status: new Priority: high |Milestone: 6.12.1 Component: libraries (other) | Version: 6.9 Severity: major | Resolution: Keywords: | Difficulty: Unknown Testcase: | Os: Windows Architecture: Unknown/Multiple | --+- Comment (by duncan): So according to the [http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6428742 JVM bug report] we can make `CreateProcess.close_fds` work except when also trying to redirect stdin/out. Currently we do not attempt to make it work at all. And on Vista we can make it work even when redirect stdin/out. So it seems like we both need to make new handles (eg from opening files and sockets) non-inheritable and implement the above tricks. This all looks quite doable but will need some careful testing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2650#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: [GHC] #3231: Permission denied error with runProcess/openFile
#3231: Permission denied error with runProcess/openFile -+-- Reporter: NeilMitchell |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Runtime System| Version: 6.10.2 Severity: major | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Windows Architecture: Unknown/Multiple | -+-- Comment (by duncan): Replying to [comment:14 claus]: If there is no way to implement the `close_fds` parameter to `createProcess` properly on Windows, that should at least be mentioned in the documentation! Since the parameter is there, I'd prefer to have it implemented, rather than ignored, though. There is a way on XP at least for the case where you're not setting stdin/out. On Vista it looks like it can be made to work in all cases. See #2650. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#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] #3217: Make GHCi have separate flags for interactive Haskell expressions
#3217: Make GHCi have separate flags for interactive Haskell expressions
-+--
Reporter: simonpj |Owner:
Type: feature request | Status: new
Priority: normal|Milestone: 6.12 branch
Component: Compiler | Version: 6.10.2
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by claus):
Can you precisely define compatibility? Can you imagine implementing
(or even describing) it in a simple way?
Sure - the same way it is defined currently, in a single file!-) Actually,
defining and implementing this would be good in any case, as there
currently are a few oddities..:
- no multiple `default` permitted (as in a single file; this could be
relaxed to permitting *identical* `default`s)
- no `{-# LANGUAGE X, NoX #-}` (actually, that is currently permitted,
but I consider it an oversight/bug..)
- no `{-# OPTIONS_GHC -fthis, -fno-this #-}` (again, that is currently
permitted..)
If there are any non-obvious cases, simply require that all modules must
have the same, identical options for those. In general, proceed as if all
`*`-ed modules were in a single file, with allowances for identical
duplicates.
My intention here is that explicit settings have priority over implicit
ones (if one module doesn't have an explicit `default`, another does, then
the combination has the explicitly given `default`). This merging of
explicit settings might lead to a module not being loadable with the
merged settings, but this isn't different from that module depending on
specific settings, which should be made explicit.
An alternative would be to require identical settings in all modules to be
loaded in a `*` combination. This would be easier to check, but almost as
cumbersome as permitting only a single `*`-ed module.
If this is really a necessary feature, can you describe a compelling use
case? One that doesn't have an easy workaround?
As I mentioned, a single `*`-ed module would seem to work for me. It is
just that I've often been annoyed if people who couldn't imagine a use
case decided that there were no use cases, so I didn't want to fall into
the same trap. I don't know how many folks still read ghc-bugs, or the
trac RSS feeds, so perhaps raise the issue on ghc-users, and point to this
ticket?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3217#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] #3226: please eliminate error message from Make on every build
#3226: please eliminate error message from Make on every build
-+--
Reporter: nr|Owner:
Type: feature request | Status: new
Priority: normal|Milestone:
Component: Build System | Version: 6.11
Severity: trivial | Resolution:
Keywords:| Difficulty: Unknown
Testcase:| Os: Unknown/Multiple
Architecture: Unknown/Multiple |
-+--
Comment (by nr):
I'm afraid
{{{
make 1
}}}
suffers from the same problem:
{{{
: n...@labrador 3648 [branch=norman] ; make 1
make -C .. stage=1 all_ghc_stage1 compiler_stage1_NO_BUILD_DEPS=YES
make[1]: Entering directory `/usr/local/nr/git/ghc/experimental'
===--- updating makefiles phase 0
make -r --no-print-directory -f ghc.mk phase=0 just-makefiles
===--- updating makefiles phase 1
make -r --no-print-directory -f ghc.mk phase=1 just-makefiles
===--- updating makefiles phase 2
make -r --no-print-directory -f ghc.mk phase=2 just-makefiles
===--- updating makefiles phase 3
make -r --no-print-directory -f ghc.mk phase=3 just-makefiles
ghc/ghc.mk:90: ghc/stage1/build/.depend: No such file or directory
/usr/bin/ghc -H64m -O0 -fasm -package-conf libraries/bootstrapping.conf
-package-name ghc-6.11.20090513 -hide-all-packages -i -icompiler/nativeGen
-icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn
-icompiler/cprAnalysis -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn
-icompiler/iface -icompiler/main -icompiler/parser -icompiler/prelude
-icompiler/profiling -icompiler/rename -icompiler/simplCore
-icompiler/simplStg -icompiler/specialise -icompiler/stgSyn
-icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils
-icompiler/vectorise -icompiler/stage1/build
-icompiler/stage1/build/autogen -Icompiler/stage1/build
-Icompiler/stage1/build/autogen -Icompiler/stage1
-Icompiler/../libraries/base/cbits -Icompiler/../libraries/base/include
-Icompiler/. -Icompiler/parser -Icompiler/utils -optP-include
-optPcompiler/stage1/build/autogen/cabal_macros.h -package Cabal-1.7.0
-package array-0.2.0.0 -package base-4.0.0.0 -package bytestring-0.9.1.4
-package containers-0.2.0.0 -package directory-1.0.0.2 -package
filepath-1.1.0.1 -package haskell98-1.0.1.0 -package hpc-0.5.0.2 -package
old-time-1.0.0.1 -package process-1.0.1.0 -package unix-2.3.1.0 -#include
cutils.h -DSTAGE=1 -O -fasm -Wall -fno-warn-name-shadowing -fno-warn-
orphans -XCPP -XMagicHash -XUnboxedTuples -XPatternGuards
-XForeignFunctionInterface -XEmptyDataDecls -XTypeSynonymInstances
-XMultiParamTypeClasses -XFlexibleInstances -XRank2Types
-XScopedTypeVariables -XDeriveDataTypeable -XRelaxedPolyRec-odir
compiler/stage1/build -hidir compiler/stage1/build -stubdir
compiler/stage1/build -hisuf hi -osuf o -hcsuf hc -c
compiler/codeGen/StgCmmProf.hs -o compiler/stage1/build/StgCmmProf.o
compiler/codeGen/StgCmmProf.hs:350:41:
`CmmAGraph' is not applied to enough type arguments
Expected kind `*', but `CmmAGraph' has kind `* - * - *'
In the type `FCode CmmAGraph'
In the type `CollectedCCs - FCode CmmAGraph'
In the type signature for `initCostCentres':
initCostCentres :: CollectedCCs - FCode CmmAGraph
compiler/codeGen/StgCmmProf.hs:417:30:
`CmmAGraph' is not applied to enough type arguments
Expected kind `?', but `CmmAGraph' has kind `* - * - *'
In the type `CostCentre - CmmAGraph'
In the type signature for `mkRegisterCC':
mkRegisterCC :: CostCentre - CmmAGraph
compiler/codeGen/StgCmmProf.hs:435:36:
`CmmAGraph' is not applied to enough type arguments
Expected kind `?', but `CmmAGraph' has kind `* - * - *'
In the type `CostCentreStack - CmmAGraph'
In the type signature for `mkRegisterCCS':
mkRegisterCCS :: CostCentreStack - CmmAGraph
compiler/codeGen/StgCmmProf.hs:479:27:
`CmmAGraph' is not applied to enough type arguments
Expected kind `?', but `CmmAGraph' has kind `* - * - *'
In the type `CmmExpr - CmmAGraph'
In the type signature for `bumpSccCount':
bumpSccCount :: CmmExpr - CmmAGraph
make[2]: *** [compiler/stage1/build/StgCmmProf.o] Error 1
make[1]: *** [all_ghc_stage1] Error 2
make[1]: Leaving directory `/usr/local/nr/git/ghc/experimental'
make: *** [1] Error 2
}}}
I may have a go at the doco once I understand a little better what's going
on.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3226#comment:5
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
[GHC] #3234: foldr/single no longer firing in GHC 6.10
#3234: foldr/single no longer firing in GHC 6.10
-+--
Reporter: r6| Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 6.10.3| Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
consider the following module
{{{module Foo where x = ['x']++haskell}}}
when {{{ghc --make -O2 Foo.hs -ddump-simpl-stats}}} is run using GHC
6.8.2, the output show that the foldr/single rule is fired
{{{
5 RuleFired
1 ++
1 augment/build
1 foldr/single
1 unpack
1 unpack-list
}}}
However, I am told that this does not happen in GHC 6.10.2 nor GHC 6.10.3
where foldr/app is fired instead
{{{
6 RuleFired
1 ++
1 augment/build
1 fold/build
1 foldr/app
1 unpack
1 unpack-list
}}}
Thus it appears that the above module is no longer properly optimized in
GHC 6.10
(thanks to dons and Jedai for helping with this)
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3234
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
comprehension vs `map'
Dear GHC team,
I would like to write
[rl {ruleMode = AlwaysApply} | rl - rules calc](I)
instead of map (\ rl - rl {ruleMode = AlwaysApply}) $ rules calc (II)
and instead of
let rs = rules calc in [rl {ruleMode = AlwaysApply} | rl - rs] (III).
But is this reliable in GHC that the compiler converts (I) into something
which is not not worse than III ?
What about other implementations?
Regards,
---
Mechveliani
mech...@botik.ru
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Re: ANNOUNCE: GHC version 6.10.3
On 15/05/2009 05:52, Benjamin L.Russell wrote: What happened to the Windows installation section in the corresponding User's Guide? The User's Guide for GHC version 6.10.2 (see http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/index.html) had section 2.2: Installing on Windows (see http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/install-windows.html#winfaq), but this section seems to be missing in the corresponding document for version 6.10.3 (see http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html). Not only that, but the entire chapter 2: Installing GHC seems to be missing. The Installing GHC section was mostly out-of-date and wrong, so I removed it. Some of the material, such as the section on the layout of the tree, has been updated and moved to the GHC Building Guide, here http://hackage.haskell.org/trac/ghc/wiki/Building We also have lots of information on the GHC web site about obtaining and installing GHC, so if we need anything else I think that would be the best place to put it. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: comprehension vs `map'
should generate the same code!
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Serge D. Mechveliani
| Sent: 15 May 2009 09:00
| To: glasgow-haskell-users@haskell.org
| Subject: comprehension vs `map'
|
| Dear GHC team,
|
| I would like to write
| [rl {ruleMode = AlwaysApply} | rl - rules calc](I)
|
| instead of map (\ rl - rl {ruleMode = AlwaysApply}) $ rules calc (II)
| and instead of
| let rs = rules calc in [rl {ruleMode = AlwaysApply} | rl - rs] (III).
|
| But is this reliable in GHC that the compiler converts (I) into something
| which is not not worse than III ?
| What about other implementations?
|
| Regards,
|
| ---
| Mechveliani
| mech...@botik.ru
|
|
| ___
| 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
Re: [Haskell] Re: ANNOUNCE: GHC version 6.10.3
On Fri, 15 May 2009 09:16:13 +0100, Simon Marlow marlo...@gmail.com wrote: On 15/05/2009 05:52, Benjamin L.Russell wrote: What happened to the Windows installation section in the corresponding User's Guide? The User's Guide for GHC version 6.10.2 (see http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/index.html) had section 2.2: Installing on Windows (see http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/install-windows.html#winfaq), but this section seems to be missing in the corresponding document for version 6.10.3 (see http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html). Not only that, but the entire chapter 2: Installing GHC seems to be missing. The Installing GHC section was mostly out-of-date and wrong, so I removed it. Some of the material, such as the section on the layout of the tree, has been updated and moved to the GHC Building Guide, here http://hackage.haskell.org/trac/ghc/wiki/Building We also have lots of information on the GHC web site about obtaining and installing GHC, so if we need anything else I think that would be the best place to put it. Ah, I see. I just checked out that section, but although it includes information about building GHC, it doesn't seem to include information about simply installing GHC using a binary. This could become an issue if a new user unfamiliar with the installation suddenly decides to upgrade; it is unclear without that documentation whether it is necessary to uninstall the previous version first. More specifically, section 2.2.2 Moving GHC Around indicates that the entire GHC tree can be freely moved around just by copying the c:/ghc/ghc-version directory (although it is necessary to fix up the links in 'Start/All Programs/GHC/ghc-version' if this is done); however, this information is not evident from the information provided by the Windows installer. This information initially led me to conclude that uninstalling the previous version wasn't necessary to upgrade; without this information, a new user may not be able to determine whether uninstalling a previous version is necessary to upgrade, and could make upgrading more confusing. -- 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^ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--out-implib when linking shared libraries
Hi, I've just built a Haskell dll on Windows. As part of the process it generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags passed to ld I see --out-implib=foo.dll.a. What is the purpose of the .a file? What might it be needed for? Is it possible to suppress it? I could easily be building 100 of these things and 4Gb of disk for unused files is a little painful. Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: --out-implib when linking shared libraries
On Fri, 2009-05-15 at 15:31 +0100, Neil Mitchell wrote: Hi, I've just built a Haskell dll on Windows. As part of the process it generated an 14Mb foo.dll, and a 40Mb foo.dll.a. Looking at the flags passed to ld I see --out-implib=foo.dll.a. What is the purpose of the .a file? What might it be needed for? Is it possible to suppress it? I'm less familiar with the windows dlls as I've been working on the unix case first, but as I understand it, .lib files serve a dual purpose as static libs and as import libs for corresponding dlls. To add confusion the windows gnu tools use the .dll.a extension rather than .lib which the MS tools use. It looks like what you're getting is an import lib that also contains a full copy of all the code. I think it's possible to have minimal .lib files that do not contain any code and only refer to the corresponding dll. Further, I think recent gnu ld versions can link directly against dlls without using an import lib (though you may still need the import lib if you want to use MSVC to link to your dll). So my suggestion is remove it, if you're linking using gcc it should work. See also: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/win32.html Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell] Re: ANNOUNCE: GHC version 6.10.3
On 15/05/2009 05:52, Benjamin L.Russell wrote: What happened to the Windows installation section in the corresponding User's Guide? The User's Guide for GHC version 6.10.2 (see http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/index.html) had section 2.2: Installing on Windows (see http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/install-windows.html#winfaq), but this section seems to be missing in the corresponding document for version 6.10.3 (see http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html). Not only that, but the entire chapter 2: Installing GHC seems to be missing. The Installing GHC section was mostly out-of-date and wrong, so I removed it. Some of the material, such as the section on the layout of the tree, has been updated and moved to the GHC Building Guide, here http://hackage.haskell.org/trac/ghc/wiki/Building We also have lots of information on the GHC web site about obtaining and installing GHC, so if we need anything else I think that would be the best place to put it. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANNOUNCE: GHC version 6.10.3
On Fri, 15 May 2009 09:16:13 +0100, Simon Marlow marlo...@gmail.com wrote: On 15/05/2009 05:52, Benjamin L.Russell wrote: What happened to the Windows installation section in the corresponding User's Guide? The User's Guide for GHC version 6.10.2 (see http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/index.html) had section 2.2: Installing on Windows (see http://www.haskell.org/ghc/docs/6.10.2/html/users_guide/install-windows.html#winfaq), but this section seems to be missing in the corresponding document for version 6.10.3 (see http://www.haskell.org/ghc/docs/latest/html/users_guide/index.html). Not only that, but the entire chapter 2: Installing GHC seems to be missing. The Installing GHC section was mostly out-of-date and wrong, so I removed it. Some of the material, such as the section on the layout of the tree, has been updated and moved to the GHC Building Guide, here http://hackage.haskell.org/trac/ghc/wiki/Building We also have lots of information on the GHC web site about obtaining and installing GHC, so if we need anything else I think that would be the best place to put it. Ah, I see. I just checked out that section, but although it includes information about building GHC, it doesn't seem to include information about simply installing GHC using a binary. This could become an issue if a new user unfamiliar with the installation suddenly decides to upgrade; it is unclear without that documentation whether it is necessary to uninstall the previous version first. More specifically, section 2.2.2 Moving GHC Around indicates that the entire GHC tree can be freely moved around just by copying the c:/ghc/ghc-version directory (although it is necessary to fix up the links in 'Start/All Programs/GHC/ghc-version' if this is done); however, this information is not evident from the information provided by the Windows installer. This information initially led me to conclude that uninstalling the previous version wasn't necessary to upgrade; without this information, a new user may not be able to determine whether uninstalling a previous version is necessary to upgrade, and could make upgrading more confusing. -- 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
[Haskell] ICFP09 Accepted Papers
Accepted Papers ICFP 2009: International Conference on Functional Programming Edinburgh, Scotland, 31 August - 2 September 2009 http://www.cs.nott.ac.uk/~gmh/icfp09.html The ICFP 2009 Program Chair and Committee are pleased to announce that the following papers have been accepted for the conference. Additional information regarding the final program, invited speakers, and registration will be forthcoming. However, the Local Arrangements Co-Chairs would like to remind participants of the following: * ICFP'09 coincides with the final week of the Edinburgh International Festival, one of the premier arts and cultural festivals in the world. The opportunity to attend the Festival is a plus! Due to the popularity of Edinburgh during the festival period, we recommend booking accommodation early. More details regarding accommodation may be obtained from the ICFP 2009 Local Arrangements webpage: http://www.haskell.org/haskellwiki/ICFP_2009_Local_Arrangements Accepted papers ~~~ A CONCURRENT ML LIBRARY IN CONCURRENT HASKELL Avik Chaudhuri A THEORY OF TYPED COERCIONS AND ITS APPLICATIONS Nikhil Swamy, Michael Hicks and Gavin Bierman A UNIVERSE OF BINDING AND COMPUTATION Daniel Licata and Robert Harper ATTRIBUTE GRAMMARS FLY FIRST-CLASS: HOW TO DO ASPECT ORIENTED PROGRAMMING IN HASKELL Marcos Viera, S. Doaitse Swierstra and Wouter S. Swierstra AUTOMATICALLY RESTFUL WEB APPLICATIONS OR, MARKING MODULAR SERIALIZABLE CONTINUATIONS Jay McCarthy BEAUTIFUL DIFFERENTIATION Conal Elliott BIORTHOGONALITY, STEP-INDEXING AND COMPILER CORRECTNESS Nick Benton and Chung-Kil Hur CAUSAL COMMUTATIVE ARROWS AND THEIR OPTIMIZATION Hai Liu, Eric Cheng and Paul Hudak COMPLETE AND DECIDABLE TYPE INFERENCE FOR GADTS Tom Schrijvers, Simon Peyton Jones, Martin Sulzmann and Dimitrios Vytiniotis CONTROL-FLOW ANALYSIS OF FUNCTION CALLS AND RETURNS BY ABSTRACT INTERPRETATION Jan Midtgaard and Thomas P. Jensen EDUCATIONAL PEARL: FUN FOR FRESHMEN KIDS Matthias Felleisen, Robert Bruce Findler, Matthew Flatt and Shriram Krishnamurthi EFFECTIVE INTERACTIVE PROOFS FOR HIGHER-ORDER IMPERATIVE PROGRAMS Adam Chlipala, Gregory Malecha, Greg Morrisett, Avraham Shinnar and Ryan Wisnesky EXPERIENCE REPORT: EMBEDDED, PARALLEL COMPUTER-VISION WITH A FUNCTIONAL DSL Ryan Newton and Teresa Ko EXPERIENCE REPORT: HASKELL IN THE REALWORLD Curt Sampson EXPERIENCE REPORT: OCAML FOR AN INDUSTRIAL-STRENGTH STATIC ANALYSIS FRAMEWORK Pascal Cuoq and Julien Signoles EXPERIENCE REPORT: OCSIGEN, A WEB PROGRAMMING FRAMEWORK Vincent Balat, Jérôme Vouillon and Boris Yakobowski EXPERIENCE REPORT: SEL4 -- FORMALLY VERIFYING A HIGH-PERFORMANCE MICROKERNEL Gerwin Klein, Philip Derrin and Kevin Elphinstone FINDING RACE CONDITIONS IN ERLANG WITH QUICKCHECK AND PULSE Koen Claessen, Michal Palka, Nicholas Smallbone, John Hughes, Hans Svensson, Thomas Arts and Ulf Wiger FREE THEOREMS INVOLVING TYPE CONSTRUCTOR CLASSES Janis Voigtlaender GENERIC PROGRAMMING WITH FIXED POINTS FOR MUTUALLY RECURSIVE DATATYPES Alexey Rodriguez, Stefan Holdermans, Andres Löh and Johan Jeuring IDENTIFYING QUERY INCOMPATIBILITIES WITH EVOLVING XML SCHEMAS Pierre Geneves, Nabil Layaida and Vincent Quint IMPLEMENTING FIRST-CLASS POLYMORPHIC DELIMITED CONTINUATIONS BY A TYPE-DIRECTED SELECTIVE CPS-TRANSFORM Tiark Rompf, Ingo Maier and Martin Odersky LA TOUR D'HANOï Ralf Hinze NON-PARAMETRIC PARAMETRICITY Georg Neis, Derek Dreyer and Andreas Rossberg OXENSTORED: AN EFFICIENT HIERARCHICAL AND TRANSACTIONAL DATABASE USING FUNCTIONAL PROGRAMMING WITH REFERENCE CELL COMPARISONS Thomas Gazagnaire and Vincent Hanquez PARALLEL CONCURRENT ML John Reppy, Claudio Russo and Yingqi Xiao PARTIAL MEMOIZATION OF CONCURRENCY AND COMMUNICATION Suresh Jagannathan, KC Sivaramakrishnan and Lukasz Ziarek PURELY FUNCTIONAL LAZY NON-DETERMINISTIC PROGRAMMING Sebastian Fischer, Oleg Kiselyov and Chung-chieh Shan RUNTIME SUPPORT FOR MULTICORE HASKELL Simon Marlow, Simon Peyton Jones and Satnam Singh SAFE FUNCTIONAL REACTIVE PROGRAMMING THROUGH DEPENDENT TYPES Neil Sculthorpe and Henrik Nilsson SCRIBBLE: CLOSING THE BOOK ON AD HOC DOCUMENTATION TOOLS Matthew Flatt, Eli Barzilay and Robert Bruce Findler USING OBJECTIVE CAML TO DEVELOP SAFETY-CRITICAL EMBEDDED TOOL IN A CERTIFICATION FRAMEWORK Bruno Pagano, Olivier Andrieu, Thomas Moniot, Benjamin Canou, Emmanuel Chailloux, Philippe Wang, Pascal Manoury and Jean-Louis Colaco ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] TFM09: Last CFP (Formal Methods Week, Eindhoven, November 6th 2009)
TFM2009 2nd Int. FME Conference on Teaching Formal Methods Widening Access to Formal Methods Friday, November 6th 2009, co-located with FM2009 : 16th International Symposium on Formal Methods Eindhoven, the Netherlands, November 2 - November 6, 2009 CALL FOR PAPERS (URL: http://www.di.uminho.pt/tfm09) 1. About the conference --- Ten years after the First World Formal Methods Congress (FM'99) in Toulouse, formal methods communities from all over the world will once again have an opportunity to come together. As part of the First Formal Methods Week event surrounding the FM2009 conference in Eindhoven, Formal Methods Europe will be organizing TFM2009, the Second International Conference on Teaching Formal Methods. The conference will serve as a forum to explore the successes and failures of Formal Methods (FM) education, and to promote cooperative projects to further education and training in FMs. We would like to provide a forum for lecturers, teachers, and industrial partners to discuss their experience, present their pedagogical methodologies, and explore best practices. TFM2009 follows in a series of recent events on teaching formal methods, including: two BCS-FACS TFM workshops (Oxford in 2003, and London in 2006), the TFM 2004 conference in Ghent (with proceedings published as Springer LNCS Volume 3294), the FM-Ed 2006 workshop (Hamilton, co-located with FM'06), FORMED (Budapest, at ETAPS 2008), FMET 2008 (Kitakyushu 2008, co-located with ICFEM), etc. 2. Topics of interest - Formal methods (FM) have an important role to play in the development of complex computing systems - a role acknowledged in industrial standards such as IEC 61508 and ISO/IEC 15408, and in the increasing use of precise modeling notations, semantic markup languages, and model-driven techniques. There is a growing need for software engineers who can work effectively with simple, mathematical abstractions, and with practical notions of inference and proof. However, there is little clear guidance ? for educators, for managers, or for the engineers themselves ? as to what might comprise a basic education in FM. Neither the present IEEE/ACM Software Engineering Body of Knowledge (SWEBOK) nor the forthcoming Graduate Software Engineering Reference Curriculum (GSWERC) provide the kind of specific information that teachers and practitioners need to establish an adequate, balanced programme of learning in FM. Original contributions are solicited that provide insight, opinions, and suggestions for courses of action regarding the teaching FMs, including but not limited to the following aspects: * experiences of teaching FMs, both successful and unsuccessful; * educational resources including the use of books, case studies and the internet; * the education of weak and mathphobic students; * the integration, or otherwise, of FMs into the curriculum, including contributions to the definition of a Formal Methods Body of Knowledge (FMBOK); * the advantages of FM-trained graduates in the workplace; * changing attitudes towards FMs in students, academic staff and practitioners; * the necessary mathematical background. The conference proceedings will be published by Springer-Verlag in the LNCS series. Submissions may be up to 20 pages long using Springer's LNCS format. 3. Important dates -- Please put the following dates in your diary: Submission deadline May 25, 2009 Notification of acceptance July 6, 2009 Final version August 3, 2009 4. How to submit Papers for TFM2009 will be processed through the EasyChair conference management system.To submit your paper, please visit: http://www.easychair.org/conferences/?conf=tfm2009 5. Invited speakers --- To be announced 6. Programme Committee -- Izzat Alsmadi (North Dakota State University, USA) Dines Bjorner (IIMM Institute, Denmark) Eerke Boiten(University of Kent, UK) Raymond Boute (Universiteit Gent, Belgium) Andrew Butterfield (Trinity College, Dublin) Jim Davies (University of Oxford, UK) David Duce (Oxford Brookes University, UK) John Fitzgerald (University of Newcastle upon Tyne, UK) Jeremy Gibbons (University of Oxford, UK) Randolph Johnson(National Security Agency, USA) Michael Mac an Airchinnigh (Trinity College, Dublin) Dino Mandrioli (Politecnico di Milano, Italy) Jose Oliveira (Universidade do Minho, Portugal) Kees Pronk (Technische Universiteit Delft, NL) Bernhard Schaetz(Tecnical University of Munique, Germany) Wolfgang Schreiner (Johannes Kepler University Linz, Austria) Simao Melo de Sousa (Universidade da
[Haskell] ANN: RESTng 0.1 + RedHandlers 0.1 (request handlers) + YuiGrids 0.1 (yahoo grids)
I'd like to announce the release of 3 new packages in hackage developed for a RESTful web framework called RESTng. They are experimental, the framework is incomplete and we are currently not actively developing it. There are several interesting features so we have decided to release them to share the ideas. *RESTng:* A framework for writing RESTful applications. Features that may be of interest are: * Resource presentation with annotations (implemented with Grids): Resources are annotated with related data and all ends in boxes using grids. i.e., an annotation for a book resource could be its author (the author resource), and also their comments, so the book, the author and their comments are shown in boxes. Annotations can have arbitrary data, but there are some generic ones already available. * Hierarchical URLs are automatically handled. i.e.: Can easily define that a book resource has many chapters, then these actions are defined: GET http://site/book/3/chapter/1(get the chapter 1 of book with id 3) GET http://site/book/3/chapter/new (get a form for filling data for the new chapter for book with id 3) POST http://site/book/3/chapter/new (create a new chapter for the book with id 3) and so on for updates, list and delete actions * ORM generates tables from haskell records (currently only PostgreSQL is supported in the ORM). * Associations has many defined for models. Making available functions to query for the parent and children so you don't have to make the SQL query. * Associations can be polymorphic so a comment can be associated to different resources types. A record for a comment on a book, another for a comment on a post. * Tags, Ratings, Comments, Users and login and CMS-like form fields validations supported. *YuiGrids:* * Containers and boxes with layout hints are specified. i.e: - Box A: in left side bar, near the bottom, with this content - Container B: in the main part of the page, near the top, with 3 columns and these let's say 14 boxes inside ... (including Box C) - Box C: in the left column of three, with this other content ... * Tries to satisfy the layout hints. Not allways possible, i.e: if every box has layout hint to go near the bottom, some of them will go at the top. * Boxes can have CSS specifications. * All is rendered into Yahoo grids (http://developer.yahoo.com/yui/grids). Currently, the YuiGrids uses own contextual html combinators are also implemented in this package (called CxML here) instead of Text.XHtml for keeping track of html parts like inline CSSs to be rendered at the head. This can be improved to use the standard Text.XHtml library. *RedHandlers:* It is another HTTP request handlers library to build standalone web apps. * They deal with request data as usual. * There are also combinators for mapping part of the URL to public folders in the file system. * And one for sending files efficiently in the response (a fork of the HTTP library was necessary for this, included here). ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] conflicting variable definitions in pattern
It is pretty clear, that the following is not a valid Haskell pattern: foo (x:x:xs) = x:xs My questions is _why_ this is not allowed. IMHO, the semantics should be clear: The pattern is expected to succeed, iff 'x' is each time bound to the same term. Isn't this allowed, because this would require a strict evaluation of the 'x' variables? Thanks, Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
What would you expect foo [id, \x - x] to be? Martin Hofmann wrote on 15.05.2009 12:09: It is pretty clear, that the following is not a valid Haskell pattern: foo (x:x:xs) = x:xs My questions is _why_ this is not allowed. IMHO, the semantics should be clear: The pattern is expected to succeed, iff 'x' is each time bound to the same term. Isn't this allowed, because this would require a strict evaluation of the 'x' variables? Thanks, Martin ___ 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] conflicting variable definitions in pattern
Martin Hofmann wrote: It is pretty clear, that the following is not a valid Haskell pattern: foo (x:x:xs) = x:xs My questions is _why_ this is not allowed. IMHO, the semantics should be clear: The pattern is expected to succeed, iff 'x' is each time bound to the same term. Isn't this allowed, because this would require a strict evaluation of the 'x' variables? One reason is: What if the list were a list of functions? How would you decide sameness of lambda-terms? By investigating their in-memory representations? By trying to prove that they denote the same mathematical function? Ciao, 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] conflicting variable definitions in pattern
Martin Hofmann wrote: It is pretty clear, that the following is not a valid Haskell pattern: foo (x:x:xs) = x:xs My questions is _why_ this is not allowed. IMHO, the semantics should be clear: The pattern is expected to succeed, iff 'x' is each time bound to the same term. How do you define the same term? One natural way of compiling it would be to foo (x:y:xs) | x == y = x:xs but then pattern matching can introduce Eq constraints which some might see as a bit odd. Isn't this allowed, because this would require a strict evaluation of the 'x' variables? The translation into == would probably introduce some strictness, for most implementations of Eq. I don't think this is a huge problem in itself. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
Dear Martin, I think that the (practical) reason is avoiding equality checks during pattern matching. For instance, how do you evaluate this: foo ((+1):(1+):[])? Both expressions in the first and second entries of the list are semantically equivalent, but from an operational point of view, you have to ensure the equality of two functions over an infinite domain (of integer numbers). Best regards, Salvador. Martin Hofmann escribió: It is pretty clear, that the following is not a valid Haskell pattern: foo (x:x:xs) = x:xs My questions is _why_ this is not allowed. IMHO, the semantics should be clear: The pattern is expected to succeed, iff 'x' is each time bound to the same term. Isn't this allowed, because this would require a strict evaluation of the 'x' variables? Thanks, Martin ___ 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] Pretty printing a tree
José Romildo Malaquias wrote: Hello. I would like to pretty print a tree in a way that its structure is easily perceived. For instance, consider the declarations: data Node a = Node a [Node a] type Tree a = [ Node a ] t = [ Node a [ Node b [] , Node c [ Node c1 [] , Node c2 [] ] , Node d [ Node d1 [ Node d1a [] ] , Node d2 [] ] ] ] Then the resulting of pretty printing the given tree would be something like the following: a | +-+ ||| bcd || +---++---+ | || | c1 c2 d1 d2 | d1a If you're just curious about how one would write such a thing, you can look at Data.Trie.Internal.showTrie[1]--- it's horizontal rather than vertical, and it doesn't center labels above their children, but it should give you a starting idea. Data.Map and Data.IntMap also have examples (showTree, showTreeWith) which are a bit simpler. This is a common homework assignment (because it's a great exercise!) though I haven't seen any prepackaged generic solutions. Perhaps we need more enterprising students :) [1] http://community.haskell.org/~wren/bytestring-trie/src/Data/Trie/Internal.hs -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
Why, then, not permit such definitions only for members of Eq? My thoughts: - because it will break an important invariant indicated by Martin, namely the one that says that pattern variables are not forced - it will make efficient compilation of pattern matching much harder - it will make the termination behavior of pattern matching dependent not only on the term being matched, but also on how Eq is implemented for that type - it will make the very rules of evaluation for pattern matching much more complex, fragile and hard to understand: in what order should the equated parts be evaluated? That influences termination behavior, so it is important. In what order should equality comparisons be performed in f (Node a (Leaf b a) (Node a))) = b ? 2009/5/15 Salvador Lucas slu...@dsic.upv.es: Dear Martin, I think that the (practical) reason is avoiding equality checks during pattern matching. For instance, how do you evaluate this: foo ((+1):(1+):[]) ? Both expressions in the first and second entries of the list are semantically equivalent, but from an operational point of view, you have to ensure the equality of two functions over an infinite domain (of integer numbers). Best regards, Salvador. Martin Hofmann escribió: It is pretty clear, that the following is not a valid Haskell pattern: foo (x:x:xs) = x:xs My questions is _why_ this is not allowed. IMHO, the semantics should be clear: The pattern is expected to succeed, iff 'x' is each time bound to the same term. Isn't this allowed, because this would require a strict evaluation of the 'x' variables? Thanks, Martin ___ 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 -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I have forgotten .. my bad
On Fri, May 15, 2009 at 5:30 AM, Vasili I. Galchin vigalc...@gmail.com wrote: Hello, darcs get --init ?? I want to pull down Data.FiniteMap. I have forgotten the path to Hackage .. I tried sudo darcs get http://hackage.haskell.org/ Data.FiniteMap [sudo] password for vigalchin: Invalid repository: http://hackage.haskell.org darcs failed: Failed to download URL http://hackage.haskell.org/_darcs/inventory : HTTP error (404?) ?? Obviously the code I am cabalizing needs to be upgraded(i.e. not using deprecated packages) but first I want it to build! If you want to install something from Hackage, use $ cabal install foo If you want to grab the source $ darcs get --partial path/to/repo (Omit the --partial flag if you want the full source tree, but if you're not intending to do serious work on the source it's probably not worth it.) From the error message above you appear to be darcs getting the root directory of the hackage server, which isn't a valid repository. Cheers, D -- Dougal Stanton dou...@dougalstanton.net // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
Hi On 15 May 2009, at 09:11, Sittampalam, Ganesh wrote: Martin Hofmann wrote: It is pretty clear, that the following is not a valid Haskell pattern: foo (x:x:xs) = x:xs My questions is _why_ this is not allowed. IMHO, the semantics should be clear: The pattern is expected to succeed, iff 'x' is each time bound to the same term. That's what my daddy did in 1970. It was an extension of LISP with pattern matching. He used EQUAL. That makes me one of the few functional programmers who's had this feature taken away from them. I'm not weeping, but I do miss it. How do you define the same term? One natural way of compiling it would be to foo (x:y:xs) | x == y = x:xs but then pattern matching can introduce Eq constraints which some might see as a bit odd. Doesn't seem that odd to me. Plenty of other language features come with constraints attached. Isn't this allowed, because this would require a strict evaluation of the 'x' variables? The translation into == would probably introduce some strictness, for most implementations of Eq. I don't think this is a huge problem in itself. There's some conceptual ugliness in that such a mechanism *relies* on fall-through. In principle a sequence of guardless patterns can always be fleshed out (at some cost) to disjoint patterns. What precisely covers the case disjoint from (x, x)? This is fixable if one stops quibbling about guardlessness, or even if one adds inequality patterns. One certainly needs a convention about the order in which things happen: delaying equality tests until after constructor matching --- effectively the guard translation --- seems sensible and preserves the existing compilation regime. Otherwise, repeated pattern variables get (==)-tested, linear ones are lazy. Meanwhile, yes the semantics depends on the implementation of (==), but what's new? That's true of do too. The guard translation: linearize the pattern, introducing new vars for all but the leftmost occurrence of repeated vars. For each new x' made from x, add a guard x == x'. The new guards should come in the same order as the new variables and stand before any other guards present. Presumably one can already cook up an ugly version of this with view patterns ((x ==) - True). It seems to me that the only questions of substance remaining is whether improved clarity in normal usage is worth a little more translational overhead to unpick what's wrong when weird things happen, and whether any such gain is worth the effort in implementation. I miss lots of stuff from when I was a kid. I used to write elem x (_ ++ x : _) = True elem _ _ = False and think that was cool. How dumb was I? Cheers Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Data.Binary and little endian encoding
leimy2k: On Thu, May 14, 2009 at 8:46 PM, Don Stewart d...@galois.com wrote: leimy2k: On Thu, May 14, 2009 at 8:40 PM, Don Stewart d...@galois.com wrote: leimy2k: I actually need little endian encoding... wondering if anyone else hit this with Data.Binary. (because I'm working with Bell Lab's 9P protocol which does encode things on the network in little-endian order). Anyone got some tricks for this? Yes! There are big, little and host-endian primitives in the Get/Put monads. http://hackage.haskell.org/packages/archive/binary/0.5.0.1/doc/html/ Data-Binary-Put.html#v%3AputWord16le You can use these to build encoders directly. Cool... I just have to write my own encoder and decoder now. As a request could we get encodeLe decodeLe for a later version of this library? :-) That'd be totally awesome. Oh, you mean entirely different instances for all the current ones, that use LE encodings? Well the library is leaning towards Network Byte Order in that it has encode/decode that only encode/decode for Big Endian. Us folks who have to do little endian all now have to write our own encoding/decoding :-) I'm speaking specifically of the encode/decode functions. I have no idea how they're implemented. The encode/decode functions just call the runGet/runPut functions for whatever is being encoded or decoded to combined with the get/put functions from the Binary instance. The endian-ness is entirely determined by the Binary instance for the data type you're encoding/decoding, not anything in the encode/decode functions themselves. For data types you define, you can make the Binary instance LE standard (although it may not be a good idea) by using the little-endian primitives Don mentioned. For built-in types, if you want to use a different endian-ness, you can make new get/put functions then call runGet/runPut on those directly. You won't be able to redefine the Binary instances, but if you'll be doing this with a lot of different types you could make your own BinaryLE class like this: class BinaryLE t where putLE :: t - Put getLE :: Get t encodeLE :: BinaryLE a = a - ByteString encodeLE = runPut . putLE decodeLE :: BinaryLE a = ByteString - a decodeLE = runGet getLE I've done some work with Binary and little-endian, and this bias never really bothered me (I think it's actually a host-endian bias, could be mistaken). I was using my own data types so I had to make my own custom Binary instances, which I would have had to do anyway. The data format specified little-endian, so making the Binary instance LE-standard seemed appropriate. You'd only need to re-make custom get/put functions if you're using types that already have Binary instances, and you intend to manipulate the data outside of Haskell. Does that describe your situation? John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I have forgotten .. my bad
On Thu, May 14, 2009 at 9:30 PM, Vasili I. Galchin vigalc...@gmail.com wrote: Hello, darcs get --init ?? I want to pull down Data.FiniteMap. I have forgotten the path to Hackage .. I tried sudo darcs get http://hackage.haskell.org/ Data.FiniteMap [sudo] password for vigalchin: I don't know what your machine is configured like, but I'm rather surprised to see you use 'sudo' with darcs. In case you're not already familiar with the purpose of sudo, I'll explain. The purpose is to give the command the same privileges as root, the super user. Effectively, you're giving darcs full range over your computer. Although, this should be harmless in the case of darcs, it is usually a bad idea to give commands superuser privileges unless they really need it :) Good luck! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
Conor McBride wrote: Hi Sittampalam, Ganesh wrote: Martin Hofmann wrote: It is pretty clear, that the following is not a valid Haskell pattern: foo (x:x:xs) = x:xs My questions is _why_ this is not allowed. IMHO, the semantics should be clear: The pattern is expected to succeed, iff 'x' is each time bound to the same term. That's what my daddy did in 1970. It was an extension of LISP with pattern matching. He used EQUAL. That makes me one of the few functional programmers who's had this feature taken away from them. I'm not weeping, but I do miss it. On the one hand, unification is awesome; on the other hand, pattern matching is simple. The nice thing about the simplicity is that it's easy to compile into efficient code, and it's easy to explain/understand. Unification has all sorts of unfortunate consequences[1] and it's much harder to explain to the uninitiated. Curry[2] has features like this, but then it has full backtracking-search logic programming. It might be interesting to see if a more restricted form is useful in Haskell, though it should be an optional feature IMO so that it can be disabled for guaranteed-efficient patterns and typo detection. [1] e.g. optimal factoring of an unordered set of Prolog terms is NP-complete. For a fixed ordering there are good algorithms, and Haskell has fixed ordering due to the semantics of overlapping patterns, but this should still give some clues about what lurks beneath. [2] http://www.curry-language.org/ How do you define the same term? One natural way of compiling it would be to foo (x:y:xs) | x == y = x:xs but then pattern matching can introduce Eq constraints which some might see as a bit odd. Doesn't seem that odd to me. Plenty of other language features come with constraints attached. Another option is to use structural matching all the way down. This has the benefit of not calling user-defined code, though it has the disadvantages of not matching heterogeneous but semantically-equal values. Of course, by removing the Eq constraint this also re-raises the specter of comparing functions. But it's a good Devil's Advocate definition to bear in mind. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
I miss lots of stuff from when I was a kid. I used to write elem x (_ ++ x : _) = True elem _ _ = False and think that was cool. How dumb was I? Yeah, the Kiel Reduction Language had similarly expressive and fun pattern matching, with subsequence matching and backtracking if the guard failed. Of course, these days, you could use view patterns for the simpler cases, but it doesn't look quite as nice: elem x (break (==x) - (_, _:_)) = True elem _ _ = False and gets ugly enough to spoil the fun quickly: -- lookup key (_++((key,value):_)) = Just value lookup key (break ((==key).fst) - (_ , (_,value):_)) = Just value lookup _ _ = Nothing Also, view patterns don't handle match failure by an implicit Monad, let alone MonadPlus, so one often has to insert an explicit Maybe, and there is no backtracking:-( Claus -- Nostalgia isn't what it used to be [source: ?] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary and little endian encoding
On Thu, 2009-05-14 at 20:46 -0700, David Leimbach wrote: On Thu, May 14, 2009 at 8:40 PM, Don Stewart d...@galois.com wrote: leimy2k: I actually need little endian encoding... wondering if anyone else hit this with Data.Binary. (because I'm working with Bell Lab's 9P protocol which does encode things on the network in little-endian order). Anyone got some tricks for this? Yes! There are big, little and host-endian primitives in the Get/Put monads. http://hackage.haskell.org/packages/archive/binary/0.5.0.1/doc/html/Data-Binary-Put.html#v%3AputWord16le You can use these to build encoders directly. Cool... I just have to write my own encoder and decoder now. As a request could we get encodeLe decodeLe for a later version of this library? :-) That'd be totally awesome. The thing you're missing (and which admittedly is not clear) is that the binary package has two parts. One is a layer where you get full control over the binary representation. The other is a portable serialisation layer for pickling and unpickling Haskell values. That pickling layer (ie the Binary class) is not for working with externally-defined binary formats. It might seem like we could co-opt the Binary class for this purpose eg by parametrising by a dozen things like endian, padding, etc etc but I don't think it scales or is sufficiently flexible (and it'd be slow). What is missing in the binary package is a nice set of combinators for using the low level layer to easily construct parsers for externally-defined formats. That's what you'd want for your P9 protocol. To reduce confusion we should also split the Haskell picking layer from the lower layer. This has been on our TODO list for some time. It needs to be done pretty carefully however and we've not really had the time. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] conflicting variable definitions in pattern
Conor McBride wrote: On 15 May 2009, at 09:11, Sittampalam, Ganesh wrote: but then pattern matching can introduce Eq constraints which some might see as a bit odd. Doesn't seem that odd to me. Plenty of other language features come with constraints attached. It's the introduction of a constraint from tweaking a pattern that is odd, I think. By way of precedent H98 rejected this kind of idea in favour of putting 'fail' into Monad. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
In the original language design the Haskell committee considered allowing multiple occurrences of the same variable in a pattern (with the suggested equality tests), but it was rejected in favour of simplicity. -- Lennart On Fri, May 15, 2009 at 11:30 AM, Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com wrote: Conor McBride wrote: On 15 May 2009, at 09:11, Sittampalam, Ganesh wrote: but then pattern matching can introduce Eq constraints which some might see as a bit odd. Doesn't seem that odd to me. Plenty of other language features come with constraints attached. It's the introduction of a constraint from tweaking a pattern that is odd, I think. By way of precedent H98 rejected this kind of idea in favour of putting 'fail' into Monad. Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ 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] conflicting variable definitions in pattern
On 15 May 2009, at 12:07, Lennart Augustsson wrote: In the original language design the Haskell committee considered allowing multiple occurrences of the same variable in a pattern (with the suggested equality tests), but it was rejected in favour of simplicity. Simplicity for whom, is the question? My point is only that there's no technical horror to the proposal. It's just that, given guards, the benefit (in simplicity of program comprehension) of nonlinear patterns over explicit == is noticeable but hardly spectacular. Rumblings about funny termination behaviour, equality for functions, and the complexity of unification (which isn't the proposal anyway) are wide of the mark. This is just an ordinary cost-versus-benefit issue. My guess is that if this feature were already in, few would be campaigning to remove it. (By all means step up and say why!) As it's not in, it has to compete with other priorities: I'm mildly positive about nonlinear patterns, but there are more important concerns. Frankly, the worst consequence I've had from Haskell's pattern linearity was just my father's derision. He quite naturally complained that his programs had lost some of their simplicity. All the best Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
Conor McBride wrote on 15.05.2009 16:19: My guess is that if this feature were already in, few would be campaigning to remove it. You're probably right. For example, I'm not compaigning to remove multiple inheritance (from non-abstract classes) from C++. But I still think it's an ugly feature, it'd be better not to have it, it's encouraging bad design etc. The same for this Eq-patterns. BTW, why stop on (x:x:xs)? Let's use patterns like (x:factorial(x):xs), or (factorial(x):x:xs), or (factorial(x):xs)... No, wait, the last pattern would be impossible to compile. But I think you've got the point. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pretty printing a tree
Hello, Or --- if you just want pretty trees and you are not confined to the command line: You can generate GraphViz code and use that program to draw your tree in PostScript. (There is also a GraphViz-package, but generating the code yourself is easy.) Matthias. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
Simplicity of pattern matching semantics, not of implementation (we all knew how to implement it). Miranda had non-linear patterns, but nobody really argued for them in Haskell. If Haskell had them, I'd not argue to have them removed, but nor will I argue to add them. -- Lennart On Fri, May 15, 2009 at 1:19 PM, Conor McBride co...@strictlypositive.org wrote: On 15 May 2009, at 12:07, Lennart Augustsson wrote: In the original language design the Haskell committee considered allowing multiple occurrences of the same variable in a pattern (with the suggested equality tests), but it was rejected in favour of simplicity. Simplicity for whom, is the question? My point is only that there's no technical horror to the proposal. It's just that, given guards, the benefit (in simplicity of program comprehension) of nonlinear patterns over explicit == is noticeable but hardly spectacular. Rumblings about funny termination behaviour, equality for functions, and the complexity of unification (which isn't the proposal anyway) are wide of the mark. This is just an ordinary cost-versus-benefit issue. My guess is that if this feature were already in, few would be campaigning to remove it. (By all means step up and say why!) As it's not in, it has to compete with other priorities: I'm mildly positive about nonlinear patterns, but there are more important concerns. Frankly, the worst consequence I've had from Haskell's pattern linearity was just my father's derision. He quite naturally complained that his programs had lost some of their simplicity. All the best Conor ___ 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] Problem with haddock importing definition
Hi, I have a situation like this: module A imports R (a newtype declaration) from module B, and lists it in its (module A) export list. Documentation for R is included by haddock in documentation for module A, as I want. However, if my package exposes only module A, documentation for R desapears. So: if my .cabal file lists A and B in 'exposed-modules', documentation for R is included in A documentation. If I remove B from 'exposed-modules', R documentation in A desapears. Do you know what should I do? Thanks, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] #haskell.pt IRC channel
Hello, I'd like to invite all Portuguese speakers haskellers to join #haskell.pt in irc.freenode.net. I added it to the list in http://www.haskell.org/haskellwiki/IRC_channel . Greetings. -- marcot http://marcot.iaaeee.org/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ICFP09 Accepted Papers
Accepted Papers ICFP 2009: International Conference on Functional Programming Edinburgh, Scotland, 31 August - 2 September 2009 http://www.cs.nott.ac.uk/~gmh/icfp09.html The ICFP 2009 Program Chair and Committee are pleased to announce that the following papers have been accepted for the conference. Additional information regarding the final program, invited speakers, and registration will be forthcoming. However, the Local Arrangements Co-Chairs would like to remind participants of the following: * ICFP'09 coincides with the final week of the Edinburgh International Festival, one of the premier arts and cultural festivals in the world. The opportunity to attend the Festival is a plus! Due to the popularity of Edinburgh during the festival period, we recommend booking accommodation early. More details regarding accommodation may be obtained from the ICFP 2009 Local Arrangements webpage: http://www.haskell.org/haskellwiki/ICFP_2009_Local_Arrangements Accepted papers ~~~ A CONCURRENT ML LIBRARY IN CONCURRENT HASKELL Avik Chaudhuri A THEORY OF TYPED COERCIONS AND ITS APPLICATIONS Nikhil Swamy, Michael Hicks and Gavin Bierman A UNIVERSE OF BINDING AND COMPUTATION Daniel Licata and Robert Harper ATTRIBUTE GRAMMARS FLY FIRST-CLASS: HOW TO DO ASPECT ORIENTED PROGRAMMING IN HASKELL Marcos Viera, S. Doaitse Swierstra and Wouter S. Swierstra AUTOMATICALLY RESTFUL WEB APPLICATIONS OR, MARKING MODULAR SERIALIZABLE CONTINUATIONS Jay McCarthy BEAUTIFUL DIFFERENTIATION Conal Elliott BIORTHOGONALITY, STEP-INDEXING AND COMPILER CORRECTNESS Nick Benton and Chung-Kil Hur CAUSAL COMMUTATIVE ARROWS AND THEIR OPTIMIZATION Hai Liu, Eric Cheng and Paul Hudak COMPLETE AND DECIDABLE TYPE INFERENCE FOR GADTS Tom Schrijvers, Simon Peyton Jones, Martin Sulzmann and Dimitrios Vytiniotis CONTROL-FLOW ANALYSIS OF FUNCTION CALLS AND RETURNS BY ABSTRACT INTERPRETATION Jan Midtgaard and Thomas P. Jensen EDUCATIONAL PEARL: FUN FOR FRESHMEN KIDS Matthias Felleisen, Robert Bruce Findler, Matthew Flatt and Shriram Krishnamurthi EFFECTIVE INTERACTIVE PROOFS FOR HIGHER-ORDER IMPERATIVE PROGRAMS Adam Chlipala, Gregory Malecha, Greg Morrisett, Avraham Shinnar and Ryan Wisnesky EXPERIENCE REPORT: EMBEDDED, PARALLEL COMPUTER-VISION WITH A FUNCTIONAL DSL Ryan Newton and Teresa Ko EXPERIENCE REPORT: HASKELL IN THE REALWORLD Curt Sampson EXPERIENCE REPORT: OCAML FOR AN INDUSTRIAL-STRENGTH STATIC ANALYSIS FRAMEWORK Pascal Cuoq and Julien Signoles EXPERIENCE REPORT: OCSIGEN, A WEB PROGRAMMING FRAMEWORK Vincent Balat, Jérôme Vouillon and Boris Yakobowski EXPERIENCE REPORT: SEL4 -- FORMALLY VERIFYING A HIGH-PERFORMANCE MICROKERNEL Gerwin Klein, Philip Derrin and Kevin Elphinstone FINDING RACE CONDITIONS IN ERLANG WITH QUICKCHECK AND PULSE Koen Claessen, Michal Palka, Nicholas Smallbone, John Hughes, Hans Svensson, Thomas Arts and Ulf Wiger FREE THEOREMS INVOLVING TYPE CONSTRUCTOR CLASSES Janis Voigtlaender GENERIC PROGRAMMING WITH FIXED POINTS FOR MUTUALLY RECURSIVE DATATYPES Alexey Rodriguez, Stefan Holdermans, Andres Löh and Johan Jeuring IDENTIFYING QUERY INCOMPATIBILITIES WITH EVOLVING XML SCHEMAS Pierre Geneves, Nabil Layaida and Vincent Quint IMPLEMENTING FIRST-CLASS POLYMORPHIC DELIMITED CONTINUATIONS BY A TYPE-DIRECTED SELECTIVE CPS-TRANSFORM Tiark Rompf, Ingo Maier and Martin Odersky LA TOUR D'HANOï Ralf Hinze NON-PARAMETRIC PARAMETRICITY Georg Neis, Derek Dreyer and Andreas Rossberg OXENSTORED: AN EFFICIENT HIERARCHICAL AND TRANSACTIONAL DATABASE USING FUNCTIONAL PROGRAMMING WITH REFERENCE CELL COMPARISONS Thomas Gazagnaire and Vincent Hanquez PARALLEL CONCURRENT ML John Reppy, Claudio Russo and Yingqi Xiao PARTIAL MEMOIZATION OF CONCURRENCY AND COMMUNICATION Suresh Jagannathan, KC Sivaramakrishnan and Lukasz Ziarek PURELY FUNCTIONAL LAZY NON-DETERMINISTIC PROGRAMMING Sebastian Fischer, Oleg Kiselyov and Chung-chieh Shan RUNTIME SUPPORT FOR MULTICORE HASKELL Simon Marlow, Simon Peyton Jones and Satnam Singh SAFE FUNCTIONAL REACTIVE PROGRAMMING THROUGH DEPENDENT TYPES Neil Sculthorpe and Henrik Nilsson SCRIBBLE: CLOSING THE BOOK ON AD HOC DOCUMENTATION TOOLS Matthew Flatt, Eli Barzilay and Robert Bruce Findler USING OBJECTIVE CAML TO DEVELOP SAFETY-CRITICAL EMBEDDED TOOL IN A CERTIFICATION FRAMEWORK Bruno Pagano, Olivier Andrieu, Thomas Moniot, Benjamin Canou, Emmanuel Chailloux, Philippe Wang, Pascal Manoury and Jean-Louis Colaco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Data.Binary and little endian encoding
This approach looks like it'd work just fine. On Fri, May 15, 2009 at 2:16 AM, John Lato jwl...@gmail.com wrote: leimy2k: On Thu, May 14, 2009 at 8:46 PM, Don Stewart d...@galois.com wrote: leimy2k: On Thu, May 14, 2009 at 8:40 PM, Don Stewart d...@galois.com wrote: leimy2k: I actually need little endian encoding... wondering if anyone else hit this with Data.Binary. (because I'm working with Bell Lab's 9P protocol which does encode things on the network in little-endian order). Anyone got some tricks for this? Yes! There are big, little and host-endian primitives in the Get/Put monads. http://hackage.haskell.org/packages/archive/binary/0.5.0.1/doc/html/ Data-Binary-Put.html#v%3AputWord16le You can use these to build encoders directly. Cool... I just have to write my own encoder and decoder now. As a request could we get encodeLe decodeLe for a later version of this library? :-) That'd be totally awesome. Oh, you mean entirely different instances for all the current ones, that use LE encodings? Well the library is leaning towards Network Byte Order in that it has encode/decode that only encode/decode for Big Endian. Us folks who have to do little endian all now have to write our own encoding/decoding :-) I'm speaking specifically of the encode/decode functions. I have no idea how they're implemented. The encode/decode functions just call the runGet/runPut functions for whatever is being encoded or decoded to combined with the get/put functions from the Binary instance. The endian-ness is entirely determined by the Binary instance for the data type you're encoding/decoding, not anything in the encode/decode functions themselves. For data types you define, you can make the Binary instance LE standard (although it may not be a good idea) by using the little-endian primitives Don mentioned. For built-in types, if you want to use a different endian-ness, you can make new get/put functions then call runGet/runPut on those directly. You won't be able to redefine the Binary instances, but if you'll be doing this with a lot of different types you could make your own BinaryLE class like this: class BinaryLE t where putLE :: t - Put getLE :: Get t encodeLE :: BinaryLE a = a - ByteString encodeLE = runPut . putLE decodeLE :: BinaryLE a = ByteString - a decodeLE = runGet getLE I've done some work with Binary and little-endian, and this bias never really bothered me (I think it's actually a host-endian bias, could be mistaken). I was using my own data types so I had to make my own custom Binary instances, which I would have had to do anyway. The data format specified little-endian, so making the Binary instance LE-standard seemed appropriate. You'd only need to re-make custom get/put functions if you're using types that already have Binary instances, and you intend to manipulate the data outside of Haskell. Does that describe your situation? John ___ 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] TFM09: Last CFP (Formal Methods Week, Eindhoven, November 6th 2009)
TFM2009 2nd Int. FME Conference on Teaching Formal Methods Widening Access to Formal Methods Friday, November 6th 2009, co-located with FM2009 : 16th International Symposium on Formal Methods Eindhoven, the Netherlands, November 2 - November 6, 2009 CALL FOR PAPERS (URL: http://www.di.uminho.pt/tfm09) 1. About the conference --- Ten years after the First World Formal Methods Congress (FM'99) in Toulouse, formal methods communities from all over the world will once again have an opportunity to come together. As part of the First Formal Methods Week event surrounding the FM2009 conference in Eindhoven, Formal Methods Europe will be organizing TFM2009, the Second International Conference on Teaching Formal Methods. The conference will serve as a forum to explore the successes and failures of Formal Methods (FM) education, and to promote cooperative projects to further education and training in FMs. We would like to provide a forum for lecturers, teachers, and industrial partners to discuss their experience, present their pedagogical methodologies, and explore best practices. TFM2009 follows in a series of recent events on teaching formal methods, including: two BCS-FACS TFM workshops (Oxford in 2003, and London in 2006), the TFM 2004 conference in Ghent (with proceedings published as Springer LNCS Volume 3294), the FM-Ed 2006 workshop (Hamilton, co-located with FM'06), FORMED (Budapest, at ETAPS 2008), FMET 2008 (Kitakyushu 2008, co-located with ICFEM), etc. 2. Topics of interest - Formal methods (FM) have an important role to play in the development of complex computing systems - a role acknowledged in industrial standards such as IEC 61508 and ISO/IEC 15408, and in the increasing use of precise modeling notations, semantic markup languages, and model-driven techniques. There is a growing need for software engineers who can work effectively with simple, mathematical abstractions, and with practical notions of inference and proof. However, there is little clear guidance ? for educators, for managers, or for the engineers themselves ? as to what might comprise a basic education in FM. Neither the present IEEE/ACM Software Engineering Body of Knowledge (SWEBOK) nor the forthcoming Graduate Software Engineering Reference Curriculum (GSWERC) provide the kind of specific information that teachers and practitioners need to establish an adequate, balanced programme of learning in FM. Original contributions are solicited that provide insight, opinions, and suggestions for courses of action regarding the teaching FMs, including but not limited to the following aspects: * experiences of teaching FMs, both successful and unsuccessful; * educational resources including the use of books, case studies and the internet; * the education of weak and mathphobic students; * the integration, or otherwise, of FMs into the curriculum, including contributions to the definition of a Formal Methods Body of Knowledge (FMBOK); * the advantages of FM-trained graduates in the workplace; * changing attitudes towards FMs in students, academic staff and practitioners; * the necessary mathematical background. The conference proceedings will be published by Springer-Verlag in the LNCS series. Submissions may be up to 20 pages long using Springer's LNCS format. 3. Important dates -- Please put the following dates in your diary: Submission deadline May 25, 2009 Notification of acceptance July 6, 2009 Final version August 3, 2009 4. How to submit Papers for TFM2009 will be processed through the EasyChair conference management system.To submit your paper, please visit: http://www.easychair.org/conferences/?conf=tfm2009 5. Invited speakers --- To be announced 6. Programme Committee -- Izzat Alsmadi (North Dakota State University, USA) Dines Bjorner (IIMM Institute, Denmark) Eerke Boiten(University of Kent, UK) Raymond Boute (Universiteit Gent, Belgium) Andrew Butterfield (Trinity College, Dublin) Jim Davies (University of Oxford, UK) David Duce (Oxford Brookes University, UK) John Fitzgerald (University of Newcastle upon Tyne, UK) Jeremy Gibbons (University of Oxford, UK) Randolph Johnson(National Security Agency, USA) Michael Mac an Airchinnigh (Trinity College, Dublin) Dino Mandrioli (Politecnico di Milano, Italy) Jose Oliveira (Universidade do Minho, Portugal) Kees Pronk (Technische Universiteit Delft, NL) Bernhard Schaetz(Tecnical University of Munique, Germany) Wolfgang Schreiner (Johannes Kepler University Linz, Austria) Simao Melo de Sousa (Universidade da
Re: [Haskell-cafe] I have forgotten .. my bad
I mean what is the path to Hackage repo? Vasili On Fri, May 15, 2009 at 4:32 AM, Jason Dagit da...@codersbase.com wrote: On Thu, May 14, 2009 at 9:30 PM, Vasili I. Galchin vigalc...@gmail.com wrote: Hello, darcs get --init ?? I want to pull down Data.FiniteMap. I have forgotten the path to Hackage .. I tried sudo darcs get http://hackage.haskell.org/ Data.FiniteMap [sudo] password for vigalchin: I don't know what your machine is configured like, but I'm rather surprised to see you use 'sudo' with darcs. In case you're not already familiar with the purpose of sudo, I'll explain. The purpose is to give the command the same privileges as root, the super user. Effectively, you're giving darcs full range over your computer. Although, this should be harmless in the case of darcs, it is usually a bad idea to give commands superuser privileges unless they really need it :) Good luck! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: I have forgotten .. my bad
Vasili I. Galchin schrieb: Hello, darcs get --init ?? I want to pull down Data.FiniteMap. I have forgotten the path to Hackage .. I tried Hi Vasili, Hackage does not host the darcs repositories. You can get the FinitMap's source code via cabal unpack FiniteMap though. benedikt sudo darcs get http://hackage.haskell.org/ Data.FiniteMap [sudo] password for vigalchin: Invalid repository: http://hackage.haskell.org darcs failed: Failed to download URL http://hackage.haskell.org/_darcs/inventory : HTTP error (404?) ?? Obviously the code I am cabalizing needs to be upgraded(i.e. not using deprecated packages) but first I want it to build! Thanks, Vasili ___ 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] Don't play with your monads...
eventually you'll go bind. Sorry couldn't resist. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Don't play with your monads...
David Leimbach leim...@gmail.com wrote: eventually you'll go bind. Sorry couldn't resist. I'd rather go pure joyn. Greets, Ertugrul. -- nightmare = unsafePerformIO (getWrongWife = sex) http://blog.ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: RESTng 0.1 + RedHandlers 0.1 (request handlers) + YuiGrids 0.1 (yahoo grids)
I'd like to announce the release of 3 new packages in hackage developed for a RESTful web framework called RESTng. They are experimental, the framework is incomplete and we are currently not actively developing it. There are several interesting features so we have decided to release them to share the ideas. *RESTng:* A framework for writing RESTful applications. Features that may be of interest are: * Resource presentation with annotations (implemented with Grids): Resources are annotated with related data and all ends in boxes using grids. i.e., an annotation for a book resource could be its author (the author resource), and also their comments, so the book, the author and their comments are shown in boxes. Annotations can have arbitrary data, but there are some generic ones already available. * Hierarchical URLs are automatically handled. i.e.: Can easily define that a book resource has many chapters, then these actions are defined: GET http://site/book/3/chapter/1(get the chapter 1 of book with id 3) GET http://site/book/3/chapter/new (get a form for filling data for the new chapter for book with id 3) POST http://site/book/3/chapter/new (create a new chapter for the book with id 3) and so on for updates, list and delete actions * ORM generates tables from haskell records (currently only PostgreSQL is supported in the ORM). * Associations has many defined for models. Making available functions to query for the parent and children so you don't have to make the SQL query. * Associations can be polymorphic so a comment can be associated to different resources types. A record for a comment on a book, another for a comment on a post. * Tags, Ratings, Comments, Users and login and CMS-like form fields validations supported. *YuiGrids:* * Containers and boxes with layout hints are specified. i.e: - Box A: in left side bar, near the bottom, with this content - Container B: in the main part of the page, near the top, with 3 columns and these let's say 14 boxes inside ... (including Box C) - Box C: in the left column of three, with this other content ... * Tries to satisfy the layout hints. Not allways possible, i.e: if every box has layout hint to go near the bottom, some of them will go at the top. * Boxes can have CSS specifications. * All is rendered into Yahoo grids (http://developer.yahoo.com/yui/grids). Currently, the YuiGrids uses own contextual html combinators are also implemented in this package (called CxML here) instead of Text.XHtml for keeping track of html parts like inline CSSs to be rendered at the head. This can be improved to use the standard Text.XHtml library. *RedHandlers:* It is another HTTP request handlers library to build standalone web apps. * They deal with request data as usual. * There are also combinators for mapping part of the URL to public folders in the file system. * And one for sending files efficiently in the response (a fork of the HTTP library was necessary for this, included here). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSoC project for EclipseFP
On Thu, 14 May 2009, Thomas ten Cate wrote: I'm happy to announce that my Google Summer of Code project proposal, titled Extend EclipseFP functionality for Haskell, has been accepted! This means that I will be working on EclipseFP during the upcoming months. Great news! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Example code won't compile
Why won't this code compile?
Michael
===
{- Author: Jeff Newbern
Maintainer: Jeff Newbern jnewb...@nomaware.com
Time-stamp: Thu Aug 14 09:53:53 2003
License: GPL
-}
{- DESCRIPTION
Example 14 - Using the IO monad
Usage: Compile the code to produce a poor replacement for
the standard Unix tr command.
Try: cat file | ./ex14 aeiou X
cat file | ./ex14 _
./ex14 abc
-}
import Monad
import System
import IO
import Control.Monad.Error
-- translate char in set1 to corresponding char in set2
translate :: String - String - Char - Char
translate [] _ c = c
translate (x:xs) [] c = if x == c then ' ' else translate xs [] c
translate (x:xs) [y] c = if x == c then y else translate xs [y] c
translate (x:xs) (y:ys) c = if x == c then y else translate xs ys c
-- translate an entire string
translateString :: String - String - String - String
translateString set1 set2 str = map (translate set1 set2) str
usage :: IOError - IO ()
usage e = do putStrLn Usage: ex14 set1 set2
putStrLn Translates characters in set1 on stdin to the
corresponding
putStrLn characters from set2 and writes the translation to
stdout.
-- translates stdin to stdout based on commandline arguments
main :: IO ()
main = (do [set1,set2] - getArgs
contents - hGetContents stdin
putStr $ translateString set1 set2 contents)
`catchError` usage
-- END OF FILE
=
[mich...@localhost ~]$ ghc ex14.hs -o ex14
ex14.o: In function `rF8_info':
(.text+0x48): undefined reference to
`mtlzm1zi1zi0zi2_ControlziMonadziError_zdf17_closure'
ex14.o: In function `sGp_info':
(.text+0x861): undefined reference to
`mtlzm1zi1zi0zi2_ControlziMonadziError_zdf17_closure'
ex14.o: In function `sGp_info':
(.text+0x91d): undefined reference to
`__stginit_mtlzm1zi1zi0zi2_ControlziMonadziError_'
ex14.o: In function `rF8_info':
(.text+0x50): undefined reference to
`mtlzm1zi1zi0zi2_ControlziMonadziErrorziClass_zdp1MonadError_info'
ex14.o: In function `sGp_info':
(.text+0x869): undefined reference to
`mtlzm1zi1zi0zi2_ControlziMonadziErrorziClass_catchError_info'
ex14.o: In function `rF8_srt':
(.data+0x0): undefined reference to
`mtlzm1zi1zi0zi2_ControlziMonadziError_zdf17_closure'
ex14.o: In function `Main_main_srt':
(.data+0x6c): undefined reference to
`mtlzm1zi1zi0zi2_ControlziMonadziError_zdf17_closure'
collect2: ld returned 1 exit status
[mich...@localhost ~]$
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example code won't compile
nowgate: Why won't this code compile? [mich...@localhost ~]$ ghc ex14.hs -o ex14 Missing --make I'd also add -O2, but I'm like that. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example code won't compile
This example compiles fine without --make. What's the difference?
Michael
==
{- Author: Jeff Newbern
Maintainer: Jeff Newbern jnewb...@nomaware.com
Time-stamp: Wed Jul 2 18:11:36 2003
License: GPL
-}
{- DESCRIPTION
Example 13 - Using the List monad
Usage: Compile the code and execute the resulting program
with various arguments. Each argument will produce
a list of possible parses of the argument as a decimal
number, a hexadecimal number or a word.
Try: ./ex13 34 f3 bean
./ex13 food f00d
./ex13 beef 10 n!
./ex13 why? (punctuation)
-}
import Monad
import System
import Char
-- we can parse three different types of terms
data Parsed = Digit Integer | Hex Integer | Word String deriving Show
-- attempts to add a character to the parsed representation of a hex digit
parseHexDigit :: Parsed - Char - [Parsed]
parseHexDigit (Hex n) c = if isHexDigit c then
return (Hex ((n*16) + (toInteger (digitToInt c
else
mzero
parseHexDigit _ _ = mzero
-- attempts to add a character to the parsed representation of a decimal digit
parseDigit :: Parsed - Char - [Parsed]
parseDigit (Digit n) c = if isDigit c then
return (Digit ((n*10) + (toInteger (digitToInt c
else
mzero
parseDigit _ _ = mzero
-- attempts to add a character to the parsed representation of a word
parseWord :: Parsed - Char - [Parsed]
parseWord (Word s) c = if isAlpha c then
return (Word (s ++ [c]))
else
mzero
parseWord _ _ = mzero
-- tries to parse the digit as a hex value, a decimal value and a word
-- the result is a list of possible parses
parse :: Parsed - Char - [Parsed]
parse p c = (parseHexDigit p c) `mplus` (parseDigit p c) `mplus` (parseWord p c)
-- parse an entire String and return a list of the possible parsed values
parseArg :: String - [Parsed]
parseArg s = do init - (return (Hex 0)) `mplus` (return (Digit 0)) `mplus`
(return (Word ))
foldM parse init s
-- show the original string and all possible parses for the string
showResult :: String - IO ()
showResult s = do putStr s
putStr :
print (parseArg s)
-- prints possible parsed values for command-line arguments
main :: IO ()
main = do args - getArgs
mapM_ showResult args
-- END OF FILE
--- On Fri, 5/15/09, Lennart Augustsson lennart.augusts...@gmail.com wrote:
From: Lennart Augustsson lennart.augusts...@gmail.com
Subject: Re: [Haskell-cafe] Example code won't compile
To: michael rice nowg...@yahoo.com
Cc: haskell-cafe@haskell.org haskell-cafe@haskell.org
Date: Friday, May 15, 2009, 7:25 PM
--make
-- Lennart (iPhone)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
Conor McBride wrote: Rumblings about funny termination behaviour, equality for functions, and the complexity of unification (which isn't the proposal anyway) But unification is what you get by adding non-linearity. Sure, all terms are ground; would you prefer I said testing for membership in an element of the RATEG class? For more ickiness about RATEG, it's not closed under compliment and the emptiness problem is undecidable (so dead code elimination can't always work). Even restricting to the closed subset (aka tree-automata with (dis-)equality constraints) leaves emptiness undecidable, though there are a couple still more restricted classes that are decidable. cf ch.4 of TATA http://tata.gforge.inria.fr/ -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example code won't compile
The one important line is import Control.Monad.Error It adds dependancy on mtl package, which is not used by default (contrary to 'base' package, which includes Monad, System and IO modules). With --make GHC adds it automatically. Therefore $ ghc -package mtl ex14.hs compiles fine. I'd recommend using --make. In rare occasions when there is a namespace clash between packages one can simply hide offending packages or specify preferred ones. Best regards Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] conflicting variable definitions in pattern
Algebraic datatypes are built and unpacked with constructors. Pattern matching is just a way to use these constructors. This is distinct from the kind of unification/validation that happens in logic languages like Prolog. There is no special list constructor for when the first two items are equal. -- Jason Dusek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Example code won't compile
OK. Thanks, everyone. Michael --- On Fri, 5/15/09, Krzysztof Skrzętnicki gte...@gmail.com wrote: From: Krzysztof Skrzętnicki gte...@gmail.com Subject: Re: [Haskell-cafe] Example code won't compile To: michael rice nowg...@yahoo.com Cc: Lennart Augustsson lennart.augusts...@gmail.com, haskell-cafe@haskell.org haskell-cafe@haskell.org Date: Friday, May 15, 2009, 9:55 PM The one important line is import Control.Monad.Error It adds dependancy on mtl package, which is not used by default (contrary to 'base' package, which includes Monad, System and IO modules). With --make GHC adds it automatically. Therefore $ ghc -package mtl ex14.hs compiles fine. I'd recommend using --make. In rare occasions when there is a namespace clash between packages one can simply hide offending packages or specify preferred ones. Best regards Christopher Skrzętnicki ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.FiniteMap deprecrated
Hello, http://hackage.haskell.org/cgi-bin/hackage-scripts/package/FiniteMap ... since this is deprecated what is the orthodox way to implement finite map?? Thanks, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
