July 2003 - FFI - Haskell.org

Example: Binding C++ to Haskell using the ffi
by David Sankel 13 Dec '03

13 Dec '03

Sorry, forgot attachment . . . again. :-P -- Here is some example code doing just that. It uses ghc. Questions: Can one think of better ways to interface generic c++ libraries to Haskell? What do you think of the ->> member function operator? for the ffi people: Has any though gone into cplusplus? If so, how would it interface? Would stubs on the c++ side be generated or would it use the code directly. Later, David J. Sankel

2 1

The Errno Story
by Wolfgang Thaller 28 Jul '03

28 Jul '03

First, the "bug" part: None of the libraries that use errno are compatible with concurrency. When a (lightweight) thread-switch occurs between the call to some foreign function and the corresponding call to Foreign.C.Error.getErrno, we have a problem: a) the RTS trashes the value of errno b) another Haskell thread might call a function that sets errno c) on most platforms, errno is thread-local state, with all the consequences that has for the threaded RTS (bound threads required....) Now, the "ffi" part: b) and c) could be solved by using bound threads, but that's probably too inefficient for something that's used as frequently as errno. Bound threads wouldn't solve a). I therefore propose that we make the RTS save & restore the value of errno in the TSO, thus making errno "Haskell-Thread-Local-State", and solving all of the above problems. I also propose adding a note to the FFI spec (or the bound threads document, I'm not sure which is the right place) that says that implementations have to make sure that "Errno" is local to each *Haskell* thread. Cheers, Wolfgang

7 6

Interested?
by jc123＠hotmail.com 28 Jul '03

28 Jul '03

WANTED: We're looking for motivated, entreprenurial people who would like to be their own boss and earn an executive 6-figure income this year. Would you enjoy earning $1,000 commissions starting this month? (And market a product with a value of over $15,000). - This is a legitimate business that you can run from your home - You make $1,000 profit for every sale - Market a high-demand travel related product - Total support given at all times - Excellent income is possible starting immediately This is not like other businesses that drain your savings and don't work... - Not MLM or networkmarketing - No hard ball selling - No need to approach friends or family - No inventory to buy We have a simple, turn-key system for you to plug into. We have our own leads for you to work, and a great personalized website which we provide for you. Our support team is unparalleled and you can start earning $1,000 per sale right away. If you're success-minded and enjoy a challenge then this could be just the opportunity you've been looking for. Interested? For free and immediate info, send your name and phone # to the email address below: mailto:travelbiz15@hotmail.com To recieve no more mailings, simply send a blank email to the address below: mailto:trvlbiz11@hotmail.com

1 0

RE: The Errno Story
by Simon Marlow 25 Jul '03

25 Jul '03

John Meacham writes: > I am not a fan of having to stow errno for every ffi call.. As was pointed out to me last time this came up, you don't have to stow it for every FFI call, only on a context switch. Adding one word to a TSO is also very cheap. The total cost is almost certainly unmeasurable. Cheers, Simon

2 1

RE: The Errno Story
by Simon Marlow 25 Jul '03

25 Jul '03

> I therefore propose that we make the RTS save & restore the value of > errno in the TSO, thus making errno "Haskell-Thread-Local-State", and > solving all of the above problems. Actually this has been on my ToDo list for a long time, I just never got around to doing it (it has been mentioned on the FFI list before, IIRC). > I also propose adding a note to the FFI spec (or the bound threads > document, I'm not sure which is the right place) that says that > implementations have to make sure that "Errno" is local to each > *Haskell* thread. Not the FFI spec - it assumes a single-threaded Haskell implementation. The right place is the bound threads doc, and eventually the Concurrent Haskell addendum. Cheers, Simon

1 0

ENQUIRY
by MR. DAVID LARSON 25 Jul '03

25 Jul '03

FROM: MR. DAVID LARSON ANTHONY EZE & CO. SIR, SUBJECT: TRUST NEED YOUR KIND RESPONSE TO THE FOLLOWING REQUEST: I HAVE A MANDATE TO SOURCE FOR A FINANCIAL MANAGEMENT PERSONNEL ASIDE AFRICA, BE IT YOUR PROFFESSION OR NOT, ITS NATURE DOES NOT COUNT, BUT ONLY HONESTY IS NEEDED AT ITS PEAK AND WANTED AS MOST PRIORTY TO ACTUALIZE THIS EXPECTED GOAL. HAS CLOSE LINK WITH THE PERSONNELS IN THE CORRIDORS OF POWER IN MY COUNTRY HAS BEEN DELEGATED TO SOURCE FOR A COMPETENT ASSOCIATE OUTSIDE AFRICA IF YOU ARE WORTHY OF BEEN TRUSTED WITH HUGE CAPITAL FOR ESTABLISHMENT IN YOUR COUNTRY CONTACT ME FOR FULL PERSONAL SECRETIVE INFORMATION OR DETIALS FOR COMMENCEMENT AND TERMS OF REWARD FOR YOUR EXPERTED INTEREST AND CONTRIBUTION. THE VOLUME OF CAPITAL WILL BE DISCLOSED TO YOU ON MY RECEIPT OF YOUR RETURN CORRESPONDENCE INDICATING YOUR WILLINGNESS TO PER-TAKE. KINDLY RESPOND TO THIS MAIL INCLUDING YOUR PERSONAL CONTACT DATA'S FOR FULL DISCLOSURE OF PROCEEDURES. JUST WAITING FOR YOUR REVERT THANKS MR. DAVID LARSON

1 0

stdcall
by Ross Paterson 24 Jul '03

24 Jul '03

Could the meaning of stdcall be broadened to "the standard calling convention for libraries on the native system", i.e. pascal on Win32 (as now) and ccall on Unix? It would save a lot of fuss for interfaces to portable libraries.

3 2

RE: stdcall
by Simon Marlow 23 Jul '03

23 Jul '03

> On Saturday 19 July 2003 12:51 am, Ross Paterson wrote: > > Could the meaning of stdcall be broadened to "the standard calling > > convention for libraries on the native system", i.e. pascal on Win32 > > (as now) and ccall on Unix? It would save a lot of fuss > for interfaces > > to portable libraries. > > If I understand you correctly: > > 1) Even on Win32, a function defined with type: > > rty foo(argtys) > > should be called using stdcall. I don't think that's true. The default calling convention on Windows is still ccall (known as __cdecl to the C compiler), it's just that cross-DLL calls are normally done using the __stdcall calling convention. On Windows, functions in the C runtime are called using the __cdecl calling convention. I just tested this by checking the assembly generated for calling malloc(). Although __stdcall is used more often than __cdecl for library calls on Windows, it doesn't seem to be used exclusively (someone correct me if I'm wrong). So I'd say that specifying a "default" calling convention which maps to stdcall on Windows and ccall on Unix is probably a bad idea. You've just got to know which one to use on Windows - this is the job for a tool which checks the FFI decls against the prototypes. Cheers, Simon

5 5

PARCELAS PUNTA DE CHOROS O $2.000.000 SOLO JULIO Consulte Facilidades
by Tu Tierra 19 Jul '03

19 Jul '03

OFERTA DE INVIERNO PARCELAS PUNTA DE CHOROS CHILE VALOR PARCELA $2.000.000 CHILE CHILE A solo 120 km al norte de La Serena Parcelas de 5075 m2 Fono 09-7979918 -51-311479 Un Entorno Privilegiado de Flora y Fauna A Minutos de la Caleta de Punta de Choros Escritura Inmediata www.tutierra.cl A 2500 Metros de la Playa Grande www.tutierra.cl PROMOCIÓN VENTA DE INVIERNO VALOR PARCELA $2.000.000 USTED DEFINE EL PIE DIFERENCIA 15 CHEQUES TOME SU CUPO OFERTA HASTA EL 31 DE JULIO FORMULARIO DE CONSULTAS AL CONSULTAR RECIBIRÁ TODA LA INFORMACIÓN DEL LOTEO, FOTOGRAFÍAS ANTECEDENTES LEGALES, EMPLAZAMIENTO, UBICACIÓN Y ANTECEDENTES GENERALES PARCELAS DE AGRADO PUNTA DE CHOROS WWW.TUTIERRA.CL VENTA(a)TUTIERRA.CL 09-7979918 SI NO DESEA RECIBIR MAS INFORMACIÓN COMUNIQUESE A ESTE MAIL no deseo recibir mas información (Nota: la legislación chilena no contempla el envío de publicidad por correo electrónico. Respetamos la normativa internacional que establece que ningún e-mail puede considerarse SPAM si se le estipula a las personas instrucciones precisas de como removerse de esta lista

1 0

More Finaliser Trouble
by Ashley Yakeley 16 Jul '03

16 Jul '03

How do I pass a parameter to a finaliser? The pointer itself does not have enough information to run the finaliser, I need an extra parameter available at the time the pointer is created. This was easy to do when I could write finalisers in Haskell, of course, since I could just apply the parameter to my finaliser function to get a finaliser that had the correct type. This is what it looked like: foreign import ccall "JVMBridge.h JVMBridge_DeleteGlobalRefGC" rawDeleteGlobalRefGC :: JavaVM -> RawGlobalRef -> IO (); vm <- rawGetJavaVM ?jvmenv; gref <- newForeignPtr rgref (rawDeleteGlobalRefGC vm (MkRawGlobalRef rgref)); return (MkVMRef gref); But with the new FFI I can't do this so easily. How would I pass the 'vm' parameter to a finaliser which is only allowed to look at the 'rgref' pointer? -- Ashley Yakeley, Seattle WA

6 9