Re: [Haskell-cafe] Optimal line length for haskell
I also stick to a pretty rigid 78 characters. Doing so actually helps me fit more code onto my screen at a time because I usually have two or three columns of open files side by side. I find that I need this more often than I need to see a single function on a page (thanks to Haskell's traditionally small functions). But this works for single functions as well because I can open the same file in multiple columns at different locations in the file. The ideal line length for text layout is based on the physiology of the human eye… At normal reading distance the arc of the visual field is only a few inches – about the width of a well-designed column of text, or about 12 words per line. Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text. Web Style Guide – Basic Design Principles for Creating Website Patrick J. Lynch and Sarah Horton 2nd edition, page 97. On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur jake.mcart...@gmail.com wrote: I stick to 80 columns fairly rigidly. This is not only so that it fits into narrow windows, but also so that any two subexpressions in the same expression tend to be close together on my screen, which makes it easier for me to reason about it. If only it was easy for me to read and write code on a Hilbert curve... :) I don't think long lines indicate a design problem; it's solely a formatting thing. On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody rustompm...@gmail.com wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] Thanks, Rusi ___ 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] Optimal line length for haskell
I frequently find myself wanting to look at one file while coding in another file so I can see type signatures, data type definitions, etc. If I only have one file fullscreen, then I would have to switch back and forth to refresh my mind with API information. If your max lines are sometimes 200 chars, then you're going to have tons of wasted screen space from all the other lines that aren't 200 characters wide. On Mon, Oct 29, 2012 at 4:44 PM, Marc Ziegert co...@gmx.de wrote: O_o Those are damn strange reasons to restrict oneself to 80 chars, iMho. I tend to look at ONE file at a time, on one fullscreen widescreen. 100 chars per line is more or less normal; I have my vertical line limit marker set to 100, but only for layout-zen. My lines have sometimes 200 chars length, which causes the less important (long) code not to clutter my overview on the 50 neighbouring lines (~10 functions overview on the left half of the screen). Otherwise, I'd use a browser/Haddock on one part of the screen just to see an overview of the code I'm writing. I'm now wondering, whether this could have sth to do with my ADD, which I had the first 3 decades of my life (and without whiteboard). I think, I should try to code in a small narrow window of 1/4 of my screen, just to test whether that would (still) be a handicap. Roman: academic background... Funny; my impression about this matter was from the other point of view: Short lines are good for diff/patch files. Are there more people here with ADD (or ADD-history) and long-lines-disorder? Or is that just me? - marc Original-Nachricht Datum: Mon, 29 Oct 2012 11:32:29 -0400 Von: MightyByte mightyb...@gmail.com An: Jake McArthur jake.mcart...@gmail.com CC: Haskell Cafe haskell-cafe@haskell.org Betreff: Re: [Haskell-cafe] Optimal line length for haskell I also stick to a pretty rigid 78 characters. Doing so actually helps me fit more code onto my screen at a time because I usually have two or three columns of open files side by side. I find that I need this more often than I need to see a single function on a page (thanks to Haskell's traditionally small functions). But this works for single functions as well because I can open the same file in multiple columns at different locations in the file. The ideal line length for text layout is based on the physiology of the human eye… At normal reading distance the arc of the visual field is only a few inches – about the width of a well-designed column of text, or about 12 words per line. Research shows that reading slows and retention rates fall as line length begins to exceed the ideal width, because the reader then needs to use the muscles of the eye and neck to track from the end of one line to the beginning of the next line. If the eye must traverse great distances on the page, the reader is easily lost and must hunt for the beginning of the next line. Quantitative studies show that moderate line lengths significantly increase the legibility of text. Web Style Guide – Basic Design Principles for Creating Website Patrick J. Lynch and Sarah Horton 2nd edition, page 97. On Mon, Oct 29, 2012 at 10:37 AM, Jake McArthur jake.mcart...@gmail.com wrote: I stick to 80 columns fairly rigidly. This is not only so that it fits into narrow windows, but also so that any two subexpressions in the same expression tend to be close together on my screen, which makes it easier for me to reason about it. If only it was easy for me to read and write code on a Hilbert curve... :) I don't think long lines indicate a design problem; it's solely a formatting thing. On Mon, Oct 29, 2012 at 7:50 AM, Rustom Mody rustompm...@gmail.com wrote: There was a recent discussion on the python list regarding maximum line length. It occured to me that beautiful haskell programs tend to be plump (ie have long lines) compared to other languages whose programs are 'skinnier'. My thoughts on this are at http://blog.languager.org/2012/10/layout-imperative-in-functional.html. Are there more striking examples than the lexer from the standard prelude? [Or any other thoughts/opinions :-) ] Thanks, Rusi ___ 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 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments (in deutsch: http://www.gerstbach.at/2004/ascii/) ___ Haskell-Cafe mailing list Haskell-Cafe
Re: [Haskell-cafe] [Snap] Argument Substitution in Heist Templates with Splices
This is one of the more subtle corner cases of Heist. My default, splices
are recursively processed. So when testSplice is executed for the test
tag, the results are fed back into splice processing. I think this is the
right thing to do because it makes behavior less sensitive to evaluation
order. Obviously this can lead to infinite recursion, so Heist limits the
splice call stack to a depth of 50. If this limit is exceeded, then Heist
simply stops recursing and returns the nodes unprocessed. I also think
this is the right thing to do because it is happening as we're serving a
page to the end user, so there's an argument for failing quietly instead of
going up in a ball of flames.
In your case, you are returning the same node that was spliced in, so you
are hitting the recursion limit and splice processing just stops. I
discuss this issue in my blog post about splice subtleties (
http://softwaresimply.blogspot.com/2011/04/splice-subtleties.html). Since
you're writing a filter splice, you need to call stopRecursion. But if you
do that, then the child arg / tag won't be processed. So what you need
to do is use the runChildren function to process the child nodes, then
return them in whatever your constructed node is.
I think the easiest solution to your problem is to not write it as a filter
splice. Bind your testSplice function to the mytest tag and return a
test tag. This avoids the infinite recursion and will work the way you
want without needing stopRecursion.
On Thu, Sep 20, 2012 at 3:00 PM, Sebastian Fischer m...@sebfisch.de wrote:
Hello,
the following program demonstrates that arguments in Heist templates
are sometimes not substituted in presence of splices:
{-# LANGUAGE OverloadedStrings #-}
import Blaze.ByteString.Builder (toByteString)
import qualified Data.ByteString.Char8as BS
import Data.Functor (($))
import Data.Maybe (fromJust)
import Text.Templating.Heist
-- just return input node unchanged
testSplice :: Splice IO
testSplice = (:[]) $ getParamNode
main = do
writeFile test.tpl arg /test attr='${arg}'arg //test
state - either error id $ loadTemplates . defaultHeistState
(builder,_) - fromJust $ renderWithArgs [(arg,42)] state test
BS.putStrLn $ toByteString builder
-- 42test attr='42'42/test
let state' = bindSplices [(test,testSplice)] state
(builder',_) - fromJust $ renderWithArgs [(arg,42)] state'
test
BS.putStrLn $ toByteString builder'
-- 42test attr='42'arg/arg/test
Without using splices, all occurrences of 'arg' in the template are
substituted. When using a splice, 'arg' is not substituted underneath
the input node of the splice. It is substituted in an attribute of the
input node.
Is this intentional? How can I ensure substitution also underneath the
input node?
Best,
Sebastian
___
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] Build regressions due to GHC 7.6
Interesting data point. I think my initial thoughts can be summarized with the suggestion that this thread would be better served by a little irony and a new subject: Reuse Considered Harmful. On Thu, Aug 30, 2012 at 1:26 AM, Bryan O'Sullivan b...@serpentine.comwrote: Since the release of the GHC 7.6 RC, I've been going through my packages and fixing up build problems so that people who upgrade to 7.6 will have a smooth ride. Sad to say, my experience of 7.6 is that it has felt like a particularly rough release for backwards incompatibility. I wanted to quantify the pain, so I did some research, and here's what I found. I maintain 25 open source Haskell packages. Of these, the majority have needed updates due to the GHC 7.6 release: - base16-bytestring - blaze-textual - bloomfilter - configurator - criterion - double-conversion - filemanip - HDBC-mysql - mwc-random - pcap - pool - riak-haskell-client - snappy - text - text-format - text-icu That's 16 out of 25 packages I've had to update. I've also either reported bugs on, or had to fix, several other people's packages along the way (maybe four?). So let's say I've run into problems with 20 out of the combined 29 packages of mine and my upstreams. The reasons for these problems fall into three bins: - Prelude no longer exports catch, so a lot of import Prelude hiding (catch) had to change. - The FFI now requires constructors to be visible, so CInt has to be imported as CInt(..). - bytestring finally got bumped to 0.10, so many upper bounds had to be relaxed (*cf* my suggestion that the upper-bounds-by-default policy is destructive). It has been a lot of work to test 29 packages, and then modify, rebuild, and release 20 of them. It has consumed most of my limited free time for almost two weeks. Worse, this has felt like make-work, of no practical benefit to anyone beyond scrambling to restore the status quo ante. If over half of my packages needed fixing, I'm alarmed at the thought of the effects on the rest of Hackage. I'm torn over this. I understand and agree with the impetus to improve the platform by tidying things up, and yet just two seemingly innocuous changes (catch and FFI) have forced me to do a bunch of running to stand still. I don't have any suggestions about what to do; I know that it's hard to estimate the downstream effects of what look like small changes. And so I'm not exactly complaining. Call this an unhappy data point. ___ 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] ANNOUNCE: readable-0.1
I'm happy to announce a new package called readable: http://hackage.haskell.org/package/readable This package provides simple reading of data types from ByteString and Text using MonadPlus to handle failure. It doesn't seem like there's a standard way to do simple reading from ByteString and Text, so hopefully this package will fill the gap. Suggestions/improvements are most welcome. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Platform Versioning Policy: upper bounds are not our friends
On Wed, Aug 15, 2012 at 9:19 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 16 August 2012 08:55, Brandon Allbery allber...@gmail.com wrote: Indeed. But the ghc release that split up base broke cabalised packages with no warning to users until they failed to compile. Upper bounds were put in place to avoid that kind of breakage in the future. I like having upper bounds on version numbers... right up until people abuse them. I also tend to favor having upper bounds. Obviously they impose a cost, but it's not clear to me at all that getting rid of them is a better tradeoff. I've had projects that I put aside for awhile only to come back and discover that they would no longer build because I hadn't put upper bounds on all my package dependencies. With no upper bounds, a package might not be very likely to break for incremental version bumps, but eventually it *will* break. And when it does it's a huge pain to get it building again. If I have put effort into making a specific version of my package work properly today, I want it to always work properly in the future (assuming that everyone obeys the PVP). I don't think it's unreasonable that some activation energy be required to allow one's project to work with a new version of some upstream dependency. Is that activation energy too high right now? Almost definitely. But that's a tool problem, not a problem with the existence of upper bounds themselves. One tool-based way to help with this problem would be to add a flag to Cabal/cabal-install that would cause it to ignore upper bounds. (Frankly, I think it would also be great if Cabal/cabal-install enforced upper version bounds automatically if none were specified.) Another approach that has been discussed is detecting dependencies that are only used internally[1], and I'm sure there are many other possibilities. In short, I think we should be moving more towards purely functional builds that reduce the chance that external factors will break things, and it seems like removing upper version bounds is a step in the other direction. [1] http://cdsmith.wordpress.com/2011/01/21/a-recap-about-cabal-and-haskell-libraries/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Martin Odersky on What's wrong with Monads
Tillmann Rendel rendel at informatik.uni-marburg.de writes: Which drawbacks do you see besides increased verbosity? Well, you did change the equation amount (Leaf x) = x to amount fun (Leaf x) = x. In a larger example, this means that you need to change many lines of many functions, just to get the the value of fun from the point where it is known to the point where you need it. I would argue that no matter how good one's language is, there will always exist realistic refactorings that require you to make sweeping changes to a large portion of your code base. [...] I am wondering which ways of doing this in Haskell you mean. I thought of the following three options, but see also Nathan Howells email for another alternative (that is related to my option (1) below): (1) Implicit parameters: snip (2) Lexical Scoping: snip (3) UnsafePerformIO: snip I'm not happy with any of these options. Personally, I would probably go ahead and transform the whole program just to get the value of fun to where it is needed. Nevertheless, having actually done this before, I understand why Martin Odersky doesn't like doing it :) I think that Martin's statement is an unavoidable fact of life that follows directly from the definition of purity and the mechanics of data dependencies. Of course nobody likes making sweeping changes to their app because they didn't anticipate the way the future would evolve. But lets not blame monads for what is really a much more fundamental phenomenon. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Martin Odersky on What's wrong with Monads
Jonathan Geddes geddes.jonathan at gmail.com writes: Cafe, I was watching a panel on languages[0] recently and Martin Odersky (the creator of Scala) said something about Monads: What's wrong with Monads is that if you go into a Monad you have to change your whole syntax from scratch. Every single line of your program changes if you get it in or out of a Monad. They're not polymorphic so it's really the old days of Pascal. A monomorphic type system that says 'well that's all I do' ... there's no way to abstract over things. [0, 53:45] Thoughts? In my mind, his first sentence could be paraphrased as follows: What's wrong with having a strongly typed mechanism for separating pure and effectful code is that pure code and effectful code are actually separate. Of course every line of your program that uses a Foo will change if you switch to IO Foo instead. If the two were indistinguishable, then you'd have an impure language instead of a pure one. Furthermore, this isn't a characteristic specific to monads, it's the same for any type constructor whether it's a monad or not. To Martin's credit, earlier in the talk (around 45:15) he makes the following statement: What you need in the language is the ability to essentially reduce state. And potentially what Scala doesn't do, but for instance Haskell does is to control state and purity, and I think that might be the next frontier. Then at 50:15 he says, So right now, I think...in the world of effect checking we're about where we were with Pascal in terms of static typing. It seems that his heart is in the right place, but he isn't aware of where we actually are right now, and probably doesn't fully appreciate the consequences of strongly typed purity. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GSOC Proposal 2012 : HDBC
pranjal pandit pranjal5215 at gmail.com writes: Hi,I would like to work on improving the HDBC as a GSOC project 2012. I have a previous working experience with Django and its ORM and I had a look at Amnesia (http://amnesia.sourceforge.net/user_manual/manual.html) which is a SQL database interface for Erlang. Few of the features of both include: 1 ) Database operation are supported through Language Native types. 2 ) Direct table creation from native language constructs. Hi Pranjal, Here are some things to consider when writing your proposal. Haskell RDBMS libraries exist on two different broad levels of abstraction. There are low-level libraries that provide the ability to write raw SQL queries and retrieve the results, and there are high-level libraries that do more sophisticated things. These high-level libraries are more of what you're probably thinking about when you think ORM. HDBC and others like mysql-simple, postgresql-simple, etc are in the low-level category. The high-level category has libraries like haskelldb, persistent, and groundhog. In some cases the high-level libraries are written using a low-level library as the back-end. Haskelldb is a good example of this because it uses HDBC for its low-level access. HDBC provides a uniform interface for working with MySQL, PostgreSQL, and SQLite so by using HDBC, haskelldb works with all these databases for free. However, some high-level libraries like persistent don't use a separate low-level library and instead opt to maintain their own code for interfacing directly with the database. There are a number of different approaches one could take in the implementation of a Haskell ORM like you have described. It is a big enough problem that I think you need to focus on a smaller, more specific goal for a GSoC proposal. If you are interested in the high-level ORM side of the problem, check out the links Greg Weber mentioned for the persistent project. Improving HDBC is also a great idea for a project. It currently has some significant performance issues because of its use of String. There's a ticket for this at http://hackage.haskell.org/trac/summer-of-code/ticket/1598. Improvements to HDBC would also benefit other high-level libraries like haskelldb that use HDBC as a back-end, so Google might consider such a project to have more impact per developer hour spent. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Software Deployment and Distribution - WAS Re: CUFP mailing list
Fundamentally, Software Copy Protection (as well as DRM) is an unsolvable problem. It's basically like saying that you want to give someone something and not give it to them at the same time. With physical products there are physical properties that you can use to accomplish some aspects of this. But with information products and the possibility of essentially zero-cost copying you don't have these physical constraints to help you. Copy Protection (CP) and DRM advocates have tried to use cryptography to solve this problem. The idea being that cryptography lets you hide information from people, so it should be able to help with this problem. Encryption allows Alice and Bob to communicate secretly without Eve, Mallet, etc from being able to read their communication. This is all predicated on the idea that Alice and Bob trust each other. (I'm only going to reveal my secrets to you if I trust that you're not going to publish them for others to read.) The problem that CP (Alice) is up against is that Bob and Eve are the same person! If you can't trust the person to whom you're sending something, then the only secure solution is not to send it to them. This can be done by delivering software that simply doesn't have certain capabilities. You typically can't just disable the capabilities in your software. You have to ensure that the code implementing those capabilities is not present. Software as a service is another solution to this problem. On Mon, Mar 22, 2010 at 6:09 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Günther Schmidt wrote: I've written a commercial Desktop application in Haskell for the Win32 platform. The one thing missing is Software Copy Protection, ie. a software licensing mechanism. When I google for Software Copy Protection I get a lot of results, commercial products themselves, which is fine, but I can't tell which ones are any good or worth their money. I've never seriously done C#, VB or whatever people mainly write Win32 apps in, so I don't know any mailing lista or forums where I could ask this question. This list has pretty much been the only list I used for more than 2 years now. I've never seen a similar issued raised here before so I thought the CUFP mailing list is a better place for this. Can anybody here recommend a good software for this then? I do not want to code it myself and would prefer a ready to use solution, it it's not free that fine too. Well that certainly is an unusual question. There are large companies like Apple, the RIAA and the MPAA who have put large amounts of time, money and effort into copy protection schemes only to have them broken, sometimes in as little as a day or two. In addition, by the time you have a copy control mechanism that is partially effective your users may find the experience so painful that using cracked copies is easier. There is a common theme here: http://i.imgur.com/GxzeV.jpg http://www.bradcolbow.com/archive.php/?p=205 http://xkcd.com/488/ Erik -- -- Erik de Castro Lopo http://www.mega-nerd.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] search Data.Tree.Zipper
I haven't tested it, but I think you're looking for something like this: searchTree2 :: (a - Bool) - TreeLoc a - Maybe (TreeLoc a) searchTree2 pred rootLoc = if pred (getLabel rootLoc) then Just rootLoc else firstChild rootLoc = siblings where siblings loc = searchTree2 pred loc `mplus` (searchTree2 pred = right loc) On Mon, Mar 8, 2010 at 1:11 PM, Jian Fan abe...@gmail.com wrote: Hi, There doesn't seem to be a function to search the tree so I come up with following function: searchTree :: (a - Bool) - TreeLoc a - Maybe (TreeLoc a) searchTree pred rootLoc = if pred (getLabel rootLoc) then Just rootLoc else case firstChild rootLoc of Just loc - case searchTree pred loc of Just loc - Just loc Nothing - case right loc of Just rLoc - searchTree pred rLoc Nothing - Nothing Nothing - Nothing Which feels quite ugly. Any suggestions? Thanks. Jian ___ 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] GPL answers from the SFLC (WAS: Re: ANN: hakyll-0.1)
Interesting. It seems to me that the only solution for the BSD-oriented haskell community is to practically boycott GPL'd libraries. From what I understand, this is exactly what the LGPL is for. I've known the basic idea behind the GPL/LGPL distinction for quite awhile, but I didn't realize that mistaking the two had such far-ranging consequences. Since GPL seems to be the big elephant in the room, it seems very easy to make this mistake. At the very least we should try to educate the community about this. On Thu, Mar 4, 2010 at 12:34 PM, Tom Tobin korp...@korpios.com wrote: After politely pestering them again, I finally heard back from the Software Freedom Law Center regarding our GPL questions (quoted below). I exchanged several emails to clarify the particular issues; in short, the answers are No, No, N/A, and N/A. The SFLC holds that a library that depends on a GPL'd library must in turn be GPL'd, even if the library is only distributed as source and not in binary form. They offered to draft some sort of explicit response if we'd find it useful. Maybe it would be useful if Cabal had some sort of licensing check command that could be run on a .cabal file, and warn an author if any libraries it depends on (directly or indirectly) are GPL'd but the .cabal itself does not have the license set to GPL. On Fri, Dec 11, 2009 at 10:21 PM, Tom Tobin korp...@korpios.com wrote: I'd like to get these questions out to the SFLC so we can satisfy our curiosity; at the moment, here's what I'd be asking: Background: X is a library distributed under the terms of the GPL. Y is another library which calls external functions in the API of X, and requires X to compile. X and Y have different authors. 1) Can the author of Y legally distribute the *source* of Y under a non-GPL license, such as the 3-clause BSD license or the MIT license? 2) If the answer to 1 is no, is there *any* circumstance under which the author of Y can distribute the source of Y under a non-GPL license? 3) If the answer to 1 is yes, what specifically would trigger the redistribution of a work in this scenario under the GPL? Is it the distribution of X+Y *together* (whether in source or binary form)? 4) If the answer to 1 is yes, does this mean that a BSD-licensed library does not necessarily mean that closed-source software can be distributed which is based upon such a library (if it so happens that the library in turn depends on a copylefted library)? By the way, apologies to the author of Hakyll — I'm sure this isn't what you had in mind when you announced your library! I'm just hoping that we can figure out what our obligations are based upon the GPL, since I'm not so sure myself anymore. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the meaning of tilde (~) symbol
I like that idea. When I was first learning Haskell, I remember spending a non-trivial amount of time trying to figure out what '$' did. I incorrectly assumed that it was provided by some library. '!' and '~' would certainly be other good candidates for this kind of a page. These types of things can be pretty hard to google. On Sun, Feb 14, 2010 at 8:24 AM, Andrew Coppin andrewcop...@btinternet.com wrote: Here's an idea... maybe we should make a small page on the Wiki explaining what all the various symbols in Haskell mean? There are a couple which are rare enough that most tutorials don't mention them that often. And there are of course symbols which mean different things in different contexts. (I especially love how curly braces are used for overriding layout *and* for named fields...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What is the meaning of tilde (~) symbol
On Sun, Feb 14, 2010 at 8:39 AM, Andrew Coppin andrewcop...@btinternet.com wrote: MightyByte wrote: I like that idea. When I was first learning Haskell, I remember spending a non-trivial amount of time trying to figure out what '$' did. I incorrectly assumed that it was provided by some library. Technically, it is... Hmmm, both Hoogle and Hayoo give me the right answer when I search for '$'. For some reason I thought I had tried that without success. However, I'm pretty sure that was before Hayoo came out; and maybe Hoogle wasn't as good in those days. At any rate, they still don't help for things like '~', so there's definitely a use for a wiki page like this. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Using Cabal during development
On Thu, Feb 11, 2010 at 5:28 AM, Limestraël limestr...@gmail.com wrote: Eventually, I think using cabal during development may be convenient. The only drawback is that you have to specify each dependency... I actually think this is a benefit, not a drawback. In one of my projects where I used makefiles, I was depending on a variety of hackage projects. I was using development code from one of these that had not yet made it onto hackage. There was a period of time where I didn't do much development, and when I came back, I updated to the most recent development code and discovered that it broke my build. Since I didn't have all my dependencies specified and didn't know which devel version I had been using, I was unable to build the project until I fixed all the places where the update to the other package broke my code. If you are on a tight time schedule, this could be very problematic, whereas if you had specified the dependencies, cabal would easily be able to get the right versions for you. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] various dependencies breakages
The latest darcs head for happstack has changed the quickcheck dependency to 2. You might try that. On Tue, Feb 9, 2010 at 7:13 AM, Thomas Girod tho...@0xc29.net wrote: thanks Lars and Max. It did the trick, except for one small detail : MissingH needs the testpack -any dependency, but cabal does not install it automatically. tom ___ 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: sendfile leaking descriptors on Linux?
I've been seeing a steady stream of similar resource vanished messages for as long as I've been running my happstack app. This message I get is this: socket: 58: hClose: resource vanished (Broken pipe) I run my app from a shell script inside a while true loop, so it automatically gets restarted if it crashes. This incurs no more than a few seconds of down time. Since that is acceptable for my application, I've never put much effort into investigating the issue. But I don't think the resource vanished error results in program termination. When I have looked into it, I've had similar trouble reproducing it. Clients such as wget and firefox don't seem to cause the problem. If I remember correctly it only happens with IE. On Fri, Feb 5, 2010 at 2:56 AM, Bardur Arantsson s...@scientician.net wrote: Jeremy Shaw wrote: Actually, We should start by testing if native sendfile leaks file descriptors even when the whole file is sent. We have a test suite, but I am not sure if it tests for file handle leaking... I should have posted this earlier, but the exact message I'm seeing in the case where the Bad Client disconnects is this: hums: Network.Socket.SendFile.Linux: resource vanished (Broken pipe) Oddly, I haven't been able to reproduce this using a wget client with a ^C during transfer. When I disconnect wget with ^C or pkill wget or even pkill -9 wget, I get this message: hums: Network.Socket.SendFile.Linux: resource vanished (Connection reset by peer) (and no leak, as observed by lsof | grep hums). So there appears to be some vital difference between the handling of the two cases. Another observation which may be useful: Before the sendfile' API change (Handle - FilePath) in sendfile-0.6.x, my code used withFile to open the file and to ensure that it was closed. So it seems that withBinaryFile *should* also be fine. Unless the Broken pipe error somehow escapes the scope without causing a close. I don't have time to dig more right now, but I'll try to see if I can find out more later. Cheers, ___ 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] Anyone recommend a VPS?
Hi, I'm also a happy linode customer. However, my happstack app eats a lot of memory. I currently have plans to switch to prgmr.com because their hosting plans give you much more RAM / dollar than any other hosting company I've seen ($20 / month for a gig of RAM). On Sun, Jan 31, 2010 at 4:37 PM, Michael Snoyman mich...@snoyman.com wrote: OK, I guess the unananimous opinion in linode ;). Thanks for the input everyone! Michael On Sun, Jan 31, 2010 at 11:29 PM, Marc Weber marco-owe...@gmx.de wrote: I'm a happy linode customer: http://www.linode.com/ Me too. I tried different hosting services before. They all have there strength. The linode shell is terrific! If all you want is standard debian or such it does'nt matter. However I tried installing NixOS Linux and I've had lot's of trouble until switching to linode. NixOS was up and running within 30min then.. Marc Weber ___ 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] on Happstack - embedded HTML
The example you came across is probably using HSP [1] to generate HTML. Happstack isn't tied to a specific method of generating HTML. You could use HSP or other libraries such as html-minimalist [2], xhtml [3], HStringTemplate [4], or even plain old manual construction of strings. [1] http://www.cs.chalmers.se/~d00nibro/hsp/ [2] http://hackage.haskell.org/package/html-minimalist [3] http://hackage.haskell.org/package/xhtml [4] http://hackage.haskell.org/package/HStringTemplate 2010/1/12 Günther Schmidt gue.schm...@web.de: Hi, I'm just introducing myself to Happstack. I come across an example page where HTML and haskell code is mixed. Is this how happstack produces html, it's haskell code embedded in HTML? Günther ___ 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] looking for origin of quote on preprocessors and language design
It strikes me that this question may be related (perhaps distantly) to Godel's incompleteness theorem. Anyone else see similarities here? On Thu, Jan 7, 2010 at 7:32 AM, Johannes Waldmann waldm...@imn.htwk-leipzig.de wrote: Dear all, It's not exactly Haskell-specific, but ... I am trying to track down the origin of the proverb the existence (or: need for) a preprocessor shows omissions in (the design of) a language. I like to think that in Haskell, we don't need preprocessors since we can manipulate programs programmatically, because they are data. In other words, a preprocessor realizes higher order functions, and you only need this if your base language is first-order. Yes, that's vastly simplified, and it does not cover all cases, what about generic programming (but this can be done via Data.Data) and alex/happy (but we have parsec) etc etc. Best regards, J.W. ___ 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: Why?
On Thu, Dec 10, 2009 at 9:50 AM, John D. Earle johndea...@cox.net wrote: in progress. The Haskell creed appears to be, This is the way so stick to it! The idea appears to be that by sticking to the program the problems will be overcome in time and we will be left with all the glorious goodness. At I think this is a bit of a misnomer. My perception of a Haskell creed, if there really is one, is something more along the lines of: Purity (also laziness, amongst other things) gives us some desirable properties. Let's see how far we can go with these ideas and if we can use them to solve practical problems. The Haskell community is not trying to shove these ideas down your throat. We're just interested in exploring them. Before monadic I/O was introduced, the absence of side effects made practical applications clumsy if not impossible [1]. But the Haskell researchers persisted. It just so happens that now the industry seems to be taking note of what the Haskell community has accomplished with careful adherence to these ideas. [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why?
On Thu, Dec 10, 2009 at 11:56 AM, Sebastian Sylvan sebastian.syl...@gmail.com wrote: On Thu, Dec 10, 2009 at 3:30 PM, John D. Earle johndea...@cox.net wrote: My intuition says that laziness and purity are distinct whereas yours says that purity is a necessary condition. This is what needs to be reconciled. I think laziness requires purity to make sense. Laziness implies that the order of evaluation is highly unpredictable and depends strongly on the implementation details of libraries and such (which you may not have access to). So it's fickle. Someone adds an if statement somewhere and all of a sudden a variable gets evaluated earlier than it used to. It would be madness to write any code which depends on this unpredictable behaviour. In other words, the expressions that get evaluated lazily must not have side effects. Yes, this is discussed in section 3.2 of the paper I cited earlier (http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/history.pdf). That paper gives some nice insight into the history of Haskell. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you haven't bought any of Knuth's fascicles yet, this is definitely the one to get. Bitwise Tricks Techniques
I can't compare it with Knuth's fascicle, but the FXT book (linked to from http://www.jjj.de/fxt/) has a whole chapter on bit wizardry and is another excellent resource along these lines. On Wed, Nov 18, 2009 at 6:22 PM, Casey Hawthorne cas...@istar.ca wrote: If you haven't bought any of Knuth's fascicles yet, this is definitely the one to get. The Art of Computer Programming: Volume 4 Bitwise Tricks Techniques Binary Decision Diagrams Fascicle 1 Donald E. Knuth 2009 Describes basic broadword operations and an important class of data structures that can make computer programs run dozens - even thousands - of times faster. I started a Haskell program using bitwise operations and then discarded them thinking them to low level. I think one of the dangers of Haskell, is that I get carried away with medium and high level abstractions and think everything MUST be done that way. :) -- Regards, Casey ___ 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] Static Linking Problem
On Tue, Nov 10, 2009 at 4:29 PM, Ketil Malde ke...@malde.org wrote: MightyByte mightyb...@gmail.com writes: After a bit of googling, I came to the conclusion that I needed to compile it with ghc --make -static -optl-static Foo.hs. Using only -static or -optl-static by themselves did not generate a statically linked binary. But when I compile with both those parameters I get a bunch of linker errors: [..] (.text+0x59c): undefined reference to `pthread_mutex_lock' For some reason, GHC doesn't link with the pthreads library, so you need to compile (link) with two options: -opt-static -optl-pthread Excellent, that appears to have solved my problem. It still gives me the warning: (.text+0x3068): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking But glibc is pretty standard, so I don't think this will be a problem for me. Thanks for the help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Static Linking Problem
I am trying to statically compile a simple haskell program so I can use it on a Linux computer without haskell and it's associated libraries. Here is a small example program that illustrates my problem: module Main where import Network.Fancy main = do withDgram (IP 127.0.0.1 1234) (flip send Hello network\n) After a bit of googling, I came to the conclusion that I needed to compile it with ghc --make -static -optl-static Foo.hs. Using only -static or -optl-static by themselves did not generate a statically linked binary. But when I compile with both those parameters I get a bunch of linker errors: /home/mightybyte/.cabal/lib/network-fancy-0.1.4/ghc-6.10.4/libHSnetwork-fancy-0.1.4.a(Fancy.o): In function `s6ks_info': (.text+0x3068): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking /usr/lib/ghc-6.10.4/libffi.a(closures.o): In function `init_mparams': (.text+0x3e): undefined reference to `pthread_mutex_lock' /usr/lib/ghc-6.10.4/libffi.a(closures.o): In function `init_mparams': (.text+0x52): undefined reference to `pthread_mutex_unlock' /usr/lib/ghc-6.10.4/libffi.a(closures.o): In function `init_mparams': (.text+0xd3): undefined reference to `pthread_mutex_init' /usr/lib/ghc-6.10.4/libffi.a(closures.o): In function `ffi_closure_free': (.text+0x59c): undefined reference to `pthread_mutex_lock' etc... I've tried this on both Fedora and Arch Linux and I get the same error. Anyone know how to solve this problem? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
