Re: Latest GHC (binary distr) and Suse 6.3 linux
Laszlo Nemeth wrote: libgmp is from the gnu web site, freshly installed. After 'make' the libgmp.so.2 file was generated from libgmp.a by ld -Bsymbolic. If anyone had similar problems or knows how to fix this I would appreciate any hints. The problem of getting a shared version of libgmp was addressed around New Year's. Marcin 'Qrczak' Kowalczy gave the following URL for source code that allows building both static and shared libs: A HREF="ftp://ftp.pld.org.pl/stable/SRPMS/gmp-2.0.2-14.src.rpm" ftp://ftp.pld.org.pl/stable/SRPMS/gmp-2.0.2-14.src.rpm/A I haven't tried it (I had already built a shared version by editing the Makefile by hand), but it should work just fine. By the way, although I am by no means an expert on shared libraries, I am quite certain that it is not possible to turn a standard static library into a shared library. Among other problems, the code in a shared library must be position-independent, and the only way to get position-independent code is to compile the source code with the option -fPIC (or perhaps some other equivalent option if you're not using GCC), which is not normally done for a static library. Mark Mark E. Hall Mahanakorn University of Technology Vanit Building 2, 8th Floor 1126/1 New Petchburi Road Bangkok 10400, Thailand 66-2-6553181--7 [EMAIL PROTECTED] http://www.mut.ac.th/~mehall
Re: Trivial Haskell Concurrency problem
Tom Pledger wrote: For two threads to have access to the same MVar, they must have a common ancestor, right? Could a common ancestor spawn a transaction broker thread? That would be similar to what database management systems do. It'd still be centralised, but wouldn't need to do unsafe IO. Well, all threads trivially have a common ancestor. But I don't see how you can pick a particular ancestor. The flags could easily have been passed around in a fairly general fashion along polymorphic channels.
Re: Trivial Haskell Concurrency problem
Marcin 'Qrczak' Kowalczyk wrote: ...relative time of IO events that occured in a single thread. (=) imposes the sequencing. Yes OK. I see no problem with required elements of the Unique type to increase in a single thread. But I suspect anything stronger than this could slow things down and/or cause difficulties. BTW: The random generator from the IO monad seems to be not thread-safe. Oops. I think it should be either fixed or documented. Haha. That'll teach them to write global variables into the standard, won't it? That's why I said Integer, not Int :-) It's important in the application I have in mind (the Two-Flags problem is a real one in UniForM) that the Unique type be as fast as possible. So I really do not want it to be tied to any particular thing. For example I suggest that for GHC the most efficient implementation might be an Int64 or a 64-bit pointer (to nothing) on machines which support that, or when not a Double with incrementing done by the nextAfter function. Integer is just too slow. (You have to allocate two blocks of memory for it I think.)
Re: Latest GHC (binary distr) and Suse 6.3 linux
Laszlo Nemeth wrote: Sorry to bother the list with a purely installation problem, but I downloaded the latest i386-unknown-linux binary, plus happy-1.6 and can't get them run. [...] Perhaps the easiest way for SuSE users until SuSE finally gets this libgmp problem fixed :-( is to use the RPMs from ftp://ftp.informatik.uni-muenchen.de/pub/local/pms/ They have been built on SuSE 6.2 and consequently don't depend on the dynamic version of libgmp. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
RE: Wanted: mmap or other fast IO
Manuel M. T. Chakravarty [EMAIL PROTECTED] writes: Sven Panne [EMAIL PROTECTED] wrote, [ Simply can't resist... ;-) ] Simon Marlow wrote: The easiest way is to declare mmap as a foreign function using foreign import, then build a little wrapper around it. A problem will be: What Haskell types should be used for size_t and off_t? Getting this done properly would require autoconf or something similar. Perhaps some more Haskell types (Size, Off, ...) should be added to the FFI module. I'm not sure which ones exactly and if FFI is the right place for it. Opinions? I don't think that the standard FFI is the right place for that. If you are programming the FFI by hand, autoconf is the right thing to use. Otherwise, a tool can help. C-Haskell can compute the right type by analysing the C headers, ie, feeding it `sys/mman.h'. H/Direct when fed `mman.h' might also do the right thing. I don't see why HDirect shouldn't. This request is not a new one - having a module that provides a Haskell mapping for the various 'abstract' types that ISO/ANSI C defines (and POSIX.1 doesn't.) It was a bit painful to introduce such a thing at the time (it very easily led to mutual dep. between the 'posix' and 'misc' syslibs), but perhaps the new library organization has untied the knot. --sigbjorn
RE: Wanted: mmap or other fast IO
Title: RE: Wanted: mmap or other fast IO Is there any interface to mmap(2) available? Something that behaves like an immutable array would be great. An mmap may have a signature like mmap :: Ix a, ?? b = Handle - IO (Array a b) I've no idea what types should be allowed for b. It has to be some fixed size type, e.g. Int, but this would require the mmapped file's size to be a multiple of the size of Ints. The easiest way is to declare mmap as a foreign function using foreign import, then build a little wrapper around it. Unfortunately you won't be able to turn the resulting memory into an array (even a ByteArray), since these are assumed to live in GHC's heap, but you'll be able to return an Addr and use writeXXXOffAddr/readXXXOffAddr to access it(*). Cheers, Simon (*) the readXXXOffAddr functions are known to be broken at the moment (see recent discussion on ghc-bugs), we're currently working on fixing them.
Re: Wanted: mmap or other fast IO
[ Simply can't resist... ;-) ] Simon Marlow wrote: The easiest way is to declare mmap as a foreign function using foreign import, then build a little wrapper around it. A problem will be: What Haskell types should be used for size_t and off_t? Getting this done properly would require autoconf or something similar. Perhaps some more Haskell types (Size, Off, ...) should be added to the FFI module. I'm not sure which ones exactly and if FFI is the right place for it. Opinions? [...] but you'll be able to return an Addr and use writeXXXOffAddr/ readXXXOffAddr to access it(*). If you are using GHC 4.06 you should better use the Storable class in the module FFI. For an idea what a slightly higher-level module layered upon FFI could look like, see http://www.informatik.uni-muenchen.de/~Sven.Panne/haskell_libs/ffi/Marshal.hs or Manuel's http://www.informatik.uni-muenchen.de/~Sven.Panne/haskell_libs/ffi/C2HSMarsh.hs from his C-HS tool. Both should be merged and improved somehow, suggestions welcome. (*) the readXXXOffAddr functions are known to be broken at the moment (see recent discussion on ghc-bugs), we're currently working on fixing them. A workaround is not using -O for modules using FFI or readXXXOffAddr. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
Re: Wanted: mmap or other fast IO
Sven Panne [EMAIL PROTECTED] wrote, [ Simply can't resist... ;-) ] Simon Marlow wrote: The easiest way is to declare mmap as a foreign function using foreign import, then build a little wrapper around it. A problem will be: What Haskell types should be used for size_t and off_t? Getting this done properly would require autoconf or something similar. Perhaps some more Haskell types (Size, Off, ...) should be added to the FFI module. I'm not sure which ones exactly and if FFI is the right place for it. Opinions? I don't think that the standard FFI is the right place for that. If you are programming the FFI by hand, autoconf is the right thing to use. Otherwise, a tool can help. C-Haskell can compute the right type by analysing the C headers, ie, feeding it `sys/mman.h'. H/Direct when fed `mman.h' might also do the right thing. It might of course be nice to provide some libraries in hslibs/ that define access to some of the often used types and functions. Manuel
