Re: Proposed ghc-pkg and cabal feature - right list?

I'm replying to Simon M. and myself, as should have sent my first reply to the ghc users list, I guess. On 14.03.2010, at 10:54, Axel Simon wrote: Hi Dan, I reply to libraries, I think that's the right list for Cabal. On 13.03.2010, at 21:39, Dan Knapp wrote: There doesn't seem to be a ma

RE: Documenting GHC

| > As a user of GHC, I would vote for a full two-month delay in | > the next release of GHC to allow the GHC team to devote | > two months of their time exclusively to writing documentation. | | While it would be lovely to be able to do that, in reality both Simon PJ | and myself work in a resear

Feedback request: priority queues in containers

Hey, I'd like to request some more feedback on the proposedimplementation for priority queues in containers. Mostly, I feel like adding a new module to containers should be contentious, and there hasn't been as much griping or contention as I expec

Re: Strange GHC/STM behaviour

On 15/03/2010 22:03, Simon Marlow wrote: On 15/03/10 16:02, Michael Lesniak wrote: Hello Simon, with 6.12.1.20100313 the behaviour is worse: even when using $! in the appropiate lines (see [2] in my original message) the programs hangs quite often. Hence, 6.12.1 works better in this (special?)

Re: Strange GHC/STM behaviour

Hello Simon, > I reproduced the deadlock, and it looks like a new one: a lock order > reversal between Schedule.c:checkBlackHoles() and RtsAPI.c:rts_unlock().  It > turns out I've already fixed it in the HEAD as a side effect of some other > improvements, so I'm going to try to bring those into th

Re: Strange GHC/STM behaviour

On 16/03/2010 14:34, Michael Lesniak wrote: Hello Simon, I reproduced the deadlock, and it looks like a new one: a lock order reversal between Schedule.c:checkBlackHoles() and RtsAPI.c:rts_unlock(). It turns out I've already fixed it in the HEAD as a side effect of some other improvements, so

Re: Feedback request: priority queues in containers

On March 16, 2010 09:29:06 Louis Wasserman wrote: > I'd like to request some more feedback on the > proposedimplementation > for priority queues in containers. Mostly, I feel like > adding a new module to containers should be contentious, and there

Re: Feedback request: priority queues in containers

I'm not willing to do this sort of typeclass wrapper thing, primarily because nothing else in containers does -- even though we might have a Mapping type class that handles both IntMap and Map, we don't. I'm inclined to let that design choice stand, as far as containers is concerned. It would mak

Re: Feedback request: priority queues in containers

Hi, I second that choice. There have been some attempts at using type classes, notably the Edison library, but it never got widespread. So I would follow the current containers design. Milan > I'm not willing to do this sort of typeclass wrapper thing, primarily > because nothing else in contain

Re: Feedback request: priority queues in containers

> Specifically, we use a binomial heap, which offers > > O(log n) worst-case union > O(log n) worst-case extract (this in particular was a key objective of ours) > amortized O(1), worst-case O(log n) insertion. (In a persistent context, > the amortized performance bound does not necessarily hold.)

Re: Feedback request: priority queues in containers

Hi, I think this is my first post to this list although I've been reading it for a long time. So, please, be patient with me and my post. On 03/16/2010 02:29 PM, Louis Wasserman wrote: * We offer Functor, Foldable, and Traversable instances that do not respect key ordering. All are

Re: Feedback request: priority queues in containers

Louis Wasserman wrote: > > I'm not willing to do this sort of typeclass wrapper thing, primarily > because nothing else in containers does -- even though we might have a > Mapping type class that handles both IntMap and Map, we don't. > > I'm inclined to let that design choice stand, as f

Re: Feedback request: priority queues in containers

> > So, it is possible to break the invariants of your priority queue by using fmap with a non-monotonic function, right? I see that it might be usefull to have such instances, sometimes. As it is not possible to hide instances, once they are definded, I'd propose to not offer those instances

Re: Feedback request: priority queues in containers

Why not use Okasaki & Brodal's "Optimal Purely Functional Priority Queues"? They offer worst case: * O(1) union, findMin, and insert * O(lg n) deleteMin The primary reason that we don't use this implementation is, quoting from the paper you yourself linked to, > Our data structure is reasonab

Re: Feedback request: priority queues in containers

> > I'm not sure about some of that. Imperative queues sometimes offer O(1) decreaseKey and O(lg n) delete by storing pointers to elements in a priority queue. The usual purely functional PQs can only offer O(n) decreaseKey and O(n) delete. Purely functional PSQs can offer O(lg n) decreaseKey a

Re: Feedback request: priority queues in containers

> I wrote a pretty efficient skew binomial heap implementation -- the first > step of Okasaki's approach -- and found it was already slower than the > optimized binomial heap. I'm not sure whether or not I uploaded that > benchmark, though. I'll do that at some point today, just to keep everyone

Re: Feedback request: priority queues in containers

On March 16, 2010 13:24:32 k...@cas.mcmaster.ca wrote: > Just an aside (and shameless plug ;-): Since the signatures overlap so > much, it is in fact easy to wrap these modules into instances > for many possible different type classes Yes. I can see the preferred way would be to put the classes o

Re: "static_wrapper" imports in the FFI

Hello, after I pulled and made the darcs patch again, now it is 116K, which is still too big to send to the list. If I gzip it, then it becomes 44K, which is almost the right size. For reference, if I use "darcs diff" to compute the changes, the resulting patch is 2.8K. Let me know how to procee

RE: "static_wrapper" imports in the FFI

Try darcs optimize --reorder in your repo, or pull your patch into a freshly got repo. (Annoying internal detail of darcs - it probably won't use the tag unless it's "clean", which requires that any patches not included in the tag should be after it in the repo order) -Original Message-

Re: "static_wrapper" imports in the FFI

On 15/03/10 23:54, Iavor Diatchki wrote: Hi, I think that one may view a "static_wrapper" import as a pair of an export like the one you wrote and an import of the address of the exported function (this is useful because usually it is convenient to install the handler on the Haskell side). Perha

Haskell Platform can't use OpenGL on OpenBSD.

Hello. I have successfully compiled ghc-6.10.4 on OpenBSD on i386. I have downloaded the Haskell Platform tarball, but ./configure fails: [ ... ] checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking for library containing glEnd... no configure: e

Re: "static_wrapper" imports in the FFI

Hello, On Tue, Mar 16, 2010 at 3:22 PM, Simon Marlow wrote: > It seems hard to justify adding this to GHC, since it's really just > syntactic convenience for a particular case.  Traditionally syntactic sugar > for FFI declarations has been implemented in the preprocessing tools: c2hs > and hsc2h

Re: "static_wrapper" imports in the FFI

On 03/16/10 19:38, Iavor Diatchki wrote: The fact that, at present, all GHC-compiled programs require an executable data segment is a fairly significant problem. ... I thought of implementing the feature as a preprocessor but it did not seem very easy to do because we need to parse Haskell

Re: "static_wrapper" imports in the FFI

On Mar 16, 2010, at 19:47 , Isaac Dupree wrote: On 03/16/10 19:38, Iavor Diatchki wrote: The fact that, at present, all GHC-compiled programs require an executable data segment is a fairly significant problem. Something doesn't add up for me here. If *all* GHC-compiled programs require an exe

Re: "static_wrapper" imports in the FFI

Hi, Optionally disabling executable heap blocks would be a separate patch. As far as I know, the only reason that the heap is executable is to support the adjustor thunks used to implement "wrapper" imports. The "static_wrapper" patch provides a way to install Haskell callbacks in many C librarie

Re: Feedback request: priority queues in containers

> > I suspect the following might be faster: > > data BinomForest2 a = Empty >| NonEmpty a [BinomTree2 a] > > data BinomTree2 a = BinomTree2 a [BinomTree2 a] > > This eliminates the "Skip" constructor, which contributes only to the > nested type guarantee. > Ehehehe. This is s

Re: Haskell Platform can't use OpenGL on OpenBSD.

Solved! In case anyone has similar problems, here's what I did. Somehow my LDFLAGS were unset. With LDFLAGS='-L/usr/X11R6/lib -L/usr/local/lib' it passed that test, but still failed in a similar fashion at the next one. In short, I had to install the GLUT library which is not part of the system