Re: [Haskell-cafe] Cabal Install Links to Source from Haddock Docs
Thank you. As it turns out, I was aware of that recipe. What I wanted was to be able to use cabal install's nice dependency following features and still get source links in my documentation. Personally, I feel that inclusion of source and docs should be the DEFAULT for cabal, as well as for binary distributions of ghc. -rhayes On Dec 21, 2008, at 1:11 AM, Thomas Hartman wrote: the answer: not cabal install, just cabal. thart...@thartman-laptop:~/haskellInstalls/smallInstalls/ pureMD5-0.2.3 thart...@thartman-laptop:~/haskellInstalls/smallInstalls/ pureMD5-0.2.3cabal --help | grep -i doc haddock Generate Haddock HTML documentation. thart...@thartman-laptop:~/haskellInstalls/smallInstalls/ pureMD5-0.2.3cabal haddock --help | grep -i link --hyperlink-source Hyperlink the documentation to the source code thart...@thartman-laptop:~/haskellInstalls/smallInstalls/ pureMD5-0.2.3cabal haddock --hyperlink-source 2008/12/21 R Hayes rfha...@reillyhayes.com: Is there a way I can get Haddock Docs WITH links to source (local) from modules installed with cabal install xxx? Getting the docs themselves is pretty easy by changing either ~/.cabal/config or using --enable-documentation. Automatically generating the source (colourised or not) and integrated links eludes me. -r ___ 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] Cabal Install Links to Source from Haddock Docs
Is there a way I can get Haddock Docs WITH links to source (local) from modules installed with cabal install xxx? Getting the docs themselves is pretty easy by changing either ~/.cabal/ config or using --enable-documentation. Automatically generating the source (colourised or not) and integrated links eludes me. -r ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Ghci for Mac OSX?
I had this problem. The installer didn't make the sym links from / usr/bin/ghc* to /Library/Frameworks/GHC.framework/Versions/Current/usr/ bin/ ghc* The issue was I had installed the beta package and not removed it. The fix was to uninstall 6.10.1 using /Library/Frameworks/ GHC.framework/Tools/Uninstaller and then reinstall the package. -r On Nov 20, 2008, at 11:08 AM, Colin Adams wrote: I installed the 6.10.1 .pkg on my MacBook Air, and ghci works fine, but if I type ghci, I get program not found. Is it supposed to be available for Mac? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Help with Building on Mac OS X Leopard
What resembles an old issue has reappeared when building HEAD on Leopard. The build of the stage two compiler fails with: ld: in /Users/rfh/3rdParty/builds/ghc-6.9.20071028/libraries/ haskell98/dist/build/libHShaskell98-1.0.1.a, archive has no table of contents This happens when the modify time on library is later than the timestamp on the library index. It's not an uncommon issue for building software on the Mac. The usual cause is builds that copy .a files and are unaware of this mac feature. Running ranlib on libHShaskell98-1.0.1.a file and resuming the make causes the build to continue until it gets to the next .a file. ld: in /Users/rfh/3rdParty/builds/ghc-6.9.20071028/libraries/array/ dist/build/libHSarray-0.1.a, archive has no table of contents It seems this problem has occurred before. My guess is that a work- around was put in place that no longer works on Leopard. I'm not sure exactly where to look in the Make system. Any pointers would be appreciated. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Transformation sequence
I know that this is a resolved question, but wouldn't Huet's Zipper also work for this On Oct 20, 2007, at 5:26 PM, Alfonso Acosta wrote: On 10/20/07, Mads Lindstrøm [EMAIL PROTECTED] wrote: I am not a monad-expect, so I may be wrong, but wouldn't a writer monad be more appropriate? You are at least more monad-expert than myself . I knew the existence of the writer monad but not really how it works. After checking its documentation I must say you and Brandon are right. Using the Writer Monad makes sense. ___ 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] Do you trust Wikipedia?
shai dorsai On Oct 18, 2007, at 5:00 PM, Brandon S. Allbery KF8NH wrote: On Oct 18, 2007, at 19:53 , John Meacham wrote: On Thu, Oct 18, 2007 at 02:31:10AM +0100, PR Stanley wrote: Do you trust mathematical materials on Wikipedia? Certainly! I honestly think wikipedia is one of man's greatest achievements, and it is just in its infancy. For what it's worth, I'm withholding judgement on Wikipedia until it matures a bit (they're still learning how to deal with editorial issues IMO) --- but when I first heard about it I couldn't help but think of the Final Encyclopedia. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon university KF8NH ___ 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] Cabal, lib and exe in one
I think Simon is right, and not just from a Haskell point of view. Allowing a package to contain a both a library and an executable makes the behavior of the package system less obvious. That's not to say that it can't behave correctly, but that it can't behave both correctly and in a way that is easy to understand. Yes, it makes installation of an executable package more complicated if you have to install its library package as well. But making this simple should be handled by a layer above the cabal package files (Hackage?). In my experience, the best packaging systems distinguish between dependency assurance and dependency satisfaction. For example, the Debian packaging system has two layers. dpkg deals with package files, installing a single package, and assuring that dependencies are met prior to installation. apt-get retrieves packages from repositories with their pre-reqs (based on the dependency) and invokes dpkg on the retrieved packages. I know the problem is not identical to the one cabal is trying to solve, but I think there is a great deal to be learned by looking at the Debian packaging system and its conventions. In any event, solid naming conventions could go a long way to making this obvious. If foo has a useful exposed library, but primarily consists of an executable, dividing it into foo-bin and foo-lib could serve to clarify. I would propose that, since the bulk of existing packages seem to be libraries, we use a naming convention to distinguish packages that build executables and leave the names of library packages unannotated. -r On May 2, 2007, at 2:08 AM, Simon Marlow wrote: Duncan Coutts wrote: On Tue, 2007-05-01 at 22:29 +0100, Magnus Therning wrote: So if foo.hs is in test-src and Foo/Bar.hs is in src then I think you just need: hs-source-dirs: test-src, src No, that's not enough, I also have to add the following lines to make the executable compile and link: extensions: ForeignFunctionInterface c-sources: csrc/ptrace.c That is, I end up compiling the library a second time! Can't I get the executable to link against the library that was just created? I was just expecting to not have to repeat myself in the cabal file. Not such a strange thing to expect from a build system, I think :-) Yes this is an interesting question about what it means to have programs in the same cabal package as an executable. Currently having a executable and a library inside a cabal package is not the same thing as having a library package and separate package that contains only that executable. The difference is that when the executable is in the same cabal package it merely has access to the same modules, it doesn't 'depend' on that library package exactly. So for example it can access modules which are not exposed by the library and indeed it can compile those same modules with completely different build flags. So currently those modules will be built twice. It's not clear to me that this is the right meaning, or indeed that we should allow multiple entries in a single .cabal file. I think it might be better to just have multiple .cabal files (possibly in the same directory). Then we could be explicit and state that an executable depends on the library or if we want to use different build flags, or use modules that are not exposed by the lib then we can do that and only in that case do we build those modules twice. Right at the front of the Cabal docs it says: However having both a library and executables in a package does not work very well; if the executables depend on the library, they must explicitly list all the modules they directly or indirectly import from that library. IMO we shouldn't allow both a library and an exe in the same package. I think I argued against this originally, and my understanding is that doing this is deprecated, although perhaps not visibly enough. Whenever the question of what to do about lib +exe packages arises, the discussion tends to spiral out of control into what we should do about collections of packages in general. For now, the simple story is that each package should have either a single library or a single executable (even multiple executables in a package is questionable; if they share some code it shoud be in a package). Cheers, Simon ___ 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 Albus Dumbledore would sell Haskell
I don't know how many of the other people on this list are actually going to *be* at OSCON. I will. I think it is important to think about the kinds of problems the audience is trying to solve, as well as the context in which they are trying to solve them. For the most part, the attendees at OSCON work on system software: operating systems, operating system services (printing, packaging, scheduling, etc), network distributed computing infrastructure, databases, languages, and every imaginable variation on the word web. 1) Build a simple database access layer that is immune to SQL injection attacks from user input (using the type system to guarantee that safety). Include the FFI portion (FFI is a point of paranoia about any new language). Now the, the audience values the type system. 2) Show something appallingly simple, yet blazingly fast. Demonstrate that it is blazingly fast. I would implement wc -l using data.Bytestring.lazy and run in over a huge file. It's a one line program and it will run faster than the built in unix command. Explain that its fast because of GHCs rewrite rules. Explain that the rewrite rules are only possible because of purity. Now the, the audience values purity. 3) Build a simple combinator framework that supports multiple evaluation schemes (like your derivative framework that supported both valuation and settlement processes). For this audience, it might be cool to build a simple package system that both installed software and later verified the integrity of the installation. Although, if you *wanted* to present How to write a financial contract I could not object. Quantitative finance is my business and I promise to be in the audience for this. Also, see if Audrey Tang is going to be present. If she is, consider enlisting her support. Haskell has *enormous* credibility in the Perl 6 community because of PUGS. I recently had a conversation with Jesse Vincent, the Perl 6 program manager. He said that the majority of the Perl 6 community is aware that PUGS (and therefore Haskell) are crucial to the success of Perl 6. Perl has its own track at this conference. reilly hayes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How Albus Dumbledore would sell Haskell
In general, problems that would lose millions of dollars are noticed very quickly. Quants are constantly analyzing the sources of shortfall in implementing strategies. Also, time to market is generally more important than correctness. It's much better to have a strategy that mostly works sooner than a strategy that's perfect later. The opportunities to extract alpha from the market decay as more people see them (it is a zero sum game after all). Most of this technology has a lot in common with a Formula 1 race car: you can't win the race with a car that doesn't risk breaking down halfway through the race. Of course, there are exceptions (risk systems, systems that handle client orders, etc). The interest I've seen in Haskell and ML in the quant world has been driven by expressiveness. On Apr 18, 2007, at 1:47 PM, Seth Gordon wrote: Paul Johnson wrote: You cannot win over the entrepreneur with promises of easier and more robust. This translates to anyone can do it and the valuable trade secret of arcane wizardry is now devalued. I suggest reading extracts from Beating the Averages by Paul Graham. Then explain that Graham only wrote in Lisp because his university didn't teach Haskell. I think a more powerful argument would be to talk about cases where Haskell is *actually being used* industrially. E.g., these folks at Credit Suisse are using Haskell for their analytics because in their line of work, if the implementation of the code doesn't match up perfectly with the spec, their employer could lose millions of dollars, and the programmers might not notice the bug until those millions were long gone. ___ 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] Tutorial on Haskell
In my opinion, one of the things that makes Haskell difficult to learn is the value system. I'm not referring to pure vs. impure. Instead, I am referring to the beliefs and principles held by the Haskell community that are not shared with most of the programming world. Principles like It is valuable to be able to reason about programs rigorously. This is foreign to most developers. When they get to the section of a Haskell book that starts talking about this, their eyes glaze over and they skip over to the more practical stuff. By the time they get to Monads they're ready to rip their eyes out because the book is too theoretical or too academic. One of the truly powerful things about Haskell is the short distance between theory and practicality. The problem is how to demonstrate this convincingly. The ability to prove a program's correctness is regularly trotted out for show in this arena (or at least the lighter- weight claim that programs that compile usually work). I don't think that most developers (and certainly not the OSCON crowd) are ready to drink that kool-aid. They *enjoy* debugging and are tired of the static vs. dynamic debate. But the ability to reason about programs has borne fruit that I *do* think they will appreciate. Because many of them care about performance. I don't need to tell the subscribers to this list that the shockingly good performance of code written using Data.ByteString.Lazy is a direct result of being able to reason about programs. Obviously, the details of the fusion techniques are outside the scope of any introductory tutorial. But I think it would be useful to quickly implement a wc -l equivalent and explain why it's faster than the simple C equivalent. Nothing overly deep, just draw the line from reasoning about programs to fusion and on to amazing performance (capping it off with the fact the the fusion optimization is in the *Library*, not baked in to the compiler). At a minimum, it shows that being able to reason about programs rigorously can have a payoff in a currency that they value. R Hayes rfhayes@/reillyhayes.com On Apr 16, 2007, at 1:34 AM, Simon Peyton-Jones wrote: Friends I have agreed to give a 3-hr tutorial on Haskell at the Open Source Convention 2007 http://conferences.oreillynet.com/os2007/ I'm quite excited about this: it is a great opportunity to expose Haskell to a bunch of smart folk, many of whom won't know much about Haskell. My guess is that they'll be Linux/Perl/Ruby types, and they'll be practitioners rather than pointy-headed academics. One possibility is to do a tutorial along the lines of here's how to reverse a list, here's what a type is etc; you know the kind of thing. But instead, I'd prefer to show them programs that they might consider *useful* rather than cute, and introduce the language along the way, as it were. So this message is to ask you for your advice. Many of you are exactly the kind of folk that come to OSCON --- except that you know Haskell. So help me out: Suggest concrete examples of programs that are * small * useful * demonstrate Haskell's power * preferably something that might be a bit tricky in another language For example, a possible unifying theme would be this: http://haskell.org/haskellwiki/Simple_unix_tools Another might be Don's cpu-scaling example http://cgi.cse.unsw.edu.au/~dons/blog/2007/03/10 But there must be lots of others. For example, there are lots in the blog entries that Don collects for the Haskell Weekly Newsletter. But I'd like to use you as a filter: tell me your favourites, the examples you find compelling. (It doesn't have to be *your* program... a URL to a great blog entry is just fine.) Of course I'll give credit to the author. Remember, the goal is _not_ explain monads. It's Haskell is a great way to Get The Job Done. Thanks! Simon ___ 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] Tutorial on Haskell
On Apr 17, 2007, at 4:46 PM, David Brown wrote: R Hayes wrote: They *enjoy* debugging ... I have to say this is one of the best things I've found for catching bad programmers during interviews, no matter what kind of system it is for. I learned this the hard way after watching someone who never really understood her program, but just kept thwacking at it with a debugger until it at least partially worked. I've seen this too, but I would not use the word debugging to describe it. I don't think I agree that enjoying debugging is a sufficient symptom for diagnosing this condition. There are many people that love the puzzle-box aspect of debugging. Some of them are very talented developers. R Hayes rfhayes@/reillyhayes.com Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Mathematics in Haskell
Wouldn't this be a good discussion for the Haskell Prime List? Reilly Hayes +1 415 388 3903 (office) +1 415 846 1827 (mobile) [EMAIL PROTECTED] On Apr 2, 2007, at 3:24 PM, Andrzej Jaworski wrote: I too was put off by the Num issues though--strange mixture of sophisticated category theory and lack of a sensible hierarchy of algebraic objects. Perhaps we should replace CT with lattice theoretic thinking (e.g. functor = monotonic function) before cleaning up the type-related mess? See: http://citeseer.ist.psu.edu/269479.html so count me in on an effort to make Haskell more mathematical. For me that probably starts with the semigroup/group/ring setup, and good arbitrary-precision as well as approximate linear algebra support. I agree: semigoups like lattices are everywhere. Then there could be a uniform treatment of linear algebra, polynomial equations, operator algebra, etc. So, perhaps haste is not a good advice here? -Andrzej ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
[Haskell-cafe] Re: Mathematics in Haskell
Wouldn't this be a good discussion for the Haskell Prime List? Reilly Hayes +1 415 388 3903 (office) +1 415 846 1827 (mobile) [EMAIL PROTECTED] On Apr 2, 2007, at 3:24 PM, Andrzej Jaworski wrote: I too was put off by the Num issues though--strange mixture of sophisticated category theory and lack of a sensible hierarchy of algebraic objects. Perhaps we should replace CT with lattice theoretic thinking (e.g. functor = monotonic function) before cleaning up the type-related mess? See: http://citeseer.ist.psu.edu/269479.html so count me in on an effort to make Haskell more mathematical. For me that probably starts with the semigroup/group/ring setup, and good arbitrary-precision as well as approximate linear algebra support. I agree: semigoups like lattices are everywhere. Then there could be a uniform treatment of linear algebra, polynomial equations, operator algebra, etc. So, perhaps haste is not a good advice here? -Andrzej ___ 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
Problems with -caf-all
I get the following error message when I try to compile with -caf-all. /tmp/ghc583_0/ghc583_0.s:6482:0: FATAL:Symbol _Mainmain_CAF_cc_ccs already defined. My command line looks like this: ghc --make PriceHisto.hs -ljudy -prof -auto-all -caf-all I also tried the following command line and got the same error: ghc --make PriceHisto.hs -ljudy -prof -caf-all Any ideas as to what I'm doing wrong? R Hayes rfhayes@/reillyhayes.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
