August 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

Virus Alert
by iscan-mail02＠extranetpesa.com 30 Aug '03

30 Aug '03

The mail message (file: your_details.pif) you sent to forosabc(a)abc.es contains a virus. (on mailsrv02)

1 0

Delivery Status Notification
by Mail Delivery Service 29 Aug '03

29 Aug '03

The message you sent contained an attachment or description which the recipient has chosen to block. Please choose a different subject and/or attachment format and try again

1 0

RE: CWString
by Simon Marlow 29 Aug '03

29 Aug '03

> 3) link against another library such as libunicode which provides its > own classification routines (this could be done optionally at compile > time...) libunicode is no good, I tried it. It only recognises Unicode characters up to '\xffff'. 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 majority of our installed base. Cheers, Simon

2 1

RE: CWString
by Simon Marlow 28 Aug '03

28 Aug '03

> > > In our new implementation of Data.Char.isUpper and > friends, I made the > > > simplifying assumption that Char==wchar_t==Unicode. With > glibc, this > > > appears to be valid as long as (a) you set LANG to > something other than > > > "C" or "POSIX", and (b) you call setlocale() first. > > > > The glibc Info file says: > > > > The wide character character set always is UCS4, at least on > > GNU systems. > yes. with glibc, wchar_t is always unicode no matter what the locale. > better yet, all ISO C implementations define a handy C symbol to test > for this. if __STDC_ISO_10646__ is defined then wchar_t is always > unicode no matter what. Sure, but as I've been saying, the implementation of glibc doesn't do this. In the C or POSIX locale, the ctype macros only recognise ASCII. Try it: #include <wctype.h> #include <stdio.h> #include <locale.h> main() { setlocale(LC_ALL,""); printf("%d\n", iswupper('A')); printf("%d\n", iswupper(0x391)); // Greek capital alpha printf("%d\n", iswupper(0x3B1)); // Greek small alpha printf("%d\n", iswlower(0x391)); // Greek capital alpha printf("%d\n", iswlower(0x3B1)); // Greek small alpha } $ LANG=en_GB ./a.out 1 1 0 0 1 $ LANG=C ./a.out 1 0 0 0 0 Should this be considered a bug in glibc? Cheers, Simon

3 4

RE: haskell.cs.yale.edu not catching enough attention
by Joanne Parker 28 Aug '03

28 Aug '03

Not Catching Enough Attention? www.submitpower.com will attract heavy traffic to your website. Submit your website to 300,000 search engines and directories today! Click at http://s2h6a0w3.trafficglue.com/mnkr/www/r?1000022673.2963.3.hKbcp4Co6T$WuB to sign up now! Not interested in our www.submitpower.com service? To be taken off our mailing list, please follow the instructions below http://s2h6a0w3.trafficglue.com/mnkr/www/r?1000022673.2963.1.QpJj+s+YRQKtI$

1 0

Virus Alert
by postmaster＠us.es 27 Aug '03

27 Aug '03

Este mensaje ha sido generado AUTOMATICAMENTE por el Sistema de deteccion de Virus de correo de la Universidad de Sevilla, el cual ha encontrado el virus WORM_SOBIG.F en el fichero: wicked_scr.scr que ha enviado a corchu(a)lsi.us.es, debido bien a que su sistema esta infectado por un virus que usa su libreta de direcciones para estos envios indiscriminados o bien a que el propio fichero que esta enviando esta infectado. Accion: rejected.

1 0

Returned mail: see transcript for details
by Mail Delivery Subsystem 27 Aug '03

27 Aug '03

The original message was received at Wed, 27 Aug 2003 13:54:49 +0100 from [200.24.7.180] ----- The following addresses had permanent fatal errors ----- <corchu(a)lsi.us.es> (reason: 550 Unacceptable content) ----- Transcript of session follows ----- ... while talking to localhost.us.es.: >>> DATA <<< 550 Unacceptable content 554 5.0.0 Service unavailable

1 0

RE: CWString
by Simon Marlow 27 Aug '03

27 Aug '03

> hmm.. how odd. I would consider it a bug, I think. I don't have a copy > of the ISO spec handy but will be sure to look up whether that is > conforming... It is certainly a malfeature if it is not a bug... I fired off a message to bug-glibc(a)gnu.org, we'll see what they have to say. Cheers, Simon

1 0

CWString
by John Meacham 27 Aug '03

27 Aug '03

Attached is a properly internationalized implementation of Foreign.C.String, along with some other routines which I feel would be very at home in the FFI standard. Note that I am trying to solve a simpler problem than full generic i18n. I just want the ability to work within the current locale, whatever it might be. I have tested these routines in utf8, latin1, greek, korean and a few other locales. they seem to work well. in addition to properly localeizing withCString, peek/pokeCString and friends I feel it is important to provide routines to work on wchar_t * strings. there are a number of reasons: * if __STDC_ISO_10646__ is defined (which is almost always), conversions can be incredibly optimized, in particular an array of Chars can be implemented directly as an array of wchar_t's * many c libraries nativly take wchar_t *s, converting to and from a multibyte encoding would be wasteful * wchar_t and the assosiated charset routines has been part of C since C90.1 and are quite stable. * and mainly, is is LIKELY that the current multibyte encoding is lossy compared to wchar_t. forcing people to go through char *s will break encodings for no good reason. * multiple locales are very common nowadays, not just for internationalization, but to differentiate between a utf8 based unix and a latin1 one. the routines I propose adding are: withCWString, withCWStringLen, newCWString, newCWStringLen, peekCWString, peekCWStringLen, -- same as CString counterparts charIsRepresentable :: Char -> IO Bool -- returns true if the argument can be represented in the current locale and the types CWChar, CWString, CWStringLen with CWChar == wchar_t and the others defined analogously to the CString versions. also, to a lesser extent I propose we add explicit utf8 routines: withUTF8String, withUTF8StringLen, newUTF8String, newUTF8StringLen, peekUTF8String, peekUTF8StringLen there are several libraries (X11 being a major one) which export an explicit utf8 based interface, it would be nice to be able to call their routines directly without worrying about the current locale. these might be more at home in a seperate library and not the FFI spec since they can be implemented independently, but can probably benefit from compiler dependent optimization. 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 all. the localized versions of the CString routines are named with LCString, which stands for localized C string...

3 4