On 04/08/2011 21:02, Simon Peyton-Jones wrote:
| data LiteralDesugaring m =
|LiteralDesugaring
| { desugarInt :: MonadThings m = Integer - m CoreExpr
| , desugarWord :: MonadThings m = Integer - m CoreExpr
...
I am not sure why you want to control the desugaring of literals.
On 05/08/2011 08:45, Jens Petersen wrote:
On 5 August 2011 05:27, Ian Lynaghig...@earth.li wrote:
from http://koji.fedoraproject.org/koji/getfile?taskID=3251249name=build.log .
| *** unexpected failure for fed001(normal)
but it works fine for me on x86/Linux.
Note the Fedora build is
On 05/08/2011 12:08, Joachim Breitner wrote:
Hi,
Am Freitag, den 05.08.2011, 09:46 +0100 schrieb Simon Marlow:
I don't like having to do this, but it reduces our testing surface (we
don't want to have to test against N different versions of libffi). I'm
quite happy for distros to build
On 07/08/2011 02:18, Evan Laforge wrote:
On Sat, Jul 30, 2011 at 9:25 PM, Ian Lynaghig...@earth.li wrote:
But I also think we may as well just remove most of these conditionals.
The GHC 4.09 tests can surely be removed, and likewise the GHC 6.3
tests. Personally I'd remove the GHC 6.10 test
On 09/08/2011 05:59, Jens Petersen wrote:
I'm quite happy for distros to build against their system libffi though, and we
should
make that easier. Note that if you build against the system libffi you are
responsible for fully testing the combination (I know you already do that,
which is
On 09/08/2011 02:44, Evan Laforge wrote:
So the simplest thing to do is remove all the version stuff. That
means that if you want to run hsc2hs with a version of ghc which is
not the one linked in /usr/bin, you also can't run the hsc2hs linked
in /usr/bin, but have to get the one out of the
An Array# of size zero is a perfectly reasonable thing. If it doesn't
work, it should (and I vaguely recall making it work at some point in
the past, but perhaps I failed to add a test and as a result it has
rotted...)
Cheers,
Simon
On 22/08/11 17:08, Johan Tibell wrote:
I agree
You could make it a precondition of copyArray#, although that's slightly
less pleasant from a user's perspective.
Cheers,
Simon
On 23/08/11 21:04, Johan Tibell wrote:
It could well be that it's some later primop that's failing due to the
empty size, like my new copyArray# primop. If
On 24/08/2011 13:12, Joachim Breitner wrote:
Hi,
Am Mittwoch, den 24.08.2011, 12:44 +0200 schrieb Matthias Klose:
The question that has to be answered first is: Assume the libraries do
not depend on libffi themselves, and only ghc does. Now you update
libffi and ghc gets rebuilds, what will
On 30/08/2011 00:42, Thomas Schilling wrote:
The performance problem was due to the use of unsafePerformIO or other
thunk-locking functions. The problem was that such functions can
cause severe performance problems when using a deep stack. The
problem is that these functions need to traverse
On 01/09/2011 08:44, Evan Laforge wrote:
Yes, the plan was to eventually have a parallel --make mode.
If that's the goal, wouldn't it be easier to start many ghcs?
It's an interesting idea that I hadn't thought of. There would have to
be an atomic file system operation to commit a compiled
On 01/09/2011 18:02, Evan Laforge wrote:
It's an interesting idea that I hadn't thought of. There would have to be
an atomic file system operation to commit a compiled module - getting that
right could be a bit tricky (compilation isn't deterministic, so the commit
has to be atomic).
I
On 03/09/2011 02:05, Evan Laforge wrote:
Another way to do this would be to have GHC --make invoke itself to
compile each module separately. Actually I think I prefer this method,
although it might be a bit slower since each individual compilation has
to read lots of interface files. The main
On 06/09/2011 09:47, Kazu Yamamoto (山本和彦) wrote:
Recently I exchanged information about user threads with Ruby
community in Japan.
The user threads of Ruby 1.8 are heavy weight and Ruby 1.9 switched to
kernel threads. The reason why user threads of Ruby 1.8 are heavy
weight is *portability*.
On 07/09/2011 08:13, Kazu Yamamoto (山本和彦) wrote:
Simon,
Thank you for explanation.
- We have an accurate GC, which means that the Haskell stack can be
movable, whereas the C stack isn't. So we can start with small
stacks and enlarge them as necessary.
What is the difference
On 01 October 2004 08:45, Peter Simons wrote:
I am a happy user of hGetBufNonBlocking, but I have come to
realize that mutable arrays are nicer to work with than
pointers, so I have considered using hGetArray instead. I
do, however, depend on the fact that the function returns as
soon as it
On 02 October 2004 13:04, Tomasz Zielonka wrote:
On Fri, Oct 01, 2004 at 09:34:36PM +0100, Simon Marlow wrote:
Not currently, but I could probably implement the equivalent
(hGetArrayNonBlocking).
It is perhaps not closely related, but could we also have
Network.Socket recvFrom / sendTo
On 02 October 2004 01:22, John Goerzen wrote:
rm -f GHC/Base.o; if [ ! -d GHC/Base_split ]; then mkdir
GHC/Base_split; else /o pt/freeware/bin/find GHC/Base_split -name
'*.o' -print | xargs rm -f __rm_food; fi;
../../ghc/compiler/ghc-inplace -H16m -O -fglasgow-exts -cpp -Iinclude
-#include
this much more
easily.
Cheers,
Simon
On 02 October 2004 08:42, Adrian Hey wrote:
On Friday 01 Oct 2004 9:36 pm, Simon Marlow wrote:
Looks fine - GHCi is supposed to look in the directories in
import_dirs
for .hi files. What does ghci -v tell you?
Quite a lot :-), but nothing very
On 03 October 2004 02:14, Donald Bruce Stewart wrote:
Waldemar.Kornewald:
Hi,
is it possible to use a simpler build system for GHC? :)
It isn't so bad. It seems to be quite portable :)
We *are* using a simpler build system for GHC. You should have seen the
last one :-)
Cheers,
On 05 October 2004 10:16, John Meacham wrote:
Quite a few foreign calls in the library are missing threadsafe in
their declarations. if this could be fixed by 6.2.2 that would be
great. in particular
system, rawSystem, and DNS lookups are important to be able to do
concurrently.
Thanks,
On 03 October 2004 14:07, Tomasz Zielonka wrote:
Then I noticed the cause:
GHC.Prim.# returns a boxed, heap allocated Bool, and so do other
primitive comparison operators.
Would it be difficult to add Bool unboxing to GHC?
Maybe it would suffice to use preallocated False and True?
On 03 October 2004 19:34, Peter Simons wrote:
I have another I/O problem. I need to time out when a Handle
blocks forever. I am using hWaitForInput anyway, so that
shouldn't be a problem, but the documentation says that
using this feature will block all IO threads? Is it much
work to fix
On 04 October 2004 17:19, John Goerzen wrote:
On 2004-10-02, John Goerzen [EMAIL PROTECTED] wrote:
to help from people here, I have built a working GHC 6.2.1 for
AIX5.1L. (The last GHC I could find for AIX was GHC 2.09!)
As a follow-up question: what does it take to get this listed at
On 06 October 2004 00:53, John Meacham wrote:
On Tue, Oct 05, 2004 at 01:48:30PM +0100, Simon Marlow wrote:
It would probably be better to return 0#/1# instead of a Bool from
the comparison primops, because this would expose slightly more
detail to the simplifier and might result in slightly
On 06 October 2004 11:36, Josef Svenningsson wrote:
Simon Marlow wrote:
On 06 October 2004 00:53, John Meacham wrote:
This seems like it could be nicely generalized such that all
enumeration types unbox to the unboxed integer of their offset. so
data Perhaps = Yes | Maybe
On 19 October 2004 17:08, Peter Simons wrote:
The following reproducibly fails:
$ darcs get http://cryp.to/hsdns [*]
$ cd hsdns/
$ hsc2hs ADNS.hsc
$ ghc -threaded -Wall -O --make test.hs -o test -ladns
| Chasing modules from: test.hs
| Compiling ADNS (
On 20 October 2004 14:36, Adrian Hey wrote:
[Excuse me for moving this discussion to the ghc mailing list,
but it seems the appropriate place, seeing as ghc is where
any solution will happen first in all probability.]
I've noticed that the neither of the two Simons has expressed an
opinion
On 23 October 2004 19:25, Lauri Alanko wrote:
On Thu, Oct 21, 2004 at 09:17:20AM -0400, Robert Dockins wrote:
There is a hashtable in the IO monad:
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data.HashTabl
e.html
Why is it in IO instead of the more general ST? IMHO _all_
Sorry I should have broadcast a message about this; I mentioned it to
the *BSD guys because I knew they'd be affected, but forgot about
darwinports. Sorry about that.
Cheers,
Simon
On 23 October 2004 20:27, Gregory Wright wrote:
Hi Sven,
Yes, that would be it. The change is
On 22 October 2004 21:58, Peter Simons wrote:
I know it's a rather mundane question, but I couldn't find
an answer to it!
So what does happen when I forget to hClose a Handle? Will
the garbage collector do that for me? Or not?
Yes, a Handle will be automatically closed sometime after it
On 25 October 2004 14:24, John Goerzen wrote:
On 2004-10-25, Simon Marlow [EMAIL PROTECTED] wrote:
On 22 October 2004 21:58, Peter Simons wrote:
On 24 October 2004 23:37, John Goerzen wrote:
* What happens when one Handle corresponding to a socket is closed,
but another isn't?
You
I can't repeat this, it works here:
*Main test1
ExitSuccess
*Main test2
Just ExitSuccess
(after changing /usr/bin/sleep to /bin/sleep).
The only thing I can think of is that you somehow have a SIGCHLD handler
that calls wait(), but I don't see where that can be happening. GHC
doesn't have any
My apologies if I misinterpreted your comments. There appear to be some
use cases and conventions here that I'm not altogether familiar with.
So basically you're saying that if runProcess is to be used in a
system()-like way, that is the parent is going to wait synchronously for
the child, then
Just to let everyone know that Simon PJ and myself will be away for the
rest of this week and the next, and will probably have intermittent
network connectivity, so it might take us a while to respond to
messages.
Cheers,
Simon
___
On 04 November 2004 18:21, Ian Lynagh wrote:
However, if a .y file starts:
{
{-# OPTIONS -w #-}
-- Foo
{-# OPTIONS -w #-}
module Parser (parse) where
}
then the generated .hs file starts:
-- parser produced by Happy Version 1.14
-- Foo
{-#
On 06 November 2004 10:10, Sven Panne wrote:
Duncan Coutts wrote:
I can knock up a proof of concept patch if anyone thinks this is a
good idea. It should be totally backward compatible, it's ok to use
both, but ditro packagers might like to enforce a policy of using a
directory of package
On 08 November 2004 02:49, David Lo wrote:
I'm new in haskell. I'm assigned to see that a piece of Haskell code
need to be callable from C#. I find that I can convert Haskell to DLL
using ghc --mk-dll.
I find it is fine for simple function but for the following errors are
reported.
On 08 November 2004 18:47, Duncan Coutts wrote:
We can use ghc-pkg at the build / install-into-temp phase to create
the $(package).conf files under
$TMP_INSTALL_ROOT/usr/lib/ghc-$VER/package.conf.d/ and then final
installation is jsut merging files without any post-install calls to
ghc-pkg
On 09 November 2004 12:54, Duncan Coutts wrote:
[snip]
When I do time profiling, the big cost centres come up as putByte and
putWord. When I profile for space it shows the large FiniteMaps
dominating most everything else. I originally guessed from that that
the serialisation must be forcing
On 09 November 2004 17:04, Duncan Coutts wrote:
Are you using BinMem, or BinIO?
BinIO
Ah. BinIO is going to be a lot slower than BinMem, because it does
an hPutChar for each character, whereas BinMem just writes into an
array. I never really optimised the BinIO path, because we use
On 09 November 2004 17:36, Isaac Jones wrote:
Simon Marlow [EMAIL PROTECTED] writes:
On 08 November 2004 18:47, Duncan Coutts wrote:
We can use ghc-pkg at the build / install-into-temp phase to create
the $(package).conf files under
$TMP_INSTALL_ROOT/usr/lib/ghc-$VER/package.conf.d
On 15 November 2004 21:16, Stephane Bortzmeyer wrote:
[Not subscribed to haskell-users so please copy me the answers.]
To compile the revision control system Darcs (http://www.darcs.net/),
I need Haskell but I'm not myself a Haskell user.
My machine is an UltraSparc 10 running NetBSD
[ moved to [EMAIL PROTECTED] ]
On 16 November 2004 07:51, Fred Nicolier wrote:
I have some packages for doing signal and image processing stuff.
Here is a little test program :
\begin{code}
module Main where
import Hips
a = listSignal (1,10) [1..10]
b = liftSignals (:+) a a
c = fft
On 20 November 2004 23:02, Benjamin Franksen wrote:
I am using Foreign.Concurrent.newForeignPtr and touchForeignPtr
inside the finalizers to express liveness dependencies as hinted to
by the documentation. This doesn't seem to work, though, or at least
I can't see what I've done wrong. I
On 18 November 2004 20:31, Christian Maeder wrote:
calling unlit on a DOS file fails, whereas hugs is able to process the
same file (under unix).
Christian
Prelude readFile Test.lhs = putStrLn . show
\r\n module Test where\r\n\r\n
Prelude :l Test.lhs
Test.lhs line 2: unlit: Program
On 21 November 2004 00:56, Isaac Jones wrote:
The systems that would want to do this kind of thing, such as Debian,
have other mechanisms for deciding whether packages conflict, etc.
IIRC, this is the argument I just used against adding support for
multiple libraries in Cabal, so I guess I
On 22 November 2004 17:28, Benjamin Franksen wrote:
I understand that there are situations where finalizers cannot be
guaranteed to run: First because of an unconditional termination
signal (SIGKILL), second because of circular dependencies resulting
in a deadlock.
I don't understand why
version
Cheers,
Simon
On 17 November 2004 12:37, Fred Nicolier wrote:
Simon Marlow wrote:
Please send the output of command (2) with -v added to the command
line.
Cheers,
Simon
I have isolated the dependancies of the packages : the work file is
now : \begin{code
On 17 November 2004 14:01, Christian Maeder wrote:
[EMAIL PROTECTED] - uname -a
SunOS leo 5.8 Generic_117000-05 sun4u sparc SUNW,Sun-Fire-280R
[EMAIL PROTECTED] - ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.2.1
[EMAIL PROTECTED] - gcc -v
Reading specs from
On 23 November 2004 13:46, Keean Schupke wrote:
Simon Marlow wrote:
Note that the GC only starts the finaliser thread. The program can
still terminate before this thread has run to completion (this is one
reason why we say that finalisers don't always run before program
termination
On 30 November 2004 09:35, John Meacham wrote:
On Tue, Nov 30, 2004 at 12:41:04AM -0800, Krasimir Angelov wrote:
Hello guys,
I am working on updated version of HDirect and now I
am going to use CWString API to marshal (wchar_t *)
type to String. I found some inconsistencies in the API.
On 04 December 2004 01:49, Ben Kavanagh wrote:
I'm going to create a standard dist for cygwin.
In order to do so, according to the porting guide I need to build a
set of .hc files with mingw32(same hardware) and then use hc-build
with those. To create the hc files from mingw32 for use with
On 04 December 2004 04:27, Judah Jacobson wrote:
What exactly are redex's, in this context,
Any expression which can be beta-reduced or case-reduced.
and is it (still?) true that GHC never expands them?
I'm not sure if GHC guarantees never to duplicate a redex, Simon PJ
might know.
Or are
On 06 December 2004 06:03, Adam Megacz wrote:
Hrm, is the GHC magic memo function still around? In 5.0.4 it was
in util, but I can't seem to find it in 6.2.2.
It's still there in module Memo, in the util package. It's scheduled
for demolition in 6.6.
Cheers,
Simon
On 06 December 2004 13:25, Simon Peyton-Jones wrote:
and is it (still?) true that GHC never expands them?
I'm not sure if GHC guarantees never to duplicate a redex, Simon PJ
might know.
Yes, it's very careful not to duplicate a redex, except for ones of
known bounded size, like x +# y,
On 06 December 2004 21:31, Sven Panne wrote:
Hmmm, having some fragile OS-dependent #ifdefs is not the way to go.
While you are there, every
#ifdef mingw32_TARGET_OS
which needs to be changed should be replaced by something
feature-specific like
#if HAVE_FOO_BAR_FUNCTION
Good
On 08 December 2004 09:10, Adam Megacz wrote:
Simon Marlow [EMAIL PROTECTED] writes:
It's still there in module Memo, in the util package. It's scheduled
for demolition in 6.6.
Huh... why? It's pretty convenient, especially if you're aware of the
relevant GC issues and don't mind them
On 10 December 2004 10:55, Mårten Dolk wrote:
Btw, you import GHC.IO and not System.IO. What is the diffrence
between those two?
System.IO is guaranteed to be there in the next release :-)
Cheers,
Simon
___
Glasgow-haskell-users mailing list
On 14 December 2004 10:46, Arjen van Weelden wrote:
I compiled a Haskell 98 program using ghc 6.2 -O and ran the
executable, using main +RTS -H256m -s, on two similar computers:
PC 1: Athlon 1400, 512MB, Windows XP Prof SP2 (successful termination)
PC 2: Athlon XP 1800+, 512MB, Windows XP
On 16 December 2004 16:12, Peter Simons wrote:
I'm getting this error in my software every now and then:
postmaster: internal error: scavenge_stack: weird activation record
found on stack: 9 Please report this as a bug to
[EMAIL PROTECTED], or
On 09 December 2004 17:46, Mårten Dolk wrote:
I'm trying to create a client application that needs to read and write
data from a socket. What I want to do is to have one thread reading
the socket and another thread writing to the same socket, but I can't
get it to work.
I know that there
On 21 December 2004 17:38, Sven Panne wrote:
[EMAIL PROTECTED] wrote:
Okay, I've tried to follow the directions, and ran into a couple
minor issues I was able to work through, but I got stuck at the cd
H/libraries make boot make stage. The host system is redhat
enterprise linux 3, the
On 03 January 2005 15:19, Peter Simons wrote:
I wrote:
Simon Marlow writes:
Please compile the program with -debug, then open it
with gdb.
Unfortunately, -debug seems to conflict with -threaded:
ghc --make -threaded -debug -O -Wall [...] -o postmaster
tutorial.lhs
On 05 January 2005 22:20, Wolfgang Thaller wrote:
The hook idea works with static linking: the RTS provides a default
version of the hook, that can be overriden by a user-supplied
function of the same name. This is what GHC does. However, our
dynamic linker doesn't support this kind of
On 09 January 2005 06:50, Sean Seefried wrote:
I have managed to build package GHC *and* load it into GHCi.
Initially this did not work. When I loaded up ghci with the -package
ghc flag I was assaulted with the following error message.
GHCi runtime linker: fatal error: I found a
On 11 January 2005 02:29, Dimitry Golubovsky wrote:
Bad thing is, LD_PRELOAD does not work on all systems. So I tried to
put the code directly into the runtime (where I believe it should be;
the Unicode properties table is packed, and won't eat much space). I
renamed foreign function names in
On 12 January 2005 12:49, Christian Maeder wrote:
in a new version of ghc I've noticed that a colon in a path (as
argument to -i) is no longer recognized. Will this also be the case
in the new version ghc-6.4?
Thanks! In fact I broke that by accident recently. Now fixed.
Cheers,
On 14 January 2005 13:35, Peter Simons wrote:
after rebuilding ghc-current, I got an intact Cabal version
and managed to install HaXml successfully. However, when I
try to link a program that actually uses the package, the
linker stage fails with these errors:
On 14 January 2005 12:58, Dimitry Golubovsky wrote:
Now I need more advice on which flavor of Unicode support to
implement. In Haskell-cafe, there were 3 flavors summarized: I am
reposting the table here (its latest version).
|Sebastien's| Marcin's | Hugs
On 13 January 2005 23:36, Nick Main wrote:
I'm planning to implement a small OO language on top of GHC (think
JavaScript) and need to decide on how to implement the mutable object
graph that is required.
The two approaches I'm considering are:
- something on top of Data.Graph
- using
On 18 January 2005 14:52, Duncan Coutts wrote:
While we're thinking about it, could a link to Gtk2Hs be added:
http://gtk2hs.sourceforge.net/ . Our web page has been updated to be
rather more current.
Done.
Simon
___
Glasgow-haskell-users mailing
On 18 January 2005 14:42, Ketil Malde wrote:
I seem to be getting messages from Sourceforge from this mailing
list. Is that an intended use for ghc-users?
It's intentional, but it can be easily turned off. Do people want to
see feature-requests, task-list entries and so forth on this mailing
On 15 December 2004 14:46, William Lee Irwin III wrote:
There seems to be some trouble with the debian ghci on sparc64. I can
dredge up more information if given an idea of what to look for.
$ ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive,
On 19 January 2005 05:31, John Meacham wrote:
A while ago I wrote a glibc specific implementation of the CWString
library. I have since made several improvements:
* No longer glibc specific, should compile and work on any system with
iconv (which is unix standard) (but there are still
, Simon Marlow wrote:
This turned out to be relatively straightforward. Two fixes:
ghc-asm.lprl needs slight modifications for new versions of gcc on
sparc-*-linux, and the dynamic linker also needs to have USE_MMAP
enabled due to needing to execute dynamically allocated memory.
I've made
On 17 January 2005 22:53, Sean Bowman wrote:
I'm trying to install HUnit to use with ghci and hugs and having some
trouble. It works if I use the -i option with ghci, but I'd rather
not have to specify that on the command line every time. Putting it
in a ~/.ghci file doesn't seem to work.
On 21 January 2005 09:13, Santoemma Enrico wrote:
I don't understand from the manual whether it is possible to have a
short .exe file and the rest as a dynamic linking part, or not yet.
Not at the moment. It was possible in the past, and it might be
possible again shortly in the future:
On 24 January 2005 09:11, Serge D. Mechveliani wrote:
-
Mon Jan 24 10:30 2005 Time and Allocation Profiling Report (Final)
a.out +RTS -M40m -p -RTS
total time =9.04 secs (452 ticks @ 20 ms)
total
On 26 January 2005 09:13, Serge D. Mechveliani wrote:
The indentation in the profiling report or in the source program?
In the profiling report.
The report prints some function names not from the beginning of the
line ...
Maybe, you can give a simple example of a program with SCC when the
On 27 October 2004 15:08, Glynn Clements wrote:
Simon Marlow wrote:
So basically you're saying that if runProcess is to be used in a
system()-like way, that is the parent is going to wait synchronously
for the child, then the parent should be ignoring SIGQUIT/SIGINT.
On the other hand
On 01 February 2005 10:33, Ben Horsfall wrote:
On 01 Feb 2005 10:32:14 +0100, Peter Simons [EMAIL PROTECTED] wrote:
I can't build the library's Haddock documentation anymore:
the process fails claiming that Control/Arrow-raw.hs would
be missing. I've had this problem for a while now. Does
On 01 February 2005 11:31, [EMAIL PROTECTED] wrote:
On Tue, Feb 01, 2005 at 11:02:45AM -, Simon Marlow wrote:
I'm making some changes to the way Haddock creates links, and I'd
like to solicit comments on possible alternatives.
The existing approach is for each non-locally-defined
On 01 February 2005 12:48, Ketil Malde wrote:
Simon Marlow [EMAIL PROTECTED] writes:
There are some problems with the existing approach. It doesn't cope
well with instances: instances might refer to types/classes not below
the current module in the hierarchy. Also you might import
On 02 February 2005 19:48, Peter Simons wrote:
Wolfgang Thaller writes:
a) poll() is not supported on Mac OS X and (at least some
popular versions of) BSD.
Are you certain? Just tried man poll on one of the MacOS X
machines the SourceForge compile farm offers, and that one
had it:
On 03 February 2005 00:41, Duncan Coutts wrote:
On Wed, 2005-02-02 at 13:30 -0700, Seth Kurtzberg wrote:
Duncan Coutts wrote:
In these cases we cannot turn on traditional profiling since that
would interfere with the optimisations we are relying on to
eliminate most of the other memory
On 02 February 2005 18:42, Duncan Coutts wrote:
On Wed, 2005-02-02 at 17:01 +, Simon Marlow wrote:
On 02 February 2005 13:38, Duncan Coutts wrote:
Would looking at the core files help? What would I be looking for?
Here's a simple version that I would expect to run in constance
space
On 02 February 2005 15:51, Ian Lynagh wrote:
The Debian ghc6 package curently has both a build-dependency and a
normal dependency on libreadline4-dev. The former is so the readline
library (and ghci) can be built, and the latter so compiling programs
with the readline package behaves
On 07 February 2005 19:28, Patrick Scheibe wrote:
It seems that there are changes in the OpenGl library during the last
month. So I decided to load a really young cvs version of the ghc
(ghc-6.5.20050206-src.tar.bz2). The compilation works fine.
My Problem is, that I also need the wxHaskell
On 08 February 2005 12:43, Lennart Kolmodin wrote:
I'm working on an IDE for Haskell, written in Haskell.
Currently, I'm looking for a way to parse .hs-files for a module
browser and I recall that Simon Marlow was going to release GHC as a
package soon.
We could also use that package
Hi folks,
For the forthcoming 6.4 release, we'd like to get a rough idea of
download statistics, at least from haskell.org. Both Simon I are too
busy/lazy (delete as applicable) to do this ourselves, and we don't know
the best tools to use (grep|wc on the access_log is a bit too crude - we
want
On 09 February 2005 20:03, Tomasz Zielonka wrote:
On Wed, Feb 09, 2005 at 01:11:34PM -, Simon Marlow wrote:
Hi folks,
For the forthcoming 6.4 release, we'd like to get a rough idea of
download statistics, at least from haskell.org. Both Simon I are
too busy/lazy (delete as applicable
We are finally at the release candidate stage for GHC 6.4. Snapshots
with versions 6.4.20050209 and later should be considered release
candidates for 6.4.
Source and Linux binary distributions are avaiable here:
http://www.haskell.org/ghc/dist/stable/dist/
Please test if you're able to, and
On 09 February 2005 08:53, Axel Simon wrote:
gcc uses a different convention from the Microsoft environment when it
comes to laying out fields in C structs, in particular bit fields.
Can I pass the -optc--mms-bitfields to ghc when it compiles via C
without negative effect?
This flag is not
On 10 February 2005 13:31, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] writes:
We are finally at the release candidate stage for GHC 6.4. Snapshots
with versions 6.4.20050209 and later should be considered release
candidates for 6.4.
Using: ghc-6.4.20050209-i386-unknown
On 10 February 2005 13:40, Simon Marlow wrote:
On 10 February 2005 13:31, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] writes:
We are finally at the release candidate stage for GHC 6.4.
Snapshots with versions 6.4.20050209 and later should be considered
release candidates
On 09 February 2005 13:32, Peter Simons wrote:
I have an interesting problem. There are two versions of the
HsDNS package installed right now:
$ ghc-pkg list
| /usr/local/ghc-current/lib/ghc-6.5/package.conf:
| rts-1.0, [...] (hsdns-2005-02-04),
| hsdns-2005-02-08
Now how
On 10 February 2005 15:13, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] writes:
We are finally at the release candidate stage for GHC 6.4.
Please test if you're able to, and give us feedback.
In versions 5.00 = ghc = 6.2.2, the result of
ghc -v 21 | head -2
On 10 February 2005 15:36, Malcolm Wallace wrote:
Simon Marlow [EMAIL PROTECTED] writes:
Ok, fixed. The right way to get the location of the package.conf
file is to ask ghc-pkg, BTW. In fact, the right way is not to know
the location of package.conf at all, but to use ghc-pkg to query its
On 10 February 2005 17:07, Malcolm Wallace wrote:
$ ghc-pkg-6.4.20050209 --show-package=base --field=import_dirs
[/usr/malcolm/local/lib/ghc-6.4.20050209/imports]
yet
$ ghc-pkg-6.4.20050209 --show-package=base-1.0 --field=import_dirs
ghc-pkg: cannot find package base-1.0
701 - 800 of 2671 matches
Mail list logo
