On Wed, 09 May 2007 17:42:11 +0900, Neil Mitchell <[EMAIL PROTECTED]> wrote:
>> Custom/complete: yes, typical: no. What on earth does "typical" mean? The
>> user has no idea whether it will install the features they need or not, so
>> it's
>> a meaningless option.
>
> From all I can tell, GHC 6
On Wed, 09 May 2007 17:31:51 +0900, Simon Marlow <[EMAIL PROTECTED]> wrote:
>> You forgot to include GLUT and readline packages.
>> I think you can't build these packages, so you don't include it.
>>
>> This is well-known problem, if build GHC your self.
>> Because MInGW doesn't have these headers
Hi,
On Wed, 09 May 2007 17:31:51 +0900, Simon Marlow <[EMAIL PROTECTED]> wrote:
> So to summarise, the following are missing from the binary distribution that
> Neil used as the basis for his installer:
>
> * readline
> * ALUT
> * OpenAL
> * GLUT
> * C++ support in the bundled GCC
>
> ri
On Wed, 2007-05-09 at 23:44 +0100, Frederik Eaton wrote:
> I think the problem is that there is a /usr/lib/libstdc++.so.5 and a
> /usr/lib/libstdc++.so.6 but no /usr/lib/libstdc++.so; when I created
> the latter, linking to the libstdc++.so.6 link, I was able to use ghci
> with my package. I wish
On Fri, Apr 27, 2007 at 11:01:49AM +0100, Simon Marlow wrote:
> Frederik Eaton wrote:
> >Hello,
> >I am wondering how to link a package with some dynamic libraries in a
> >way that works with ghci. If I run the command
> >LD_PRELOAD=/lib/libgcc_s.so.1:/usr/lib/libstdc++.so.6 ghci -package mypackage
[My apologies for the long'ish e-mail, for Win9x users mostly..]
Someone sent an e-mail querying about Win9x compatibility, which
is something I forgot to take into account when building the 6.6.1
installer. To remedy, I've refreshed the installer to include a new
version that ought to work acro
Hi
While wrapIO works in most cases, try running this:
:m +Control.Concurrent
forkIO (let foo = do threadDelay 100; print "A"; foo in foo)
I am not saying that this makes wrapIO unusable - just that it is not
bulletproof. If not using forkIO is ok, then this is a much easier
solution, than c
On Wed, May 09, 2007 at 10:48:15PM +0200, Mads Lindstr?m wrote:
> Hi
>
> Look at System.Posix.IO
>
> I do not know if that module can do what you want. But it does deal with
> FileDescriptors and handles.
>
> Maybe the dup function can help you. According to
> http://www2.lib.uchicago.edu/~keith
Hi Simon
The Interactive.hs program do not really redirect stdout. It intercepts
calls to putStrLn and getLine via let definitions:
mustWork "let putStrLn = MyPrelude.myPutStrLn"
mustWork "let getLine = MyPrelude.myGetLine"
-- mustWork either runs the given statement successfull
Hi
Look at System.Posix.IO
I do not know if that module can do what you want. But it does deal with
FileDescriptors and handles.
Maybe the dup function can help you. According to
http://www2.lib.uchicago.edu/~keith//tcl-course/topics/processes.html it
does:
"The dup implements the dup system ca
On Fri, May 04, 2007 at 08:12:55PM +0200, Pepe Iborra wrote:
> Mads
>
> On 04/05/2007, at 19:19, Mads Lindstr?m wrote:
>
> >Hi Pepe
> >
> >I would have liked something cross-platform.
> >
>
> Take a look at the unix-compat[1] package by Bjorn Bringert, although
> it looks like it won't help yo
How well is ghc supported on newer versions of Sparc/Intel Solaris?
Thanks, Joel
--
http://wagerlabs.com/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-user
Cristian Perfumo wrote:
Simon: (first of all: thank you for the information. As soon as we have
it working we will try that application in nofib to see what happens)
We already implemented those synchronization functions for ia64
architecture and we have a problem related with base register (fin
I have adopted our sources now so that they also work with fgl-5.4.1.
So neither ghc-6.6.1 nor fgl-5.4.1 need to change.
The problem was that "inn" returns loops since fgl-5.4, that led to more
edges to be processed (by our function selectProofBasis).
Another problem (not relevant for our perfor
Simon: (first of all: thank you for the information. As soon as we have it
working we will try that application in nofib to see what happens)
We already implemented those synchronization functions for ia64 architecture
and we have a problem related with base register (find output below).
The ques
Simon Marlow schrieb:
> Christian Maeder wrote:
>> Dear Hets- and GHC-Developers,
>>
>> we have a problem using ghc-6.6.1. The created hets binary runs a couple
>> of times slower than the one created using ghc-6.6. (see below)
>>
>> What might be the cause for this?
>
> Very strange. The perform
Christian Maeder wrote:
Dear Hets- and GHC-Developers,
we have a problem using ghc-6.6.1. The created hets binary runs a couple
of times slower than the one created using ghc-6.6. (see below)
What might be the cause for this?
Very strange. The performance has decreased dramatically, but the
Cristian Perfumo wrote:
Some days ago I sent an email to the list asking about the reason why I
couldn't run my programs with the "-Nx" RTS option even if I compiled
them with -threaded.
AH! by the way, the architecture is ia64 (Itanium).
Today I realized that when I ./configure, a preprocessor
Hi
> GHC 6.6's installer (MSI) has three Installation Mode, Typical,
> Custom, Complete. These mode doesn't work GHC 6.6's one, but some
> other installer uses these Installation Mode, to suport install
> options.
Custom/complete: yes, typical: no. What on earth does "typical" mean? The
user
shelarcy wrote:
> GHC 6.6's installer (MSI) has three Installation Mode, Typical,
> Custom, Complete. These mode doesn't work GHC 6.6's one, but some
> other installer uses these Installation Mode, to suport install
> options.
Custom/complete: yes, typical: no. What on earth does "typical" mean
So to summarise, the following are missing from the binary distribution that
Neil used as the basis for his installer:
* readline
* ALUT
* OpenAL
* GLUT
* C++ support in the bundled GCC
right? I can try to roll another binary distribution, but I don't know much
about these packages or
Aha! So the problem is a library change rather than a compiler change. That's
a relief.
Simon
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
| Behalf Of Christian Maeder
| Sent: 08 May 2007 22:33
| To: [EMAIL PROTECTED]; GHC Users Mailing List; [EMAIL PROTE
22 matches
Mail list logo
