Re: [Haskell-cafe] Poll & plea: State of GUI & graphics libraries in Haskell

[Paul Liu]

Hi Conal,

I wasn't able to make it to last Saturday's FARM track, but I think
there was a good chance that Paul would have demonstrated his Euterpea
music library, which includes a GUI interface (called MUI) written on
top of GLFW. I wrote its initial implementation (around 2009?) with a
monadic interface that let you wire together UI components with
signals (I believe Dan later wrote an arrow interface, but I could be
wrong). It was actually inspired by the ideas behind your Phooey UI
library. It should be very easy to extract this part out as a
standalone package if there is enough interest.

The only issue with it (and all other UI libraries) is that it doesn't
play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4
on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke
Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this
problem.

BTW, as also the author of the GLFW library on HackageDB, I've done
barely minimal to keep this Haskell binding afloat. I'm actually
leaning towards GLFW-b library, which is better maintained, and
provides similar binding for GLFW C library but with a saner interface
(no dependency on the OpenGL library, for example). If you don't need
the two extra things that GLFW does (choice of either dynamic or
static linking to GLFW C, and an embedded bitmap font), I suggest you
try out GLFW-b if you are only looking for a think graphics layer with
input+window+OpenGL.

The only thing keeping GLFW-b from becoming a good foundation for a
pure Haskell UI lib is IMHO the lack of a light-weight,
cross-platform, and full-featured font rendering solution. I believe
many other libraries (including Diagram) are having the same problem.


On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott  wrote:
> I'm polling to see whether there are will and expertise to reboot graphics
> and GUIs work in Haskell. I miss working on functional graphics and GUIs in
> Haskell, as I've been blocked for several years (eight?) due to the absence
> of low-level foundation libraries having the following properties:
>
> * cross-platform,
> * easily buildable,
> * GHCi-friendly, and
> * OpenGL-compatible.
>
> The last several times I tried Gtk2hs, I was unable to compile it on my Mac.
> Years ago when I was able to compile, the GUIs looked and interacted like a
> Linux app, which made them awkward and upleasant to use. wxHaskell (whose
> API and visual appearance I prefered) has for years been incompatible with
> GHCi, in that the second time I open a top-level window, the host process
> (GHCi) dies abruptly. Since my GUI & graphics programs are often one-liners,
> and I tend to experiment a lot, using a full compilation greatly thwarts my
> flow. For many years, I've thought that the situation would eventually
> improve, since I'm far from the only person who wants GUIs or graphics from
> Haskell.
>
> About three years ago, I built a modern replacement of my old Pan and
> Vertigo systems (optimized high-level functional graphics in 2D and 3D),
> generating screamingly fast GPU rendering code. I'd love to share it with
> the community, but I'm unable to use it even myself.
>
> Two questions:
>
> * Am I mistaken about the current status? I.e., is there a solution for
> Haskell GUI & graphics programming that satisfies the properties I'm looking
> for (cross-platform, easily buildable, GHCi-friendly, and
> OpenGL-compatible)?
> * Are there people willing and able to fix this situation? My own
> contributions would be to test and to share high-level composable and
> efficient GUI and graphics libraries on top of a working foundation.
>
> Looking forward to replies. Thanks,
>
> -- Conal
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Regards,
Paul Liu
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] New Functional Programming Job Opportunities

[Functional Jobs]

Here are some functional programming job opportunities that were posted
recently:

Senior Scala Developer for Green Building Software at Sefaira
http://functionaljobs.com/jobs/8649-senior-scala-developer-for-green-building-software-at-sefaira

Cheers,
Sean Murphy
FunctionalJobs.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: Partitionable goes somewhere + containers instances

[Mario Blažević]

On 09/29/13 08:20, Edward Kmett wrote:
I don't know that it belongs in the "standard" libraries, but there 
could definitely be a package for something similar.


ConstraintKinds are a pretty hefty extension to throw at it, and the 
signature written there prevents it from being used on ByteString, 
Text, etc.


This can be implemented with much lighter weight types though!
class Partitionable t where
 partition  ::  Int  ->  t  ->  [t]


I'm not sure why I don't already have this method in the 
FactorialMonoid class, but I'll happily add it if anybody wants it. 
Probably under the name splitEvery, since I already have splitAt.


I'm not sure this is actually the best answer to Ryan's original 
plea, because I thought the idea was to let the original monoid "split 
itself" in an optimal way, which would preferably be an O(1) operation. 
Then again, this could be overly optimistic. For example, Map is defined as


data Map k a = Bin {-# UNPACK #-} !Size !k a !(Map k a) !(Map k a)
| Tip

so the simple O(1) split would produce three submaps, the middle one 
having only one element. This operation would not be very 
parallelization-friendly.


That is not particularly surprising, since parallelization was not 
the main concern when Data.Map (or containers) was originally written. 
The main goal, as it should have been, was optimizing the containers for 
sequential execution speed. A containers-like package optimized for easy 
and efficient parallelization would have to be written almost from scratch.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: Partitionable goes somewhere + containers instances

[Mike Izbicki]

Besides just partition balance, the ordering of the resulting partitions is
important.  For example, the most efficient way to partition a list is by
taking an every-other-n approach, whereas the most efficient way to
partition a vector is by using a slice.  (This, BTW, might be a good
alternative name for the class to avoid the conflict Edward mentioned.)

These partitions are not necessarily usable in the same contexts.  For
example, Vector's slicing strategy is always usable (only requires
associativity of the monoid to reduce over, which is guaranteed by the
laws).  But the List's strategy also requires commutativity.  This is not
guaranteed.

I would guess that maintaining the partition ordering and balance will be
at odds with each other in the Map and Set cases.


On Sun, Sep 29, 2013 at 8:06 PM, Ryan Newton  wrote:

> Thanks Edward.  Good point about Brent's 'split' package.  That would be a
> really nice place to put the class.  But it doesn't currently depend on
> containers or vector so I suppose the other instances would need to go
> somewhere else.  (Assuming containers only exported monomorphic versions.)
>
> Maybe a next step would be proposing some monomorphic variants for the
> containers package.
>
> I think the complicated bit will be describing how "best-efforty"
> splitting variants are:
>
>- Is it guaranteed O(1) time and allocation?
>- Is the provided Int an upper bound?  Lower(ish) bound?  Or just a
>hint?
>
> With some data structures, there will be a trade-off between partition
> imbalance and the work required to achieve balance.  But with some data
> structures it is happily not a problem (e.g. Vector)!
>
> But whether there's one variant or a few, I'd be happy either way, as long
> as I get at least the cheap one (i.e. prefer imbalance to restructuring).
>
>   -Ryan
>
>
>
>
> On Sun, Sep 29, 2013 at 8:20 AM, Edward Kmett  wrote:
>
>> I don't know that it belongs in the "standard" libraries, but there could
>> definitely be a package for something similar.
>>
>> ConstraintKinds are a pretty hefty extension to throw at it, and the
>> signature written there prevents it from being used on ByteString, Text,
>> etc.
>>
>> This can be implemented with much lighter weight types though!
>>
>>
>> class Partitionable t where
>>
>>
>> partition :: Int -> t -> [t]
>>
>>
>>
>> Now ByteString, Text etc. can be instances and no real flexibility is
>> lost, as with the class associated constraint on the argument, you'd
>> already given up polymorphic recursion.
>>
>> There still remain issues. partition is already established as the 
>> filterthat returns both the matching and unmatching elements, so the name is
>> wrong.
>>
>> This is a generalization of Data.List.splitEvery, perhaps it is worth
>> seeing how many others can be generalized similarly and talk to Brent about
>> adding, say, a Data.Split module to his split package in the platform?
>>
>> -Edward
>>
>>
>>
>>
>>
>> On Sun, Sep 29, 2013 at 4:21 AM, Ryan Newton  wrote:
>>
>>> 
>>>
>>> On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki  wrote:
>>>
 I've got a Partitionable class that I've been using for this purpose:

 https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs

>>>
>>> Mike -- Neat, that's a cool library!
>>>
>>> Edward --  ideally, where in the standard libraries should the
>>> Partitionable comonoid go?
>>>
>>> Btw, I'm not sure what the ideal return type for comappend is, given
>>> that it needs to be able to "bottom out".  Mike, our partition function's
>>> list return type seems more reasonable.  Or maybe something simple would be
>>> this:
>>>
>>> *class Partitionable t where*
>>> *  partition :: t -> Maybe (t,t)*
>>>
>>> That is, at some point its not worth splitting and returns Nothing, and
>>> you'd better be able to deal with the 't' directly.
>>>
>>> So what I really want is for the *containers package to please get some
>>> kind of Partitionable instances! * Johan & others, I would be happy to
>>> provide a patch if the class can be agreed on. This is important because
>>> currently the balanced tree structure of Data.Set/Map is an *amazing
>>> and beneficial property* that is *not* exposed at all through the API.
>>>For example, it would be great to have a parallel traverse_ for Maps
>>> and Sets in the Par monad.  The particular impetus is that our new and
>>> enhanced Par monad makes extensive use of Maps and Sets, both the pure,
>>> balanced ones, and lockfree/inplace ones based on concurrent skip lists:
>>>
>>> http://www.cs.indiana.edu/~rrnewton/haddock/lvish/
>>>
>>> Alternatively, it would be ok if there were a "Data.Map.Internal" module
>>> that exposed the Bin/Tip, but I assume people would rather have a clean
>>> Partitionable instance...
>>>
>>> Best,
>>>   -Ryan
>>>
>>>
>>> On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki  wrote:
>>>
 I've got a Partitionable class that I've been using for this purpose:

Re: [Haskell-cafe] FFI: how to handle external dll crashes

[kudah]

On Mon, 23 Sep 2013 15:32:35 +0200 Miro Karpis
 wrote:

> Thanks for that. I checked forkProcess - which is packed in POSIX
> module. I'm building under windows. Do I need to go via cygwin, is
> there some other way for creating new OS process?

Windows doesn't support fork(), you'll need to either use cygwin or
move your code to a helper binary and launch it with System.Process.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: Partitionable goes somewhere + containers instances

[Ryan Newton]

Thanks Edward.  Good point about Brent's 'split' package.  That would be a
really nice place to put the class.  But it doesn't currently depend on
containers or vector so I suppose the other instances would need to go
somewhere else.  (Assuming containers only exported monomorphic versions.)

Maybe a next step would be proposing some monomorphic variants for the
containers package.

I think the complicated bit will be describing how "best-efforty" splitting
variants are:

   - Is it guaranteed O(1) time and allocation?
   - Is the provided Int an upper bound?  Lower(ish) bound?  Or just a hint?

With some data structures, there will be a trade-off between partition
imbalance and the work required to achieve balance.  But with some data
structures it is happily not a problem (e.g. Vector)!

But whether there's one variant or a few, I'd be happy either way, as long
as I get at least the cheap one (i.e. prefer imbalance to restructuring).

  -Ryan




On Sun, Sep 29, 2013 at 8:20 AM, Edward Kmett  wrote:

> I don't know that it belongs in the "standard" libraries, but there could
> definitely be a package for something similar.
>
> ConstraintKinds are a pretty hefty extension to throw at it, and the
> signature written there prevents it from being used on ByteString, Text,
> etc.
>
> This can be implemented with much lighter weight types though!
>
>
> class Partitionable t where
>
> partition :: Int -> t -> [t]
>
>
> Now ByteString, Text etc. can be instances and no real flexibility is
> lost, as with the class associated constraint on the argument, you'd
> already given up polymorphic recursion.
>
> There still remain issues. partition is already established as the filterthat 
> returns both the matching and unmatching elements, so the name is
> wrong.
>
> This is a generalization of Data.List.splitEvery, perhaps it is worth
> seeing how many others can be generalized similarly and talk to Brent about
> adding, say, a Data.Split module to his split package in the platform?
>
> -Edward
>
>
>
>
>
> On Sun, Sep 29, 2013 at 4:21 AM, Ryan Newton  wrote:
>
>> 
>>
>> On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki  wrote:
>>
>>> I've got a Partitionable class that I've been using for this purpose:
>>>
>>> https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs
>>>
>>
>> Mike -- Neat, that's a cool library!
>>
>> Edward --  ideally, where in the standard libraries should the
>> Partitionable comonoid go?
>>
>> Btw, I'm not sure what the ideal return type for comappend is, given that
>> it needs to be able to "bottom out".  Mike, our partition function's list
>> return type seems more reasonable.  Or maybe something simple would be this:
>>
>> *class Partitionable t where*
>> *  partition :: t -> Maybe (t,t)*
>>
>> That is, at some point its not worth splitting and returns Nothing, and
>> you'd better be able to deal with the 't' directly.
>>
>> So what I really want is for the *containers package to please get some
>> kind of Partitionable instances! * Johan & others, I would be happy to
>> provide a patch if the class can be agreed on. This is important because
>> currently the balanced tree structure of Data.Set/Map is an *amazing and
>> beneficial property* that is *not* exposed at all through the API.
>>For example, it would be great to have a parallel traverse_ for Maps
>> and Sets in the Par monad.  The particular impetus is that our new and
>> enhanced Par monad makes extensive use of Maps and Sets, both the pure,
>> balanced ones, and lockfree/inplace ones based on concurrent skip lists:
>>
>> http://www.cs.indiana.edu/~rrnewton/haddock/lvish/
>>
>> Alternatively, it would be ok if there were a "Data.Map.Internal" module
>> that exposed the Bin/Tip, but I assume people would rather have a clean
>> Partitionable instance...
>>
>> Best,
>>   -Ryan
>>
>>
>> On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki  wrote:
>>
>>> I've got a Partitionable class that I've been using for this purpose:
>>>
>>>
>>> https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs
>>>
>>> The function called "parallel" in the HLearn library will automatically
>>> parallelize any homomorphism from a Partionable to a Monoid.  I
>>> specifically use that to parallelize machine learning algorithms.
>>>
>>> I have two thoughts for better abstractions:
>>>
>>> 1)  This Partitionable class is essentially a comonoid.  By reversing
>>> the arrows of mappend, we get:
>>>
>>> comappend :: a -> (a,a)
>>>
>>> By itself, this works well if the number of processors you have is a
>>> power of two, but it needs some more fanciness to get things balanced
>>> properly for other numbers of processors.  I bet there's another algebraic
>>> structure that would capture these other cases, but I'm not sure what it is.
>>>
>>> 2) I'm working with parallelizing tree structures right now (kd-trees,
>>> cover trees, oct-trees, etc.).  The real problem is not split

Re: [Haskell-cafe] What class for splittable data / balanced-fold?

[Ryan Newton]

Thanks, that's interesting to know (re: Fortress).

Interestingly, in my Fortress days we looked at both using a split-like
> interface and at a more foldMap / reduce - like interface, and it seemed
> like the latter worked better – it requires a lot less boilerplate for
> controlling recursion, and better matches the fanout of whatever structure
> you're actually using underneath.
>

Ok, we'll have to try that.  I may be underestimating the power of a
newtype and a monoid instance to expose the structure..  I was wrong about
this before [1].  Here's the foldMap instance for Data.Map:

  foldMap _ Tip = mempty  foldMap f (Bin _ _ v l r) = Foldable.foldMap
f l `mappend` f v `mappend` Foldable.foldMap f r

Simon Marlow in his recent Haxl talk also had a domain where they
wanted a symmetric (non-monadic) parallel spawn operation...

But it remains pretty hard for me to reason about the operational
behavior of these things... especially since foldMap instances may
vary.

Thanks,

   -Ryan

[1] For example, here is a non-allocating traverseWithKey_ that I
failed to come up with:


-- Version of traverseWithKey_ from Shachaf Ben-Kiki
-- (See thread on Haskell-cafe.)
-- Avoids O(N) allocation when traversing for side-effect.

newtype Traverse_ f = Traverse_ { runTraverse_ :: f () }
instance Applicative f => Monoid (Traverse_ f) where
  mempty = Traverse_ (pure ())
  Traverse_ a `mappend` Traverse_ b = Traverse_ (a *> b)
-- Since the Applicative used is Const (newtype Const m a = Const m), the
-- structure is never built up.
--(b) You can derive traverseWithKey_ from foldMapWithKey, e.g. as follows:
traverseWithKey_ :: Applicative f => (k -> a -> f ()) -> M.Map k a -> f ()
traverseWithKey_ f = runTraverse_ .
 foldMapWithKey (\k x -> Traverse_ (void (f k x)))
foldMapWithKey :: Monoid r => (k -> a -> r) -> M.Map k a -> r
foldMapWithKey f = getConst . M.traverseWithKey (\k x -> Const (f k x))
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Richard Bird and the fast nub function

[Jason Dagit]

On Sun, Sep 29, 2013 at 1:40 PM, Henning Thielemann <
lemm...@henning-thielemann.de> wrote:

>
> In Richard Bird's "Functional Pearls in Algorithm Design" there is chapter
> 10 "Removing duplicates" which is about a fast and sorting variant of
> 'nub'. After reading the introduction of the chapter I answered mentally
> "Set.toAscList . Set.fromList - next chapter please". However after the
> introduction eight pages follow that develop an efficient algorithm for the
> problem. I suspected there might be the additional difficulty of not using
> the standard Set type, however on page 70 the common Set API is "imported".
> In the final remarks of the chapter Bird writes: "A nagging doubt remains
> that there might be a much simpler solution to such a simply stated
> problem. But so far I have not been able to find one." Now I am lost. Can
> someone tell me, how the task differs from what "Set.toAscList .
> Set.fromList" does?
>

I've been puzzling over this too. The most convincing answer I've come up
with (and it's not very convincing) is that he presented the development
because he aims to teach the process and the skill, not because it lead to
a particularly efficient implementation in this case.

In fact, when folks were talking about improving `nub` on here a few months
ago I finally got around to benchmarking it and found that it wasn't all
that efficient compared to the other proposals. I don't think I have the
numbers anymore. It wasn't terrible but it wasn't amazing either.

So yeah, I don't know what to make of that chapter :(

Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Richard Bird and the fast nub function

[David Fletcher]

On Sun, 29 Sep 2013 21:40:28 +0100, Henning Thielemann  
 wrote:




In Richard Bird's "Functional Pearls in Algorithm Design" there is  
chapter 10 "Removing duplicates" which is about a fast and sorting  
variant of 'nub'. After reading the introduction of the chapter I  
answered mentally "Set.toAscList . Set.fromList - next chapter please".  
However after the introduction eight pages follow that develop an  
efficient algorithm for the problem. I suspected there might be the  
additional difficulty of not using the standard Set type, however on  
page 70 the common Set API is "imported". In the final remarks of the  
chapter Bird writes: "A nagging doubt remains that there might be a much  
simpler solution to such a simply stated problem. But so far I have not  
been able to find one." Now I am lost. Can someone tell me, how the task  
differs from what "Set.toAscList . Set.fromList" does?


It asks for the lexicographically least solution that is still an actual
subsequence, i.e. still in the order it appears in the input.

He gives the example that input "calculus" "aclus".  Your way would
give "aclsu".
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Richard Bird and the fast nub function

[Henning Thielemann]

In Richard Bird's "Functional Pearls in Algorithm Design" there is chapter 
10 "Removing duplicates" which is about a fast and sorting variant of 
'nub'. After reading the introduction of the chapter I answered mentally 
"Set.toAscList . Set.fromList - next chapter please". However after the 
introduction eight pages follow that develop an efficient algorithm for 
the problem. I suspected there might be the additional difficulty of not 
using the standard Set type, however on page 70 the common Set API is 
"imported". In the final remarks of the chapter Bird writes: "A nagging 
doubt remains that there might be a much simpler solution to such a simply 
stated problem. But so far I have not been able to find one." Now I am 
lost. Can someone tell me, how the task differs from what "Set.toAscList . 
Set.fromList" does?

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [ANN] New OpenCV Bindings

[Ivan Perez]

Noam Lewis?

https://github.com/sinelaw



On 28 September 2013 21:48, Arjun Comar  wrote:

> Ahh, I misunderstood then. Who is currently maintaining the HOpenCV
> package on Hackage?
>
>
> On Sat, Sep 28, 2013 at 3:45 PM, Anthony Cowley wrote:
>
>> To be clear, I am not the maintainer of HOpenCV. I have used a fork of
>> that library for experimenting with OpenCV interfaces over the past few
>> years, and written quite a few kloc using it in several robotics oriented
>> projects with computer vision needs. None of my experiments with HOpenCV
>> are on hackage as they are experiments, but I have helped others get
>> started with them over time.
>>
>> I am totally supportive of Arjun's new efforts: OpenCV has changed a lot,
>> and there is reason to be optimistic that he will be able to provide a much
>> better foundation for Haskell bindings than we have ever had. As the low
>> level bindings come online, we will be able to introduce some of the extra
>> type-driven code paths and static checks that have proven successful in the
>> existing fragmented Haskell-OpenCV ecosystem.
>>
>> Anthony
>>
>> On Sep 28, 2013, at 2:31 PM, Arjun Comar  wrote:
>>
>> I've been talking to Anthony Cowley who I think is the current maintainer
>> of HOpenCV and Ville Tirronen who has been developing the CV bindings.
>> Basically the consensus is that these raw bindings provide a new base to
>> work from, and it's worthwhile to rethink the API we provide with a fresh
>> start.
>>
>>
>> On Sat, Sep 28, 2013 at 2:23 PM, Ivan Perez > > wrote:
>>
>>> The people working on HOpenCV are very open to incorporating other's
>>> programmer's patches. Maybe you can incorporate your changes to
>>> cv-combinators? (Project's been halted since 2010, I'm sure they'll be very
>>> happy to see that sb is contributing).
>>>
>>>
>>> On 28 September 2013 19:13, Arjun Comar  wrote:
>>>
 Fair enough, it's been two or three years since I tried to play with
 them. Most of my work is in the raw bindings currently, which provide the
 C++ API in Haskell, so much lower level that cv-combinators. If HOpenCV
 were to incorporate parts of these bindings then cv-combinators would be
 able to benefit from this work. That said, my effort going forward is to
 provide something equivalent to cv-combinators in expressiveness. I'm
 definitely taking inspiration from the library though I'm not basing my
 work on their source code.


 On Sat, Sep 28, 2013 at 12:51 PM, Ivan Perez <
 ivanperezdoming...@gmail.com> wrote:

> I think they do work. cv-combinators depends on HOpenCV, which depends
> on OpenCV 2.0.
>
>
>
> On 28 September 2013 16:03, Arjun Comar  wrote:
>
>> No, these are unrelated. Cv-combinators hasn't really worked since
>> OpenCV 2.0 waa released I believe.
>>  On Sep 28, 2013 8:54 AM, "Ivan Perez" 
>> wrote:
>>
>>> Cool. Thanks a lot for uploading this.
>>>
>>> I have a question (and I confess that I haven't checked the link).
>>> How is this related to or overlaps with cv-combinators?
>>>
>>> Cheers
>>> Ivan
>>>
>>>
>>> On 28 September 2013 06:18, Arjun Comar  wrote:
>>>
 After receiving feedback, I went ahead and split out the raw C
 wrappers and Haskell bindings. You can find them at
 www.github.com/arjuncomar/opencv-raw. I'll upload it to hackage as
 opencv-raw once I have uploader privileges.

 Regards,
 Arjun


 On Fri, Sep 27, 2013 at 4:09 PM, Arjun Comar wrote:

> Hi all,
> I've been hard at work on a new set of OpenCV bindings that will
> hopefully solve a lot of the shortcomings with previous attempts. An
> automatic header parser has been used to generate a full set of 
> Haskell
> bindings for the C++ API, and I'm now working to create a pleasant 
> Haskell
> API. The plan is to expose major functionality through pipes for two
> reasons: 1) OpenCV is not very referentially transparent, and so 
> you're
> stuck in IO for anything non-trivial. Lazy IO is potentially 
> problematic,
> and so immediate incorporation of a proper streaming library is 
> probably
> best. 2) Computer vision algorithms are frequently expressed in terms 
> of
> pipelines of functionality, and a pipes approach can provide a very 
> natural
> API for expressing these algorithms.
>
> At this stage, I could very much use input from anyone who's
> interested in these bindings. I've got the basics of a library 
> forming, but
> there's a ton to do and help in the form of pull requests are very 
> very
> welcome. I could also use feedback on what's been done so far 
> (especially
> criticisms) as well as feature requests.
>>

Re: [Haskell-cafe] What class for splittable data / balanced-fold?

[Jan-Willem Maessen]

On Sat, Sep 28, 2013 at 1:09 PM, Ryan Newton  wrote:

> Hi all,
>
> We all know and love Data.Foldable and are familiar with left folds and
> right folds.  But what you want in a parallel program is a balanced fold
> over a tree.  Fortunately, many of our datatypes (Sets, Maps) actually ARE
> balanced trees.  Hmm, but how do we expose that?
>
> It seems like it would be nice to have a* standard class t*hat allows you
> to split a datatype into roughly even halves, until you get down to the
> leaves.  This goes along with Guy Steele's argument that we should use
> "append lists" as primitive rather than "cons-lists", and it's why we added 
> append-lists
> within the monad-par 
> library
> .
>

Interestingly, in my Fortress days we looked at both using a split-like
interface and at a more foldMap / reduce - like interface, and it seemed
like the latter worked better – it requires a lot less boilerplate for
controlling recursion, and better matches the fanout of whatever structure
you're actually using underneath.

So I'd just go with a hand-written Foldable instance here.

But I'd love to hear if you've come up with an application that requires
split itself, and that *isn't* zip.  I recall we decided zip was better
done with element-and-index iteration over one of the structures and
indexing into the other since most tree structures don't actually zip
properly anyway.

-Jan-Willem Maessen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: Partitionable goes somewhere + containers instances

[Edward Kmett]

I don't know that it belongs in the "standard" libraries, but there could
definitely be a package for something similar.

ConstraintKinds are a pretty hefty extension to throw at it, and the
signature written there prevents it from being used on ByteString, Text,
etc.

This can be implemented with much lighter weight types though!


class Partitionable t where
partition :: Int -> t -> [t]


Now ByteString, Text etc. can be instances and no real flexibility is lost,
as with the class associated constraint on the argument, you'd already
given up polymorphic recursion.

There still remain issues. partition is already established as the
filterthat returns both the matching and unmatching elements, so the
name is
wrong.

This is a generalization of Data.List.splitEvery, perhaps it is worth
seeing how many others can be generalized similarly and talk to Brent about
adding, say, a Data.Split module to his split package in the platform?

-Edward





On Sun, Sep 29, 2013 at 4:21 AM, Ryan Newton  wrote:

> 
>
> On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki  wrote:
>
>> I've got a Partitionable class that I've been using for this purpose:
>>
>> https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs
>>
>
> Mike -- Neat, that's a cool library!
>
> Edward --  ideally, where in the standard libraries should the
> Partitionable comonoid go?
>
> Btw, I'm not sure what the ideal return type for comappend is, given that
> it needs to be able to "bottom out".  Mike, our partition function's list
> return type seems more reasonable.  Or maybe something simple would be this:
>
> *class Partitionable t where*
> *  partition :: t -> Maybe (t,t)*
>
> That is, at some point its not worth splitting and returns Nothing, and
> you'd better be able to deal with the 't' directly.
>
> So what I really want is for the *containers package to please get some
> kind of Partitionable instances! * Johan & others, I would be happy to
> provide a patch if the class can be agreed on. This is important because
> currently the balanced tree structure of Data.Set/Map is an *amazing and
> beneficial property* that is *not* exposed at all through the API.
>For example, it would be great to have a parallel traverse_ for Maps
> and Sets in the Par monad.  The particular impetus is that our new and
> enhanced Par monad makes extensive use of Maps and Sets, both the pure,
> balanced ones, and lockfree/inplace ones based on concurrent skip lists:
>
> http://www.cs.indiana.edu/~rrnewton/haddock/lvish/
>
> Alternatively, it would be ok if there were a "Data.Map.Internal" module
> that exposed the Bin/Tip, but I assume people would rather have a clean
> Partitionable instance...
>
> Best,
>   -Ryan
>
>
> On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki  wrote:
>
>> I've got a Partitionable class that I've been using for this purpose:
>>
>>
>> https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs
>>
>> The function called "parallel" in the HLearn library will automatically
>> parallelize any homomorphism from a Partionable to a Monoid.  I
>> specifically use that to parallelize machine learning algorithms.
>>
>> I have two thoughts for better abstractions:
>>
>> 1)  This Partitionable class is essentially a comonoid.  By reversing the
>> arrows of mappend, we get:
>>
>> comappend :: a -> (a,a)
>>
>> By itself, this works well if the number of processors you have is a
>> power of two, but it needs some more fanciness to get things balanced
>> properly for other numbers of processors.  I bet there's another algebraic
>> structure that would capture these other cases, but I'm not sure what it is.
>>
>> 2) I'm working with parallelizing tree structures right now (kd-trees,
>> cover trees, oct-trees, etc.).  The real problem is not splitting the
>> number of data points equally (this is easy), but splitting the amount of
>> work equally.  Some points take longer to process than others, and this
>> cannot be determined in advance.  Therefore, an equal split of the data
>> points can result in one processor getting 25% of the work load, and the
>> second processor getting 75%.  Some sort of lazy Partitionable class that
>> was aware of processor loads and didn't split data points until they were
>> needed would be ideal for this scenario.
>>
>> On Sat, Sep 28, 2013 at 6:46 PM, adam vogt  wrote:
>>
>>> On Sat, Sep 28, 2013 at 1:09 PM, Ryan Newton  wrote:
>>> > Hi all,
>>> >
>>> > We all know and love Data.Foldable and are familiar with left folds and
>>> > right folds.  But what you want in a parallel program is a balanced
>>> fold
>>> > over a tree.  Fortunately, many of our datatypes (Sets, Maps) actually
>>> ARE
>>> > balanced trees.  Hmm, but how do we expose that?
>>>
>>> Hi Ryan,
>>>
>>> At least for Data.Map, the Foldable instance seems to have a
>>> reasonably balanced fold called fold (or foldMap):
>>>
>>> >  fold t = go t
>>> >where   go (Bin _ _ 

Re: [Haskell-cafe] Proposal: Partitionable goes somewhere + containers instances

[Milan Straka]

Hi Ryan,

> -Original message-
> From: Ryan Newton 
> Sent: 29 Sep 2013, 04:21
>
> 
>
> *class Partitionable t where*
> *  partition :: t -> Maybe (t,t)*
>
> 
> 
> So what I really want is for the *containers package to please get some
> kind of Partitionable instances! * Johan & others, I would be happy to
> provide a patch if the class can be agreed on. This is important because
> currently the balanced tree structure of Data.Set/Map is an *amazing and
> beneficial property* that is *not* exposed at all through the API.

Some comments:

1) containers are a boot package 
(http://ghc.haskell.org/trac/ghc/wiki/Commentary/Libraries)
   therefore its dependencies have to be boot packages too. If
   Partitionable gets into base or some other boot package, fine :)

2) IntMap/IntSet have different partitioning operation than Map/Set:
 partition :: IntMap a -> Either IntMap (IntMap a, IntMap)
  partition :: Map k v -> Either Map (Map, k, v, Map)
   Nevertheless, IntMap/IntSet are not well balanced, so maybe it would
   be fine to have partition working for Map/Set.

3) Partition somehow exposes internal structure, which forces us to only
   some implementations. Nevertheless, I doubt the representation of
   containers will change wildly (although I am planning to add data
   constructor to Map/Set shortly, so you never know).

It seems that the best course of action would be to ignore the
Partitionable class and instead provide methods in the containers to
allow splitting.

The question is how should the API look like. Currently IntMap and
IntSet are deliberately as close to Map and Set as possible. Introducing
this splitting operation would enlarge the difference between them.
But as noted, we could provide split only for Map and Set, as
IntMap/IntSet are not well balanced anyway.

Cheers,
Milan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: new function for lifting

[Bas van Dijk]

On 27 September 2013 21:51, Thiago Negri  wrote:
> Stop lifting, start using shinny operators like this one:
>
> (^$) :: Monad m => m a -> (a -> b -> c) -> m b -> m c
> (^$) = flip liftM2

Note that something like this is already provided by the
InfixApplicative library:

http://hackage.haskell.org/package/InfixApplicative
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Product Profunctor and Contravariant

[Tom Ellis]

Does anyone recognise these typeclasses:

import Data.Profunctor (Profunctor)
import Data.Functor.Contravariant (Contravariant)

class Profunctor p => ProductProfunctor p where
  empty :: p () ()
  (***!) :: p a b -> p a' b' -> p (a, a') (b, b')

class Contravariant f => ProductContravariant f where
  point :: f ()
  (***<) :: f a -> f b -> f (a, b)

They are both a bit like Applicative, and ProductProfunctor is basically
Arrow without the Category part.  I'm finding ProductProfunctor useful for
marshalling data from a database into Haskell, and both of them come up a
lot inside my database library.

Has anyone ever seen these before?  Has Edward Kmett written a library for
these already?  Thanks,

Tom
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal: Partitionable goes somewhere + containers instances

[Nicolas Trangez]

I'd think

partition :: t -> Either t (t, t)

might be more suited then...

Nicolas
On Sep 29, 2013 1:21 AM, "Ryan Newton"  wrote:

> 
>
> On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki  wrote:
>
>> I've got a Partitionable class that I've been using for this purpose:
>>
>> https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs
>>
>
> Mike -- Neat, that's a cool library!
>
> Edward --  ideally, where in the standard libraries should the
> Partitionable comonoid go?
>
> Btw, I'm not sure what the ideal return type for comappend is, given that
> it needs to be able to "bottom out".  Mike, our partition function's list
> return type seems more reasonable.  Or maybe something simple would be this:
>
> *class Partitionable t where*
> *  partition :: t -> Maybe (t,t)*
>
> That is, at some point its not worth splitting and returns Nothing, and
> you'd better be able to deal with the 't' directly.
>
> So what I really want is for the *containers package to please get some
> kind of Partitionable instances! * Johan & others, I would be happy to
> provide a patch if the class can be agreed on. This is important because
> currently the balanced tree structure of Data.Set/Map is an *amazing and
> beneficial property* that is *not* exposed at all through the API.
>For example, it would be great to have a parallel traverse_ for Maps
> and Sets in the Par monad.  The particular impetus is that our new and
> enhanced Par monad makes extensive use of Maps and Sets, both the pure,
> balanced ones, and lockfree/inplace ones based on concurrent skip lists:
>
> http://www.cs.indiana.edu/~rrnewton/haddock/lvish/
>
> Alternatively, it would be ok if there were a "Data.Map.Internal" module
> that exposed the Bin/Tip, but I assume people would rather have a clean
> Partitionable instance...
>
> Best,
>   -Ryan
>
>
> On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki  wrote:
>
>> I've got a Partitionable class that I've been using for this purpose:
>>
>>
>> https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs
>>
>> The function called "parallel" in the HLearn library will automatically
>> parallelize any homomorphism from a Partionable to a Monoid.  I
>> specifically use that to parallelize machine learning algorithms.
>>
>> I have two thoughts for better abstractions:
>>
>> 1)  This Partitionable class is essentially a comonoid.  By reversing the
>> arrows of mappend, we get:
>>
>> comappend :: a -> (a,a)
>>
>> By itself, this works well if the number of processors you have is a
>> power of two, but it needs some more fanciness to get things balanced
>> properly for other numbers of processors.  I bet there's another algebraic
>> structure that would capture these other cases, but I'm not sure what it is.
>>
>> 2) I'm working with parallelizing tree structures right now (kd-trees,
>> cover trees, oct-trees, etc.).  The real problem is not splitting the
>> number of data points equally (this is easy), but splitting the amount of
>> work equally.  Some points take longer to process than others, and this
>> cannot be determined in advance.  Therefore, an equal split of the data
>> points can result in one processor getting 25% of the work load, and the
>> second processor getting 75%.  Some sort of lazy Partitionable class that
>> was aware of processor loads and didn't split data points until they were
>> needed would be ideal for this scenario.
>>
>> On Sat, Sep 28, 2013 at 6:46 PM, adam vogt  wrote:
>>
>>> On Sat, Sep 28, 2013 at 1:09 PM, Ryan Newton  wrote:
>>> > Hi all,
>>> >
>>> > We all know and love Data.Foldable and are familiar with left folds and
>>> > right folds.  But what you want in a parallel program is a balanced
>>> fold
>>> > over a tree.  Fortunately, many of our datatypes (Sets, Maps) actually
>>> ARE
>>> > balanced trees.  Hmm, but how do we expose that?
>>>
>>> Hi Ryan,
>>>
>>> At least for Data.Map, the Foldable instance seems to have a
>>> reasonably balanced fold called fold (or foldMap):
>>>
>>> >  fold t = go t
>>> >where   go (Bin _ _ v l r) = go l `mappend` (v `mappend` go r)
>>>
>>> This doesn't seem to be guaranteed though. For example ghc's derived
>>> instance writes the foldr only, so fold would be right-associated for
>>> a:
>>>
>>> > data T a = B (T a) (T a) | L a deriving (Foldable)
>>>
>>> Regards,
>>> Adam
>>> ___
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>
>>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Proposal: Partitionable goes somewhere + containers instances

[Ryan Newton]

On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki  wrote:

> I've got a Partitionable class that I've been using for this purpose:
>
> https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs
>

Mike -- Neat, that's a cool library!

Edward --  ideally, where in the standard libraries should the
Partitionable comonoid go?

Btw, I'm not sure what the ideal return type for comappend is, given that
it needs to be able to "bottom out".  Mike, our partition function's list
return type seems more reasonable.  Or maybe something simple would be this:

*class Partitionable t where*
*  partition :: t -> Maybe (t,t)*

That is, at some point its not worth splitting and returns Nothing, and
you'd better be able to deal with the 't' directly.

So what I really want is for the *containers package to please get some
kind of Partitionable instances! * Johan & others, I would be happy to
provide a patch if the class can be agreed on. This is important because
currently the balanced tree structure of Data.Set/Map is an *amazing and
beneficial property* that is *not* exposed at all through the API.
   For example, it would be great to have a parallel traverse_ for Maps and
Sets in the Par monad.  The particular impetus is that our new and enhanced
Par monad makes extensive use of Maps and Sets, both the pure, balanced
ones, and lockfree/inplace ones based on concurrent skip lists:

http://www.cs.indiana.edu/~rrnewton/haddock/lvish/

Alternatively, it would be ok if there were a "Data.Map.Internal" module
that exposed the Bin/Tip, but I assume people would rather have a clean
Partitionable instance...

Best,
  -Ryan


On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki  wrote:

> I've got a Partitionable class that I've been using for this purpose:
>
>
> https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs
>
> The function called "parallel" in the HLearn library will automatically
> parallelize any homomorphism from a Partionable to a Monoid.  I
> specifically use that to parallelize machine learning algorithms.
>
> I have two thoughts for better abstractions:
>
> 1)  This Partitionable class is essentially a comonoid.  By reversing the
> arrows of mappend, we get:
>
> comappend :: a -> (a,a)
>
> By itself, this works well if the number of processors you have is a power
> of two, but it needs some more fanciness to get things balanced properly
> for other numbers of processors.  I bet there's another algebraic structure
> that would capture these other cases, but I'm not sure what it is.
>
> 2) I'm working with parallelizing tree structures right now (kd-trees,
> cover trees, oct-trees, etc.).  The real problem is not splitting the
> number of data points equally (this is easy), but splitting the amount of
> work equally.  Some points take longer to process than others, and this
> cannot be determined in advance.  Therefore, an equal split of the data
> points can result in one processor getting 25% of the work load, and the
> second processor getting 75%.  Some sort of lazy Partitionable class that
> was aware of processor loads and didn't split data points until they were
> needed would be ideal for this scenario.
>
> On Sat, Sep 28, 2013 at 6:46 PM, adam vogt  wrote:
>
>> On Sat, Sep 28, 2013 at 1:09 PM, Ryan Newton  wrote:
>> > Hi all,
>> >
>> > We all know and love Data.Foldable and are familiar with left folds and
>> > right folds.  But what you want in a parallel program is a balanced fold
>> > over a tree.  Fortunately, many of our datatypes (Sets, Maps) actually
>> ARE
>> > balanced trees.  Hmm, but how do we expose that?
>>
>> Hi Ryan,
>>
>> At least for Data.Map, the Foldable instance seems to have a
>> reasonably balanced fold called fold (or foldMap):
>>
>> >  fold t = go t
>> >where   go (Bin _ _ v l r) = go l `mappend` (v `mappend` go r)
>>
>> This doesn't seem to be guaranteed though. For example ghc's derived
>> instance writes the foldr only, so fold would be right-associated for
>> a:
>>
>> > data T a = B (T a) (T a) | L a deriving (Foldable)
>>
>> Regards,
>> Adam
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] What class for splittable data / balanced-fold?

[Mike Izbicki]

I've got a Partitionable class that I've been using for this purpose:

https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs

The function called "parallel" in the HLearn library will automatically
parallelize any homomorphism from a Partionable to a Monoid.  I
specifically use that to parallelize machine learning algorithms.

I have two thoughts for better abstractions:

1)  This Partitionable class is essentially a comonoid.  By reversing the
arrows of mappend, we get:

comappend :: a -> (a,a)

By itself, this works well if the number of processors you have is a power
of two, but it needs some more fanciness to get things balanced properly
for other numbers of processors.  I bet there's another algebraic structure
that would capture these other cases, but I'm not sure what it is.

2) I'm working with parallelizing tree structures right now (kd-trees,
cover trees, oct-trees, etc.).  The real problem is not splitting the
number of data points equally (this is easy), but splitting the amount of
work equally.  Some points take longer to process than others, and this
cannot be determined in advance.  Therefore, an equal split of the data
points can result in one processor getting 25% of the work load, and the
second processor getting 75%.  Some sort of lazy Partitionable class that
was aware of processor loads and didn't split data points until they were
needed would be ideal for this scenario.

On Sat, Sep 28, 2013 at 6:46 PM, adam vogt  wrote:

> On Sat, Sep 28, 2013 at 1:09 PM, Ryan Newton  wrote:
> > Hi all,
> >
> > We all know and love Data.Foldable and are familiar with left folds and
> > right folds.  But what you want in a parallel program is a balanced fold
> > over a tree.  Fortunately, many of our datatypes (Sets, Maps) actually
> ARE
> > balanced trees.  Hmm, but how do we expose that?
>
> Hi Ryan,
>
> At least for Data.Map, the Foldable instance seems to have a
> reasonably balanced fold called fold (or foldMap):
>
> >  fold t = go t
> >where   go (Bin _ _ v l r) = go l `mappend` (v `mappend` go r)
>
> This doesn't seem to be guaranteed though. For example ghc's derived
> instance writes the foldr only, so fold would be right-associated for
> a:
>
> > data T a = B (T a) (T a) | L a deriving (Foldable)
>
> Regards,
> Adam
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe