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

[Petr P]

  Hi Felipe,

thanks for making me think about the licenses. Without your suggestion, I
wouldn't be aware of problems LGPL might cause for Haskell projects. And
I'm considering the possibility of using BSD (or a similar) license in the
future.

I'm aware of the issues you pointed out. As you say, since tie-knot is a
small library, it's not really that important what license it has, it's
easy to re-implement it if needed. And, until some else contributes to the
library, anybody can ask me to release the code under a different license,
if needed.

I'd say that the recent debate was a bit academic. (That wasn't bad at all,
it clarified many things for me.) Nobody actually said "I want to use the
library, but I cannot because of the license". Also we're talking about
LGPL, not GPL, and this makes thing different. Consider this: All packages
on Hackage have published their source codes. (More than 95% are open
source, and it's likely that those in "OtherLicence" are too.) With public
source codes, there is no problem using a LGPL-ed library! Anybody can
write a BSD licensed program which uses a LGPL library, and because all
sources are public, the requirement to allow re-linking is easily
satisfied. And nobody is forced to (L)GPL (unless the library is modified).
We can freely mix open-source projects that use LGPL and non-copyleft
licenses. The "LGPL problem" manifests only when someone wants to keep
source codes secret - then (s)he is forced to solve the problem with
re-linking. [With GPL, this would be very different, the whole project
would have to be GPL no matter what.]

I think it would be interesting to make some kind of poll to see what kind
of software Haskell community writes (FOSS vs closed source) and what
licensing issues people have. But the usual problem with such polls is that
only people who have problems vote, so the results are very biased.

  Best regards,
  Petr


2012/12/12 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 dist

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

[Michael Snoyman]

To take this out of the academic realm and into the real-life realm: I've
actually done projects for companies which have corporate policies
disallowing the usage of any copyleft licenses in their toolset. My use
case was a web application, which would not have been affected by a GPL
library usage since we were not distributing binaries. Nonetheless, those
clients would not have allowed usage of any such libraries. You can argue
whether or not this is a good decision on their part, but I don't think the
companies I interacted with were unique in this regard.

So anyone who's considering selling Haskell-based services to companies
could very well be in a situation where any (L)GPL libraries are
non-starters, regardless of actual legal concerns. This affects the open
source realm as well, because I think many of us want our libraries to be
commercial-friendly (I know this is the case for Yesod).

As one specific data point, I initially created the markdown package[1]
because I couldn't use pandoc[2] in one of these situations due to its GPL
license.

MIchael

[1] http://hackage.haskell.org/package/markdown
[2] http://hackage.haskell.org/package/pandoc


On Thu, Dec 13, 2012 at 10:00 AM, Petr P  wrote:

>   Hi Felipe,
>
> thanks for making me think about the licenses. Without your suggestion, I
> wouldn't be aware of problems LGPL might cause for Haskell projects. And
> I'm considering the possibility of using BSD (or a similar) license in the
> future.
>
> I'm aware of the issues you pointed out. As you say, since tie-knot is a
> small library, it's not really that important what license it has, it's
> easy to re-implement it if needed. And, until some else contributes to the
> library, anybody can ask me to release the code under a different license,
> if needed.
>
> I'd say that the recent debate was a bit academic. (That wasn't bad at
> all, it clarified many things for me.) Nobody actually said "I want to use
> the library, but I cannot because of the license". Also we're talking about
> LGPL, not GPL, and this makes thing different. Consider this: All packages
> on Hackage have published their source codes. (More than 95% are open
> source, and it's likely that those in "OtherLicence" are too.) With public
> source codes, there is no problem using a LGPL-ed library! Anybody can
> write a BSD licensed program which uses a LGPL library, and because all
> sources are public, the requirement to allow re-linking is easily
> satisfied. And nobody is forced to (L)GPL (unless the library is modified).
> We can freely mix open-source projects that use LGPL and non-copyleft
> licenses. The "LGPL problem" manifests only when someone wants to keep
> source codes secret - then (s)he is forced to solve the problem with
> re-linking. [With GPL, this would be very different, the whole project
> would have to be GPL no matter what.]
>
> I think it would be interesting to make some kind of poll to see what kind
> of software Haskell community writes (FOSS vs closed source) and what
> licensing issues people have. But the usual problem with such polls is that
> only people who have problems vote, so the results are very biased.
>
>   Best regards,
>   Petr
>
>
> 2012/12/12 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 Frib

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

[Colin Adams]

On 13 December 2012 08:09, Michael Snoyman  wrote:

> To take this out of the academic realm and into the real-life realm: I've
> actually done projects for companies which have corporate policies
> disallowing the usage of any copyleft licenses in their toolset. My use
> case was a web application, which would not have been affected by a GPL
> library usage since we were not distributing binaries. Nonetheless, those
> clients would not have allowed usage of any such libraries. You can argue
> whether or not this is a good decision on their part, but I don't think the
> companies I interacted with were unique in this regard.
>
> So anyone who's considering selling Haskell-based services to companies
> could very well be in a situation where any (L)GPL libraries are
> non-starters, regardless of actual legal concerns.
>

Presumably you are talking about companies who want to distribute programs
(a very small minority of companies, I would think)?
___
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)

[Alfredo Di Napoli]

Let me just chime in to give my 2 cents; I quote Micheal 100%; if we want
to push Haskell out of the academic/open source world to the "real world",
well, GPL is not the way to go, due to its viral nature.

Cheers,
A.

On 13 December 2012 08:09, Michael Snoyman  wrote:

> To take this out of the academic realm and into the real-life realm: I've
> actually done projects for companies which have corporate policies
> disallowing the usage of any copyleft licenses in their toolset. My use
> case was a web application, which would not have been affected by a GPL
> library usage since we were not distributing binaries. Nonetheless, those
> clients would not have allowed usage of any such libraries. You can argue
> whether or not this is a good decision on their part, but I don't think the
> companies I interacted with were unique in this regard.
>
> So anyone who's considering selling Haskell-based services to companies
> could very well be in a situation where any (L)GPL libraries are
> non-starters, regardless of actual legal concerns. This affects the open
> source realm as well, because I think many of us want our libraries to be
> commercial-friendly (I know this is the case for Yesod).
>
> As one specific data point, I initially created the markdown package[1]
> because I couldn't use pandoc[2] in one of these situations due to its GPL
> license.
>
> MIchael
>
> [1] http://hackage.haskell.org/package/markdown
> [2] http://hackage.haskell.org/package/pandoc
>
>
> On Thu, Dec 13, 2012 at 10:00 AM, Petr P  wrote:
>
>>   Hi Felipe,
>>
>> thanks for making me think about the licenses. Without your suggestion, I
>> wouldn't be aware of problems LGPL might cause for Haskell projects. And
>> I'm considering the possibility of using BSD (or a similar) license in the
>> future.
>>
>> I'm aware of the issues you pointed out. As you say, since tie-knot is a
>> small library, it's not really that important what license it has, it's
>> easy to re-implement it if needed. And, until some else contributes to the
>> library, anybody can ask me to release the code under a different license,
>> if needed.
>>
>> I'd say that the recent debate was a bit academic. (That wasn't bad at
>> all, it clarified many things for me.) Nobody actually said "I want to use
>> the library, but I cannot because of the license". Also we're talking about
>> LGPL, not GPL, and this makes thing different. Consider this: All packages
>> on Hackage have published their source codes. (More than 95% are open
>> source, and it's likely that those in "OtherLicence" are too.) With public
>> source codes, there is no problem using a LGPL-ed library! Anybody can
>> write a BSD licensed program which uses a LGPL library, and because all
>> sources are public, the requirement to allow re-linking is easily
>> satisfied. And nobody is forced to (L)GPL (unless the library is modified).
>> We can freely mix open-source projects that use LGPL and non-copyleft
>> licenses. The "LGPL problem" manifests only when someone wants to keep
>> source codes secret - then (s)he is forced to solve the problem with
>> re-linking. [With GPL, this would be very different, the whole project
>> would have to be GPL no matter what.]
>>
>> I think it would be interesting to make some kind of poll to see what
>> kind of software Haskell community writes (FOSS vs closed source) and what
>> licensing issues people have. But the usual problem with such polls is that
>> only people who have problems vote, so the results are very biased.
>>
>>   Best regards,
>>   Petr
>>
>>
>> 2012/12/12 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)
>>> ("Publ

Re: [Haskell-cafe] containers license issue

[Mike Meyer]

On Wed, 12 Dec 2012 17:27:03 +0100
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.

While algorithms aren't covered by copyright, *code* is. A translation
of a copyrighted work into another language is considered a derived
work of the original. If not, then simply translating a source program
into some computer's binary language would release it from copyright,
and it could be freely distributed. That would pretty much kill the
GPL.

Once someone has read an algorithm in some programming language, it
opens the question of whether they are copying the algorithm or the
code if they produce a copy of the algorithm. The generally accepted
solution is the one taken here - a clean-room re-implementation by
people who haven't read the code (ok, sort of taken here).

It might be small enough to get by on a "fair use" clause. The "prior
art" and "obvious" exceptions stated on this thread are for patents,
and don't apply to copyright.

But that's all irrelevant. The reason company lawyers object to having
GPL'ed code in the company code base is that it opens them up to the
possibility of a lawsuit. That the original author said it was derived
from GPL'ed code was sufficient to cause at least one lawyer to
believe that a case existed.

 http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

___
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)

[Michael Snoyman]

On Thu, Dec 13, 2012 at 10:14 AM, Colin Adams wrote:

> On 13 December 2012 08:09, Michael Snoyman  wrote:
>
>> To take this out of the academic realm and into the real-life realm: I've
>> actually done projects for companies which have corporate policies
>> disallowing the usage of any copyleft licenses in their toolset. My use
>> case was a web application, which would not have been affected by a GPL
>> library usage since we were not distributing binaries. Nonetheless, those
>> clients would not have allowed usage of any such libraries. You can argue
>> whether or not this is a good decision on their part, but I don't think the
>> companies I interacted with were unique in this regard.
>>
>> So anyone who's considering selling Haskell-based services to companies
>> could very well be in a situation where any (L)GPL libraries are
>> non-starters, regardless of actual legal concerns.
>>
>
> Presumably you are talking about companies who want to distribute programs
> (a very small minority of companies, I would think)?
>

No, read my use case again. I was creating a web application for a company.
The company was not going to distribute my code in any way to their
clients. Nonetheless, the company had a corporate policy to not use *any*
copyleft licenses, and therefore I was unable to use a library such as
Pandoc. (I believe this policy affected me at two separate companies, but I
don't remember all the details tbh.)

I also don't think that distributing programs is as small a market as you
think, and should also be something we support for commercial users of
Haskell.

Michael
___
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)

[Mike Meyer]

On Thu, 13 Dec 2012 08:58:07 +1100
Ramana Kumar  wrote:
> 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,

Or using a free license that isn't compatible with the GPL, or
incorporating software that is covered by such a license. You can find
a list of these licenses at:

http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses

and following, which lists licenses used for open source but aren't
considered free licenses by the GNU folks.

 http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

___
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 8:09 PM, Michael Snoyman wrote:

> I also don't think that distributing programs is as small a market as you
> think, and should also be something we support for commercial users of
> Haskell.
>

Distributing programs commercially is compatible with distributing them as
free software.
I think it would be helpful not to use "commercial users" to refer to both
those with policies against copyleft licenses and those who make money
distributing software.
Those groups are not even extensionally equal, and separating them further
(by having companies reconsider such policies) is, I would think, an
instrumental goal of the free software movement, which is one reason why
these tensions arise.
___
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)

[Michael Snoyman]

On Thu, Dec 13, 2012 at 11:35 AM, Ramana Kumar wrote:

> On Thu, Dec 13, 2012 at 8:09 PM, Michael Snoyman wrote:
>
>> I also don't think that distributing programs is as small a market as you
>> think, and should also be something we support for commercial users of
>> Haskell.
>>
>
> Distributing programs commercially is compatible with distributing them as
> free software.
> I think it would be helpful not to use "commercial users" to refer to both
> those with policies against copyleft licenses and those who make money
> distributing software.
> Those groups are not even extensionally equal, and separating them further
> (by having companies reconsider such policies) is, I would think, an
> instrumental goal of the free software movement, which is one reason why
> these tensions arise.
>

I'm not saying that *every* commercial user of Haskell has these concerns.
But I think it's a fair statement to say that a very large number of
commercial users do not wish to give out their source code. If you want to
claim that this isn't a commercial concern, but simply a concern of many
companies, that's fine, but I think it's irrelevant to the point: in many
cases, you will be unable to use GPLed libraries when creating software for
companies. Ignoring semantics, are you arguing with that claim?

If you want to try and convince companies to change their software policies
by writing some incredibly compelling GPL libraries, more power to you, and
I wish you the best. But I think that's quite separate to the question of
whether usage of the GPL today will hinder your ability to sell your
products or services to a company.

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

[Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Petr P]

  Dear Haskellers,

following up the recent discussion about copyleft licenses, I'd suggest a
(hopefully minor) improvement of Hackage: For each package, gather the list
of the licenses of everything it depends on. I think this would help
considerably people who don't want or can't use software licensed under a
particular license (most often (L)GPL). In particular, we can have a BSD
package that depends on a LGPL package, and this is fine for FOSS
developers. But for a commercial developer, this can be a serious issue
that is not apparent until one examines *every* transitive dependency.

This idea is a bit vague, because a dependency is actually a range of
packages, which in theory could have different licenses. But I suppose this
will rarely happen in practice, so it'd be safe just to take the last
package in the range (or maybe take all licences of the packages in the
range).

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

Re: [Haskell-cafe] Kernel Loops in Accelerate

[Trevor L. McDonell]

Hi Clark,

The question of sequential loops in Accelerate has come up a few times in the
past. The main sticking point is knowing how to implement them in a way that
encourages efficient programs; avoiding irregular arrays (iteration depths),
discouraging scalar versions of collective combinators, etc. Basically we need
to avoid thread divergence where possible, else the GPU SIMD hardware won't be
well utilised.

I've experimented a little with this. If you check the generated code of the
mandelbrot program [1], you'll see it has recovered the _fixed_ iteration depth
into a scalar loop.

I'll hack up something like a while loop for value iteration and see what
happens. Tentative proposal (perhaps just the second):

  iterate :: Exp Int-- fixed iteration count (maybe just a regular 
Int)
  -> (Exp a -> Exp a)   -- function to repeatedly apply
  -> Exp a  -- initial (seed) value
  -> Exp a

  while   :: (Exp a -> Exp Bool)
  -> (Exp a -> Exp a)
  -> Exp a
  -> Exp a

It would be good if we could collect some additional concrete applications and
see if there are better ways to map certain classes of sequential iteration to
efficient GPU code.

Additional thoughts/comments welcome!

Cheers,
-Trev


[1]: 
https://github.com/AccelerateHS/accelerate-examples/tree/master/examples/mandelbrot

On 12/12/2012, at 4:34 PM, Clark Gaebel  wrote:

> Hi Trevor (and cafe),
> 
> I've been playing more and more with accelerate, and I find it quite annoying 
> that there are no loops. It makes implementing many algorithms much harder 
> than it should be.
> 
> For example, I would love to submit a patch to fix issue #52 [0] on github by 
> implementing MWC64X [1], but it's very hard to port the OpenCL code on that 
> page when it's impossible to write kernel expressions with loops. Also, that 
> means there are no high-level combinators I'm used to for my sequential code 
> (such as map and fold) that would work on an accelerate CUDA kernel.
> 
> As a nice strawman example, how would one implement the following kernel in 
> accelerate, assuming 'rand_next', 'rand_get', and 'rand_skip' can all be 
> implemented cheaply? :
> 
> typedef uint64_t rand_state;
> 
> __device__ rand_state rand_next(rand_state s);
> __device__ uint32_t rand_get(rand_state s);
> __device__ rand_state rand_skip(rand_state s, uint64_t distance);
> __device__ uint32_t round_to_next_pow2(uint32_t n);
> 
> // Fills an array with random numbers given a random seed,
> // a maximum random number to generate, and an output
> // array to put the result in. The output will be in the range
> // [0, rand_max).
> __kernel__ void fill_random(rand_state start_state, uint32_t rand_max, 
> uint32_t* out) {
> rand_state current_state = start_state;
> int i = blockDim.x*blockIdx.x + threadIdx.x;
> // assumes we skip less than 1 million times per element...
> current_state = rand_skip(current_state, i*1e6);
> uint32_t mask = round_to_next_pow2(rand_max) - 1;
> uint32_t result;
> do {
> result = rand_get(current_state);
> current_state = rand_next(current_state);
> } while(result & mask >= rand_max);
> 
> out[i] = result;
> } // note: code was neither debugged, run, nor compiled.
> 
> Thanks,
>   - Clark
> 
> [0] https://github.com/AccelerateHS/accelerate/issues/52
> [1] http://cas.ee.ic.ac.uk/people/dt10/research/rngs-gpu-mwc64x.html

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

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Henk-Jan van Tuyl]

On Thu, 13 Dec 2012 11:41:14 +0100, Petr P  wrote:


For each package, gather the list
of the licenses of everything it depends on. I think this would help
considerably people who don't want or can't use software licensed under a
particular license (most often (L)GPL). In particular, we can have a BSD
package that depends on a LGPL package, and this is fine for FOSS
developers. But for a commercial developer, this can be a serious issue
that is not apparent until one examines *every* transitive dependency.

This idea is a bit vague, because a dependency is actually a range of
packages, which in theory could have different licenses. But I suppose  
this

will rarely happen in practice, so it'd be safe just to take the last
package in the range (or maybe take all licences of the packages in the
range).



cab[0] can do that, for installed packages:
  cab deps -i -r -a vector
will generate a list of licenses for the packages that vector depends  
upon, like this:


base 4.3.1.0 BSD3 ""
ghc-prim 0.2.0.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
integer-gmp 0.2.0.3 BSD3 ""
ghc-prim 0.2.0.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
primitive 0.4.0.1 BSD3 "Roman Leshchinskiy "
base 4.3.1.0 BSD3 ""
ghc-prim 0.2.0.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
integer-gmp 0.2.0.3 BSD3 ""
ghc-prim 0.2.0.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""
ghc-prim 0.2.0.0 BSD3 ""
rts 1.0 BSD3 ""
ffi 1.0 BSD3 ""


Regards,
Henk-Jan van Tuyl

[0] http://hackage.haskell.org/package/cab


--
http://Van.Tuyl.eu/
http://members.chello.nl/hjgtuyl/tourdemonad.html
Haskell programming
--

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

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

I think that's a great idea. I just implemented this on PackDeps:

http://packdeps.haskellers.com/licenses

As with all features on that site, I'll be happy to deprecate it as soon as
Hackage incorporates the feature in the future.

Michael


On Thu, Dec 13, 2012 at 12:41 PM, Petr P  wrote:

>   Dear Haskellers,
>
> following up the recent discussion about copyleft licenses, I'd suggest a
> (hopefully minor) improvement of Hackage: For each package, gather the list
> of the licenses of everything it depends on. I think this would help
> considerably people who don't want or can't use software licensed under a
> particular license (most often (L)GPL). In particular, we can have a BSD
> package that depends on a LGPL package, and this is fine for FOSS
> developers. But for a commercial developer, this can be a serious issue
> that is not apparent until one examines *every* transitive dependency.
>
> This idea is a bit vague, because a dependency is actually a range of
> packages, which in theory could have different licenses. But I suppose this
> will rarely happen in practice, so it'd be safe just to take the last
> package in the range (or maybe take all licences of the packages in the
> range).
>
>   Best regards,
>   Petr
>
> ___
> 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]

Outside of the Valley and FOSS movement, programs are still usually
distributed as binaries.

For example, I have a secret, dirty desire to write a game in Haskell. This
would be closed source, and if I'd have to rewrite most of the supporting
libraries, it would be a nonstarter.

Plus, it's hard enough advocating for Haskell adoption because "it's hard"
or "less experienced developers won't get it". It'd rather not add "the
entire ecosystem is GPL, and there's no dynamic linking" to that list if I
could avoid it.

   - Clark


On Thu, Dec 13, 2012 at 3:14 AM, Colin Adams wrote:

> On 13 December 2012 08:09, Michael Snoyman  wrote:
>
>> To take this out of the academic realm and into the real-life realm: I've
>> actually done projects for companies which have corporate policies
>> disallowing the usage of any copyleft licenses in their toolset. My use
>> case was a web application, which would not have been affected by a GPL
>> library usage since we were not distributing binaries. Nonetheless, those
>> clients would not have allowed usage of any such libraries. You can argue
>> whether or not this is a good decision on their part, but I don't think the
>> companies I interacted with were unique in this regard.
>>
>> So anyone who's considering selling Haskell-based services to companies
>> could very well be in a situation where any (L)GPL libraries are
>> non-starters, regardless of actual legal concerns.
>>
>
> Presumably you are talking about companies who want to distribute programs
> (a very small minority of companies, I would think)?
>
> ___
> 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] Kernel Loops in Accelerate

[Clark Gaebel]

Sometimes we need some divergence in kernels, such as the random number
generation example I just posted. Technically (but not practically), we
could have a thread executing forever.

It's fine to discourage writing these loops, and with the proposed
signatures there still won't be any temptation to do data-parallel work,
but they're necessary for many real-world tasks on which parallel
algorithms don't entirely map.

Once this is all said and done, however, I think I'll be writing an initial
implementation of a parallel Monte Carlo library based on accelerate. It
(accelerate) seems really promising. I especially love how I can test my
programs without an Nvidia GPU, and can switch to performance test and to
run real-world code.

Thanks,
  - Clark

P.S. Don't forget about do-while! =)


On Thu, Dec 13, 2012 at 7:47 AM, Trevor L. McDonell <
tmcdon...@cse.unsw.edu.au> wrote:

> Hi Clark,
>
> The question of sequential loops in Accelerate has come up a few times in
> the
> past. The main sticking point is knowing how to implement them in a way
> that
> encourages efficient programs; avoiding irregular arrays (iteration
> depths),
> discouraging scalar versions of collective combinators, etc. Basically we
> need
> to avoid thread divergence where possible, else the GPU SIMD hardware
> won't be
> well utilised.
>
> I've experimented a little with this. If you check the generated code of
> the
> mandelbrot program [1], you'll see it has recovered the _fixed_ iteration
> depth
> into a scalar loop.
>
> I'll hack up something like a while loop for value iteration and see what
> happens. Tentative proposal (perhaps just the second):
>
>   iterate :: Exp Int-- fixed iteration count (maybe just a
> regular Int)
>   -> (Exp a -> Exp a)   -- function to repeatedly apply
>   -> Exp a  -- initial (seed) value
>   -> Exp a
>
>   while   :: (Exp a -> Exp Bool)
>   -> (Exp a -> Exp a)
>   -> Exp a
>   -> Exp a
>
> It would be good if we could collect some additional concrete applications
> and
> see if there are better ways to map certain classes of sequential
> iteration to
> efficient GPU code.
>
> Additional thoughts/comments welcome!
>
> Cheers,
> -Trev
>
>
> [1]:
> https://github.com/AccelerateHS/accelerate-examples/tree/master/examples/mandelbrot
>
> On 12/12/2012, at 4:34 PM, Clark Gaebel  wrote:
>
> Hi Trevor (and cafe),
>
> I've been playing more and more with accelerate, and I find it quite
> annoying that there are no loops. It makes implementing many algorithms
> much harder than it should be.
>
> For example, I would love to submit a patch to fix issue #52 [0] on github
> by implementing MWC64X [1], but it's very hard to port the OpenCL code on
> that page when it's impossible to write kernel expressions with loops.
> Also, that means there are no high-level combinators I'm used to for my
> sequential code (such as map and fold) that would work on an accelerate
> CUDA kernel.
>
> As a nice strawman example, how would one implement the following kernel
> in accelerate, assuming 'rand_next', 'rand_get', and 'rand_skip' can all be
> implemented cheaply? :
>
> typedef uint64_t rand_state;
>
> __device__ rand_state rand_next(rand_state s);
> __device__ uint32_t rand_get(rand_state s);
> __device__ rand_state rand_skip(rand_state s, uint64_t distance);
> __device__ uint32_t round_to_next_pow2(uint32_t n);
>
> // Fills an array with random numbers given a random seed,
> // a maximum random number to generate, and an output
> // array to put the result in. The output will be in the range
> // [0, rand_max).
> __kernel__ void fill_random(rand_state start_state, uint32_t rand_max,
> uint32_t* out) {
> rand_state current_state = start_state;
> int i = blockDim.x*blockIdx.x + threadIdx.x;
> // assumes we skip less than 1 million times per element...
> current_state = rand_skip(current_state, i*1e6);
> uint32_t mask = round_to_next_pow2(rand_max) - 1;
> uint32_t result;
> do {
> result = rand_get(current_state);
> current_state = rand_next(current_state);
> } while(result & mask >= rand_max);
>
> out[i] = result;
> } // note: code was neither debugged, run, nor compiled.
>
> Thanks,
>   - Clark
>
> [0] https://github.com/AccelerateHS/accelerate/issues/52
> [1] http://cas.ee.ic.ac.uk/people/dt10/research/rngs-gpu-mwc64x.html
>
>
>
> ___
> 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] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Vincent Hanquez]

On 12/13/2012 12:51 PM, Michael Snoyman wrote:

I think that's a great idea. I just implemented this on PackDeps:

http://packdeps.haskellers.com/licenses

As with all features on that site, I'll be happy to deprecate it as 
soon as Hackage incorporates the feature in the future.


awesome Michael !

However i think ithis shouldn't take dependencies from tests and benchmarks.
This doesn't make differences for the "overall" license that the library 
"exposes".


--
Vincent

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

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez  wrote:

> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
>
>> I think that's a great idea. I just implemented this on PackDeps:
>>
>> http://packdeps.haskellers.**com/licenses
>>
>> As with all features on that site, I'll be happy to deprecate it as soon
>> as Hackage incorporates the feature in the future.
>>
>
> awesome Michael !
>
> However i think ithis shouldn't take dependencies from tests and
> benchmarks.
> This doesn't make differences for the "overall" license that the library
> "exposes".
>
> --
> Vincent
>

Hmm, that's a good point. I'll admit I hadn't really thought this through,
but I can actually see an argument going both ways on this:

* Viral licenses won't actually affect you if they're just used for test
suites.
* But company lawyers will probably be nervous about it anyway.

Nonetheless, I think you have the right of it. Unless people say otherwise,
I'm going to implement Vincent's change.

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

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Felipe Almeida Lessa]

While you're at it, maybe whitelisting cpphs would be nice as well =).

On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman  wrote:
>
>
>
> On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez  wrote:
>>
>> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
>>>
>>> I think that's a great idea. I just implemented this on PackDeps:
>>>
>>> http://packdeps.haskellers.com/licenses
>>>
>>> As with all features on that site, I'll be happy to deprecate it as soon
>>> as Hackage incorporates the feature in the future.
>>
>>
>> awesome Michael !
>>
>> However i think ithis shouldn't take dependencies from tests and
>> benchmarks.
>> This doesn't make differences for the "overall" license that the library
>> "exposes".
>>
>> --
>> Vincent
>
>
> Hmm, that's a good point. I'll admit I hadn't really thought this through,
> but I can actually see an argument going both ways on this:
>
> * Viral licenses won't actually affect you if they're just used for test
> suites.
> * But company lawyers will probably be nervous about it anyway.
>
> Nonetheless, I think you have the right of it. Unless people say otherwise,
> I'm going to implement Vincent's change.
>
> Michael
>
> ___
> 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] LGPL and Haskell

[Herbert Valerio Riedel]

Alfredo Di Napoli  writes:

> Let me just chime in to give my 2 cents; I quote Micheal 100%; if we want
> to push Haskell out of the academic/open source world to the "real world",
> well, GPL is not the way to go, due to its viral nature.

just to throw in a different argument: there's also the concept of
dual-licensing[1,2] to accomodate both the F/OSS users as well as the
commercial users...

cheers,
  hvr

 [1]: http://www.linuxinsider.com/story/38172.html
 [2]: http://www.oss-watch.ac.uk/resources/duallicence2

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

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

Are you referring to:

http://code.haskell.org/cpphs/LICENCE-commercial

If the package is dual-licensed BSD3 and LGPL, maybe Malcolm could change
the cabal file to mention the BSD3 so that its package description is less
intimidating?


On Thu, Dec 13, 2012 at 4:12 PM, Felipe Almeida Lessa <
felipe.le...@gmail.com> wrote:

> While you're at it, maybe whitelisting cpphs would be nice as well =).
>
> On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman 
> wrote:
> >
> >
> >
> > On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez  wrote:
> >>
> >> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
> >>>
> >>> I think that's a great idea. I just implemented this on PackDeps:
> >>>
> >>> http://packdeps.haskellers.com/licenses
> >>>
> >>> As with all features on that site, I'll be happy to deprecate it as
> soon
> >>> as Hackage incorporates the feature in the future.
> >>
> >>
> >> awesome Michael !
> >>
> >> However i think ithis shouldn't take dependencies from tests and
> >> benchmarks.
> >> This doesn't make differences for the "overall" license that the library
> >> "exposes".
> >>
> >> --
> >> Vincent
> >
> >
> > Hmm, that's a good point. I'll admit I hadn't really thought this
> through,
> > but I can actually see an argument going both ways on this:
> >
> > * Viral licenses won't actually affect you if they're just used for test
> > suites.
> > * But company lawyers will probably be nervous about it anyway.
> >
> > Nonetheless, I think you have the right of it. Unless people say
> otherwise,
> > I'm going to implement Vincent's change.
> >
> > Michael
> >
> > ___
> > 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

[Haskell-cafe] ANNOUNCE: hoodle : Pen note-taking program written in haskell

[Ian-Woo Kim]

Hi, Haskellers!

I am happy to announce hoodle : pen note-taking program written in haskell.
Hoodle is a continuation of the development of hxournal. I renamed it
to hoodle, apparently meaning Haskell + doodle. It has undergone many
changes and bug fixes. Hopefully, this program is now useful to users.

See how it works in action :
http://www.youtube.com/watch?v=Z2wzpyxsVSU

Hoodle has been uploaded on hackage and is installable using cabal.
After the installation of gtk2hs, you can install it by simply typing

> cabal install hoodle

As a default, pdf annotation is turned off, but if you have installed
poppler, then you can install hoodle with pdf-annotation function by
typing

> cabal install -fpoppler hoodle-render hoodle-core hoodle

Hoodle Homepage is http://ianwookim.org/hoodle
Have fun with hoodle!

Thanks.

best,
Ian-Woo Kim

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

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Felipe Almeida Lessa]

>From [1] I gather that its license really is LGPL/GPL.  However, when
used as a preprocessor its license doesn't really matter.  Many
packages on that list have a LGPL "taint" because one of its deps use
cpphs.  So the whitelist of cpphs would be stating that nobody is
using cpphs as a library (which may be false, but is mostly true ;).

[1] http://code.haskell.org/cpphs/README

On Thu, Dec 13, 2012 at 1:08 PM, Michael Snoyman  wrote:
> Are you referring to:
>
> http://code.haskell.org/cpphs/LICENCE-commercial
>
> If the package is dual-licensed BSD3 and LGPL, maybe Malcolm could change
> the cabal file to mention the BSD3 so that its package description is less
> intimidating?
>
>
> On Thu, Dec 13, 2012 at 4:12 PM, Felipe Almeida Lessa
>  wrote:
>>
>> While you're at it, maybe whitelisting cpphs would be nice as well =).
>>
>> On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman 
>> wrote:
>> >
>> >
>> >
>> > On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez  wrote:
>> >>
>> >> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
>> >>>
>> >>> I think that's a great idea. I just implemented this on PackDeps:
>> >>>
>> >>> http://packdeps.haskellers.com/licenses
>> >>>
>> >>> As with all features on that site, I'll be happy to deprecate it as
>> >>> soon
>> >>> as Hackage incorporates the feature in the future.
>> >>
>> >>
>> >> awesome Michael !
>> >>
>> >> However i think ithis shouldn't take dependencies from tests and
>> >> benchmarks.
>> >> This doesn't make differences for the "overall" license that the
>> >> library
>> >> "exposes".
>> >>
>> >> --
>> >> Vincent
>> >
>> >
>> > Hmm, that's a good point. I'll admit I hadn't really thought this
>> > through,
>> > but I can actually see an argument going both ways on this:
>> >
>> > * Viral licenses won't actually affect you if they're just used for test
>> > suites.
>> > * But company lawyers will probably be nervous about it anyway.
>> >
>> > Nonetheless, I think you have the right of it. Unless people say
>> > otherwise,
>> > I'm going to implement Vincent's change.
>> >
>> > Michael
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > Haskell-Cafe@haskell.org
>> > http://www.haskell.org/mailman/listinfo/haskell-cafe
>> >
>>
>>
>>
>> --
>> Felipe.
>
>



-- 
Felipe.

___
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 11:11:28PM -0800, Chris Smith wrote:
> Well, actual legal advice comes from actual lawyers, who often want actual
> money.

That's true.  However, haskell.org's fiscal sponsor receives pro bono
legal services.

> 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.

I may have been conflating threads, though the response to what I assume
was just a lawyer asking a question seems excessive too.

___
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?

[Badi' Abdul-Wahid]

Just my two cents: Nix is great, Modules is not perfect, but it is good.

I think that Nix solves a lot of the problems, but will likely take a while
to be adopted.
I'm still exploring Nix and NixOS, but I have to say: I really like it.

I've found that a practical solution for my own development work has been
the modules project [1].
I'd describe it as a happy medium between manual software management and
Nix.
The upside is similar to that of Nix: software with conflicting
dependencies can coexist.
The downside is that there is no package management: everything needs to be
installed manually and configured with --prefix.

However, I've found that the advantages far outweigh the disadvantages.
For instance, tracking down a bug where software A which depends on B which
depends on C, but C1 conflicts with C2, C3... etc, and you need to test all
permutations.
In my case, package C was multiple versions of cuda: 3.2, 4.0, 4.1, and 5.0
Testing was, eg:
$ module load environment/A-1.0/B-2.0/cuda-4.0
$ ./runtest.sh

I'd really like to see if cabal is compatible with this setup. Hopefully
I'll have time in the next few weeks to look into it.

Quick example of a module file for gsl on my machine:
$ cat ~/privatemodules/gsl/1.15
#%Module

set namegsl
set version 1.15
set prefix  /opt
set root$prefix/$name/$version

prepend-path PATH  $root/bin
prepend-path INCLUDE   $root/include
prepend-path LD_LIBRARY_PATH   $root/lib
prepend-path DYLD_LIBRARY_PATH $root/lib


[1] http://modules.sourceforge.net/



On Thu, Dec 13, 2012 at 1:12 AM, Rustom Mody  wrote:

> 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
>
>


-- 

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

Re: [Haskell-cafe] containers license issue

[Christopher Howard]

On 12/13/2012 08:34 AM, Clint Adams wrote:
> On Wed, Dec 12, 2012 at 11:11:28PM -0800, Chris Smith wrote:
> 
> That's true.  However, haskell.org's fiscal sponsor receives pro bono
> legal services.
> 
> 
> I may have been conflating threads, though the response to what I assume
> was just a lawyer asking a question seems excessive too.
> 
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

Just thought I'd mention: It is possible for anyone involved in a FOSS
project to get pro bono legal advice from the SFLC, from actual lawyers
who are highly familiar with the legal aspects of FOSS licenses:

https://www.softwarefreedom.org

quote:

If you are involved in a Free, Libre and Open Source Software (FLOSS)
project in need of legal advice, please email h...@softwarefreedom.org.
When seeking legal advice, please use only this address to contact us
(unless you are already a client).


I'm not sure if they are willing to help those who are trying to /avoid/
making a free software product, but they would likely be willing to
answer any generic questions about applicability of the GPLs, derived
works, etc.

-- 
frigidcode.com



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

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

I'm not quite certain what to make of:

If you have a commercial use for cpphs, and feel the terms of the (L)GPL
are too onerous, you have the option of distributing unmodified binaries
(only, not sources) under the terms of a different licence (see
LICENCE-commercial).

It seems like that's saying "if you really want to, use the BSD license
instead." But I'm not sure what the legal meaning of "If you have a
commercial use" is. Malcolm: could you clarify what the meaning is?


On Thu, Dec 13, 2012 at 6:37 PM, Felipe Almeida Lessa <
felipe.le...@gmail.com> wrote:

> From [1] I gather that its license really is LGPL/GPL.  However, when
> used as a preprocessor its license doesn't really matter.  Many
> packages on that list have a LGPL "taint" because one of its deps use
> cpphs.  So the whitelist of cpphs would be stating that nobody is
> using cpphs as a library (which may be false, but is mostly true ;).
>
> [1] http://code.haskell.org/cpphs/README
>
> On Thu, Dec 13, 2012 at 1:08 PM, Michael Snoyman 
> wrote:
> > Are you referring to:
> >
> > http://code.haskell.org/cpphs/LICENCE-commercial
> >
> > If the package is dual-licensed BSD3 and LGPL, maybe Malcolm could change
> > the cabal file to mention the BSD3 so that its package description is
> less
> > intimidating?
> >
> >
> > On Thu, Dec 13, 2012 at 4:12 PM, Felipe Almeida Lessa
> >  wrote:
> >>
> >> While you're at it, maybe whitelisting cpphs would be nice as well =).
> >>
> >> On Thu, Dec 13, 2012 at 12:03 PM, Michael Snoyman 
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Thu, Dec 13, 2012 at 3:53 PM, Vincent Hanquez 
> wrote:
> >> >>
> >> >> On 12/13/2012 12:51 PM, Michael Snoyman wrote:
> >> >>>
> >> >>> I think that's a great idea. I just implemented this on PackDeps:
> >> >>>
> >> >>> http://packdeps.haskellers.com/licenses
> >> >>>
> >> >>> As with all features on that site, I'll be happy to deprecate it as
> >> >>> soon
> >> >>> as Hackage incorporates the feature in the future.
> >> >>
> >> >>
> >> >> awesome Michael !
> >> >>
> >> >> However i think ithis shouldn't take dependencies from tests and
> >> >> benchmarks.
> >> >> This doesn't make differences for the "overall" license that the
> >> >> library
> >> >> "exposes".
> >> >>
> >> >> --
> >> >> Vincent
> >> >
> >> >
> >> > Hmm, that's a good point. I'll admit I hadn't really thought this
> >> > through,
> >> > but I can actually see an argument going both ways on this:
> >> >
> >> > * Viral licenses won't actually affect you if they're just used for
> test
> >> > suites.
> >> > * But company lawyers will probably be nervous about it anyway.
> >> >
> >> > Nonetheless, I think you have the right of it. Unless people say
> >> > otherwise,
> >> > I'm going to implement Vincent's change.
> >> >
> >> > Michael
> >> >
> >> > ___
> >> > Haskell-Cafe mailing list
> >> > Haskell-Cafe@haskell.org
> >> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >> >
> >>
> >>
> >>
> >> --
> >> Felipe.
> >
> >
>
>
>
> --
> Felipe.
>
___
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 didn't even know that site existed. Let's add them to the thread!

softwarefreedom.org, what are your opinions on what was discussed in this
thread:

http://www.haskell.org/pipermail/haskell-cafe/2012-December/105193.html

Is there anything that we, as a community, should know about? Should we
proceed differently?

Thanks,
  - Clark

(you might need to sign up to haskell-cafe to post. maybe use a different
account?)

On Thu, Dec 13, 2012 at 1:45 PM, Christopher Howard <
christopher.how...@frigidcode.com> wrote:

> On 12/13/2012 08:34 AM, Clint Adams wrote:
> > On Wed, Dec 12, 2012 at 11:11:28PM -0800, Chris Smith wrote:
> >
> > That's true.  However, haskell.org's fiscal sponsor receives pro bono
> > legal services.
> >
> >
> > I may have been conflating threads, though the response to what I assume
> > was just a lawyer asking a question seems excessive too.
> >
> > ___
> > Haskell-Cafe mailing list
> > Haskell-Cafe@haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
>
> Just thought I'd mention: It is possible for anyone involved in a FOSS
> project to get pro bono legal advice from the SFLC, from actual lawyers
> who are highly familiar with the legal aspects of FOSS licenses:
>
> https://www.softwarefreedom.org
>
> quote:
> 
> If you are involved in a Free, Libre and Open Source Software (FLOSS)
> project in need of legal advice, please email h...@softwarefreedom.org.
> When seeking legal advice, please use only this address to contact us
> (unless you are already a client).
> 
>
> I'm not sure if they are willing to help those who are trying to /avoid/
> making a free software product, but they would likely be willing to
> answer any generic questions about applicability of the GPLs, derived
> works, etc.
>
> --
> frigidcode.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] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Daniel Trstenjak]

On Thu, Dec 13, 2012 at 08:40:09PM +0200, Michael Snoyman wrote:
> If you have a commercial use for cpphs, and feel the terms of the (L)GPL
> are too onerous, you have the option of distributing unmodified binaries
> (only, not sources) under the terms of a different licence (see
> LICENCE-commercial).

I think that depedencies to binaries, like cpphs, should be treated
differently than depedencies to libraries, because using a (L)GPL-ed
binary mostly hasn't any implications for a "commercial" user and
also for the output of a (L)GPL-ed binary usually the (L)GPL doesn't apply.

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

Re: [Haskell-cafe] Hackage suggestion: Gather the list of the licenses of all dependencies of a package

[Michael Snoyman]

On Thu, Dec 13, 2012 at 9:51 PM, Daniel Trstenjak <
daniel.trsten...@gmail.com> wrote:

>
> On Thu, Dec 13, 2012 at 08:40:09PM +0200, Michael Snoyman wrote:
> > If you have a commercial use for cpphs, and feel the terms of the (L)GPL
> > are too onerous, you have the option of distributing unmodified binaries
> > (only, not sources) under the terms of a different licence (see
> > LICENCE-commercial).
>
> I think that depedencies to binaries, like cpphs, should be treated
> differently than depedencies to libraries, because using a (L)GPL-ed
> binary mostly hasn't any implications for a "commercial" user and
> also for the output of a (L)GPL-ed binary usually the (L)GPL doesn't apply.
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

In the case of cpphs, there's no way to determine that we're using it as a
library or an executable, since it's just listed in the build-depends.

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

[Haskell-cafe] Second Call for Copy: Monad.Reader #21

[Edward Z. Yang]

Second Call for Copy: The Monad.Reader - Issue 21
-

Whether you're an established academic or have only just started
learning Haskell, if you have something to say, please consider
writing an article for The Monad.Reader!  The submission deadline
for Issue 21 will be:

**Tuesday, January 1**

Less than half a month away, but that's what Christmas break is for,
right? :-)

The Monad.Reader


The Monad.Reader is a electronic magazine about all things Haskell. It
is less formal than journal, but somehow more enduring than a wiki-
page. There have been a wide variety of articles: exciting code
fragments, intriguing puzzles, book reviews, tutorials, and even
half-baked research ideas.

Submission Details
~~

Get in touch with me if you intend to submit something -- the sooner
you let me know what you're up to, the better.

Please submit articles for the next issue to me by e-mail (ezy...@mit.edu).

Articles should be written according to the guidelines available from

http://themonadreader.wordpress.com/contributing/

Please submit your article in PDF, together with any source files you
used. The sources will be released together with the magazine under a
BSD license.

If you would like to submit an article, but have trouble with LaTeX
please let me know and we'll work something out.

___
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?

[Richard O'Keefe]

On 13/12/2012, at 7:12 PM, Rustom Mody wrote:

> 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]

Why rely on memory?
The Algol-60 compiler Dijkstra worked on was for the Electrologica X1.
"The basic X1 machine, fitting in a large writing desk,
 consisted of an arithmetic unit and several registers,
 in particular two 27-bit accumulators A and S, a condition register,
 an instruction register, and a 16-bit index register.  A and S could
 be used together as a single double-length register for multiply and
 divide operations.  The basic machine had a built-in 'live'
 (i.e. random-access) memory of 512 words of 28 bits (including 1 sign
 bit and 1 parity bit); and 700 words of 'dead' (i.e. read-only) memory.
 More memory could be added in separate storage cabinets, up to 32768
 words, including additional read-only memory.  Normally there was no
 magnetic drum, disk or other type of secondary memory (a magnetic
 drum was an optional extension, however)".
[http://www.science.uva.nl/faculteit/museum/X1.php   -- edited lightly]
Apparently the actual machine the compiler was built on had 4 kilo-words.

That compiler read the source paper tape exactly twice.

"The greatest shortcoming of the system, however, was the almost
 complete absence of syntax checks and run–time checks", something
that was to be repeated in the development of C.  Another front end
that did more thorough syntax checking was written a few years later;
Lint saw _that_ part of Algol 60 history repeated too.

A leaflet in my letterbox yesterday advertised a headless box with 16GB
of memory for NZD 700.  We've come a long way.



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

Re: [Haskell-cafe] containers license issue

[Richard O'Keefe]

On 14/12/2012, at 7:45 AM, Christopher Howard wrote:
> Just thought I'd mention: It is possible for anyone involved in a FOSS
> project to get pro bono legal advice from the SFLC, from actual lawyers
> who are highly familiar with the legal aspects of FOSS licenses:
> 
> https://www.softwarefreedom.org

Intimately familiar with New Zealand law, are they?


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

Re: [Haskell-cafe] containers license issue

[Christopher Howard]

On 12/13/2012 05:54 PM, Richard O'Keefe wrote:
> 
> On 14/12/2012, at 7:45 AM, Christopher Howard wrote:
> 
> Intimately familiar with New Zealand law, are they?
> 

I couldn't say anything about that, specifically. However, SFLC has an
international outreach. From 2011 SFLC news:

quote:

We are proud to announce a new position at the Software Freedom Law
Center: Director of International Programs. Over the past few years SFLC
has become an increasingly International organization, working with the
European Commission, launching SFLC India, and consulting with
governments around the world on issues of free software licensing,
policy, and use. Mishi Choudhary, counsel at SFLC and head of SFLC
India, has always been at the heart of this work so it is only fitting
that she is stepping up to fill the new position. Congratulations to Ms.
Choudhary and we all look forward to a stronger international presence
ahead.
-

-- 
frigidcode.com



signature.asc
Description: OpenPGP digital signature
___
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?

[wren ng thornton]

On 12/12/12 3:07 AM, Janek S. wrote:

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.


In that case I'd suggest reading some of the papers on STM, DPH, REPA, 
and Cloud Haskell, and then just diving into the GHC code. It's been a 
while since I've read them, but SPJ's classic books don't have a whole 
lot about concurrency/parallelism IIRC.


For the type system, I highly recommend reading [1]. It's long but it's 
more of an introductory/tutorial sort of paper, so it's easy reading. 
Also, unlike most intro/tutorial papers, it goes all the way through 
System F (H98 minus type classes, plus RankNTypes), whereas most intros 
only show Hindley--Damas--Milner (SML). On the one hand, HDM is a good 
starting place because it's such an easy type system with a very nice 
power/weight ratio, but if you're interested in hacking on modern 
Haskell we're so far beyond HDM that starting there would only slow you 
down, since we can no longer take advantage of a number of simplifying 
assumptions that HDM makes. ... After you've read that paper, you'll 
probably want to take a look at one of the newer Fc papers, which adds 
in GADTs, type families, and other GHC Haskellisms. After that you 
should be ready to start hacking, though you'll need to backfill some of 
the theory from time to time.



[1] 
http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/


--
Live well,
~wren

___
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)

[wren ng thornton]

On 12/13/12 3:14 AM, Colin Adams wrote:

Presumably you are talking about companies who want to distribute programs
(a very small minority of companies, I would think)?


Not at all. In addition to Michael's own rebuttal, I'll add my own. 
There are many companies which *fear* the L/GPL. The important thing to 
note here is this:


The Actual Legal Requirements of Copyleft Licenses are IRRELEVANT.

This simple fact is consistently ignored by advocates of the GPL (of 
which I number myself, FWIW). The great majority of all software 
produced in the world is developed for in-house use, and thus would not 
be subject to any of the "bad" side effects from using copyleft 
software. And yet, in spite of this fact, there are a great many 
companies which have official policies forbidding the use of copyleft 
software.


Why is that? It's because companies have legal departments whose jobs it 
is to ensure that the company won't be destroyed by legal action. And 
because there isn't an extensive record of actual court rulings 
regarding purported violations of the GPL, lawyers are rightly wary of 
it. Companies do not (generally) avoid the GPL because of understanding 
its requirements and refusing to abide by them. Companies avoid the GPL 
because they do not know what it means! More particularly, because they 
do not know what the courts will think it means, and that's too much 
uncertainty to risk your company over. Any actual commercial burden 
imposed by the GPL re distributing software is beside the point. 
Corporate lawyers (for these companies) won't risk getting close enough 
to even evaluate what that burden would amount to.


--
Live well,
~wren

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

Re: [Haskell-cafe] LGPL and Haskell

[wren ng thornton]

On 12/13/12 9:30 AM, Herbert Valerio Riedel wrote:

Alfredo Di Napoli  writes:


Let me just chime in to give my 2 cents; I quote Micheal 100%; if we want
to push Haskell out of the academic/open source world to the "real world",
well, GPL is not the way to go, due to its viral nature.


just to throw in a different argument: there's also the concept of
dual-licensing[1,2] to accomodate both the F/OSS users as well as the
commercial users...


I'm a big fan of dual-licensing. It's an underutilized tactic for 
overcoming the competing forces of commercial success and F/OSS success.


Moreover, in my experience, those companies which refuse to have 
anything to do with the GPL tend to be more than willing to pay for a 
corporate license. Just remember: money isn't evil, it's proprietarism 
that's evil.


--
Live well,
~wren

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