Re: [GHC] #3484: GHC diverges when proving nonequality of types
#3484: GHC diverges when proving nonequality of types -+-- Reporter: ryani |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.10.4 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonpj): * difficulty: = Unknown Comment: It's true that we have not explicitly thought about higher rank, but I'm still surprised at divergence. Let's leave this open and on the type- families list, so that we remember to get back to it. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3484#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
[GHC] #3490: Relax superclass restrictions
#3490: Relax superclass restrictions
---+
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone: _|_
Component: Compiler |Version: 6.10.4
Severity: minor | Keywords:
Difficulty: Unknown | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
---+
Doaitse points out that we currently reject
{{{
class C a b | a - b where
class C a b = D a where
}}}
on the grounds that 'b' is not in scope in the second class decl. (Only
type variables in the head, namely (D a), can be mentioned in the
superclass context.) My response to him was as follows.
The easiest way forward is to re-express your program using type
functions. Then class C will have just a single type parameter (a), with
the 'b' part being expressed by a type function. That would resolve the
problem rather nicely.
Medium term, I think the Right Thing is to allow a class declaration
{{{
class Q = C a b
}}}
(where Q is a context) if and only iff the type
{{{
forall ab. Q = C a b
}}}
is unambiguous. What does unambiguous mean? As it happens, we are
working on nailing that down right now. For example, here is a stupid but
unambiguous declaration:
{{{
type family F a
class (b ~ F a, Eq b) = C a
}}}
I do not know of any non-stupid examples that would be rejected by the
current rule, but there might be some.
I'll open a ticket because I'd like to get to this when we have the other
pieces working.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3490
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] #3491: Relax superclass restrictions
#3491: Relax superclass restrictions
---+
Reporter: simonpj | Owner:
Type: bug | Status: new
Priority: normal| Milestone: _|_
Component: Compiler |Version: 6.10.4
Severity: minor | Keywords:
Difficulty: Unknown | Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
---+
Doaitse points out that we currently reject
{{{
class C a b | a - b where
class C a b = D a where
}}}
on the grounds that 'b' is not in scope in the second class decl. (Only
type variables in the head, namely (D a), can be mentioned in the
superclass context.) My response to him was as follows.
The easiest way forward is to re-express your program using type
functions. Then class C will have just a single type parameter (a), with
the 'b' part being expressed by a type function. That would resolve the
problem rather nicely.
Medium term, I think the Right Thing is to allow a class declaration
{{{
class Q = C a b
}}}
(where Q is a context) if and only iff the type
{{{
forall ab. Q = C a b
}}}
is unambiguous. What does unambiguous mean? As it happens, we are
working on nailing that down right now. For example, here is a stupid but
unambiguous declaration:
{{{
type family F a
class (b ~ F a, Eq b) = C a
}}}
I do not know of any non-stupid examples that would be rejected by the
current rule, but there might be some.
I'll open a ticket because I'd like to get to this when we have the other
pieces working.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3491
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] #3492: Add TyThing - HsSyn translation code from Haddock
#3492: Add TyThing - HsSyn translation code from Haddock ---+ Reporter: simonmar | Owner: Type: task | Status: new Priority: normal| Milestone: 6.14.1 Component: Compiler |Version: 6.10.4 Severity: normal| Keywords: Difficulty: Unknown | Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple ---+ See attached; part of refactoring described in [wiki:Commentary/Compiler/TemplateHaskell]. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3492 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] #3490: Relax superclass restrictions
#3490: Relax superclass restrictions -+-- Reporter: simonpj |Owner: Type: bug | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by claus): This sounded familiar. See #714 . -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3490#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
[GHC] #3493: make install fails with error on rts/Config.h in HEAD
#3493: make install fails with error on rts/Config.h in HEAD
-+--
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 6.11 | Severity: normal
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
Using the package from
http://www.haskell.org/ghc/dist/current/dist/ghc-6.11.20090907-x86_64
-unknown-linux.tar.bz2
I think this is the symptom we need to find the cause of:
{{{
rts/package.conf.in:4: error: rts/Config.h: No such file or directory
}}}
Full log:
{{{
a1333...@dev2 ~/ghc-6.11.20090907
$ ./configure --prefix=$HOME
checking for path to top of build tree... /home/a1333478/ghc-6.11.20090907
checking for perl... /usr/bin/perl
checking if your perl works in shell scripts... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
checking for ar... /usr/bin/ar
checking whether /usr/bin/ar is GNU ar... yes
checking for ar arguments... q
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether ranlib is needed... no
checking for sed... /bin/sed
checking version of gcc... 4.1.2
checking how to run the C preprocessor... gcc -E
checking for extra options to pass gcc when compiling via C... -fwrapv
configure: creating ./config.status
config.status: creating extra-gcc-opts
config.status: creating mk/config.mk
config.status: creating mk/install.mk
Configuration done, ready to 'make install'
(see README and INSTALL files for more info.)
a1333...@dev2 ~/ghc-6.11.20090907
$ make install
make -r --no-print-directory -f ghc.mk install BINDIST=YES
NO_INCLUDE_DEPS=YES
/usr/bin/install -c -m 755 -d /home/a1333478/bin
rm -f
/home/a1333478/bin/ghci-6.11.20090907
create () { touch $1 chmod 755 $1 ; } create
/home/a1333478/bin/ghci-6.11.20090907
echo '#!/bin/sh'
/home/a1333478/bin/ghci-6.11.20090907
echo 'exec /home/a1333478/bin/ghc-6.11.20090907 --interactive ${1+$@}'
/home/a1333478/bin/ghci-6.11.20090907
chmod +x
/home/a1333478/bin/ghci-6.11.20090907
rm -f /home/a1333478/bin/ghci
ln -s ghci-6.11.20090907 /home/a1333478/bin/ghci
/usr/bin/install -c -m 755 -d /home/a1333478/lib/ghc-6.11.20090907
/usr/bin/install -c -m 755 -d /home/a1333478/lib/ghc-6.11.20090907/include
cp rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build
/libHSrts-ghc6.11.20090907.so rts/dist/build/libHSrts_l.a rts/dist/build
/libHSrts_debug-ghc6.11.20090907.so rts/dist/build/libHSrts_thr-
ghc6.11.20090907.so rts/dist/build/libHSrts_thr_debug-ghc6.11.20090907.so
rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a
rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a
rts/dist/build/libHSrtsmain.a /home/a1333478/lib/ghc-6.11.20090907
/usr/bin/install -c -m 755 -d /home/a1333478/bin
rm -f /home/a1333478/bin/haddock
create () { touch $1 chmod 755 $1 ; } create
/home/a1333478/bin/haddock
echo '#!/bin/sh'
/home/a1333478/bin/haddock
echo 'executablename=/home/a1333478/lib/ghc-6.11.20090907/haddock'
/home/a1333478/bin/haddock
echo 'datadir=/home/a1333478/share'
/home/a1333478/bin/haddock
echo 'bindir=/home/a1333478/bin'
/home/a1333478/bin/haddock
echo 'topdir=/home/a1333478/lib/ghc-6.11.20090907'
/home/a1333478/bin/haddock
cat utils/haddock/haddock.wrapper
/home/a1333478/bin/haddock
chmod +x /home/a1333478/bin/haddock
rm -f -r /home/a1333478/share/doc//html
/usr/bin/install -c -m 755 -d /home/a1333478/share/doc//html
cp -R utils/haddock/html /home/a1333478/share/doc//html
/usr/bin/install -c -m 755 -d /home/a1333478/bin
rm -f /home/a1333478/bin/hsc2hs
create () { touch $1 chmod 755 $1 ; } create
/home/a1333478/bin/hsc2hs
echo '#!/bin/sh'
/home/a1333478/bin/hsc2hs
echo 'executablename=/home/a1333478/lib/ghc-6.11.20090907/hsc2hs'
/home/a1333478/bin/hsc2hs
echo 'datadir=/home/a1333478/share'
Re: [GHC] #3490: Relax superclass restrictions
#3490: Relax superclass restrictions -+-- Reporter: simonpj |Owner: Type: bug | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: 6.10.4 Severity: minor | Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by simonpj): Dead right -- thanks. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3490#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] #783: SRTs bigger than they should be?
#783: SRTs bigger than they should be? -+-- Reporter: guest |Owner: Type: run-time performance bug | Status: new Priority: normal|Milestone: 6.14.1 Component: Compiler | Version: 6.4.2 Severity: normal| Resolution: Keywords: performance | Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * summary: performance problem compiling large file = SRTs bigger than they should be? * type: compile-time performance bug = run-time performance bug * milestone: 6.12.1 = 6.14.1 Comment: We should look at the SRTs in this example with the new code generator. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/783#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1136: High memory use when compiling many let bindings.
#1136: High memory use when compiling many let bindings. -+-- Reporter: igloo |Owner: simonmar Type: compile-time performance bug | Status: new Priority: high |Milestone: 6.12.1 Component: Compiler | Version: 6.6 Severity: normal| Resolution: Keywords: performance | Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * owner: = simonmar Comment: I'll take another look at this before 6.12.1. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1136#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3403: linear stack usage where constant stack usage expected
#3403: linear stack usage where constant stack usage expected
---+
Reporter: igloo |Owner:
Type: bug | Status: closed
Priority: normal |Milestone: 6.14.1
Component: Compiler| Version: 6.10.4
Severity: normal | Resolution: fixed
Keywords: | Difficulty: Unknown
Testcase: simplCore/should_run/T3403 | Os: Unknown/Multiple
Architecture: Unknown/Multiple|
---+
Changes (by simonpj):
* testcase: = simplCore/should_run/T3403
* status: new = closed
* resolution: = fixed
Comment:
Thanks for a fine bug report. It turned out that the CPR optimisation was
interacting badly with the code generated by pattern matching. Happily,
easy to fix.
{{{
Tue Sep 8 14:14:00 BST 2009 simo...@microsoft.com
* Fix Trac #3403: interaction of CPR and pattern-match failure
A fine bug report (#3403) demonstrated that we were losing the tail
call property when a complicated pattern match was involved. After
a bit of investigation I discovered that the culprit was the failure
join-point introduced by the pattern matcher. It was a zero-argument
thunk, which is not very CPR-friendly, and that interacted badly with
CPR worker/wrapper.
It's easy to fix, the same way that we fix other join points, by
supplying
a dummy argument (that is not really passed at runtime.
M ./compiler/deSugar/DsUtils.lhs -12 +25
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3403#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] #3468: GHC panic: boxy_match_s
#3468: GHC panic: boxy_match_s
+---
Reporter: wkahl|Owner:
Type: bug | Status: closed
Priority: normal |Milestone:
Component: Compiler | Version: 6.10.4
Severity: minor| Resolution: fixed
Keywords: boxy_match_s | Difficulty: Unknown
Testcase: typecheck/should_fail/T3468 | Os: Linux
Architecture: powerpc |
+---
Changes (by simonpj):
* testcase: = typecheck/should_fail/T3468
* difficulty: = Unknown
* status: new = closed
* resolution: = fixed
Comment:
The underlying problem is that the bit of code that compares the `hs-boot`
interface with the Real Truth gotten from the `.hs` file was forgetting to
compare the kinds of the `TyCon`s involved.
I've fixed that, so that this inconsistency won't happen again. Thank you
for reporting it
{{{
Tue Sep 8 14:03:50 BST 2009 simo...@microsoft.com
* Fix Trac #3468: improve checking for hs-boot interfaces
When checking the interface exported by a hs-boot file against the
Real Thing, I'd failed to check the kind of a type constructor. If you
get it wrong, the inconsistency leads to all manner of mischief, as
'wkahl' reports in #3468.
This patch should do the job.
M ./compiler/typecheck/TcRnDriver.lhs -38 +52
}}}
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3468#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] #2965: GHC on OS X does not compile 64-bit
#2965: GHC on OS X does not compile 64-bit +--- Reporter: Axman6 |Owner: thoughtpolice Type: feature request | Status: new Priority: normal |Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit| Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | +--- Comment (by simonmar): Ok, just to summarise the situation: * 6.10.4 needs a tiny fix to work with Snow Leopard: add `-optc-m32 -opta-m32 -optl-m32` to the script `/usr/bin/ghc`, or wherever ghc lives on your system. If there is a problem with TH, then please make a separate ticket. * The 32-bit OS X distribution of GHC 6.12.1 will work on Snow Leopard without modification. * A 64-bit port is being worked on by various people (see e.g. #3472; we will help with the porting effort) * 64-bit OS X is, for the time being, a Tier-2 platform. That means we expect the community to support it, with guidance from GHC HQ. We don't hold up releases for it. (this is moot since there isn't even a working port at this stage, but still). However, depending on how much extra work is involved and the demand, we'll consider upgrading it to Tier-1 in the future. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2965#comment:24 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] #3479: Build from source fails with variables passed to configure
#3479: Build from source fails with variables passed to configure -+-- Reporter: atler |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Build System | Version: 6.10.4 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * difficulty: = Unknown Comment: Ok, I claim that we should completely ignore `CFLAGS` and `LDFLAGS` settings. Does anyone disagree? GHC is not a C program: `CFLAGS` and `LDFLAGS` don't make sense here. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3479#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] #3495: make install DESTDIR= is failing in ghc HEAD
#3495: make install DESTDIR= is failing in ghc HEAD --+- Reporter: duncan| Owner: igloo Type: bug | Status: new Priority: normal| Milestone: Component: Build System |Version: 6.11 Severity: major | Resolution: Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple --+- Changes (by duncan): * owner: = igloo -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3495#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
[GHC] #3495: make install DESTDIR= is failing in ghc HEAD
#3495: make install DESTDIR= is failing in ghc HEAD
-+--
Reporter: duncan| Owner:
Type: bug | Status: new
Priority: normal| Component: Build System
Version: 6.11 | Severity: major
Keywords:| Testcase:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
-+--
`make install DESTDIR=$image` is failing currently with ghc HEAD. This is
the method distro packages use so it'll need fixing before 6.12.1.
The failing command is on the first instance of `ghc-cabal install` for
the libs:
{{{
inplace/bin/ghc-cabal install image/usr/... etc
ghc-cabal: ghc-pkg dump failed
}}}
Unfortunately, it does not give any more info if I pass `-v3`. That flag
seems to be swallowed rather than passed down.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3495
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] #3479: Build from source fails with variables passed to configure
#3479: Build from source fails with variables passed to configure -+-- Reporter: atler |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Build System | Version: 6.10.4 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Unknown/Multiple Architecture: Unknown/Multiple | -+-- Comment (by atler): Actually I found the cause for this issue. All passed variables had space at the end, for example CFLAGS=-O2 -fno-strict-aliasing -fwrapv -march=i686 which is stored in $CONFIGURE_ARGS as 'CFLAGS=-O2 -fno- strict-aliasing -fwrapv -march=i686 '. In mk/cabal-flags.mk $(space)' is used as a configure args separtor so it breaks in this case. I couldn't think of any simple solution to handle it (using only functions provided by make) but simple shell script would do the thing. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3479#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
[GHC] #3494: missing build system dependency
#3494: missing build system dependency -+-- Reporter: duncan| Owner: igloo Type: bug | Status: new Priority: normal| Component: Build System Version: 6.11 | Severity: minor Keywords:| Testcase: Os: Unknown/Multiple | Architecture: Unknown/Multiple -+-- The `inplace/bin/ghc-cabal` does not get rebuilt automatically if the Cabal sources change. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3494 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: simonmar Type: bug | Status: new Priority: normal|Milestone: 6.12.1 Component: Runtime System| Version: 6.10.4 Severity: normal| Resolution: Keywords:| Difficulty: Unknown Testcase:| Os: Windows Architecture: Unknown/Multiple | -+-- Changes (by simonmar): * status: reopened = new * owner: igloo = simonmar * milestone: 6.10.4 = 6.12.1 Comment: We need to look at this before 6.12.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3231#comment:26 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] #2965: GHC on OS X does not compile 64-bit
#2965: GHC on OS X does not compile 64-bit +--- Reporter: Axman6 |Owner: thoughtpolice Type: feature request | Status: new Priority: normal |Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit| Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | +--- Comment (by simonpj): Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: * MacOS is already in one Tier-1 platform (32 bit) * x86_64 is already in another Tier-1 platform (Linux) All we need to do is to put the two together -- and some folk are already working on that (#3472). But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2965#comment:25 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] #2965: GHC on OS X does not compile 64-bit
#2965: GHC on OS X does not compile 64-bit +--- Reporter: Axman6 |Owner: thoughtpolice Type: feature request | Status: new Priority: normal |Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit| Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | +--- Comment (by pumpkin): Replying to [comment:25 simonpj]: Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: * MacOS is already in one Tier-1 platform (32 bit) * x86_64 is already in another Tier-1 platform (Linux) All we need to do is to put the two together -- and some folk are already working on that (#3472). But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) Simon I would definitely be willing to co-maintain this with someone else, but as a relative newcomer to Haskell and GHC (who hasn't even succeeded in making an unregistered build for this platform yet) I don't think I'd be suitable as a sole maintainer. Any experts out there who'd be willing to help? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2965#comment:26 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] #2965: GHC on OS X does not compile 64-bit
#2965: GHC on OS X does not compile 64-bit +--- Reporter: Axman6 |Owner: thoughtpolice Type: feature request | Status: new Priority: normal |Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit| Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | +--- Comment (by geekiac): Replying to [comment:26 pumpkin]: I too would be happy to help to maintain this, however, I am also a relative newbie and would need assistance. If someone could point me in the right direction, I am a fast learner Replying to [comment:25 simonpj]: Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: * MacOS is already in one Tier-1 platform (32 bit) * x86_64 is already in another Tier-1 platform (Linux) All we need to do is to put the two together -- and some folk are already working on that (#3472). But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) Simon I would definitely be willing to co-maintain this with someone else, but as a relative newcomer to Haskell and GHC (who hasn't even succeeded in making an unregistered build for this platform yet) I don't think I'd be suitable as a sole maintainer. Any experts out there who'd be willing to help? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2965#comment:27 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] #3496: GHC panic while building the base library with Cabal
#3496: GHC panic while building the base library with Cabal
-+--
Reporter: elliottt | Owner:
Type: bug | Status: new
Priority: normal| Component: Compiler
Version: 6.10.4| Severity: major
Keywords:| Testcase:
Os: Linux | Architecture: Unknown/Multiple
-+--
On a project here, we are building a custom version of ghc. Part of our
build process involves building the base library with Cabal, which
produces the following error message:
{{{
[ 57 of 128] Compiling Data.Either ( Data/Either.hs,
dist/build/Data/Either.o )
[ 58 of 128] Compiling System.IO.Error ( System/IO/Error.hs,
dist/build/System/IO/Error.o )
[ 59 of 128] Compiling Text.Read( Text/Read.hs,
dist/build/Text/Read.o )
[ 60 of 128] Compiling Foreign.Ptr ( Foreign/Ptr.hs,
dist/build/Foreign/Ptr.o )
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for x86_64-unknown-linux):
tcIfaceGlobal (local): not found:
base:GHC.Word.W#{d 6w}
[(32R, Type constructor `base:GHC.Word.Word{tc 32R}'),
(32U, Type constructor `base:GHC.Word.Word8{tc 32U}'),
(32X, Type constructor `base:GHC.Word.Word16{tc 32X}'),
(333, Type constructor `base:GHC.Word.Word32{tc 333}'),
(339, Type constructor `base:GHC.Word.Word64{tc 339}'),
(r1ujj, Data constructor `base:GHC.Word.W64#{d r1ujj}'),
(r1ujl, Data constructor `base:GHC.Word.W32#{d r1ujl}'),
(r1ujn, Data constructor `base:GHC.Word.W16#{d r1ujn}'),
(r1ujp, Data constructor `base:GHC.Word.W8#{d r1ujp}'),
(r1ujr, Data constructor `base:GHC.Word.W#{d r1ujr}'),
}}}
The command that Cabal generated was this:
{{{
/usr/bin/ghc -package-name base-4.1.0.0 --make -hide-all-packages -i
-idist/build -i. \
-idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP-
include \
-optPdist/build/autogen/cabal_macros.h -#include HsBase.h -odir
dist/build \
-hidir dist/build -stubdir dist/build -package ghc-prim-0.1.0.0 -package
integer-0.1.0.1 \
-package rts-1.0 -O -package-name base -XMagicHash
-XExistentialQuantification -XRank2Types \
-XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface
-XUnliftedFFITypes \
-XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances
-XStandaloneDeriving \
-XPatternGuards -XEmptyDataDecls -XCPP Foreign.Concurrent GHC.Arr GHC.Base
GHC.Classes GHC.Conc \
GHC.ConsoleHandler GHC.Desugar GHC.Enum GHC.Environment GHC.Err
GHC.Exception GHC.Exts GHC.Float \
GHC.ForeignPtr GHC.Handle GHC.IO GHC.IOBase GHC.Int GHC.List GHC.Num
GHC.PArr GHC.Pack GHC.Ptr \
GHC.Read GHC.Real GHC.ST GHC.STRef GHC.Show GHC.Stable GHC.Storable
GHC.TopHandler GHC.Unicode \
GHC.Weak GHC.Word System.Timeout Control.Applicative Control.Arrow
Control.Category \
Control.Concurrent Control.Concurrent.Chan Control.Concurrent.MVar
Control.Concurrent.QSem \
Control.Concurrent.QSemN Control.Concurrent.SampleVar Control.Exception
Control.Exception.Base \
Control.OldException Control.Monad Control.Monad.Fix
Control.Monad.Instances Control.Monad.ST \
Control.Monad.ST.Lazy Control.Monad.ST.Strict Data.Bits Data.Bool
Data.Char Data.Complex \
Data.Dynamic Data.Either Data.Eq Data.Data Data.Fixed Data.Foldable
Data.Function Data.HashTable \
Data.IORef Data.Int Data.Ix Data.List Data.Maybe Data.Monoid Data.Ord
Data.Ratio Data.STRef \
Data.STRef.Lazy Data.STRef.Strict Data.String Data.Traversable Data.Tuple
Data.Typeable \
Data.Unique Data.Version Data.Word Debug.Trace Foreign Foreign.C
Foreign.C.Error \
Foreign.C.String Foreign.C.Types Foreign.ForeignPtr Foreign.Marshal
Foreign.Marshal.Alloc \
Foreign.Marshal.Array Foreign.Marshal.Error Foreign.Marshal.Pool
Foreign.Marshal.Utils \
Foreign.Ptr Foreign.StablePtr Foreign.Storable Numeric Prelude
System.Console.GetOpt \
System.CPUTime System.Environment System.Exit System.IO System.IO.Error
System.IO.Unsafe \
System.Info System.Mem System.Mem.StableName System.Mem.Weak
System.Posix.Internals \
System.Posix.Types Text.ParserCombinators.ReadP
Text.ParserCombinators.ReadPrec Text.Printf \
Text.Read Text.Read.Lex Text.Show Text.Show.Functions Unsafe.Coerce
}}}
I noticed that if I remove the -O from the command that cabal generated,
and rebuild after cleaning and re-configuring, the problem goes away.
However, if I clean, reconfigure and use the command that Cabal generated,
I get the same build error.
This bug has been seen on x86 and x86_64 Linux installs.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3496
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
Re: [GHC] #2965: GHC on OS X does not compile 64-bit
#2965: GHC on OS X does not compile 64-bit +--- Reporter: Axman6 |Owner: thoughtpolice Type: feature request | Status: new Priority: normal |Milestone: 6.12 branch Component: Compiler | Version: Severity: normal | Resolution: Keywords: 64bit| Difficulty: Unknown Testcase: | Os: MacOS X Architecture: x86_64 (amd64) | +--- Comment (by axman6): It's my ticket, so i guess i could take some responsibility. I'm not sure how useful I could be, or how much time i could spend, at least not until the summer holidays here (December to February). I've also never looked into GHC's source, so I'd probably need help too. So anyway, sign me up as co-maintainer, and i'll see how i can help when I have time. I'd also like to say thanks to everyone for the recent activity regarding this ticket. With Snow Leopard being the first Mac OS favouring 64-bit over 32, I think it's important that GHC move that way, so it doesn't feel left behind on the system. Replying to [comment:26 pumpkin]: Replying to [comment:25 simonpj]: Just to add: what we would really like is for someone to step forward as the Maintainer of the X86_64 MacOS port of GHC. Then we really could make it a Tier-1 platform (see http://hackage.haskell.org/trac/ghc/wiki/Platforms). In principle its not hard: * MacOS is already in one Tier-1 platform (32 bit) * x86_64 is already in another Tier-1 platform (Linux) All we need to do is to put the two together -- and some folk are already working on that (#3472). But for us to sign up to Tier-1-ness, we need someone (or a small group) to sign up to being the maintainers. (Ben recently volunteered to be the maintainer for Sparc; thanks Ben.) Simon I would definitely be willing to co-maintain this with someone else, but as a relative newcomer to Haskell and GHC (who hasn't even succeeded in making an unregistered build for this platform yet) I don't think I'd be suitable as a sole maintainer. Any experts out there who'd be willing to help? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2965#comment:28 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 --help displays obsolete URL
On 05/09/2009 17:38, Phil Dennis wrote: Or... someone could put the URL back up as a redirect to the current location of the documentation :) Done. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: no backspace, delete or arrow keys in ghci
On Mon, 2009-09-07 at 11:24 -0700, Judah Jacobson wrote: I'm not sure I understand. Are you saying that you can't use backspace/arrows/etc when the getLine command itself is waiting for input? But otherwise at the Prelude prompt, where you type in the commands, everything behaves fine? If so, that is normal behavior for the getLine function. For what it's worth, while ghci has behaved this way for a long time (since at least 6.4), hugs seems to work more nicely in this regard. In hugs when you getLine it seems to switch into cooked mode so you at least get backspace etc. Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Last Call for Papers: VSTTE 2009
* * * * VSTTE 2009 * * * *Workshop on Verified Software * *Theory Tools and Experiments * * * *(affiliated with Formal Methods Week) * * * * November 2, 2009* * Eindhoven, the Netherlands * *http://vstte09.lri.fr/ * * * *Deadline for submissions: Sep 11, 2009* * * * FM 2009 is the sixteenth in a series of symposia of the Formal Methods Europe association, and the second one that is organized as a world congress. Ten years after FM'99, the 1st World Congress, the formal methods communities from all over the world will once again have an opportunity to meet. FM 2009 will be both an opportunity to celebrate, and an opportunity to join in when enthusiastic researchers and practitioners from a diversity of backgrounds and schools come together to discuss their ideas and experiences. The workshop on Verified Software: Theories, Tools, and Experiments (VSTTE 2009) will take place on November the 2nd. The focus of this workshop will be on tools, as previous VSTTE conferences in Zurich and Toronto emphasised theories and experiments. Consisting of contributed papers and invited talks, the workshop will focus on the tools behind the development of systematic methods for specifying, building, and verifying high-quality software. This includes topics like: * Program logic * Specification and verification techniques * Tool support for specification languages * Tool for various design methodologies * Tool integration and plug-ins * Automation in formal verification * Tool comparisons and benchmark repositories * Combination of tools and techniques (e.g. formal vs. semiformal, software specification vs. engineering techniques) * Customizing tools for particular applications Papers about tool architectures, and their achievements are most welcome. The contributed papers, which should report on previously unpublished work, can reflect current and preliminary work in areas of software verification. New technical results, overviews of new developments in software verification projects, short papers accompanying tool demonstrations, as well as position papers on how to further advance the goal of verified software are all welcome. SUBMISSION PROCEDURE VSTTE proceedings will be published as a special issue of the Software Tools for Technology Transfer (STTT) journal. Submitted papers should not have been submitted elsewhere for publication. Papers should use Springer-Verlag's STTT package ftp://ftp.springer.de/pub/tex/latex/svjour/sttt/, and should not exceed 15 pages including appendices. Papers are processed through the EasyChair conference management system. IMPORTANT DATES === Submission deadline September 11, 2009, 11:59pm Samoa time (UTC-11) Notification of acceptance October 2, 2009 Final version October 16, 2009 PROGRAM COMMITTEE = * David Deharbe, Dimap UFRN, Brazil * Dino Distefano, Queen Mary University of London, UK * Jean-Christophe Filliâtre (co-chair), CNRS, France * Leo Freitas (co-chair), University of York, UK * John McDermott, Naval Research Laboratory, USA * Yannick Moy, AdaCore, France * Arnaud Venet, Kestrel Technology, USA CONTACT === Leo Freitas, l...@cs.york.ac.uk Department of Computer Science University of York, YO10 5DD York, UK Tel: (+44) (0) 1904 434753 Jean-Christophe Filliatre, jean-christophe.fillia...@lri.fr CNRS / INRIA Saclay - Ile-de-france - ProVal Parc Orsay Universite, batiment N 4, rue Jacques Monod 91893 Orsay Cedex FRANCE Tel: (+33) (0)1 74 85 42 27 FURTHER INFORMATION === Further information will be put on the workshop web-page http://vstte09.lri.fr/. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CfPart: FMICS 2009, 2-3 November 2009
FMICS 2009 - FIRST CALL FOR PARTICIPATION Please visit: http://users.dsic.upv.es/workshops/fmics2009 * 14th International Workshop on * * Formal Methods for Industrial Critical Systems * * FMICS 2009 * * * * November 2-3, 2009 * * Eindhoven, The Netherlands * * ** NEWS ** * * * * Full programme for FMICS 2009 now available* * * * Registration for FMICS 2009 is open* * Early registration before September 14 * * * * FMICS 2009 proceedings available as LNCS 5825 * * * FMICS 2009 is the fourteenth in a series of International Workshop on Formal Methods for Industrial Critical Systems. Previous workshops of the ERCIM working group on Formal Methods for Industrial Critical Systems were held in Oxford (March 1996), Cesena (July 1997), Amsterdam (May 1998), Trento (July 1999), Berlin (April 2000), Paris (July 2001), Malaga (July 2002), Trondheim (June 2003), Linz (September 2004), Lisbon (September 2005), Bonn (August 2006), Berlin (July 2007), and L'Aquila (September 2008). The aim of the FMICS workshop series is to provide a forum for researchers who are interested in the development and application of formal methods in industry. In particular, these workshops bring together scientists and engineers who are active in the area of formal methods and are interested in exchanging their experiences in the industrial usage of these methods. These workshops also strive to promote research and development for the improvement of formal methods and tools for industrial applications. Complete and up to date information can be found at the event website http://users.dsic.upv.es/workshops/fmics2009/. FMICS 2009 is part of the 1st FMweek (Formal Methods week, http://www.win.tue.nl/fmweek/), which brings together 10 international scientific events, 6 project and working group meetings, and a variety of other activities in the area. Further information about the FMICS working group and the next FMICS workshop can be found at: http://www.inrialpes.fr/vasy/fmics. The topics chosen for FMICS 2009 include: - design, specification, code generation and testing based on formal methods; - methods, techniques and tools to support automated analysis, certification, debugging, learning, optimization and transformation of complex, distributed, real-time and embedded systems; - verification and validation methods that address shortcomings of existing methods with respect to their industrial applicability (e.g., scalability and usability issues); - tools for the development of formal design descriptions; - case studies and experience reports on industrial applications of formal methods, focusing on lessons learned or new research directions; - impact and costs of the adoption of formal methods; - application of formal methods in standardization and industrial forums; In response to the call for papers, 24 contributions were submitted from 16 different countries. The Program Committee selected ten papers, basing this choice on their scientific quality, originality, and relevance to the workshop. Each paper was reviewed by at least three Program Committee members or external referees. The programme also includes four invited contributions as well as six poster descriptions. INVITED SPEAKERS Dino Distefano Queen Mary, University of London, UK Diego LatellaCNR/ISTI, Italy Thierry Lecomte ClearSy, France Ken McMillan Cadence Berkeley Labs, USA Following a tradition established over the past few years, the European Association of Software Science and Technology (EASST) will offer an award to the best FMICS paper. VENUE - The venue for FMICS 2009 is the Auditorium of Eindhoven University of Technology. The university campus lies in the centre of Eindhoven, within walking distance of conference hotels. The city itself can easily be reached via both its own airport and Schiphol (the Dutch mainport). REGISTRATION The event website provides a one-stop window where participants can register to FMICS 2009 and to any combination of FMweek events they would like
Re: [Haskell] Looking for a new HWN editor
On Sat, 5 Sep 2009 19:34:24 -0400, Brent Yorgey byor...@seas.upenn.edu wrote: On Sat, Sep 05, 2009 at 05:26:08PM -0400, Brent Yorgey wrote: Executive summary: * I'm looking for someone to take over as HWN editor * It is highly automated and doesn't take as much time as you might think (about 3-4 hours/week on average) * You DON'T need to be a Haskell guru * It is far from a thankless job and is a fun way to provide an appreciated service to the community! The position has been filled! More details to come. Wow! That was a quick decision! Most Haskell users probably didn't even have time to read the announcement before the position was filled; I certainly did not. Well, since this position has already been filled, there's probably not much that can be done (other than ask the new editor and hope that he/she is understanding), but just to give a fair opportunity to all Haskell users, if the editor changes again, it may be helpful at least to give everybody an opportunity to read the announcement and apply for the position. Just my two cents -- 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] Ph.D position, Utrecht University, the Netherlands
=== Vacancy PhD student on Realizing Optimal Sharing in the Functional Language Implementations Utrecht University, The Netherlands. === Within the Software Technology group of the Information and Computing Sciences department of Utrecht University there is a vacancy for a PhD student to work on the efficient implementation of functional languages. The position is funded by NWO, the Netherlands Organization for Scientific Research. - Project summary: Lambda-calculus and term rewriting are models of computation lying at the basis of functional programming languages. Both possess syntactic meta-theories based on analyzing rewrite steps. Unfortunately, naive implementations are inefficient, since subterms are frequently copied. To overcome this problem in both theoretical systems and actual implementations, duplicate work is avoided by using graph-based term representations, in which identical subterms can be (but not always are) shared. The question arises whether graph-representations and their reductions that are optimal in a theoretical sense can also be practical from an implementer's point of view. However, so far it is unclear whether nice theoretical ideas combine well with existing implementation methods. The overall-goal of this project is to answer this question in a back-and-forth communication between theoretical concepts and practical realizations. Starting points are the recent work on the optimal Lambdascope implementation based on context sharing, and the Haskell implementation developed at Utrecht University. One of the open problems is whether the Lambdascope framework can be extended to efficiently represent sets of mutually recursive definitions. Another, whether global program analysis can discover where Lambdascope-based approaches solve problems due to insufficient sharing. If both questions can be solved, we want to combine Lambdascope-based implementations with conventional frameworks, and investigate how efficient the resulting implementations become. The unique combination of the theoretical depth from the Logic department and the implementation skills and compiler infrastructure from the Computer Science department make Utrecht University the optimal surroundings for such a project. - Project leaders are Prof.dr. Doaitse Swierstra and dr. Vincent van Oostrom (principal investigator). The project will be executed in close cooperation between * the Software Technology group (http://www.cs.uu.nl/wiki/Center) of the Information and Computing Sciences department (http://www.cs.uu.nl/ ) * and the Theoretical Philosophy group (http://www.uu.nl/EN/faculties/Humanities/research/researchinstitutes/zeno/research/theoreticalphilosophy/Pages/default.aspx ) of the Philosophy department (http://www.phil.uu.nl/), and between * the more practically oriented PhD student and * the more theory oriented postdoc. - Requirements: Master degree in Computer Science, Logic, or equivalent. Good knowledge of functional programming, and several advanced computer science techniques. Knowledge of lambda-calculus implementations, Haskell, and compiler construction will be useful. Both theory and software development based on this should appeal to you. Terms of employment: the PhD student should start as soon as possible, but no later than January 1, 2010. The position is for four years (after one year there will be an evaluation), full-time. Gross salary starts with € 2042,-- per month in the first year and increases to € 2612,-- in the fourth year of employment. The salary is supplemented with a holiday bonus of 8% and an end-of-year bonus of 3%. In addition we offer: a pension scheme, partially paid parental leave, facilities for child care, flexible employment conditions in which you may trade salary for vacation days or vice versa. Conditions are based on the Collective Employment Agreement of the Dutch Universities: http://www.vsnu.nl/Workstudy/Universities-as-employers-/Collective-Labour-Agreement.htm More information: * about the project can be found on http://www.cs.uu.nl/wiki/bin/view/Center/OptimalSharing * about the Software Technology group on http://www.cs.uu.nl/wiki/Center * about the Information and Computing Sciences department on http://www.cs.uu.nl/ * about this vacancy can be obtained from Doaitse Swierstra (doai...@cs.uu.nl , +31 6 4613 6929). Send your application in pdf (or another non-proprietary format) to mailto:sciencep...@uu.nl with a cc to mailto:doai...@cs.uu.nl. on or before Sept 31,
[Haskell] ANNOUNCE: uvector-algorithms 0.2
Greetings, It is my pleasure to announce version 0.2 of the uvector-algorithms package. The package so far has implementations of several sorting and selection algorithms for use on the mutable arrays from the uvector library, as well as combinators for applying them to immutable arrays. New developments in this version include: - A simple benchmarking program for testing the performance of the algorithms (it's what I use to measure them, but I only have one computer to run it on, so perhaps other folks might want to see how it works on their machine) - A testing program, written with quick check to verify properties of the algorithms - Several bugs found and fixed due to the above tests and using HPC to verify good program coverage - Combinators for Schwartzian transform - Reworking radix sort to be more amenable to optimization. It's now around twice as fast. - A Radix instance for strict pairs, and a radix sortBy - Merge sort is now slightly faster due to memcpy in uvector :) The library can be found at hackage: http://hackage.haskell.org/package/uvector-algorithms or in its darcs repository: http://code.haskell.org/~dolio/uvector-algorithms/ As always, I can be notified of any issues. Enjoy. -- Dan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Deconstructing types
I don't know a thing about SYB, Data.Data, or Data.Typeable, mostly because I'm an efficiency fanatic. Nevertheless, I'd like to know whether or not there's a way to deconstruct a (mostly) arbitrary type, into tuples, unions, etc. using this framework. Any thoughts? You can use the Template Haskell deriving in EMGM to get that structure pretty efficiently. http://www.cs.uu.nl/wiki/GenericProgramming/EMGM http://hackage.haskell.org/package/emgm The obligatory question is: why do you want it? Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: hmatrix on os x
Ben wrote: i've been having a heck of a time installing hmatrix on mac os x. i've seen the help pages including http://mit.edu/harold/Public/easyVisionNotes.html but they haven't helped me. my setup is haskell platform 2009.2.0.2 (ghc 6.10.4) os x 10.5 macports -- i've tried installing gsl and gsl-devel to no avail. i've tried cabal install with various options, to no avail. has anyone else have luck with this? Lapack and Gsl (or something combination thereof, I don't remember) is installed on MacOS X by default, but it's a framework called vecLib . You have to add ld-options: -framework vecLib to the hmatrix.cabal file and possibly remove the other library flags. I suggest nagging the maintainer about this. (Also, I had to remove and Intel specific opcode when compiling on PowerPC.) Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Looking for a new HWN editor
I'd just like to say a big Thank you to Brent for his service as the HWN editor. I appreciate it very much and always look forward to HWN. Thanks for all your work, Brent. Cheers, John Message: 11 Date: Sat, 5 Sep 2009 17:26:08 -0400 From: Brent Yorgey byor...@seas.upenn.edu Subject: [Haskell-cafe] Looking for a new HWN editor Hi all, As you probably know, I've been the editor of the Haskell Weekly News for a little over a year now, and I've decided that it's time for me to move on to other things. So, I'm looking for someone to volunteer to take over as HWN editor. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Failure to build curl bindings on alpha
Hi all, I am the Debian Maintainer of the haskell curl bindings which is failing to build on the alpha CPU with the following error: [7 of 8] Compiling Network.Curl.Easy ( Network/Curl/Easy.hs, dist/build/Network/Curl/Easy.o ) Network/Curl/Easy.hs:218:0: On Alpha, I can only handle 32 bytes of non-floating-point arguments to foreign export dynamic When checking declaration: foreign import ccall safe wrapper mkProgress :: ProgressFunction - IO (FunPtr ProgressFunction) Network/Curl/Easy.hs:221:0: On Alpha, I can only handle 32 bytes of non-floating-point arguments to foreign export dynamic When checking declaration: foreign import ccall safe wrapper mkDebugFun :: DebugFunctionPrim - IO (FunPtr DebugFunctionPrim) The GHC version is 6.10.4 and the full Debian build log is here: https://buildd.debian.org/fetch.cgi?pkg=haskell-curlver=1.3.5-2arch=alphastamp=1249232593file=log I am correct to suspect that this is a bug in ghc rather than in haskell-curl? Any other useful clues or information? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] High memory consumption of print
The following toy program consumes either 25MB or 70MB, depending on whether the line print done is a comment or code. (Using only 1 OS thread increases memory consumption to 130MB when the print is active vs 25MB when inactive.) What am I doing wrong? - module Main where import Control.Concurrent import Control.Concurrent.STM import Control.Concurrent.STM.TChan import System.Environment import Control.Applicative main = do n - read . head $ getArgs tvar - newTVarIO 0 tchan - newTChanIO tids - sequence [ forkIO (test tchan tvar i) | i - [1..10^n] ] waitForAll tchan $! length tids where waitForAll _ 0 = return () waitForAll tchan len = do atomically $ readTChan tchan waitForAll tchan (len-1) test :: TChan () - TVar Int - Int - IO () test tchan tvar i = do atomically $ do val - readTVar tvar if val+1 == i then do writeTVar tvar i writeTChan tchan () else retry print done - ghc --make -O2 teststm.hs -threaded ./teststm 4 +RTS -sstderr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Looking for a new HWN editor
On Sat, 5 Sep 2009 19:34:24 -0400, Brent Yorgey byor...@seas.upenn.edu wrote: On Sat, Sep 05, 2009 at 05:26:08PM -0400, Brent Yorgey wrote: Executive summary: * I'm looking for someone to take over as HWN editor * It is highly automated and doesn't take as much time as you might think (about 3-4 hours/week on average) * You DON'T need to be a Haskell guru * It is far from a thankless job and is a fun way to provide an appreciated service to the community! The position has been filled! More details to come. Wow! That was a quick decision! Most Haskell users probably didn't even have time to read the announcement before the position was filled; I certainly did not. Well, since this position has already been filled, there's probably not much that can be done (other than ask the new editor and hope that he/she is understanding), but just to give a fair opportunity to all Haskell users, if the editor changes again, it may be helpful at least to give everybody an opportunity to read the announcement and apply for the position. Just my two cents -- 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-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal install on Windows 7
I tried the cabal install command on Windows 7, and I had to run it with administrative privileges, otherwise I got access denied (it failed to create the Haskell folder in C:\Program Files) Not sure if this is also the case on Vista. Is this the intended behavior? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal install on Windows 7
On Tue, Sep 8, 2009 at 9:17 AM, Peter Verswyvelenbugf...@gmail.com wrote: Ouch, right, I forgot the default is global. It works fine with cabal install --user. And of course I could have edited the default config file, setting user-install: True Well, maybe for newbies this might be a bit confusing. Yep, I agree. I'm not sure why Cabal defaults to --global on Windows, but I found it quite counter-intuitive having come from a Linux environment. I forgot about the different default for some time. Jeff Wheeler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal install on Windows 7
Ouch, right, I forgot the default is global. It works fine with cabal install --user. And of course I could have edited the default config file, setting user-install: True Well, maybe for newbies this might be a bit confusing. Typically, under Windows Vista or 7 when you try to install something that requires admin rights, you get a popup window asking if it's okay to do so. Would be great to have this support built into Cabal? On Tue, Sep 8, 2009 at 3:45 PM, John Van Enkvane...@gmail.com wrote: Might it make sense to try and get the concept of global and user working in Windows? (It may already, but I noticed that the default seems to be global.) I don't know what technical challenges there are, but the ApplicationData directory (or AppData, or whatever) seems like a good place to stick user cabal packages. /jve On Tue, Sep 8, 2009 at 9:31 AM, Peter Verswyvelen bugf...@gmail.com wrote: I tried the cabal install command on Windows 7, and I had to run it with administrative privileges, otherwise I got access denied (it failed to create the Haskell folder in C:\Program Files) Not sure if this is also the case on Vista. Is this the intended behavior? ___ 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] Ph.D position, Utrecht University, the Netherlands
Subject: Ph.D position, Utrecht University, the Netherlands === Vacancy PhD student on Realizing Optimal Sharing in the Functional Language Implementations Utrecht University, The Netherlands. === Within the Software Technology group of the Information and Computing Sciences department of Utrecht University there is a vacancy for a PhD student to work on the efficient implementation of functional languages. The position is funded by NWO, the Netherlands Organization for Scientific Research. - Project summary: Lambda-calculus and term rewriting are models of computation lying at the basis of functional programming languages. Both possess syntactic meta-theories based on analyzing rewrite steps. Unfortunately, naive implementations are inefficient, since subterms are frequently copied. To overcome this problem in both theoretical systems and actual implementations, duplicate work is avoided by using graph-based term representations, in which identical subterms can be (but not always are) shared. The question arises whether graph-representations and their reductions that are optimal in a theoretical sense can also be practical from an implementer's point of view. However, so far it is unclear whether nice theoretical ideas combine well with existing implementation methods. The overall-goal of this project is to answer this question in a back-and-forth communication between theoretical concepts and practical realizations. Starting points are the recent work on the optimal Lambdascope implementation based on context sharing, and the Haskell implementation developed at Utrecht University. One of the open problems is whether the Lambdascope framework can be extended to efficiently represent sets of mutually recursive definitions. Another, whether global program analysis can discover where Lambdascope-based approaches solve problems due to insufficient sharing. If both questions can be solved, we want to combine Lambdascope-based implementations with conventional frameworks, and investigate how efficient the resulting implementations become. The unique combination of the theoretical depth from the Logic department and the implementation skills and compiler infrastructure from the Computer Science department make Utrecht University the optimal surroundings for such a project. - Project leaders are Prof.dr. Doaitse Swierstra and dr. Vincent van Oostrom (principal investigator). The project will be executed in close cooperation between * the Software Technology group (http://www.cs.uu.nl/wiki/Center) of the Information and Computing Sciences department (http://www.cs.uu.nl/ ) * and the Theoretical Philosophy group (http://www.uu.nl/EN/faculties/Humanities/research/researchinstitutes/zeno/research/theoreticalphilosophy/Pages/default.aspx ) of the Philosophy department (http://www.phil.uu.nl/), and between * the more practically oriented PhD student and * the more theory oriented postdoc. - Requirements: Master degree in Computer Science, Logic, or equivalent. Good knowledge of functional programming, and several advanced computer science techniques. Knowledge of lambda-calculus implementations, Haskell, and compiler construction will be useful. Both theory and software development based on this should appeal to you. Terms of employment: the PhD student should start as soon as possible, but no later than January 1, 2010. The position is for four years (after one year there will be an evaluation), full-time. Gross salary starts with € 2042,-- per month in the first year and increases to € 2612,-- in the fourth year of employment. The salary is supplemented with a holiday bonus of 8% and an end-of-year bonus of 3%. In addition we offer: a pension scheme, partially paid parental leave, facilities for child care, flexible employment conditions in which you may trade salary for vacation days or vice versa. Conditions are based on the Collective Employment Agreement of the Dutch Universities: http://www.vsnu.nl/Workstudy/Universities-as-employers-/Collective-Labour-Agreement.htm More information: * about the project can be found on http://www.cs.uu.nl/wiki/bin/view/Center/OptimalSharing * about the Software Technology group on http://www.cs.uu.nl/wiki/Center * about the Information and Computing Sciences department on http://www.cs.uu.nl/ * about this vacancy can be obtained from Doaitse Swierstra (doai...@cs.uu.nl , +31 6 4613 6929). Send your application in pdf (or another non-proprietary format) to mailto:sciencep...@uu.nl
[Haskell-cafe] Re: ANNOUNCE: dbmigrations 0.1
Jonathan == Jonathan Daugherty drcyg...@gmail.com writes: Jonathan This package is motivated by the need for a Jonathan framework-independent, solid tool to manage database schema Jonathan changes in a clean way without assuming a linear sequence of Jonathan changes assumed by existing tools. dbmigrations lets you Jonathan manage a forest of schema changes. Thank you for this package! It is something which Haskell community was really missing. Looking forward to make use of it. Sincerely, Gour -- Gour | Hlapičina, Croatia | GPG key: F96FF5F6 --- pgpJMBa0bOcUK.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Looking for a new HWN editor
On Tue, Sep 8, 2009 at 8:16 AM, Benjamin L.Russelldekudekup...@yahoo.com wrote: On Sat, 5 Sep 2009 19:34:24 -0400, Brent Yorgey byor...@seas.upenn.edu wrote: On Sat, Sep 05, 2009 at 05:26:08PM -0400, Brent Yorgey wrote: Executive summary: * I'm looking for someone to take over as HWN editor * It is highly automated and doesn't take as much time as you might think (about 3-4 hours/week on average) * You DON'T need to be a Haskell guru * It is far from a thankless job and is a fun way to provide an appreciated service to the community! The position has been filled! More details to come. Wow! That was a quick decision! Most Haskell users probably didn't even have time to read the announcement before the position was filled; I certainly did not. Well, since this position has already been filled, there's probably not much that can be done (other than ask the new editor and hope that he/she is understanding), but just to give a fair opportunity to all Haskell users, if the editor changes again, it may be helpful at least to give everybody an opportunity to read the announcement and apply for the position. Just my two cents I don't think that's really necessary. I suppose there's no reason for more people to be editors if the demand is high. It could even eventually have its own articles and perhaps and bigger summaries about the threads. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Deconstructing types
Sean, The answer is, I'm working on a recently semi-released package called TrieMap. The objective of this package, building off of the work in this paperhttps://docs.google.com/Doc?docid=0AWuaUF8ZNTNDZHB3emdyaF8zMzNmZmtmcHo2Ywhl=en, is to automatically derive the type of a generalized trie for any algebraic type based on its algebraic representation. (I am working on writing up my methods for publication.) Of course, if I could get automatic access to the mechanisms of a type's constructors, I wouldn't even require users to describe the algebraic representation of their type... Louis Wasserman wasserman.lo...@gmail.com On Tue, Sep 8, 2009 at 2:34 AM, Sean Leather leat...@cs.uu.nl wrote: I don't know a thing about SYB, Data.Data, or Data.Typeable, mostly because I'm an efficiency fanatic. Nevertheless, I'd like to know whether or not there's a way to deconstruct a (mostly) arbitrary type, into tuples, unions, etc. using this framework. Any thoughts? You can use the Template Haskell deriving in EMGM to get that structure pretty efficiently. http://www.cs.uu.nl/wiki/GenericProgramming/EMGM http://hackage.haskell.org/package/emgm The obligatory question is: why do you want it? Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal install on Windows 7
Might it make sense to try and get the concept of global and user working in Windows? (It may already, but I noticed that the default seems to be global.) I don't know what technical challenges there are, but the ApplicationData directory (or AppData, or whatever) seems like a good place to stick user cabal packages. /jve On Tue, Sep 8, 2009 at 9:31 AM, Peter Verswyvelen bugf...@gmail.com wrote: I tried the cabal install command on Windows 7, and I had to run it with administrative privileges, otherwise I got access denied (it failed to create the Haskell folder in C:\Program Files) Not sure if this is also the case on Vista. Is this the intended behavior? ___ 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] Deconstructing types
The answer is, I'm working on a recently semi-released package called TrieMap. The objective of this package, building off of the work in this paperhttps://docs.google.com/Doc?docid=0AWuaUF8ZNTNDZHB3emdyaF8zMzNmZmtmcHo2Ywhl=en, is to automatically derive the type of a generalized trie for any algebraic type based on its algebraic representation. (I am working on writing up my methods for publication.) Of course, if I could get automatic access to the mechanisms of a type's constructors, I wouldn't even require users to describe the algebraic representation of their type... Well, it's relatively easy to use Template Haskell to determine the structure of a datatype. Look in the Generics category on Hackage for a number of examples (e.g. emgm, regular, multirec) or see if the Derive package will do it for you. According to Neil Mitchell, you just need one example: http://www.cogsys.wiai.uni-bamberg.de/aaip09/aaip09_submissions/talk_mitchell.pdf I don't know if it's easy or even possible to capture a sum-of-products view from SYB. Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Deconstructing types
Oh, geez. Wrong link. I meant http://portal.acm.org/citation.cfm?id=967471 . Louis Wasserman wasserman.lo...@gmail.com On Tue, Sep 8, 2009 at 1:06 PM, Louis Wasserman wasserman.lo...@gmail.comwrote: Sean, The answer is, I'm working on a recently semi-released package called TrieMap. The objective of this package, building off of the work in this paperhttps://docs.google.com/Doc?docid=0AWuaUF8ZNTNDZHB3emdyaF8zMzNmZmtmcHo2Ywhl=en, is to automatically derive the type of a generalized trie for any algebraic type based on its algebraic representation. (I am working on writing up my methods for publication.) Of course, if I could get automatic access to the mechanisms of a type's constructors, I wouldn't even require users to describe the algebraic representation of their type... Louis Wasserman wasserman.lo...@gmail.com On Tue, Sep 8, 2009 at 2:34 AM, Sean Leather leat...@cs.uu.nl wrote: I don't know a thing about SYB, Data.Data, or Data.Typeable, mostly because I'm an efficiency fanatic. Nevertheless, I'd like to know whether or not there's a way to deconstruct a (mostly) arbitrary type, into tuples, unions, etc. using this framework. Any thoughts? You can use the Template Haskell deriving in EMGM to get that structure pretty efficiently. http://www.cs.uu.nl/wiki/GenericProgramming/EMGM http://hackage.haskell.org/package/emgm The obligatory question is: why do you want it? Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ForeignFunPtr
You are right, I forgot about callbacks. freeHaskellFunPtr is only for Haskell functions packaged for usage by the foreign code. Example from the FFI specification, Section 5.4.2: type Compare = Int - Int - Bool foreign import ccall wrapper mkCompare :: Compare - IO (FunPtr Compare) If you, say, x = mkCompare () and at some point decide x is not needed in your foreign code any more, it has to be freed by hand. This is the only case in which you are allowed to use freeHaskellFunPtr. The (much less interesting) case that I was thinking about, where FunPtr is used for foreign C functions, usually requires no finalization. ForeignPtr is used for foreign objects used by Haskell. The garbage collector (gc) can decide whether the object is still in use and, if it's not, finalize it. A Haskell function wrapped in a FunPtr is used in the foreign world. Haskell gc cannot be made responsible for finalizing it. In fact, (unless the foreign world has some gc of its own) there is no way for any compiler of deciding when to finalize at all. The programmer needs to decide this by calling freeHaskellFunPtr, just like she needs to decide when to free mallocked memory in C. Does that make more sense? Please kick me again if you are still not buying it. :-) cheers, matthias On Sun, Sep 06, 2009 at 02:53:52PM -0300, Maur??cio CA wrote: To: haskell-cafe@haskell.org From: Maur??cio CA mauricio.antu...@gmail.com Date: Sun, 06 Sep 2009 14:53:52 -0300 Subject: [Haskell-cafe] Re: ForeignFunPtr Isn't freeHaskellFunPtr a required finalization procedure? Maurício the purpose of ForeignPtr is to attach a finalization procedure to the object behind the pointer. for example, you can have close called aimplicitly whenever the garbage collector finds you don't need a file handle any more. function pointers do not need finalization. We have ForeignPtr. Why isn't there a corresponding ForeignFunPtr? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ** ACCEPT: CRM114 PASS osb unique microgroom Matcher ** CLASSIFY succeeds; success probability: 1. pR: 5.6531 Best match to file #0 (nonspam.css) prob: 1. pR: 5.6531 Total features in input file: 2752 #0 (nonspam.css): features: 758386, hits: 2838587, prob: 1.00e+00, pR: 5.65 #1 (spam.css): features: 1686574, hits: 3088399, prob: 2.22e-06, pR: -5.65 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Takusen: *** Exception: readUTF8Char: illegal UTF-8 character 252
Hi all, I'm trying to use Takusen ODBC on Windows. I'm using a German WinXP Pro and try to connect to an MS Access database. As soon as I try to do some inserts the above mentioned exception shows up. Does anyone know a work around for this? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: uvector-algorithms 0.2
Greetings, It is my pleasure to announce version 0.2 of the uvector-algorithms package. The package so far has implementations of several sorting and selection algorithms for use on the mutable arrays from the uvector library, as well as combinators for applying them to immutable arrays. New developments in this version include: - A simple benchmarking program for testing the performance of the algorithms (it's what I use to measure them, but I only have one computer to run it on, so perhaps other folks might want to see how it works on their machine) - A testing program, written with quick check to verify properties of the algorithms - Several bugs found and fixed due to the above tests and using HPC to verify good program coverage - Combinators for Schwartzian transform - Reworking radix sort to be more amenable to optimization. It's now around twice as fast. - A Radix instance for strict pairs, and a radix sortBy - Merge sort is now slightly faster due to memcpy in uvector :) The library can be found at hackage: http://hackage.haskell.org/package/uvector-algorithms or in its darcs repository: http://code.haskell.org/~dolio/uvector-algorithms/ As always, I can be notified of any issues. Enjoy. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to understand the 'forall' ?
Eugene Kirpichov wrote: P.S. I tried to write up the difference between datatype and function declarations in this respect, but my explanations turned into a mess, so I erased them in the hope that someone will explain it better than me. Hello Eugene, I'll give it a try. In a non-constructive way: there seems to be nothing in common between those. In a constructive way: Datatype forall is called existential quantification, forall in function signature is called first-class polymorphism, if I'm not mistaken. Existential is a perfect word, because it really is data S = exists a. Show a = S [a]. The meaning is that within a given instance of S there lies some value of some particular type (a type exists). It's not any, it's some particular type. It can be either [Int], or forall a. Show a = [a], for example [], or some other type, but it exists. With first-class polymorphism there's nothing that lies somewhere. Nothing of some particular type. The function whose type is forall ... is applicable to any type within the given bounds. And even this function itself doesn't lie anywhere, since it's a parameter. I think it can be considered just a way to impact the scope of type parameters within the signature, roughly speaking. Not sure it this is useful, but data S = ∃x. S x f :: ∀x. x - (∀y. y - t) - t and just in case, the data constructor S doesn't use first-class polymorphism since its type is just S :: ∀x. x - S I know that you perfectly understand it, I just tried to word it :) -- Daniil Elovkov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: fclabels-0.4.0 - First class accessor labels.
On Fri, 4 Sep 2009, Sebastiaan Visser wrote: Hello all, There are more package around that serve the same purpose (like the Lenses package which was uploaded a few days ago), but I'm convinced the simplicity and elegance of fclabels will strike you all. ;-) How does it compare to data-accessor and data-accessor-template? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] problems with HOC install from svn
I'm unable to build HOC from the svn read-only checkout. Here are some details of what I'm doing. I'm running OS X 10.5.8 on an intel iMac with Xcode is 3.1.3. Haskel and Cabal are from the Haskel platform, haskell-platform-2009.2.0.2-i386.dmg I got Parsec 3.0 from Hackage. I checked out HOC using the svn command at http://code.google.com/p/hoc/source/checkout and checked out revision 411. Configure goes OK except for the complaint: Setup.hs:1:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks But when I try to build, I get, after a bunch of apparently successful things: --- Loading package binary-0.5.0.1 ... command line: can't load .so/.DLL for: HSbinary-0.5.0.1 (dlopen(libHSbinary-0.5.0.1.dylib, 9): image not found) --- I certainly can't find libHSbinary... of any version on my computer, dylib or not. Tried looking in the /Library/Frameworks/GHC.Framework stuff, also did a find . -iname *libHS* and found libHSGLFW..., libHSparsec-3.0.0. (also tried this in my home directory). What is this, and how do I get it? Best, John Velman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to understand the 'forall' ?
On Tue, Sep 8, 2009 at 12:44 PM, Daniil Elovkovdaniil.elov...@googlemail.com wrote: Existential is a perfect word, because it really is data S = exists a. Show a = S [a]. If you were going to make exists a keyword, I think you would write it like this: data S = ConsS (exists a. Show a = [a]) To contrast: data GhcS = forall a. Show a = ConsGhcS [a] data T = ConsT (forall a. Show a = [a]) This gives these constructors: ConsS :: forall a. (Show a = [a] - S) ConsGhcS :: forall a. (Show a = [a] - S) -- same ConsT :: (forall a. Show a = [a]) - T -- higher-rank type! T isn't very useful, it has to be able to provide a list of *any* instance of Show, so probably [] is all you get. But you can do something similar: data N = ConsN (forall a. Num a = [a]) Now you get ConsN :: (forall a. Num a = [a]) - N and you can legally do n = ConsN [1,2,3] since [1,2,3] == [fromInteger 1, fromInteger 2, fromInteger 3] :: forall a. Num a = [a] Conceptually, an S holds *some* instance of Show, so the user of a constructed S can only use methods of Show; they don't have any further knowledge about what is inside. But a N holds *any* instance of Num, so the user of the data can pick which one they want to use; Integer, Rational, Double, some (Expr Int) instance made by an embedded DSL programmer, etc. Of course, there are some ways to recover information about what types are inside the existential using GADTs or Data.Dynamic. But those need to be held in the structure itself. For example: data Typ a where TBool :: Typ Bool TInt :: Typ Int TFunc :: Typ a - Typ b - Typ (a - b) TList :: Typ a - Typ [a] TPair :: Typ a - Typ b - Typ (a,b) Now you can create an existential type like this: data Something = forall a. Something (Typ a) a and you can extract the value if the type matches: data TEq a b where Refl :: TEq a a extract :: forall a. Typ a - Something - Maybe a extract ta (Something tb vb) = do Refl - eqTyp ta tb return vb This desugars into ] extract ta (Something tb vb) = ]eqTyp ta tb = \x - ] case x of ] Refl - return vb ] _ - fail pattern match failure which, since Refl is the only constructor for TEq, simplifies to ] extract ta (Something tb vb) = eqTyp ta tb = \Refl - Just vb The trick is that the pattern match on Refl proves on the right-hand side that a is the same type as that held in the existential, so we have successfully extracted information from the existential and can return it to the caller without breaking encapsulation. Here's the helper function eqTyp; it's pretty mechanical: eqTyp :: Typ a - Typ b - Maybe (TEq a b) eqTyp TBool TBool = return Refl eqTyp TInt TInt = return Refl eqTyp (TFunc a1 b1) (TFunc a2 b2) = do Refl - eqTyp a1 a2 Refl - eqTyp b1 b2 return Refl eqTyp (TList a1) (TList a2) = do Refl - eqTyp a1 a2 return Refl eqTyp (TPair a1 b1) (TPair a2 b2) = do Refl - eqTyp a1 a2 Refl - eqTyp b1 b2 return Refl eqTyp _ _ = Nothing Here's a simple test: test = Something (TFun TInt TBool) (\x - x == 3) runTest = fromJust (extract (TFun TInt TBool) test) 5 runTest == False, of course. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problems with HOC install from svn
It sounds like it's looking for the binary package -- you should install it using cabal, e.g. private (per-user) install: cabal update cabal install binary global (system-wide) install: sudo cabal update sudo cabal install --global binary -Ross On Sep 8, 2009, at 7:57 PM, John Velman wrote: I'm unable to build HOC from the svn read-only checkout. Here are some details of what I'm doing. I'm running OS X 10.5.8 on an intel iMac with Xcode is 3.1.3. Haskel and Cabal are from the Haskel platform, haskell-platform-2009.2.0.2-i386.dmg I got Parsec 3.0 from Hackage. I checked out HOC using the svn command at http://code.google.com/p/hoc/source/checkout and checked out revision 411. Configure goes OK except for the complaint: Setup.hs:1:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks But when I try to build, I get, after a bunch of apparently successful things: --- Loading package binary-0.5.0.1 ... command line: can't load .so/.DLL for: HSbinary-0.5.0.1 (dlopen (libHSbinary-0.5.0.1.dylib, 9): image not found) --- I certainly can't find libHSbinary... of any version on my computer, dylib or not. Tried looking in the /Library/Frameworks/GHC.Framework stuff, also did a find . -iname *libHS* and found libHSGLFW..., libHSparsec-3.0.0. (also tried this in my home directory). What is this, and how do I get it? Best, John Velman ___ 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] problems with HOC install from svn
Thanks. Now I do have libHSbinary-0.5.0.1.a in /usr/local/lib, but apparently not the dylib version. Tomorrow I'll look further. Perhaps there are some options to produce dylib libraries. I've used Haskell on Linux some time ago (but not Cabal), and have been Xcoding with Objective C for a year or so now, but never tried this before. I am interested in HOC, but I've obviously got a lot to learn. Thanks again, John Velman On Tue, Sep 08, 2009 at 08:35:54PM -0400, Ross Mellgren wrote: It sounds like it's looking for the binary package -- you should install it using cabal, e.g. private (per-user) install: cabal update cabal install binary global (system-wide) install: sudo cabal update sudo cabal install --global binary -Ross On Sep 8, 2009, at 7:57 PM, John Velman wrote: I'm unable to build HOC from the svn read-only checkout. Here are some details of what I'm doing. I'm running OS X 10.5.8 on an intel iMac with Xcode is 3.1.3. Haskel and Cabal are from the Haskel platform, haskell-platform-2009.2.0.2-i386.dmg I got Parsec 3.0 from Hackage. I checked out HOC using the svn command at http://code.google.com/p/hoc/source/checkout and checked out revision 411. Configure goes OK except for the complaint: Setup.hs:1:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks But when I try to build, I get, after a bunch of apparently successful things: --- Loading package binary-0.5.0.1 ... command line: can't load .so/.DLL for: HSbinary-0.5.0.1 (dlopen(libHSbinary-0.5.0.1.dylib, 9): image not found) --- I certainly can't find libHSbinary... of any version on my computer, dylib or not. Tried looking in the /Library/Frameworks/GHC.Framework stuff, also did a find . -iname *libHS* and found libHSGLFW..., libHSparsec-3.0.0. (also tried this in my home directory). What is this, and how do I get it? Best, John Velman ___ 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] problems with HOC install from svn
I have binary-0.5 not binary-0.5.0.1, but it doesn't have any dylibs. Moreover, I was under the impression that GHC does not yet support shared libraries like those, so I'm not sure why it would be looking for one. I can't really speculate, maybe more of the build output might help? -Ross On Sep 8, 2009, at 10:54 PM, John Velman wrote: Thanks. Now I do have libHSbinary-0.5.0.1.a in /usr/local/lib, but apparently not the dylib version. Tomorrow I'll look further. Perhaps there are some options to produce dylib libraries. I've used Haskell on Linux some time ago (but not Cabal), and have been Xcoding with Objective C for a year or so now, but never tried this before. I am interested in HOC, but I've obviously got a lot to learn. Thanks again, John Velman On Tue, Sep 08, 2009 at 08:35:54PM -0400, Ross Mellgren wrote: It sounds like it's looking for the binary package -- you should install it using cabal, e.g. private (per-user) install: cabal update cabal install binary global (system-wide) install: sudo cabal update sudo cabal install --global binary -Ross On Sep 8, 2009, at 7:57 PM, John Velman wrote: I'm unable to build HOC from the svn read-only checkout. Here are some details of what I'm doing. I'm running OS X 10.5.8 on an intel iMac with Xcode is 3.1.3. Haskel and Cabal are from the Haskel platform, haskell-platform-2009.2.0.2-i386.dmg I got Parsec 3.0 from Hackage. I checked out HOC using the svn command at http://code.google.com/p/hoc/source/checkout and checked out revision 411. Configure goes OK except for the complaint: Setup.hs:1:0: Warning: In the use of `defaultUserHooks' (imported from Distribution.Simple): Deprecated: Use simpleUserHooks or autoconfUserHooks, unless you need Cabal-1.2 compatibility in which case you must stick with defaultUserHooks But when I try to build, I get, after a bunch of apparently successful things: --- Loading package binary-0.5.0.1 ... command line: can't load .so/.DLL for: HSbinary-0.5.0.1 (dlopen(libHSbinary-0.5.0.1.dylib, 9): image not found) --- I certainly can't find libHSbinary... of any version on my computer, dylib or not. Tried looking in the /Library/Frameworks/GHC.Framework stuff, also did a find . -iname *libHS* and found libHSGLFW..., libHSparsec-3.0.0. (also tried this in my home directory). What is this, and how do I get it? Best, John Velman ___ 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] HList and Type signatures / synonyms
Gunther, I've got a little experience with HList - read below. 2009/9/6 Günther Schmidt gue.schm...@web.de: Hi, I keep accumulating values and right now use plain tuples for that. I end up with a 12 element tuple and things are a bit messy. I'd like to use extensible Records from HList instead, thing is I'd like to keep putting type signatures in my code. As it turns out that seems to be where it gets messy with HList. There is a template haskell function called makeLabel that can generate the boilerplate for you. If you are comfortable not seeing all the type definitions, it might do the trick. PS: Does anyone know why there are Label-n modules in HList, and which one to use? I don't but Label4 works for me. Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Takusen: *** Exception: readUTF8Char: illegal UTF-8 character 252
Hello Günther, It looks like Access is not using UTF8 as its text encoding. I have Access at work, so I can look into this at some point. The ODBC code assumes the encoding is always UTF8. For some drivers (e.g. PostgreSQL) you must configure the ODBC driver correctly to provide UTF8. Does Takusen work with Access for US7ASCII text? If not, this would suggest that Access is using UTF16 (which is common on Windows). Alistair 2009/9/8 Günther Schmidt gue.schm...@web.de: Hi all, I'm trying to use Takusen ODBC on Windows. I'm using a German WinXP Pro and try to connect to an MS Access database. As soon as I try to do some inserts the above mentioned exception shows up. Does anyone know a work around for this? Günther ___ 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
