Re: [Haskell-cafe] Template Haskell Splicing
I don't think that there is a particular reason for not supporting quasi-quotes in where clauses.. It should be added! The reason for /splices/ to not be supported in here statements is that they are run during type checking. That way calls to reify can access type information for things before your splice. It also allows checking any AST quotes used inside your splice. Since type-checking comes after renaming, splices can't be used in patterns (because it would affect the lexical scope). Quasi-quotes, on the other hand, are run in the renamer, and ought to be able to be used in where clauses. Yet for some reason they can't - I get parse error (possibly incorrect indentation or mismatched brackets) when I try to put one under a where. Good catch! -Michael On Fri, Dec 14, 2012 at 11:09 PM, satvik chauhan mystic.sat...@gmail.comwrote: Is there any way to splice declarations inside where? If not, then what is the reason for not supporting this? -Satvik ___ 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] edge: compile testing
Compiled just fine on my machine. Ubuntu 12.10, Haskell Platform 2012.2.0.0, GHC 7.4.2, cabal-install 1.16.0.1. Christopher Howard christopher.how...@frigidcode.com писал(а) в своём письме Sat, 15 Dec 2012 06:52:22 +0300: Hey guys, to teach myself Haskell I wrote a little arcade game called The Edge, built on gloss. It is in hackage under the package name edge. Are there a few kind souls who would be willing to compile it on their machines and let me know if there are any problems at the compiling level? In the past, I've had issues with Haskell code compiling fine on my development system but not on others (due to dependency-related issues). I want to double check this before I try to make any distro-specific packages. I developed with GHC 7.4 and cabal-install 1.16.0.2 on a Gentoo system. Requires OpenGL and OpenAL (for sound). cabal update cabal install edge ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
Clark Gaebel cgae...@uwaterloo.ca writes: I just did a quick derivation from http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 A copyrighted work, you say? to get the highest bit mask, and did not reference FXT nor the containers implementation. Here is my code: If copyright follows reimplementations of algorithms from other programs (because they are considered translations of that program), then surely it must also follow reimplementation from copyrighted documentation? I think this is wrong, copyright does not cover algorithms, and reverse engineering is not literary translation. The implications of anything else would be draconian, simply documenting a program would be a breach of its copyright, for instance, and Tanenbaum would hold the copyright to Linux. But in a court of law, anything is possible. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] containers license issue
Ketil Malde ke...@malde.org writes: I just did a quick derivation from http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 A copyrighted work, you say? Whoops, public domain, according to itself. Of course, there's no way to tell if the author read similar copyrighted programs, but maybe you'll get off easier from claimin the infringement was not wilful? (BTW, the concept Public Domain isn't recognized in some jurisdictions) -k ___ 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
On Sat, Dec 15, 2012 at 08:13:44AM +0100, Petr P wrote: This is strange, I thought that cpphs should be specified in build-tools:, not in build-depends:. http://www.haskell.org/cabal/users-guide/developing-packages.html#build-information Best regards, Petr Presumably the reason to list it in build-depends instead of build-tools is that in the latter case cabal will not automatically install it as a dependency. But you are right that this is a strange situation, since if it is being used only as a preprocessor, semantically it ought to be listed in build-tools. -Brent 2012/12/13 Michael Snoyman mich...@snoyman.com 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 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
2012/12/15 Brent Yorgey byor...@seas.upenn.edu On Sat, Dec 15, 2012 at 08:13:44AM +0100, Petr P wrote: This is strange, I thought that cpphs should be specified in build-tools:, not in build-depends:. http://www.haskell.org/cabal/users-guide/developing-packages.html#build-information Best regards, Petr Presumably the reason to list it in build-depends instead of build-tools is that in the latter case cabal will not automatically install it as a dependency. But you are right that this is a strange situation, since if it is being used only as a preprocessor, semantically it ought to be listed in build-tools. So if I put cpphs into build-tools and I don't have it installed, the build will fail? Is this a desired behavior, or a bug? Best regards, Petr ___ 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
On 13 Dec 2012, at 18:40, Michael Snoyman wrote: 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? No, the LICENCE-commercial is not BSD. Read it more carefully. :-) So, I dual-licensed cpphs (which was originally only LGPL as a library, GPL as a binary), in response to a request from a developer (working for a company) who wished to use it as a library linked into their own software (rather than a standalone executable), but who was unable to convince his boss that LGPL would be acceptable. IIRC, the software was going to end up in some gadget to be sold (and therefore the code was being distributed, indirectly). The commercial licence I provided for him was intended to uphold the spirit of the LGPL, without going as far as BSD in laxity. So, if you simply want to use cpphs in a distributed product (but not modify it), it is very easy. The moment you want to distribute a modified version, you must abide by the LGPL, which to me essentially means that you contribute back your changes to the community. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell Splicing
On Sat, Dec 15, 2012 at 1:30 PM, Michael Sloan mgsl...@gmail.com wrote: I don't think that there is a particular reason for not supporting quasi-quotes in where clauses.. It should be added! The reason for /splices/ to not be supported in here statements is that they are run during type checking. That way calls to reify can access type information for things before your splice. It also allows checking any AST quotes used inside your splice. Since type-checking comes after renaming, splices can't be used in patterns (because it would affect the lexical scope). Quasi-quotes, on the other hand, are run in the renamer, and ought to be able to be used in where clauses. Yet for some reason they can't - I get parse error (possibly incorrect indentation or mismatched brackets) when I try to put one under a where. Good catch! -Michael Yeah, that is the problem. I have a function inside which I need to generate some declarations using TH. I can not generate these at the top level as these generations depend on the function's parameters which are local to the function. Something like f p1 p2= ... where -- this has to be generated by TH g_1 = p1 g_2 = p2 g_3 = p1 `xor` p2 something like the above. In the above I have shown only 2 parameters but in my case it is much more. I am able to get the above splice as toplevel declaration but I am still unsuccessful in getting it inside the where. I can always make `g` a function and take parameters of `f` as arguments in the top level splice but that will defeat the purpose of optimization here(which I am trying to do), as that would result in a function call every time I use `g` instead of above variables. ___ 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
On 13 Dec 2012, at 10:41, Petr P wrote: 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 might a good time to remind everyone that every single program compiled by a standard GHC is linked against an LGPL library (the Gnu multi-precision integer library) - unless you take care first to build your own copy of the compiler against the integer-simple package instead of integer-gmp. As far as I know, there are no ready-packaged binary installers for GHC that avoid this LGPL'd dependency. http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes Just saying. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is it possible to have constant-space JSON decoding?
Johan Tibell posed an interesting problem of incremental XML parsing while still detecting and reporting ill-formedness errors. What you can't have (I think) is a function: decode :: FromJSON a = ByteString - Maybe a and constant-memory parsing at the same time. The return type here says that we will return Nothing if parsing fails. We can only do so after looking at the whole input (otherwise how would we know if it's malformed). The problem is very common: suppose we receive an XML document over a network (e.g., in an HTTP stream). Network connections are inherently unreliable and can be dropped at any time (e.g., because someone tripped over a power cord). The XML document therefore can come truncated, for example, missing the end tag for the root element. According to the XML Recommendations, such document is ill-formed, and hence does not have an Infoset (In contrast, invalid but well-formed documents do have the Infoset). Strictly speaking, we should not be processing an XML document until we verified that it is well-formed, that is, until we parsed it at all and have checked that all end tags are in place. It seems we can't do the incremental XML processing in principle. I should mention first that sometimes people avoid such a strict interpretation. If we process telemetry data encoded in XML, we may consider a document meaningful even if the root end tag is missing. We process as far as we can. Even if we take the strict interpretation, it is still possible to handle a document incrementally so long as the processing is functional or the side effects can be backed out (e.g., in a transaction). This message illustrates exactly such an incremental processing that always detects ill-formed XML, and, optionally, invalid XML. It is possible after all to detect ill-formedness errors and process the document without loading it all in memory first -- using as little memory as needed to hold the state of the processor -- just a short string in our example. Our running example is an XML document representing a finite map: a collection of key-value pairs where key is an integer: map kvkey1/keyvaluev1/value/kv kvkey2/keyvaluev2/value/kv kvkeybad/keyvaluev3/value/kv The above document is both ill-formed (missing the end tag) and invalid (one key is bad: non-read-able). We would like to write a lookup function for a key in such an encoded map. We should report an ill-formedness error always. The reporting of validation errors may vary. The function xml_lookup :: Monad m = Key - Iteratee Char m (Maybe Value) xml_lookup key = id .| xml_enum default_handlers .| xml_normalize .| kv_enum (lkup key) always reports the validation errors. The function is built by composition from smaller, separately developed and tested pipeline components: parsing of a document to the XMLStream, normalization, converting the XMLStream to a stream of (Key,Value) pairs and finally searching the stream. A similar function that replaces kv_enum with kv_enum_pterm terminates the (Key,Value) conversion as soon as its client iteratee finished. In that case if the lookup succeeds before we encounter the bad key, no error is reported. Ill-formedness errors are raised always. The code http://okmij.org/ftp/Haskell/Iteratee/XMLookup.hs shows the examples of both methods of validation error reporting. This code also illustrates the library of parsing combinators, which represent the element structure (`DTD'). ___ 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
On Sat, Dec 15, 2012 at 9:01 AM, Petr P petr@gmail.com wrote: So if I put cpphs into build-tools and I don't have it installed, the build will fail? Is this a desired behavior, or a bug? Shortcoming of cabal; it only knows about libraries because it is really just a front-end for ghc-pkg, so can't really figure dependencies involving only executables and not libraries. The same thing comes up with happy, alex, and gtk2hsc2hs. -- 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
Ketil Malde ke...@malde.org wrote: Clark Gaebel cgae...@uwaterloo.ca writes: I just did a quick derivation from http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 A copyrighted work, you say? The work is copyrighted, the snippets are placed in the placed in the public domain. This is old hat - you can copyright a collection of non-copyrightable objects. I think this is wrong, copyright does not cover algorithms, and reverse engineering is not literary translation. As it's commonly understood, reverse engineering doesn't involve looking at the code. That's why it's called reverse engineering instead of copying. If you never had access to the code, you couldn't have copied it. Of course, you can't produce a literary translation of it, either. The implications of anything else would be draconian Calling the current state of copyright law in the US draconian might be going a little far. But only a little. simply documenting a program would be a breach of its copyright Documenting code has run into copyright issue before. That's why *both* volumes of the Lion's book were pulled from publication. Documenting codes behavior as a black box or how you use it isn't a problem. If you say function F finds the highest one it in it's argument or call f(x) to find the highest one bit in x and I then write a function f that behaves that way, there can't have been a copyright violation, because I never saw the source to f. If you *give* me that source, and I translate the code to another language, then I've created a derived work, which means copyright law applies. If you give me the source to f, and I write a function that does the same thing - then I may or may not have copied it. This means I *could* wind up in court over the thing, which is exactly the possibility that the lawyer is trying to avoid. Tanenbaum would hold the copyright to Linux. Only if Tanenbaum documented the internal behavior of Linux before it was written. -- 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] containers license issue
2012/12/15 Mike Meyer m...@mired.org: Only if Tanenbaum documented the internal behavior of Linux before it was written. Tannenbaum wrote Minix, the operating system that Linus used (and hacked on) before he did Linux. Minix contained lots of features that was reimplemented in Linux. Same thing with Stallman, do you think he never saw the Unix sources? Niklas ___ 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
On Sat, Dec 15, 2012 at 4:25 PM, Malcolm Wallace malcolm.wall...@me.comwrote: On 13 Dec 2012, at 10:41, Petr P wrote: 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 might a good time to remind everyone that every single program compiled by a standard GHC is linked against an LGPL library (the Gnu multi-precision integer library) - unless you take care first to build your own copy of the compiler against the integer-simple package instead of integer-gmp. As far as I know, there are no ready-packaged binary installers for GHC that avoid this LGPL'd dependency. http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes Just saying. The difference between a library being (L)GPLed and this GMP issue is that, in the latter case, we have an escape route. I know of at least two companies which are actively considering switching entirely to simple-integer because of this issue. If a widely used package (e.g., cpphs) is not available under a permissive license, there's not such escape route available to users. (And note that I'm not actually *happy* about the GMP situation, but at least we have a possible solution.) I would strongly recommend reconsidering the licensing decision of cpphs. Even if the LICENSE-commercial is sufficient for non-source releases of software to be protected[1], it introduces a very high overhead for companies to need to analyze a brand new license. Many companies have already decided BSD3, MIT, and a number of other licenses are acceptable. It could be very difficult to explain to a company, Yes, we use this software which says it's LGPL, but it has this special extra license which, if I'm reading it correctly, means you can't be sued, but since the author of the package wrote it himself, I can't really guarantee what its meaning would be in a court of law. Looking at the list of reverse dependencies[2], I see some pretty heavy hitters. Via haskell-src-exts[3] we end up with 75 more reverse dependencies. I'd also like to point out that cpphs is the only non-permissively-licensed dependency for a large number of packages. I can give you more detailed information about my commercial experience privately. But I can tell you that, in the currently situation, I have created projects for clients for which Fay[4] would not be an option due to the cpphs licensing issue. Michael [1] I'm not sure of that, since IANAL. [2] http://packdeps.haskellers.com/reverse/cpphs [3] http://packdeps.haskellers.com/reverse/haskell-src-exts [4] http://packdeps.haskellers.com/licenses/fay ___ 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
On Sat, Dec 15, 2012 at 9:25 AM, Malcolm Wallace malcolm.wall...@me.comwrote: This might a good time to remind everyone that every single program compiled by a standard GHC is linked against an LGPL library (the Gnu multi-precision integer library) - unless you take care first to build your own This is less relevant though, because gmp is not a Haskell library so linking against it doesn't pull significant chunks of its source code into your program. Indeed, many GHC distributions dynamic-link against it, minimizing the legal concerns; and IIRC the gmp license explicitly allows the use GHC makes of it as long as the gmp symbols are not re-exported as part of its API (which they aren't). -- 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
Niklas Larsson metanik...@gmail.com wrote: 2012/12/15 Mike Meyer m...@mired.org: Only if Tanenbaum documented the internal behavior of Linux before it was written. Tannenbaum wrote Minix, the operating system that Linus used (and hacked on) before he did Linux. Minix contained lots of features that was reimplemented in Linux. Ah, Minix isn't documentation. And it has a radically different architecture than either Linux or Unix (which it copied features from). That makes a successful lawsuit unlikely should Tanenbaum pursue one - but you can't say for certain until after a court rules on it. Which is the bottom line in such cases: if the copyright holder doesn't care, it'll never go to court, so there isn't an infringement. Same thing with Stallman, do you think he never saw the Unix sources? Did he ever write anything that was copied from Unix? The Hurd used a completely different architecture than Unix. Emacs predated Unix. By the time he got around to writing a c compiler, there were more from people other than ATT than from ATT. And gcc drew more from the lisp community than from the Unix compilers. -- 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] ANNOUNCE: timeout-with-results
A small library that extends System.Timeout.timeout. It adds the possibility of saving partial results. Useful for AI-like algorithms that should return the best result found within a time limit. It comes in two variants: (1) Simple, which only allows computations to save partial results, not retrieve what has been written already. If a computation times out, the last saved partial result is returned. It comes in two flavours: One that converts saved values to WHNF, the other to NF. (This is required so that the producing thread performs the computations, not the consuming thread.) (2) Based on MonadWriter. The types of partial results have to be monoids. Saving a partial result combines it with the saved value using `mappend`. It also adds the ability to run a contained computation within another one, without disturbing its output. See https://github.com/ppetr/timeout-with-results#examples for examples. Repo:https://github.com/ppetr/timeout-with-results Hackage: http://hackage.haskell.org/package/timeout-with-results (I apologize for not being able to come up with a better package/module names. Suggestions welcomed.) Petr Pudlak ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage down, again?
It looks like hackage is down again. Is it planned or unplanned downtime this time? There doesn't happen to be some mirror of the packages that is a bit more reliable than the original? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay pgpuJ67OiZdLu.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell Splicing
On Sat, Dec 15, 2012 at 9:24 AM, satvik chauhan mystic.sat...@gmail.com wrote:
Yeah, that is the problem. I have a function inside which I need to generate
some declarations using TH. I can not generate these at the top level as
these generations depend on the function's parameters which are local to the
function.
Something like
f p1 p2= ...
where
-- this has to be generated by TH
g_1 = p1
g_2 = p2
g_3 = p1 `xor` p2
something like the above. In the above I have shown only 2 parameters but in
my case it is much more. I am able to get the above splice as toplevel
declaration but I am still unsuccessful in getting it inside the where.
I can always make `g` a function and take parameters of `f` as arguments in
the top level splice but that will defeat the purpose of optimization
here(which I am trying to do), as that would result in a function call every
time I use `g` instead of above variables.
Hi Satvik
Perhaps you could put the variables whose evaluations are shared in a 'let':
f p1 p2 = $(mkG [| g_1 |])
mkG body = liftM2 LetE [d| g_1 = $(dyn p1) |] body
The above example won't work exactly because the two occurences of g_1
are different names. But you could replace the [d| |] with something
that has a [Dec] with variables defined in such a way that they can be
captured.
On a somewhat unrelated note, GHC is less able to infer types for
expression splices than for top level bindings. The issue had
something to do with needing to typecheck all the $( x :: ExpQ ) as a
group, even if the values could be defined in separate modules. It
might not be an issue in your case, but one possible way around it is
have the definition of 'f p1 p2 = ... ' done by template haskell. But
then there is the issue that top level splices are run in order, so
-- this doesn't work:
{-# LANGUAGE TemplateHaskell #-}
[d| y = x |]
[d| x = 1 |]
-- This does work:
{-# LANGUAGE TemplateHaskell #-}
[d| x = 1 |]
[d| y = x |]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage down, again?
new-hackage is down too. On Sat, Dec 15, 2012 at 11:05 AM, Magnus Therning mag...@therning.orgwrote: It looks like hackage is down again. Is it planned or unplanned downtime this time? There doesn't happen to be some mirror of the packages that is a bit more reliable than the original? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay ___ 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
On Sat, 15 Dec 2012 16:14:59 +0100, Brandon Allbery allber...@gmail.com wrote: On Sat, Dec 15, 2012 at 9:01 AM, Petr P petr@gmail.com wrote: So if I put cpphs into build-tools and I don't have it installed, the build will fail? Is this a desired behavior, or a bug? Shortcoming of cabal; it only knows about libraries because it is really just a front-end for ghc-pkg, so can't really figure dependencies involving only executables and not libraries. The same thing comes up with happy, alex, and gtk2hsc2hs. A work-around for this would be to add a dummy library to program-only packages. Regards, Henk-Jan van Tuyl -- 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
[Haskell-cafe] A new FFMPEG library?
The current hs-ffmpeg library is labeled as old on github: https://github.com/anders-/hs-ffmpeg is there a newer one or perhaps an alternative to play media files in haskell? -- Kyle Hanson ___ 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
On Sat, Dec 15, 2012 at 4:38 PM, Henk-Jan van Tuyl hjgt...@chello.nlwrote: On Sat, 15 Dec 2012 16:14:59 +0100, Brandon Allbery allber...@gmail.com wrote: On Sat, Dec 15, 2012 at 9:01 AM, Petr P petr@gmail.com wrote: So if I put cpphs into build-tools and I don't have it installed, the build will fail? Is this a desired behavior, or a bug? Shortcoming of cabal; it only knows about libraries because it is really A work-around for this would be to add a dummy library to program-only packages. But then what do you do about the current case, where the library imports a potentially dubious license dependency? -- 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] Hackage suggestion: Gather the list of the licenses of all dependencies of a package
On 15 Dec 2012, at 16:54, Michael Snoyman wrote: I would strongly recommend reconsidering the licensing decision of cpphs. Even if the LICENSE-commercial is sufficient for non-source releases of software to be protected[1], it introduces a very high overhead for companies to need to analyze a brand new license. Many companies have already decided BSD3, MIT, and a number of other licenses are acceptable. Well, if a company is concerned enough to make an internal policy on open source licences at all, one might hope that they would perform due diligence on them too. For instance, the FSF have lawyers, and have done enough legal work to be able to classify 48 licences as both free and GPL-compatible, a further 39 licences as free but non-GPL-compatible, and 27 open source licences that are neither free nor GPL-compatible. This kind of understanding is what lawyers are supposed to be for. Making them look at another (short) licence is not really a big deal, especially when it closely resembles BSD, which they have already supposedly decided is good. My suspicion, though, is that most of the companies who even think about this question are small, do not have their own lawyers, and are making policy on the hoof, motivated purely by fear. I also suspect that they do not even have the resources to read the licence for each library in its entirety, to determine whether it is in fact BSD3 or MIT, as claimed, or whether someone has subtly altered it. Also, I think I could be pretty confident that there are many shipping products that contain genuine BSD-licensed code, but which do not comply with its terms. It could be very difficult to explain to a company, Yes, we use this software which says it's LGPL, but it has this special extra license which, if I'm reading it correctly, means you can't be sued, but since the author of the package wrote it himself, I can't really guarantee what its meaning would be in a court of law. Like I say, if someone claims the software to be BSD-licensed, someone has to read the licence text itself anyway, to determine whether the claim is true. Pretty much every copy of the BSD licence text differs anyway, at least by the insertion of the authors' names in various places, and sometimes there are varying numbers of clauses. Looking at the list of reverse dependencies[2], I see some pretty heavy hitters. Via haskell-src-exts[3] we end up with 75 more reverse dependencies. I'd also like to point out that cpphs is the only non-permissively-licensed dependency for a large number of packages. I'm glad that cpphs is widely used. I'm also glad that it remains free, and I disagree with you that its dual-licence model is non-permissive. I would like to encourage more Haskell developers to adopt free licensing. Don't be bullied by BSD evangelists! BSD is not the only way to a good citizen of the community! Your libraries can be delivered to clients as products, without you having to give up all rights in them! It's not like I'm saying to companies if you make money out of my code, you have to pay me a fee. All I'm saying, to everyone, is if you notice a bug in my code and fix it, tell me. This is fully compatible with allowing people to release my code to their clients inside products. I can give you more detailed information about my commercial experience privately. But I can tell you that, in the currently situation, I have created projects for clients for which Fay[4] would not be an option due to the cpphs licensing issue. If you are complaining about the crazy policies that many companies adopt about the use of free software within their business, then I have plenty of sympathy for that too. I know of one which has a policy of no use of open source code whatsoever, but runs thousands of linux servers. :-) Also, many companies with large numbers of software engineers on staff apparently prefer to buy crappy commercial products and pay handsomely for non-existent support, instead of running high-quality open-source software with neither initial nor ongoing costs, and where bugfixes are often available the same day as you report the bug. But hey ho. Corporate policy is usually made by people with neither technical nor legal expertise. As regards cpphs, if you don't want to use it because of its licences, that is your choice. You can always use some other implementation of the C pre-processor if you wish. GHC has always refused to distribute cpphs, on the basis of its GPL licence, and instead chose to distribute GNU's gcc on Windows. :-) (I hope you see the irony!) Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage down, again?
A mirror is available here: http://hdiff.luite.com/packages/archive/ See: http://comonad.com/reader/2012/hackage-mirror/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
