lan ve Reklamlarnz
ilan gazetesi bayinizde sadece 500.000 TL, isteyiniz. ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 13
Alastair Reid [EMAIL PROTECTED] wrote, I wonder how this discrepancy between the libraries and the report arose. For what it's worth, the library has been that way since June 28, 2001: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/Foreign/ Storable.hs?rev=1.1content-type=text/x-cvsweb-markup http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/GHC/ Storable.lhs?rev=1.1content-type=text/x-cvsweb-markup This seems to be copied from Marcin's QForeign which had the same type from Jan 2, 2001 - March 18, 2001 (i.e., the entire lifetime of the library) http://cvs.sourceforge.net/viewcvs.py/qforeign/qforeign/lib/ QStorable.hsc?rev=1.7view=markup Did I simply make a mistake when writting the report (then, this would qualify as an error in the report anyway)? On this evidence, it looks like it's an error in the report. I agree. I am changing the report. Thanks for the forensics. And thanks to Sven for spotting the mismatch. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 13
Ross Paterson [EMAIL PROTECTED] wrote, In the sentence The marshalling takes the current Unicode encoding on the Haskell side into account. (which seems to have been there before), current seems wrong, since the Haskell side is constant. How about something like The marshalling converts each Haskell character, representing a Unicode code point, to one or more bytes in a manner determined by the current locale. and dropping the later sentence about the locale. Done. It might be worth emphasizing that the Len is the number of bytes rather than Chars. Done. In the part about the single-byte versions, it might be worth tightening the warning to say that these preserve only the first 256 values of Char. Ok. (That is the Latin-1 subset, so calling them ASCII seems a misnomer.) Yes, but we can't call it Latin-1 either, because that implies a locale (there is also Latin-2 etc). Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 13
John Meacham [EMAIL PROTECTED] wrote, On Fri, Oct 31, 2003 at 12:32:55PM +, Ross Paterson wrote: Making the Right Thing the default, though it may cost more, seems appropriate. In the sentence The marshalling takes the current Unicode encoding on the Haskell side into account. (which seems to have been there before), current seems wrong, since the Haskell side is constant. How about something like The marshalling converts each Haskell character, representing a Unicode code point, to one or more bytes in a manner determined by the current locale. and dropping the later sentence about the locale. This sounds good to me. I also might reword the paragraph introducing the 8bit versions, as the efficiency reason for using them is less important than the API one. meaning that some C APIs specify that a localized string should be passed, while others explicitly don't use localization and only expect ASCII (or another specific encoding such as utf8) strings and this is most likely what will determine the choice of string marshalers. True. I changed that. What happens if one attempts to convert a Char that has no encoding in the current locale? 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, I chose the '?' route because it matches what happens when you don't have a font installed and get a replacement character and is less troublesome for the user. I agree. I now documented to conversion to '?'. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 13
I have put RC 14 at http://www.cse.unsw.edu.au/~chak/haskell/ffi/ including all the feedback on RC13. Please especially have a look at Section 6.3 (Section CString), where some of the wording changed. Cheers, Manuel ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 13
W licie 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 application: - When displaying email on screen, it's best to transliterate by removing accents etc. - When communicating with a database, it's best to report an error so configuration can be fixed (perhaps charsets are wrongly set). - When converting HTML, it's best to provide a hook to replace unrepresentable characters with #; -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
Re: ANN: H98 FFI Addendum 1.0, Release Candidate 13
On Sun, Nov 02, 2003 at 09:31:30PM +1100, Manuel M T Chakravarty wrote: Ross Paterson [EMAIL PROTECTED] wrote, (That is the Latin-1 subset, so calling them ASCII seems a misnomer.) Yes, but we can't call it Latin-1 either, because that implies a locale (there is also Latin-2 etc). CByteString? Do you intend to wait until an implementation of this is committed to CVS before finalizing the spec? (I hope so.) Incidentally, the spec says CWChar but the libraries say CWchar. It seems they always disagreed. (If the libs change, maybe CPtrdiff and CFpos should be CPtrDiff and CFPos too.) ___ FFI mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/ffi
