Re: [Haskell-cafe] containers license issue

[Chris Smith]

"Clint Adams"  wrote:
>
> On Wed, Dec 12, 2012 at 10:45:48PM -0500, Clark Gaebel wrote:
> > This is a silly issue.
>
> It certainly seems to be.  If it were serious, I'd like to think
> that people would be attempting to get actual legal advice
> instead of spouting anti-copyleft FUD.

Well, actual legal advice comes from actual lawyers, who often want actual
money.

I'm interested in what you saw as "anti-copyleft FUD" though.  That the
code might be subject to the GPL and that caused problems?  That's the only
thing that did come from a lawyer.  And it's really the only negative thing
I saw about the GPL in this thread.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can cabal be turned into a package manager?

[Rustom Mody]

On Thu, Dec 13, 2012 at 1:29 AM, Brandon Allbery wrote:

> On Wed, Dec 12, 2012 at 12:51 PM, Andre Cunha wrote:
>
>> Janek, did you mean something like Rubygems (http://rubygems.org)? It
>> manages the download, installation and manipulation of Ruby packages,
>> called "gems". A gem can contain executable programs or libraries (just
>> like traditional packages, like .rpm). Rubygems also handles dependencies
>> between gems, and allows you to update them.
>>
>
> But doesn't solve the actual problem;
>

Considering that this question is such a FAQ, I believe it would be
worthwhile discussing  what we think the 'actual problem' is.

When Algol-60 was being implemented, the challenge was how to compile using
only 2000 words of memory (or something as ridiculous as that). The
solution was to make a compiler with 20-odd passes.
[Sorry if the details are wrong; its from (neurological) memory]

Today not just compilers but databases are vying with each other to go back
from disk to memory -- hardly surprising considering that a vanilla machine
bought today has a TB of disk and GBs of memory.

In short the goal-posts shift with time and we need to readjust priorities
accordingly.

For myself if the total disk usage of my haskell-related installation were
to go up from being linear in the number of packages to quadratic, I am
unlikely to care.  Of course total naivete in package-management strategy
may make it exponential which would make me sit up!

Reminds me of a restatement/corollary to Moore's law I recently saw:
Programmers' cost increase exponentially with time.

Just alpha-rename 'programmer' to 'cabal-installer'


On Thu, Dec 13, 2012 at 12:19 AM, Ertugrul Söylemez  wrote:

> I'm afraid the burden is that you would have to write the necessary Nix
> expressions for your Haskell packages, so until we create a real Nix
> channel for Hackage the barrier to entry is high.  But it's certainly
> possible as a community project.
>
>
I believe you are saying something significant here. Here's my rendering of
it.

Currently we have a 'managed' hackage server talking to an unmanaged cabal
client (in the sense of
http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager
/  )

We need to move to hackage talking to a managed (as with nix) client.

So what work is needed to make this happen?

-- 
http://www.the-magus.in
http://blog.languager.org
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] containers license issue

[Clint Adams]

On Wed, Dec 12, 2012 at 10:45:48PM -0500, Clark Gaebel wrote:
> This is a silly issue.

It certainly seems to be.  If it were serious, I'd like to think
that people would be attempting to get actual legal advice
instead of spouting anti-copyleft FUD.

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

Re: [Haskell-cafe] containers license issue

[Clark Gaebel]

This is a silly issue.

I'd be willing to testify in court that that implementation was clean. If
such an issue were to ever come up, shoot me an email and I'll be there.
Until then, you're going to have to take my word for it. And honestly, we
do that with every bit of code we use every day. Do we really have anything
except the author's word that he hasn't copied some GPL code?

And, if it ever does come up and a real clean-room implementation (with
someone who's never seen FXT nor this thread) needs to be done, let me know
about that, too. I know lots of kids who'd jump at the chance for a
practice interview question.

I'll even do that now if Johan wants, but I doubt it's that useful. There
are bigger fish in the sea, and you're chasing a minnow.

Regards,
  - Clark


On Wed, Dec 12, 2012 at 8:53 PM, Johan Tibell wrote:

> On Wed, Dec 12, 2012 at 5:38 PM, Michael Orlitzky 
> wrote:
> > On 12/12/2012 08:15 PM, Johan Tibell wrote:
> >> On Wed, Dec 12, 2012 at 12:18 PM, Dmitry Kulagin
> >>  wrote:
> >>> Clark, Johan, thank you! That looks like perfect solution to the
> problem.
> >>
> >> Clean-room reimplementation merged and released as 0.5.2.0.
> >>
> >
> > Not even a little bit clean-room: he posted the source code that he was
> > going to reimplement like two hours earlier, and had obviously read it.
>
> Clean-room was clearly a bit over enthusiastic. He said he didn't use
> the other code as a reference but instead the bithacks reference,
> which is public domain. I'm comfortable enough with this. I wasn't
> particularly worried about the prior implementation either, as it
> don't think (as a non-lawyer) that it will hold up as copyrightable in
> court due to its trivial nature and the presence of prior art (this is
> a standard bit-twiddling algorithm).
>
> ___
> 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] containers license issue

[Johan Tibell]

On Wed, Dec 12, 2012 at 5:38 PM, Michael Orlitzky  wrote:
> On 12/12/2012 08:15 PM, Johan Tibell wrote:
>> On Wed, Dec 12, 2012 at 12:18 PM, Dmitry Kulagin
>>  wrote:
>>> Clark, Johan, thank you! That looks like perfect solution to the problem.
>>
>> Clean-room reimplementation merged and released as 0.5.2.0.
>>
>
> Not even a little bit clean-room: he posted the source code that he was
> going to reimplement like two hours earlier, and had obviously read it.

Clean-room was clearly a bit over enthusiastic. He said he didn't use
the other code as a reference but instead the bithacks reference,
which is public domain. I'm comfortable enough with this. I wasn't
particularly worried about the prior implementation either, as it
don't think (as a non-lawyer) that it will hold up as copyrightable in
court due to its trivial nature and the presence of prior art (this is
a standard bit-twiddling algorithm).

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

Re: [Haskell-cafe] containers license issue

[Michael Orlitzky]

On 12/12/2012 08:15 PM, Johan Tibell wrote:
> On Wed, Dec 12, 2012 at 12:18 PM, Dmitry Kulagin
>  wrote:
>> Clark, Johan, thank you! That looks like perfect solution to the problem.
> 
> Clean-room reimplementation merged and released as 0.5.2.0.
> 

Not even a little bit clean-room: he posted the source code that he was
going to reimplement like two hours earlier, and had obviously read it.

Did anyone consider just asking the original author if he cares?

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

Re: [Haskell-cafe] containers license issue

[Felipe Almeida Lessa]

Crisis averted!

=)

On Wed, Dec 12, 2012 at 11:15 PM, Johan Tibell  wrote:
> On Wed, Dec 12, 2012 at 12:18 PM, Dmitry Kulagin
>  wrote:
>> Clark, Johan, thank you! That looks like perfect solution to the problem.
>
> Clean-room reimplementation merged and released as 0.5.2.0.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



-- 
Felipe.

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

Re: [Haskell-cafe] containers license issue

[Johan Tibell]

On Wed, Dec 12, 2012 at 12:18 PM, Dmitry Kulagin
 wrote:
> Clark, Johan, thank you! That looks like perfect solution to the problem.

Clean-room reimplementation merged and released as 0.5.2.0.

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

Re: [Haskell-cafe] Control.bimap?

[Tony Morris]

Check out Control.Lens on hackage.

On 13/12/12 07:54, Gregory Guthrie wrote:
>
> I found a nice idiom for a graph algorithm where the pairs of nodes
> representing links could be merged into node lists by something like:
>
> ns = nub $ map fst  g--head nodes
>
> ne = nub $ map snd g   -- tail nodes
>
>  
>
> And found a nicer approach:
>
>(ns,ne) = (nub***nub) unzip g
>
> Or perhaps:
>
>(ns.ne) = bimap nub nub $ unzip g-- from Control.Bifunctor
>
>  
>
> The SO reference I saw described bimap as a way to map a function over
> a pair, and it seemed like a great match, but I cannot find the bimap
> function, and cabal reports no package Control.Bifunctor.
>
> ??
>
> ---
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe


-- 
Tony Morris
http://tmorris.net/

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

Re: [Haskell-cafe] Observer pattern in haskell FRP

[Nathan Hüsken]

On 12/12/2012 01:26 AM, Ertugrul Söylemez wrote:
> Nathan Hüsken  wrote:
> 
>>> Actually it is very scalable, as the same map is passed to every
>>> object. It can even live in the underlying monad, which means that
>>> you could even use a mutable vector, if you wish; however, I don't
>>> recommend that.
>>>
>>> Remember that a map is immutable and shared, so passing the same map
>>> to multiple objects is in fact the same as passing a pointer in
>>> C++. Lookups in and updates to the map are of logarithmic
>>> complexity, so this scales well.  Only doubling the number of nodes
>>> actually adds one full step to lookups and updates.
>>>
>>> If you're dealing with millions of objects you may want to use the
>>> vector solution mentioned earlier.  This requires an imperative
>>> underlying monad, but you would get about the same speed as in C++.
>>
>> I might just not be used enough to functional data structures, "Purely
>> functional data structures" is on my reading list :).
>>
>> I was thinking, in the asteroids example the only reason why the view
>> needs more input than the models output, is that it needs to be
>> informed of creation and destruction of asteroids.
> 
> Why would the view need to be informed?

So that the coresponding view objects can be removed (imidiatly or at
some later point).

> 
> 
>> So, in the model one could habe a signal
>>
>> asteroidsModel :: Signal Input [Just AsteroidModel]
>>
>> which outputs "Nothing" for asteroids that have been destroyed.
>> Then, in the view this would be taken for as input for
>>
>> asteroidsView :: Signal [Just AsteroidModel] [Picture]
>>
>> asteroidsView would have to do the following:
>> * route the input list to a list of "asteroidView" signals.
>> * When there is a "Nothing" in the input list, the corresponding (now
>> exploding) view is moved to a list of "zombie asteroids" where it
>> remains until its explosion animation is over.
>> * When the input list is longer than the list of current astroidView
>> signals, the list is extended.
>>
>> This would avoid the need for bookkeeping ids.
> 
> This is a very complicated way to do it.  I would simply regard the
> "zombie asteroids" as regular objects.  That way you don't need a
> special case in the view.

I was thinking by doing it this way I could completely avoid the need
for ids by this the bookkeeping of ids.
On the other hand, I might need the ids anyway for other things and than
my approach would just add complexity, as you said.

Regards,
Nathan


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

Re: [Haskell-cafe] Yesod double free or corruption

[Manuel Gómez]

On Wed, Dec 12, 2012 at 12:24 PM, Andras Gyomrey  wrote:
> Hi,
>
> i got the following error using "yesod devel" it happened after adding the
> file which seems to have invalid content (not true). What should i do?

The first bit of your error message indeed indicates
`./Handler/Model/Season.hs` isn’t encoded as `hGetContents` expects:

> yesod: ./Handler/Model/Season.hs: hGetContents: invalid argument (invalid 
> byte sequence)

`System.IO.hGetContents` converts into Unicode from the default
encoding configured in your system unless explicitly told otherwise
with `hSetEncoding`[1].  You can check what this encoding is with the
GHC primitive `GHC.IO.Encoding.getLocaleEncoding`[2], or with the
somewhat less reliable `System.IO.localeEncoding` runtime constant.

This StackOverflow answer has some good pointers on inference and
validation of file encoding: 

The simplest solution is, of course, to set your system encoding to
UTF‐8, and make sure your source code is encoded accordingly.  GNU
iconv is quite handy for encoding conversions.  Remember to tell your
editor to default to UTF‐8 in case it doesn’t detect the system
encoding — or better yet, switch to a better editor that does.

The heap corruption does indeed indicate a bug somewhere, though not
necessarily in Yesod code.  If I understand this correctly, the
exception is uncaught (and printed by the default uncaught exception
handler[4] that, in turn, calls `errorBelch` in the RTS[5]) and the
heap corruption becomes evident only later during the GHC runtime’s
cleanup, whatever that may be.

[1]: 

[2]: 

[3]: 

[4]: 

[5]: Lines 34 and 174–202 of  in the GHC source


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

Re: [Haskell-cafe] Control.bimap?

[Timo von Holtz]

Control.Categorical.Bifunctor and Data.Bifunctor are the module names
not the packages.
The corresponding packages are "categories" and "bifunctors" respectively.

2012/12/12 Gregory Guthrie :
> Yes, thanks, I've seen this; why can't cabal find the package?
>
> Is the fact that it is filed under "archive" an indicator?!
> I have tried Control.Bifunctor, and also Control.Categorical.Bifunctor, and 
> Data.Bifunctor.
>
> Certainly it is an easy thing to define myself, but I'm both trying to be 
> minimalistic, and to understand what failed.
> ---
> From: Clark Gaebel [mailto:cgae...@uwaterloo.ca]
> Sent: Wednesday, December 12, 2012 3:12 PM
> Subject: Re: [Haskell-cafe] Control.bimap?
>
> http://hackage.haskell.org/packages/archive/categories/0.59/doc/html/Control-Categorical-Bifunctor.html
> .
>  And found a nicer approach:
>(ns,ne) = (nub***nub) unzip g
> Or perhaps:
>(ns.ne) = bimap nub nub $ unzip g-- from Control.Bifunctor
>  The SO reference I saw described bimap as a way to map a function over a 
> pair, and it seemed like a great match, but I cannot find the bimap function, 
> and cabal reports no package Control.Bifunctor.
> ??
>
> ___
> 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] LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)

[Brandon Allbery]

On Wed, Dec 12, 2012 at 4:58 PM, Ramana Kumar wrote:

> Using it has the advantage of offering a reason to push those on the fence
> about whether to make their software free.
>

As has already been pointed out, definitions of "free" differ.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] containers license issue

[Johan Tibell]

On Wed, Dec 12, 2012 at 12:09 PM, Clark Gaebel  wrote:
> Possibly. I tend to trust GHC's strictness analyzer until proven otherwise,
> though. Feel free to optimize as necessary.

The GHC strictness analyzer will have no troubles with this. Since the
return type is Word64, there's no place for thunks to hide as Word64
is defined as:

data Word64 = W64# Word#  -- on 64-bit archs

or some such. Since Word# is unlifted it cannot be a pointer (to a thunk).

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

Re: [Haskell-cafe] LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)

[Ramana Kumar]

On Thu, Dec 13, 2012 at 5:36 AM, Felipe Almeida Lessa <
felipe.le...@gmail.com> wrote:

> A GPLed containers forces the library user to somehow get a way of
> complying to the license.
>

The language here needs some clarification: the GPL (or other free copyleft
license) only "forces" someone to do something under very particular
circumstances, which could be characterised as:
1. They are planning on distributing non-free software, and,
2. They haven't made a special agreement with the copyright holder.

I would hope that condition 1 does not hold for a large proportion of
library users.
Those users should not be scared away from copyleft.
Using it has the advantage of offering a reason to push those on the fence
about whether to make their software free.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Control.bimap?

[Gregory Guthrie]

Yes, thanks, I've seen this; why can't cabal find the package?

Is the fact that it is filed under "archive" an indicator?!
I have tried Control.Bifunctor, and also Control.Categorical.Bifunctor, and 
Data.Bifunctor.

Certainly it is an easy thing to define myself, but I'm both trying to be 
minimalistic, and to understand what failed.
--- 
From: Clark Gaebel [mailto:cgae...@uwaterloo.ca] 
Sent: Wednesday, December 12, 2012 3:12 PM
Subject: Re: [Haskell-cafe] Control.bimap?

http://hackage.haskell.org/packages/archive/categories/0.59/doc/html/Control-Categorical-Bifunctor.html
.
 And found a nicer approach:
   (ns,ne) = (nub***nub) unzip g
Or perhaps:
   (ns.ne) = bimap nub nub $ unzip g    -- from Control.Bifunctor 
 The SO reference I saw described bimap as a way to map a function over a pair, 
and it seemed like a great match, but I cannot find the bimap function, and 
cabal reports no package Control.Bifunctor.
??

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

Re: [Haskell-cafe] Control.bimap?

[Clark Gaebel]

Also,
http://hackage.haskell.org/packages/archive/bifunctors/3.0/doc/html/Data-Bifunctor.html


On Wed, Dec 12, 2012 at 4:12 PM, Clark Gaebel  wrote:

>
> http://hackage.haskell.org/packages/archive/categories/0.59/doc/html/Control-Categorical-Bifunctor.html
>
>
> On Wed, Dec 12, 2012 at 3:54 PM, Gregory Guthrie  wrote:
>
>> I found a nice idiom for a graph algorithm where the pairs of nodes
>> representing links could be merged into node lists by something like:
>>
>> ns = nub $ map fst  g--head nodes
>>
>> ne = nub $ map snd g   -- tail nodes
>>
>> ** **
>>
>> And found a nicer approach:
>>
>>(ns,ne) = (nub***nub) unzip g
>>
>> Or perhaps:
>>
>>(ns.ne) = bimap nub nub $ unzip g-- from Control.Bifunctor 
>>
>> ** **
>>
>> The SO reference I saw described bimap as a way to map a function over a
>> pair, and it seemed like a great match, but I cannot find the bimap
>> function, and cabal reports no package Control.Bifunctor.
>>
>> ??
>>
>> ---
>>
>> ___
>> 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] Control.bimap?

[Clark Gaebel]

http://hackage.haskell.org/packages/archive/categories/0.59/doc/html/Control-Categorical-Bifunctor.html


On Wed, Dec 12, 2012 at 3:54 PM, Gregory Guthrie  wrote:

> I found a nice idiom for a graph algorithm where the pairs of nodes
> representing links could be merged into node lists by something like:
>
> ns = nub $ map fst  g--head nodes
>
> ne = nub $ map snd g   -- tail nodes
>
> ** **
>
> And found a nicer approach:
>
>(ns,ne) = (nub***nub) unzip g
>
> Or perhaps:
>
>(ns.ne) = bimap nub nub $ unzip g-- from Control.Bifunctor 
>
> ** **
>
> The SO reference I saw described bimap as a way to map a function over a
> pair, and it seemed like a great match, but I cannot find the bimap
> function, and cabal reports no package Control.Bifunctor.
>
> ??
>
> ---
>
> ___
> 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] Control.bimap?

[Gregory Guthrie]

I found a nice idiom for a graph algorithm where the pairs of nodes 
representing links could be merged into node lists by something like:
ns = nub $ map fst  g--head nodes
ne = nub $ map snd g   -- tail nodes

And found a nicer approach:
   (ns,ne) = (nub***nub) unzip g
Or perhaps:
   (ns.ne) = bimap nub nub $ unzip g-- from Control.Bifunctor

The SO reference I saw described bimap as a way to map a function over a pair, 
and it seemed like a great match, but I cannot find the bimap function, and 
cabal reports no package Control.Bifunctor.
??
---
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] reviving HaNS (haskell network stack)

[Carter Schonwald]

wooops,
seems theres a galois repo on github here https://github.com/GaloisInc/HaNS




On Wed, Dec 12, 2012 at 3:04 PM, Carter Schonwald <
carter.schonw...@gmail.com> wrote:

> Hey All,
>
> I noticed that the really cool HaNS work
> (a mostly pure HS + bits of C networking stack)
> seems to have languished for quite some time, and the absence of a
> publicly visible repo certainly doesnt help!
>
> accordingly, i've taken the most recent code snapshot from the galois
> archive repo and created a copy on github!
>
> https://github.com/cartazio/HaNS
>
> I'll be having a go at trying to get things to build on ghc 7.6 + seeing
> about doing travisCI integration over the next few days, but if anyone else
> might be interested in helping out, that'd be welcome!
>
> cheers
> -Carter
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] containers license issue

[Dmitry Kulagin]

Clark, Johan, thank you! That looks like perfect solution to the problem.

12.12.2012, в 22:56, Johan Tibell  написал(а):

> On Wed, Dec 12, 2012 at 10:40 AM, Clark Gaebel  wrote:
>> I just did a quick derivation from
>> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 to get
>> the highest bit mask, and did not reference FXT nor the containers
>> implementation. Here is my code:
>>
>> highestBitMask :: Word64 -> Word64
>> highestBitMask x1 = let x2 = x1 .|. x1 `shiftR` 1
>>x3 = x2 .|. x2 `shiftR` 2
>>x4 = x3 .|. x3 `shiftR` 4
>>x5 = x4 .|. x4 `shiftR` 8
>>x6 = x5 .|. x5 `shiftR` 16
>>x7 = x6 .|. x6 `shiftR` 32
>> in x7 `xor` (x7 `shiftR` 1)
>>
>> This code is hereby released into the public domain. Problem solved.
>
> I will integrate this into containers later today.
>
> ___
> 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] containers license issue

[Clark Gaebel]

Possibly. I tend to trust GHC's strictness analyzer until proven otherwise,
though. Feel free to optimize as necessary.

  - Clark


On Wed, Dec 12, 2012 at 3:06 PM, Vo Minh Thu  wrote:

> 2012/12/12 Johan Tibell :
> > On Wed, Dec 12, 2012 at 10:40 AM, Clark Gaebel 
> wrote:
> >> I just did a quick derivation from
> >> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 to
> get
> >> the highest bit mask, and did not reference FXT nor the containers
> >> implementation. Here is my code:
> >>
> >> highestBitMask :: Word64 -> Word64
> >> highestBitMask x1 = let x2 = x1 .|. x1 `shiftR` 1
> >> x3 = x2 .|. x2 `shiftR` 2
> >> x4 = x3 .|. x3 `shiftR` 4
> >> x5 = x4 .|. x4 `shiftR` 8
> >> x6 = x5 .|. x5 `shiftR` 16
> >> x7 = x6 .|. x6 `shiftR` 32
> >>  in x7 `xor` (x7 `shiftR` 1)
> >>
> >> This code is hereby released into the public domain. Problem solved.
> >
> > I will integrate this into containers later today.
>
> Note that I think the current implementation use a series of case
> expression instead of a let binding, possibly to force the evaluation.
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] containers license issue

[Vo Minh Thu]

2012/12/12 Johan Tibell :
> On Wed, Dec 12, 2012 at 10:40 AM, Clark Gaebel  wrote:
>> I just did a quick derivation from
>> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 to get
>> the highest bit mask, and did not reference FXT nor the containers
>> implementation. Here is my code:
>>
>> highestBitMask :: Word64 -> Word64
>> highestBitMask x1 = let x2 = x1 .|. x1 `shiftR` 1
>> x3 = x2 .|. x2 `shiftR` 2
>> x4 = x3 .|. x3 `shiftR` 4
>> x5 = x4 .|. x4 `shiftR` 8
>> x6 = x5 .|. x5 `shiftR` 16
>> x7 = x6 .|. x6 `shiftR` 32
>>  in x7 `xor` (x7 `shiftR` 1)
>>
>> This code is hereby released into the public domain. Problem solved.
>
> I will integrate this into containers later today.

Note that I think the current implementation use a series of case
expression instead of a let binding, possibly to force the evaluation.

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

[Haskell-cafe] reviving HaNS (haskell network stack)

[Carter Schonwald]

Hey All,

I noticed that the really cool HaNS work
(a mostly pure HS + bits of C networking stack)
seems to have languished for quite some time, and the absence of a publicly
visible repo certainly doesnt help!

accordingly, i've taken the most recent code snapshot from the galois
archive repo and created a copy on github!

https://github.com/cartazio/HaNS

I'll be having a go at trying to get things to build on ghc 7.6 + seeing
about doing travisCI integration over the next few days, but if anyone else
might be interested in helping out, that'd be welcome!

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

Re: [Haskell-cafe] Can cabal be turned into a package manager?

[Brandon Allbery]

On Wed, Dec 12, 2012 at 12:51 PM, Andre Cunha wrote:

> Janek, did you mean something like Rubygems (http://rubygems.org)? It
> manages the download, installation and manipulation of Ruby packages,
> called "gems". A gem can contain executable programs or libraries (just
> like traditional packages, like .rpm). Rubygems also handles dependencies
> between gems, and allows you to update them.
>

But doesn't solve the actual problem; Ruby programmers use RVM (think
virthualenv) religiously to avoid "gem hell", and every Ruby project
effectively has its own Ruby installation as a result.  Indeed, gem
managers mostly expect you to be installing into private RVM sandboxes.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Large, numerical calculations in Haskell

[Carter Schonwald]

Emil, there is an actively maintained set of FFTW bindings on hackage,
would that help you?

cheers
-Carter


On Wed, Dec 12, 2012 at 5:03 AM, Emil Hedevang wrote:

> Hi A.M. and Dominic,
>
> I have been following the development of Repa for some time, mostly
> reading blogs and papers about it, not actually writing any code. It's some
> quite cool stuff the developers are doing.
>
> A discrete convolution is a stencil computation. There are (to my
> knowledge) essentially two approaches to calculate a discrete convolutions
> Y = K * X:
> (1) from the definition, and
> (2) using discrete Fourier transforms
>
> Approach no. 1 runs in O(nK nX) where nK and nX are the number of elements
> in the arrays K and X, respectively, whereas approach no. 2 runs in O(nX
> log nX). If nK is very, very small, then approach no. 1 is fastest,
> otherwise approach no. 2 is fastest. If nK is somewhat smaller than nX,
> then some tricks can be applied to obtain something a bit faster than
> approach no. 2.
>
> To my knowledge, Repa applies approach no. 1 in its stencil computations
> and discrete convolutions. Therefore it cannot be applied in my case, since
> I have nK = 10^6 and nX = 10^9 (or something similar), and so I must use
> approach no. 2 with discrete Fourier transforms (DFT). In Repa, the DFT for
> arbitrary array sizes is implemented using the slow O(n^2) algorithm, i.e.,
> implemented using the definition of the DFT. If the size of the array is a
> power of two, then the DFT is implemented using the fast Fourier transform
> (FFT). Unfortunately, the Repa documentation states that the Repa FFT is
> approximately 50 times slower than the FFT from FFTW. (And the FFT from
> FFTW is even capable of calculating fast DFTs of arbitrary size). This
> essentially forces my to use FFTW for the actual number crunching.
>
> I suppose it would be a very interesting research project to implement
> FFTW entirely in Haskell. Unfortunately, I currently do not have the time
> to embark on such a quest.
>
> Regarding the generation of random numbers, Repa implements what they call
> a minimal standard Lehmer generator. I am not sure if that random number
> generator is of high enough qualify for my needs.
>
> Cheers,
> Emil
>
>
> On 12 December 2012 10:15, Dominic Steinitz  wrote:
>
>> Emil Hedevang  gmail.com> writes:
>>
>> >
>> >
>> > Hi Haskell Cafe,
>> >
>> > I need to perform very large numerical computations requiring tens of
>> GB of
>> memory. The computations consist essentially of generation of random
>> numbers
>> and discrete convolutions of large arrays of random numbers with somewhat
>> smaller kernel arrays. Should I use Haskell and call some C libraries when
>> necessary? Should I just write everything in C? Or should I use e.g.
>> Chapel
>> (chapel.cray.com)?
>> >
>> >
>> Hi Emil,
>>
>> The first place I would look would be repa http://repa.ouroborus.net/.
>> IIRC it
>> supports discrete convolutions and repa folks seem quite responsive.
>>
>> Dominic.
>>
>> PS I am planning to use repa to solve PDEs and address, at least
>> partially, "the curse of dimensionality" with it.
>>
>>
>>
>>
>> ___
>> 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

Re: [Haskell-cafe] containers license issue

[Johan Tibell]

On Wed, Dec 12, 2012 at 10:40 AM, Clark Gaebel  wrote:
> I just did a quick derivation from
> http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 to get
> the highest bit mask, and did not reference FXT nor the containers
> implementation. Here is my code:
>
> highestBitMask :: Word64 -> Word64
> highestBitMask x1 = let x2 = x1 .|. x1 `shiftR` 1
> x3 = x2 .|. x2 `shiftR` 2
> x4 = x3 .|. x3 `shiftR` 4
> x5 = x4 .|. x4 `shiftR` 8
> x6 = x5 .|. x5 `shiftR` 16
> x7 = x6 .|. x6 `shiftR` 32
>  in x7 `xor` (x7 `shiftR` 1)
>
> This code is hereby released into the public domain. Problem solved.

I will integrate this into containers later today.

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

Re: [Haskell-cafe] Can cabal be turned into a package manager?

[Ertugrul Söylemez]

Rustom Mody  wrote:

> On Wed, Dec 12, 2012 at 11:25 PM, Ertugrul Söylemez 
> wrote:
>
> > "Janek S."  wrote:
> >
> > > In the recent months there was a lot of dicussion about cabal,
> > > dependency hell and alike. After reading some of these discussions
> > > there is a question I just have to ask:
> > >
> > > Why not create a package manager (like rpm or apt) for Haskell
> > > software?
> >
> > There is no need to reinvent that.  See below.
> >
> >
> > > I've been using Linux for years. Software for Linux is mostly
> > > written in C and C++. There are thousands of libraries with lots
> > > of dependencies and yet: a) Linux distributions manage to have
> > > package repositories that are kept in a consistent state b) Linux
> > > package managers can avoid dependency hell, automatically update
> > > to new packages, etc. Linux people did it! Is there any technical
> > > issue that prevents Haskell people from doing exactly the same
> > > thing? Or are we just having non-technical problems like lack of
> > > money or developers?
> >
> > Actually Linux distributions do all the hard work for you.  Package
> > maintainers know what I'm talking about.  It's a difficult task to
> > specify correct dependencies, tedious to negotiate with all the
> > other developers and all in all provide a consistent system.  But
> > that's only half of the story.
> >
> > The problem starts with the File Hierarchy Standard (FHS), which
> > essentially doesn't allow you to employ a more useful concept.
> > That's why an experimental (yet quite usable) Linux distribution
> > called NixOS [1] has established.  It recognizes the problems of the
> > FHS.  The solution is simple and radical:  the FHS sucks, so ignore
> > it.
> >
> > NixOS uses the Nix package manager, which you can also use for your
> > Haskell packages to escape from the dependency hell.  With Nix you
> > can even allow all users to install arbitrary packages without
> > interfering with other users, even the same packages with different
> > versions.  Two programs can depend on different versions of the same
> > library, etc. It's the package manager of the future.  Unfortunately
> > the concept is new and different enough that it will be difficult to
> > convince a large portion of the Linux community to employ it.  It's
> > the same issue Haskell has in the programming language world.
> >
> > There is no need to switch to NixOS to use Nix.  You can even
> > install it in your home directory.
> >
> > [1]: http://nixos.org/
>
> Thanks Ertugrul for mentioning nix.  My initial study of nix looked
> very promising as a solution to cabal-hell[2] but it seemed to suggest
> that one needs to change the whole OS!
>
> I must say that I am still dilly-dallying between cabal-dev
> virthualenv and nix and would appreciate a push!

I'm afraid the burden is that you would have to write the necessary Nix
expressions for your Haskell packages, so until we create a real Nix
channel for Hackage the barrier to entry is high.  But it's certainly
possible as a community project.

By the way, the Nix expressions can be derived from the Cabal
descriptions, at least for packages with the build type "Simple".  Even
for more complicated packages it should be very well possible.


> [2] I believe that saying cabal-hell is part of the problem with
> cabal-hell.  A more correct phrase may be
> "Haskell-has-no-standardized-package-manager-hell" (which is a bit
> long!)

It's commonly referred to as the "dependency hell".


Greets,
Ertugrul

-- 
Key-ID: E5DD8D11 "Ertugrul Soeylemez "
FPrint: BD28 3E3F BE63 BADD 4157  9134 D56A 37FA E5DD 8D11
Keysrv: hkp://subkeys.pgp.net/


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

Re: [Haskell-cafe] containers license issue

[Clark Gaebel]

I just did a quick derivation from
http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 to get
the highest bit mask, and did not reference FXT nor the containers
implementation. Here is my code:

highestBitMask :: Word64 -> Word64
highestBitMask x1 = let x2 = x1 .|. x1 `shiftR` 1
x3 = x2 .|. x2 `shiftR` 2
x4 = x3 .|. x3 `shiftR` 4
x5 = x4 .|. x4 `shiftR` 8
x6 = x5 .|. x5 `shiftR` 16
x7 = x6 .|. x6 `shiftR` 32
 in x7 `xor` (x7 `shiftR` 1)

This code is hereby released into the public domain. Problem solved.

  - Clark


On Wed, Dec 12, 2012 at 12:23 PM, Mike Meyer  wrote:

> Niklas Larsson  wrote:
> >2012/12/12 Niklas Larsson :
> >>
> >> There is no copied code from FXT (which can be said with certainty as
> >> FXT is a C library), hence the there can be copyright issue.
> >Gah, I should proofread! NO copyright issue, of course.
>
> Um, no. Copyright *includes* translations. A translated copy of a work is
> based on the original and requires copyright permissions. This makes it a
> modified work according to the definitions in the GPL.
>
> You're all thinking about this as if logic and the law had something in
> common. The relevant question isn't  whether or not the GPL applies, but
> whether or not a case can be made that the GPL should apply. Clearly, that
> case can be made, so if you include the containers code without treating it
> as GPL'ed, you risk winding up in court. I suspect that's what the lawyer
> is really trying to avoid, as it would mean they'd actually have to work.
> --
> Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
>
> ___
> 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] Can cabal be turned into a package manager?

[Rustom Mody]

On Wed, Dec 12, 2012 at 11:25 PM, Ertugrul Söylemez  wrote:

> "Janek S."  wrote:
>
> > In the recent months there was a lot of dicussion about cabal,
> > dependency hell and alike. After reading some of these discussions
> > there is a question I just have to ask:
> >
> > Why not create a package manager (like rpm or apt) for Haskell
> > software?
>
> There is no need to reinvent that.  See below.
>
>
> > I've been using Linux for years. Software for Linux is mostly written
> > in C and C++. There are thousands of libraries with lots of
> > dependencies and yet: a) Linux distributions manage to have package
> > repositories that are kept in a consistent state b) Linux package
> > managers can avoid dependency hell, automatically update to new
> > packages, etc. Linux people did it! Is there any technical issue that
> > prevents Haskell people from doing exactly the same thing? Or are we
> > just having non-technical problems like lack of money or developers?
>
> Actually Linux distributions do all the hard work for you.  Package
> maintainers know what I'm talking about.  It's a difficult task to
> specify correct dependencies, tedious to negotiate with all the other
> developers and all in all provide a consistent system.  But that's only
> half of the story.
>
> The problem starts with the File Hierarchy Standard (FHS), which
> essentially doesn't allow you to employ a more useful concept.  That's
> why an experimental (yet quite usable) Linux distribution called NixOS
> [1] has established.  It recognizes the problems of the FHS.  The
> solution is simple and radical:  the FHS sucks, so ignore it.
>
> NixOS uses the Nix package manager, which you can also use for your
> Haskell packages to escape from the dependency hell.  With Nix you can
> even allow all users to install arbitrary packages without interfering
> with other users, even the same packages with different versions.  Two
> programs can depend on different versions of the same library, etc.
> It's the package manager of the future.  Unfortunately the concept is
> new and different enough that it will be difficult to convince a large
> portion of the Linux community to employ it.  It's the same issue
> Haskell has in the programming language world.
>
> There is no need to switch to NixOS to use Nix.  You can even install it
> in your home directory.
>
> [1]: http://nixos.org/
>

Thanks Ertugrul for mentioning nix.  My initial study of nix looked very
promising as a solution to cabal-hell[2] but it seemed to suggest that one
needs to change the whole OS!

I must say that I am still dilly-dallying between cabal-dev virthualenv and
nix and would appreciate a push!

[2] I believe that saying cabal-hell is part of the problem with
cabal-hell.  A more correct phrase may be
"Haskell-has-no-standardized-package-manager-hell" (which is a bit long!)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)

[Felipe Almeida Lessa]

When deciding what license to use, I think one should also think about
the role of their library.  For example, containers is quite central
to the Haskell community and not easily replaceable.  The tie-knot
library, OTOH, may be rewritten from scratch or even just skipped
(just tie the knot yourself).  A GPLed containers forces the library
user to somehow get a way of complying to the license.  A GPLed
tie-knot, OTOH, may be just ignored.

What I'm trying to say is that if your library is nice but someone may
just rewrite it without much effort, then using GPL will just drive
potential users of your library away, which is bad not just for the
library but also for those potential users as well.  Perhaps you have
a nice library but it may be replaced (with some small pain) by
another, similar library.

(In particular, I'm not saying that tie-knot is a library that should
be ignored.  On the contrary, I think it's quite nice and it would be
a shame if I had to ignore it when tying a knot just because of its
restrictive license.)

Of course, if everything on Hackage was GPLed, then it wouldn't make
sense to release something as BSD as you wouldn't be able to use it
anyway.  But the reality right now is that we have:

("Apache",3)
("BSD3",3359)
("BSD4",3)
("MIT",269)
("PublicDomain",142)

("GPL",409)
("GPL-2",27)
("GPL-3",147)
("LGPL",138)
("LGPL-2",2)
("LGPL-2.1",25)
("LGPL-3",21)

("OtherLicense",179)

This data comes from a quick shell session while considering the
latest .cabal of all Hackage packages, so take it with a grain of salt
=).

Cheers,

On Wed, Dec 12, 2012 at 2:12 PM, Jonathan Fischer Friberg
 wrote:
> +1
>
> Very similar to my point (see original thread), but put in a better way. :)
> As an interesting coincidence, this exact thing happened to someone
> just now. (thread "containers license issue")
>
> Jonathan
>
> On Wed, Dec 12, 2012 at 5:00 PM, Clark Gaebel  wrote:
>> Since we've already heard from the aggressive (L)GPL side of this "debate",
>> I think it's time for someone to provide the opposite opinion.
>>
>> I write code to help users. However, as a library designer, my users are
>> programmers just like me. Writing my Haskell libraries with restrictions
>> like the (L)GPL means my users need to jump through hoops to use my
>> software, and I personally find that unacceptable. Therefore, I gravitate
>> more towards BSD3 and "beer-ware" type licenses. This also means my users
>> aren't subjected to my religious views just because they want to use my
>> "ones and zeros".
>>
>> Also, with GHC's aggressive inlining, even if you do have a static linking
>> exception in your (L)GPL license, it still may not hold up! Although the
>> entire idea is untested in court, GHC can (and will!) inline potentially
>> huge parts of statically linked libraries into your code, and this would
>> force you to break the license terms if you were to distribute the software
>> without source code. In Haskell-land, the GPL is the ultimate in viral
>> licensing, and very hard to escape.
>>
>> That's why I don't use (L)GPL licenses.
>>
>> Just making sure both sides have a horse in this race :)
>>   - Clark
>>
>>
>> On Wed, Dec 12, 2012 at 9:51 AM, kudah  wrote:
>>>
>>> On Wed, 12 Dec 2012 10:06:23 +0100 Petr P  wrote:
>>>
>>> > 2012/12/12 David Thomas 
>>> >
>>> > Yet another solution would be
>>> > what David Thomas suggest: To provide the source code to your users,
>>> > but don't allow them to use the code for anything but relinking the
>>> > program with a different version of the library (no distribution, no
>>> > modification etc.).
>>>
>>> You can also provide object code for linking, though I'm sure this
>>> will not work with Haskell object files. Providing alternative
>>> distribution of your program linked dynamically, or a promise to
>>> provide one on notice, also satisfies the LGPL as long as
>>> dynamic-version is as functional as the static and can be dropped-in
>>> as a replacement.
>>>
>>> ___
>>> 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



-- 
Felipe.

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

Re: [Haskell-cafe] Can cabal be turned into a package manager?

[Ertugrul Söylemez]

"Janek S."  wrote:

> In the recent months there was a lot of dicussion about cabal,
> dependency hell and alike. After reading some of these discussions
> there is a question I just have to ask:
>
> Why not create a package manager (like rpm or apt) for Haskell
> software?

There is no need to reinvent that.  See below.


> I've been using Linux for years. Software for Linux is mostly written
> in C and C++. There are thousands of libraries with lots of
> dependencies and yet: a) Linux distributions manage to have package
> repositories that are kept in a consistent state b) Linux package
> managers can avoid dependency hell, automatically update to new
> packages, etc. Linux people did it! Is there any technical issue that
> prevents Haskell people from doing exactly the same thing? Or are we
> just having non-technical problems like lack of money or developers?

Actually Linux distributions do all the hard work for you.  Package
maintainers know what I'm talking about.  It's a difficult task to
specify correct dependencies, tedious to negotiate with all the other
developers and all in all provide a consistent system.  But that's only
half of the story.

The problem starts with the File Hierarchy Standard (FHS), which
essentially doesn't allow you to employ a more useful concept.  That's
why an experimental (yet quite usable) Linux distribution called NixOS
[1] has established.  It recognizes the problems of the FHS.  The
solution is simple and radical:  the FHS sucks, so ignore it.

NixOS uses the Nix package manager, which you can also use for your
Haskell packages to escape from the dependency hell.  With Nix you can
even allow all users to install arbitrary packages without interfering
with other users, even the same packages with different versions.  Two
programs can depend on different versions of the same library, etc.
It's the package manager of the future.  Unfortunately the concept is
new and different enough that it will be difficult to convince a large
portion of the Linux community to employ it.  It's the same issue
Haskell has in the programming language world.

There is no need to switch to NixOS to use Nix.  You can even install it
in your home directory.

[1]: http://nixos.org/


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


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

Re: [Haskell-cafe] Can cabal be turned into a package manager?

[Andre Cunha]

Hi. I'm new here, so this may not be a good suggestion.

Janek, did you mean something like Rubygems (http://rubygems.org)? It
manages the download, installation and manipulation of Ruby packages,
called "gems". A gem can contain executable programs or libraries (just
like traditional packages, like .rpm). Rubygems also handles dependencies
between gems, and allows you to update them.

About multiple versions of the same gem: there is a gem called Bundler (
http://gembundler.com)? It allows you to create a Gemfile for your project,
describing which gem and which version you need for your project to run.
When you enter the command:

$ bundle install

It installs the required versions of the required gems, specified in your
Gemfile. When you run:

$ bundle exec 

It runs the  using the specified version of each gem. So, you can
keep multiple versions of the gems, and choose which one to use in a
particular project.


On 12 December 2012 15:16, Bardur Arantsson  wrote:

> On 12/12/2012 06:01 PM, Janek S. wrote:
> > In the recent months there was a lot of dicussion about cabal,
> dependency hell and alike. After
> > reading some of these discussions there is a question I just have to ask:
> >
> > Why not create a package manager (like rpm or apt) for Haskell software?
> >
> > I've been using Linux for years. Software for Linux is mostly written in
> C and C++. There are
> > thousands of libraries with lots of dependencies and yet:
> > a) Linux distributions manage to have package repositories that are kept
> in a consistent state
> > b) Linux package managers can avoid dependency hell, automatically
> update to new packages, etc.
> > Linux people did it! Is there any technical issue that prevents Haskell
> people from doing exactly
> > the same thing? Or are we just having non-technical problems like lack
> of money or developers?
> >
>
> Well, one big issue is that Linux distribution packagers have control of
> the entire stack. A (hypothetical) Haskell package manager wouldn't.
>
> Typical package managers also restrict you to exactly one version of any
> given package. This can be a severe limitation for developers.
>
> (There are more issues.)
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



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

Re: [Haskell-cafe] How is default method signatures supposed to be used together with Generics

[Johan Tibell]

On Tue, Dec 11, 2012 at 9:31 PM, dag.odenh...@gmail.com
 wrote:
> The practice seems to be to not export it, but maybe it would be a better
> practice to export it. That way it can work without DefaultSignatures too,
> and if you use the generic-deriving package it could work with zero
> extensions or GHC-specific dependencies.
>
> Are you adding support to hashable after all? I'd love that, but thought you
> decided against it because of the clash with the existing defaults.

We did a major redesign of the library (without affecting users much).
This meant that hash became a top-level function and hashWithSalt the
only method of the Hashable class. As it's now the only method we
don't have a default implementation for it anymore (except the default
method signature).

-- Johan

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

Re: [Haskell-cafe] containers license issue

[Mike Meyer]

Niklas Larsson  wrote:
>2012/12/12 Niklas Larsson :
>>
>> There is no copied code from FXT (which can be said with certainty as
>> FXT is a C library), hence the there can be copyright issue.
>Gah, I should proofread! NO copyright issue, of course.

Um, no. Copyright *includes* translations. A translated copy of a work is based 
on the original and requires copyright permissions. This makes it a modified 
work according to the definitions in the GPL.

You're all thinking about this as if logic and the law had something in common. 
The relevant question isn't  whether or not the GPL applies, but whether or not 
a case can be made that the GPL should apply. Clearly, that case can be made, 
so if you include the containers code without treating it as GPL'ed, you risk 
winding up in court. I suspect that's what the lawyer is really trying to 
avoid, as it would mean they'd actually have to work.
-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.

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

Re: [Haskell-cafe] Can cabal be turned into a package manager?

[Bardur Arantsson]

On 12/12/2012 06:01 PM, Janek S. wrote:
> In the recent months there was a lot of dicussion about cabal, dependency 
> hell and alike. After 
> reading some of these discussions there is a question I just have to ask:
> 
> Why not create a package manager (like rpm or apt) for Haskell software?
> 
> I've been using Linux for years. Software for Linux is mostly written in C 
> and C++. There are 
> thousands of libraries with lots of dependencies and yet:
> a) Linux distributions manage to have package repositories that are kept in a 
> consistent state
> b) Linux package managers can avoid dependency hell, automatically update to 
> new packages, etc.
> Linux people did it! Is there any technical issue that prevents Haskell 
> people from doing exactly 
> the same thing? Or are we just having non-technical problems like lack of 
> money or developers?
> 

Well, one big issue is that Linux distribution packagers have control of
the entire stack. A (hypothetical) Haskell package manager wouldn't.

Typical package managers also restrict you to exactly one version of any
given package. This can be a severe limitation for developers.

(There are more issues.)



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

Re: [Haskell-cafe] Can cabal be turned into a package manager?

[Scott Lawrence]

On Wed, 12 Dec 2012, Janek S. wrote:

In the recent months there was a lot of dicussion about cabal, dependency 
hell and alike. After reading some of these discussions there is a question 
I just have to ask:


Why not create a package manager (like rpm or apt) for Haskell software?

I've been using Linux for years. Software for Linux is mostly written in C 
and C++. There are thousands of libraries with lots of dependencies and yet: 
a) Linux distributions manage to have package repositories that are kept in 
a consistent state b) Linux package managers can avoid dependency hell, 
automatically update to new packages, etc. Linux people did it! Is there any 
technical issue that prevents Haskell people from doing exactly the same 
thing? Or are we just having non-technical problems like lack of money or 
developers?


Linux package managers are so "good" at avoiding dependency hell because they 
don't have to - they fetch only from repositories that are carefully 
maintained and tested by humans, in a centralized fashion. The problem of 
handling dependencies in a purely automated fashion, with no concerted human 
effort, isn't solved by any of the major linux distros AFAIK.


Which isn't to say that I think it can't be solved; just that I don't know of 
any shining star we can use as an example.


(Incidentally, many linux distros package cabal packages with the same 
centralized-testing methodology under their own package repos, and it avoids 
dependency hell quite nicely. But I think there ought to be a better 
solution.)




Janek

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



--
Scott Lawrence

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

[Haskell-cafe] Can cabal be turned into a package manager?

[Janek S.]

In the recent months there was a lot of dicussion about cabal, dependency hell 
and alike. After 
reading some of these discussions there is a question I just have to ask:

Why not create a package manager (like rpm or apt) for Haskell software?

I've been using Linux for years. Software for Linux is mostly written in C and 
C++. There are 
thousands of libraries with lots of dependencies and yet:
a) Linux distributions manage to have package repositories that are kept in a 
consistent state
b) Linux package managers can avoid dependency hell, automatically update to 
new packages, etc.
Linux people did it! Is there any technical issue that prevents Haskell people 
from doing exactly 
the same thing? Or are we just having non-technical problems like lack of money 
or developers?

Janek

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

[Haskell-cafe] Yesod double free or corruption

[Andras Gyomrey]

Hi,

i got the following error using "yesod devel" it happened after adding the
file which seems to have invalid content (not true). What should i do?

Andras Gyomrey
Yesod devel server. Press ENTER to quit
yesod: ./Handler/Model/Season.hs: hGetContents: invalid argument (invalid byte 
sequence)
*** glibc detected *** yesod: double free or corruption (out): 
0x2b5fe0006b10 ***
=== Backtrace: =
/lib64/libc.so.6(+0x75916)[0x2b5fda07b916]
/lib64/libc.so.6(+0x78443)[0x2b5fda07e443]
/lib64/libc.so.6(+0x203c6)[0x2b5fda0263c6]
/lib64/libc.so.6(iconv_close+0xf)[0x2b5fda02595f]
yesod[0x317d93a]
=== Memory map: 
0040-035a6000 r-xp  00:1b 112951588  
/home/paxer/.cabal/bin/yesod
037a5000-03bc1000 rwxp 031a5000 00:1b 112951588  
/home/paxer/.cabal/bin/yesod
03bc1000-03bca000 rwxp 03bc1000 00:00 0
05e7f000-05ec1000 rwxp 05e7f000 00:00 0  [heap]
2b5fd8ec1000-2b5fd8ee1000 r-xp  00:1b 99617724   
/lib64/ld-2.12.so
2b5fd8eef000-2b5fd8ef rwxp 2b5fd8eef000 00:00 0
2b5fd90e-2b5fd90e1000 r-xp 0001f000 00:1b 99617724   
/lib64/ld-2.12.so
2b5fd90e1000-2b5fd90e2000 rwxp 0002 00:1b 99617724   
/lib64/ld-2.12.so
2b5fd90e2000-2b5fd90e3000 rwxp 2b5fd90e2000 00:00 0
2b5fd90e3000-2b5fd90f8000 r-xp  00:1b 99617828   
/lib64/libz.so.1.2.3
2b5fd90f8000-2b5fd92f7000 ---p 00015000 00:1b 99617828   
/lib64/libz.so.1.2.3
2b5fd92f7000-2b5fd92f8000 r-xp 00014000 00:1b 99617828   
/lib64/libz.so.1.2.3
2b5fd92f8000-2b5fd92f9000 rwxp 00015000 00:1b 99617828   
/lib64/libz.so.1.2.3
2b5fd92f9000-2b5fd930 r-xp  00:1b 99628779   
/lib64/librt-2.12.so
2b5fd930-2b5fd94ff000 ---p 7000 00:1b 99628779   
/lib64/librt-2.12.so
2b5fd94ff000-2b5fd950 r-xp 6000 00:1b 99628779   
/lib64/librt-2.12.so
2b5fd950-2b5fd9501000 rwxp 7000 00:1b 99628779   
/lib64/librt-2.12.so
2b5fd9501000-2b5fd9503000 r-xp  00:1b 99625968   
/lib64/libutil-2.12.so
2b5fd9503000-2b5fd9702000 ---p 2000 00:1b 99625968   
/lib64/libutil-2.12.so
2b5fd9702000-2b5fd9703000 r-xp 1000 00:1b 99625968   
/lib64/libutil-2.12.so
2b5fd9703000-2b5fd9704000 rwxp 2000 00:1b 99625968   
/lib64/libutil-2.12.so
2b5fd9704000-2b5fd9705000 rwxp 2b5fd9704000 00:00 0
2b5fd9705000-2b5fd9707000 r-xp  00:1b 99623838   
/lib64/libdl-2.12.so
2b5fd9707000-2b5fd9907000 ---p 2000 00:1b 99623838   
/lib64/libdl-2.12.so
2b5fd9907000-2b5fd9908000 r-xp 2000 00:1b 99623838   
/lib64/libdl-2.12.so
2b5fd9908000-2b5fd9909000 rwxp 3000 00:1b 99623838   
/lib64/libdl-2.12.so
2b5fd9909000-2b5fd995f000 r-xp  00:1b 99624917   
/usr/lib64/libgmp.so.3.5.0
2b5fd995f000-2b5fd9b5f000 ---p 00056000 00:1b 99624917   
/usr/lib64/libgmp.so.3.5.0
2b5fd9b5f000-2b5fd9b64000 rwxp 00056000 00:1b 99624917   
/usr/lib64/libgmp.so.3.5.0
2b5fd9b64000-2b5fd9be7000 r-xp  00:1b 99625157   
/lib64/libm-2.12.so
2b5fd9be7000-2b5fd9de6000 ---p 00083000 00:1b 99625157   
/lib64/libm-2.12.so
2b5fd9de6000-2b5fd9de7000 r-xp 00082000 00:1b 99625157   
/lib64/libm-2.12.so
2b5fd9de7000-2b5fd9de8000 rwxp 00083000 00:1b 99625157   
/lib64/libm-2.12.so
2b5fd9de8000-2b5fd9de9000 rwxp 2b5fd9de8000 00:00 0
2b5fd9de9000-2b5fd9e0 r-xp  00:1b 99617779   
/lib64/libpthread-2.12.so
2b5fd9e0-2b5fda00 ---p 00017000 00:1b 99617779   
/lib64/libpthread-2.12.so
2b5fda00-2b5fda001000 r-xp 00017000 00:1b 99617779   
/lib64/libpthread-2.12.so
2b5fda001000-2b5fda002000 rwxp 00018000 00:1b 99617779   
/lib64/libpthread-2.12.so
2b5fda002000-2b5fda006000 rwxp 2b5fda002000 00:00 0
2b5fda006000-2b5fda18f000 r-xp  00:1b 99617771   
/lib64/libc-2.12.so
2b5fda18f000-2b5fda38f000 ---p 00189000 00:1b 99617771   
/lib64/libc-2.12.so
2b5fda38f000-2b5fda393000 r-xp 00189000 00:1b 99617771   
/lib64/libc-2.12.so
2b5fda393000-2b5fda394000 rwxp 0018d000 00:1b 99617771   
/lib64/libc-2.12.so
2b5fda394000-2b5fda39b000 rwxp 2b5fda394000 00:00 0
2b5fda40-2b5fda50 rwxp 2b5fda40 00:00 0
2b5fda50-2b5fda501000 ---p 2b5fda50 00:00 0
2b5fda501000-2b5fdaf01000 rwxp 2b5fda501000 00:00 0
2b5fdaf01000-2b5fdaf08000 r-xs  00:1b 99630484   
/usr/lib64/gconv/gconv-modules.cache
2b5fdaf08000-2b5fdaf0a000 r-xp  00:1b 99625937   
/usr/lib64/gconv/UTF-32.so
2b5fdaf0a000-2b5fdb109000 ---p 2000 00:1b 99625937   
/usr/lib64/gconv/UTF-3

Re: [Haskell-cafe] containers license issue

[Clark Gaebel]

Just for reference:

In Data/IntMap/Base.hs

highestBitMask :: Nat -> Nat
highestBitMask x0
  = case (x0 .|. shiftRL x0 1) of
 x1 -> case (x1 .|. shiftRL x1 2) of
  x2 -> case (x2 .|. shiftRL x2 4) of
   x3 -> case (x3 .|. shiftRL x3 8) of
x4 -> case (x4 .|. shiftRL x4 16) of
#if !(defined(__GLASGOW_HASKELL__) && WORD_SIZE_IN_BITS==32)
 x5 -> case (x5 .|. shiftRL x5 32) of   -- for 64 bit platforms
#endif
  x6 -> (x6 `xor` (shiftRL x6 1))

In FXT bithigh.h:

static inline ulong highest_one(ulong x)
// Return word where only the highest bit in x is set.
// Return 0 if no bit is set.
{
#if defined  BITS_USE_ASM
if ( 0==x )  return 0;
x = asm_bsr(x);
return  1UL<>1);
#endif  // BITS_USE_ASM
}

And in FXT bits/bithigh-edge.h:

static inline ulong highest_one_01edge(ulong x)
// Return word where all bits from (including) the
//   highest set bit to bit 0 are set.
// Return 0 if no bit is set.
//
// Feed the result into bit_count() to get
//   the index of the highest bit set.
{
#if defined  BITS_USE_ASM

if ( 0==x )  return 0;
x = asm_bsr(x);
return  (2UL<>1;
x |= x>>2;
x |= x>>4;
x |= x>>8;
x |= x>>16;
#if  BITS_PER_LONG >= 64
x |= x>>32;
#endif
return  x;
#endif  // BITS_USE_ASM
}

=

However... I think the easy solution for this is to just find this in
http://graphics.stanford.edu/~seander/bithacks.html, and cite it instead. I
looked briefly and couldn't find it, but I'm almost sure it's in there.

  - Clark


On Wed, Dec 12, 2012 at 11:37 AM, Niklas Larsson wrote:

> 2012/12/12 David Thomas :
> > Ah, that's more than we'd been told.  If that is the case, then
> containers
> > is in violation of the GPL (unless they got permission to copy that code,
> > separately), and either must obtain such permission, be relicensed,
> > remove/replace that code.
>
> I think it's just a confusion of language, the "derived" algorithm
> clashes uncomfortably with the lawyerly "derived work". They are not
> used in the same sense.
>
> Niklas
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] containers license issue

[David Thomas]

This may be overconfident - how does copyright law deal with translations
in literature?  Still, it certainly makes infringement less likely, and the
earlier explicit statement that code was copied likely the result of
confusion.
On Dec 12, 2012 8:33 AM, "Niklas Larsson"  wrote:

> > The problem is that FXT library is GPL and thus containers package can
> not
> > be considered as BSD3. And it means that it can not be used in my case
> > (closed source software).
> >
> > Is this logic actually correct and containers should be considered as
> GPL?
> >
> > The package is widely used by other packages and the only way I see right
> > now is to fix sources to reimplement this functionality, which is not
> good
> > option.
> >
>
> There is no copied code from FXT (which can be said with certainty as
> FXT is a C library), hence the there can be copyright issue.
>
> Niklas
>
> ___
> 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] containers license issue

[Niklas Larsson]

2012/12/12 David Thomas :
> Ah, that's more than we'd been told.  If that is the case, then containers
> is in violation of the GPL (unless they got permission to copy that code,
> separately), and either must obtain such permission, be relicensed,
> remove/replace that code.

I think it's just a confusion of language, the "derived" algorithm
clashes uncomfortably with the lawyerly "derived work". They are not
used in the same sense.

Niklas

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

Re: [Haskell-cafe] containers license issue

[David Thomas]

Ah, that's more than we'd been told.  If that is the case, then containers
is in violation of the GPL (unless they got permission to copy that code,
separately), and either must obtain such permission, be relicensed,
remove/replace that code.


On Wed, Dec 12, 2012 at 8:29 AM, Clark Gaebel  wrote:

> It's not an algorithm. The source code of containers is derived from the
> source code of another library.
>
>   - Clark
>
>
> On Wed, Dec 12, 2012 at 11:27 AM, Vo Minh Thu  wrote:
>
>> I'm not sure what your point is.
>>
>> Re-implementing an algorithm is not a copyright infringement (nor is a
>> propagation of the original work). Algorithms are not covered by
>> copyright.
>>
>> 2012/12/12 Clark Gaebel :
>> > I think this is a potential problem, but, obviously, IANAL. [1]
>> >
>> > According to the GPL:
>> >
>> > To “propagate” a work means to do anything with it that, without
>> permission,
>> > would make you directly or secondarily liable for infringement under
>> > applicable copyright law, except executing it on a computer or
>> modifying a
>> > private copy. Propagation includes copying, distribution (with or
>> without
>> > modification), making available to the public, and in some countries
>> other
>> > activities as well.
>> >
>> > and
>> >
>> > You may make, run and propagate covered works that you do not convey,
>> > without conditions so long as your license otherwise remains in force.
>> >
>> > and of course
>> >
>> > You may not propagate or modify a covered work except as expressly
>> provided
>> > under this License. Any attempt otherwise to propagate or modify it is
>> void,
>> > and will automatically terminate your rights under this License
>> (including
>> > any patent licenses granted under the third paragraph of section 11).
>> >
>> >
>> > I believe that this counts as "propagation" of the original work, since
>> it
>> > would be considered "infringement under applicable copyright law". Now,
>> the
>> > wording in the GPL is a bit confusing on this point. I'm not sure if
>> > propagation requires that the BSD3 that containers is licensed under
>> must
>> > remain in force, or the GPL on which the which is derived must remain in
>> > force. Does anyone else have better luck interpreting this?
>> >
>> >   - Clark
>> >
>> > [1] Aside: Can we stop saying IANAL? Let's just all assume that, until
>> > proven otherwise, no one here is a lawyer.
>> > [2] Required Reading: http://www.gnu.org/licenses/gpl.html
>> >
>> >
>> > On Wed, Dec 12, 2012 at 11:00 AM, David Thomas <
>> davidleotho...@gmail.com>
>> > wrote:
>> >>
>> >> Right. If either of the following hold, you should be able to carry on
>> as
>> >> you were (but double check with your lawyer):
>> >>
>> >> 1) The algorithm is borrowed but the code was not copied.  In this
>> case,
>> >> copyright doesn't cover it, and the GPL is inapplicable.  (Patents
>> could
>> >> conceivably be an issue, but no more so than if it was BSD code).
>> >>
>> >> 2) If you are not going to be distributing the code - either it is used
>> >> for internal tools or in the backend of a networked service (which the
>> GPL
>> >> does not treat as distribution, as distinct from the AGPL).
>> >>
>> >> If a sizable chunk of actual code was copied, then the containers
>> package
>> >> would have to be GPL, and if you are using the library and distribute
>> >> programs built with it then those programs must be GPL as well.
>> >>
>> >>
>> >>
>> >> On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu  wrote:
>> >>>
>> >>> 2012/12/12 Dmitry Kulagin :
>> >>> > Hi Cafe,
>> >>> >
>> >>> > I am faced with unpleasant problem. The lawyer of my company checked
>> >>> > sources
>> >>> > of containers package and found out that it refers to some
>> GPL-library.
>> >>> >
>> >>> > Here is quote:
>> >>> > "The algorithm is derived from Jorg Arndt's FXT library"
>> >>> > in file Data/IntMap/Base.hs
>> >>> >
>> >>> > The problem is that FXT library is GPL and thus containers package
>> can
>> >>> > not
>> >>> > be considered as BSD3. And it means that it can not be used in my
>> case
>> >>> > (closed source software).
>> >>> >
>> >>> > Is this logic actually correct and containers should be considered
>> as
>> >>> > GPL?
>> >>> >
>> >>> > The package is widely used by other packages and the only way I see
>> >>> > right
>> >>> > now is to fix sources to reimplement this functionality, which is
>> not
>> >>> > good
>> >>> > option.
>> >>>
>> >>> GPL covers code, not algorithms.
>> >>>
>> >>> Beside, you can use GPL in closed-source code. GPL forces you to make
>> >>> the source available when you distribute the software, but if you
>> >>> don't distribute the software, there is nothing wrong to use GPL and
>> >>> not make your code available.
>> >>>
>> >>> HTH, IANAL,
>> >>> Thu
>> >>>
>> >>> ___
>> >>> Haskell-Cafe mailing list
>> >>> Haskell-Cafe@haskell.org
>> >>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >>
>> >>
>> >>
>> >> _

Re: [Haskell-cafe] containers license issue

[Niklas Larsson]

2012/12/12 Niklas Larsson :
>> The problem is that FXT library is GPL and thus containers package can not
>> be considered as BSD3. And it means that it can not be used in my case
>> (closed source software).
>>
>> Is this logic actually correct and containers should be considered as GPL?
>>
>> The package is widely used by other packages and the only way I see right
>> now is to fix sources to reimplement this functionality, which is not good
>> option.
>>
>
> There is no copied code from FXT (which can be said with certainty as
> FXT is a C library), hence the there can be copyright issue.
>
> Niklas

Gah, I should proofread! NO copyright issue, of course.

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

Re: [Haskell-cafe] containers license issue

[Niklas Larsson]

> The problem is that FXT library is GPL and thus containers package can not
> be considered as BSD3. And it means that it can not be used in my case
> (closed source software).
>
> Is this logic actually correct and containers should be considered as GPL?
>
> The package is widely used by other packages and the only way I see right
> now is to fix sources to reimplement this functionality, which is not good
> option.
>

There is no copied code from FXT (which can be said with certainty as
FXT is a C library), hence the there can be copyright issue.

Niklas

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

Re: [Haskell-cafe] containers license issue

[Clark Gaebel]

It's not an algorithm. The source code of containers is derived from the
source code of another library.

  - Clark


On Wed, Dec 12, 2012 at 11:27 AM, Vo Minh Thu  wrote:

> I'm not sure what your point is.
>
> Re-implementing an algorithm is not a copyright infringement (nor is a
> propagation of the original work). Algorithms are not covered by
> copyright.
>
> 2012/12/12 Clark Gaebel :
> > I think this is a potential problem, but, obviously, IANAL. [1]
> >
> > According to the GPL:
> >
> > To “propagate” a work means to do anything with it that, without
> permission,
> > would make you directly or secondarily liable for infringement under
> > applicable copyright law, except executing it on a computer or modifying
> a
> > private copy. Propagation includes copying, distribution (with or without
> > modification), making available to the public, and in some countries
> other
> > activities as well.
> >
> > and
> >
> > You may make, run and propagate covered works that you do not convey,
> > without conditions so long as your license otherwise remains in force.
> >
> > and of course
> >
> > You may not propagate or modify a covered work except as expressly
> provided
> > under this License. Any attempt otherwise to propagate or modify it is
> void,
> > and will automatically terminate your rights under this License
> (including
> > any patent licenses granted under the third paragraph of section 11).
> >
> >
> > I believe that this counts as "propagation" of the original work, since
> it
> > would be considered "infringement under applicable copyright law". Now,
> the
> > wording in the GPL is a bit confusing on this point. I'm not sure if
> > propagation requires that the BSD3 that containers is licensed under must
> > remain in force, or the GPL on which the which is derived must remain in
> > force. Does anyone else have better luck interpreting this?
> >
> >   - Clark
> >
> > [1] Aside: Can we stop saying IANAL? Let's just all assume that, until
> > proven otherwise, no one here is a lawyer.
> > [2] Required Reading: http://www.gnu.org/licenses/gpl.html
> >
> >
> > On Wed, Dec 12, 2012 at 11:00 AM, David Thomas  >
> > wrote:
> >>
> >> Right. If either of the following hold, you should be able to carry on
> as
> >> you were (but double check with your lawyer):
> >>
> >> 1) The algorithm is borrowed but the code was not copied.  In this case,
> >> copyright doesn't cover it, and the GPL is inapplicable.  (Patents could
> >> conceivably be an issue, but no more so than if it was BSD code).
> >>
> >> 2) If you are not going to be distributing the code - either it is used
> >> for internal tools or in the backend of a networked service (which the
> GPL
> >> does not treat as distribution, as distinct from the AGPL).
> >>
> >> If a sizable chunk of actual code was copied, then the containers
> package
> >> would have to be GPL, and if you are using the library and distribute
> >> programs built with it then those programs must be GPL as well.
> >>
> >>
> >>
> >> On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu  wrote:
> >>>
> >>> 2012/12/12 Dmitry Kulagin :
> >>> > Hi Cafe,
> >>> >
> >>> > I am faced with unpleasant problem. The lawyer of my company checked
> >>> > sources
> >>> > of containers package and found out that it refers to some
> GPL-library.
> >>> >
> >>> > Here is quote:
> >>> > "The algorithm is derived from Jorg Arndt's FXT library"
> >>> > in file Data/IntMap/Base.hs
> >>> >
> >>> > The problem is that FXT library is GPL and thus containers package
> can
> >>> > not
> >>> > be considered as BSD3. And it means that it can not be used in my
> case
> >>> > (closed source software).
> >>> >
> >>> > Is this logic actually correct and containers should be considered as
> >>> > GPL?
> >>> >
> >>> > The package is widely used by other packages and the only way I see
> >>> > right
> >>> > now is to fix sources to reimplement this functionality, which is not
> >>> > good
> >>> > option.
> >>>
> >>> GPL covers code, not algorithms.
> >>>
> >>> Beside, you can use GPL in closed-source code. GPL forces you to make
> >>> the source available when you distribute the software, but if you
> >>> don't distribute the software, there is nothing wrong to use GPL and
> >>> not make your code available.
> >>>
> >>> HTH, IANAL,
> >>> Thu
> >>>
> >>> ___
> >>> 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

Re: [Haskell-cafe] containers license issue

[Vo Minh Thu]

I'm not sure what your point is.

Re-implementing an algorithm is not a copyright infringement (nor is a
propagation of the original work). Algorithms are not covered by
copyright.

2012/12/12 Clark Gaebel :
> I think this is a potential problem, but, obviously, IANAL. [1]
>
> According to the GPL:
>
> To “propagate” a work means to do anything with it that, without permission,
> would make you directly or secondarily liable for infringement under
> applicable copyright law, except executing it on a computer or modifying a
> private copy. Propagation includes copying, distribution (with or without
> modification), making available to the public, and in some countries other
> activities as well.
>
> and
>
> You may make, run and propagate covered works that you do not convey,
> without conditions so long as your license otherwise remains in force.
>
> and of course
>
> You may not propagate or modify a covered work except as expressly provided
> under this License. Any attempt otherwise to propagate or modify it is void,
> and will automatically terminate your rights under this License (including
> any patent licenses granted under the third paragraph of section 11).
>
>
> I believe that this counts as "propagation" of the original work, since it
> would be considered "infringement under applicable copyright law". Now, the
> wording in the GPL is a bit confusing on this point. I'm not sure if
> propagation requires that the BSD3 that containers is licensed under must
> remain in force, or the GPL on which the which is derived must remain in
> force. Does anyone else have better luck interpreting this?
>
>   - Clark
>
> [1] Aside: Can we stop saying IANAL? Let's just all assume that, until
> proven otherwise, no one here is a lawyer.
> [2] Required Reading: http://www.gnu.org/licenses/gpl.html
>
>
> On Wed, Dec 12, 2012 at 11:00 AM, David Thomas 
> wrote:
>>
>> Right. If either of the following hold, you should be able to carry on as
>> you were (but double check with your lawyer):
>>
>> 1) The algorithm is borrowed but the code was not copied.  In this case,
>> copyright doesn't cover it, and the GPL is inapplicable.  (Patents could
>> conceivably be an issue, but no more so than if it was BSD code).
>>
>> 2) If you are not going to be distributing the code - either it is used
>> for internal tools or in the backend of a networked service (which the GPL
>> does not treat as distribution, as distinct from the AGPL).
>>
>> If a sizable chunk of actual code was copied, then the containers package
>> would have to be GPL, and if you are using the library and distribute
>> programs built with it then those programs must be GPL as well.
>>
>>
>>
>> On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu  wrote:
>>>
>>> 2012/12/12 Dmitry Kulagin :
>>> > Hi Cafe,
>>> >
>>> > I am faced with unpleasant problem. The lawyer of my company checked
>>> > sources
>>> > of containers package and found out that it refers to some GPL-library.
>>> >
>>> > Here is quote:
>>> > "The algorithm is derived from Jorg Arndt's FXT library"
>>> > in file Data/IntMap/Base.hs
>>> >
>>> > The problem is that FXT library is GPL and thus containers package can
>>> > not
>>> > be considered as BSD3. And it means that it can not be used in my case
>>> > (closed source software).
>>> >
>>> > Is this logic actually correct and containers should be considered as
>>> > GPL?
>>> >
>>> > The package is widely used by other packages and the only way I see
>>> > right
>>> > now is to fix sources to reimplement this functionality, which is not
>>> > good
>>> > option.
>>>
>>> GPL covers code, not algorithms.
>>>
>>> Beside, you can use GPL in closed-source code. GPL forces you to make
>>> the source available when you distribute the software, but if you
>>> don't distribute the software, there is nothing wrong to use GPL and
>>> not make your code available.
>>>
>>> HTH, IANAL,
>>> Thu
>>>
>>> ___
>>> 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

Re: [Haskell-cafe] containers license issue

[Clark Gaebel]

I think this is a potential problem, but, obviously, IANAL. [1]

According to the GPL:

To “propagate” a work means to do anything with it that, without
permission, would make you directly or secondarily liable for infringement
under applicable copyright law, except executing it on a computer or
modifying a private copy. Propagation includes copying, distribution (with
or without modification), making available to the public, and in some
countries other activities as well.

and

You may make, run and propagate covered works that you do not convey,
without conditions so long as your license otherwise remains in force.

and of course

You may not propagate or modify a covered work except as expressly provided
under this License. Any attempt otherwise to propagate or modify it is
void, and will automatically terminate your rights under this License
(including any patent licenses granted under the third paragraph of section
11).


I believe that this counts as "propagation" of the original work, since it
would be considered "infringement under applicable copyright law". Now, the
wording in the GPL is a bit confusing on this point. I'm not sure if
propagation requires that the BSD3 that containers is licensed under must
remain in force, or the GPL on which the which is derived must remain in
force. Does anyone else have better luck interpreting this?

  - Clark

[1] Aside: Can we stop saying IANAL? Let's just all assume that, until
proven otherwise, no one here is a lawyer.
[2] Required Reading: http://www.gnu.org/licenses/gpl.html


On Wed, Dec 12, 2012 at 11:00 AM, David Thomas 
wrote:
>
> Right. If either of the following hold, you should be able to carry on as
you were (but double check with your lawyer):
>
> 1) The algorithm is borrowed but the code was not copied.  In this case,
copyright doesn't cover it, and the GPL is inapplicable.  (Patents could
conceivably be an issue, but no more so than if it was BSD code).
>
> 2) If you are not going to be distributing the code - either it is used
for internal tools or in the backend of a networked service (which the GPL
does not treat as distribution, as distinct from the AGPL).
>
> If a sizable chunk of actual code was copied, then the containers package
would have to be GPL, and if you are using the library and distribute
programs built with it then those programs must be GPL as well.
>
>
>
> On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu  wrote:
>>
>> 2012/12/12 Dmitry Kulagin :
>> > Hi Cafe,
>> >
>> > I am faced with unpleasant problem. The lawyer of my company checked
sources
>> > of containers package and found out that it refers to some GPL-library.
>> >
>> > Here is quote:
>> > "The algorithm is derived from Jorg Arndt's FXT library"
>> > in file Data/IntMap/Base.hs
>> >
>> > The problem is that FXT library is GPL and thus containers package can
not
>> > be considered as BSD3. And it means that it can not be used in my case
>> > (closed source software).
>> >
>> > Is this logic actually correct and containers should be considered as
GPL?
>> >
>> > The package is widely used by other packages and the only way I see
right
>> > now is to fix sources to reimplement this functionality, which is not
good
>> > option.
>>
>> GPL covers code, not algorithms.
>>
>> Beside, you can use GPL in closed-source code. GPL forces you to make
>> the source available when you distribute the software, but if you
>> don't distribute the software, there is nothing wrong to use GPL and
>> not make your code available.
>>
>> HTH, IANAL,
>> Thu
>>
>> ___
>> 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

Re: [Haskell-cafe] LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)

[Jonathan Fischer Friberg]

+1

Very similar to my point (see original thread), but put in a better way. :)
As an interesting coincidence, this exact thing happened to someone
just now. (thread "containers license issue")

Jonathan

On Wed, Dec 12, 2012 at 5:00 PM, Clark Gaebel  wrote:
> Since we've already heard from the aggressive (L)GPL side of this "debate",
> I think it's time for someone to provide the opposite opinion.
>
> I write code to help users. However, as a library designer, my users are
> programmers just like me. Writing my Haskell libraries with restrictions
> like the (L)GPL means my users need to jump through hoops to use my
> software, and I personally find that unacceptable. Therefore, I gravitate
> more towards BSD3 and "beer-ware" type licenses. This also means my users
> aren't subjected to my religious views just because they want to use my
> "ones and zeros".
>
> Also, with GHC's aggressive inlining, even if you do have a static linking
> exception in your (L)GPL license, it still may not hold up! Although the
> entire idea is untested in court, GHC can (and will!) inline potentially
> huge parts of statically linked libraries into your code, and this would
> force you to break the license terms if you were to distribute the software
> without source code. In Haskell-land, the GPL is the ultimate in viral
> licensing, and very hard to escape.
>
> That's why I don't use (L)GPL licenses.
>
> Just making sure both sides have a horse in this race :)
>   - Clark
>
>
> On Wed, Dec 12, 2012 at 9:51 AM, kudah  wrote:
>>
>> On Wed, 12 Dec 2012 10:06:23 +0100 Petr P  wrote:
>>
>> > 2012/12/12 David Thomas 
>> >
>> > Yet another solution would be
>> > what David Thomas suggest: To provide the source code to your users,
>> > but don't allow them to use the code for anything but relinking the
>> > program with a different version of the library (no distribution, no
>> > modification etc.).
>>
>> You can also provide object code for linking, though I'm sure this
>> will not work with Haskell object files. Providing alternative
>> distribution of your program linked dynamically, or a promise to
>> provide one on notice, also satisfies the LGPL as long as
>> dynamic-version is as functional as the static and can be dropped-in
>> as a replacement.
>>
>> ___
>> 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

Re: [Haskell-cafe] LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)

[Clark Gaebel]

Since we've already heard from the aggressive (L)GPL side of this "debate",
I think it's time for someone to provide the opposite opinion.

I write code to help users. However, as a library designer, my users are
programmers just like me. Writing my Haskell libraries with restrictions
like the (L)GPL means my users need to jump through hoops to use my
software, and I personally find that unacceptable. Therefore, I gravitate
more towards BSD3 and "beer-ware" type licenses. This also means my users
aren't subjected to my religious views just because they want to use my
"ones and zeros".

Also, with GHC's aggressive inlining, even if you do have a static linking
exception in your (L)GPL license, it still may not hold up! Although the
entire idea is untested in court, GHC can (and will!) inline potentially
huge parts of statically linked libraries into your code, and this would
force you to break the license terms if you were to distribute the software
without source code. In Haskell-land, the GPL is the ultimate in viral
licensing, and very hard to escape.

That's why I don't use (L)GPL licenses.

Just making sure both sides have a horse in this race :)
  - Clark


On Wed, Dec 12, 2012 at 9:51 AM, kudah  wrote:

> On Wed, 12 Dec 2012 10:06:23 +0100 Petr P  wrote:
>
> > 2012/12/12 David Thomas 
> >
> > Yet another solution would be
> > what David Thomas suggest: To provide the source code to your users,
> > but don't allow them to use the code for anything but relinking the
> > program with a different version of the library (no distribution, no
> > modification etc.).
>
> You can also provide object code for linking, though I'm sure this
> will not work with Haskell object files. Providing alternative
> distribution of your program linked dynamically, or a promise to
> provide one on notice, also satisfies the LGPL as long as
> dynamic-version is as functional as the static and can be dropped-in
> as a replacement.
>
> ___
> 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] containers license issue

[David Thomas]

Right. If either of the following hold, you should be able to carry on as
you were (but double check with your lawyer):

1) The algorithm is borrowed but the code was not copied.  In this case,
copyright doesn't cover it, and the GPL is inapplicable.  (Patents could
conceivably be an issue, but no more so than if it was BSD code).

2) If you are not going to be distributing the code - either it is used for
internal tools or in the backend of a networked service (which the GPL does
not treat as distribution, as distinct from the AGPL).

If a sizable chunk of actual code was copied, then the containers package
would have to be GPL, and if you are using the library and distribute
programs built with it then those programs must be GPL as well.


On Wed, Dec 12, 2012 at 7:47 AM, Vo Minh Thu  wrote:

> 2012/12/12 Dmitry Kulagin :
> > Hi Cafe,
> >
> > I am faced with unpleasant problem. The lawyer of my company checked
> sources
> > of containers package and found out that it refers to some GPL-library.
> >
> > Here is quote:
> > "The algorithm is derived from Jorg Arndt's FXT library"
> > in file Data/IntMap/Base.hs
> >
> > The problem is that FXT library is GPL and thus containers package can
> not
> > be considered as BSD3. And it means that it can not be used in my case
> > (closed source software).
> >
> > Is this logic actually correct and containers should be considered as
> GPL?
> >
> > The package is widely used by other packages and the only way I see right
> > now is to fix sources to reimplement this functionality, which is not
> good
> > option.
>
> GPL covers code, not algorithms.
>
> Beside, you can use GPL in closed-source code. GPL forces you to make
> the source available when you distribute the software, but if you
> don't distribute the software, there is nothing wrong to use GPL and
> not make your code available.
>
> HTH, IANAL,
> Thu
>
> ___
> 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] containers license issue

[Vo Minh Thu]

2012/12/12 Dmitry Kulagin :
> Hi Cafe,
>
> I am faced with unpleasant problem. The lawyer of my company checked sources
> of containers package and found out that it refers to some GPL-library.
>
> Here is quote:
> "The algorithm is derived from Jorg Arndt's FXT library"
> in file Data/IntMap/Base.hs
>
> The problem is that FXT library is GPL and thus containers package can not
> be considered as BSD3. And it means that it can not be used in my case
> (closed source software).
>
> Is this logic actually correct and containers should be considered as GPL?
>
> The package is widely used by other packages and the only way I see right
> now is to fix sources to reimplement this functionality, which is not good
> option.

GPL covers code, not algorithms.

Beside, you can use GPL in closed-source code. GPL forces you to make
the source available when you distribute the software, but if you
don't distribute the software, there is nothing wrong to use GPL and
not make your code available.

HTH, IANAL,
Thu

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

Re: [Haskell-cafe] (L)GPL libraries & Haskell/GHC

[David Thomas]

Strictly speaking this is correct, and probably there's no one who would
miss the gotcha on the list, but for the sake of completeness:

You can release the source only to people who you have provided the
program, but *they* have the ability to redistribute it under the terms of
the GPL.  As discussed elsewhere, this seems to be a difference between the
LGPL and GPL, when dealing with Haskell libraries.  When using the LGPL,
you must allow people to update the library, so must (in the absence of
dynamic linking) provide the source, but you *may* prohibit redistribution
of that source.  (IANAL...)


On Wed, Dec 12, 2012 at 5:11 AM, Joachim Breitner
wrote:

>
> Also, if you want to sell the resulting program, you do not have to
> publish the source publicly, as long as you offer the source to your
> customers.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] containers license issue

[Dmitry Kulagin]

Hi Cafe,

I am faced with unpleasant problem. The lawyer of my company checked
sources of containers package and found out that it refers to some
GPL-library.

Here is quote:
"The algorithm is derived from Jorg Arndt's FXT library"
in file Data/IntMap/Base.hs

The problem is that FXT library is GPL and thus containers package can not
be considered as BSD3. And it means that it can not be used in my case
(closed source software).

Is this logic actually correct and containers should be considered as GPL?

The package is widely used by other packages and the only way I see right
now is to fix sources to reimplement this functionality, which is not good
option.

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

Re: [Haskell-cafe] Profiling slow multiplication of elements read from vector

[Richard Janis Beckert]

Hey! Thanks a lot for your reply!

> Disclaimer: I am compiling GHC 7.6.1-rc1 while testing this, so my
> measurements might be unreliable. Best try it out yourself.
> 
> Also, this blind-stab-optimization is /not/ best practice, I just
> enjoyed fiddling around.

What /is/ best practice in regards to performance optimization of code
such as mine? What other options than blind stabbing do I have? 


As for applying your suggestions: I have improved the speed of my
overall program by about 15% (see the new profiling I have obtained),
but it still seems as if the program spends too much time reading from
the vector and multiplying 5 integers --- but probably the cost centers
are allocated wrongly?

I tried various combinations of the changes you suggest, and had some
very interesting results.

It seems like there are some performance differences using GHC
7.4.2 (which I use due to cabal-dev) and GHC 7.6.*.

Using my initial code, I get a runtime of around 15.7s.

On 12/11/12 at 10:43pm, Joachim Breitner wrote:
> neighProd vs l !i = lukUp vs l (i-2) * lukUp vs l (i-1) *
>   lukUp vs l (i) * lukUp vs l (i+1) * lukUp vs l (i+2)
> 

Using that code rather than a map, actually leads to slower results! I
am getting an average of 18.0s for this.

Interestingly, passing the index `!i' as an unboxed Int leads to a
time-increase in my map version --- 16.8s.

However:

> Using V.unsafeIndex there gives another noticable speedup.

This helps a lot, giving me 14.8s and 15.1 for your suggestion; but
combining it with

> lukUp :: V.Vector Int -> Int -> Int -> Int
> lukUp vs l i = let !i' = i `mod` l
> in V.unsafeIndex vs i'
> 
> did, according to core, prevent some boxing, but did not speed up the
> program. Allocating Ints that are unused before the next GC are very
> cheap.

gives me a time of about 12.8s with your suggestions (explicit calls to
`lukUp', unsafeIndex'ing), which is the fastest result I got so far!

> You can save more time by not passing l around, the size of the vector
> is already present in vs and can cheaply be accessed by "V.length vs".

I decided to pass l around explicitly in order to safe on expensive
length-calculations. As it turns out, checking the bounds gives me a
decrease in speed in all cases.

Furthermore, using `mod' is actually a feature of
my underlying model, as it enforces periodic boundary conditions (think
of the vector representing a circle). Therefore the boundary checking
just happens accidentally.

> Oh, and you are creating a new byte array in every invocation of
> randVec. That is of course expensive. Using mutable arrays seems to be a
> more natural choice. Or is that really what you want to do? Judging from
> your code I would expect that you want to create a new array consisting
> only of values returned by neighProd; with the current code, when
> updating the second value you are including the _updated_ first entry in
> your product.

I will try to use a mutable vector to see if I can speed the thing up
further, since I do indeed want to update my vector one element at a
time, taking into account the elements 4 nearest and next-to-nearest
neighbours (as you can see, every iteration of the code acts on the
updated vector).

I just decided to go with an unmutable structure (a list at first,
followed by a Data.Map structure), in order to work without side
effects.



I'd be happy to get more input about how to increase the performance of
my code!


Cheers

Janis
Wed Dec 12 15:42 2012 Time and Allocation Profiling Report  (Final)

   vec +RTS -p -RTS

total time  =   12.46 secs   (12463 ticks @ 1000 us, 1 processor)
total alloc = 8,080,059,488 bytes  (excludes profiling overheads)

COST CENTRE MODULE  %time %alloc

neighProd   Main 27.75.9
iterMain 25.19.9
randVec.vs' Main 20.5   84.2
lukUp   Main 15.20.0
randVec Main 11.50.0


 individual 
inherited
COST CENTRE MODULE no. entries  %time 
%alloc   %time %alloc

MAINMAIN66   00.0
0.0   100.0  100.0
 main   Main   133   00.0
0.0   100.0  100.0
  main.vs   Main   141   10.0
0.0 0.00.0
  iter  Main   1341001   25.1
9.9   100.0  100.0
   lukUpMain   13810000.0
0.0 0.00.0
   neighProdMain   13610000.0
0.0 0.00.0
   randVec  Main   1351000   11.5
0.074.9   90.1
randVec.vs' Main   1431000   20.5   
84.220.5   84.2
neighProd   Main   139   0   27.7
5.94

Re: [Haskell-cafe] LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)

[kudah]

On Wed, 12 Dec 2012 10:06:23 +0100 Petr P  wrote:

> 2012/12/12 David Thomas 
>
> Yet another solution would be
> what David Thomas suggest: To provide the source code to your users,
> but don't allow them to use the code for anything but relinking the
> program with a different version of the library (no distribution, no
> modification etc.).

You can also provide object code for linking, though I'm sure this
will not work with Haskell object files. Providing alternative
distribution of your program linked dynamically, or a promise to
provide one on notice, also satisfies the LGPL as long as
dynamic-version is as functional as the static and can be dropped-in
as a replacement.

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

Re: [Haskell-cafe] Predicates in data types

[Ertugrul Söylemez]

Navid Hallajian  wrote:

> I'm a beginner in Haskell, so forgive me if this is a basic question,
> but I'd like to know if it's possible to have a predicate as part of a
> data type, so that when the data type is created, it can only be done
> if it satisfies the predicate else a type error is thrown.
>
> For instance, a matrix with integer elements could be modelled as
> [[Int]], given the restrictions that
>
>- it must have at least one column and one row (so there must be at
>least one list), and
>- every list must have the same length
>
> so that when a matrix is created, the type system wont allow it if the
> predicates aren't met.

You should model your data type such that it doesn't allow invalid
values to be created in the first place.  This is actually easy with the
DataKinds and GADTs extensions since GHC 7.6.  First, as almost always,
we need type-level naturals.  We will not use the predefined from
GHC.TypeLits, because we need natural numbers with structure:

data Nat :: * where
Z :: Nat
S :: Nat -> Nat

Now we define a type-indexed list type that encodes its length in the
type, commonly called 'Vec':

data Vec :: Nat -> * -> * where
Nil  :: Vec Z a
(:.) :: a -> Vec n a -> Vec (S n) a

infixr 5 :.

Unlike the regular list type this one does not give rise to a monad (I'm
lying on purpose here, but disregard that).  However, it gives you a
very useful applicative functor:

import Control.Applicative

instance Functor (Vec n) where
fmap f Nil = Nil
fmap f (x :. xs) = f x :. fmap f xs

instance Applicative (Vec Z) where
pure = const Nil
_ <*> _ = Nil

instance (Applicative (Vec n)) => Applicative (Vec (S n)) where
pure x = x :. pure x
f :. fs <*> x :. xs = f x :. (fs <*> xs)

These instances give you an arbitrary-arity zipWith, where liftA2 is
equivalent to zipWith and liftA3 is equivalent to zipWith3.  Using these
we can write a type-correct matrix transposition function:

transposeMat ::
(Applicative (Vec w))
=> Vec h (Vec w a)
-> Vec w (Vec h a)
transposeMat Nil = pure Nil
transposeMat (xs :. xss) = liftA2 (:.) xs (transposeMat xss)

We have had to use two extensions which I don't like, FlexibleContexts
and FlexibleInstances.  This is because of the Applicative class.  To
get rid of those instances you can write this in terms of a custom
class:

class ZipV (n :: Nat) where
pureV :: a -> Vec n a
zipV  :: Vec n (a -> b) -> Vec n a -> Vec n b

infixl 4 `zipV`

instance ZipV Z where
pureV= const Nil
zipV _ _ = Nil

instance (ZipV n) => ZipV (S n) where
pureV x = x :. pureV x
zipV (f :. fs) (x :. xs) = f x :. zipV fs xs

transposeMat :: (ZipV w) => Vec h (Vec w a) -> Vec w (Vec h a)
transposeMat Nil = pureV Nil
transposeMat (xs :. xss) =
pureV (:.)
`zipV` xs
`zipV` transposeMat xss

There is only one issue left:  How do we actually get these values from
the outside world?  For example how do we read such a vector from the
user?  There are two (and I think only two) ways to do it:  Higher-rank
types or existential types.  The first one is the simpler one:

fromList :: [a] -> (forall n. Vec n a -> b) -> b
fromList [] k  = k Nil
fromList (x:xs') k = fromList xs' (\xs -> k (x :. xs))

The point of the higher rank type is that the second argument to
fromList promises that it can handle vectors of any length.  It's a
function that works "for all" n.  This can be extended to actually read
such a vec from the user:

getVec :: (Read a) => (forall n. Vec n a -> IO b) -> IO b
getVec k = fmap read getLine >>= \xs -> fromList xs k

You can't pass a function that handles only non-empty lists to getVec,
because that function cannot handle any 'n'.  This lets the type system
force you to handle empty lists:

nonEmpty :: Vec n a -> b -> (forall n'. Vec (S n') a -> b) -> b

I invite you to write this function as an exercise and hope that this
mail helped.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.


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

Re: [Haskell-cafe] (L)GPL libraries & Haskell/GHC

[Joachim Breitner]

Hi,

Am Mittwoch, den 12.12.2012, 02:50 +0100 schrieb Jonathan Fischer
Friberg:
> On Wed, Dec 12, 2012 at 2:26 AM, Ramana Kumar
>  wrote:
> Using the GPL (or a strong copyleft free license) strengthens
> the free software community of which I thought the Haskell
> community is a part (or at least intersects substantially).
> 
> I don't think it strengthens the community. If someone wants to make a
> change a library, 
> but not release the source, they cannot do that with GPL.

this is not fully correct. Correct would be to say:
„If someone wants to make a change a library and distribute the
resulting programs without also sharing the source with the
recipient, they cannot do that with GPL.”

So it is fully acceptable under the GPL to change the library for your
own use, without sharing your code with anyone else.

If you create a web service based on the modified library, you do not
have to share the code (unless it is AGPL, but that is a different
license).

Also, if you want to sell the resulting program, you do not have to
publish the source publicly, as long as you offer the source to your
customers.

For LGPL, we can assume that all this holds; whether the additional
relaxation that LGPL provides over GPL apply to Haskell libraries seems
to be doubtful.

I hope that clarifies the situation a bit,
Joachim

-- 
Joachim "nomeata" Breitner
  m...@joachim-breitner.de  |  nome...@debian.org  |  GPG: 0x4743206C
  xmpp: nome...@joachim-breitner.de | http://www.joachim-breitner.de/



signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Predicates in data types

[Ivan Lazar Miljenovic]

On 12 December 2012 21:57, Navid Hallajian  wrote:
> Hello,
>
> I'm a beginner in Haskell, so forgive me if this is a basic question, but
> I'd like to know if it's possible to have a predicate as part of a data
> type, so that when the data type is created, it can only be done if it
> satisfies the predicate else a type error is thrown.
>
> For instance, a matrix with integer elements could be modelled as [[Int]],
> given the restrictions that
>
> it must have at least one column and one row (so there must be at least one
> list), and
> every list must have the same length
>
> so that when a matrix is created, the type system wont allow it if the
> predicates aren't met.

Write a custom constructor function that returns a Maybe:

newtype Matrix = Matrix [[Int]]

makeMatrix :: [[Int]] -> Maybe Matrix
makeMatrix [] = Nothing -- No columns
makeMatrix [[]] = Nothing -- Has a column but no rows
...

It is possible with smarter types to encode various predicates into
the actual type, but for your purposes they probably aren't required.

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



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com

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

[Haskell-cafe] Predicates in data types

[Navid Hallajian]

Hello,

I'm a beginner in Haskell, so forgive me if this is a basic question, but
I'd like to know if it's possible to have a predicate as part of a data
type, so that when the data type is created, it can only be done if it
satisfies the predicate else a type error is thrown.

For instance, a matrix with integer elements could be modelled as [[Int]],
given the restrictions that

   - it must have at least one column and one row (so there must be at
   least one list), and
   - every list must have the same length

so that when a matrix is created, the type system wont allow it if the
predicates aren't met.

Thanks,

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

[Haskell-cafe] Haskell Advent Calendar in Japan

[山本和彦]

Hello,

This is just for your information.

Haskell Advent Calendar is going on in Japanese Haskell Community: 

http://partake.in/events/45a01d39-af5e-42f1-91c7-e8fcc91db244

One article is evaluated lazily but other articles are in time. :-)

--Kazu

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

Re: [Haskell-cafe] Large, numerical calculations in Haskell

[Emil Hedevang]

Hi A.M. and Dominic,

I have been following the development of Repa for some time, mostly reading
blogs and papers about it, not actually writing any code. It's some quite
cool stuff the developers are doing.

A discrete convolution is a stencil computation. There are (to my
knowledge) essentially two approaches to calculate a discrete convolutions
Y = K * X:
(1) from the definition, and
(2) using discrete Fourier transforms

Approach no. 1 runs in O(nK nX) where nK and nX are the number of elements
in the arrays K and X, respectively, whereas approach no. 2 runs in O(nX
log nX). If nK is very, very small, then approach no. 1 is fastest,
otherwise approach no. 2 is fastest. If nK is somewhat smaller than nX,
then some tricks can be applied to obtain something a bit faster than
approach no. 2.

To my knowledge, Repa applies approach no. 1 in its stencil computations
and discrete convolutions. Therefore it cannot be applied in my case, since
I have nK = 10^6 and nX = 10^9 (or something similar), and so I must use
approach no. 2 with discrete Fourier transforms (DFT). In Repa, the DFT for
arbitrary array sizes is implemented using the slow O(n^2) algorithm, i.e.,
implemented using the definition of the DFT. If the size of the array is a
power of two, then the DFT is implemented using the fast Fourier transform
(FFT). Unfortunately, the Repa documentation states that the Repa FFT is
approximately 50 times slower than the FFT from FFTW. (And the FFT from
FFTW is even capable of calculating fast DFTs of arbitrary size). This
essentially forces my to use FFTW for the actual number crunching.

I suppose it would be a very interesting research project to implement FFTW
entirely in Haskell. Unfortunately, I currently do not have the time to
embark on such a quest.

Regarding the generation of random numbers, Repa implements what they call
a minimal standard Lehmer generator. I am not sure if that random number
generator is of high enough qualify for my needs.

Cheers,
Emil


On 12 December 2012 10:15, Dominic Steinitz  wrote:

> Emil Hedevang  gmail.com> writes:
>
> >
> >
> > Hi Haskell Cafe,
> >
> > I need to perform very large numerical computations requiring tens of GB
> of
> memory. The computations consist essentially of generation of random
> numbers
> and discrete convolutions of large arrays of random numbers with somewhat
> smaller kernel arrays. Should I use Haskell and call some C libraries when
> necessary? Should I just write everything in C? Or should I use e.g. Chapel
> (chapel.cray.com)?
> >
> >
> Hi Emil,
>
> The first place I would look would be repa http://repa.ouroborus.net/.
> IIRC it
> supports discrete convolutions and repa folks seem quite responsive.
>
> Dominic.
>
> PS I am planning to use repa to solve PDEs and address, at least
> partially, "the curse of dimensionality" with it.
>
>
>
>
> ___
> 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] (L)GPL libraries & Haskell/GHC (was: Re: ANNOUNCE: tie-knot library)

[Petr P]

I asked that on SO: http://programmers.stackexchange.com/q/179084/61231
So far the best answer is wxWidget's license (LGPL + linking exception)
which at least has been approved by OSI (although FSF approval would have
been better).

Best regards,
Petr


2012/12/12 Ivan Lazar Miljenovic 

> On 12 December 2012 12:57, Nicolas Trangez  wrote:
> > Note: IANAL
> >
> > On Tue, 2012-12-11 at 17:45 -0800, David Thomas wrote:
> >> On Tue, Dec 11, 2012 at 5:35 PM, Brandon Allbery  >wrote:
> >>
> >> > (Oddly enough, GPL is not the only open source license.)
> >>
> >> There was no implication to the contrary.  It was stated that BSD is a
> >> *weaker* license - this is true in the sense that it has fewer
> requirements
> >> (in particular, no copyleft) - and that "strong copyleft" licenses such
> as
> >> the GPL should be preferred as they do more to bolster the free software
> >> community.  You can disagree with this claim (there are arguments both
> ways
> >> - delving into them is not my point here) but please try not to bring in
> >> straw men.
> >
> > Actually the library is made available under the LGPL-3 license,
> > according to its README, not the GPL (although the latter is implicit,
> > of course).
> >
> > In the Haskell world this does have a different effect compared to when
> > one uses the LGPL for, say, a C library though, since (at least for now)
> > GHC uses/defaults to static linking, which IIRC (though IANAL) turns the
> > LGPL into GPL, so this has a severe impact for application authors. This
> > might be something people aren't aware of when releasing Haskell
> > libraries using the LGPL.
> >
> > I tend to use the LGPL myself for most library-style projects, and do so
> > as well for Haskell code (although I'm aware of the drawbacks), but I'm
> > perfectly fine with people linking the libs statically as long as they
> > comply to the license "as if they were using dynamic loading".
> >
> > If anyone knows some standard license which boils down to "obligations
> > like LGPL but OK for static linking as well", please let me know.
>
> I too would like such a license; however, the closest I've seen is
> LGPL + linking exception (which I believe is the license Malcolm
> Wallace uses for the cpphs library, though not the executable).
>
> >
> > Nicolas
> >
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> --
> Ivan Lazar Miljenovic
> ivan.miljeno...@gmail.com
> http://IvanMiljenovic.wordpress.com
>
> ___
> 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] How is default method signatures supposed to be used together with Generics

[José Pedro Magalhães]

Hi Johan,

The error message is not ideal, but it does say that adding a Generic (Foo
a)
instance might solve the problem.

I generally do not export classes like GHashable because they are closed;
users
should never need to provide more instances themselves. Also, exporting the
class
won't make the error message any better, and the solution to this error
doesn't really
involve the GHashable class...


Cheers,
Pedro

On Wed, Dec 12, 2012 at 4:28 AM, Johan Tibell wrote:

> Hi,
>
> I noticed that you're not required to export the types mentioned in
> the default method signature. For example, you could have:
>
> default hashWithSalt :: (Generic a, GHashable (Rep a)) => Int -> a ->
> Int
> hashWithSalt salt = ghashWithSalt salt . from
>
> and not export the GHashable class. However, if users try to define an
> instance of Hashable but forget to derive Generic:
>
> data Foo a = Foo a String
>  deriving (Eq)  -- Oops, forgot Generic here
>
> instance (Hashable a) => Hashable (Foo a)
>
> they get a pretty bad error message:
>
> Test.hs:10:10:
> Could not deduce (Generic (Foo a),
>   Data.Hashable.Class.GHashable (GHC.Generics.Rep (Foo
> a)))
>   arising from a use of `Data.Hashable.Class.$gdmhashWithSalt'
> from the context (Hashable a)
>   bound by the instance declaration at Test.hs:10:10-41
> Possible fix:
>   add (Generic (Foo a),
>Data.Hashable.Class.GHashable
>  (GHC.Generics.Rep (Foo a))) to the context of
> the instance declaration
>   or add instance declarations for
>  (Generic (Foo a),
>   Data.Hashable.Class.GHashable (GHC.Generics.Rep (Foo a)))
> In the expression: (Data.Hashable.Class.$gdmhashWithSalt)
> In an equation for `hashWithSalt':
> hashWithSalt = (Data.Hashable.Class.$gdmhashWithSalt)
> In the instance declaration for `Hashable (Foo a)'
>
> Exporting GHashable would help a little bit in that users would at
> least know what this GHashable class that the error talks about is.
>
> What's best practice?
>
> -- Johan
>
> ___
> 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] Large, numerical calculations in Haskell

[Dominic Steinitz]

Emil Hedevang  gmail.com> writes:

> 
> 
> Hi Haskell Cafe,
> 
> I need to perform very large numerical computations requiring tens of GB of 
memory. The computations consist essentially of generation of random numbers 
and discrete convolutions of large arrays of random numbers with somewhat 
smaller kernel arrays. Should I use Haskell and call some C libraries when 
necessary? Should I just write everything in C? Or should I use e.g. Chapel 
(chapel.cray.com)?
> 
> 
Hi Emil,

The first place I would look would be repa http://repa.ouroborus.net/. IIRC it 
supports discrete convolutions and repa folks seem quite responsive.

Dominic.

PS I am planning to use repa to solve PDEs and address, at least 
partially, "the curse of dimensionality" with it.




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

[Haskell-cafe] LGPL and Haskell (Was: Re: ANNOUNCE: tie-knot library)

[Petr P]

2012/12/12 David Thomas 

> IANAL, but reviewing what others have written, it sounds like it may be
> possible to maintain *some* distinction between LGPL and GPL in Haskell,
> but it's a different distinction than with an LGPL shared library, so even
> if applicable it's certainly worth being aware of.
>
> It sounds (and I'd very much like clarification) like providing source of
> an application to users *without* license to redistribute, which can be
> built using an LGPL library, would be compliant - whereas if the library
> was GPL this would not be the case?
>
> As I understand it, this is one of the main differences: Using GPL-ed
library forces the entire Combined Work to be GPL-ed (requiring to release
the source codes), while using LGPL-ed library forces only the possibility
to re-link with another version of it - you can distribute your own sources
to users with whatever license you like (unless it's a modification of the
library, of course). This could be an interesting question for FSF.


Thanks to all for valuable comments. I didn't want to start a discussion
about (L)GPL vs others, but since that already happened, let me give my
opinion:

First, LGPL  has been discussed already:
http://www.haskell.org/pipermail/haskell-cafe/2007-March/023158.html

The problem with LGPL is that it is apparently tailored to languages that
strongly rely on dynamic linking. TBH I wasn't aware of this before. One
solution (taken by wxWidgets for example) is to modify LGPL so that they
explicitly allow distributing the software without the re-linking
requirement (which grants a little less rights to end users). I tried
asking that on StackExchange: "Is there a modified LGPL license that allows
static linking?" 
Anther solution would be to focus on improvements of dynamic linking. Some
links I found:
http://hackage.haskell.org/trac/ghc/wiki/SharedLibraries/PlatformSupport
Haskell Static vs Dynamic Linking in Deployment <
http://stackoverflow.com/q/7854614/1333025>
Small Haskell program compiled with GHC into huge binary <
http://stackoverflow.com/q/6115459>
Yet another solution would be what David Thomas suggest: To provide the
source code to your users, but don't allow them to use the code for
anything but relinking the program with a different version of the library
(no distribution, no modification etc.).
 
Second, it's my wish to use (L)GPL for FOSS programs I write. My opinion
has varied for many years, but in recent years I strongly incline to
GPL-like licenses. We all know that GPL-like licenses make life more
complicated for us programmers. Programmers want to use libraries with as
little restrictions as possible. The main reason for me for choosing (L)GPL
despite the complications is the protection and rights it gives to the
*users* of a program. Sadly, no users are actually aware of  this and what
they could gain by choosing GPL-ed programs (let me know if you find a
non-programmer who is aware of GPL's benefits). Just imagine if Facebook
had to use AGPL, or if your mobile phone software would be all
GPL. (Knowing what a program does with your data is becoming more
important, like the US intelligence report suggests:
http://reut.rs/UxbLtvsection "Technology ..").

The other reason for me that GPL-like licenses give an advantage to FOSS
developers over private companies. I feel this is fair - anybody who
develops something that can be used by everyone deserves an advantage.

Another thing to consider is the aspect of adoption/marketing strategy.
Using a more permissive license can make adoption of a piece of software
much faster. This can be desirable in some cases, like if the OS community
wants to prevent the adoption of proprietary standards (like Vorbis VS
MP3). Or in the case of Haskell, to motivate private companies to use it.
Richard Stallman himself recommends this in some cases
http://lwn.net/2001/0301/a/rms-ov-license.php3
But if a project is strong enough, using (L)GPL can actually strengthen it,
like in the case of Linux VS NetBSD:
http://www.dwheeler.com/blog/2006/09/01/#gpl-bsd
To quote: "So while the BSDs have lost energy every time a company gets
involved, the GPL'ed programs gain every time a company gets involved."

Of course I respect other opinions in that matter, every author is free to
use whatever licence (s)he likes. After all, FOSS is about freedom. The
important thing to know is what advantages and drawbacks each license has
and what are the consequences of using them.

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

Re: [Haskell-cafe] How to start with GHC development?

[Janek S.]

Dnia środa, 12 grudnia 2012, wren ng thornton napisał:
> Other than that, it's hard to say. What part of the compiler are you
> (most) interested in hacking on? The type system? The compilation down
> to C-- and LLVM? The concurrency and parallelism? Debugging, testing,
> and fuzzing? ...
At the moment it's concurrency and parallelism, but I guess that at some point 
I might like to 
play with the type system.

Janek



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