Re: [Haskell-cafe] GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
Probably, a considerable part of beginner-programmers (also in our community), who are interested in GPL ideas, may want to use some similar GPL clarification: about being dependent work is not equal to derived work. I guess, an article in haskell-wiki (clarifying situation with GPL) would be nice to have. IMHO they shouldn't equalize terms dependent and deriving - that's just silly. Reagards, Andrey Rafael Almeida wrote: On Fri, Mar 5, 2010 at 2:59 PM, Job Vranish job.vran...@gmail.com wrote: Linux license specifically single that case out of the license restrictions. From the COPYING file in linux's source: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of derived work. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- View this message in context: http://old.nabble.com/GPL-answers-from-the-SFLC-%28WAS%3A-Re%3A-ANN%3A-hakyll-0.1%29-tp27783997p27803729.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell platform for GHC 6.12.1?
That and all Cabal 0.8 binaries on Windows suffer from zlib corrupted stream issues. I've got cabal-install binary, but it's not worth distributing :-( There is a cabal ticket for this. Thanks, Neil On Fri, Mar 5, 2010 at 11:27 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Andrew Coppin andrewcop...@btinternet.com writes: Is there a reason why a new precompiled binary can't be put up for download? I would assume because no-one has supplied one (Duncan doesn't use Windows; don't know about the rest of the cabal-install developers). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Real-time garbage collection for Haskell
On 06/03/10 06:56, Simon Cranshaw wrote: For settings we are using -N7 -A8m -qg. I'm surprised if turning off parallel GC improves things, unless you really aren't using all the cores (ThreadScope will tell you that). Do these flags give you an improvement in throughput, or just pause times? I don't know if they are really the optimal values but I haven't found a significant improvement on these yet. I tried -qb but that was slow. Interesting, I often find that -qb improves things. I tried larger values of A but that didn't seem to make a big difference. -A8m is close to the size of your L2 caches, right? That will certainly be better than the default of -A512k. Also -N6 didn't make much difference. Specifying H values didn't seem to make much difference. -H is certainly a mixed bag when it comes to parallel programs. I have to admit I don't fully understand the implications of the values and was just experimenting to see what worked best. So the heap size is trading off locality (cache hits) against GC time. The larger the heap, the fewer GCs you do, but the worse the locality. Usually I find keeping the nursery size (-A) close to the L2 cache size works best, although sometimes making it really big can be even better. -qg disables parallel GC completely. This is usually terrible for locality, because every GC will move all the recently allocated data from each CPU's L2 cache into the cache of the CPU doing GC, where it will have to be fetched out again after GC. -qb disables load-balancing in the parallel GC, which improves locality at the expense of parallelism, usually I find it is an improvement in parallel programs. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell platform for GHC 6.12.1?
Have you tried compiling cabal-install with GHC 6.12.1? I got these stream errors after I compiled it with 6.10.4, but with 6.12.1 it's working flawless. 2010/3/6 Neil Mitchell ndmitch...@gmail.com That and all Cabal 0.8 binaries on Windows suffer from zlib corrupted stream issues. I've got cabal-install binary, but it's not worth distributing :-( There is a cabal ticket for this. Thanks, Neil On Fri, Mar 5, 2010 at 11:27 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Andrew Coppin andrewcop...@btinternet.com writes: Is there a reason why a new precompiled binary can't be put up for download? I would assume because no-one has supplied one (Duncan doesn't use Windows; don't know about the rest of the cabal-install developers). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to obtain unique integers
On 05/03/10 21:36 Thomas Schilling wrote: I'm not sure why you need these uniques in the Show instances, though. Can't you just store the IDs with your data? No. I need to be able to print names of these unique variables. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell platform for GHC 6.12.1?
Have you tried compiling cabal-install with GHC 6.12.1? I got these stream errors after I compiled it with 6.10.4, but with 6.12.1 it's working flawless. Woohoo, your tip works! Thanks a lot. Neil 2010/3/6 Neil Mitchell ndmitch...@gmail.com That and all Cabal 0.8 binaries on Windows suffer from zlib corrupted stream issues. I've got cabal-install binary, but it's not worth distributing :-( There is a cabal ticket for this. Thanks, Neil On Fri, Mar 5, 2010 at 11:27 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Andrew Coppin andrewcop...@btinternet.com writes: Is there a reason why a new precompiled binary can't be put up for download? I would assume because no-one has supplied one (Duncan doesn't use Windows; don't know about the rest of the cabal-install developers). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
2010/3/5 Maurício CA mauricio.antu...@gmail.com To my knowledge, the LGPL only allows *linking* with non-(L)GPL software. But GHC doesn't just link but performs massive cross-module inlining. So in my opinion, LGPL is not a solution, too. Use BSD3! But that massive cross-module inlining happens at your computer, where the rights allowed by GPL for private use applies. Not if I ship you a statically linked binary. You assume everyone compiles my Haskell source code :-). So, as long as you distribute the GPL/LGPL code separate from your BSD/proprietary code, no restrictions should apply. (I believe this applies even with GPL, as all you'll be using in your code is the API which, as far as I know, can't be copyrighted, like any kind of interface -- even hardware interface. But I can't find a source on that.) This is not suitable for everyone. Best, Maurício ___ 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] ghc leaking memory?
Hi, in Debian, we are having some problems building large libraries (such as agda, highlighting-kate, xmonad-contrib) on weaker architectures (sparc, armel, s390) which compile with -fvia-C, especially when building the profiling libraries. In the case of highlighting-kate, there were really issues with the code: A huge list of words which ghc seemed to try to inline caused it consuming a lot of memory. But in the case of agda, it even fails with relatively small modules: https://buildd.debian.org/fetch.cgi?pkg=agdaarch=sparcver=2.2.6-3stamp=1267334936file=logas=raw Now, looking at the memory gauge on my computer while compiling such a program with Cabal (which compiles all modules in one ghc call), it looks like it is steadily increasing. I’d expect ghc to free a lot of memory when it is done with a module, but this does not seem to be the case. Is this a bug (i.e. memory leak) in ghc or expected behavior? Is there a way to make Cabal build each module on its own? Are there any fixes or work-arounds? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc leaking memory?
Including ghc-users. On Sat, Mar 6, 2010 at 11:57 AM, Joachim Breitner nome...@debian.org wrote: Hi, in Debian, we are having some problems building large libraries (such as agda, highlighting-kate, xmonad-contrib) on weaker architectures (sparc, armel, s390) which compile with -fvia-C, especially when building the profiling libraries. In the case of highlighting-kate, there were really issues with the code: A huge list of words which ghc seemed to try to inline caused it consuming a lot of memory. But in the case of agda, it even fails with relatively small modules: https://buildd.debian.org/fetch.cgi?pkg=agdaarch=sparcver=2.2.6-3stamp=1267334936file=logas=raw Now, looking at the memory gauge on my computer while compiling such a program with Cabal (which compiles all modules in one ghc call), it looks like it is steadily increasing. I’d expect ghc to free a lot of memory when it is done with a module, but this does not seem to be the case. Is this a bug (i.e. memory leak) in ghc or expected behavior? Is there a way to make Cabal build each module on its own? Are there any fixes or work-arounds? Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata ___ 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] ghc leaking memory?
Sounds like the known issue of ghc --make (the compilation manager) retaining meta data (like .hi file info) when compiling many modules. This isn't the case with one-shot compiltation. I'm not sure there's anything you can do about it. aslatter: Including ghc-users. On Sat, Mar 6, 2010 at 11:57 AM, Joachim Breitner nome...@debian.org wrote: Hi, in Debian, we are having some problems building large libraries (such as agda, highlighting-kate, xmonad-contrib) on weaker architectures (sparc, armel, s390) which compile with -fvia-C, especially when building the profiling libraries. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Books for advanced Haskell
Günther, A shining example are Dan Piponis blog posts. When you get stuck, post a comment saying where so that I can learn what people find difficult. On the other hand, I understand how intangible not-understanding can be, so it can be hard to point to where the problem is. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
Am Samstag, 6. März 2010 03:45:02 schrieb Maciej Piechotka: PS. There is also GPL-with-linking-exception which allows linking etc. but does not require relinking capability. I'd believe that in such case the cross-module inlining is not a problem since it is 'linking' for compiler. The term “linking” is quite well-defined in computer science. You seem to redefine it and assume that copyright holders will accept your redefinition. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Books for advanced Haskell
Hello Dan, sorry, I did not mean to single you out, I love your stuff. But I can't find the thread through it, I pretty much lack basics / fundamentals to digest it. But I do see *power* and it bugs the crap out of me that I can't grasp it yet. One example was your response to my DSL posts on this list, where you said that in a way ever/any? monad can be considered a DSL. At that time I was totally unable to understand the sentence as such nor its significance. I kinda was focused on the finally tagless approach from Oleg for DSLs. Now that I do understand the significance of that statement I try to really figure it out. Mostly it finally occurred to me because of Heinrich Apfelmus's Operational monad tutorial. Which I have no means of comprehending either because he's using GADTs. From your blog I got the impression that you focus on monads, but I may have gotten that wrong. You seem to be able to take this a very long way, without using much fancy type level arithmetic or elaborate class schemes. That gives me hope in a way because so far I'm not happy with serious type-level programming. Right now I'm reading J. Hughes '95 paper The design of a pretty printing library which I believe I can grasp, may even before the years end. Would you consider creating a guide through your blog, something like read this first, then that? Günther Am 06.03.10 21:14, schrieb Dan Piponi: Günther, A shining example are Dan Piponis blog posts. When you get stuck, post a comment saying where so that I can learn what people find difficult. On the other hand, I understand how intangible not-understanding can be, so it can be hard to point to where the problem is. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Books for advanced Haskell
Hi John, please, do try. Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghc leaking memory?
Joachim Breitner nome...@debian.org writes: In the case of highlighting-kate, there were really issues with the code: A huge list of words which ghc seemed to try to inline caused it consuming a lot of memory. This is a known problem; so much so that John is writing a new library illuminate [1] to replace it. [1] http://github.com/jgm/illuminate -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A few ideas about FRP and arbitrary access in time
On Wed, Mar 3, 2010 at 8:45 PM, sinelaw jones.noa...@gmail.com wrote: But isn't Lucid Synchrone essentially discrete-timed? Also, events Maybe reality itself can also be modeled using discrete timesteps? If so, then a discrete clock calculus might make a lot of sense. I don't know much about theoretical physics - I think general relativity still is the best model for time, and it's continuous in that model - but maybe the people with a PhD in physics know more about it :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
