Re: How does GHC's testsuite work?
Cher Sébastien, > Thanks. Unfortunately, the paper has been written in French. No need to add ``Unfortunately''... ;-) > Will come back with a link ASAP! I guess that many will agree with my opinion: Links to French papers are welcome, too! Amicalement, Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: simultaneous ghc versions
On Sat, Aug 01, 2015 at 06:31:38AM +1000, Erik de Castro Lopo wrote: I maintaing multiple versions of GHC on all the machines I use regularly for Haskell development. I have: * ghc-7.6.3 installed under /usr/lib/ghc-7.6/ * ghc-7.8.4 installed under /usr/lib/ghc-7.8/ * ghc-7.10.2 installed under /usr/lib/ghc-7.10/ To switch between versions all I need to do is modify $PATH to remove say /usr/lib/ghc-7.6/bin and add /usr/lib/ghc-7.10/bin. This lets me have two terminal window side by side with different versions of GHC. I use essentially the same setup, but found that cabal-install does not play nicely with this: No matter under which prefix I install cabal-install, it always assumes the same global path for its configuration file. This is a nuisance in particular when for some reason different versions of GHC need different versions of cabal-install --- apparently older GHCs don't work with newer versions of cabal-install? I did experiment with cabal-install's -w and sandboxes, and agree with what was previously mentioned: It only helps if you never use GHC without cabal-install. It would be nice if cabal-install had an installation-time option to set its prefix directory FOR EVERYTHING. The best cludge I found was scripts /usr/lib/ghc-*/bin/mycabal that call /usr/lib/ghc-*/bin/cabal with appropriate options... Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: base package (Was: GHC 7.8 release?)
On Thu, Feb 14, 2013 at 03:48:51PM +0100, Joachim Breitner wrote: Yesterday, I experimented a bit with base’s code, [...] Maybe the proper is to reverse the whole approach: Leave base as it is, and then build re-exporting smaller packages (e.g. a base-pure) on top of it. The advantage is: * No need to rewrite the tightly intertwined base. * Libraries still have the option to have tighter dependencies. * Base can evolve with lots of breaking changes, as long as they do not affect the API by the smaller packages. * Development of this collection can happen outside the GHC tree. * Alternative implementations for (some of) these packages can be created, if the reason why they could not be moved out of base is one of implementation, not of API How does that sound? Essentially good to me... One might consider instead (as has been proposed before, I believe), to rename the current ``base'' to something like ``ghc-base'' which is not intended to be depended on by packages not shipped with GHC (that is, by default ``hidden'' in ghc-pkg), and instead export: base with a very stable interface io with a very stable interface GHCwith a probably rapidly evolving interface. * possibly other packages giving access to internals Most packages that currently depend on ``base'' would then depend only on ``base'' and possibly ``io'', and by virtue of the stability of these two interfaces would therefore not be affected by most GHC releases. This would effectively be ``splitting the interfaces GHC and io out from base'' instead of ``deprecating base and replacing it with the three new interfaces base-pure, io, and GHC''. That choice is possibly mostly a matter of taste --- I think that the name ``base'' is good for a user-facing interface, and the name ``ghc-base'' more indicative of its implementation-dependent character. Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
+RTS -S heap reporting oddity
During one of my long Agda runs (with GHC-7.4.2), I observed the following output, with run-time options +RTS -S -H11G -M11G -K256M : 7694558208 30623864 3833166176 0.11 0.11 234.75 234.7900 (Gen: 0) 7678904688 29295168 3847737784 0.11 0.11 242.04 242.0900 (Gen: 0) 7662481840 29195736 3861451856 0.11 0.11 249.31 249.3500 (Gen: 0) 7647989280 26482704 3872463688 0.12 0.12 256.64 256.6800 (Gen: 0) 4609865360 25764016 3886000448 0.09 0.09 261.04 261.0900 (Gen: 0) 4581294920 19435032 3891512272 0.07 0.07 265.37 265.4200 (Gen: 0) 4568757088 21095864 3902286000 0.08 0.08 269.70 269.7400 (Gen: 0) 4546421608 21618856 3913923976 0.09 0.09 274.04 274.0900 (Gen: 0) 452151 2894668056 3484748224 7.63 7.63 285.94 285.9800 (Gen: 1) 8085358392 23776128 3499185336 0.11 0.11 293.49 293.5300 (Gen: 0) 8064630856 32055112 3515876576 0.13 0.13 300.91 300.9500 (Gen: 0) 8040500112 31477608 3528105088 0.12 0.12 308.37 308.4100 (Gen: 0) 8031456296 29641328 3540632456 0.11 0.11 315.83 315.8700 (Gen: 0) 8018447264 30187208 3554339600 0.12 0.12 323.26 323.3100 (Gen: 0) To my untrained eye, this seems to be saying the following: In the first 4 lines, the heap runs (almost) full before (minor) collections. In lines 5 to 9 it apparently leaves 3G empty before collection, but ``those 3G'' then appear on line 9 in the ``amount of data copied during (major) collection'' column, and after that it runs up to fill all 11G again before the next few minor collections. What is really going on here? (Previously I had never seen such big numbers in the second column on major collections.) Wolfram P.S.: Same effect again, but more dramatic, later during the same Agda run: 448829488 4864536 5710435424 0.02 0.02 1422.80 1422.9000 (Gen: 0) 445544064 3251712 5710248752 0.01 0.01 1423.23 1423.3200 (Gen: 0) 450236784 4148864 5712696848 0.02 0.02 1423.68 1423.7700 (Gen: 0) 445240152 3828120 5713606328 0.02 0.02 1424.10 1424.1900 (Gen: 0) 443285616 5906448 5717731864 0.02 0.02 1424.52 1424.6100 (Gen: 0) 430698248 4773500032 5363214440 9.30 9.30 1434.21 1434.3000 (Gen: 1) 6148455592 13490304 5374609848 0.07 0.07 1439.83 1439.9200 (Gen: 0) 6185350848 27419744 5389326896 0.11 0.11 1445.50 1445.5900 (Gen: 0) 6168805736 23069072 5398725784 0.11 0.11 1451.22 1451.3200 (Gen: 0) 6157744328 23451872 5408370152 0.09 0.09 1456.93 1457.0300 (Gen: 0) 6151715272 25739584 5421044592 0.11 0.11 1462.62 1462.7200 (Gen: 0) 6132589488 24541688 5428809632 0.10 0.10 1468.26 1468.3700 (Gen: 0) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Call to arms: lambda-case is stuck and needs your help
for clunky...
For argument supply and ``into'' we use the opposite sequence,
``arg into pat'', and clunky could then become:
clunky = caseof
env -
var1 -
var2 -
lookup env var1 into
Just val1 -
lookup env var2 into
Just val2 - val1 + val2
... other case bindings for clunky
(This runs into similar nested layout issues as discussed recently;
if we were to change the layout rule (perhaps only for the new keywords)
to not apply if the next token is separated from the layout keyword
by only a single space, we could turn this into a more compact shape:
clunky = caseof
env - var1 - var2 - lookup env var1 into Just val1
- lookup env var2 into Just val2 - val1 + val2
... other case bindings for clunky
(The alignment of the two lookups and their preceding - is irrelevant here.)
)
``into'' would generalise pattern guards by allowing the same expression
to be matched against different patterns and still enable fall-through:
f = caseof
[x] - g x into [] - []
a : b : bs - (a, b) : h bs
... other cases, including g returning a singleton ...
This could be:
Proposal 4: ``case-group argument supply'' or ``generalised pattern guards''
Best wishes,
Wolfram
-
@InProceedings{Kahl-2004a,
author = {Wolfram Kahl},
title ={Basic Pattern Matching Calculi: A Fresh View on Matching
Failure},
crossref = {FLOPS2004},
pages ={276--290},
DOI = {10.1007/978-3-540-24754-8_20},
SpringerURL = {http://www.springerlink.com/content/3jet4qgw1q2nu0a8/},
abstract = {We propose pattern matching calculi as a refinement
of $\lambda$-calculus that integrates mechanisms appropriate for
fine-grained modelling of non-strict pattern matching.
Compared with the functional rewriting strategy
usually employed to define the operational semantics of
pattern matching in non-strict functional programming languages
like Haskell or Clean, our pattern matching calculi
achieve the same effects using simpler and more local rules.
The main device is to embed into expressions
the separate syntactic category of matchings;
the resulting language naturally encompasses
pattern guards and Boolean guards as special cases.
By allowing a confluent reduction system and a normalising strategy,
these pattern matching calculi provide a new basis for
operational semantics of non-strict programming languages
and also for implementations.}
}
@InProceedings{Kahl-Carette-Ji-2006a,
author = {Wolfram Kahl and Jacques Carette and Xiaoheng Ji},
title ={Bimonadic Semantics for Basic Pattern Matching Calculi},
crossref = {MPC2006},
pages ={253--273},
DOI = {10.1007/11783596_16},
SpringerURL = {http://www.springerlink.com/content/2715070606u63648/}
}
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ghc-cabal-Random
On Sat, Dec 31, 2011 at 11:43:26PM +0200, Yitzchak Gale wrote: Serge D. Mechveliani wrote: I have ghc-7.4.0.20111219 made from source and tested it on the DoCon-2.12 application -- thanks to people for their help! It looks all right. This was -- with skipping the module Random Now it remains to add the Random package. I have taken AC-Random Version 0.1 from hackage... Its installation requires Cabal.. And Cabal is difficult to install.. [...] Today, it is very unusual to use GHC by itself. To use Haskell, you install the Haskell Platform. That is GHC together with Cabal and a basic set of libraries. It is very easy to install. http://hackage.haskell.org/platform/ However, since you are willing and able to test bleeding-edge versions of GHC, you need to be able to live without the platform, which typically catches up to GHC versions only within a couple of months. Almost all Haskell software is expected to be installed using Cabal nowadays. It is important to know that people associate two packages with the name ``Cabal'': * cabal : package infrastructure shipped with GHC --- only a library. * cabal-install : package manager requiring a number of other packages (in particular networking packages), and providing the executable ``cabal'' Life without cabal-install is not only possible, but also safer. (See also: http://www.vex.net/~trebla/haskell/sicp.xhtml ) If you installed an experimental GHC version, it makes sense to install packages into the same directory, say /usr/local/packages/ghc-7.4.0.20111219. Assuming you downloaded AC-Random-0.1.tar.gz, do the following: tar xzf AC-Random-0.1.tar.gz cd AC-Random-0.1.tar.gz ghc --make Setup ./Setup configure --prefix=/usr/local/packages/ghc-7.4.0.20111219 -p ./Setup build -v ./Setup haddock ./Setup install -v Hope this helps! Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Recompile with -fPIC (was building a patched ghc)
I am not certain, but this may be the same problem that I once had, and that was solved by updating to binutils-2.20. ld --version GNU ld (GNU Binutils) 2.20.1.20100303 Wolfram On Fri, Feb 18, 2011 at 11:34:03AM +0100, José Pedro Magalhães wrote: Hi all, I'm getting the same error as Alexy below in some 64bit linux system. What can I do? Adding -fPIC and also -dynamic does not seem to solve the problem. Also, this only happens with a perf build; devel1 works fine. Thanks, Pedro On Sat, Jun 26, 2010 at 05:56, braver delivera...@gmail.com wrote: An attempt to build the trunk gets me this: /opt/portage/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64- pc-linux-gnu/bin/ld: rts/dist/build/RtsStartup.dyn_o: relocation R_X86_64_PC32 against symbol `StgRun' can not be used when making a shared object; recompile with -fPIC -- I use prefix portage on a CentOS box, admittedly a non-standard setup. Its gcc is found first and it wants -fPIC... Should I just add it to CFLAGS or what? -- Alexy ___ Haskell-Cafe mailing list haskell-c...@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe !DSPAM:4d5e4b2789541804284693! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users !DSPAM:4d5e4b2789541804284693! ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Trying to build Agda 2.2.9 with ghc-7.1.20110131
On Tue, Feb 01, 2011 at 06:01:04PM +0300, Pavel Perikov wrote: If anyone interested... Agda-2.2.9 compiled perfectly with 7.0.1 release but with 7.1.20110131 the compiler had a few problems including impossible happened when building profiling library. Possibly related: http://hackage.haskell.org/trac/ghc/ticket/4462 Therefore: does the problem change if you pass --ghc-options=-dcore-lint to ./Setup configure -p ? Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
How to activate DEBUG in Data.HashTable?
Hello, with a large Agda development, I have a reproducible segmentation fault that I have been able to localise to the serialisation (Agda.TypeChecking.Serialise.encode), which heavily relies on Data.HashTable. Now I find that Data.HashTable (from GHC-7.0.1) has a CPP-enabled DEBUG version --- is there a ``proper'' way to activate this? Possibly even so that it can be added ex-post to an existing installation? (So I don't have to re-install all packages.) mk/ways.mk says that the ``debug'' way only affects the RTS... Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Feedback request: priority queues in containers
Louis Wasserman wrote:
I'm not willing to do this sort of typeclass wrapper thing, primarily
because nothing else in containers does -- even though we might have a
Mapping type class that handles both IntMap and Map, we don't.
I'm inclined to let that design choice stand, as far as containers is
concerned. It would make perfect sense to write a new package with such a
type class and offering instances for the containers priority queue
implementations, but I prefer to stick with the style that containers
already seems to use -- that is, exporting separate modules without a
unifying type class, but with nearly-identical method signatures.
Just an aside (and shameless plug ;-): Since the signatures overlap so much,
it is in fact easy to wrap these modules into instances
for many possible different type classes that one might consider using for
containers --- I have a tool that mechanises this instance generation,
available at:
http://sqrl.mcmaster.ca/~kahl/Haskell/ModuleTools/
More about this in the forthcoming TFP 2009 proceedings paper:
@InCollection{Kahl-2009_TFP,
author = {Wolfram Kahl},
title ={Haskell Module Tools for Liberating Type Class Design},
crossref = {TFP2009},
pages = {129--144},
chapter = {9},
abstract ={Design of Haskell type class hierarchies for complex purposes,
including for standard containers, is a non-trivial exercise,
and evolution of such designs
is additionally hampered by the large overhead
of connecting to existing implementations.
We systematically discuss this overhead,
and propose a tool solution, implemented using the GHC API,
to automate its generation.}
}
@Book{TFP2009,
title = {Trends in Functional Programming, {TFP 2009}},
booktitle = {Trends in Functional Programming, {TFP 2009}},
year = 2010,
editor ={Zolt\'an Horv{\'a}th and Vikt\'oia Zs{\'o}k and Peter Achten and
Pieter Koopman},
address = {UK},
publisher = {Intellect},
note = {(In press)}
}
Wolfram
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Running GHC 6.10.* on OpenBSD
On Sat, Dec 12, 2009 at 05:30:44AM +0200, Thanos Tsouanas wrote: Up to now I've only used binary versions of GHC, but since my operating system's (OpenBSD) version of GHC is lagging behind (currently at 6.6.1), I need to update it. I tried using my system's ghc-6.6.1 to compile ghc-6.10.4 but it failed due to haskeline not being installed (and trying to install it also failed). If Haskeline continues to make trouble (it seems to at least contribute to the crashing of GHCi on PowerPC), you could try to do a build without GHCi first --- Haskeline is not needed for the compiler. (I haven't tried that yet myself, since it only crashes at runtime.) Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Update on GHC 6.12.1
Simon Peyton Jones answered me:
| do { a - getChar
|; rec { b - f c
| ; c - g b }
|; putChar c
|; return b }
| This last point notwithstanding,
| I find the scoping rules very unintuitive!
| (b and c appear to escape their apparently nested scope.)
well you are happy with
^
(Let's say: I got used to it...)
do { z - getChar
; let { b = f c
; c = g b }
; putChar c
; return b }
It's just the same!
Indeed; I had not noticed that.
(I am spoilt by layout, and had never ``seen'' those braces before.)
However, if you write those braces, there is no reason anymore to omit the
``in do'' at the end! This variant of let is only motivated by layout...
Analogously, is
| do { a - getChar
|; rec { b - f c
| ; c - g b }
|; putChar c
|; return b }
equivalent to
| do { a - getChar
|; rec { b - f c
| ; c - g b } in do
| { putChar c
| ; return b }
?
Is
| do { rec { b - f c
| ; c - g b }
|; putChar c
|; return b }
equivalent to
| rec { b - f c
| ; c - g b } in do
|{ putChar c
|; return b }
?
Would ``dorec'', in analogy with ``letrec'', perhaps be a better name?
Wolfram
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Update on GHC 6.12.1
Simon Peyton Jones wrote:
Recursive do-notation.
~~
The change is this. Instead of writing
mdo { a - getChar
; b - f c
; c - g b
; putChar c
; return b }
you would write
do { a - getChar
; rec { b - f c
; c - g b }
; putChar c
; return b }
That is,
* 'mdo' is eliminated
* 'rec' is added, which groups a bunch of statements
into a single recursive statement
See http://hackage.haskell.org/trac/ghc/ticket/2798
This 'rec' thing is already present for the arrow notation, so it
makes the two more uniform. Moreover, 'rec' lets you say more
precisely where the recursion is (if you want to), whereas 'mdo' just
says there's recursion here somewhere. Lastly, all this works with
rebindable syntax (which mdo does not).
The main question is not whether to make this change, but when.
This last point notwithstanding,
I find the scoping rules very unintuitive!
(b and c appear to escape their apparently nested scope.)
Wolfram
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Template-haskell] How to extract name and type of exported functions in modules
Simon Peyton Jones wrote: What is the info for an instance? Do we need a way to ask for all the instances of a class (or rules for a function) regardless of what module those instances come from? etc Does this ring bells for anyone else? It does --- but completely outside the context of Template-Haskell. I have been trying to do things via the GHC API (the full API, not just module GHC), and found it surprisingly hard to obtain all exports for a given module (whether source or compiled library module): -- If it exports any prelude indentifiers (not only the Prelude itself, but also for example Data.List), I have no idea how to get at their types --- lookupGlobalName does not find them. -- I cannot find any re-exported instances. The ``package InstEnv'' obtained from tcGetInstEnvs after loading a library module interface (via findAndReadIface) seems to contain only the module's own exported instances, which are the same instances I also find via mi_insts. (For source modules, where I use typeCheckModule, I've only been able to find the module's own exported instances via hptInstances). Even while not counting the missing Prelude instances, Data.Map is still re-exporting the Data.Set instances from the same package --- where does GHC keep those? And where does it keep those from different packages? my current understanding of the ``home InstEnv'' is that it contains instances encountered during ``ghc --make'' that may not be visible in the current module, so if I ever do find instances there, how would I filter the visible ones? Do we need a way to ask for all the instances of a class (or rules for a function) regardless of what module those instances come from? etc As long as a module re-exports an instance, I'd like to be able to find it from that module. For example, if module exports T( C1, C2), where C1, C2 are constructors of T which also has constructors C3, C4, what should appear in mi_exports? Should mi_exports reflect the structure of the export list (see the AvailInfo type in GHC). Applications that look at a module ``from the outside'' should, in my opinion, not be able see C3 and C4. I think they also do not need to be able to know that there are additional constructors. There is always _|_ that doesn't match C1 nor C2, even if there are no C3 nor C4. Applications that need to know more will want an interface that allows to ``look at all the insides'' of a module, i.e., they want access to all items defined and imported inside, and may of course also want to know which of these items are exported. Since there are other interfaces to find out that C1 and C2 belong to T, I don't think it is essential to know the structure of the export list. It may be convenient, though... (By the way, IIRC, sometimes I can import C1 as ``C1'', and sometimes I need to import it as ``T(C1)''. Is this a side effect of some LANGUAGE extension?) Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Portage slots for GHC?
Duncan Coutts wrote: Sadly not because portage is not clever enough to deal with the kind of dependencies you end up with by doing that. Portage does not know that some libs are installed for one ghc and some for another, so it'd try and satisfy a dependency for mtl using the mtl you'd installed for ghc-6.4.2 when in fact you were building something for 6.6.1. You may have heard of other new portage features that sound like they'd help, they don't. We've thought about this a lot and it is not feasible in with the current portage. We could slot multiple versions of a lib for the same ghc, but not slot ghc itself. Why not library slots named ghc-6.4 ghc-6.6 ghc-6.8 (or finer), each depending on the repective compiler slot? The different slots of gtk+ also depend on different slots of glib. Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Portage slots for GHC?
Duncan Coutts wrote:
We could slot multiple versions of a lib for the same ghc, but not slot
ghc itself.
Why not library slots named
ghc-6.4
ghc-6.6
ghc-6.8
(or finer), each depending on the repective compiler slot?
The different slots of gtk+ also depend on different slots of glib.
But those are actually different versions of the Gtk+ library. Our
situation is worse, we have the exact same library version slotted for
multiple versions of ghc.
We'd want to be able to say something like:
SLOT=${GHC_PV}-${PV}
to slot on the ghc version and library version. But where does ${GHC_PV}
come from?
Well, suppose we could do that, now how do we specify the deps:
DEPEND=dev-haskell/foo:???
it's supposed to be the same ghc slot as our own slot is. But we can't
get that information.
Until portage actually can do this in a better way,
you would have to multiply ebuilds
(probably each with common import and a one-line variable setting)
(I don't know the exact restrictions on portage version strings):
=== mtl-common-X.Y.Z ===
...
SLOT=${GHC_PV}-${PV}
DEPEND=dev-haskell/ghc-${GHC_PV}
...
=== mtl-ghc.6.6..X.Y.Z ===
GHC_PV=ghc.6.6
include mtl-common-X.Y.Z
=== mtl-ghc.6.8..X.Y.Z ===
GHC_PV=ghc.6.8
include mtl-common-X.Y.Z
One day, you may even want mtl for other compilers...
Wolfram
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Getting source code
It would also be nice to have the case issue with Mac OS X document, as recent file systems have been case-insensitive for a while. Just a quick note: At Mac OS X install time (or other file system creation time) you can choose case sensitivity for HPFS+ (the default file system on Mac OS X). Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)
You do not perchance have one for powerpc, do you? I attempted to bootstrap from GHC 6.6.1, but I keep getting errors about Illegal Instructions, Try to force ./configure --build=powerpc-mac-darwin or whatever is appropriate under MacOS --- without it, ./configure will identify the target as powerpc64-... --- just give it a try without the 64. (This is what I need with 32bit userland under linux.) Otherwise try adding GhcUnregisterised=YES SplitObjs=NO to mk/build.mk. Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Unknown option -XPatternSig used in warning
| Illegal signature in pattern: a | Use -XPatternSigs to permit it | I am very happy to see that it doesn't recommend -fglasgow-exts anymore! However, I still would prefer Use LANGUAGE pragma with extension ``PatternSigs'' to permit it since it points out even more things that many may not have known before... By the way, some of my LANGUAGE pragmas are getting quite long, and last time I tried I was not allowed to have a line break in there. Are there any plans to allow line breaks, or multiple LANGUAGE pragmas? Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: building ghc6 on ppc64 linux
Has anyone successfully built it on ppc64 yet? The latest build I can find in a distro is ghc-6.4.2 in gentoo. Has anyone tried ghc [6.6.1] on ppc64? I have a gentoo binary package built some time ago from the gentoo ebuild for 6.6.1: http://sqrl.mcmaster.ca/~kahl/Haskell/ghc-bin-6.6.1.tbz2 This is for 32-bit userland running on a 64-bit kernel --- the default in gentoo, and currently restricts to unregisterised build. Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Cost of Overloading vs. HOFs
Adrian Hey wrote: Duncan Coutts wrote: One might hope that in this case we could hoist the extraction of the dictionary members outside the inner loop. This possibility had crossed my mind too. If HOFs really are faster (for whatever reason) then it should be possible for a compiler to do this automatically. Once everything is in terms of dictionaries, this should even be part of ``full laziness''. Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problems with 6.x compilers
6.4 and 6.4.1: When repeating a build (with ghc --make) all modules are rebuild even if nothing has changed. With earlier compilers, only linking takes place in this setting. Can I change this behaviour? I cannot develop this way. Should not happen, if it does there is a bug. Can you tell us how to repeat the behaviour you're seeing? We aren't seeing any unecessary recompilation here. I think I had that effect exactly when using -ddump-minimal-imports Wolfram ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: outputs during runtime
Nicole Gabler [EMAIL PROTECTED] wrote:
During runtime I want the program to output =
information about the status every time another file is parsed. That =
doesn't work, the output appears much later, mostly not until end of =
program. But I need these outputs at that specific time, so what can I =
do to manage it?
Perhaps the following fragment from my prelude extensions helps.
It requires ``import IO''.
Most probably you would either be calling
printList \n statusInformationList
or factor out the flushing part
for interleaving with your other IO actions.
Wolfram
%{{{ hPutList, printList
It is frequently annoying if a long-running program
writes a list of items to a channel or file,
and while it calculates the next item,
the last item has usually not yet been (completely) written
because at least part of it is still held in some output buffer.
The following functions flush the output buffer after every
item.
The most general variant, \verb|hPutList|,
is parameterised by a separator string for list items,
a \verb|shows| function for items,
and a handle for output.
The variant \verb|putList| writes always to the standard output channel,
and \verb|printList| in addition uses the \verb|shows| function
supplied by the type class system.
\begin{code}
hPutList :: String - (a - ShowS) - Handle - [a] - IO ()
hPutList sep shows h = mapM_ f
where f x = hPutStr h (shows x sep) hFlush h
putList :: String - (a - ShowS) - [a] - IO ()
putList sep shows = hPutList sep shows stdout
printList :: Show a = String - [a] - IO ()
printList sep = putList sep shows
\end{code}
%}}}
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Trivial Haskell Concurrency problem
Simon Peyton-Jones [EMAIL PROTECTED] writes: | elegant. If MVar's were instances of Ord as well as Eq, a | neat solution would | be to always get the least MVar first, but they aren't. So | what should one do? But you could make Flag an instance of Ord data Flag = MkFlag Int (MVar Bool) Now newMVar needs to consult a global variable to get the next Flag number, but after that there's no global locking. This is, of course, precisely what we'd have to do to make MVars an instance of Ord --- but it would impose a cost on all MVars, whether or not they needed it, which is why we've not done it. This is something that I have long been wondering about (perhaps it is just because of my ignorance): Wouldn't stable pointers be a cheaper and more appropriate means to get Ord for MVars, STRefs, and IORefs? Best regards, Wolfram
Re: Trivial Haskell Concurrency problem
Simon Peyton-Jones [EMAIL PROTECTED] answers my question: | This is something that I have long been wondering about | (perhaps it is just because of my ignorance): | Wouldn't stable pointers be a cheaper and more appropriate means | to get Ord for MVars, STRefs, and IORefs? Could be -- but do we really want to clog up the stable-pointer table with an entry for every MVar, whether or not anyone is interested in ordering? I think what you want is a distributed way to get a unique, as George suggested. Then you can pair that with an MVar when you want something comparable. The unique can include the processor id, so it can be globally unique. 64 bits? I'm still leery of putting such a unique inside every MVar, IORef etc. But maybe I shouldn't worry. Perhaps I should give some background: I am interested in implementing graph structures, and would need to handle mappings between graphs, or node labellings, or whatever. All these mappings need not reside in the graph itself, so they would require some FiniteMap structure. However, most decent such data types require Ord for being able to work efficiently. If IORefs (or whatever I use) are not ordered, then I have essentially two possibilities: 1) Do the Integer trick: slows down my program (as actually experienced in OCaml) 2) Do the memory management myself by allocating huge arrays and using the indices which are in Ord: clumsy and unwieldy So I would already be happy if IORefs, STRefs and MVars came with a variant in Ord (consider this as a concrete proposal for the standard library) --- even if some implementations choose to implement that via the Integer trick: hopefully the best implementations would provide something faster ;-) Best regards, Wolfram
Re: graphs
Wojciech Moczydlowski, Jr [EMAIL PROTECTED] (Khaliff TM) wrote: The second question - does anybody know about a GHC/Haskell library with graphs implementation? Depending on what precisely you need, Martin Erwig's ``Functional Graph Library'' might contain something useful for you: http://www.informatik.fernuni-hagen.de/import/pi4/erwig/fgl/ Wolfram
