Andre Pang <[EMAIL PROTECTED]> writes:
> I'm just wondering -- for "primitive" C types (int, float, char, etc),
> why was the decision made in the FFI to have function declarations
> look like e.g.
>
> foreign import ccall "math.h sin" sin :: CDouble -> CDouble
>
> rather than
>
> foreign impo
Axel Simon <[EMAIL PROTECTED]> writes:
> the Haskell compiler GHC replaces the memory allocator in GMP with
> one that allocates from the Haskell heap. Pedro managed to link the
> PPL with a private version of GMP but that is not a feasible
> solution in the long term.
I second this. I would like
"Daniel Müller" <[EMAIL PROTECTED]> writes:
> foreign import ccall calc :: CInt -> CInt -> CInt
>
> calculate :: Int -> Int -> CalcType
> calculate a b
> | ...
> | ...
> | otherwise = calc a b
>
>
> Unfortunately I got an error. What shall I do?
Use fromIntegral to convert between CInt and Int,
W liście z pią, 25-06-2004, godz. 12:30 +0200, Daan Leijen napisał(a):
> It seems to me that returning the old value is always good
> enough right? Here is an implementation of "atomicModifyIORef"
> with the current type in terms of a function "proposedModifyIORef" with
> type (2).
>
> atomicMod
W liście z pią, 16-04-2004, godz. 15:25 +0100, Simon Marlow napisał:
> I wondered about that (while writing my last post) but it still seems
> like a hefty price to pay for the small number of problematic cases we
> have, and given that you can already write the C stubs by hand to get
> the desire
W liście z czw, 15-04-2004, godz. 18:14 -0700, Fergus Henderson napisał:
> When using the "--target asm" option, which tells the Mercury compiler to
> compile directly to assembler, the Mercury compiler will generate some
> C glue code to handle the FFI interfacing pragmas.
Which - in case it's a
W liście z sob, 01-11-2003, godz. 02:16, John Meacham pisze:
> my implementation converts unrepresentable characters to '?'. But
> a case could be made for throwing a CharsetConversion exception of some
> sort or simply eliding invalid characters. I am not sure what is best,
It depends on the app
Dnia czw 28. sierpnia 2003 12:34, Simon Marlow napisał:
> The only right way to do this, it seems, is to generate the tables from
> UnicodeData.txt. However, I'm prepared to live with the current
> solution as long as we document its shortcomings. After all, it does
> the right thing on the majo
Dnia wto 26. sierpnia 2003 02:04, John Meacham napisał:
> my implementation is pretty hairy, but can be improved. it currently
> only works on systems where __STDC_ISO_10646__ is defined, but
> fortunatly, I have never come across a system where it was not defined
> and it implemented wchar_t at a
Dnia pią 25. lipca 2003 16:52, Dean Herington napisał:
> John's first suggested alternative above seems very appealing to me, as it
> seems neatly to fix the fundamental design flaw in `errno`: that
> determining the success/failure of a system call is separated from the call
> itself. I'm surpri
Dnia wto 22. lipca 2003 13:52, Ross Paterson napisał:
> The proposal was to have this in addition to ccall. This convention
> is currently called CALLCONV in the network, GLUT and OpenGL packages,
> with hacks to turn it into ccall or stdcall. I think it makes sense to
> regularize it as stdcall
Dnia nie 13. lipca 2003 21:20, Alastair Reid napisał:
> We dropped Haskell finalizers because neither Hugs nor NHC could implement
> them and implementing them would pretty much require them to implement
> preemptive concurrency (i.e., multiple threads each with their own stacks).
Not necessarily
Dnia wto 10. czerwca 2003 01:00, Ross Paterson napisał:
> I meant to say that you can't pass an HsDouble to a "polymorphic" C
> function expecting (void *),
You can pass a pointer to double.
Imagine a hashtable implemented in C. It will most probably store void *
as values. You can use it for an
Dnia nie 1. czerwca 2003 23:55, Alastair Reid napisał:
> introduces a type T whose only value is bottom.
> ]]
>
> This semantics is obviously flawed though because it would suggest that any
> two values of type T are equal (and equal to bottom) and that optimizations
> based on that equality are
22 Oct 2002 01:32:55 +0100, Alastair Reid <[EMAIL PROTECTED]> pisze:
> -- keepAlive x y ensures that the finalizer for y is not run
> -- until after the finalizer for x has run to completion.
What if I do keepAlive p1 p2 >> keepAlive p2 p1?
They will never be collected?
--
__("< Marc
12 Aug 2002 11:33:41 +0100, Alastair Reid <[EMAIL PROTECTED]> pisze:
> (In the image processing example, images were megabytes and an
> expression like (x + (y * mask)) would generate 2 intermediate images
> (several megabytes) while doing just 2 reductions in Haskell.)
OCaml allows the programm
Wed, 11 Sep 2002 16:42:55 +1000 (EST), Manuel M T Chakravarty <[EMAIL PROTECTED]>
pisze:
> Sure, but there is also
>
> null = (== [])
>
> in the Prelude and `Maybe.isNothing'.
Because they work even if list element type or the type argument of Maybe
isn't Eq. There is no analogous need for
24 Aug 2001 12:20:41 -0600, Alastair David Reid <[EMAIL PROTECTED]> pisze:
> Let's add some asserts to the affected code so that we'll get warnings
> when we try to compile the code on a system that breaks these assumptions.
> Something like this:
>
> #if SIZEOF_INT != SIZEOF_PTR
> #er
Sun, 19 Aug 2001 23:14:59 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> * I am still not convinced that we need
> `Storable.destruct'. For deallocating special purpose
> structures that need a deep traversal, shouldn't we just
> use a custom function?
Without destruct code
On Wed, Jun 13, 2001 at 04:22:16AM +1000, Fergus Henderson wrote:
> - Should `CInt' be guaranteed to have the same representation
> as C's `int', or just the same range of values?
You can't discover the actual representation anyway. What it
guaranteed is that you can write CInt
On Tue, Jun 12, 2001 at 11:00:09AM +0200, Sven Panne wrote:
> > (I still think that the "static" keyword is not necessary.)
>
> How would you import a function named "static" then?
There can't be such a function: it's a keyword in C :-P
And even if it was allowed in C, without any special mean
Sat, 09 Jun 2001 23:25:08 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> The new definition reduces the problem of defining exactly
> which types can be marshalled to a reference to Storable.
Being just Storable is not enough to generate a foreign call. For
example floating point a
01 Jun 2001 13:35:40 -0600, Alastair David Reid <[EMAIL PROTECTED]> pisze:
> Even if rarely used, I think it is easier to teach people to use
> it if we say there are two forms of definition (safe and unsafe,
> static and dynamic, etc.)
But there are not two forms. With the new proposal you impo
Fri, 01 Jun 2001 18:36:01 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> http://www.cse.unsw.edu.au/~chak/haskell/ffi.{ps.gz,tex}
I like it. Minor issues:
- import is not a specialid, it's already a reservedid.
- Safeness should be optional. (And maybe s/safeness/safety/ ?)
- Wou
Tue, 29 May 2001 10:37:54 +0200, Sven Panne <[EMAIL PROTECTED]> pisze:
> Just to restate my position: I'm against *always* wrapping the header file name
> in double quotes, unless
>
>#include "foo/bar.h"
>
> implies
>
>#include
>
> if the first form is not found.
It does, but having
orting:
- call
- curry
- apply
- variants mangled to distinguish from ordinary identifiers
(probably by adding underscores)
- I'm afraid that "mnemonic" symbols like (*)() or $ are too cute to be
clear.
For exporting:
- closure
- new_function
- fun_ptr
- export_fun
--
Marcin '
Sun, 6 May 2001 11:29:18 -0600 (MDT), Alastair Reid <[EMAIL PROTECTED]> pisze:
>> foreign export dynamic is a shortcut for importing an automatically
>> generated nontrivial C function, with argument type not conforming to
>> regular imports, which could not be written by hand.
>
> I don't get
Sorry for lots of small messages.
'label' can be spelled '&'. It's IMHO more intuitive, and reminds
that we get a pointer in Haskell and not the dereferenced value.
foreign import "&stdscr" stdScr :: Ptr Window
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^
Mon, 07 May 2001 00:14:32 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> The import/export information is needed by the name analysis,
> which we better leave independent of the whole extent mess.
Export dynamic introduces a name, export static exports an existing
name. For that re
6 May 2001 15:50:16 GMT, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> pisze:
> Export dynamic introduces a name, export static exports an existing
> name. For that reason putting this distinction in extent seems strange
> for me.
Moreover, export dynamic and import dy
I know that this is a silly argument, but Word is used internally in
RULES for fromIntegral to generate good code for conversions between
sized integers.
Since Word{8,16,32} and sometimes Word64 is represented as data-wrapped
Word#, it's easy to implement many conversions by delegation to the
con
Thu, 03 May 2001 22:34:50 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
> Hmmm, I thought that the Word type itself is a GHC extension, the
> hslibs docs for module Word only talk about the explictly sized
> variants. OTOH the implementation exports Word, but for legacy
> reasons, IIRC.
Rather t
Tue, 17 Apr 2001 18:05:48 +1000, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> http://www.cse.unsw.edu.au/~chak/haskell/ffi.ps.gz
Some minor points:
In C int can't have 8 bits. It is guaranteed to represent at least
-2^15..2^15.
Your syntax puts modifiers between the calling conventi
http://prdownloads.sourceforge.net/qforeign/qforeign-0.65.tar.gz
qforeign-0.65 (Apr 15, 2001)
* Make libraries for GHCi too (HS*.o).
* hsc2hs should work on Windows too (untested).
* Works with nhc98-1.02 too. ghc-4.09 support dropped.
* hsc2hs parser rewritten. #{st
Fri, 6 Apr 2001 09:04:32 -0700, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:
> It seems a bit odd to have static/dynamic *outside* but "new"
> inside the language-specific string. I suppose the justification
> is that 'new' is really a static method with a funny way to call it.
> Whereas the 's
Thu, 5 Apr 2001 07:45:44 -0700 (PDT), Ronald Legere <[EMAIL PROTECTED]> pisze:
> KDirect: Looked at it abit. Pretty sparsely documented. I could not
> figure out how it fits in with the latest tools. How does QForeign
> relate to Foreign? What is an hsc file? Also it is pretty limitted
> in the m
Wed, 28 Mar 2001 12:10:46 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> If most libraries could be ffi'd without the need for additional C files, the
> multiple header file notation would be an obvious win.
>
> As it is, many libraries I've dealt with need one or more .c files containing
>
n.
So they can be provided somewhere else and exported by Foreign as well.
--
Marcin 'Qrczak' Kowalczyk
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Mon, 19 Mar 2001 11:04:43 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> > Should these functions be available through the standard FFI?
> > IMHO they should.
>
> I don't understand the question.
> Are you asking which modules should export them?
Yes. IMHO they should be made as "standard" a
Should these functions be available through the standard FFI?
IMHO they should.
Their functionality on a variety of concrete types can be archieved
by using C, in an ugly and inefficient way. FFI already contains the
level of unsafety they are at.
They are useful, especially in the context of FF
Wed, 14 Mar 2001 10:37:04 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> > Add 'destruct :: Ptr a -> IO ()' method to class Storable. Thanks
> > Wojciech Moczydlowski <[EMAIL PROTECTED]> for the suggestion.
>
> Is this supposed to be a GHC-only extension of the FFI libraries?
>
Mon, 26 Feb 2001 07:07:55 -0800, Simon Peyton-Jones <[EMAIL PROTECTED]> pisze:
> Most notably, Malcolm's latest proposal introduces a new form
> of abstraction (named thing), a bundle of attributes like Gtk or Bzip.
> Another environment for the compiler to manage! Soon people will
> want to expo
Mon, 26 Feb 2001 11:17:07 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> I just remembered that my project (Knit - a C component language)
> has severe problems with use of macros in header files.
With hsc2hs it's easy enough to wrap macros:
foreign import "hs_incRef" unsafe incRef :: Object
Fri, 23 Feb 2001 18:38:20 +, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
pisze:
> foreign_decl ::= 'foreign' what [conid] [attributes] [foreign_name]
>varid '::' prim_type
>| 'foreign' 'library' conid attributes
I like the idea.
Putting
't fit the whole picture of files included at all places in
my head at once.
--
Marcin 'Qrczak' Kowalczyk
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
the header file to include varies depending on the system?
When you have conditional compilation (either via hsc2hs or via cpp),
wrap the proposed 'foreign default include "..."' in appropriate #ifdefs.
--
Marcin 'Qrczak' Kowalczyk
__
Thu, 22 Feb 2001 14:07:04 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> An output file or files which can be used as input to cc/ghc/Hugs/etc.
> (i.e., which doesn't require greencard, c2hs, hsc2hs, etc.) and which
> contains ifdefs to handle any portability issues.
Ah, now I see. hsc2hs cou
Thu, 22 Feb 2001 11:41:20 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> 2) Have any desire to spend half a day installing lots of
>Haskell-related tools (greencard, c2hs, happy, etc.) on their
>machine before they can try out my tool. Getting them to install
>a GHC binary is abou
Thu, 22 Feb 2001 11:27:20 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> In fact, I expect that having dlopen do a search through the
> libraries that it thinks are relevant instead of Hugs performing a
> search through the list of libraries that it knows to be relevant
> probably makes things
Thu, 22 Feb 2001 12:08:22 -, Simon Marlow <[EMAIL PROTECTED]> pisze:
> Don't forget you might need multiple includes, eg. &
> for socket(), and ordering is important.
Easy with my proposal:
foreign import "socket" include "" include ""
socket_c :: CInt -> CInt -> CInt -> IO CInt
incl
ature, calling conventions can also be
specified before the foreign_name, in which case a string following them
is not their argument but the foreign_name.
What I find ugly is that 'dynamic' does not really fit here. It changes
whether the name is created or exported (for foreign export
ch does not use these fields. IMHO each field which
is a list should be allowed to be skipped, defaulting to the empty list.
--
Marcin 'Qrczak' Kowalczyk
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Wed, 21 Feb 2001 15:51:35 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> User defined defaults are really tempting to add (my component
> programming language had them briefly and I am under constant
> pressure to add them back in) but they are kinda messy because:
They are sometimes bessy, b
Wed, 21 Feb 2001 11:41:07 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> The point of me mail was that instead of using half the features
> of cpp (Marcin gave an example which used #ifdef) and extending the
> ffi spec to do the other half, he could use all the features of cpp
> (#ifdef and #d
Wed, 21 Feb 2001 16:01:48 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> So, how about the following.
I must admit that I like my own proposal better :-)
> So, as Marcin pointed out, the only use for a library object
> spec for ccall is so that interpreters know which handle to
>
Tue, 20 Feb 2001 18:54:05 +, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
pisze:
> Since I believe backward compatibility is very important, would
> anyone like to either modify Marcin's proposal, or make a new
> concrete proposal that is perhaps slightly more conservative but
> still achieves our
Mon, 12 Feb 2001 15:49:45 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> 1) Trying to support a complex language like Java in the same design
> (or in any design, really)
Java support has no impact on C support: you can ignore it if you like.
The design as is is quite language-independent (an
Mon, 12 Feb 2001 11:39:12 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> > The ability to specify #include files in a portable way,
>
> Can this not be done with one small extension instead of a much
> larger general purpose extension?
I prefer a not too large but generic feature - to one sm
Mon, 12 Feb 2001 17:27:36 +, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
pisze:
> > We can have some declaration specifying the context of *following*
> > foreign declarations. Another such declaration can change the
> > context later in the module.
>
> Please no!
OK, my current favourite is to
Mon, 12 Feb 2001 09:50:07 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> Note that this can be done without separating the library name from
> the ffi decl:
>
> #ifdef UNIX
> # define LIBNAME "foo.so"
> #else
> # define LIBNAME "foo.dll"
> #endif
>
> foreign import ... LIBNAME ...
> foreign
Nobody answered, so perhaps everybody agrees :-)
Sat, 03 Feb 2001 00:14:56 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> Re (2): In Java, we obviously want to use qualified names
> (like "java.lang.foo"), but in the case of dynamic
> libraries and C calls it is less clear what
Wed, 07 Feb 2001 14:33:01 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> Hmmm, signature-wise, it doesn't seem that easy (without
> introducing too much clutter).
OK, I forgot that throwIf takes the monadic computation as an argument
and nothingIf takes the value.
I still think th
t make much sense anyway, and similarly
translation of errno to something other than throwing IOError.
--
Marcin 'Qrczak' Kowalczyk
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Sun, 04 Feb 2001 17:15:16 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> I am just wondering whether we would want to add the
> following to `MarshalError':
Maybe throwIf should be changed to failIf? The same function would
work for both IO and Maybe.
--
__("< Marcin Kowalczyk
ifetime is not a problem:
withByteArray :: ByteArray -> (Ptr a -> IO b) -> IO b
(And now we know that the ByteArray type should be parametrized!)
This begins looking similarly to ForeignPtr from the outside.
--
Marcin 'Qrczak' Kowalczyk
__
rmch/recu-make-cons-harm.html>).
* Check compiler abilities by compiling or running test programs
instead of relying on its version.
hsc2hs in ghc-4.11 is up to date.
--
Marcin 'Qrczak' Kowalczyk
___
FFI mailing list
[EMAIL PROTECTED]
htt
Tue, 09 Jan 2001 13:59:10 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> I was thinking of having the library itself by default
> provide a set of standard encodings. Like - as you say
> later - we usually rely on a set of standard MIME encodings
> to be available.
If an encoding
ants for Latin1 and let withCStringConv
not call newCStringConv in this case but treat it specially.
(Currently alloca is implemented in terms of malloc so it does not matter
anyway.)
--
Marcin 'Qrczak' Kowalczyk
___
FFI mailing list
[EMAIL PROTECTE
Mon, 8 Jan 2001 17:11:04 +0100 (CET), Marcin 'Qrczak' Kowalczyk
<[EMAIL PROTECTED]> pisze:
> A central database can be built around conversions available as values in
> the program. But it would be a bad idea to take it as the basic
> identification and require regist
osing.
I would not encourage people to skip the conversion and produce code which
works only for ISO-8859-1. Latin1 is just one of many encodings.
Since string handling in Haskell is already inefficient, I hope that
adding conversions would not make a big relative difference. It would
be a differe
Mon, 08 Jan 2001 14:55:31 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> How about having an interface where the String marshalling
> functions take an additional argument
>
> data CConv = NoCConv -- handle as 8bit chars
>| StdCConc
Sun, 07 Jan 2001 12:16:15 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> I think, we need the alloca and realloc versions, too.
We can't have malloc, alloca, realloc or poke. Only peek, with and new.
We can't have poke because in general the space needed for the
converted string i
Sun, 07 Jan 2001 13:15:21 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> > When someone really wants to use mallocCString and pokeCString now
> > (knowing that there is a little point of doing that in the case of
> > conversions), he can use mallocArray0 and pokeArray0, after castin
Sun, 07 Jan 2001 16:16:00 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> BTW, shall we really seperate CString and CStringLen into
> two different modules? I am all for modularisation, but in
> this case I am not sure whether it is worth it.
I would put them in one module, especia
Sat, 06 Jan 2001 00:24:14 +0100, Sven Panne <[EMAIL PROTECTED]>
pisze:
> For performance there's always #ifdef (well, at least if we
> consider piping Haskell sources through cpp as "standard"/H98).
hsc2hs used instead of cpp provides #ifdef too, and avoids lexical
analysis of Haskell source as
Sat, 06 Jan 2001 22:37:35 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> If there were a faster alloca, it would still speed up the
> common case where there is no conversion or the initial size
> estimate is correct.
I'm afraid the common case includes a conversion.
It would inde
Sat, 06 Jan 2001 21:58:26 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> > type CString= Ptr CChar
> > type CStringLen = (CString, Int)
>
> Hmmm, yes, although pointer/length pairs are not very common
> in C and this module is a language dependent module (and so
> shoul
Sat, 06 Jan 2001 02:24:00 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> Actually, given this unicode mess, how are we supposed to
> handle individual `Char's? A Haskell `Char' may expand to a
> sequence of 8bit `char's. That's a problem when the C side
> only expects a `char' and
d be added:
maybeNull :: (Ptr a -> IO b) -> Ptr a -> IO (Maybe b)
maybeNull f ptr
| ptr == nullPtr = return Nothing
| otherwise = liftM Just (f ptr)
Use it as such:
do
maybeString <- maybeNull peekCString ptr
...
--
Marcin 'Qrczak' Kowalczyk
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Thu, 4 Jan 2001 02:59:05 -0800, Simon Marlow <[EMAIL PROTECTED]> pisze:
> Actually I consider the current libraries to be on the verge
> of usability, modulo the missing string marshalling and error
> functionality.
For both subjects I have a proposal in QForeign. I have no doubts
about the stri
Thu, 4 Jan 2001 14:22:52 +, Malcolm Wallace <[EMAIL PROTECTED]> pisze:
> I don't understand - can you explain? Surely the Num instances for
> Word/Int 8/16/32/64 mean that a literal integer 3 in the source code
> becomes (fromInteger 3) in reality, and this should be fine in
> case compariso
guments:
bool :: a -> a -> Bool -> a
-- Or the name cond might be better.
Then the conversion from Bool is: bool 1 0. Or bool 0 1. I'm not sure
which order is better (false true: consistent with maybe and ordering
on Bool, true false: consistent with plain if).
--
Marcin 'Qrczak' Kowalczyk
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Wed, 3 Jan 2001 15:31:43 -0700, Alastair Reid <[EMAIL PROTECTED]> pisze:
> Which is all just my long-winded way of saying I agree with Simon
> that we should not do this. Even if f.e.d. could return nullFunPtr,
> we should not do this because we can express it better using a Maybe.
I retrieve t
Wed, 3 Jan 2001 21:44:03 +1100, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> Personally I'd rather have a single well-designed convenient foreign
> language interface as a standard part of the language, rather than
> having a minimalistic foreign language interface in the language
> standard and
to
C functions may be inlined across Haskell modules. A user module doing
"import Curses" and being compiled with optiimzation and without
appropriate -#include options may cause the C compiler to call function
without prototypes, which is not legal in C99 and does not work for
ar
n't heard of it and gcc does not
provide them).
--
Marcin 'Qrczak' Kowalczyk
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Wed, 3 Jan 2001 21:12:54 +1100, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> Well, if they are left, then at very least they should be
> very clearly documented as being non-portable.
They should, they aren't. Perl internally relies on the fact that
memsetting all bits to 0 produces null pointe
Wed, 03 Jan 2001 12:27:20 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> This means that we should not provide
>
> castFunPtrToPtr :: FunPtr a -> Ptr b
> castPtrToFunPtr :: Ptr a -> FunPtr b
It does not mean that, because existing C libraries are usually
non-portable and s
Tue, 2 Jan 2001 22:28:02 +1100, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> Doing it in a separate tool will lose efficiency in some important
> cases. If the compiler is compiling via C, then it can insert
> inline C code directly in the generated code, and thus get
> inlining. But I think a
C interfaces use them,
and even the ability to cast between data pointers and function pointers
is described as a common non-standard extension in ISO/ANSI C99.
--
Marcin 'Qrczak' Kowalczyk
___
FFI mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/ffi
Tue, 02 Jan 2001 19:40:11 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> PS: It could be argued that `Ptr ()' can always be used
> instead of `Addr' and that therefore we should do away
> with `Addr' altogether. Opinions?
I agree that Addr uses should be replaced by Ptr an
http://download.sourceforge.net/qforeign/qforeign-0.63.tar.gz
(Will be in CVS there soon.)
Changes since 0.62:
* Adapted to MarshalUtils and ForeignPtr introduced in ghc-4.11.
* Works on ghc-4.08 through ghc-4.11 and nhc98-1.00 through nhc98-1.01.
Uses native modules where available, otherwise
Mon, 11 Dec 2000 02:03:27 -0800, Simon Marlow <[EMAIL PROTECTED]> pisze:
> Change to the FFI recently discussed on the mailing list.
> Still to come: error handling utilites.
>
> This is mostly untested.
Thanks. I've been sceptic about ForeignPtr, but now I like it.
In three of qforeig
Wed, 6 Dec 2000 16:35:51 +, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
pisze:
> I *really* *really* want to be able to insert small snippets of
> foreign code into the source of a Haskell module.
You can do it with hsc2hs:
foreign import "hs_PyTuple_Check" unsafe
tupleCheck :: Object -> Boo
Wed, 6 Dec 2000 03:04:25 -0800, Simon Marlow <[EMAIL PROTECTED]> pisze:
> >* s/Marshal/MarshalUtils/
>
> ok, that seems to be the consensus.
Not StorableUtils, to show that it's a set of wrappers and utils
extending basic Storable things?
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] ht
Mon, 04 Dec 2000 17:17:09 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> So far, we have handled similar cases by using the inefficient
> variant as the "default" and adding a RULES pragma to get the
> efficient version. See, for example, the various IntXX to Int casts.
> We can us
Mon, 4 Dec 2000 04:15:28 -0800, Simon Marlow <[EMAIL PROTECTED]> pisze:
> Ok, so the malloc/free is the most expensive part. I'm moderately
> surprised:) Perhaps we could do a better job, but we'll never do
> better than ByteArrays as long as the bracket is required.
BTW, withCString in my imp
the storage for use by alloca could be allocated as a linked list of
large memory blocks. It should still make use of efficient stack-like
allocation within the block.
> because I recon eliminating the exception handler is more important than
> speeding up the actual malloc/free.
Hm
Sat, 02 Dec 2000 13:49:52 +1100, Manuel M. T. Chakravarty <[EMAIL PROTECTED]> pisze:
> And because the greatest fun of all is to argue about names,
> I propose to rename `throwIf_EINTR', `throwIfNull_EINTR',
> and `throwIfMinus1_EINTR' to `throwIfEINTR',
> `throwIfNullEINTR', and `throwIfMinus1EI
Sat, 2 Dec 2000 13:13:08 +1100, Fergus Henderson <[EMAIL PROTECTED]> pisze:
> > 1. Is it possible to have the second kind from the level of the
> >Haskell compiler at all (done in an sufficiently elegant way to
> >think about it as a candidate proposal for the official FFI)?
>
> I think
1 - 100 of 139 matches
Mail list logo
