Dominik Oesterreich | 2 Aug 17:21 2004
Picon

FFI, Ghc and Libs

Hello,
 
i have one Problem with ghc (and FFI).
 
I wrote some functions in C and compiled that file. After that I typed:
 
 
ghci -fffi komplett.obj test.lhs -l apr.lib
 
and got the following error meassage:

Loading package base ... linking ... done
Warning: ignoring unrecognised input 'apr.lib'
Loading object (static) kompett.obj ... done
Loading object (dynamic) ... failed.
Dynamic Linker error message was:
    addDLL: unknown error
Whilst trying to load (dynamic)
Directories to search are:
    C:\ghc\ghc-6.2.1\bin
ghc.exe: user specified .o/.so/.DLL could not be loaded
 
 
 
I have to use different Libraries from Subversion (subversion.tigris.org => http://subversion.tigris.org/files/documents/15/14892/svn-win32-1.0.6_dev.zip).
 
Dominik
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Hal Daume III | 4 Aug 02:53 2004
Picon

Double -> CDouble, realToFrac doesn't work

I need to convert a Double to a CDouble to pass to a C function.

In the past, when I've asked how to do this, I'm told: realToFrac. This
works in most cases, but recently gave me a problem that took me *forever* 
to track down:

Prelude Foreign.C> (0 :: CDouble) / 0
NaN
Prelude Foreign.C> (0 :: Double) / 0
NaN
Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble
-Infinity

yikes!  the NaN got turned into a -Infinity!!!

aside from manually checking for 'strange' Double/CDouble values and 
wrapping realToFrac, is there a better way?  also, does this count as a 
bug?

--

-- 
 Hal Daume III                                   | hdaume <at> isi.edu
 "Arrest this man, he talks in maths."           | www.isi.edu/~hdaume
David Roundy | 4 Aug 12:02 2004

Re: hPutBuf synchronous?

On Tue, Jul 27, 2004 at 02:36:39PM +0100, Simon Marlow wrote:
> hGetBuf is synchronous; the system will not write to the buffer after
> hGetBuf returns.  hPutBuf is also synchronous, in the sense that the
> data to be written is copied out of the buffer passed in, and either
> written right away or placed in the Handle's buffer ready to be written
> at a later time.
> 
> So I don't think your hypothetical scenario is happening, sounds like it
> must be something else.
> 
> There has been one GC bug found since 6.2.1, which could perhaps be the
> cause.  Try getting your user to compile up an RTS from the latest CVS
> sources of the 6.2 branch and see if that helps.

I just got a report that the CVS version of 6.2.1 doesn't show the error!
:)
--

-- 
David Roundy
http://www.abridgegame.org
Krasimir Angelov | 7 Aug 13:20 2004
Picon

getDirectoryContents fails under Windows

    The getDirectoryContents function from CVS sources
fails under Windows. It seems like in the
__hscore_end_of_dir function from HsBase.h should
return 0 under Windows and ENOENT under other
platforms.

Cheers,
  Krasimir

		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
Remi Turk | 8 Aug 14:52 2004
Picon
Picon

GHCI/FFI/GMP/Me madness

[second attempt, this time from my bulk mailinglist address
 instead of the normal one.]

Hi all,

I recently tried to create a ffi-binding to gmp in ghc, and
failed miserably. After a few days of debugging, simplifying the
code and tearing my hear out, I'm slightly completely stumped,
and crying for help ;)

In short: calling gmp-functions from GHCI *with a prompt between*
them seems to do Really Bad Things. (read: memory corruption)

The long story:
---------------

mpz_t p;

str_test()
{
	gmp_printf("%Zd\n", p);
}

void mpz_new()
{
	mpz_init_set_si(p, 1);
}

foreign import ccall mpz_new    :: IO ()
foreign import ccall str_test   :: IO ()

Prelude Main> mpz_new
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
142833060
Prelude Main> str_test
142833060

Using other flags, importing extra modules, using CVS 6.3 (a few
weeks old) or not compiling it before loading it in GHCI slightly
changes the symptoms (other wrong numbers or make it happen
later/earlier) but copypasting the code from main some 10 to 20
times seems to be a sure way to reproduce it.

Simply running main doesn't seem to expose the problem.
Now of course, GHCI uses Integer-ops during it's REPL, which I
suspect is exactly what causes/exposes the problem.

Am I doing (Un)Officially Forbidden Things? Is it time for a
bug-report? Do I finally have to learn drinking coffee? ;)
I'd be delighted to know.

The full code is attached.

TIA,
Remi

-- 
Nobody can be exactly like me. Even I have trouble doing it.
.PHONY: clean ghci

CC=gcc
CFLAGS=-Wall -g
GHCFLAGS=util.o -\#include util.h

main_src=PrimMpz.hs

ghci: util.o
	ghci $(GHCFLAGS) $(main_src)

exe: util.o
	ghc --make $(GHCFLAGS) $(main_src)

util.o: util.c
	$(CC) $(CFLAGS) -c $<

clean:
	rm -f a.out *.o *.hi
{-# OPTIONS -fffi #-}
module Main where

foreign import ccall mpz_new    :: IO ()
foreign import ccall str_test   :: IO ()

main= do
    mpz_new
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
#include <stdio.h>

#include "util.h"

mpz_t p;

void str_test()
{
	gmp_printf("%Zd\n", p);
}

void mpz_new()
{
	mpz_init_set_si(p, 1);
}
#ifndef _UTIL_H
#define _UTIL_H

#include <gmp.h>

void str_test();
void mpz_new();

#endif /* _UTIL_H */
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Sigbjorn Finne | 8 Aug 16:34 2004

Re: GHCI/FFI/GMP/Me madness

Hi,

please be aware that the RTS uses GMP as well, and upon
initialisation it sets GMP's 'memory functions' to allocate memory
from the RTS' heap. So, in the code below, the global variable
'p' will end up having components pointing into the heap.
Which is fine, until a GC occurs and the pointed-to
GMP allocated value is eventually stomped on by the storage
manager for some other purpose.

I'm _guessing_ that's the reason for the behaviour you're seeing.

--sigbjorn

----- Original Message ----- 
From: "Remi Turk" <buran <at> xs4all.nl>
To: <glasgow-haskell-users <at> haskell.org>
Sent: Sunday, August 08, 2004 05:52
Subject: GHCI/FFI/GMP/Me madness

> [second attempt, this time from my bulk mailinglist address
>  instead of the normal one.]
>
> Hi all,
>
> I recently tried to create a ffi-binding to gmp in ghc, and
> failed miserably. After a few days of debugging, simplifying the
> code and tearing my hear out, I'm slightly completely stumped,
> and crying for help ;)
>
> In short: calling gmp-functions from GHCI *with a prompt between*
> them seems to do Really Bad Things. (read: memory corruption)
>
>
> The long story:
> ---------------
>
> mpz_t p;
>
> str_test()
> {
> gmp_printf("%Zd\n", p);
> }
>
> void mpz_new()
> {
> mpz_init_set_si(p, 1);
> }
>
> foreign import ccall mpz_new    :: IO ()
> foreign import ccall str_test   :: IO ()
>
>
> Prelude Main> mpz_new
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 1
> Prelude Main> str_test
> 142833060
> Prelude Main> str_test
> 142833060
>
>
> Using other flags, importing extra modules, using CVS 6.3 (a few
> weeks old) or not compiling it before loading it in GHCI slightly
> changes the symptoms (other wrong numbers or make it happen
> later/earlier) but copypasting the code from main some 10 to 20
> times seems to be a sure way to reproduce it.
>
> Simply running main doesn't seem to expose the problem.
> Now of course, GHCI uses Integer-ops during it's REPL, which I
> suspect is exactly what causes/exposes the problem.
>
> Am I doing (Un)Officially Forbidden Things? Is it time for a
> bug-report? Do I finally have to learn drinking coffee? ;)
> I'd be delighted to know.
>
> The full code is attached.
>
> TIA,
> Remi
>
> -- 
> Nobody can be exactly like me. Even I have trouble doing it.
>

----------------------------------------------------------------------------
----

> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users <at> haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
Sven Panne | 8 Aug 18:02 2004
Picon

Re: Double -> CDouble, realToFrac doesn't work

Hal Daume III wrote:
> [...]
> Prelude Foreign.C> (0 :: CDouble) / 0
> NaN
> Prelude Foreign.C> (0 :: Double) / 0
> NaN
> Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble
> -Infinity
> 
> yikes!  the NaN got turned into a -Infinity!!!
> 
> aside from manually checking for 'strange' Double/CDouble values and 
> wrapping realToFrac, is there a better way?  also, does this count as a 
> bug?

Hmmm, this is a little bit of a dark corner in the H98 report, but there are
probably other people on this list who know better than me. :-] The problem
is that 'realToFrac' is defined as 'fromRational . toRational', so the first
question is: How is 'toRational' supposed to handle NaN? One thing coming to
my mind is '0 :% 0', but this is normally a value which can't be constructed.
So the next question is: Would this be allowed? +Infinity and -Infinity could
be represented similarly then ('1 :% 0' and '(-1) :% 0'), and 'fromRational'
could handle these values specially. But I can't believe that this has been
discussed for the first time. SPJ? Malcolm?

When you compile the stuff above with optimizations on, you get what you've
expected, thanks to RULES which shortcut the route via Rational completely.

Cheers,
    S.
Simon Peyton-Jones | 9 Aug 13:51 2004
Picon

RE: Double -> CDouble, realToFrac doesn't work

| Hmmm, this is a little bit of a dark corner in the H98 report, but
there are
| probably other people on this list who know better than me. :-] The
problem
| is that 'realToFrac' is defined as 'fromRational . toRational', so the
first
| question is: How is 'toRational' supposed to handle NaN? One thing
coming to
| my mind is '0 :% 0', but this is normally a value which can't be
constructed.
| So the next question is: Would this be allowed? +Infinity and
-Infinity could
| be represented similarly then ('1 :% 0' and '(-1) :% 0'), and
'fromRational'
| could handle these values specially. But I can't believe that this has
been
| discussed for the first time. SPJ? Malcolm?

I don't recall a discussion about this, and a quick search in my mail
archive didn't turn up anything except the enclosed from George Russell.

I'm pretty ignorant about the dark corners of numerics, but it does seem
bad that passing through Rational loses information.  Perhaps the Report
should specify normalised representations for +Inf, -Inf and NaN as
Rationals (1:%0, -1:%0, and 0:%0 seem like plausible candidates).  

If someone wants to try this out, and send us a patch for the Rational
library, we could incorporate it.  And so far as the report goes,
perhaps the Errata could contain a note identifying the issue, and
suggesting a solution.  It's a bit late to *specify* a solution unless
we are really sure about it.

Simon

-----Original Message-----
From: George Russell [mailto:ger <at> informatik.uni-bremen.de] 
Sent: 25 February 2000 10:19
To: glasgow-haskell-users <at> haskell.org
Subject: Floating-point nitpicking: floor(Inf) and floor(NaN)

floor(Inf) and floor(NaN) do not appear to be defined in Standard
Haskell.
(They both come down to "properFraction" which is only defined for
Ratio.)
This differs from (for example) the Standard ML Basis Library, where it
is specified that floor(Int) should raise Overflow and floor(NaN) should
raise Domain.  Hence Hugs and GHC do different things.

Hugs returns floor(Inf) = 0 and floor(NaN) = 0
GHC returns floor(Inf) = very very large integer and floor(NaN) = even
larger
integer.  (This is because the GHC implementation of properFraction
simply
ignores the case of Inf/NaN and treats the artificially high exponent
encoded
in those floating-point numbers as if it were a real one.)

My own opinion is that Standard ML is right here and that floor(x)
should
raise an exception (In Haskell terms, fail) when x does not correspond
to a 
real number.

| -----Original Message-----
| From: glasgow-haskell-users-bounces <at> haskell.org
[mailto:glasgow-haskell-users-
| bounces <at> haskell.org] On Behalf Of Sven Panne
| Sent: 08 August 2004 17:02
| To: Hal Daume III
| Cc: GHC Users Mailing List; Malcom Wallace
| Subject: Re: Double -> CDouble, realToFrac doesn't work
| 
| Hal Daume III wrote:
| > [...]
| > Prelude Foreign.C> (0 :: CDouble) / 0
| > NaN
| > Prelude Foreign.C> (0 :: Double) / 0
| > NaN
| > Prelude Foreign.C> realToFrac ((0 :: Double) / 0) :: CDouble
| > -Infinity
| >
| > yikes!  the NaN got turned into a -Infinity!!!
| >
| > aside from manually checking for 'strange' Double/CDouble values and
| > wrapping realToFrac, is there a better way?  also, does this count
as a
| > bug?
| 
| Hmmm, this is a little bit of a dark corner in the H98 report, but
there are
| probably other people on this list who know better than me. :-] The
problem
| is that 'realToFrac' is defined as 'fromRational . toRational', so the
first
| question is: How is 'toRational' supposed to handle NaN? One thing
coming to
| my mind is '0 :% 0', but this is normally a value which can't be
constructed.
| So the next question is: Would this be allowed? +Infinity and
-Infinity could
| be represented similarly then ('1 :% 0' and '(-1) :% 0'), and
'fromRational'
| could handle these values specially. But I can't believe that this has
been
| discussed for the first time. SPJ? Malcolm?
| 
| When you compile the stuff above with optimizations on, you get what
you've
| expected, thanks to RULES which shortcut the route via Rational
completely.
| 
| Cheers,
|     S.
| 
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users <at> haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Remi Turk | 5 Aug 15:17 2004
Picon
Picon

GHCI/FFI/GMP/Me madness

Hi all,

I recently tried to create a ffi-binding to gmp in ghc, and
failed miserably. After a few days of debugging, simplifying the
code and tearing my hear out, I'm slightly completely stumped,
and crying for help ;)

In short: calling gmp-functions from GHCI *with a prompt between*
them seems to do Really Bad Things. (read: memory corruption)

The long story:
---------------

mpz_t p;

str_test()
{
	gmp_printf("%Zd\n", p);
}

void mpz_new()
{
	mpz_init_set_si(p, 1);
}

foreign import ccall mpz_new    :: IO ()
foreign import ccall str_test   :: IO ()

Prelude Main> mpz_new
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
1
Prelude Main> str_test
142833060
Prelude Main> str_test
142833060

Using other flags, importing extra modules, using CVS 6.3 (a few
weeks old) or not compiling it before loading it in GHCI slightly
changes the symptoms (other wrong numbers or make it happen
later/earlier) but copypasting the code from main some 10 to 20
times seems to be a sure way to reproduce it.

Simply running main doesn't seem to expose the problem.
Now of course, GHCI uses Integer-ops during it's REPL, which I
suspect is exactly what causes/exposes the problem.

Am I doing (Un)Officially Forbidden Things? Is it time for a
bug-report? Do I finally have to learn drinking coffee? ;)
I'd be delighted to know.

The full code is attached.

TIA,
Remi

-- 
Nobody can be exactly like me. Even I have trouble doing it.
.PHONY: clean ghci

CC=gcc
CFLAGS=-Wall -g
GHCFLAGS=util.o -\#include util.h

main_src=PrimMpz.hs

ghci: util.o
	ghci $(GHCFLAGS) $(main_src)

exe: util.o
	ghc --make $(GHCFLAGS) $(main_src)

util.o: util.c
	$(CC) $(CFLAGS) -c $<

clean:
	rm -f a.out *.o *.hi
{-# OPTIONS -fffi #-}
module Main where

foreign import ccall mpz_new    :: IO ()
foreign import ccall str_test   :: IO ()

main= do
    mpz_new
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
    str_test
#include <stdio.h>

#include "util.h"

mpz_t p;

void str_test()
{
	gmp_printf("%Zd\n", p);
}

void mpz_new()
{
	mpz_init_set_si(p, 1);
}
#ifndef _UTIL_H
#define _UTIL_H

#include <gmp.h>

void str_test();
void mpz_new();

#endif /* _UTIL_H */
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Marlow | 9 Aug 14:17 2004
Picon

RE: ghci: catching up with hugs?-)

On 29 July 2004 17:48, Claus Reinke wrote:

> - especially when working with gui libs, I often find myself wanting
>     to know which instances some type belongs to (as that determines
>     the attributes/properties/etc one may use with that type).

Absolutely.  This is on my ToDo list, but I haven't got around to it
yet.  

> - since ghc now keeps better source location info, how about ":find
> <name>"? 

Yes, another good suggestion.  I don't have the time to tackle these
right now, but they're good small projects for anyone looking for
something to contribute to GHC.

> - the ":set <something>" command in ghci "feeds" the ghc command
>     line, but how can I figure out the current settings (especially
>     paths and packages)? 

This is really a bug - and it's another thing that's been lurking on my
ToDo list for a long time.

Cheers,
	Simon

Gmane