Re: [GHC] #3390: Upgrade the Windows build to use gcc 4.4.0
#3390: Upgrade the Windows build to use gcc 4.4.0 -+-- Reporter: simonmar |Owner: simonmar Type: task | Status: new Priority: normal|Milestone: 6.14.1 Component: Build System | Version: 6.10.4 Keywords:| Testcase: Blockedby:| Difficulty: Unknown Os: Windows | Blocking: Architecture: x86 | Failure: None/Unknown -+-- Changes (by simonmar): * owner: = simonmar Comment: Strange, I'll try to look into it. There is a bug that would be fixed by this (I think it was one of the directory tests, but I don't remember which). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3390#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] #4295: Review higher-rank and impredicative types
#4295: Review higher-rank and impredicative types -+-- Reporter: simonpj |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Description changed by simonpj: Old description: The ticket is a placeholder to remind me to work through the test cases for impredicative and higher rank types in the new typechecker. For now, I'm marking many of them as `expect_broken` on this ticket, although I think many of them really should fail. * tc150 * tc194 * tcfail198 * tcfail174 * tcfail165 * tcfail145 * tcfail104 * tc211 * indexed-types/should_compile/T4120 * Many tests in `boxy/` (see also #1330 for Church2) New description: The ticket is a placeholder to remind me to work through the test cases for impredicative and higher rank types in the new typechecker. For now, I'm marking many of them as `expect_broken` on this ticket, although I think many of them really should fail. * tc150 * tc194 * tcfail198 * tcfail174 * tcfail165 * tcfail145 * tcfail104 * tc211 * indexed-types/should_compile/T4120 * simpl017 * Many tests in `boxy/` (see also #1330 for Church2) -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4295#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] #4267: Missing unboxing in pre-order fold over binary tree
#4267: Missing unboxing in pre-order fold over binary tree -+-- Reporter: tibbe |Owner: Type: bug | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.13 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by simonmar): Replying to [comment:2 simonmar]: We established (during a conversation on IRC) that the reason for the lack of unboxing was that the function wasn't inlined until after the worker-wrapper transformation. The question is therefore, why wasn't it inlined earlier? I think I must have misunderstood the IRC conversation in question, tibbe told me today that the function does indeed get inlined before strictness analysis and worker-wrapper. tibbe: if you could attach the output from `-dverbose-core2core` to the ticket, that might help. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4267#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] #4267: Missing unboxing in pre-order fold over binary tree
#4267: Missing unboxing in pre-order fold over binary tree
-+--
Reporter: tibbe |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 6.13
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by tibbe):
Here are the relevant parts of `-dverbose-core2core`. First, inlining
happens:
{{{
Simplifier Phase 2 [main] max-iterations=4
a_soD :: GHC.Types.Int
[LclId,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=0, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [] 1 2}]
a_soD = GHC.Types.I# 0
FoldTest.sumTree :: Fold.Tree GHC.Types.Int - GHC.Types.Int
[LclIdX,
Arity=1,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=1, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0] 18 0}]
FoldTest.sumTree =
\ (eta1_B1 :: Fold.Tree GHC.Types.Int) -
letrec {
go_aaE [Occ=LoopBreaker]
:: GHC.Types.Int - Fold.Tree GHC.Types.Int - GHC.Types.Int
[LclId,
Arity=2,
Unf=Unf{Src=vanilla, TopLvl=False, Arity=2, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0 3] 12 0}]
go_aaE =
\ (z_aaF :: GHC.Types.Int) (ds_dbh :: Fold.Tree GHC.Types.Int) -
case ds_dbh of _ {
Fold.Leaf - z_aaF;
Fold.Node a_aaH l_aaI r_aaJ -
case go_aaE z_aaF l_aaI of _ { GHC.Types.I# ipv_soJ -
case a_aaH of _ { GHC.Types.I# y_aox -
go_aaE (GHC.Types.I# (GHC.Prim.+# ipv_soJ y_aox)) r_aaJ
}
}
}; } in
go_aaE a_soD eta1_B1
}}}
And some time later demand analysis:
{{{
Demand analysis
a_soD :: GHC.Types.Int
[LclId,
Str=DmdType m,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=0, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [] 1 2}]
a_soD = GHC.Types.I# 0
FoldTest.sumTree :: Fold.Tree GHC.Types.Int - GHC.Types.Int
[LclIdX,
Arity=1,
Str=DmdType S,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=1, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0] 18 0}]
FoldTest.sumTree =
\ (eta1_B1 [Dmd=Just S] :: Fold.Tree GHC.Types.Int) -
letrec {
go_aaE [Occ=LoopBreaker]
:: GHC.Types.Int - Fold.Tree GHC.Types.Int - GHC.Types.Int
[LclId,
Arity=2,
Str=DmdType SS,
Unf=Unf{Src=vanilla, TopLvl=False, Arity=2, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0 3] 12 0}]
go_aaE =
\ (z_aaF [Dmd=Just S] :: GHC.Types.Int)
(ds_dbh [Dmd=Just S] :: Fold.Tree GHC.Types.Int) -
case ds_dbh of _ {
Fold.Leaf - z_aaF;
Fold.Node a_aaH [Dmd=Just U(L)]
l_aaI [Dmd=Just S]
r_aaJ [Dmd=Just S] -
case go_aaE z_aaF l_aaI of _ { GHC.Types.I# ipv_soJ
[Dmd=Just L] -
case a_aaH of _ { GHC.Types.I# y_aox [Dmd=Just L] -
go_aaE (GHC.Types.I# (GHC.Prim.+# ipv_soJ y_aox)) r_aaJ
}
}
}; } in
go_aaE a_soD eta1_B1
}}}
and after that worker/wrapper
{{{
Worker Wrapper binds
a_soD :: GHC.Types.Int
[LclId,
Str=DmdType m,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=0, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [] 1 2}]
a_soD = GHC.Types.I# 0
FoldTest.sumTree :: Fold.Tree GHC.Types.Int - GHC.Types.Int
[LclIdX,
Arity=1,
Str=DmdType S,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=1, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0] 18 0}]
FoldTest.sumTree =
\ (eta1_B1 [Dmd=Just S] :: Fold.Tree GHC.Types.Int) -
letrec {
go_aaE [Occ=LoopBreaker]
:: GHC.Types.Int - Fold.Tree GHC.Types.Int - GHC.Types.Int
[LclId,
Arity=2,
Str=DmdType SS,
Unf=Unf{Src=vanilla, TopLvl=False, Arity=2, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0 3] 12 0}]
go_aaE =
\ (z_aaF [Dmd=Just S] :: GHC.Types.Int)
(ds_dbh [Dmd=Just S] :: Fold.Tree GHC.Types.Int) -
case ds_dbh of _ {
Fold.Leaf - z_aaF;
Re: [GHC] #4267: Missing unboxing in pre-order fold over binary tree
#4267: Missing unboxing in pre-order fold over binary tree
-+--
Reporter: tibbe |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 6.13
Keywords:| Testcase:
Blockedby:| Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by tibbe):
To add to the confusion, using HEAD, this definition of `foldl'` gets an
unboxed accumulator:
{{{
fold' :: (a - b - a) - a - Tree b - a
fold' f = go
where
go z Leaf = z
go z (Node a l r) = z `seq` go (f (go z l) a) r
{-# INLINE fold' #-}
}}}
but this one doesn't
{{{
fold' :: (a - b - a) - a - Tree b - a
fold' f = go
where
go z Leaf = z
go z (Node a l r) = z `seq` go (f (go z l) a) r
}}}
Note the missing `INLINE` pragma.
The strange thing is that GHC happily inlines both versions (since they're
not recursive) but the former gets an unboxed accumulator for some reason
I don't understand.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4267#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] #4299: a less forceful INLINE pragma
#4299: a less forceful INLINE pragma -+-- Reporter: simonmar |Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- The `INLINE` pragmas currently does two things: 1. it saves an unoptimised definition of the function in the interface file, and 2. it unfolds the definition at (almost) every call site, before optimising it further in situ. I'm proposing that we have a variant of the `INLINE` pragma that does (1) without necessarily unfolding the definition at every call site. GHC's simplifier already has some well-tuned heuristics for deciding whether to inline something or not based on information about the context, and when we use `INLINE` we bypass all this and potentially end up with unnecessary code bloat and maybe even a loss of performance in some cases. If we had an `INLINEABLE` pragma that did (1) without forcing (2), then the decision about whether to inline or not is deferred to the call site, where the user can decide how they want to trade off code size against speed. Right now the user doesn't get to decide - the library writer does. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4299 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] #836: rebindable if-then-else syntax
#836: rebindable if-then-else syntax
--+-
Reporter: nibro |Owner:
Type: feature request| Status: new
Priority: normal |Milestone: _|_
Component: Compiler (Parser) | Version: 6.13
Keywords: | Testcase: N/A
Blockedby: | Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
--+-
Comment(by simonpj):
The main ticket is, I believe, suggesting that when rebindable syntax is
enabled, then whenever GHC sees
{{{
if e1 then e2 else e3
}}}
it behaves precisely as if you'd written
{{{
cond e1 e2 e3
}}}
from ''both'' the point of view of typechecking, ''and'' the point of view
of desugaring. So, for example if
{{{
cond :: Bool - Int - Char
}}}
then you could write
{{{
if xy then 3 else 'c'
}}}
That seems entirely feasible to me. The question of overloading then
becomes quite orthogonal. For example, if the imported `cond` had this
type:
{{{
cond :: IfThenElse a = Bool - a - a - a
}}}
then that'd be fine. The term `if e1 then e2 else e3` would typecheck and
desugar as if you'd written `cond e1 e2 e3`. I think that would satisfy
vivian without any need for special support.
My main question is this: what about `case`? The proposal would mean that
`if-then-else` was different to
{{{
case e1 of
True - e2
False - e3
}}}
Maybe that's ok. Maybe it's even desirable. But I don't see how to
generalise the story to case expressions, at least not without a lot more
elaboration.
Simon
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/836#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] #4284: Adding parentheses introduces type error
#4284: Adding parentheses introduces type error -+-- Reporter: jpbernardy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type checker) |Version: 6.12.3 Resolution: fixed | Keywords: higher-rank polymorphism Testcase: typecheck/should_compile/T4284 | Blockedby: Difficulty: | Os: Unknown/Multiple Blocking: | Architecture: Unknown/Multiple Failure: GHC rejects valid program | -+-- Changes (by simonpj): * status: new = closed * testcase: = typecheck/should_compile/T4284 * resolution: = fixed Comment: Good point, thank you. Works in the new typechecker, which is about to become HEAD, so I'll close this. Added a regression test though. Simon -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4284#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] #4299: a less forceful INLINE pragma
#4299: a less forceful INLINE pragma -+-- Reporter: simonmar |Owner: Type: feature request | Status: new Priority: normal|Milestone: Component: Compiler | Version: 6.12.3 Keywords:| Testcase: Blockedby:| Difficulty: Moderate (less than a day) Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by tibbe): * cc: johan.tib...@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4299#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: SIGALRM, SIGVTALRM, and third party libraries
On 08/09/2010 15:57, Edward Z. Yang wrote: Excerpts from Simon Marlow's message of Wed Sep 08 03:40:42 -0400 2010: Maybe. As a first step I think we could just document what happens when a call is interrupted (pthread_cancel() on POSIX, ??? on Windows) and let the user handle it. Is there even a good lowest-common-denominator that we can build an API on top of? I've been thinking carefully about this, and I kind of suspect one-size fits all won't work here. I've done a writeup here; one of the problems with moving pthread_cancel to Windows is that its semantics are so complicated. http://blog.ezyang.com/2010/09/pthread-cancel-on-window/ I don't think porting pthreads to Windows is the right way to handle this anyway, Windows programmers want to use Windows APIs. I suggest that we use CancelSynchronousIO if it is available, and otherwise do nothing (this means a dynamic binding which is a bit fiddly, but I think we already do this elsewhere). TerminateThread is out of the question, because it provides no way to block it or clean up. CancelSynchronousIO will let us interrupt threads blocked on I/O on Windows, which we can't currently do, and it works for both bound and unbound threads. On POSIX we can pthread_kill() bound threads. This will let us handle at least one important case I can think of: waitForProcess. We just have to find an appropriate signal to use - we can't use SIGVTALRM, because it is already set to SA_RESTART. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
how to terminate an external program after timeout?
Hi, we call from our haskell application the metis prover via System.Process.readProcessWithExitCode metis filename However, we are not able to get rid of this process if metis does not terminate by itself. In particular, wrapping this call into a System.Timeout.timeout does not work. Any suggestions how we should handle this ideally portably but first of all under unix. (ghc-6.12.3) Thanks Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to terminate an external program after timeout?
Christian Maeder schrieb: Hi, we call from our haskell application the metis prover via System.Process.readProcessWithExitCode metis filename However, we are not able to get rid of this process if metis does not terminate by itself. In particular, wrapping this call into a System.Timeout.timeout does not work. timeout works so far as it is possible to start another action, but the continuing metis process still blocks the whole system. C. Any suggestions how we should handle this ideally portably but first of all under unix. (ghc-6.12.3) Thanks Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Type Families and defaults
| I'm afraid I didn't understand your questions well enough to answer them. | | My question is, why does this type check: It's hard for me to answer a question like that! To explain why something type checks I'd have to show every constraint and how it is solved. I think you have something more specific in mind. Maybe you think this should not typecheck. E.g. here's an expression (f x), and f has type Int - blah, and x has type Boo, so the application should fail to typecheck. You say that example 1 (which typechecks) is different to example 2 (which does not). Again, in itself that's not surprising. They differ, so their behaviours may differ. Do remember that (e :: IO n) means (e :: forall n. IO n) unless you have ScopedTypeVariables Sorry not to be more helpful. Simon | | instance Neuron TestNeuron where | data LiveNeuron TestNeuron = LiveTestNeuron NeuronId | | mkLiveNeuron nid = LiveTestNeuron nid | getNeuronId (LiveTestNeuron nid) = nid | | live _ _ = return () | | attach nerve = ((liftM mkLiveNeuron) . forkIO $ bracket (grow :: IO | FooNeuron) dissolve (live nerve)) :: IO (LiveNeuron TestNeuron) | | FooNeuron is obviously different to TestNeuron (but both are instances | of Neuron class). | | Type signature is: | | attach nerve = ((liftM mkLiveNeuron) . forkIO $ bracket (grow :: IO n) | dissolve (live nerve)) :: IO (LiveNeuron n) | | This seems different to: | | attach nerve = ((liftM mkLiveNeuron) . forkIO $ bracket (grow :: | forall n. IO n) dissolve (live nerve)) :: IO (LiveNeuron n) | | which does not type check. | | Maybe I am missing some basic understanding. | | But it'd be worth reading | http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/other-type- | extensions.html#scoped-type-variables | | I had. Thanks. | | | Mitar ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: alignment and the evil gc assertion failure
On 06/09/2010 19:03, Evan Laforge wrote:
So a long time ago (I think when 6.10 first came out, the problem
didn't happen with the previous version, and I think 6.10 changed how
the FFI used alignment) I filed a ghc ticket about a gc assertion
failure. Unfortunately it was so hard to reproduce and reduce to a
manageable example that I wound up thinking I had fixed it and closing
it as user error. However, I'm pretty sure I tracked down what the
problem was since I changed something and I haven't had that crash
since.
To recap, the crash is an assertion failure in the gc, I've seen two positions:
seq: internal error: ASSERTION FAILED: file
rts/dist/build/sm/Evac_thr.c, line 298
seq: internal error: ASSERTION FAILED: file
rts/dist/build/sm/Evac_thr.c, line 369
The problem was in the marshalling of a certain struct. The struct
has 3 Color fields and two char fields. The Colors are simply triples
of chars. I'd been using an alignment macro I've seen around:
#let alignment t = %lu, (unsigned long)offsetof(struct {char x__; t
(y__); },y__)
Since my struct is made out of chars, this macro returns an alignment
of 1. However, an alignment of 1 seems to be what leads to the GC
crash. After setting the alignment to 4 I've never had the crash
again.
I've poked around and apart from noticing that we're allocating a bit
too much memory sometimes (but not in the alignment==1 case), I didn't
find anything wrong. GHC will always give you memory that is at least
word-aligned (4 or 8 bytes) anyway.
Assertions in the RTS are only activated when you compile with -debug.
Do you get a crash without -debug? What are the exact results you get
with 6.12.3, or better still HEAD if you're able to test that?
So... what's going on here? Is the macro wrong? Alignment 1 seems
correct for something built of chars... or does a 'struct { char,
char, char }' embedded in another struct turn it into alignment 4
somehow?
Alignment seems like a particularly problematic part of the FFI, which
is in all other respects very easy to use. It's low level, poorly
understood (well, by me at least), not super well documented, and one
little mistake can either be harmless, or lead to a *very* hard to
track down bug.
If the alignment macro is correct, can it be built into hsc2hs?
It looks good enough to me, and it uses the same trick that GHC's
configure script uses to compute the required alignment for the basic types.
We could certainly add this as one of the built-in macros in hsc2hs - a
patch would help though!
Cheers,
Simon
Copy
and pasting some magic I saw on the net into every hsc file doesn't
give me a good feeling. If it's incorrect, what would a correct one
be? One odd thing about that macro is that if you mis-spell a field
name, gcc gets a bus error (OS X 10.5.8, gcc 4.0.1, does anyone else
see this?) Or is the alignment correct and it really is a ghc bug?
If so, how can I help track it down? The best I can think of is to
make a small program with that same data structure, pass it around
some, and then generate and collect a lot of garbage, but this bug has
been really hard to pin down in the past, change one little thing and
it disappears only to pop up again in 6 months.
___
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: HEAD: Deterioration in ByteString I/O
On 09/09/2010 00:28, Daniel Fischer wrote:
On Wednesday 08 September 2010 23:55:35, Don Stewart wrote:
simonpj:
| ghc-6.12.3:
|89,330,672 bytes allocated in the heap
|15,092 bytes copied during GC
|35,980 bytes maximum residency (1 sample(s))
|29,556 bytes maximum slop
| 2 MB total memory in use (0 MB lost due to
| fragmentation)
|
| ghc-6.13.20100831:
| 475,305,720 bytes allocated in the heap
|89,272 bytes copied during GC
|68,860 bytes maximum residency (1 sample(s))
|29,444 bytes maximum slop
| 2 MB total memory in use (0 MB lost due to
| fragmentation)
|
| Can you put your benchmark code somewhere? Likely a GHC
| regression.
Indeed bad. If someone could characterise the regression more
precisely (e.g. fusion isn't happening here) that would be jolly
helpful.
Shouldn't be fusion. Is this a straight IO function. Something to do
with buffering/encoding?
Maybe the following observation helps:
ghc-6.13.20100831 reads lazy ByteStrings in chunks of 8192 bytes.
If I understand correctly, that means (since defaultChunkSize = 32760)
- bytestring allocates a 32K buffer to be filled and asks ghc for 32760
bytes in that buffer
- ghc asks the OS for 8192 bytes (and usually gets them)
- upon receiving fewer bytes than requested, bytestring copies them to a
new smaller buffer
- since the number of bytes received is a multiple of ghc's allocation
block size (which I believe is 4K), there's no space for the bookkeeping
overhead, hence the new buffer takes up 12K instead of 8, resulting in 44K
allocation for 8K bytes
That factor of 5.5 corresponds pretty well with the allocation figures
above, and the extra copying explains the approximate doubling of I/O time.
Trying to find out why ghc asks the OS for only 8192 bytes instead of 32760
hasn't brought enlightenment yet.
I think I've found the problem, GHC.IO.Handle.Text:
bufReadNBEmpty :: Handle__ - Buffer Word8 - Ptr Word8 - Int - Int -
IO Int
bufReadNBEmpty h...@handle__{..}
b...@buffer{ bufRaw=raw, bufR=w, bufL=r, bufSize=sz }
ptr so_far count
| count sz, False,
Just fd - cast haDevice = do
m - RawIO.readNonBlocking (fd::FD) ptr count
case m of
Nothing - return so_far
Just n - return (so_far + n)
See if you can spot it. I must have made this change for debugging, and
forgot to revert it. d'oh!
Cheers,
Simon
Cheers,
Daniel
Excerpt of strace log:
read(3, %!PS-Adobe-2.0\n%%Title: nbench\n%..., 8192) = 8192
open(/usr/lib/gconv/UTF-32.so, O_RDONLY) = 4
read(4,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\4\0\0004\0\0\0..., 512)
= 512
fstat64(4, {st_mode=S_IFREG|0755, st_size=9672, ...}) = 0
mmap2(NULL, 12328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) =
0xb7852000
fadvise64(4, 0, 12328, POSIX_FADV_WILLNEED) = 0
mmap2(0xb7854000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 4, 0x1) = 0xb7854000
close(4)= 0
mprotect(0xb7854000, 4096, PROT_READ) = 0
ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbff37cb0) = -1 ENOTTY
(Inappropriate ioctl for device)
select(2, [], [1], NULL, {0, 0})= 1 (out [1], left {0, 0})
write(1, , 0) = 0
select(2, [], [1], NULL, {0, 0})= 1 (out [1], left {0, 0})
write(1, %!PS-Adobe-2.0\n%%Title: nbench\n%..., 8192) = 8192
read(3, 20.00 lineto\n121.153524 20, 8192) = 8192
select(2, [], [1], NULL, {0, 0})= 1 (out [1], left {0, 0})
write(1, , 0) = 0
select(2, [], [1], NULL, {0, 0})= 1 (out [1], left {0, 0})
write(1, 20.00 lineto\n121.153524 20, 8192) = 8192
read(3, 30.542315 21.394403 lineto\n125.3..., 8192) = 8192
select(2, [], [1], NULL, {0, 0})= 1 (out [1], left {0, 0})
write(1, , 0) = 0
select(2, [], [1], NULL, {0, 0})= 1 (out [1], left {0, 0})
write(1, 30.542315 21.394403 lineto\n125.3..., 8192) = 8192
read(3, neto\n308.929337 21.969871 lineto..., 8192) = 8192
___
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: how to terminate an external program after timeout?
On 09/09/2010 10:39, Christian Maeder wrote: Christian Maeder schrieb: Hi, we call from our haskell application the metis prover via System.Process.readProcessWithExitCode metis filename However, we are not able to get rid of this process if metis does not terminate by itself. In particular, wrapping this call into a System.Timeout.timeout does not work. timeout works so far as it is possible to start another action, but the continuing metis process still blocks the whole system. C. Any suggestions how we should handle this ideally portably but first of all under unix. (ghc-6.12.3) Take a look at the timeout program in GHC's test suite: http://darcs.haskell.org/testsuite/timeout/timeout.hs Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HEAD: Deterioration in ByteString I/O
On Thursday 09 September 2010 13:19:23, Simon Marlow wrote:
I think I've found the problem, GHC.IO.Handle.Text:
bufReadNBEmpty :: Handle__ - Buffer Word8 - Ptr Word8 - Int - Int -
IO Int
bufReadNBEmpty h...@handle__{..}
b...@buffer{ bufRaw=raw, bufR=w, bufL=r, bufSize=sz }
ptr so_far count
| count sz, False,
Just fd - cast haDevice = do
m - RawIO.readNonBlocking (fd::FD) ptr count
case m of
Nothing - return so_far
Just n - return (so_far + n)
See if you can spot it.
Yes, that's it. Removing the literal False to make that branch reachable
more or less reinstates old behaviour.
For I/O of (lazy) ByteStrings only, the allocation figures of HEAD are
consistently slightly higher than those of 6.12.3, but the difference is
less than 1%, well within the normal fluctuation due to changes in
implementation. Timings seem to be identical.
When performing work on the ByteStrings (finding/replacing substrings),
however, things change a bit.
The allocation figures observed so far range from almost identical ( 1%
difference) to above 15% higher (90,146,508 bytes allocated vs.
106,237,456), most of the differences I observed so far are between 5% and
10%.
The wall clock time (elapsed, per +RTS -s or time) seems to be identical
(very stable timings for multiple runs of the same benchmark), but the MUT
times reported by +RTS -s differ for some benchmarks (between 10% less for
HEAD and 20% more observed, but identical for most).
That might be worthy of examination, though it's not alarming.
Cheers,
Daniel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to terminate an external program after timeout?
On Sep 9, 2010, at 6:37 AM, Simon Marlow wrote: On 09/09/2010 10:39, Christian Maeder wrote: Christian Maeder schrieb: Hi, we call from our haskell application the metis prover via System.Process.readProcessWithExitCode metis filename However, we are not able to get rid of this process if metis does not terminate by itself. In particular, wrapping this call into a System.Timeout.timeout does not work. timeout works so far as it is possible to start another action, but the continuing metis process still blocks the whole system. C. Any suggestions how we should handle this ideally portably but first of all under unix. (ghc-6.12.3) Take a look at the timeout program in GHC's test suite: http://darcs.haskell.org/testsuite/timeout/timeout.hs In case it's not obvious, I believe this has to be compiled with -threaded to get the desired behavior. -David Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: HEAD: Deterioration in ByteString I/O
On 09/09/2010 15:08, Daniel Fischer wrote:
On Thursday 09 September 2010 13:19:23, Simon Marlow wrote:
I think I've found the problem, GHC.IO.Handle.Text:
bufReadNBEmpty :: Handle__ - Buffer Word8 - Ptr Word8 - Int - Int -
IO Int
bufReadNBEmpty h...@handle__{..}
b...@buffer{ bufRaw=raw, bufR=w, bufL=r, bufSize=sz }
ptr so_far count
| count sz, False,
Just fd- cast haDevice = do
m- RawIO.readNonBlocking (fd::FD) ptr count
case m of
Nothing - return so_far
Just n - return (so_far + n)
See if you can spot it.
Yes, that's it. Removing the literal False to make that branch reachable
more or less reinstates old behaviour.
For I/O of (lazy) ByteStrings only, the allocation figures of HEAD are
consistently slightly higher than those of 6.12.3, but the difference is
less than 1%, well within the normal fluctuation due to changes in
implementation. Timings seem to be identical.
When performing work on the ByteStrings (finding/replacing substrings),
however, things change a bit.
The allocation figures observed so far range from almost identical ( 1%
difference) to above 15% higher (90,146,508 bytes allocated vs.
106,237,456), most of the differences I observed so far are between 5% and
10%.
The wall clock time (elapsed, per +RTS -s or time) seems to be identical
(very stable timings for multiple runs of the same benchmark), but the MUT
times reported by +RTS -s differ for some benchmarks (between 10% less for
HEAD and 20% more observed, but identical for most).
That might be worthy of examination, though it's not alarming.
If you can find an example that consistently allocates significantly
more than with 6.12 (10%+), then I'd say it would be worth looking into.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to terminate an external program after timeout?
David Peixotto schrieb: On Sep 9, 2010, at 6:37 AM, Simon Marlow wrote: On 09/09/2010 10:39, Christian Maeder wrote: Christian Maeder schrieb: Hi, we call from our haskell application the metis prover via System.Process.readProcessWithExitCode metis filename However, we are not able to get rid of this process if metis does not terminate by itself. In particular, wrapping this call into a System.Timeout.timeout does not work. timeout works so far as it is possible to start another action, but the continuing metis process still blocks the whole system. C. Any suggestions how we should handle this ideally portably but first of all under unix. (ghc-6.12.3) Take a look at the timeout program in GHC's test suite: http://darcs.haskell.org/testsuite/timeout/timeout.hs This looks pretty complicated. Did no one else needed this? Isn't it easier to put the application into a wrapper script and call the script from haskell? In case it's not obvious, I believe this has to be compiled with -threaded to get the desired behavior. -David Yes, we do use -threaded. Christian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: how to terminate an external program after timeout?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/9/10 05:35 , Christian Maeder wrote: System.Process.readProcessWithExitCode metis filename If all else fails, there's: sh -c '(sleep 120; kill -TERM $$ /dev/null 21) exec metis' which makes the shell deal with timeouts for you. (Adjust sleep time and kill signal as needed.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyJOIUACgkQIn7hlCsL25VzdwCfcFW/LHTRslit2P4en/o3V88j VEcAnjTB6Dzhpc74TmIvvTUwXwENhDz/ =8ROO -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: ANN: iyql - interactive yql
Oh, forget to send the links: cabal pkg: http://hackage.haskell.org/package/iyql source: http://github.com/dsouza/iyql Thanks! On Wed, Sep 8, 2010 at 11:27 PM, Diego Souza dso...@bitforest.org wrote: Hi All, I'm pleased to announce iyql, an interactive CLI for YQL [ http://developer.yahoo.com/yql/console]. This version provides the first release, which allows you perform all queries supported by YQL [with the sole exception of parenthesis in WHERE clause]. Among other things, completion and history are implemented [=haskeline] along with support for queries that requires OAuth authentication. Plans for next releases: * Implement a decent error handling: currently any unexpected exception aborts the program; * Support parenthesis in WHERE clause; * More local functions; Please let me know about any issues or suggestions! Regards, -- ~dsouza yahoo!im: paravinicius gpg key fingerprint: 71B8 CE21 3A6E F894 5B1B 9ECE F88E 067F E891 651E gpg pub key: http://bitforest.org/~dsouza/pub/gpg-pubkey.txthttp://bitforest.org/%7Edsouza/pub/gpg-pubkey.txt authorized_keys: http://bitforest.org/~dsouza/pub/authorized_keys.txthttp://bitforest.org/%7Edsouza/pub/authorized_keys.txt -- ~dsouza yahoo!im: paravinicius gpg key fingerprint: 71B8 CE21 3A6E F894 5B1B 9ECE F88E 067F E891 651E gpg pub key: http://bitforest.org/~dsouza/pub/gpg-pubkey.txt authorized_keys: http://bitforest.org/~dsouza/pub/authorized_keys.txt ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Form a haskell.org committee
On Mon, Sep 06, 2010 at 07:27:35AM +, Simon Peyton-Jones wrote: I think that's an excellent idea. I think there should be a web page describing what the committee does, who is in it, how to contact it, etc. Yes, definitely. I've created: http://www.haskell.org/haskellwiki/Haskell.org_committee That doubtless isn't perfect, but I'm sure it can be refined and clarified by the first committee as necessary. Well the committee also be responsible for the haskell.org web site? The site will shortly be moving to a server paid for with haskell.org funds, so yes, in the general policy sense (e.g. they might be asked to decide if job ads should be allowed on h.o), but they would not be responsible for the day-to-day running (e.g. configuring the wiki, or removing spam from it). Five might be a little small. OK, I've made it 7. I've also incorporated your other suggestions into the above page. Thanks Ian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] New haskell.org server
Hi all, We will shortly be replacing the haskell.org server with a more modern, commercially hosted machine. For now, the new server is available as http://new-www.haskell.org/ The ghc, hugs and nhc98 websites have been copied across, and there is a copy of the wiki (although that will be resynced when we change servers). We will also be moving the mailing lists at changeover time. *** If you know of anything else that haskell.org *** *** does, and should keep doing, please let us know *** ***now or it will break soon! *** *** *** *** If you have anything else on haskell.org, *** *** please find it a new home now! *** Note that if there are other services currently running on haskell.org, this may be a good time to consider moving them to the community server instead: http://community.haskell.org/ Meanwhile, we would like to thank Paul Hudak, John Peterson, Mark Wogahn, the Yale Workstation Support team and Yale University for hosting, running and maintaining the haskell.org server for countless years. We would also like to thank the Haskell Summer of Code team for providing the funding for the new server, and the community sysadmin team for agreeing to maintain it in the future. Thanks also to Thomas Schilling and Ashley Yakeley for getting the wiki up and running, and restyling it. Thanks Ian, on behalf of the Haskell Infrastructure team. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: ANNOUNCE: GotoT-transformers version 1.0
Antoine Latter aslat...@gmail.com wrote: I don't think you need 'goto' to implement jumps in Haskell. Note that functions as well as computations are first class: To recover from my overly complex previous post, here is a much simply goto based on existing monad transformers: goto :: Monad m = ContT r m r - ContT r m a goto (ContT m) = ContT $ \_ - m return Reading your post, Ertugrul, made something click for me Yeah, that's a great functional CPS-based goto, which allows all kinds of spaghetti code. And it is in fact a real jump because of tail-call optimization. =) As a side note, the 'abort' function is implemented in a similar way. It ignores the continuation and jumps to an empty computation, that way it returns from the ContT computation. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife = sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: GotoT-transformers version 1.0
Antoine Latter wrote: To recover from my overly complex previous post, here is a much simply goto based on existing monad transformers: goto :: Monad m = ContT r m r - ContT r m a goto (ContT m) = ContT $ \_ - m return That is precisely how continuations were discovered (as John Reynolds documents, continuations have been discovered and rediscovered multiple times). The paper Continuations: A Mathematical Semantics for Handling Full Jumps Christopher Strachey and Christopher P. Wadsworth http://www.ling.ohio-state.edu/research/groups/commies/past/autumn2009/strachey-wadsworth2000.pdf first published in 1974 and republished in Higher-Order and Symbolic Computation, 13, 135-152, 2000 starts with the following sentence: The purpose of this paper is to explain a method of giving the mathematical semantics of a programming language which includes a very general form of jump (goto statement). The cited goto expression above appears, in mathematical notation, as the second equation on p. 143 of the paper. Labels are considered next. The paper is still a good read. One can literally implement the language of the paper, by reading domain equations as the implementation of a monad. Incidentally, Note 1 of the paper anticipated delimited continuations. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Unwrapping newtypes
Hi Ertugrul,
My goal was to find a way to define all that was needed using
Haskell's automatic instance deriving mechanism. Haskell can
automatically derive Foldable, which is why I was looking at that.
However, that requires writing two lines for each wrapper newtype to
get around the kind problem.
I wanted one line.
Fortunately,
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
gives me what I want now that I know how it works!
I agree that the Foldable solution was a bit of a kludge.
Kevin
On Sep 9, 3:57 am, Ertugrul Soeylemez e...@ertes.de wrote:
Kevin Jardine kevinjard...@gmail.com wrote:
I have a generic object that I want to wrap in various newtypes to
better facilitate type checking.
For example,
newtype Blog = Blog Obj
newtype Comment = Comment Obj
newtype User = User Obj
Unlike Obj itself, whose internal structure is hidden in a library
module, the newtype wrappings are purely to facilitate type checking.
It is no secret that each is just a wrapper around Obj.
It is obvious how to construct the various wrapper objects. It is not
so obvious how to extract the Obj they contain in a reasonably generic
way however. What I want is a getObj function that works on all of
them.
Of course this could work if someone using the library wrote an
instance for each wrapper object:
instance GetObject Blog where
getObj (Blog obj) = obj
but this is a pain in the neck to write for each newtype.
Simple solution:
data ObjContent = Blah
data Obj
= Blog { getObj :: !ObjContent }
| Comment { getObj :: !ObjContent }
| User { getObj :: !ObjContent }
With your GetObject class this even becomes extensible:
instance GetObject Obj where
getObject = getObj
data OtherType = OtherType ObjContent
instance GetObject OtherType where
getObject (OtherType obj) = obj
I discovered that Foldable defines a handy toList function that
extracts content from generic Foldable structures.
So that I could write:
toObj :: Foldable thing = thing Obj - Obj
toObj w = head $ toList w
Slightly kludgy but it works.
But it's not what you are looking for. You are confusing constructor
types with type kinds. Foldable expects a type of kind * - *, which
isn't quite what you want. Also I would consider this to be abuse.
Also from a complexity standpoint it's nothing different from your
GetObject class anyway. You still need to write the instances.
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife = sex)http://ertes.de/
___
Haskell-Cafe mailing list
haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: recommendations for reading list?
David Leimbach wrote: In my amazon shopping cart I currently have: *Conceptual Mathematics: A First Introduction to Categorieshttp://www.amazon.com/gp/product/052171916X/ref=ord_cart_shr?ie=UTF8m=ATVPDKIKX0DER *- F. William Lawvere *Categories for the Working Mathematician (Graduate Texts in Mathematics)http://www.amazon.com/gp/product/0387984038/ref=ord_cart_shr?ie=UTF8m=ATVPDKIKX0DER *- Saunders Mac Lane *Categories and Computer Science (Cambridge Computer Science Texts)http://www.amazon.com/gp/product/0521422264/ref=ord_cart_shr?ie=UTF8m=ATVPDKIKX0DER *- R. F. C. Walters Are all 3 of these worthwhile? Any of them? I'm just trying to get a grasp on enough Category Theory to be able think more deeply about programming in general, and maybe grasp more Haskell terminology beyond the seemingly superficial meanings I understand today. I would recommend against MacLane (unless you are indeed a working mathematician), his choice of topics and examples does not really help understanding the Haskell side of category theory. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Handling platform- or configuration-specific code (or, my CPP complaints)
In general, I think using CPP for actual macro processing is extremely poor style and can easily make code inscrutable (and no doubt bug-prone). If the Haskell spec were to add support for this sort of top-level compiler/compiletime-flag conditional definition, I'd switch over. I agree that CPP used only for conditional compilation, is much more acceptable than using it for macros as well. And co-incidentally, cpphs has a --nomacro flag. :-) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Unwrapping newtypes
Kevin Jardine kevinjard...@gmail.com wrote:
My goal was to find a way to define all that was needed using
Haskell's automatic instance deriving mechanism. Haskell can
automatically derive Foldable, which is why I was looking at that.
However, that requires writing two lines for each wrapper newtype to
get around the kind problem.
I wanted one line.
There:
newtype Blog= Blog{ getBlogObj:: Obj }
newtype Comment = Comment { getCommentObj :: Obj }
newtype User= User{ getUserObj:: Obj }
class GetObject a where getObject :: a - Obj
instance GetObject Blogwhere getObject = getBlogObject
instance GetObject Comment where getObject = getCommentObject
instance GetObject Userwhere getObject = getUserObject
You shouldn't abuse Foldable for this purpose, unless you really mean
it.
I agree that the Foldable solution was a bit of a kludge.
And not necessary either.
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife = sex)
http://ertes.de/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: recommendations for reading list?
David Leimbach wrote: In my amazon shopping cart I currently have: *Conceptual Mathematics: A First Introduction to Categorieshttp://www.amazon.com/gp/product/052171916X/ref=ord_cart_shr?ie=UTF8m=ATVPDKIKX0DER *- F. William Lawvere Lawvere is widely regarded as being very accessible. The introductory chapter can be read online at Amazon, if you want to get a flavour. I've only read a couple of chapters of it myself, in a borrowed copy, but I was impressed. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Unwrapping newtypes
Hi Ertugrul,
if you look back earlier in this thread, you'll see that
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
allows me to write genuine one line definitions for each wrapper type.
Eg.
newtype Blog = Blog Obj deriving ToObj
There is no need to code the instances as GHC will do that for you.
Figuring out how to avoid writing the instances was the point of my
original post.
Kevin
On Sep 9, 11:10 am, Ertugrul Soeylemez e...@ertes.de wrote:
Kevin Jardine kevinjard...@gmail.com wrote:
My goal was to find a way to define all that was needed using
Haskell's automatic instance deriving mechanism. Haskell can
automatically derive Foldable, which is why I was looking at that.
However, that requires writing two lines for each wrapper newtype to
get around the kind problem.
I wanted one line.
There:
newtype Blog = Blog { getBlogObj :: Obj }
newtype Comment = Comment { getCommentObj :: Obj }
newtype User = User { getUserObj :: Obj }
class GetObject a where getObject :: a - Obj
instance GetObject Blog where getObject = getBlogObject
instance GetObject Comment where getObject = getCommentObject
instance GetObject User where getObject = getUserObject
You shouldn't abuse Foldable for this purpose, unless you really mean
it.
I agree that the Foldable solution was a bit of a kludge.
And not necessary either.
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife = sex)http://ertes.de/
___
Haskell-Cafe mailing list
haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Handling platform- or configuration-specific code (or, my CPP complaints)
Malcolm Wallace malcolm.wallace at me.com writes: I agree that CPP used only for conditional compilation, is much more acceptable than using it for macros as well. And co-incidentally, cpphs has a --nomacro flag. So that's basically what the C# preprocessor does? http://msdn.microsoft.com/en-us/library/ed8yd1ha(v=VS.100).aspx ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
Since GHC 6.14 will (hopefully) be use LLVM as a default backend, an idea has occured to me Should GHC also use the clang (C/C++-LLVM compiler) on external C library sources which are used with certain Haskell packages (such as gtk) when LLVM does become a default backend for GHC. The consensus is that since Clang will also produce LLVM 'assembler', it can be very easily linked with the LLVM 'assembler' produced by GHC's LLVM backend, making the process of using external C sources a lot easier. Parts of Clang required could even be integrated into GHC (although this may be tricky since its coded in C++). It should also hopefully make using Haskell packages on windows that use C sources less painful Clang could also make using FFI with C++ much easier (for reasons stated above) Thoughts? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell, arrows and signal processing
Am Mittwoch, den 08.09.2010, 11:47 -0300 schrieb Rafael Gustavo da Cunha Pereira Pinto: The input and output are infinite streams. I have a few questions: 1) Is it possible to change it to use arrows? How would it look like? 2) How would one implement an continuous time version? Have you had a look at Yampa? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage package download count
Is there anywhere we can see the number of download for a particular package, especially ones you maintain yourself? Thanks, Tony ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News
I miss the Haskell Weekly News. The most recent issue was published on 8th March 2010. The volunteer who produces it claimed on 27th April that he would be back in action soon, implying that once a couple of weeks' worth of university classes were finished, HWN would return. So in the absence of any visible movement, and it now being Sept, can I appeal for a new volunteer to take over? There is more info here: http://www.haskell.org/haskellwiki/HWN Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
I'm not sure using Clang would make it any *easier* to use external sources, but it could provide opportunities for optimizing across the C/Haskell boundary. The main difficulty in getting it all working correctly is the linking step. The Mac OSX linker can [link together llvm bitcode][1] for link-time optimization, but the support on Linux is less mature. You have to use the [gold linker][2] if you want to optimize bitcode at link time. I made an attempt in May to compile the GHC runtime with Clang. The process is documented in this [blog post][3]. I was interested in using LLVM's link-time optimization to optimize parts of the runtime together with a compiled Haskell program. While I never got that far, just getting the GHC runtime to compile with Clang was a bit difficult. It uses some GCC specific extensions (pinned global registers, and __thread for thread local data) that did not work well with Clang. In particular, lack of support for these two extensions made it impossible to compile the threaded runtime. I think it would be very interesting to see what kind of performance benefits we could get from using the LLVM backend in GHC to link with LLVM bitcode generated by Clang. [1] http://developer.apple.com/library/mac/releasenotes/DeveloperTools/RN-llvm-gcc/index.html#//apple_ref/doc/uid/TP40007133-CH1-SW14 [2] http://llvm.org/docs/GoldPlugin.html [3] http://www.dmpots.com/blog/2010/05/08/building-ghc-with-clang.html On Sep 9, 2010, at 7:10 AM, Mathew de Detrich wrote: Since GHC 6.14 will (hopefully) be use LLVM as a default backend, an idea has occured to me Should GHC also use the clang (C/C++-LLVM compiler) on external C library sources which are used with certain Haskell packages (such as gtk) when LLVM does become a default backend for GHC. The consensus is that since Clang will also produce LLVM 'assembler', it can be very easily linked with the LLVM 'assembler' produced by GHC's LLVM backend, making the process of using external C sources a lot easier. Parts of Clang required could even be integrated into GHC (although this may be tricky since its coded in C++). It should also hopefully make using Haskell packages on windows that use C sources less painful Clang could also make using FFI with C++ much easier (for reasons stated above) Thoughts? ___ 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] Hackage package download count
tonyhannan2: Is there anywhere we can see the number of download for a particular package, especially ones you maintain yourself? Nothing terribly automated, but the status for the last quarter: http://donsbot.wordpress.com/2010/06/30/popular-haskell-packages-q2-2010-report/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News
I'd like to do it. Any tips? -deech On Thu, Sep 9, 2010 at 9:35 AM, Malcolm Wallace malcolm.wall...@me.com wrote: I miss the Haskell Weekly News. The most recent issue was published on 8th March 2010. The volunteer who produces it claimed on 27th April that he would be back in action soon, implying that once a couple of weeks' worth of university classes were finished, HWN would return. So in the absence of any visible movement, and it now being Sept, can I appeal for a new volunteer to take over? There is more info here: http://www.haskell.org/haskellwiki/HWN Regards, Malcolm ___ 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] problems using macports?
I am in my yearly fightto get a working combination of operating system (Snow Leopard), compiler version (6.12) , wxWidgets and wxHaskell on my Mac . After deleting most of my stuff, starting afresh, hours of building using macports etc. I finally get the message: loeki:Opgave doaitse$ ghc --make Turtle.hs [1 of 1] Compiling Main ( Turtle.hs, Turtle.o ) Linking Turtle ... Undefined symbols: _iconv_open, referenced from: _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) (maybe you meant: _hs_iconv_open) _iconv, referenced from: _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) _iconv_close, referenced from: _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) (maybe you meant: _hs_iconv_close) ld: symbol(s) not found collect2: ld returned 1 exit status loeki:Opgave doaitse$ Some Googling showed me that the same problem has shown up with Yi, The solution however is not there. Can someone enlighten me. Doaitse ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problems using macports?
S. Doaitse Swierstra doai...@swierstra.net writes: I am in my yearly fightto get a working combination of operating system (Snow Leopard), compiler version (6.12) , wxWidgets and wxHaskell on my Mac . After deleting most of my stuff, starting afresh, hours of building using macports etc. I finally get the message: loeki:Opgave doaitse$ ghc --make Turtle.hs [1 of 1] Compiling Main ( Turtle.hs, Turtle.o ) Linking Turtle ... Undefined symbols: _iconv_open, referenced from: _hs_iconv_open in libHSbase-4.2.0.2.a(iconv.o) (maybe you meant: _hs_iconv_open) _iconv, referenced from: _hs_iconv in libHSbase-4.2.0.2.a(iconv.o) (maybe you meant: _hs_iconv_open, _hs_iconv , _hs_iconv_close ) _iconv_close, referenced from: _hs_iconv_close in libHSbase-4.2.0.2.a(iconv.o) (maybe you meant: _hs_iconv_close) ld: symbol(s) not found collect2: ld returned 1 exit status loeki:Opgave doaitse$ Some Googling showed me that the same problem has shown up with Yi, The solution however is not there. Can someone enlighten me. Have you played with: cabal install --extra-include-dirs=/opt/local/include \ --extra-lib-dirs=/opt/local/lib ? Note that you have to compile all of your macports stuff as 32-bit or universal (/opt/local/etc/macports/variants.conf, uncomment +universal) in order for a 32-bit GHC to link with it. G -- Gregory Collins g...@gregorycollins.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [wxhaskell-users] problems using macports?
Hi Doaitse, On Thu, Sep 09, 2010 at 17:38:40 +0200, S. Doaitse Swierstra wrote: I am in my yearly fightto get a working combination of operating system (Snow Leopard), compiler version (6.12) , wxWidgets and wxHaskell on my Mac . After deleting most of my stuff, starting afresh, hours of building using macports etc. I finally get the message: I may have had a similar problem back in March: http://www.mail-archive.com/wxhaskell-us...@lists.sourceforge.net/msg00827.html Don't know if my explanation is sensible or not. -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow For a faster response, try +44 (0)1273 64 2905 or xmpp:ko...@jabber.fr (Jabber or Google Talk only) pgpW8LxWnWPFb.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [wxhaskell-users] problems using macports?
On Thu, Sep 9, 2010 at 17:44, Eric Y. Kow wrote: On Thu, Sep 09, 2010 at 17:38:40 +0200, S. Doaitse Swierstra wrote: I am in my yearly fightto get a working combination of operating system (Snow Leopard), compiler version (6.12) , wxWidgets and wxHaskell on my Mac . After deleting most of my stuff, starting afresh, hours of building using macports etc. I finally get the message: I may have had a similar problem back in March: http://www.mail-archive.com/wxhaskell-us...@lists.sourceforge.net/msg00827.html Don't know if my explanation is sensible or not. Your observation seems to agree with several other links at http://www.google.com/search?q=macports+iconv+link . Some of them suggest renaming the Mac OS X header file iconv.h (rather than not using MacPorts). Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Weekly News
I miss it too, I've got one person set up (or in the process of setting up) to take it over. I'll be happy to help anyone else get set up (the tools are nontrivial to use at first). The current plan, when I finally get back on my feet, is to have multiple editors trading off weeks/months/ timeframetobedetermined to minimize downtime such as this. I would like to really apologize to the community, I had thought I had the problems fixed, then I ran into some financial difficulties, and couldn't finish fixing the machine. Pride kept me from asking for someone to take over the HWN in my absence, that was silly, you guys would (as I can see) have jumped at the chance to help. Please send me an email if you'd like to help, I have a little tutorial tome I can forward you that will get you set up, and we can work out a schedule with the other editor(s). Having 5 or 6 editors to cycle through will be ideal, I think, that way we have a fair amount of redundancy to prevent situations like this. /Joe On Sep 9, 2010, at 10:35 AM, Malcolm Wallace wrote: I miss the Haskell Weekly News. The most recent issue was published on 8th March 2010. The volunteer who produces it claimed on 27th April that he would be back in action soon, implying that once a couple of weeks' worth of university classes were finished, HWN would return. So in the absence of any visible movement, and it now being Sept, can I appeal for a new volunteer to take over? There is more info here: http://www.haskell.org/haskellwiki/HWN Regards, Malcolm ___ 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 using macports?
See if http://stackoverflow.com/questions/2726248/ghc-6-12-and-macports/3601842#3601842 is of any help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: AbortT-transformers version 1.0
Colin Paul Adams schrieb: Henning == Henning Thielemann lemm...@henning-thielemann.de writes: Henning On Wed, 8 Sep 2010, Gregory Crosswhite wrote: ExceptionT is a different matter because it handles fail as an uncaught error and places no restrictions on the error type, so one could implement the same functionality as AbortT by using ExceptionalT and requiring the end result be a monadic value of type ExceptionalT e m e, where the exception and result types are the same. However, I believe that it is better to have the AbortT functionality available as a separate simple library specialized for this purpose than to have its functionality buried inside a more general library that is really intended to be used for a different purpose. Henning If we get rid of the notion of an exception as being Henning something bad, and instead consider an exception as being Henning early exit for whatever reason, I see no problem. E.g. you Henning may well use an exception to terminate a successful search, Henning returning the search result as exception value. So where is the exceptional nature? Is a successful conclusion to a search so exceptional? You search as long as you don't find what you are looking for. So not finding what you search seems to be the rule and finding it seems to be the exception. :-) It seems to me that you want to get rid of the notion of an exception as something exceptional, in which case it would be better to give it a different name. English is not my native tongue. If 'abort' is more appropriate than 'exception' we may rename modules from Exception to Abort. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage package download count
On 9 September 2010 14:56, Tony Hannan tonyhann...@gmail.com wrote: Is there anywhere we can see the number of download for a particular package, especially ones you maintain yourself? And the new hackage server implementation maintains download counts. See the server test instance here: http://sparky.haskell.org:8080/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell, arrows and signal processing
Just found it! It is pretty much what I was looking for, On Thu, Sep 9, 2010 at 10:08, Wolfgang Jeltsch g9ks1...@acme.softbase.orgwrote: Am Mittwoch, den 08.09.2010, 11:47 -0300 schrieb Rafael Gustavo da Cunha Pereira Pinto: The input and output are infinite streams. I have a few questions: 1) Is it possible to change it to use arrows? How would it look like? 2) How would one implement an continuous time version? Have you had a look at Yampa? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Rafael Gustavo da Cunha Pereira Pinto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] BPMN and BPEL
Thank you for your advice, Actually, I'm not comfortable with C# at all... I'm gonna be learning it as I develop the application. Also helpful are various Haskell-inspired features added to C# in the last few years, making it feasible to port a large subset of Haskell to C# fairly directly. What kind of features are those you mention? I'd like to know in advance in order to search them before I start to do anything, even if I'm not going to use Haskell, knowing those features might help me to get a high level of abstraction in C# (or not). On Wed, Sep 8, 2010 at 4:46 PM, C. McCann c...@uptoisomorphism.net wrote: On Wed, Sep 8, 2010 at 3:38 PM, Hector Guilarte hector...@gmail.com wrote: If somebody can point out really good reasons on why I should use Haskell to do my work, please let me know them, they might help me convincing my bosses. On the other hand, if you believe Haskell is a bad language for this kind of task, and why C# or any other .NET language would be better, I'm welcome to hear your reasons, they might convince me. Well, how comfortable are you with Haskell? If you're roughly as proficient in it as you are in C#, you could probably bang out a prototype using Haskell in a fraction of the time with fewer bugs. Most software projects get massively revised from the initial version anyway, so using a more productive language and then rewriting for the production version can still be a net win, especially since you can use the prototype as a specification or reference implementation (e.g., you get some QA for free by running the two on identical input and checking for identical output). And of course, maintenance and scalability don't matter in a prototype. If it goes well, you'll have proven that Haskell has value (without forcing a long-term, up-front commitment to it), probably improved the quality of the C# version, and gotten the chance to write Haskell at work. Furthermore, in this particular case, you say it's a mapper between data description languages. While I obviously don't know the details, applying transformations to complex, easily-inspected data structures is a classic example of a problem ideally suited to a functional language with pattern matching, be it Haskell, F#, or any other ML-influenced language--thus making Haskell even more advantageous for rapid prototyping. Also helpful are various Haskell-inspired features added to C# in the last few years, making it feasible to port a large subset of Haskell to C# fairly directly. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell, arrows and signal processing
Rafael Gustavo da Cunha Pereira Pinto schrieb: The input and output are infinite streams. I have a few questions: 1) Is it possible to change it to use arrows? How would it look like? 2) How would one implement an continuous time version? For 2) I would like to implement something like that digital integrator, so I could create filters based on integrator loops like this one: x(t) (+) Integrator --|--- y(t) ^| || Note that x(t) would be a function, and I would expect to create a function y, based on this flow! If you look for Arrows, Signal processing _and_ real-time efficiency, then you might be interested in my experiments with LLVM: http://www.youtube.com/watch?v=GNiAqBTVa6U http://arxiv.org/abs/1004.4796 http://code.haskell.org/synthesizer/llvm/ (you need some more repositories like http://code.haskell.org/~thielema/llvm-2.6/, http://code.haskell.org/synthesizer/alsa/ ... no fun of installation currently because I could not achieve to get some patches to llvm to hackage.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] installing GHC/Haskell Platform in Linux without root permission
Is it possible to install either of these (preferably the latter) somewhere in my home directory without having root permission? I tried the unknown linux package with configure --prefix set to a subdir in my home, to no avail. The problem seems to be due to some library registration which fails. thanks Ali ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] installing GHC/Haskell Platform in Linux without root permission
ali.razavi: Is it possible to install either of these (preferably the latter) somewhere in my home directory without having root permission? I tried the unknown linux package with configure --prefix set to a subdir in my home, to no avail. The problem seems to be due to some library registration which fails. Assuming you have GHC installed, the Haskell Platform Linux generic source installer will install without root privledges. If that doesn't work for you, file a bug with a log of what failed on the HP bug tracker. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage package download count
Nice, thanks, looking forward to it. On Thu, Sep 9, 2010 at 12:14 PM, Duncan Coutts duncan.cou...@googlemail.com wrote: On 9 September 2010 14:56, Tony Hannan tonyhann...@gmail.com wrote: Is there anywhere we can see the number of download for a particular package, especially ones you maintain yourself? And the new hackage server implementation maintains download counts. See the server test instance here: http://sparky.haskell.org:8080/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] installing GHC/Haskell Platform in Linux without root permission
Unfortunately I don't have ghc installed. Can I install it without root priv? On Sep 9, 2010, at 1:40 PM, Don Stewart d...@galois.com wrote: ali.razavi: Is it possible to install either of these (preferably the latter) somewhere in my home directory without having root permission? I tried the unknown linux package with configure --prefix set to a subdir in my home, to no avail. The problem seems to be due to some library registration which fails. Assuming you have GHC installed, the Haskell Platform Linux generic source installer will install without root privledges. If that doesn't work for you, file a bug with a log of what failed on the HP bug tracker. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell, arrows and signal processing
The input and output are infinite streams. I have a few questions: 1) Is it possible to change it to use arrows? How would it look like? 2) How would one implement an continuous time version? Yampa can do *exactly* what you're asking for. Unfortunately the code seems to be a little rough and there are many space leaks (some of which are alluded to in the source code comments). Definitely make sure to profile memory usage as you code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] installing GHC/Haskell Platform in Linux without root permission
On Thursday 09 September 2010 20:23:13, Ali Razavi wrote: Unfortunately I don't have ghc installed. Can I install it without root priv? That ought to work. I just unpacked and installed ghc-6.8.3-i386-unknown- linux.tar.bz2 in a subdir of $HOME without root privileges. (I would've tried a newer release, but I had the 6.8.3 vanilla binary just happening to lie around.) So in principle it works, if it doesn't work with a later vanilla linux binary, that would be a surprise (and a bug), but then you could use an older one to build from source (that works, promised, I have done that a lot). On Sep 9, 2010, at 1:40 PM, Don Stewart d...@galois.com wrote: ali.razavi: Is it possible to install either of these (preferably the latter) somewhere in my home directory without having root permission? I tried the unknown linux package with configure --prefix set to a subdir in my home, to no avail. The problem seems to be due to some library registration which fails. Assuming you have GHC installed, the Haskell Platform Linux generic source installer will install without root privledges. If that doesn't work for you, file a bug with a log of what failed on the HP bug tracker. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: AbortT-transformers version 1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/8/10 18:43 , Henning Thielemann wrote: On Wed, 8 Sep 2010, Gregory Crosswhite wrote: ExceptionT is a different matter because it handles fail as an uncaught error and places no restrictions on the error type, so one could implement the same functionality as AbortT by using ExceptionalT and requiring the end result be a monadic value of type ExceptionalT e m e, where the exception and result types are the same. However, I If we get rid of the notion of an exception as being something bad, and instead consider an exception as being early exit for whatever reason, I see no problem. E.g. you may well use an exception to terminate a successful search, returning the search result as exception value. But that's not an *exception*. It's probably best referred to as a signal (of the Qt/Gtk+ variety, not the Unix one). - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyJM1EACgkQIn7hlCsL25VpRwCeNPcG9JVvLBqpCXCKynA4zwDe 5gIAnioNUIytSOxLiNqGv8wryOvBxWY3 =w2i0 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: AbortT-transformers version 1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/9/10 12:16 , Henning Thielemann wrote: Colin Paul Adams schrieb: Henning == Henning Thielemann lemm...@henning-thielemann.de writes: Henning On Wed, 8 Sep 2010, Gregory Crosswhite wrote: ExceptionT is a different matter because it handles fail as an uncaught error and places no restrictions on the error type, so one could implement the same functionality as AbortT by using ExceptionalT and requiring the end result be a monadic value of type ExceptionalT e m e, where the exception and result types are the same. However, I believe that it is better to have the AbortT functionality available as a separate simple library specialized for this purpose than to have its functionality buried inside a more general library that is really intended to be used for a different purpose. Henning If we get rid of the notion of an exception as being Henning something bad, and instead consider an exception as being Henning early exit for whatever reason, I see no problem. E.g. you Henning may well use an exception to terminate a successful search, Henning returning the search result as exception value. So where is the exceptional nature? Is a successful conclusion to a search so exceptional? You search as long as you don't find what you are looking for. So not finding what you search seems to be the rule and finding it seems to be the exception. :-) It seems to me that you want to get rid of the notion of an exception as something exceptional, in which case it would be better to give it a different name. English is not my native tongue. If 'abort' is more appropriate than 'exception' we may rename modules from Exception to Abort. Abort is even worse, as it implies *ab*normal termination (to my mind, at least, this suggests something closer to error than exception). In some sense this seems closer to Prolog's cut than any kind of exception. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyJNAEACgkQIn7hlCsL25U2mwCggCsGcC1zJAjqmW+7tiXLlQ9i LGEAnig9tA2HZOc3uhVS6sDHLPuufCA2 =lmI1 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] CAL experience
Hello, as this is really friendly forum, I'd like to ask to perhaps solve my wonder. From time to time I'm seeing people here recommending Scala as a kind of replacement for non-existent Haskell on Java/JVM platform. My wonder is: why the people here do not recommend CAL, which at least to me, looks much more closer to Haskell than Scala is. Are there any bad experiences with this language and OpenQuark platform? I'm asking since I'm currently playing with it and plan to use it for java objects data processing. Thanks, Karel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CAL experience
karel.gardas: Hello, as this is really friendly forum, I'd like to ask to perhaps solve my wonder. From time to time I'm seeing people here recommending Scala as a kind of replacement for non-existent Haskell on Java/JVM platform. My wonder is: why the people here do not recommend CAL, which at least to me, looks much more closer to Haskell than Scala is. Are there any bad experiences with this language and OpenQuark platform? I'm asking since I'm currently playing with it and plan to use it for java objects data processing. Since Business Objects was aquired by SAP, development has slowed. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] malicious JS on haskell site
Hello cafe, Maybe malicious isn't the right word but there is a JS based web counter on http://www.haskell.org/complex/why_does_haskell_matter.html which likes to show pop up adverts. They must have switched over from counting visitors to showing adverts at some point since the web page was created. I'm sure this is something we want removed... It would probably be good to grep the whole server to make sure that this counter doesn't show up on some other page too. Sorry if this is a simple oversight on my part but I don't know who I should be contacting about this kind of thing. It would be great if there was some kind of webmas...@haskell.org address that was advertised or some form that we could submit for issues like this. -keith -- keithsheppard.name ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Style and a problem
Am 09.09.2010 22:55, schrieb Wanas: Hey all, So I have a two part question (I'm new to haskell, so you can throw all your mugs at me). a) I want to write a function that generates lists of lists of size $n$. All having the property that sum lst = sum [1..n]. a-1) After that, I want to remove all permutations. My idea of doing this is to get all lists from the first function and create a new list with the property that if sorted list A is not in the list, add it. b-2) I think that's too much questions, but I want to get the hang of this quickly (it was kickass for the few things I've tried out). Something like this? import Data.List newList :: Int - [[Int]] newList n = myNub [ l | l - undefined -- not really sure how you want -- to generate these lists :) , sum l == sum [1..n] ] myNub :: (Ord a) = [[a]] - [[a]] myNub = nubBy (\a b - sort a == sort b) - Nils ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Style and a problem
On Thursday 09 September 2010 22:55:14, Wanas wrote: Hey all, So I have a two part question (I'm new to haskell, so you can throw all your mugs at me). a) I want to write a function that generates lists of lists of size $n$. All having the property that sum lst = sum [1..n]. a-1) After that, I want to remove all permutations. My idea of doing this is to get all lists from the first function and create a new list with the property that if sorted list A is not in the list, add it. It's better to not create equivalent lists from the beginning. For n = 12, for example, there are almost 500 million (479001600) permutations of [1 .. 12], that's a lot of wasted work if you create them all and throw away all but one. Assuming that the list elements should be positive (or at least non- negative), what you want is to create the partitions of a target sum with a given length. Such a partition can be represented as a list of pairs (number, multiplicity) with the properties a) the sum of the multiplicities is the target length sum (map snd partition) == targetLength b) the sum of (number * multiplicity) is the target sum sum [n * m | (n,m) - partition] == targetSum Such a representation is unique if you demand that the numbers (map fst partition) form a strictly decreasing (or increasing, but decreasing is simpler to construct) list and all multiplicities are strictly positive. So you want a function buildPartitions :: Integer - Integer - Integer - [[(Integer,Integer)]] buildPartitions targetSum targetLength maxNumber should create the list of all essentially different partitions of targetSum into exactly targetLength positive (non-negative) numbers not greater than maxNumber. There are two sorts of such partitions, those containing maxNumber and those which don't, hence buildPartitions targetSum targetLength maxNumber = listOne ++ listTwo where listTwo = buildPartitions targetSum targetLength (maxNumber - 1) and listOne is constructed per - for all multiplicities mul from 1 to some limit - for all partitions part of (targetSum - mul*maxNumber) with length (targetLength - mul) into positive numbers maxNumber - prefix (maxNumber, mul) to part Of course, for there to be any such partitions, some conditions have to be met: targetSum = targetLength*maxNumber targetSum = targetLength (if the numbers have to be strictly positive) With these conditions in mind for the recursive call, you can efficiently generate the list of all essentially different partitions via buildPartitions targetSum targetLength maxNumber = [(maxNumber, mul) : part | mul - [1 .. maxMul] , part - buildPartitions newSum newLength newMax] ++ buildPartitions targetSum targetLength (maxNumber-1) with appropriate values of maxMul and newMax (newMax can often be smaller than maxNumber-1) and a few cases to end the recursion (when no or only one partition is possible). Then you have to flatten the [(Integer, Integer)] lists into [Integer] lists, for example per flatten ps = [n | (n,m) - ps, _ - [1 .. m]] b-2) I think that's too much questions, but I want to get the hang of this quickly (it was kickass for the few things I've tried out). Thanks, \/\/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Style and a problem
Hello Wanas, Friday, September 10, 2010, 12:55:14 AM, you wrote: a) I want to write a function that generates lists of lists of size $n$. All having the property that sum lst = sum [1..n]. a-1) After that, I want to remove all permutations. My idea of you have very interesting questions. hopefully it was already answered at http://www.haskell.org/haskellwiki/Homework_help -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Style and a problem
Although it was phrased as one, it wasn't. If it were a homework question, wouldn't you think that I'd be trained to do it or have a TA to ask? But who said that you're accusing me of anything :) Thanks for your concern, Bulat. \/\/ On Fri, Sep 10, 2010 at 1:47 AM, Bulat Ziganshin bulat.zigans...@gmail.comwrote: Hello Wanas, Friday, September 10, 2010, 12:55:14 AM, you wrote: a) I want to write a function that generates lists of lists of size $n$. All having the property that sum lst = sum [1..n]. a-1) After that, I want to remove all permutations. My idea of you have very interesting questions. hopefully it was already answered at http://www.haskell.org/haskellwiki/Homework_help -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] malicious JS on haskell site
On 10-09-09 05:30 PM, Keith Sheppard wrote: Maybe malicious isn't the right word but there is a JS based web counter on http://www.haskell.org/complex/why_does_haskell_matter.html which likes to show pop up adverts. They must have switched over from counting visitors to showing adverts at some point since the web page was created. The web counter is obtained from script language=JavaScript src=http://m1.nedstatbasic.net/basic.js;/script Instead of doing static analysis on the javascript code, I decided to exploit society instead. Googling nedstatbasic, I found this (though not 1st hit): http://www.nedstat.com/nedstat-news-archive/129-nedstat-sells-nedstat-basic-to-ad-pepper-media Looks like the free web counter was sold to an advertiser as few years ago. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
I am not that familiar with LLVM, if anything it complicates matters, rather than making things easier. The llvm-ld program has limited support for native code generation, when using the -native or -native-cbe options. Native code generation is performed by converting the linked bitcode into native assembly (.s) or C code and running the system compiler (typically gcc) on the result. so it seems that the gcc support infrastructure that is currently integrated into ghc will still be required. Then the question arises what library formats will ghc use under the circumstances ?(.bc, .a) and how will the two be integrated? On windows, most c/c++ public domain libraries are either compiled with ms-c or gcc which have their standard library formats. which in many cases come pre-compiled with the libraries. Becuase of this I would assume retention of the .a format, but perhaps compiling haskell to .bc would offer opportunities for link time optimisation? In fact I would like a lot more information on what is being proposed with respect of a LLVM backend and any changes to the compiler tool chain. Since GHC 6.14 will (hopefully) be use LLVM as a default backend, an idea has occured to me Should GHC also use the clang (C/C++-LLVM compiler) on external C library sources which are used with certain Haskell packages (such as gtk) when LLVM does become a default backend for GHC. The consensus is that since Clang will also produce LLVM 'assembler', it can be very easily linked with the LLVM 'assembler' produced by GHC's LLVM backend, making the process of using external C sources a lot easier. Parts of Clang required could even be integrated into GHC (although this may be tricky since its coded in C++). It should also hopefully make using Haskell packages on windows that use C sources less painful Clang could also make using FFI with C++ much easier (for reasons stated above) Thoughts? ___ 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] Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
On Thu, Sep 9, 2010 at 9:08 PM, John Lask jvl...@hotmail.com wrote: so it seems that the gcc support infrastructure that is currently integrated into ghc will still be required. Then the question arises what library formats will ghc use under the circumstances ?(.bc, .a) and how will the two be integrated? As far as I know, the same files are used. See [1], for example. [1] http://llvm.org/docs/GoldPlugin.html Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
On 9 September 2010 22:10, Mathew de Detrich dete...@gmail.com wrote: It should also hopefully make using Haskell packages on windows that use C sources less painful Clang could also make using FFI with C++ much easier (for reasons stated above) Thoughts? I don't think it would make it any easier to use C/C++ from Haskell at the moment. LLVM for static compilation works by compiling to assembly. After that it has no support. So we use gcc to finish off the rest of the job; producing object code and linking. There is a pretty cool project going on in LLVM at the moment of integrating an assembler into LLVM so that it can directly produce object code. This should mean that the LLVM backend wouldn't need gcc anymore (but obviously gcc will still be needed by ghc as a whole). As David Peixotto mentioned though, the ghc runtime can't be built by clang. There is probably a few reason but a main one is that Clang doesn't support gcc's global register variable extension (register pinning). The LLVM guys also have no plans to support this feature so unless we want to stop using this extension we are stuck with using gcc. I think the main advantage to trying to use Clang for compiling C/C++ would be that it would enable us to do whole program optimisation across Haskell and C/C++. It could also make cross compiling slightly easier. These ideas are defiantly something I'd like to investigate more in the future. On 10 September 2010 10:08, John Lask jvl...@hotmail.com wrote: In fact I would like a lot more information on what is being proposed with respect of a LLVM backend and any changes to the compiler tool chain. What would you like to know? If you're talking just about the new LLVM backend for GHC (not the proposal here of using clang) then the effect on the end user is nothing. The LLVM backend compiles an individual Haskell module to LLVM assembly, which is then compiled to native assembly by the 'llc' tool. This gets you now to the same place as the native code generator, where gcc is used to compiled the assembly to an object file. Obviously there is a new dependency on having LLVM 2.7 or greater installed but that should be it. Cheers, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
This is the main thing I was getting behind, making cross compiling slightly easier (in regards to C/C++ sources). As also pointed out, whole program optimization can be one major benefit to integrating Clang like this. On Fri, Sep 10, 2010 at 11:01 AM, David Terei dave.te...@gmail.com wrote: I think the main advantage to trying to use Clang for compiling C/C++ would be that it would enable us to do whole program optimisation across Haskell and C/C++. It could also make cross compiling slightly easier. These ideas are defiantly something I'd like to investigate more in the future. Cheers, David ___ 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] Style and a problem
On Sep 10, 2010, at 8:55 AM, Wanas wrote:
Hey all,
So I have a two part question (I'm new to haskell, so you can throw all your
mugs at me).
a) I want to write a function that generates lists of lists of size $n$. All
having the property that sum lst = sum [1..n].
a-1) After that, I want to remove all permutations. My idea of doing this is
to get all lists from the first function and create a new list with the
property that if sorted list A is not in the list, add it.
It's not completely clear to me what you want.
Here's my take on it:
S0 = {L | L is a list of positive integers and sum L = n}
L1 ~~ L2 iff L2 is a permutation of L1
You want to enumerate S0/~~.
Staring at this for a bit, what you want is
ENUMERATING THE PARTITIONS OF AN INTEGER.
Look this up in almost any combinatorics book and you will find an
algorithm that you can adapt. There's stuff in Knuth, AOCP, Vol 4,
for example. A good reference is The Theory of Partitions, by
G. E. Andrews, Cambridge University Press, 1998.
Rung-Bin Lin has reported in Efficient Data Structures for Storing
the Partitions of an Integer on a data structure for representing
all the partitions of an integer n in O(n**2) space, taking O(n**2)
time to construct it, so a list of lists might not be the best way
to do it in Haskell.
What you want to do is to generate the partitions in a canonical
order with no duplicates in the first place. Something along these
lines:
the partiions of n are
the partitions of n into pieces no bigger than n with [] appended.
the partitions of n into pieces no bigger than k with xx appended are
the partitions of n-k into pieces no bigger than k with k::xx appended
followed by
the partitions of n into pieces no bigger than k-1 with xx appended
*with* some termination clauses which I haven't shown.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On 9/9/10 1:04 AM, David Menendez wrote: Fascinating. I figured there might be a counter-example involving seq, but this is pretty subtle. In particular, would it be fair to say that in Haskell-without-seq, E (f a) a and E (f a) (f a) are indistinguishable? Yes, I think that without polymorphic seq (or within a strict language) they are observationally equivalent. But, observational equivalence is not the same as equality. And the category theoretic laws really do mean equality. To pick an example: consider the case where 'a' is an enormous data structure and (f a) returns some small value. Even though (E (f a) a) and (E (f a) (f a)) are observationally equivalent within Haskell, they're still observationally distinct from outside of the language because they have very different memory profiles. (We may need to make E strict in the second argument, or NOINLINE impure, in order to guarantee this behavior.) Thus, the equality still fails, though this may go undetected for a long time until someone notices the memory leak. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Handling platform- or configuration-specific code (or, my CPP complaints)
On 09/09/2010 00:54, wren ng thornton wrote: On 9/7/10 3:10 PM, Ben Millwood wrote: So I wonder what people think of the use of CPP in Haskell code, what alternatives people can propose, or what people hope to see in future to make conditional compilation of Haskell code more elegant and simple? The only thing I ever use CPP for in Haskell is top-level conditional definitions. * That is, say I have a function foo which has a vanilla Haskell definition, but also has a special definition for GHC performance hackery, or which needs a special definition on some compilers in order to correct compiler-specific bugs. I'll use #ifdef here to give the different versions. I'll also occasionally do this for things like choosing whether to use the FFI vs a native definition, for debugging purposes. * Another example is when using GeneralizedNewtypeDeriving in GHC, but still wanting to give normal definitions for other compilers to use. * The only other example I can think of is when defining Applicative instances, since I only want to do that when linking against versions of base which are new enough to have it. Occasionally you can get similar issues re ByteString vs base. In general, I think using CPP for actual macro processing is extremely poor style and can easily make code inscrutable (and no doubt bug-prone). If the Haskell spec were to add support for this sort of top-level compiler/compiletime-flag conditional definition, I'd switch over. This matches the style in most of the code I've looked at. And it also means that the incompatibilities are localized and hidden from most client code. Depending on the nature of your library API conflict, if you can localize things into a few definitions of the core functions you use in the rest of your code, then that'd be best. But that's not always possible. I've yet to run into the case where I really need to support incompatible versions of a library when it's that closely integrated, so I don't have much advice there. I'm afraid I instigated the CPP-vs-no-CPP issue with a patch I sent to Ben that adds backwards compatibility for GHC 6.10 to the haskell-src-meta package. Unfortunately the Template Haskell AST data type changed between the version of the library that works with 6.10 and the version that works with 6.12, and I used CPP and cabal's MIN_VERSION_* macro to conditionally compile the appropriate code. For example, unlike the previous version of the library, the AST data type for patterns in the 6.12-compatible version of the template-haskell package includes a case for bang patterns. I worked around this by using CPP to conditionally compile the case that handles translating bang patterns between the template-haskell and haskell-src-exts representations only when the new version of the template-haskell library is present. The problem with having completely separate implementations in different source code files for different versions of the template-haskell library instead of using CPP is that the rest of the pattern translation function then has to be duplicated. The question isn't whether or not to use CPP for macro expansion---I think we all can agree that that is in bad taste ;) To quote Ben, the choice is between the following two options: 1. Use CPP and the macros defined by Cabal to conditionally include or exclude code for each version. 2. Use Cabal file conditionals to select hs-source-dirs containing those parts of the code (or even TH to help generate those parts of the code) that are specific to each configuration. I too dislike CPP, but I dislike duplicated code more. Within reason, I would prefer to be able to find a function's implementation in a single file even if that definition has a few conditionally-compiled parts. Geoff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: ecu-0.0.0
This package is a collection of programs that we use at Eaton to interact with, debug, and analyze data from vehicle ECUs (Electronic Control Unit: automotive speak for an embedded computer). The motivation to put this stuff on hackage is to encourage the use of Haskell in automotive electronics and to help standardize open data formats and protocols -- the most common formats and protocols in this industry are proprietary. (The other motivation for hackage is it makes it easy for us to distribute tool updates to our engineers and technicians in the field. :-) ) Most of these programs in this package read or write data on a CAN bus. At work we use Kvaser CAN cables, so these tools link in Kvaser's open source CAN driver library, canlib. However, we anticipate adding several tools that have nothing to do with CAN -- they could be general data analysis programs that could be applicable to other fields, not just automotive. My question is, is it possible for a user to select which programs to install within a given package? I could see where someone would want to install a data analysis tool, but not want to bother with separately installing Kvaser canlib. I had considered different packages for the individual tools, but that would get messy pretty quick, especially since many tools share a lot of common code. Another question: Can we get a Hackage category specifically for the use of Haskell in embedded systems? I didn't see anything that stood out. And one last question: The Kvaser canlib library has a different name depending on if the machine is Linux or Windows. What is the best way to configure the build based on the platform? Current I have the library name hard coded in the extra-libraries field in the cabal file. -Tom http://hackage.haskell.org/package/ecu http://github.com/tomahawkins/ecu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Restricted type classes
On Thu, Sep 9, 2010 at 11:33 PM, wren ng thornton w...@freegeek.org wrote: On 9/9/10 1:04 AM, David Menendez wrote: Fascinating. I figured there might be a counter-example involving seq, but this is pretty subtle. In particular, would it be fair to say that in Haskell-without-seq, E (f a) a and E (f a) (f a) are indistinguishable? Yes, I think that without polymorphic seq (or within a strict language) they are observationally equivalent. But, observational equivalence is not the same as equality. And the category theoretic laws really do mean equality. To pick an example: consider the case where 'a' is an enormous data structure and (f a) returns some small value. Even though (E (f a) a) and (E (f a) (f a)) are observationally equivalent within Haskell, they're still observationally distinct from outside of the language because they have very different memory profiles. (We may need to make E strict in the second argument, or NOINLINE impure, in order to guarantee this behavior.) Thus, the equality still fails, though this may go undetected for a long time until someone notices the memory leak. It seems like you could use a similar argument to show that fmap id /= id. Specifically, xs and map id xs are equivalent lists, but they occupy different locations in memory. By replacing xs with map id xs, you can come arbitrarily close to doubling a program's memory requirements. (You can also use pointer comparison to distinguish them, but I assume that doesn't count.) What about Set.map? We have forall s. Set.map id s == s, but the actual structure may not be identical. In principle, there's no way to observe the difference, but in practice you can do it by breaking the precondition on foldMap. Does that mean we can't consider Set.Set/Set.map a functor over the subcategory of ordered Haskell types? -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
I wonder if llvm-gcc supports it's own (gcc) extensions. If it supports then there is no need to stuck in clang right now. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
