July 2005 - Haskell-Cafe

matrix computations based on the GSL
by Alberto Ruiz 21 Apr '06

21 Apr '06

Hello all! This is my first message to the list. In my work I often need linear algebra algorithms and other numeric computations. An option is using scientific computing systems like Matlab, Mathematica, Maple, etc. In Haskell there are several modules and bindings to matrix libraries; many of them are excellent. But I think that Haskell would be even more attractive if the basic matrix computations (what we find, for example, in the GNU Octave Quick Reference) were easily available in a standard library. We have all we need: an interactive environment, excellent graphics (HOpenGL), FFI and ForeignPtr with automatic garbage collection, QuickCheck, etc. Computations can be implemented by the GSL (GNU Scientific Library), a well designed numerical library written in C. Well... I know that I am trying to reinvent the wheel: I am working on a user friendly functional interface to matrix computations based on the GSL. I think that many numeric problems that can be solved using Octave or a similar system can be also solved more elegantly using Haskell. The library is very preliminary and incomplete but some simple problems can already be solved. The sources, haddock documentation and the draft of a tutorial can be found at: http://dis.um.es/~alberto/hmatrix/matrix.html I am not a Haskell expert, I only use the most basic programming techniques, so any suggestion will be greatly appreciated... Alberto

22 97

How to debug GHC
by Monique Louise de Barros Monteiro 10 Sep '05

10 Sep '05

Hi, all, I'm developing a back end for GHC and I have the following problem: my program is throwing an "empty list exception" due to head [] and I need to compile GHC with -prof -auto-all in order to see the stack trace when running it with +RTS -xc -RTS. I changed the makefile but the option +RTS -xc -RTS was not recognized as an available RTS option Does anyone have any idea about how I can do that ? Thanks in advance, __________________________________________________ Monique Louise Monteiro Mestranda em Ciencia da Computacao Centro de Informatica - CIn - UFPE

14 21

RE: [Haskell-cafe] FFI and callbacks
by Simon Marlow 22 Aug '05

22 Aug '05

On 20 July 2005 14:35, John Goerzen wrote: > I'm looking at packaging an event-driven console widget set (CDK) for > Haskell using FFI. I know that other event-driven widget sets have > Haskell bindings, but I'm not quite sure how to make everything play > nice with forkIO. > > These systems generally have some sort of an opaque main loop, > implemented in C. This loop would usually never return, or perhaps > only return once the UI is destroyed. Is the library thread-safe or not? I mean OS-thread safe. If it is, then you're home and dry: just compile your program with GHC's -threaded option, and any foreign calls that need to run concurrently with Haskell threads must be declared "safe" (which is the default in fact, so instead I should really advise you to mark all calls that don't need to run concurrently as "unsafe", because that's good for performance). If the library isn't thread-safe, then you're in the same boat as Gtk and wxHaskell (I believe) where there are known problems with having a multithreaded Haskell GUI app. You can only have one OS thread (and hence only one Haskell thread) doing GUI operations, and that is the thread in the main loop. You have to somehow set up a communication between your other Haskell threads and the thread running the main loop - perhaps you can send requests of type (IO ()) down a channel to the main loop thread which wakes up occasionally to run them, for example. Cheers, Simon

5 8

Call for participation: CUFP 2005
by Andy Moran 01 Aug '05

01 Aug '05

IMPORTANT NOTE: Registration is now available at: http://www.cs.ioc.ee/tfp-icfp-gpce05/ CUFP 2005 THE SECOND ACM SIGPLAN COMMERCIAL USERS OF FUNCTIONAL PROGRAMMING WORKSHOP http://www.galois.com/cufp/ Talinn, Estonia September 24th 2005 Co-located with ICFP http://www.brics.dk/~danvy/icfp05/ ---------------------------------------------------------------------- Important dates Early registration deadline July 29, 2005 Late registration deadline September 2, 2005 Workshop September 24, 2005 Registration is available at: http://www.cs.ioc.ee/tfp-icfp-gpce05 ---------------------------------------------------------------------- The goal of CUFP is to build a community for users of functional programming languages and technology, be they using functional languages in their professional lives, in an open source project (other than implementation of functional languages), as a hobby, or any combination thereof. In short: anyone who uses functional programming as a /means/, but not an /end/. ---------------------------------------------------------------------- Schedule The meeting will last a full day, with a mix of invited presentations and discussion sessions. This year, we have the following confirmed speakers: * Atrijus Tang; talking about PUGS, a Perl6 implementation, written in Haskell; * Fabrice Le Fessant; talking about MLDonkey, a popular multi-platform, multi-network P2P client written in OCaml. * Michael Sperber; talking about uses of Scheme in the banking industry. * David Roundy; talking about darcs, a popular and flexible revision control system well-suited to highly distributed development, written in Haskell. * Jim Grundy; talking his experiences with functional programming at Intel's Strategic CAD Labs. * Robert Boone; talking about his experiences at FreeScale. * Jonathan Soebel; talking about lessons the FP community can learn from the OMG's Model Driven Architecture (MDA) and its related marketing efforts. We will also be having two working sessions, where lively debate and brainstorming will be the order of the day: * FP, Education, and Industry: industry folks complain that there aren't enough FP folks being produced by schools, and educators complain that students don't see any point in studying FP if there are no jobs to be had. How can we break this stalemate? Simon Thompson of Functional and Declarative Programming in Education (FDPE05) will be joining us, and we'll be debriefing at FDPE05. * Stimulating a CUFP Community: we'd like the buzz and excitement surrounding CUFP to persist beyond the workshops. What would such a community look like? How do we make it happen? The session will kick off with two separate but complimentary starting points: a proposed "Users of FP" community web site and a proposed "Haskell Consortium" web site. There will be no published proceedings, as the meeting is intended to be more a discussion forum than a technical interchange. A full report of last year's workshop appeared in the Functional Programming column of the December 2004 issue of SIGPLAN Notices, and we plan to do the same this year. -- Andy Moran Phone: 503.626.6616, x113 Galois Connections Inc. Fax: 503.350.0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005 moran(a)galois.com

5 6

STM and MonadFix?
by Jonathan Cast 29 Jul '05

29 Jul '05

Why is there no MonadFix STM instance? Jon Cast

1 0

RE: [Haskell-cafe] hssfig: Unresolved symbols when importing a foreignlibrary: what is the preferred way of handling?
by Simon Marlow 28 Jul '05

28 Jul '05

On 27 July 2005 15:32, Dimitry Golubovsky wrote: > - instead of generation of a single object file referencing all the > functions, create one per funciton import and place them all in an > archive (.a). Then, when linking, only actually used functions will be > picked from the archive. This is what ghc -split-objs does. It's something of a hack, but I just thought I'd mention it. I believe it would fix your problem. Cheers, Simon

1 0

Suggestions for #defines with FFI
by John Goerzen 28 Jul '05

28 Jul '05

Hi, I'm writing a Haskell interface to a library that #defines about 100 constants corresponding to numeric exit codes. It also defines hundreds of contants, over the same numbering ranges, for other purposes. The exit codes are non-contiguous as well. So my question is: is there a nice way I can represent this in Haskell, preferably without having to key in all 100 constants? Or will I just have to list all the options and give up type checking to differentiate one purpose of a constant from another? Thanks, -- John

3 3

RE: [Haskell-cafe] Suggestions for #defines with FFI
by Dimitry Golubovsky 28 Jul '05

28 Jul '05

John, Could you please give an example of such constant definitions? Is it possible to look at the include file? -- Dimitry Golubovsky Anywhere on the Web

4 5

hssfig: Unresolved symbols when importing a foreign library: what is the preferred way of handling?
by Dimitry Golubovsky 27 Jul '05

27 Jul '05

I would like to collect opinions from interested people on this matter. Background: Hsffig parses include files (.h) and generates FFI import declarations for every function/external variable it encounters a prototype declaration for. The result is a .hsc file which is converted into a Haskell source and compiled into an object file and linked into an executable along with other application source files using ghc as frontend (so far, hsffig is targeted to ghc users only). This object file will contain references to all foreign functions to be imported. Problem: In some cases, a include file may contain prototypes of functions not existing in the library it corresponds to. In my case, <unistd.h> (Linux, glibc2) contains prototypes for __ftruncate and pthread_atfork which come up unresolved when linking the executable without additional libraries specified. pthread_atfork is resolved when linking with -lpthread. Where is __ftruncate defined, I don't know, and I do not really want ot know unless I need to use this function. Possible solutions, sorted by expected amount of work necessary to implement (please pick one you would prefer, or suggest yours): - leave everything as is: the executable will not be linked until the developer finds all the libraries to resolve all the missing symbols. That's how it works (or doesn't work) now. - tell ld only to warn about unresolved symbols: the executable will be built anyway, but if the unresolved function is called from under the hood it most likely results in segfault hard to explain (which function caused it). Only special linker option is required. - for each foreign function imported, generate a stub which, when called, complains loudly and aborts the program. These stubs are placed in a separate object file and linked after all possible libraries, so library-defined symbols always take precedence. The disadvantage is: the developer would not know which symbols remained unresolved when the executable was linked, only will he know when the application crashes. I am trying to implement this now, using the hsc2hs' #def macro to define those stub functions. - analyze the linker output and make auto-correction in the generated .hsc file just by excluding FFI declarations for unresolved functions. Non-elegant, requires second pass and highly platform and tool dependent. - instead of generation of a single object file referencing all the functions, create one per funciton import and place them all in an archive (.a). Then, when linking, only actually used functions will be picked from the archive. I am not sure how would this interact with ghc --make: I got an impression that a .hi file is necessary for all modules (.hs/.hi/.o triple) imported unless they are gotten from a package. If I have in my program: import FOO_H and there is no FOO_H.hi nor FOO_H.hs, only libFOO_H.a: how ghc would live with this? The latter approach does not take much to implement in hsffig itself (I already have a splitter which splits into one object file per a structure/union). I am more concerned how to make ghc live with this. Creation of a package for each imported include file seems like overkill. PS I believe that hsffig will be an useful utility. I noticed several people downloaded nightly tarballs or checked out from the DARCS repo. If these persons have found this program useful, would they please suggest something on the matter I described. -- Dimitry Golubovsky Anywhere on the Web

1 0

RE: [Haskell-cafe] ForeignPtrs with liveness dependencies
by Simon Marlow 27 Jul '05

27 Jul '05

On 26 July 2005 16:49, Einar Karttunen wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >> No, unfortunately not. You have foo's finalizer which refers to bar >> via a touchForeignPtr. If both foo and bar are unreachable >> (references from finalizers don't count), then both foo and bar's >> finalizers will be started together, and may run in any order. > > I didn't realize the "references from finalizers don't count" rule. It does make sense. If references from finalizers *did* keep objects alive, then if you had two objects that referreed to each other by their finalizers, neither would ever be finalized. This paper has all the rationale, you might find it interesting: http://www.haskell.org/~simonmar/papers/weak.pdf Expressing ordering relationships between finalizers is known to be hard - for instance, if you have a chain of N dependent finalizers that are all unreachable, you don't want to take N major GCs to discover the fact. The canonical paper on this is Hans Boehm's "Destructors, finalizers, and synchronization": http://portal.acm.org/citation.cfm?id=604153 > What would happen if the finalizer of foo would resurrect bar after > bar's finalizer has been run? That can happen. Nothing goes wrong on the Haskell side, but if this is a problem for your C objects then you need to be aware of it. >> So touchForeignPtr does only one thing: it expresses the precise >> relationship "bar is alive if foo is alive". If both are not alive, >> then both finalizers can run, in any order. > > So reference counting the objects is the solution? Perhaps. It seems robust, anyway. >> I realise this is very subtle. By all means suggest improvements to >> the docs. > > Mentioning that references from finalizers don't count could help > someone not to repeat my mistakes. Ok, will do. Cheers, Simon

1 0