April 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

haskell.cs.yale.edu
by CoolStats Reseller 30 Apr '03

30 Apr '03

BECOME A COOLSTATS RESELLER TODAY! Hi, Are you earning enough revenue from your web space and web traffic? Have you thought about reselling other companies' products from haskell.cs.yale.edu I would like to offer you the opportunity to resell our popular CoolStats website tracking and analysis service to your own site visitors. -------------------------------------------------------------------------- RESELLER BENEFITS! -------------------------------------------------------------------------- 1. Offer CoolStats to your site visitors - directly from your own site. To learn more, click at http://www.coolstats.com! 2. Earn $10 commission EVERY TIME you refer a sale to CoolStats. 3. Track your sales through an online Reseller Account Manager. 4. Receive monthly commission payment for the sale you refer. 5. Attractive monthly performance incentives. For more info, click at http://www.coolstats.com/reseller/benefits.html 6. 24/7 dedicated toll-free customer support. 7. It is FREE to Join. Click at http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000022088.2245.11.1xxdaY2IFC0OFr to Sign Up now! Sign up today to exploit this great revenue generating opportunity. We look forward to working together with you! Best regards CoolStats Reseller Support Team Email:reseller@coolstats.com Http://www.coolstats.com Not interested in becoming a CoolStats Reseller? To be taken off our mailing list, please follow the instructions here: http://p1j2m3a4.pdhost.com/pdsvr/www/r?1000022088.2245.1.0+LaKeLS+QaD5k

1 0

RE: New Bound Threads Proposal
by Simon Marlow 28 Apr '03

28 Apr '03

> > Hmmm - what about the following situation: > > > > - Haskell thread A is bound to native thread N > > - Haskell thread A makes an FFI call > > - the FFI call invokes a foreign export, creating Haskell thread B > > - Haskell thread B calls threadbound() > > > > at this point A & B are both bound to the same native thread, right? > > No. In the formal semantics, Haskell thread A ceases to exist at the > moment it makes an FFI call. > This is an area where we always had many misunderstandings. > In the GHC > runtime, yes, A & B would > both be bound to the same native thread, but A would be > "BlockedOnCCall". Other people might also > consider A and B to be the same thread. Urk. Ok, I can see the logic in treating A & B as the same thread. The semantics doesn't model the identity of Haskell threads, so it's difficult to say what we mean by "the same thread" anyway. Note that in practice you can actually observe whether A & B are the same Haskell thread or not, using myThreadId, so if the semantics were to model myThreadId it would have to explicitly allow A & B to have the same ThreadId. I'm not saying we should do this, just that it's something to bear in mind. Cheers, Simon

1 0

RE: New Bound Threads Proposal
by Simon Marlow 28 Apr '03

28 Apr '03

> > If true, that gives us the > > important principle that > > > > At any one time, there is at most one runnable Haskell thread > > associated with, or bound to, any given native thread. > > Exactly. I'll make sure it's mentioned somewhere. > (Also, a Haskell thread cannot be bound to a native thread > that already has a different Haskell thread associated with it). Hmmm - what about the following situation: - Haskell thread A is bound to native thread N - Haskell thread A makes an FFI call - the FFI call invokes a foreign export, creating Haskell thread B - Haskell thread B calls threadbound() at this point A & B are both bound to the same native thread, right? But only B is runnable (which is why I said only one *runnable* Haskell thread may be bound to any given native thread, but I see you removed that word when you added the statement to the document). Cheers, Simon

2 1

Arkadasa yardimci olalim
by Dr. Ahmet Yalcin 27 Apr '03

27 Apr '03

Arkadaslar, lütfen dikkate alin, yardimci olalim: Merhaba, cok zor durumda ve baska caresi kalmamis biri olarak hosgörünüze ve insan sevginize siginarak sizden bana cok kisada olsa kulak vermenizi rica edecegim. Ben, 34 yasinda evli ve 4 yasinda olan bir cocuk babasiyim. Aile hayatimizin sorunsuz ve mutlu sekilde devam ederken biricik oglumuz aniden rahatsizlandi. Uzun süren arastirmalar sonucu oglumuz Ali Can'in kalbinde hayati bir fonksiyon bozuklugunun bulundugu doktorlar tarafindan tespit edildi. Oglumuz cok acil sekilde ameliyat olmazsa maalesef hayata gözlerini yumacak. Ancak ne varki ameliyat icin gerekli olan parayi ödememiz bizim icin mümkün gözükmüyor. Bu nedenle uzun ugraslar sonucu iki önemli Internet sirketi ile yaptigimiz görüsme sonucu, bize her mailde gönderecegimiz link'in tiklanmasi durumunda cocugumuzun ameliyat masraflarina 10 Cent (= 0,10 Euro) katkida bulunacaklari yönünde anlasmaya varabildik. Bu dogrultuda sizden rica edecegimiz, sizi sözkonusu sirketlerin sayfalarina yönelten bu linki tiklamaniz. Bu linki tiklayarak sizinde ameliyat masraflarini karsilamamizda katkiniz olabilir. Sizden bu zor durumumuzda istedigimiz sadece bir tik. >> TIKLAYINIZ --> http://partners.webmasterplan.com/click.asp?ref=160073&site=2514&type=text&… Bunun yaninda bu emaili tüm tanidiklariniza gönderirseniz bize son derece yardimci olursunuz. Ne kadar kisi linki tiklarsa, gerekli olan ameliyat masrafini yakalayabilmemiz o kadar olasi olur. Hos görünüz icin tesekkür eder, saygilarimi sunarim. Mehmet Can Yakupoglu.

1 0

Re: Handling Errors (continued)
by Gustavo Villavicencio 26 Apr '03

26 Apr '03

Before nothing, thanks Axel and Alastair. Following your suggestions i have constructed another two solutions: 1- getMem s = catch (do m <- newCString s return m) (\_ -> return nullPtr) -- the exception handler could be more elaborated. 2- fpred p | p == nullPtr = True | otherwise = False getMem s = throwIf (fpred) (\nullPtr -> "memory out") (do m <- newCString s return m) in both cases main = getMem s1 >>= \p1 -> getMem s2 >>= \p2 -> let p3 = hstrL p2 p1 in peekCString p3 >>= \s -> print s Which of the three solutions, including those of Alastair, would be better?. Can one fail and other one not in some situation?. Thanks again for your help, gustavo

2 1

RE: New Bound Threads Proposal
by Simon Marlow 26 Apr '03

26 Apr '03

> Yesterday evening I was experimenting with an electronic circuit, and > the fumes from the soldering must have entered my brain and triggered > something there - I've thought up a new proposal, which I like much > better than the old one. > It no longer requires extending the FFI syntax; instead, it uses just > one new combinator. > It can be implemented as efficiently as the previous proposal. > The proposal is described in detail in the new "Part II" of the > haskell-report/ffi/threads.tex document (in CVS). > For everyone's convenience, I've put up a typesetted version again at: > > http://www.uni-graz.at/imawww/haskell/threads.pdf > > Everyone please tell me what you think. I've not had the benefit of soldering fumes, but I find whiteboard markers work quite well ;-) I think I like it. Just to clarify: when you fork a new Haskell thread, it isn't associated with a native thread, right? (the semantics doesn't model forkIO, I think it probably should). If true, that gives us the important principle that At any one time, there is at most one runnable Haskell thread associated with, or bound to, any given native thread. which is important for reducing the complexity of the implementation. In an implementation which actually runs the Haskell thread in its bound native thread (eg. GHC), we can be sure that when we want to switch to the bound native thread it isn't off doing something else. Is that the reason for wanting this property? Cheers, Simon

3 3

Handling Errors
by Gustavo Villavicencio 25 Apr '03

25 Apr '03

Hi all, Suppose the next fragment main = newCString s1 >>= \p1 -> newCString s2 >>= \p2 -> let p3 = hstrL p2 p1 in peekCString p3 >>= \s -> print s where hstrL is a C function. The question is, if newCString fails to get allocation to s1 or s2, how must i handle this error?. Thanks for any help. gustavo

4 3

New Bound Threads Proposal
by Wolfgang Thaller 25 Apr '03

25 Apr '03

Hi All, Yesterday evening I was experimenting with an electronic circuit, and the fumes from the soldering must have entered my brain and triggered something there - I've thought up a new proposal, which I like much better than the old one. It no longer requires extending the FFI syntax; instead, it uses just one new combinator. It can be implemented as efficiently as the previous proposal. The proposal is described in detail in the new "Part II" of the haskell-report/ffi/threads.tex document (in CVS). For everyone's convenience, I've put up a typesetted version again at: http://www.uni-graz.at/imawww/haskell/threads.pdf Everyone please tell me what you think. Cheers, Wolfgang

1 0

[Hugs]Unexpected signal from FFI
by Marco Vezzoli 24 Apr '03

24 Apr '03

(sorry for the cross-posting with hugs-user -- I 've found this ml later) Hi, I'm learning how to use ffi with hugs (latest version, on Solaris 8, gcc 3.0.2). I can compile this simple example without errors ----Test.hs----------------------- module Test where import Foreign.C.String import Foreign.C.Types foreign import ccall "test.h incr" incr :: Int->IO Int foreign import ccall "test.h times" times :: CChar->Int->IO CString testTimes = do{j<-times (castCharToCChar 'a') 3;c <- peekCString j ;putStr c} testIncr = do{j<-incr 1;putStr $show j} ----Test.hs----------------------- ----test.c----------------------- #include <stdlib.h> #include "test.h" int incr(int i){ return i+1; } char* times(char c,int i){ printf("times running %d\n",i); char* ret; char* itr; ret=(char*)malloc(i*sizeof(char)+1); for (itr=ret;itr<ret+i;itr++){ *itr=c; } *itr=0; return ret; } ----test.c----------------------- ----test.h----------------------- int incr(int); char* times(char,int); ----test.h----------------------- the command I use is ffihugs -P{Hugs}/libraries/:{Hugs}/oldlib +G +L"test.c" Test.hs and generates Test.c and Test.so Hugs loads correctly the module but fails one of the tests: [vezzoli@web:883] ffi ->hugs -P{Hugs}/libraries/:{Hugs}/oldlib Test.hs __ __ __ __ ____ ___ _________________________________________ || || || || || || ||__ Hugs 98: Based on the Haskell 98 standard ||___|| ||__|| ||__|| __|| Copyright (c) 1994-2002 ||---|| ___|| World Wide Web: http://haskell.org/hugs || || Report bugs to: hugs-bugs(a)haskell.org || || Version: November 2002 _________________________________________ Haskell 98 mode: Restart with command line option -98 to enable extensions [loading prints removed] Test.hs Type :? for help Test> testIncr 2 Test> testTimes Unexpected signal [vezzoli@web:884] ffi -> The C code compiles and works correctly with a stand-alone test. Thank you in advance for any help. Marco -- Marco Vezzoli tel. +39 039 603 6852 STMicroelectronics fax. +39 039 603 5055 -- Marco Vezzoli tel. +39 039 603 6852 STMicroelectronics fax. +39 039 603 5055

1 0