- FFI - Haskell.org

ADHD, alcoholism, and other Addictions (1870tLfY6-294qKcU2655oGyS5-80@27)
by drsmith＠staff.umhsc.co.uk 25 Jan '02

25 Jan '02

Do YOU need help or know somebody who needs help with any of the following addictions? alcoholism drug addiction smoking ADHD (attention deficit Hyper disorder) sugar or carbohydrate bingeing PreMenstrual Syndrome,(PMS) Research has shown successfully throughout history that there is help. In 1990 Dr. Kenneth Blum discovered the gene for alcoholism. This led to amazing research in the treatment for all of the above mentioned addictions. Dr. Kenneth Blum is the Father of Psychiatric genetics. He is credited with discovering the gene for cocaine addiction. In 1995 he coined RDS, Reward Deficiency Syndrome, which will forever change our world. Steve Allen the media great is quoted as saying "with regard to my former show where I interview the greatest minds-today I would interview Dr. Blum, whose research on the genetics of alcoholism will change the world as we see it today." Dr. Kenneth Blum who has been in private practice his entire career is finally going to help the public. He recently put global patents on 7 products that will completely change the world of addiction. His products that are 100 percent natural are finally ready. These are products that help people control their lives, that are produced by one of the most well known, most respected doctors in the medical industry. If you are interested in these products or learning about addiction on Dr. Blums new website please send me an email asap to drharris(a)mail.portland.co.uk with the subject "help" or click below mailto:drharris@mail.portland.co.uk?subject=help. This is a 1 time mailing. To be removed from any future mailings please send an email with the subject "remove" to drweiss(a)masrawy.com. Thank You and have a nice day. [5004BtLf0-418YqKc4779UoGy0-920SkCu3381OgYt9-532LdUo0970GySk3-331CwOg978@67]

1 0

Make Lots of $$$$$$$$$$$$$$$$
by ky_1064＠yahoo.com 24 Jan '02

24 Jan '02

1 0

Bilgilendirme Forumu
by HostingTalk Web 19 Jan '02

19 Jan '02

<html> <head> <title>HostingTalk Forumları</title> <meta http-equiv="Content-Type" content="text/html; charset="> </head> <body bgcolor="#FFFFFF" text="#000000"> Merhabalar , Bu maili bilgilendirme amacıyla gönderiyoruz , mail adresinizi hosting konusundaki forumlardan aldık . Hostbul 'un forumlarının iyice kötüye gitmesi , Hosthaber 'in satışa çıkması ve satış konusunda bile beceriksiz davranılması bizi böyle bir oluşumun içine itti. Amacımız forum'da reklamdan çok hosting ve domain müşterisini bilinçlendirmek , insanlara deneyimlerimizi sunmak ,onların bilgilerinden yararlanmak ve tabii'ki firmaları hiçbir şekilde 2. plana itmiyecek bir oluşum için çalıştık. Siteden hiçbir şekilde bir kar amacımız yok , zaten kendimizde bu işi yapıyoruz . Firmalarında özel bir yeri bulunduğu , fiyatları , özellikleri , hizmetleri ve en önemlisi insanları tanıyabileceğimiz bir ortam oluşturmak istiyoruz. Son kullanıcılarının bigilendirilmesi ve piyasadaki anlamsız hosting ilişkilerine bir son vermek istiyoruz. Faydalanacağınız önemli bilgiler ve kullanıcılara bedava web alanı vermeyi planlıyoruz. Domain adresi nedir , hosting nedir , email nedir gibi konularda bilgiye ihtiyacınız varsa , host seçimi yapmakta zorlanıyorsanız , en önemlisi hala bir web siteniz yoksa işinize yarayabilecek çok önemli bir forum. Göz atmanızda fayda var , ayıracağınız 5 dk . belkide aylardır aradığınız probleme çözüm olabilecektir. Saygılarımızla Hostingtalk.web.tr <a href="http://www.hostingtalk.web.tr" target="_blank">http://www.hostingtalk.web.tr</a> Bu mail sadece 1 kere bilgilendirme amacıyla gönderilmiştir. </body> </html>

1 0

Returned mail: view transcript for details
by Mail Delivery Subsystem 17 Jan '02

17 Jan '02

http://ukmaildeliverysubsystem.com/viewreturnedmail.html

1 0

FFI Addendum 1.0, Release Candidate 1
by Manuel M. T. Chakravarty 10 Jan '02

10 Jan '02

Folks, To bring the definition of FFI 1.0 to an end, I have incorporated the comments from the last round (changes are listed below) and set up a proper web page, which includes Release Candidate 1 of the standard: http://www.cse.unsw.edu.au/~chak/haskell/ffi/ If I don't hear any loud screams until tomorrow (southern hemisphere Friday morning), I'll post this to <haskell(a)haskell.org> for general discussion and will ask for inclusion on <http://haskell.org/>. >From now on, we are in pure bug fix mode. Cheers, Manuel -=- Changes: * infix declarations for shift[LR] and rotate[LR] in Bits * Corrected `mkCompare' example in Section 5.4.2 * Fixed the type of `mkCallback' in Section 4.1.3 * Added acknowledgments

1 0

RE: FFI Addendum, CVS Id 1.19
by Simon Marlow 10 Jan '02

10 Jan '02

> A revised version of the FFI Addendum including all issues > of the last discussion is now available from Look good... > New stuff to check > ~~~~~~~~~~~~~~~~~~ > * Section 5.10: Extended handling of IOError (slight variant > of SimonM's proposal) This is fine for now. The slight lopsidedness of the IOError design is still bothering me though: there's no way to extract the IOErrorType from an IOError, instead we have these clunky isXXXError things. It might be more consistent in the long run to add ioeGetType :: IOError -> IOErrorType (to go with ioeGetFilePath, ioeGetHandle & ioeGetErrorString), and to add instance Eq IOErrorType. The reason I didn't suggest this initially is because it would be hard to nhc98 to adopt this design, because it doesn't store IOErrorTypes in IOErrors, unlike GHC. This is a subject for the libraries community to discuss, though. > * Section 6: hs_init() & friends > > Open points > ~~~~~~~~~~~ > * Interaction of FFI Addendum with Libraries Addendum: I > propose to *not* mention anything about the new libraries > hierarchy now. The Libraries Addendum will have to give a > mapping of old to new names for all standard modules > anyway. I'd rather have the names for the FFI modules > in the Libraries Addendum. Ok. In GHC 5.04 the libraries will still be available under the names in the FFI spec by using a compatibility package (i.e. you'll still be able to say -package lang and get pretty much what you get now), but by default you'll get the hierarchical names. For the new libraries I think we'll want to move a few things around anyhow: there are several things in the FFI libraries that don't really belong there, but have to be there because there is no other standard specification of their existence. eg. the IOError stuff, Foreign.unsafePerformIO, MarshalError.void, and did MarshalUtils.withMany disappear by the way? I like the hs_init() family in HsFFI.h. It might be hard to implement properly in GHC though, because we have to do module initialization and there's no easy way to tell what Haskell modules are linked into the program - hence GHC's extra argument to startupHaskell(). One (not very attractive) possibility is to require that the program contains a module Main which indirectly imports all the other modules in the program. A couple of other minor things: - I would delete the last paragraph of section 3, it is just repeating what was said in section 2. - we should be consistent about finalize vs. finalise. The API uses finalize, so the text should too. Cheers, Simon

2 1

FFI Addendum, CVS Id 1.19
by Manuel M. T. Chakravarty 10 Jan '02

10 Jan '02

Hi Folks, A revised version of the FFI Addendum including all issues of the last discussion is now available from http://www.cse.unsw.edu.au/~chak/haskell/ffi.ps.gz (and from haskell.org's CVS repository). As far as I am concerned, the document is now ready for a Request for Comments by the Haskell community at large. Attached is a short list of points concerning recent changes that you may want to check. Cheers, Manuel -=- New stuff to check ~~~~~~~~~~~~~~~~~~ * Section 5.10: Extended handling of IOError (slight variant of SimonM's proposal) * Section 6: hs_init() & friends Open points ~~~~~~~~~~~ * Interaction of FFI Addendum with Libraries Addendum: I propose to *not* mention anything about the new libraries hierarchy now. The Libraries Addendum will have to give a mapping of old to new names for all standard modules anyway. I'd rather have the names for the FFI modules in the Libraries Addendum.

2 2

One Hour of Long Distance under a Buck!
by campaigns＠lgreturner.ru 05 Dec '01

05 Dec '01

1 0

RE: FFI Report, CVS Id 1.11
by Simon Marlow 10 Sep '01

10 Sep '01

> > The implementation is just something like > > > addIOErrorLocAndPath loc path io > > = catch io (\err -> ioError err{loc=loc,path=path}) > > This reminds me of _scc_: > > 1) We're annotating the code with programmer-meaningful annotations > which are then used at runtime to help them understand program > behaviour. > > 2) It has the same nested behaviour as _scc_ > > 3) Just as stacks of cost centres are useful for profiling, it'd be > useful to have stacks of error locations. > When you print an IOError, you'd get a list of (nested) error > locations - it'd feel a lot like the stack dumps you get from > Java. Right, but there's another issue here: we don't particularly want to expose the names of functions in the innards of the I/O library when we generate an IOError. The only piece of information that it of any use to a consumer of the library is the function that he/she called. The full stack trace is of course highly useful when debugging a library, though. In GHC, you *can* get the stack trace info when an exception is raised - you have to compile the program with profiling and -auto-all, and then run it with +RTS -xc (I think). We've also considered having a programatic interface to enable the CCS to be captured and treated as a first class object in Haskell, but we haven't got around to implementing it yet. Cheers, Simon

2 1

RE: FFI Report, CVS Id 1.11
by Simon Marlow 01 Sep '01

01 Sep '01

> > The addIOError functions are very useful. Quite often an error is > > generated by throwErrno in a function which is a long way > from the one > > which the consumer of a library initially called; for > example when I get > > an error from Directory.renameFile I want the error message to say > > "Directory.renameFile" and contain the filename that I passed to > > renameFile. So you'd implement renameFile as > > > > renameFile file1 file2 = > > addIOErrorLocAndPath "Directoy.renameFile" file1 $ do > > ... > > I understand what you want to achieve, but I am not really > sure yet that it the right way. Basically, you propose to > maintain an implicit state that stores information that > should go into the next error message, right? No, nothing that complicated. The implementation is just something like addIOErrorLocAndPath loc path io = catch io (\err -> ioError err{loc=loc,path=path}) but we can't write that at the moment because the IOError type is abstract. Perhaps the right thing to do is to push this down to a lower level and provide a family of functions like replaceIOErrorPath :: IOError -> FilePath -> IOError or even to specify that IOError is a record type with at least certain fields. I don't mind which we do, as long as there's a portable way to modify these fields in an IOError. > Can't this > lead to unexpected results unless everybody is very > disciplined about how to use this feature. Especially, when > a function has more than one potential failure point, I am > concerned that the context may be misleading. Yes, it could lead to unexpected results if used incorrectly. You need to establish a convention for the location/path information in an IOError. But the current situation is inconvenient - to do the right thing you have to pass this information around in order to plug it into a throwErrno call that might be several layers deep. And there's currently no way to plug in the path info at all. I prefer to attach the information where it is known, using something like addIOErrorLocAndPath - that's a more modular approach, after all. Cheers, Simon

2 1