[Haskell] [Fwd: Re: CFP - DAMP 2008 - Declarative Aspects of Multicore Programming]
[ posting on behalf of Manuel Hermenegildo [EMAIL PROTECTED]] Subject: CFP - DAMP 2008 - Declarative Aspects of Multicore Programming DAMP 2008: Workshop on Declarative Aspects of Multicore Programming San Francisco, CA, USA (colocated with POPL 2008) January 9, 2008 SUBMISSION DEADLINE: OCTOBER 26 Parallelism is going mainstream. Many chip manufactures are turning to multicore processor designs rather than scalar-oriented frequency increases as a way to get performance in their desktop, enterprise, and mobile processors. This endeavor is not likely to succeed long term if mainstream applications cannot be parallelized to take advantage of tens and eventually hundreds of hardware threads. Multicore architectures will differ in significant ways from their multisocket predecessors. For example, the communication to compute bandwidth ratio is likely to be higher, which will positively impact performance. More generally, multicore architectures introduce several new dimensions of variability in both performance guarantees and architectural contracts, such as the memory model, that may not stabilize for several generations of product. Programs written in functional or (constraint-)logic programming languages, or even in other languages with a controlled use of side effects, can greatly simplify parallel programming. Such declarative programming allows for a deterministic semantics even when the underlying implementation might be highly non-deterministic. In addition to simplifying programming this can simplify debugging and analyzing correctness. DAMP is a one-day workshop seeking to explore ideas in programming language design that will greatly simplify programming for multicore architectures, and more generally for tightly coupled parallel architectures.The emphasis willbe onfunctional and (constraint-)logic programming, but any programming language ideas that aim to raise the level of abstraction are welcome. DAMP seeks to gather together researchers in declarative approaches to parallel programming and to foster cross fertilization across different approaches. Specific topics include, but are not limited to: * suitability of functional and (constraint-)logic programming languages to multicore applications; * run-time issues such as garbage collection or thread scheduling; * architectural features that may enhance the parallel performance of declarative languages; * type systems and analysis for accurately knowing or limiting dependencies, aliasing, effects, and nonpure features; * ways of specifying or hinting at parallelism; * ways of specifying or hinting at data placement which abstract away from any details of the machine; * compilertechniques,automatic parallelization,automatic granularity control; * experiences of and challenges arising from making declarative programming practical; * technology for debugging parallel programs; * design and implementation of domain-specific declarative languages for multi-core; Submission: Submitted papers papers should not exceed 15 pages in LLNCS format. Submission is electronic via: http://www.easychair.org/DAMP2008/ Important dates: Paper submission:Oct 26 Notification to authors: Nov 30 Camera ready:Dec 14 Program Chair: Manuel Hermenegildo Technical University of Madrid / IMDEA-Software -- [EMAIL PROTECTED] University of New Mexico -- [EMAIL PROTECTED] Program Committee: Koen De Bosschere (U. of Gent, Belgium) Manuel Carro (Tech. U. of Madrid, Spain) Manuel Chakravarty (U. of New S. Wales, Australia) Clemens Grelck (U. of Luebeck, Germany) Dan Grossman (U. of Washington, USA) Suresh Jagannathan (Purdue U., USA) Pedro Lopez-Garcia (Tech. U. of Madrid, Spain) Lee Naish (Melbourne University, Australia) Leaf Petersen (Intel Corporation, USA) Enrico Pontelli (New Mexico State U., USA) John Reppy (U. of Chicago, USA) Vitor Santos-Costa (U. of Porto, Portugal) General Chairs: Leaf Petersen Neal Glew Intel Corporation Santa Clara, CA, USA [EMAIL PROTECTED] [EMAIL PROTECTED] URL: http://www.cliplab.org/Conferences/DAMP08 Past DAMPs: http://glew.org/damp2006 http://www.cs.cmu.edu/~damp -- -- --- Manuel Hermenegildo | Prof., C.S. Department Director, IMDEA-Software and CLIP Group |T.U. of Madrid (UPM) http://www.cliplab.org/herme| +34-91-336-7435 (W) -352-4819 (Fax) --- ___ Haskell mailing
Re: [Haskell] Re: Trying to install binary-0.4
Udo Stenzel [EMAIL PROTECTED] writes: [incompatibilities between recent libraries/cabal/ghc] I'm installing a GHC-6.8 snapshot, and compiling a bunch of libraries I need in the process (HTTP, HXT, and binary). No show-stoppers, but a lot of rewriting of the dependencies. At least ghc will tell me which package to add, and after a bunch of iterations of this, things work nicely. +1 to renaming the new base, and have 'base' be a compatibility package incorporating 'containers', 'array', etc, with compatible interfaces. (Versioning isn't as good, I think, because it's too common to specify just 'base' without any version. At least, I know I do.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Ketil Malde wrote: +1 to renaming the new base, and have 'base' be a compatibility package incorporating 'containers', 'array', etc, with compatible interfaces. (Versioning isn't as good, I think, because it's too common to specify just 'base' without any version. At least, I know I do.) There's currently no (easy) way to make a package that just re-exports the contents of other packages. I've been thinking about ways to do this recently, but I'm now convinced that adding direct support to Cabal and the rest of the packaging infrastructure to do this is the wrong way. I'll try to write down my thoughts and post it sometime. Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Udo Stenzel wrote: - Provide a known good cabal. Make sure it installs on GHC 6.6 and 6.4. Cabal 1.2 works all the way back to GHC 6.2. The recommended way to build new packages with an old GHC will be to upgrade Cabal first. - Start fixing dependencies. In progress for the GHC 6.8.1 release, I believe (dcoutts is on the case). - Refrain from renaming stuff. System.Posix is a fine name. Who renamed it? It's still called System.Posix AFAIK. - Refrain from always using the latest interface of everything. While we're at it, the ability to have multiple versions of a library installed under the same name is a recipe for desaster, too. It should be dropped, instead implementing Eternal Compatibility in Theory by encoding version numbers in module names. Personally I object to ECT, it's too heavy. I believe versioning belongs in the package system where it currently is. Sorry for the rant, but the situation was actually better before Cabal tried to fix everything and in the process broke both versions of GHC that are in widespread use right now. The main problem you seem to be running into is that base previously contained bytestring, but you need to upgrade bytestring in order to use binary, right? In that case, I think a reasonable hack is to modify the package configuration for base to move Data.ByteString from exposed-modules to hidden-modules (I'd be wary about removing it altogether). Perhaps the bytestring Setup.lhs should do this automatically when registering? Cheers, Simon ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] C++ bindings
Hi Wolfgang,
On Oct 12, 2007, at 15:22, Wolfgang Jeltsch wrote:
Hello,
what are good approaches for creating Haskell bindings to C++
libraries? The
most promising so far seems to create C wrappers around the C++
libraries and
then bind to them. Is it feasible to bind directly to C++ using
ccall by
relying on some standardized C++ ABI? What about H/Direct? Are
there any
other good ways?
Since the name mangling of C++ members, classes and functions are
compiler specific, I don't think there is a good way of directly
calling the C++ functions and methods. I wrapped all C++ methods of
my classes in C functions. I use the following structure:
C++ header file tvpi.hh:
#ifndef __TVPI_H
#define __TVPI_H
namespace Tvpi {
class Domain {
public:
Domain();
void joinWiden(Domain prev, mpz_class extrapolate);
};
#endif // __TVPI_H
==
C header file tvpi_c.h
#ifndef TVPI_C_H_
#define TVPI_C_H_
#ifdef __cplusplus
extern C {
#endif // __cplusplus
#undef TVPI_TYPE_DECLARATION
#define TVPI_TYPE_DECLARATION(Type) \
typedef struct Type ## _tag Type ## _t; \
typedef Type ## _t * Type ## _p; \
typedef Type ## _t const* const_ ## Type ## _p
TVPI_TYPE_DECLARATION(Domain);
Domain_p tvpiNew(void);
void tvpiFree(Domain_p d);
void tvpiJoin(Domain_p d1, Domain_p d2);
#ifdef __cplusplus
}
#endif // __cplusplus
#endif // TVPI_C_H_
==
C wrapper file, tvpi_c.cpp:
#include tvpi_c.h
#include tvpi.hh
using namespace Tvpi;
templateclass ToType, class FromType
const ToType* to_const(const FromType* x) {
return reinterpret_castconst ToType*(x);
}
templateclass ToType, class FromType
ToType* to_nonconst(FromType* x) {
return reinterpret_castToType*(x);
}
Domain_p tvpiNew() {
return to_nonconstDomain_t, Domain(new Domain());
}
void tvpiFree(Domain_p d) {
delete to_nonconstDomain, Domain_t(d);
}
Domain_p tvpiCopy(Domain_p d) {
return to_nonconstDomain_t, Domain
(new Domain(*to_constDomain, Domain_t(d)));
}
void tvpiJoin(Domain_p d1, Domain_p d2) {
mpz_class w(-1);
to_nonconstDomain, Domain_t(d2)-joinWiden(*to_nonconstDomain,
Domain_t(d1
), w);
}
==
I'm not claiming it's pretty, but it works on several g++ versions.
You also need to pass
something like -pgml g++ -optl -pg to ghc so it know that it should
link using g++ (and thereby linking against the C++ runtime).
Hope this helps,
Axel.
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] C++ bindings
Hello, what are good approaches for creating Haskell bindings to C++ libraries? The most promising so far seems to create C wrappers around the C++ libraries and then bind to them. Is it feasible to bind directly to C++ using ccall by relying on some standardized C++ ABI? What about H/Direct? Are there any other good ways? Thank you for any hints. Best wishes, Wolfgang ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Fingerprints and hashing
Neil Mitchell wrote: Hi Simon, We are all familiar with the idea of an MD5 checksum, which provides a reliable fingerprint for a file, usually 128 bits or so. If the file changes, the fingerprint is (almost) certain to do so too. There are lots of techniques: CRC, shar?, MD5, etc. I believe the basic operations are all in the Crypto library: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Crypto-3.0.3 - see Data.Digest.SHA1 and Data.Digest.MD5 - digest is simply another word for fingerprint in this sense. The Crypto library does indeed provide those operations, but the implementations are naive and hence extremely slow. Fine for hashing an individual password, but not appropriate for ten thousand identifiers in a compiler. b ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Simon Marlow [EMAIL PROTECTED] writes: +1 to renaming the new base, and have 'base' be a compatibility package incorporating 'containers', 'array', etc There's currently no (easy) way to make a package that just re-exports the contents of other packages. Presumably the hard way would be to simply compile a 'base' consisting of all the modules from those packages? Would that be an option? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Trying to install binary-0.4
Udo Stenzel wrote: - install exactly one version of cabal, 1.1.6.2, and *remove* all others, - ask ghc-pkg for the description of base, then edit Data.ByteString out of that and re-register it, I forgot, I also tried tar-1.0 on GHC 6.6, and had the same problem there. Even after updating Cabal, there was no way to install 'bytestring' due to the conflict with 'base'. A modified package description for 'base' helped. The reason that tar absolutely wants new stuff is 'instance MonadFix Get', which is not in binary-0.3. If you absolutely want users of GHC 6.6 to stick with binary-0.3, then you should provide a maintenance release binary-0.3.1. And we're back to Eternal Compatibility in Theory... -Udo signature.asc Description: Digital signature ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [GHC] #1758: misleading compiler error message in case of interface file inconsistency
#1758: misleading compiler error message in case of interface file inconsistency
-+--
Reporter: guest |Owner: igloo
Type: merge | Status: new
Priority: normal|Milestone:
Component: Compiler | Version: 6.6.1
Severity: normal| Resolution:
Keywords:| Difficulty: Unknown
Os: MacOS X | Testcase:
Architecture: powerpc |
-+--
Changes (by igloo):
* owner: = igloo
* type: bug = merge
Comment:
{{{
Mon Oct 8 14:49:58 BST 2007 Simon Marlow [EMAIL PROTECTED]
* error message fix (#1758)
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1758#comment:1
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1746: GADT bug with -O2
#1746: GADT bug with -O2 -+-- Reporter: igloo |Owner: igloo Type: merge | Status: closed Priority: normal|Milestone: 6.8.1 Component: Compiler | Version: 6.8 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Os: Unknown | Testcase: simpl019 Architecture: Unknown | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1746#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] #1743: debugger: confusion with shadowed bindings
#1743: debugger: confusion with shadowed bindings -+-- Reporter: simonmar |Owner: igloo Type: merge | Status: closed Priority: normal|Milestone: 6.8 branch Component: GHCi | Version: 6.8 Severity: minor | Resolution: fixed Keywords:| Difficulty: Moderate (1 day) Os: Unknown | Testcase: break026 Architecture: Unknown | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1743#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] #1733: RTS option -N not exposed at Haskell level
#1733: RTS option -N not exposed at Haskell level ---+ Reporter: [EMAIL PROTECTED] |Owner: igloo Type: merge | Status: closed Priority: normal |Milestone: 6.8.1 Component: libraries/base | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Os: Unknown | Testcase: Architecture: Unknown | ---+ Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Both merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1733#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] #1678: runIO does not catch userErrors, just causes code generation to fail silently
#1678: runIO does not catch userErrors, just causes code generation to fail silently -+-- Reporter: greenrd |Owner: igloo Type: merge | Status: closed Priority: normal|Milestone: 6.8.1 Component: Template Haskell | Version: 6.7 Severity: normal| Resolution: fixed Keywords: runIO regression | Difficulty: Unknown Os: Linux | Testcase: TH_runIO Architecture: x86_64 (amd64)| -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1678#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1680: Attempting to do foreign import with unboxed tuple return type causes GHC panic
#1680: Attempting to do foreign import with unboxed tuple return type causes GHC panic ---+ Reporter: sorear |Owner: igloo Type: merge | Status: closed Priority: normal |Milestone: 6.8 branch Component: Compiler (FFI) | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: Linux | Testcase: ccfail002 Architecture: x86 | ---+ Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1680#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] #1681: :abandon in an exception breakpoint can lead ghci to freeze later
#1681: :abandon in an exception breakpoint can lead ghci to freeze later -+-- Reporter: mnislaih |Owner: igloo Type: merge | Status: closed Priority: normal|Milestone: 6.8 branch Component: GHCi | Version: 6.8 Severity: normal| Resolution: fixed Keywords: debugger | Difficulty: Unknown Os: Unknown | Testcase: break025 Architecture: Unknown | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1681#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] #1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX)
#1391: forkProcess() in Schedule.c with -threaded should initialize mutexes in child process (POSIX) ---+ Reporter: thorkilnaur |Owner: igloo Type: merge | Status: closed Priority: high|Milestone: 6.8.1 Component: Runtime System | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Os: MacOS X | Testcase: forkprocess01(ghci) Architecture: powerpc | ---+ Changes (by igloo): * status: new = closed * resolution: = fixed Comment: All merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1391#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1758: misleading compiler error message in case of interface file inconsistency
#1758: misleading compiler error message in case of interface file inconsistency -+-- Reporter: guest |Owner: igloo Type: merge | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.6.1 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Os: MacOS X | Testcase: Architecture: powerpc | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1758#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] #1748: main-is argument cannot be hierarchical module
#1748: main-is argument cannot be hierarchical module -+-- Reporter: guest |Owner: igloo Type: merge | Status: closed Priority: normal|Milestone: Component: Compiler | Version: 6.9 Severity: normal| Resolution: fixed Keywords:| Difficulty: Unknown Os: Unknown | Testcase: driver062.5 Architecture: Unknown | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1748#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] #1755: Template Haskell quoting bug
#1755: Template Haskell quoting bug -+-- Reporter: guest |Owner: igloo Type: merge | Status: closed Priority: low |Milestone: Component: Template Haskell | Version: 6.6.1 Severity: minor | Resolution: fixed Keywords:| Difficulty: Unknown Os: Unknown | Testcase: TH_qname Architecture: Multiple | -+-- Changes (by igloo): * status: new = closed * resolution: = fixed Comment: Merged -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1755#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 benchmarks
Simon Marlow [EMAIL PROTECTED] writes: Not so much code size, but data size (heap size, to be more precise). Of course. There was some talk about storing tags in pointers for 6.8, I couldn't find the reference, but I wonder if that would help my situation? It would be interesting to know how much time is spent in the GC - run the program with +RTS -sstderr. MUT time decreases a bit (131 to 127s) for x86_64, but GC time increases a lot (98 to 179s). i686 version: 94,088,199,152 bytes allocated in the heap 22,294,740,756 bytes copied during GC (scavenged) 2,264,823,784 bytes copied during GC (not scavenged) 124,747,644 bytes maximum residency (4138 sample(s)) 179962 collections in generation 0 ( 67.33s) 4138 collections in generation 1 ( 30.92s) 248 Mb total memory in use INIT time0.00s ( 0.00s elapsed) MUT time 131.53s (133.03s elapsed) GCtime 98.25s (100.13s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 229.78s (233.16s elapsed) %GC time 42.8% (42.9% elapsed) Alloc rate715,345,865 bytes per MUT second Productivity 57.2% of total user, 56.4% of total elapsed x86_64 version: 173,790,326,352 bytes allocated in the heap 59,874,348,560 bytes copied during GC (scavenged) 5,424,298,832 bytes copied during GC (not scavenged) 247,477,744 bytes maximum residency (9856 sample(s)) 331264 collections in generation 0 (111.51s) 9856 collections in generation 1 ( 67.80s) 582 Mb total memory in use INIT time0.00s ( 0.00s elapsed) MUT time 127.20s (127.76s elapsed) GCtime 179.32s (179.63s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 306.52s (307.39s elapsed) %GC time 58.5% (58.4% elapsed) Alloc rate1,366,233,874 bytes per MUT second Productivity 41.5% of total user, 41.4% of total elapsed I've also added results from the 64 bit ghc-6.8.20071011 binary snapshot, which shows some nice improvements, with one benchmark improving by 30%(!). 151,807,589,712 bytes allocated in the heap 50,687,462,360 bytes copied during GC (scavenged) 4,472,003,520 bytes copied during GC (not scavenged) 256,532,480 bytes maximum residency (6805 sample(s)) 289342 collections in generation 0 ( 89.30s) 6805 collections in generation 1 ( 60.26s) 602 Mb total memory in use INIT time0.00s ( 0.00s elapsed) MUT time 83.79s ( 84.36s elapsed) GCtime 149.57s (151.10s elapsed) EXIT time0.00s ( 0.00s elapsed) Total time 233.35s (235.47s elapsed) %GC time 64.1% (64.2% elapsed) Alloc rate1,811,779,785 bytes per MUT second Productivity 35.9% of total user, 35.6% of total elapsed I'll add some more benchmarks And I did. Below is a bit more detail from the log. The rc hash counts traverse a bytestring, hashing fixed-size words into Integers. As you can see, I haven't yet gotten the SPECIALIZE pragma to work correctly :-). The global alignment is the previous test, performing global (Needleman-Wunsch) alignment on pairs of sequences of length 100 (short) or 1000 (long), implementing the dynamic programming matrix as a list of lists. Start:Fri Oct 12 08:48:36 CEST 2007 Linux nmd 2.6.20-16-generic #2 SMP Fri Aug 31 00:55:27 UTC 2007 i686 GNU/Linux ghc 6.6 --- Sequence bench --- rc hash counts int (8) . OK, passed 10 tests, CPU time: 34.526157s rc hash counts int (16) . OK, passed 10 tests, CPU time: 34.746172s rc hash counts (16) . OK, passed 10 tests, CPU time: 34.642164s rc hash counts (32) . OK, passed 10 tests, CPU time: 35.378212s Sequence bench totals, CPU time: 139.292705s, wall clock: 139 secs --- Alignment bench --- global alignment, short . OK, passed 10 tests, CPU time: 2.696168s global alignment, long .. OK, passed 10 tests, CPU time: 90.481655s Alignment bench totals, CPU time: 93.177823s, wall clock: 94 secs Total for all tests, CPU time: 232.474528s, wall clock: 233 secs End:Fri Oct 12 08:52:29 CEST 2007 Start:Fri Oct 12 09:52:33 CEST 2007 Linux nmd.imr.no 2.6.22-13-generic #1 SMP Thu Oct 4 17:52:26 GMT 2007 x86_64 GNU/Linux ghc 6.6.1 --- Sequence bench --- rc hash counts int (8) . OK, passed 10 tests, CPU time: 36.634289s rc hash counts int (16) . OK, passed 10 tests, CPU time: 36.590286s rc hash counts (16) . OK, passed 10 tests, CPU time: 36.946309s rc hash counts (32) . OK, passed 10 tests, CPU time: 37.402338s Sequence bench totals, CPU time: 147.577222s, wall clock: 148 secs --- Alignment
Re: GHC benchmarks
Ketil Malde [EMAIL PROTECTED] writes: I've also added results from the 64 bit ghc-6.8.20071011 binary snapshot, which shows some nice improvements, with one benchmark improving by 30%(!). One difference between these runs is that the ByteString library, on which this particular benchmark depends heavily, got upgraded from fps-0.7 to bytestring-0.9. I initially thought some of the performance increase could be due to that, but after some contortions, I find that 6.6.1 with bytestring-0.9 gives me slightly worse results(!) (I haven't yet entirely convinced myself that I got this properly set up, but at least ghci lets me :m Data.ByteString.Lazy.Internals, which I believe is a new addition) Here are the numbers: --- Sequence bench --- rc hash counts int (8) . OK, passed 10 tests, CPU time: 38.778423s rc hash counts int (16) . OK, passed 10 tests, CPU time: 38.522408s rc hash counts (16) . OK, passed 10 tests, CPU time: 38.694418s rc hash counts (32) . OK, passed 10 tests, CPU time: 39.170448s Sequence bench totals, CPU time: 155.165697s, wall clock: 155 secs --- Alignment bench --- global alignment, short . OK, passed 10 tests, CPU time: 3.492218s global alignment, long .. OK, passed 10 tests, CPU time: 152.497531s Alignment bench totals, CPU time: 155.989749s, wall clock: 156 secs Total for all tests, CPU time: 311.155446s, wall clock: 311 secs -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] [EMAIL PROTECTED]: darcs patch: fix typo in docs.]
David Roundy wrote: It seems a little unfriendly to reject contributions from anyone who isn't subscribed to the libraries mailing list... Quite so. `darcs send` should send to an e-mail address where darcs patch:es will be accepted (read at least, or responded to, or applied, as the case may be). (at least as long as spammers don't start generating things that look like darcs patches, this should be possible...) Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] WinAmp plugin?
sounds like great fun to me. i'll contribute some functional graphics expertise. dons others have learned how to get good performance out of elegant code. does anyone have WinAmp plugin know-how? - Conal On 10/12/07, Andrew Coppin [EMAIL PROTECTED] wrote: Does anybody here know WinAmp? [I feel sure the answer must be yes!] How hard would it be to write a visualisation plugin in Haskell? I think this would be a neat way of demonstrating that Haskell isn't slow. Also, WinAmp plugins (and, actually, WinAmp) are notoriously buggy and unstable. Would be a nice place to show off how reliable Haskell programs are. OTOH, I have no idea about this kind of thing, so... ___ 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] Filesystem questions
All these questions are actually Windows-centric; the answers are different on Unix. On Oct 12, 2007, at 13:21 , Andrew Coppin wrote: I notice that getDirectoryContents appears to return its results in alphabetical order. Is this behaviour actually guaranteed? There is no guarantee, however on Windows this is done by invoking Win32 directory globbing routines which happen to return things in alpha order. (On Unix it might be alpha order if the underlying filesystem is a btree, but there are no guarantees at all except perhaps that '.' and '..' come first.) Related: Is there a way to get rid of . and .. in the results? (Obviously this causes directory recusion to malfunction.) I can of course manually filter them out, but it's annoying. Manual filtering is always required, whether C, Perl, Haskell, etc. I dunno, maybe python filters them for you or something. Every language I've ever used makes you deal. doesDirectoryExist C: doesDirectoryExist C:\ both yield False? (This frequently trips up programs that try to check that a destination folder exists.) Ask Microsoft. Drive top level handling has been weird since MS-DOS 2.0. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] WinAmp plugin?
pierre wrote: Wouldn't it be better to write not just a visualization plugin, but a whole player from scratсh? :-) ...this idea also occurred to me. ;-) Why, do *you* know how to decode MP3 data? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On Fri, 12 Oct 2007 18:24:38 +0100, you wrote: I was actually thinking more along the lines of a programming language where you can just write head :: (n 1) = List n x - x tail :: List n x - List (n-1) x (++) :: List n x - List m x - List (n+m) x and so forth. How, then, is that any different from a general-purpose programming language? You're just drawing the line in the sand in a different place. You end up with a programming system where compilation is a side effect of executing the real program. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On 10/12/07, Andrew Coppin [EMAIL PROTECTED] wrote: I was actually thinking more along the lines of a programming language where you can just write head :: (n 1) = List n x - x tail :: List n x - List (n-1) x (++) :: List n x - List m x - List (n+m) x and so forth. You know, instead of the elaborate simulations crafted out of systems that weren't meant to do this stuff. You might be interested in Epigram: http://e-pig.org/ The paper at: http://www.e-pig.org/downloads/epigram-notes.pdf has an example like your head/tail example (in section 3, Vectors and finite sets). Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt I always feel I have to take a stand and there's always someone on hand to hate me for standing there / I always feel i have to open my mouth and every time I do I offend someone somewhere -- Ani DiFranco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filesystem questions
On Fri, 12 Oct 2007 18:21:07 +0100, you wrote: I notice that getDirectoryContents appears to return its results in alphabetical order. Is this behaviour actually guaranteed? This is a Windows thing. All of the NT-based operating systems list files in alphabetical order by default. You see the same thing if you use the DIR command from a command-line prompt. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] WinAmp plugin?
Does anybody here know WinAmp? [I feel sure the answer must be yes!] How hard would it be to write a visualisation plugin in Haskell? I think this would be a neat way of demonstrating that Haskell isn't slow. Also, WinAmp plugins (and, actually, WinAmp) are notoriously buggy and unstable. Would be a nice place to show off how reliable Haskell programs are. OTOH, I have no idea about this kind of thing, so... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Filesystem questions
I notice that getDirectoryContents appears to return its results in alphabetical order. Is this behaviour actually guaranteed? Related: Is there a way to get rid of . and .. in the results? (Obviously this causes directory recusion to malfunction.) I can of course manually filter them out, but it's annoying. Finally, why do doesDirectoryExist C: doesDirectoryExist C:\ both yield False? (This frequently trips up programs that try to check that a destination folder exists.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] more functions to evaluate
Hi folks Any comments and/or criticisms no matter how trivial on the following please: wordSize :: [Int] - Int wordSize xs = head (dropWhile ((length xs)) $ iterate (*2) 8) intToBinWord :: Int - [Int] intToBinWord n = reverse (take elements (xs ++ repeat 0)) where xs = reverse (intToBin n) elements = wordSize xs Thanks, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] WinAmp plugin?
On Oct 12, 2007, at 14:26 , Andrew Coppin wrote: pierre wrote: Wouldn't it be better to write not just a visualization plugin, but a whole player from scratсh? :-) ...this idea also occurred to me. ;-) Why, do *you* know how to decode MP3 data? Don't Do That. Use someone else's plugin-based library if you can help it. Do you really want to write your own Haskell implementations of mp3, aac, aac+, etc.? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type-level arithmetic
I was actually thinking more along the lines of a programming language where you can just write head :: (n 1) = List n x - x tail :: List n x - List (n-1) x (++) :: List n x - List m x - List (n+m) x and so forth. You know, instead of the elaborate simulations crafted out of systems that weren't meant to do this stuff. Of course, the integer case is probably fairly easy. I suspect the issue is that as soon as you try to do this kind of thing, you develop a terminal case of wanting to hyper-generalise everything which then directly results in an incomprehensible mess... ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On 10/12/07, Steve Schafer [EMAIL PROTECTED] wrote: On Fri, 12 Oct 2007 18:24:38 +0100, you wrote: I was actually thinking more along the lines of a programming language where you can just write head :: (n 1) = List n x - x tail :: List n x - List (n-1) x (++) :: List n x - List m x - List (n+m) x and so forth. How, then, is that any different from a general-purpose programming language? It's different because the property that (for example) head requires a nonempty list is checked at compile time instead of run time. You're just drawing the line in the sand in a different place. You end up with a programming system where compilation is a side effect of executing the real program. I'm not sure exactly what you mean by that, but a lot of people are spending time thinking about ways for programmers to express more of their knowledge about programs in a way that's accessible to and checkable by compilers and other automated tools, and while you might see it as just drawing the line in the sand in a different place, you could say the same thing about programming in a language with a Haskell-like type system instead of a Lisp-like type system. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt Yeah. Okay. Yeah. Basically, swingers meet ISO 9000. -- DF, on cuddle parties ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] WinAmp plugin?
On 10/12/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: Don't Do That. Use someone else's plugin-based library if you can help it. Do you really want to write your own Haskell implementations of mp3, aac, aac+, etc.? Something based on GStreamer should be somewhat easier to get done right. No, I don't have any experience in this area, sorry =). -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On 10/12/07, Steve Schafer [EMAIL PROTECTED] wrote: On Fri, 12 Oct 2007 13:03:16 -0700, you wrote: It's different because the property that (for example) head requires a nonempty list is checked at compile time instead of run time. No, I understand that. Andrew was talking about using type programming to do the things that a sane person would use ordinary programming to do. I'm not sure what sanity has to do with it. Presumably we all agree that it's a good idea for the compiler to know, at compile-time, that head is only applied to lists. Why not also have the compiler check that head is only applied to non-empty lists? If you think it's sane to want one property checked at compile-time and insane to want the other property checked at compile-time, can you describe your test that can be applied to program properties to determine whether or not it's sane to want them statically checked? And he wanted to know if there were any efforts to create a type system syntax that better supported that. But it seems to me that when you do that, the language of the type system begins to look like a general-purpose programming language. And that just shoves everything up to the next meta level. Pretty soon, you're going to need a meta-type system to meta-type-check your type language, and so on. This criticism has been made before. I'm all for enhancing the expressibility of concepts _related to typing_ within the type system, but I don't think that was the original point of this discussion. After all, Andrew's original message mentioned stuff the type system was never designed to do. What do you mean by related to typing? Haskell's type system allows us to say that head is a function that maps a list of things of type a onto a thing of type a. A more expressive type system might allow us to say that head's domain consists of *non-empty* lists. In this type system, emptiness or non-emptiness is a concept related to typing, because it's a concept that that type system can express. You seem to be criticizing richer type systems on the sole basis that they are richer than existing ones. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt I always wanted to be commander-in-chief of my own one-woman army -- Ani DiFranco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On Fri, 12 Oct 2007 13:03:16 -0700, you wrote: It's different because the property that (for example) head requires a nonempty list is checked at compile time instead of run time. No, I understand that. Andrew was talking about using type programming to do the things that a sane person would use ordinary programming to do. And he wanted to know if there were any efforts to create a type system syntax that better supported that. But it seems to me that when you do that, the language of the type system begins to look like a general-purpose programming language. And that just shoves everything up to the next meta level. Pretty soon, you're going to need a meta-type system to meta-type-check your type language, and so on. I'm all for enhancing the expressibility of concepts _related to typing_ within the type system, but I don't think that was the original point of this discussion. After all, Andrew's original message mentioned stuff the type system was never designed to do. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On Fri, 12 Oct 2007 13:25:28 -0700, you wrote: I'm not sure what sanity has to do with it. Presumably we all agree that it's a good idea for the compiler to know, at compile-time, that head is only applied to lists. Why not also have the compiler check that head is only applied to non-empty lists? Again, that sort of practical application of type systems is not (as far as I know) what this discussion is about. This discussion was spawned by talk of using the type system to do truly bizarre things, such as solve the Instant Insanity puzzle. A while back, Dan Piponi posed the question of using the type system to solve one of the liar/truthteller logic problems. And so on. Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more functions to evaluate
how about this, for wordSize? I used quickcheck to verify that my
wordSize2 is the same as yours.
Actually, it's not! if you allow negative integers in the list, it's not
at any rate. (falsifiable after 50 tries)
I haven't thought through what this means... if your function isn't quite
right, or mine, or it doesn't really matter.
Also I would be curious to see this quickchecked but not allowing negative
integers in the list if someone can show me how to do that.
Also, I commented out intToBinWord because intToBin isn't in prelude nor
in any library I could track down and I'm not sure what it was supposed to
do.
thomas.
import Data.List
import Data.Maybe
import Test.QuickCheck
wordSize :: [Int] - Int
wordSize xs = head (dropWhile ((length xs)) $ iterate (*2) 8)
wordSize2 :: [Int] - Int
wordSize2 xs = fromJust $ find ((length xs)) $ iterate (*2) 8
main = quickCheck $ \xs - wordSize2 ( xs :: [Int]) == wordSize xs
{-
intToBinWord :: Int - [Int]
intToBinWord n = reverse (take elements (xs ++ repeat 0))
where
xs = reverse (intToBin n)
elements = wordSize xs
-}
PR Stanley [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
10/12/2007 03:10 PM
To
haskell-cafe@haskell.org
cc
Subject
[Haskell-cafe] more functions to evaluate
Hi folks
Any comments and/or criticisms no matter how trivial on the following
please:
wordSize :: [Int] - Int
wordSize xs = head (dropWhile ((length xs)) $ iterate
(*2) 8)
intToBinWord :: Int - [Int]
intToBinWord n = reverse (take elements (xs ++ repeat 0))
where
xs = reverse (intToBin n)
elements = wordSize xs
Thanks, Paul
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
---
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On Fri, 12 Oct 2007, Steve Schafer wrote: On Fri, 12 Oct 2007 13:25:28 -0700, you wrote: I'm not sure what sanity has to do with it. Presumably we all agree that it's a good idea for the compiler to know, at compile-time, that head is only applied to lists. Why not also have the compiler check that head is only applied to non-empty lists? Again, that sort of practical application of type systems is not (as far as I know) what this discussion is about. This discussion was spawned by talk of using the type system to do truly bizarre things, such as solve the Instant Insanity puzzle. A while back, Dan Piponi posed the question of using the type system to solve one of the liar/truthteller logic problems. And so on. Which is nevertheless the kind of power you need in order to also be able to prove precise properties. How are you going to prove that an entire class of problems is solveable (and the safety or termination of a piece of code may depend on this) if you can't prove that an individual one is? -- [EMAIL PROTECTED] A problem that's all in your head is still a problem. Brain damage is but one form of mind damage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
Steve said: How, then, is that any different from a general-purpose programming language? You're just drawing the line in the sand in a different place. In a way it is like drawing a line in sand. But that's a useful thing to do for a bunch of reasons. (1) When developing code, you'd like to test as much of the code as possible for reliability. But you don't necessarily know what data your code is going to run on in the future. It'd be cool if you could somehow run as much of your code as possible even without yet having the data. By having a declaration like (++) :: List n x - List m x - List (n+m) x it's almost as if the compiler gets to run a 'reduced' version of your application. You don't actually know what the elements of the list are (or even their types), and yet you can still test to see if your code handles the lists of the lengths correctly. (2) Sometimes you want to solve a problem incrementally. It's often helpful to reason first to the type we want, and then the implementation, rather than just to the implementation - it gives a way to factor the problem into two stages. By allowing some computation to take place at compile time you can be flexible about where the boundaries between your stages lie allowing you much more freedom in how you incrementally arrive at your solution. (3) In theory you can get very efficient code out of a type system where the compiler knows, for example, how long the lists are in advance. I guess you could say it's a form of partial evaluation. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On Fri, 12 Oct 2007 21:51:46 +0100 (GMT Daylight Time), you wrote: Which is nevertheless the kind of power you need in order to also be able to prove precise properties. We're not talking about POWER, we're talking about SYNTAX. That the Instant Insanity problem _was_ solved using Haskell's type system is obviously proof that the power to solve that kind of problem, at least, is already there. However, the solution is convoluted and less than clear at first glance. The question is whether or not there is a way to allow such solutions to be expressed in a more natural way. To which my rejoinder is, To what end? To extend the _syntax_ of the type system in a way that allows such natural expression turns it into yet another programming language. So what have we gained? Steve Schafer Fenestra Technologies Corp. http://www.fenestra.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fusing foldr's
Always check optimizations to make sure they are not pessimizations! Actually, traversing the list twice is very cheap compared to space leakage, and accumulating pairs requires tuple boxing and unboxing which I don't know how to get GHC not to do. Your avg3 (along with several attempts of mine to fix the problem) gave stack overflows on a large list. Only avg4 below (traversing the list twice with strict accumulation) didn't blow up on large lists, even though avg5 and avg6 were intended to be strict. Prelude Control.Arrow Data.List let avg4 = uncurry (/) . (foldl' (+) 0 foldl' (\x y - x + 1) 0) in avg4 [1..1000] 500.5 -- This took 13 sec on my machine Prelude Control.Arrow Data.List let avg3 = uncurry (/) . foldr (\x (s,n) - (s + x,n + 1)) (0,0) in avg3 [1..1000] *** Exception: stack overflow -- This fails in 1 sec Prelude Control.Arrow Data.List let avg5 = uncurry (/) . foldl' (\(s,n) x - (s + x,n + 1)) (0,0) in avg5 [1..1000] *** Exception: stack overflow -- This fails in 100 sec Prelude Control.Arrow Data.List let avg6 = uncurry (/) . foldl' (\sn x - (fst sn+x,snd sn+1)) (0,0) in avg6 [1..1000] *** Exception: stack overflow -- This fails in 30 sec Prelude Control.Arrow Data.List let avg3 = uncurry (/) . foldr (\n - (+n) *** (+1)) (0, 0) in avg3 [1..1000] *** Exception: stack overflow -- This fails in 2 sec Tim Newsham wrote: Just goofing around with arrows and foldr while reading Hutton's excellent paper on folds (http://www.cs.nott.ac.uk/~gmh/fold.pdf). Wondering if this can be done automatically and more generally? module Main where import Control.Arrow import Data.List -- sum and length expressed as foldr. fsum = foldr (\n - (+n)) 0 flen = foldr (\n - (+1)) 0 -- compute average using arrows.. -- compute the sum of a list, compute the length, and do a divide. -- this traverses the list twice using two foldrs. avg1 = uncurry (/) . (fsum flen) avg2 = uncurry (/) . (foldr (\n - (+n)) 0 foldr (\n - (+1)) 0) -- But the two foldr's can be fused together -- here we're mixing the two foldr constants 0 and 0 to (0,0) -- and we're mixing the two functions (\n - (+n)) and -- (\n - (+1)) to (\n - (+n) *** (+1)). avg3 = uncurry (/) . foldr (\n - (+n) *** (+1)) (0, 0) main = do print $ avg1 [1,2,3,4] print $ avg2 [1,2,3,4] print $ avg3 [1,2,3,4] Tim Newsham http://www.thenewsh.com/~newsham/ ___ 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] WinAmp plugin?
Brandon S. Allbery KF8NH wrote: On Oct 12, 2007, at 14:26 , Andrew Coppin wrote: Why, do *you* know how to decode MP3 data? Don't Do That. Use someone else's plugin-based library if you can help it. Do you really want to write your own Haskell implementations of mp3, aac, aac+, etc.? Well, it would certainly be an interesting project! However, I doubt we could find anybody with the necessary knowledge to attempt it... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Dual Parser Failure???
Hi failure :: (Parser a) failure = \inp - [] The code might contain some syntax errors and I'd be grateful for any corrections. What is a dual parser failure? Thanks, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: latest hdbc-odbc
On 2007-10-11, jeff p [EMAIL PROTECTED] wrote: Hello, When building the latest hdbc-odbc (1.1.2.0) on a linux box with ghc6.6.1, I get the following warnings: [7 of 7] Compiling Database.HDBC.ODBC ( Database/HDBC/ODBC.hs, dist/build/Database/HDBC/ODBC.o ) hdbc-odbc-helper.c: In function â: That's a mighty suspicious function name, but as far as I can tell, that aside, these are probably harmless. then, after installing the package I get the following error/strange behavior: There was a line missing in the cabal file. I have posted 1.1.2.2 to http://software.complete.org/hdbc-odbc/downloads which fixes it. -- John Prelude :t Database.HDBC.ODBC.connectODBC /usr/local/lib/HDBC-odbc-1.1.2.0/ghc-6.6.1/Database/HDBC/ODBC/Connection.hi Declaration for connectODBC: Failed to load interface for `Database.HDBC.ODBC.ConnectionImpl': Use -v to see a list of the files searched for. Cannot continue after interface file error Can anyone shed light on what is going wrong? Is it something I can fix, or is the distribution buggy? thanks, Jeff -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to thoroughly clean up Haskell stuff on linux
Hi, I have been hacking the Haskell installation a few days on Redhat Linux. GHC 6.6 - 6.6.1 - Lambdabot does not work. Downgrade to GHC 6.4 - Still not working, tried cabal-install to simplify my life, but no luck. Then install Cabal, Haddock - Haddock cannot install bc Lambdabot is not there. (And some dependency issues.) Remove .ghci, Haddock still not work. It seems the Haskell world (outside the beautiful GHC) is in a recursive non-functional blackhole. Anyway, now my question is, how do I thoroughly clean up Haskell? (And maybe try again after a few days of rest.) My environment is Redhat Linux, install most stuff on /home/user/product/ where product = GHC, Lambdabot, cabal, haddock, etc. It seems there are some hidden files/dirs, .GHC, .ghci, anything else? Thanks, Steve -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux
are you certain haddock depends on lambdabot? that seems very strange to me. Thomas, I also thought haddock should be an easy build, but it just won't do it. /home2/user/garden/haddock-0.8 runhaskell ./Setup.lhs install Installing: --prefix=~/cabal/lib/haddock-0.8/ghc-6.4 --prefix=~/cabal/bin haddock-0.8... Then it stopped and nothing got done. (I even checked rc=0 but the lib/bin dir does not have trace of haddock!) I don't think haddock has to depend on lamdbabot. But I saw Skipping HaddockHoogle during the build. Isn't the Hoogle thing related to Lambdabot? Or they are unrelated. Again being new to the Haskell world (only a few months), I am not an expert on what depends on what. It would be nice to have a type system to check the dependency of the many packages. Perl CPAN does a good job on this. Steve -- To haskell-cafe@haskell.org cc Subject [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux Hi, I have been hacking the Haskell installation a few days on Redhat Linux. GHC 6.6 - 6.6.1 - Lambdabot does not work. Downgrade to GHC 6.4 - Still not working, tried cabal-install to simplify my life, but no luck. Then install Cabal, Haddock - Haddock cannot install bc Lambdabot is not there. (And some dependency issues.) Remove .ghci, Haddock still not work. It seems the Haskell world (outside the beautiful GHC) is in a recursive non-functional blackhole. Anyway, now my question is, how do I thoroughly clean up Haskell? (And maybe try again after a few days of rest.) My environment is Redhat Linux, install most stuff on /home/user/product/ where product = GHC, Lambdabot, cabal, haddock, etc. It seems there are some hidden files/dirs, .GHC, .ghci, anything else? Thanks, Steve -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Defining Tree
There are many tree types. Take a look at: http://www.haskell.org/ghc/docs/6.4.1/html/libraries/base/Data-Tree.html PR Stanley wrote: Hi I'm reading the chapter on parsers in the Hutton book. The text refers to the data type tree which doesn't seem to be in prelude. So, I was wondering, what would be asuitable tree for a parser? A binary tree perhaps? Are there different types of tree for different parsers? Thanks, Paul ___ 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] more functions to evaluate
Here is my suggestion: separation of concerns. Your functions are doing multiple things at once (and there are inefficiencies in your code that are not easy to see because it does do several things at once). You want the smallest word that an int will fit in. Sounds like you'll need a useful helper function: roundUpToPowerOf2 :: Int - Int roundUpToPowerOf2 n = f 1 where f x = if x = n then x else f (x*2) Prelude [(n,roundUpToPowerOf2 n) | n - [1..10]] [(1,1),(2,2),(3,4),(4,4),(5,8),(6,8),(7,8),(8,8),(9,16),(10,16)] Now wordSize is easy: wordSize :: [a] - Int wordSize = roundUpToPowerOf2 . length Prelude wordSize [1..5] 3 The second task appears to be just zero padding a list ns on the left to get to a length of wordSize ns. For this you can avoid the double reversing of ns, again by separating concerns: We know how long the list is, and how long we want it to be. The difference is how many zeroes to add: numZeroesToAdd :: Int - Int numZeroesToAdd n = roundUpToPowerOf2 n - n We don't want to make an intermediate list of zeroes and append, since that could be wasteful. Just keep adding a zero to the head of our list until it gets big enough. Our list is not copied (i.e. it is shared with the tail of the result) this way, saving making a copy during reverse. But it's good to keep things general until we need to be specific. We want to do something to something over and over a known number of times. For this to be well-typed, f has to take a type to itself. f :: a - a (In math-speak, this is an endofunction, or a function in a) applyNtimes :: (a - a) - Int - a - a This sounds like it should be in the library somewhere, but hoogle didn't find it, and it is easy enough to roll our own. It just counts down to zero, composing an f. applyNtimes f 3 = f . f . f . id Note that instead of applying f to something repeatedly, we drop the something and just compose f directly (in math-speak, we move from a group to its algebra), because what's interesting about applyNtimes is f, not what it's applied to. The something would just clutter things up. We start with the identity function: applyNtimes f n | n 0 = f . applyNtimes f (n-1) | otherwise = id For list padding, our f is just (e:), cons'ing an e to the front of the list (again we keep it generalized to any e, since this logic doesn't depend on what e is, only that it has the right type. Not hardcoding an unnecessary detail is important for separation of concerns. padToPowerOf2 :: a - [a] - [a] padToPowerOf2 e xs = applyNtimes (e:) numZeroes xs where numZeroes = numZeroesToAdd (length xs) Now we are ready for intToBinWord: intToBinWord :: Int - [Int] intToBinWord n = padToPowerOf2 0 (intToBin n) --- Just for fun, we could rewrite this in point-free notation (but if this isn't fun, don't worry, it doesn't really improve anything!) intToBinWord n = padToPowerOf2 0 . intToBin $ n or more simply intToBinWord = padToPowerOf2 0 . intToBin --- You didn't include a definition for intToBin, so I'll just make one up: intToBin :: Int - [Int] intToBin n = take n (repeat 9) Now we see the fruits of our labor: *Go intToBinWord 4 [9,9,9,9] *Go intToBinWord 5 [0,0,0,9,9,9,9,9] *Go intToBinWord 8 [9,9,9,9,9,9,9,9] *Go intToBinWord 9 [0,0,0,0,0,0,0,9,9,9,9,9,9,9,9,9] The main thing I'm trying to convince you of is that each function should pull its own weight, with no extra baggage, and always with an eye out for useful helper functions (like applyNtimes) that you can add to your bag of tricks. Each function is small and easily debuggable, and you can much more easily gauge the optimality of each factored step rather than a bloated function. Dan Weston PR Stanley wrote: Hi folks Any comments and/or criticisms no matter how trivial on the following please: wordSize :: [Int] - Int wordSize xs = head (dropWhile ((length xs)) $ iterate (*2) 8) intToBinWord :: Int - [Int] intToBinWord n = reverse (take elements (xs ++ repeat 0)) where xs = reverse (intToBin n) elements = wordSize xs Thanks, Paul ___ 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] Dual Parser Failure???
PR Stanley wrote: failure :: (Parser a) failure = \inp - [] The code might contain some syntax errors and I'd be grateful for any corrections. It looks right conceptually. Depending on the definition of Parser, you may need failure = P (\inp - []) or whatever constructor name instead of P. The type checker will know. I don't know about dual parser failure. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux
not trying to start a flame war here, but I had pretty good success with apt-get and ubuntu. however, I admit I never really got lambdabot to work. if you install from source you can have 6.6, 6.6.1 and 6.4 all installed at the same time. you just need to create simlinks for the old versions. (nothing gets overwritten except the symlink in /usr/bin) are you certain haddock depends on lambdabot? that seems very strange to me. t. Lihn, Steve [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/12/2007 05:22 PM To haskell-cafe@haskell.org cc Subject [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux Hi, I have been hacking the Haskell installation a few days on Redhat Linux. GHC 6.6 - 6.6.1 - Lambdabot does not work. Downgrade to GHC 6.4 - Still not working, tried cabal-install to simplify my life, but no luck. Then install Cabal, Haddock - Haddock cannot install bc Lambdabot is not there. (And some dependency issues.) Remove .ghci, Haddock still not work. It seems the Haskell world (outside the beautiful GHC) is in a recursive non-functional blackhole. Anyway, now my question is, how do I thoroughly clean up Haskell? (And maybe try again after a few days of rest.) My environment is Redhat Linux, install most stuff on /home/user/product/ where product = GHC, Lambdabot, cabal, haddock, etc. It seems there are some hidden files/dirs, .GHC, .ghci, anything else? Thanks, Steve -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Defining Tree
Hi I'm reading the chapter on parsers in the Hutton book. The text refers to the data type tree which doesn't seem to be in prelude. So, I was wondering, what would be asuitable tree for a parser? A binary tree perhaps? Are there different types of tree for different parsers? Thanks, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] question about throwDyn
throwDyn e = throw (DynException (toDyn e)) You're wrapping the exception in a DynException wrapper, which shows up as (unknown). -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On Fri, 12 Oct 2007, Steve Schafer wrote: On Fri, 12 Oct 2007 21:51:46 +0100 (GMT Daylight Time), you wrote: Which is nevertheless the kind of power you need in order to also be able to prove precise properties. We're not talking about POWER, we're talking about SYNTAX. Which has no small amount to do with the power to express problems in a natural way, no? My point being that we already want this for things that are more obviously appropriate uses of a type system. To which my rejoinder is, To what end? To extend the _syntax_ of the type system in a way that allows such natural expression turns it into yet another programming language. So what have we gained? It's already yet another programming language, whether you like it or not - the question is how usable it is. Either you accept the gains made on the way or not, but what we have gained is the ability to reason about our programs in the language they are written in. We already have types-of-types in Haskell, they're called kinds. There's even a language that'll let you stack this as far as you like - why not? Zero, one or infinity, what else is new? -- [EMAIL PROTECTED] Society does not owe people jobs. Society owes it to itself to find people jobs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Performance problem with random numbers
Dear all, I have implemented a small module to generate random items with a given probability distribution using the alias approach [1] and unfortunately compared to similar implementations in C++ or Java it is about 10 times slower. I have to confess that I am still in the early stages of writing Haskell programs so there is hopefully something I can do about it and I hope some helpful soul on this list can give me a hint. I have attached my implementation and a small testing routine which runs in about 5 seconds on my machine (when compiled with -O2) whereas my Java-Implementation finishes in about 0.48 seconds. Profiling indicates that the time is mostly spend in System.Random.random and System.Random.randomR so I wonder if these are slow or what else might cause the relative slowness of my implementation. Many thanks for your responses, Thoralf PS: I would also appreciate any feedback about the module from a design perspective. I bet I miss lots of good Haskell idioms. [1] The alias methods moves probability mass of a non-uniform probability distribution around to create a uniform distribution. Lets say you have three items a, b, and c with distribution [0.2, 0.1, 0.7] then a uniform distribution would assign 1/3 to each so a and b need to be filled up with exactly the same probability mass that c has too much. Then 2 uniform random numbers are generated. The first one to pick an item and the second one to pick either the item itself if the value is in the original part or the alias otherwise. A much better explanation can be found on the web somewhere. Anyway it should not matter with regards to the performance problem I have. module Main where import Random import System.Random import Data.Array import Data.List main = do g - getStdGen let k = [a, b, c] n = 100 :: Int t = setup k [0.2, 0.1, 0.7] :: (Array Int String, Array Int String, Array Int Double) print $ foldl' (\a b - if b == b then a + 1 else a) 0 (take n $ randomList t g) / fromIntegral n module Random (setup, next, randomList) where import System.Random hiding (next) import Data.Array.IArray -- Given a list of items and a list of their propabilities generate a tripel -- consisting of the values vector, the alias vector and the relative propabilities -- vector which is used in applications of next, etc. setup :: (Ord a, IArray a2 a, IArray a1 e, Num a) = [e] - [a] - (a1 Int e, a1 Int e, a2 Int a) setup xs ps = let n = length ps xv = listArray (0, n - 1) xs rv = listArray (0, n - 1) [fromIntegral n * p | p - ps] (low, high) = splitAt 1 rv (indices rv) [] [] (a, r) = calcAlias xv xv rv high low in (xv, a, r) where -- Return a pair of lists, the first consisting of elements lower than -- given threshold and the second with elements greater than threshold, -- equal elements are ignored. splitAt t v [] l h = (l, h) splitAt t v (i:is) l h = case v!i of x | x t - splitAt t v is (i:l) h | x t - splitAt t v is l (i:h) | otherwise - splitAt t v is l h -- Given an list of highs and a list of lows, calculate the alias vector and the relative -- propabilities vector. calcAlias :: (Ord e, Num e, IArray a e, Ix i, IArray a2 e1, IArray a1 e1) = a2 i e1 - a1 i e1 - a i e - [i] - [i] - (a1 i e1, a i e) calcAlias xv av rv []_ = (av, rv) calcAlias xv av rv _ [] = (av, rv) calcAlias xv av rv hi@(h:hs) (l:ls) = let av' = av//[(l, xv!h)] rv' = rv//[(h, rv!h + rv!l - 1)] in if rv'!h = 1 then calcAlias xv av' rv' hi ls else calcAlias xv av' rv' hs (h:ls) -- Generate a random item according to the given propability distribution as specified -- by the given tripel which is the result of applying setup to a list of items and -- a list of propabilities. next :: (IArray a2 e1, IArray a e1, Ord e, IArray a1 e, RandomGen t, Random e) = (a Int e1, a2 Int e1, a1 Int e) - t - (e1, t) next (xs, as, rs) g = let n = length $ indices xs (x1, g1) = randomR (0, n - 1) g (x2, g2) = random g1 r = rs!x1 in if x2 = r then (xs!x1, g2) else (as!x1, g2) -- Generate a infinite list of random items according to the specified propability -- distribution as given by the triple that results from applying setup to a pair -- of a list of items and a list of propabilities (see setup for details). randomList :: (Random e, RandomGen t1, IArray a2 e, Ord e, IArray a t, IArray a1 t) = (a Int t, a1 Int t, a2 Int e) - t1 - [t] randomList t g = let (n, g') = next t g in n:randomList t g' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more functions to evaluate
Dan Weston wrote: applyNtimes :: (a - a) - Int - a - a This sounds like it should be in the library somewhere agree, I've used it a few times (mostly for testing things) - modulo argument order and Int vs. Integer vs. (Num a = a) Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux
wayll... it (haddock at least) really is easy on deb/ubu with apt. I've found a lot of stuff is harder to install on Suse back when I was using that, and I think Suse/Redhat suffer from the same problems. not that the packager should matter, since it seems you're installing from source... are you trying to do something like install to your home dir (non root) or like that? did you look for an rpm for haddock? If you're committed to RH, honestly I would just take whatever comes nicely packaged as rpm. Life is too short (and haskell has enough other complications) to be installing stuff from source :) t. Lihn, Steve [EMAIL PROTECTED] 10/12/2007 05:38 PM To Thomas Hartman/ext/[EMAIL PROTECTED] cc haskell-cafe@haskell.org, [EMAIL PROTECTED] Subject RE: [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux are you certain haddock depends on lambdabot? that seems very strange to me. Thomas, I also thought haddock should be an easy build, but it just won't do it. /home2/user/garden/haddock-0.8 runhaskell ./Setup.lhs install Installing: --prefix=~/cabal/lib/haddock-0.8/ghc-6.4 --prefix=~/cabal/bin haddock-0.8... Then it stopped and nothing got done. (I even checked rc=0 but the lib/bin dir does not have trace of haddock!) I don't think haddock has to depend on lamdbabot. But I saw Skipping HaddockHoogle during the build. Isn't the Hoogle thing related to Lambdabot? Or they are unrelated. Again being new to the Haskell world (only a few months), I am not an expert on what depends on what. It would be nice to have a type system to check the dependency of the many packages. Perl CPAN does a good job on this. Steve -- To haskell-cafe@haskell.org cc Subject [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux Hi, I have been hacking the Haskell installation a few days on Redhat Linux. GHC 6.6 - 6.6.1 - Lambdabot does not work. Downgrade to GHC 6.4 - Still not working, tried cabal-install to simplify my life, but no luck. Then install Cabal, Haddock - Haddock cannot install bc Lambdabot is not there. (And some dependency issues.) Remove .ghci, Haddock still not work. It seems the Haskell world (outside the beautiful GHC) is in a recursive non-functional blackhole. Anyway, now my question is, how do I thoroughly clean up Haskell? (And maybe try again after a few days of rest.) My environment is Redhat Linux, install most stuff on /home/user/product/ where product = GHC, Lambdabot, cabal, haddock, etc. It seems there are some hidden files/dirs, .GHC, .ghci, anything else? Thanks, Steve -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu - direct contact information for affiliates is available at http://www.merck.com/contact/contacts.html) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- --- This e-mail may contain confidential and/or
Re: [Haskell-cafe] New slogan for haskell.org
Tim Newsham wrote: You are not expected to understand this. http://swtch.com/unix/ Hehehe! Elite system programmers understand it. If it is rephrased in terms of continuations, elite lambda calculus programmers will also understand it. You are not expected to be convinced this, but it seems continuations completely characterize system programming. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more functions to evaluate
Isaac Dupree wrote: Dan Weston wrote: applyNtimes :: (a - a) - Int - a - a This sounds like it should be in the library somewhere agree, I've used it a few times (mostly for testing things) - modulo argument order and Int vs. Integer vs. (Num a = a) What do you think about calling it iterateN instead? Maxime ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more functions to evaluate
I like that name, and will henceforth use it myself until someone sees fit to add it to the Prelude! Maxime Henrion wrote: Isaac Dupree wrote: Dan Weston wrote: applyNtimes :: (a - a) - Int - a - a This sounds like it should be in the library somewhere agree, I've used it a few times (mostly for testing things) - modulo argument order and Int vs. Integer vs. (Num a = a) What do you think about calling it iterateN instead? Maxime ___ 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] Re: Type-level arithmetic
On Oct 12, 2007, at 16:25 , Tim Chevalier wrote: On 10/12/07, Steve Schafer [EMAIL PROTECTED] wrote: On Fri, 12 Oct 2007 13:03:16 -0700, you wrote: It's different because the property that (for example) head requires a nonempty list is checked at compile time instead of run time. No, I understand that. Andrew was talking about using type programming to do the things that a sane person would use ordinary programming to do. I'm not sure what sanity has to do with it. Presumably we all agree that it's a good idea for the compiler to know, at compile-time, that head is only applied to lists. You two are talking past each other. You're talking about dependent typing, etc. Steve's complaint is not about dependent typing; he's saying Andrew is looking for something different from that, namely the type system being a metalanguage. I have the same impression, that Andrew isn't interested in dependent typing. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On 10/12/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: You two are talking past each other. You're talking about dependent typing, etc. Steve's complaint is not about dependent typing; he's saying Andrew is looking for something different from that, namely the type system being a metalanguage. Well, the type system *is* a metalanguage, so presumably Andrew's looking for something more specific than that... I have the same impression, that Andrew isn't interested in dependent typing. I'm not sure what he was really asking in his OP either, but when he said that he was looking for a language where you can write type signatures that encode list length, that certainly points to dependent types as one instance of that, even if there are other possibilities. Cheers, Tim -- Tim Chevalier * catamorphism.org * Often in error, never in doubt The way NT mounts filesystems is something I'd expect to find in a barnyard or on a stock-breeding farm.--Mike Andrews ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On Oct 12, 2007, at 18:35 , Albert Y. C. Lai wrote: You are not expected to be convinced this, but it seems continuations completely characterize system programming. :) Didn't someone already prove all monads can be implemented in terms of Cont? (here you see why schemers are so wedded to call/cc...) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On Oct 12, 2007, at 19:26 , Tim Chevalier wrote: On 10/12/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: You two are talking past each other. You're talking about dependent typing, etc. Steve's complaint is not about dependent typing; he's saying Andrew is looking for something different from that, namely the type system being a metalanguage. Well, the type system *is* a metalanguage, so presumably Andrew's looking for something more specific than that... My impression is he's looking for something more *general* than that. He wants to write entire programs in the type system, something like the crazies who write programs in C++ templates such that template expansion does all the work at compile time and the runtime code just prints the constant result. Certainly this covers dependent typing, but it goes well beyond it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On 10/12/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: He wants to write entire programs in the type system, something like the crazies who write programs in C++ templates such that template expansion does all the work at compile time Crazies? :-) http://homepage.mac.com/sigfpe/Computing/peano.html Having switched from C++ to Haskell (at least in my spare time) I thought I'd escaped that kind of type hackery but it seems to be following me... -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux
On Oct 12, 2007, at 17:38 , Lihn, Steve wrote: Installing: --prefix=~/cabal/lib/haddock-0.8/ghc-6.4 This looks suspicious to me: the ~ metacharacter is only understood by shells, and only in certain circumstances (i.e. only at the beginning of a word, not after a =), and by the time you reach that phase it should have been expanded to your home directory already. Check Cabal didn't leave stuff in a directory named ~ under your current directory, and if it did then redo the configure saying $HOME instead of ~ (and make sure you didn't quote it so that it gets passed on unexpanded like the ~ did). I don't think haddock has to depend on lamdbabot. But I saw Skipping HaddockHoogle during the build. Isn't the Hoogle thing related to Lambdabot? Or they are unrelated. Only insofar has Lambdabot has an interface to Hoogle (which IIRC depends on Haddock knowing how to build Hoogle indexes, which is what that segment is about). Haddock doesn't build the Hoogle stuff by default, IIRC. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type-level arithmetic
On Oct 12, 2007, at 19:42 , Dan Piponi wrote: On 10/12/07, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: He wants to write entire programs in the type system, something like the crazies who write programs in C++ templates such that template expansion does all the work at compile time Crazies? :-) http://homepage.mac.com/sigfpe/Computing/peano.html I'm not sure it's entirely sane even in Haskell, but in C++ templates it is definitely *not* sane. :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
allbery: On Oct 12, 2007, at 18:35 , Albert Y. C. Lai wrote: You are not expected to be convinced this, but it seems continuations completely characterize system programming. :) Didn't someone already prove all monads can be implemented in terms of Cont? Cont and StateT, wasn't it? And the schemers have no choice about running in StateT :) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more functions to evaluate
Dan Weston wrote: I like that name, and will henceforth use it myself until someone sees fit to add it to the Prelude! Oh, and I guess we'd also need: genericIterateN :: (a - a) - Integer - a - a Which also got me thinking, wouldn't it make more sense to have the count as the first parameter? iterateN:: Int - (a - a) - a - a genericIterateN :: Integer - (a - a) - a - a Cheers, Maxime ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] more functions to evaluate
Maxime Henrion wrote: Dan Weston wrote: I like that name, and will henceforth use it myself until someone sees fit to add it to the Prelude! Oh, and I guess we'd also need: genericIterateN :: (a - a) - Integer - a - a Which also got me thinking, wouldn't it make more sense to have the count as the first parameter? iterateN:: Int - (a - a) - a - a genericIterateN :: Integer - (a - a) - a - a Woops, obviously I meant: genericIterateN :: Integral a = a - (b - b) - b - b Cheers, Maxime ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to thoroughly clean up Haskell stuff on linux
On Fri, Oct 12, 2007 at 07:31:45PM -0400, Brandon S. Allbery KF8NH wrote: I don't think haddock has to depend on lamdbabot. But I saw Skipping HaddockHoogle during the build. Isn't the Hoogle thing related to Lambdabot? Or they are unrelated. Only insofar has Lambdabot has an interface to Hoogle (which IIRC depends on Haddock knowing how to build Hoogle indexes, which is what that segment is about). Haddock doesn't build the Hoogle stuff by default, IIRC. Besides, Skipping foo is GHC-ese for foo is already up to date, not wasting time... Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance problem with random numbers
On Sat, Oct 13, 2007 at 12:09:57AM +0200, ntupel wrote: Dear all, I have implemented a small module to generate random items with a given probability distribution using the alias approach [1] and unfortunately compared to similar implementations in C++ or Java it is about 10 times slower. I have to confess that I am still in the early stages of writing Haskell programs so there is hopefully something I can do about it and I hope some helpful soul on this list can give me a hint. setup :: (Ord a, IArray a2 a, IArray a1 e, Num a) = [e] - [a] - (a1 Int e, a1 Int e, a2 Int a) calcAlias :: (Ord e, Num e, IArray a e, Ix i, IArray a2 e1, IArray a1 e1) = a2 i e1 - a1 i e1 - a i e - [i] - [i] - (a1 i e1, a i e) next :: (IArray a2 e1, IArray a e1, Ord e, IArray a1 e, RandomGen t, Random e) = (a Int e1, a2 Int e1, a1 Int e) - t - (e1, t) randomList :: (Random e, RandomGen t1, IArray a2 e, Ord e, IArray a t, IArray a1 t) = (a Int t, a1 Int t, a2 Int e) - t1 - [t] I haven't looked at your code in depth, but these long contexts are something of a red flag. Overloading in Haskell is a very neat mechanism, but it is not really suitable for inner loops; each type class listed turns into an extra parameter, and proxy methods use indirect function calls for the operations (which unfortunately show up in profiles with the same names as the specific operations). I would try specializing to StdGen, UArray, and Int, for RandomGen, IArray, and Random respectively. P.S. Most real programs (outside of specialized niches like Monte-Carlo simulation) spend neglible amounts of time in random number generation. Profile before optimizing! If you've already profiled the real program, ignore this postscript. Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance problem with random numbers
stefanor: On Sat, Oct 13, 2007 at 12:09:57AM +0200, ntupel wrote: Dear all, I have implemented a small module to generate random items with a given probability distribution using the alias approach [1] and unfortunately compared to similar implementations in C++ or Java it is about 10 times slower. I have to confess that I am still in the early stages of writing Haskell programs so there is hopefully something I can do about it and I hope some helpful soul on this list can give me a hint. setup :: (Ord a, IArray a2 a, IArray a1 e, Num a) = [e] - [a] - (a1 Int e, a1 Int e, a2 Int a) calcAlias :: (Ord e, Num e, IArray a e, Ix i, IArray a2 e1, IArray a1 e1) = a2 i e1 - a1 i e1 - a i e - [i] - [i] - (a1 i e1, a i e) next :: (IArray a2 e1, IArray a e1, Ord e, IArray a1 e, RandomGen t, Random e) = (a Int e1, a2 Int e1, a1 Int e) - t - (e1, t) randomList :: (Random e, RandomGen t1, IArray a2 e, Ord e, IArray a t, IArray a1 t) = (a Int t, a1 Int t, a2 Int e) - t1 - [t] I haven't looked at your code in depth, but these long contexts are something of a red flag. Overloading in Haskell is a very neat mechanism, but it is not really suitable for inner loops; each type class listed turns into an extra parameter, and proxy methods use indirect function calls for the operations (which unfortunately show up in profiles with the same names as the specific operations). I would try specializing to StdGen, UArray, and Int, for RandomGen, IArray, and Random respectively. P.S. Most real programs (outside of specialized niches like Monte-Carlo simulation) spend neglible amounts of time in random number generation. Profile before optimizing! If you've already profiled the real program, ignore this postscript. Stefan I agree with Stefan's analysis. Very suspicious types for high performance code! And again, the only time random generation actually mattered to me was in a high perf monte carlo simulation, after all the inner loops had been specialised. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Performance problem with random numbers
dons: stefanor: On Sat, Oct 13, 2007 at 12:09:57AM +0200, ntupel wrote: Dear all, I have implemented a small module to generate random items with a given probability distribution using the alias approach [1] and unfortunately compared to similar implementations in C++ or Java it is about 10 times slower. I have to confess that I am still in the early stages of writing Haskell programs so there is hopefully something I can do about it and I hope some helpful soul on this list can give me a hint. setup :: (Ord a, IArray a2 a, IArray a1 e, Num a) = [e] - [a] - (a1 Int e, a1 Int e, a2 Int a) calcAlias :: (Ord e, Num e, IArray a e, Ix i, IArray a2 e1, IArray a1 e1) = a2 i e1 - a1 i e1 - a i e - [i] - [i] - (a1 i e1, a i e) next :: (IArray a2 e1, IArray a e1, Ord e, IArray a1 e, RandomGen t, Random e) = (a Int e1, a2 Int e1, a1 Int e) - t - (e1, t) randomList :: (Random e, RandomGen t1, IArray a2 e, Ord e, IArray a t, IArray a1 t) = (a Int t, a1 Int t, a2 Int e) - t1 - [t] I haven't looked at your code in depth, but these long contexts are something of a red flag. Overloading in Haskell is a very neat mechanism, but it is not really suitable for inner loops; each type class listed turns into an extra parameter, and proxy methods use indirect function calls for the operations (which unfortunately show up in profiles with the same names as the specific operations). I would try specializing to StdGen, UArray, and Int, for RandomGen, IArray, and Random respectively. P.S. Most real programs (outside of specialized niches like Monte-Carlo simulation) spend neglible amounts of time in random number generation. Profile before optimizing! If you've already profiled the real program, ignore this postscript. Stefan I agree with Stefan's analysis. Very suspicious types for high performance code! And again, the only time random generation actually mattered to me was in a high perf monte carlo simulation, after all the inner loops had been specialised. I should add: and in that case we called the mersenne twister generator carefully optimised in C. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
