RE: [Haskell-cafe] cabal build command and package versions
| On Wed, 2008-08-20 at 13:53 -0500, Nicolas Frisby wrote: | I have a question about cabal's behavior for the build command. When | using the build command on a cabalized project, any version changes | for installed packages go unnoticed - the necessary modules in the | project are not re-compiled. | | Yes. That's a ghc bug. Different to the one below? Is it in Trac? | Not knowing that the configure command is necessary to detect changes | in package that the current project depends on and proceeding only | with the build command has led to BusErrors and GHC incurring the | impossible in my exploration. | | Yes, it's a pretty annoying ghc bug. You'll be glad to know that it is | fixed in ghc-6.10: | | http://hackage.haskell.org/trac/ghc/ticket/1372 | | You'll notice a lot of people have commented on this one. It's tripped | up a lot of people. And happily it's fixed for 6.10! Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CouchDB module in Yhc source tree: clarification, and small problems with other packages
Sorry for not responding earlier but I didn't pay attention to this thread at the time. The reason for finding it now is that I listened to the FLOSS Weekly's episode on CouchDB yesterday; I stumbled on this email from a search for haskell+couchdb. On Sat, Jan 5, 2008 at 4:14 PM, Dimitry Golubovsky [EMAIL PROTECTED] wrote: 4. The dataenc package (http://code.haskell.org/dataenc/devo/) from which I pulled the Codec.Binary.Base64 module. The package may need some adjustment to GHC 6.8.x packages structure as only base listed in build-depends does not seem to be enough: when building it, Cabal complains for hidden packages such as collections (which I had to add manually to the cabal file), etc. Is it some problem with my GHC setup, or does just the dataenc.cabal need to be updated? As the author of dataenc I'm interested in fixing any problems you see with it. Maybe you could offer some more information: 1. Is this still a problem? (I'm using GHC 6.8.2 and I'm having no such problems at the moment.) 2. What can I do to make sure that I get contacted if similar issues come up in the future? (Currently bugs can only be reported by contacting me directly, preferably via email. Since you didn't I suspect I haven't communicated that clearly enough though.) /M ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: unknown flags scramble
Evan Laforge wrote:
I've been getting a mysterious error for a while now. It's come and
gone, but seems to be showing up slightly more consistently now.
Before I was on ghc 6.8.2 and now I'm on ghc 6.8.3, OS X 10.4 and now
10.5, i386 arch. The problem is that randomly while compiling I get
an error like this:
unknown flags in {-# OPTIONS #-} pragma:
-XDeriveDataTypeablData/Array/IArray.hs #e Ui.Font ( TextStyle(..),
Font(..), FontFace(..) ) where import qualified Data.Generics as
Data/Array/IArray.lhs.Larray-0.1.0.0aliColor as Color import
Foreign import qualified Ui.Util as Util {-# LINE 14 Ui/Font.hsc
It looks like somehow pragma parsing gets a bunch of random junk
scrambled in. In the past this would happen consistently until I did
a make clean and rebuild, but more recently all I have to do is try
again and it doesn't happen the second time. I haven't gotten it
while compiling for a while, but since I'm using hint which uses the
ghc api to interpret haskell, I'm getting this quite frequently inside
a GhcException when hint wants to interpret some code. I've also
gotten this from ghci occasionally, and the usual fix is just to do a
reload, and the second time it works.
Does this sound familiar to anyone? It's not fatal since a retry
clears things up, but it's a little worrying and would not look very
good in released software. I cast about a bit on the ghc trac and
didn't find any open bugs like this.
This is one symptom of http://hackage.haskell.org/trac/ghc/ticket/1736,
which turned out to be the same bug as
http://hackage.haskell.org/trac/ghc/ticket/2240, and haunted us for a long
time before we found it.
Sadly we found it after the 6.8.3 release, but you could backport the fix
and build your own 6.8.3 if you are badly affected.
Cheers,
Simon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: unknown flags scramble
This is one symptom of http://hackage.haskell.org/trac/ghc/ticket/1736, which turned out to be the same bug as http://hackage.haskell.org/trac/ghc/ticket/2240, and haunted us for a long time before we found it. Sadly we found it after the 6.8.3 release, but you could backport the fix and build your own 6.8.3 if you are badly affected. That's great to hear! Well, about it being fixed I mean. I think I can live with this until the next ghc release... yet another reason to await it eagerly! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Xcode Plugin
Dennis Buchmann: during my search for an acceptable development environment under Mac OS X I found this Plugin for Xcode: http://hoovy.org/HaskellXcodePlugin/ Unfortunately, I'm not able to get it to run in Xcode v3.0 and the developer seems to be not contactable at the moment. So, has anyone installed this plugin successfully (with problems in the beginning)? I have a student working on a plugin for Xcode 3.0. Hopefully, he'll be able to release something in about two month. Manuel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the process package ...
On Thu, 2008-08-21 at 00:36 -0500, Galchin, Vasili wrote: Hi Duncan, In reality there is a complaint about no configure file. In any case, you really mean autoconf and not autoreconf yes? If I should run autoconf, there is no configure.ac or configure.in file under the process directory! ?? Ah, you're using process-1.0.0.0 from hackage. It does indeed appear to be borked because it specifies build-type: Configure and yet contains no ./configure script. Sorry, I assumed that you were missing ./configure because you were using the darcs version. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] cabal build command and package versions
On Thu, 2008-08-21 at 08:23 +0100, Simon Peyton-Jones wrote: | On Wed, 2008-08-20 at 13:53 -0500, Nicolas Frisby wrote: | I have a question about cabal's behavior for the build command. When | using the build command on a cabalized project, any version changes | for installed packages go unnoticed - the necessary modules in the | project are not re-compiled. | | Yes. That's a ghc bug. Different to the one below? Is it in Trac? Same one, the one recently fixed. | Yes, it's a pretty annoying ghc bug. You'll be glad to know that it is | fixed in ghc-6.10: | | http://hackage.haskell.org/trac/ghc/ticket/1372 | | You'll notice a lot of people have commented on this one. It's tripped | up a lot of people. And happily it's fixed for 6.10! yay :-) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] darcs upgrade HOWTO (was: poll: how can we help you contribute to darcs?)
On Aug 5, 2008, at 0:26 AM, Ketil Malde wrote:
The consequences of moving to the darcs-2 format are a bit unclear to
me. For instance, I'd like to keep my main (export) repo in darcs-1
format, in order to make it as accessible as possible (Ubuntu still
ships with darcs-1.0.9, and that's a fairly cutting edge
distribution.) Can I convert my working repos to darcs-2? Should I?
How about darcs-hashed? In short, I'd like to see examples of
recommended migration strategies, and associated benefits.
Here's what I recommend, and what I've been doing for months, both
with the large Tahoe code base -- http://allmydata.org/trac/tahoe and
with numerous smaller codebases -- http://allmydata.org/trac .
1. Upgrade any executables you have to the latest stable version of
darcs immediately. The new executables are fully backwards
compatible -- you will not have any compatibility problems as a
result of upgrading. They are also much less buggy and faster than
older darcs executables.
(There are at least two known issues with the darcs-2.0.2 executable
which cause performance problems -- one is a issue with ghc v6.8.2
and the other is an issue with the latest version of libcurl --
v7.18.2. Hopefully the darcs core team will release darcs-2.0.3 soon
to fix these two issues, but even if darcs-2.0.2 is still the current
version, I recommend it over any previous version.)
If your use of darcs is currently satisfying (fast enough, no bugs
getting in your way), then stop at this step. You are now using the
latest stable darcs executable while using old-fashioned darcs-v1
repositories. Other people who are using older versions of darcs can
continue to share patches with your repositories just like always.
2. If there are problems with this situation of using darcs-2
executables and darcs-1-format repositories, then report it to the
darcs-users mailing list, and then make a new hashed-format
repository in parallel with your existing darcs-1-format repository,
like this:
darcs get --hashed ${repo} ${repo}-hashedformat
Now people who have new darcs-v2 can push and pull to the -
hashedformat repository and people who have darcs-v1 can continue to
push and pull to the original repository. You can transfer patches
between those repositories with normal darcs push and pull. For
those projects of mine which have a high rate of patches I have gone
ahead and added post-apply hooks to automatically do a push --all
to the other one, like this:
echo apply posthook darcs push --all --repodir=/home/source/darcs/
tahoe/${repo}-hashedformat /home/source/darcs/tahoe/${repo} $
{repo}-hashedformat/_darcs/prefs/defaults
echo apply run-posthook ${repo}-hashedformat/_darcs/prefs/defaults
echo apply posthook darcs push --all --repodir=/home/source/darcs/
tahoe/${repo} /home/source/darcs/tahoe/${repo}-hashedformat $
{repo}/_darcs/prefs/defaults
echo apply run-posthook ${repo}/_darcs/prefs/defaults
(Note that this is mutually recursive, but it terminates because the
post-apply hook doesn't trigger in the case that zero patches were
pushed.)
If your use of darcs is currently satisfying then stop at this step.
You are now using the latest stable darcs executable, and maintaining
two darcs repositories -- an old-fashioned darcs-1-format repository
for your darcs-1-executable-using friends and a hashed-format
repository for your darcs-2-executable using friends. Your post-
apply hooks cause these two repositories to get automatically synced
with each other.
3. If there are problems with this situation of using darcs-2
executables and a pair of repos -- one of which is darcs-1-format
repo for the use of darcs-1-executable-using users and the other of
which is a hashed-format repo for the use of darcs-2-executable-using
users -- then report it to the darcs-users mailing list and await
further instructions.
Note that these instructions do not involve any use of darcs-2-format
repositories. Those are only for projects which (a) have no darcs-1-
executable-using users, and (b) have no extant branches stored in
darcs-1-format or hashed-format repositories. Personally step 2 has
satisfied all my needs so I use the step 2 strategy for all my
publicly shared repositories, although I do tend to create new
private repositories with darcs-2-format.
If someone wants to adapt this message to the darcs wiki I would be
grateful.
Regards,
Zooko
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages)
On Tue, Aug 19, 2008 at 02:28:36PM -0700, Jeremy Shaw wrote: - the cdbs extension for supporting haskell (the one posted on debian-haskell mailing list a while ago) I keep the newest version of that at http://people.debian.org/~kaol/repos/hlibrary/ One thing that it doesn't do yet is to register the -doc packages. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CouchDB module in Yhc source tree: clarification, and small problems with other packages
magnus: Sorry for not responding earlier but I didn't pay attention to this thread at the time. The reason for finding it now is that I listened to the FLOSS Weekly's episode on CouchDB yesterday; I stumbled on this email from a search for haskell+couchdb. On Sat, Jan 5, 2008 at 4:14 PM, Dimitry Golubovsky [EMAIL PROTECTED] wrote: 4. The dataenc package (http://code.haskell.org/dataenc/devo/) from which I pulled the Codec.Binary.Base64 module. The package may need some adjustment to GHC 6.8.x packages structure as only base listed in build-depends does not seem to be enough: when building it, Cabal complains for hidden packages such as collections (which I had to add manually to the cabal file), etc. Is it some problem with my GHC setup, or does just the dataenc.cabal need to be updated? As the author of dataenc I'm interested in fixing any problems you see with it. Maybe you could offer some more information: 1. Is this still a problem? (I'm using GHC 6.8.2 and I'm having no such problems at the moment.) 2. What can I do to make sure that I get contacted if similar issues come up in the future? (Currently bugs can only be reported by contacting me directly, preferably via email. Since you didn't I suspect I haven't communicated that clearly enough though.) I think the best result here would be to put a CouchDB binding on hackage. Is anyone in a position to do this? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages)
kaol: On Tue, Aug 19, 2008 at 02:28:36PM -0700, Jeremy Shaw wrote: - the cdbs extension for supporting haskell (the one posted on debian-haskell mailing list a while ago) I keep the newest version of that at http://people.debian.org/~kaol/repos/hlibrary/ One thing that it doesn't do yet is to register the -doc packages. Can the Debian/Haskell interest parties say something about who's doing what in this area? Is there hope for a concrete effort to import large numbers of hackage apps and tools into Debian? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CouchDB module in Yhc source tree: clarification, and small problems with other packages
Don All, On 8/21/08, Don Stewart [EMAIL PROTECTED] wrote: I think the best result here would be to put a CouchDB binding on hackage. Is anyone in a position to do this? As for myself, honestly, I did not plan to do this at this time as I am busy with other stuff (Yhc Core conversion). I'd be glad to help anyone who is willing to put CouchDB interface on Hackage. I'd like to note though that this may be a bit premature at the moment. CouchDB has been going through significant redevelopment within Apache Incubator (I am not a developer, but just watch silently), and what is available within the Yhc source tree may not work properly with the current CouchDB: it was for 0.7.x while they have 0.8.x in the incubator. So I would wait for graduation of CouchDB from the incubator, or at least checked with its core developers regarding API stability. Besides, the CouchDB interface in question was written only to satisfy the needs of the Yhc Web Service and may be missing some pieces, although it may be good for a starting point. Thank you. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lines of code metrics
Hi, Greg Fitzgerald wrote: Does anyone know of a good case study comparing a project written in C versus one written in Haskell? I'm mostly looking for a comparison of lines of code, but any other metric, such as time to market and code quality metrics could also be Just curious, has anybody tried to apply Halstead's code metrics (see e. g. http://www.sei.cmu.edu/str/descriptions/halstead_body.html), but there is a 70s' book titled Elements of Software Science to Haskell and other functional languages vs. C and other imperative languages? I myself played with these calculations in late 80s trying to estimate code quality of Pascal programs on PDP-11, but that was a pain to count functions' operands properly as they might come from global variables. Application of these formulas to functional languages might be mich cleaner, so has anybody tried? Thanks. -- Dimitry Golubovsky Anywhere on the Web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages)
At Thu, 21 Aug 2008 20:10:08 +0300, Kari Pahula wrote: On Tue, Aug 19, 2008 at 02:28:36PM -0700, Jeremy Shaw wrote: - the cdbs extension for supporting haskell (the one posted on debian-haskell mailing list a while ago) I keep the newest version of that at http://people.debian.org/~kaol/repos/hlibrary/ One thing that it doesn't do yet is to register the -doc packages. Cool. We made some modifications including some patches for the -doc stuff I believe. I'll try to do a merge and get some patches back to you. j. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CouchDB module in Yhc source tree: clarification, and small problems with other packages
Actually few days ago I run into CouchDB and started to prototype a binding using JSON and Curl from hackage. Once the base functionality is supported, I could post it for review. Adam On Aug 21, 2008, at 11:29 AM, Dimitry Golubovsky wrote: Don All, On 8/21/08, Don Stewart [EMAIL PROTECTED] wrote: I think the best result here would be to put a CouchDB binding on hackage. Is anyone in a position to do this? As for myself, honestly, I did not plan to do this at this time as I am busy with other stuff (Yhc Core conversion). I'd be glad to help anyone who is willing to put CouchDB interface on Hackage. I'd like to note though that this may be a bit premature at the moment. CouchDB has been going through significant redevelopment within Apache Incubator (I am not a developer, but just watch silently), and what is available within the Yhc source tree may not work properly with the current CouchDB: it was for 0.7.x while they have 0.8.x in the incubator. So I would wait for graduation of CouchDB from the incubator, or at least checked with its core developers regarding API stability. Besides, the CouchDB interface in question was written only to satisfy the needs of the Yhc Web Service and may be missing some pieces, although it may be good for a starting point. Thank you. -- Dimitry Golubovsky Anywhere on the Web ___ 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] Lines of code metrics
Just curious, has anybody tried to apply Halstead's code metrics [...] As I understand it, Halstead's metric punishes the re-use of operands (= variables). This is what happens if you start your program with a bunch of global definitions (e.g. int i,j,k,l because you might want them as loop indices) that actually should be local. This totally does not apply to Haskell: there is no assignment, you cannot overwrite, so indeed each operand (variable) serves only one purpose, as it should be. NB: My private set of Haskell metrics: * lines of code (per declaration) (should be = 5) * number of declarations (per module) (should be = 5 as well :-) * number of usages of Int, String, List, IO (should be = 0 :-) :-) Not entirely joking - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages)
On Thu, Aug 21, 2008 at 11:19 AM, Don Stewart [EMAIL PROTECTED] wrote Can the Debian/Haskell interest parties say something about who's doing what in this area? Is there hope for a concrete effort to import large numbers of hackage apps and tools into Debian? I made a stab at it, but ran into issues with build dependencies that I didn't have the time to solve, so I switched to just importing the packages I needed. Currently, we at SeeReason are building packages for our own use based on Ubuntu Hardy Heron. People are welcome to use them at their own risk. If it breaks your computer, you get to keep both halves. People are also welcome to use our autobuilder, which we use to build the packages. All packages can be found at deb.seereason.com. We are trying to limit the amount of time we spend on these tools, but would be happy to provide pointers to self-starters and/or discuss options for other people to work on them. Cliff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Mueval 0.5.1, 0.6, 0.6.1, 0.6.2, 0.6.3, 0.6.4
Evening folks. So it's that time again, to do a Mueval announcement! This time
I'd like to announce version 0.6.4, 0.6.3. And 0.6.2. And 0.6.1. And 0.6. And
0.5.1.
These releases have some nice stuff to them; perhaps the most interesting
aspect is that I've carried through on my threats^Wpromises, and Lambdabot in
#haskell now uses Mueval.
GETTING
All the stuff from the previous ANNs still apply here: you can get it at
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mueval, do a
'darcs get --lazy http://code.haskell.org/mubot/', cabal-install mueval, and so
on.
DEPENDENCIES
0.6.4 does add an additional dependency, on haskell-src-exts, for use in some
experimental parsing code, so you'll now need that in addition to Hint,
utf8-string, and show. (Upgrading Hint is mandatory, utf8-string unnecessary,
and show nice but certainly not necessary.)
BUILDING
Same as usual.
CHANGES
0.5.1
* SmallCheck support
0.6
* A new option, --loadfile, which loads a given *.{l}hs file with a module and
makes its function available for evaluation. This is a complex option; see the
README.
* Cleaner output, thanks to a needless show call sjanssen identified.
0.6.2
* Speed improvements (shorter timeouts, optimizations)
* Mueval imports many more modules by default, so one can freely use standard
functions from Control.Monad, for example; this also brings with it many test
examples from #haskell.
* experimental --noimports flag, to disable default imports (such as the above,
and also of the Prelude). This was motivated by Lambdabot's Caleskell, but I'm
not sure why it doesn't interact well with --loadfile (and so doesn't work with
Lambdabot).
0.6.3
* Saizan contributed some significant improvements to error reporting and
thread handling, so the infamous time-out errors are replaced by normal errors
more reminiscent of GHCi.
0.6.4
* Fixed an issue with lazy printing of results
* Exceptions are now caught and printed more prettily; again, thanks to Saizan
* Forced a dependency on the latest Hint; this fixes an error where one could
successfully evaluate:
bash-3.2$ mueval -e '1 + 1 {- addition example -}'
2
but not:
bash-3.2$ mueval -e '1 + 1 -- addition example'
* Added a --rlimits option. I decided that the POSIX resource limits were
causing too many people problems. So now non-time resource limits are disabled
unless specifically requested with --rlimits.
* mmorrow contributed some experimental parsing patches intended to catch
subtle invocations of dangerous functions. If haskell-src-exts is too
burdensome a dependency, Mueval/Context.hs and mueval.cabal can be easily
edited to remove the dependency.
KNOWN ISSUES
* Qualified imports do not work. That is, one cannot do $ mueval -e 'M.map (+1)
$ M.fromList [(1,2)]' or whatever and expect the proper Data.Map functions to
be substituted in. This is a weakness in the GHC API, AFAIK. It is possible
that this will be fixed in future versions of Hint or GHC, but I do not expect
that to happen for months.
* Many limits in System.Posix.Resource are simply completely broken for many
users; that is, *no* value can be set using them. I have been unable to figure
out the heck why this is the case (I can't reproduce it), and AFAIK no one has
filed a bug with the GHC developers, so this probably won't be fixed anytime
soon.
--
gwern
Secure wwics P415 SASP Comirex mailbomb ISADC Sayeret SBI Jatti
signature.asc
Description: Digital signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Libraries of standard QuickCheck properties
This in response to a comment on a GHC ticket [1]. I thought it was interesting enough to warrant general discussion. Comment (by JeremyShaw): Also, where does the H98 report say all instances of Eq must be transitive, reflexive, symmetric, and antisymmetric? It just says The Eq class provides equality (==).., whatever that might mean :-) Well, it does not say it explicitly, but I suspect H98's usage of Eq implicitly demands those laws be followed. Indeed. The same goes for the implicit law that (x /= y) /= (x == y), since both (/=) and (==) can be overridden. [2] Hopefully in Haskell' the laws will not only be stated, but there will be some QuickCheck-style properties you can use to test your own instances ;) This is an interesting thought. Has there been any work towards collecting properties written with QuickCheck (or similar) into a reusable chunk of some form? It would be very convenient to have parametrized properties that tested implicit laws such as equality, monads, and other things that come with the Haskell Platform. Not only would such a library be useful to use, but it would provide a number of readily available examples for would-be testers, thus encouraging testing. Sean [1] http://hackage.haskell.org/trac/ghc/ticket/2528#comment:6 [2] http://www.haskell.org/tutorial/monads.html#sect9.1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the process package ...
how do I unbork it? Are darcs version of package same as hackage version of packages teh same contents? Regards, Vasili On Thu, Aug 21, 2008 at 5:01 AM, Duncan Coutts [EMAIL PROTECTED]wrote: On Thu, 2008-08-21 at 00:36 -0500, Galchin, Vasili wrote: Hi Duncan, In reality there is a complaint about no configure file. In any case, you really mean autoconf and not autoreconf yes? If I should run autoconf, there is no configure.ac or configure.in file under the process directory! ?? Ah, you're using process-1.0.0.0 from hackage. It does indeed appear to be borked because it specifies build-type: Configure and yet contains no ./configure script. Sorry, I assumed that you were missing ./configure because you were using the darcs version. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Libraries of standard QuickCheck properties
2008/8/21 Sean Leather [EMAIL PROTECTED]: This in response to a comment on a GHC ticket [1]. I thought it was interesting enough to warrant general discussion. Comment (by JeremyShaw): Also, where does the H98 report say all instances of Eq must be transitive, reflexive, symmetric, and antisymmetric? It just says The Eq class provides equality (==).., whatever that might mean :-) Well, it does not say it explicitly, but I suspect H98's usage of Eq implicitly demands those laws be followed. Indeed. The same goes for the implicit law that (x /= y) /= (x == y), since both (/=) and (==) can be overridden. [2] Hopefully in Haskell' the laws will not only be stated, but there will be some QuickCheck-style properties you can use to test your own instances ;) This is an interesting thought. Has there been any work towards collecting properties written with QuickCheck (or similar) into a reusable chunk of some form? Yes, it's in development, called 'checkers'. code.haskell.org/checkers Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HTTP package: connection closing bug?
Hi, I'm using HTTP-3001.0.4 with GHC 6.8.3 under Mac OS X 10.5 and Debian Lenny. If I open and close many connections, I eventually get the error. Anyone else seen this before? *** Exception: socket: resource exhausted (Too many open files) Apparently, the socket is not closing. in TCP.hs:168, the call to shutdown is raising a socket already closed exception. So, the program never reaches the sClose on line 171. A simple fix is: wanderlust:Network arjun$ diff TCP.hs.original TCP.hs 172c172 } --- } `Exception.catch` (\_ - sClose sk) The code that demonstrates this problem on Mac OS X is: module Main where import Network.HTTP import Network.URI (parseURI) import Data.Maybe (fromJust) import Control.Monad googleM n = do s - simpleHTTP $ Request (fromJust $ parseURI http://www.google.com ) GET [] when (n `mod` 100 == 0) $ putStrLn (show n) return () main = mapM_ googleM [1..5000] On Debian Lenny, the code works fine with google.com. However, when I try to connect to my local CouchDB server, it throws an exception after roughly 1000 connections. Thanks. Arjun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] CouchDB module in Yhc source tree: clarification, and small problems with other packages
On 8/21/08, Don Stewart [EMAIL PROTECTED] wrote: I think the best result here would be to put a CouchDB binding on hackage. Is anyone in a position to do this? As for myself, honestly, I did not plan to do this at this time as I am busy with other stuff (Yhc Core conversion). I'd be glad to help anyone who is willing to put CouchDB interface on Hackage. I'm using CouchDB for a little HAppS-based web service. I'll put it on Hackage in about a week--once I'm done with the the web service. For the moment the code is here and is cabalized. http://github.com/arjunguha/haskell-couchdb/tree/master Feedback welcome. Arjun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTTP package: connection closing bug?
On Aug 21, 2008, at 3:23 PM, Arjun Guha wrote: Hi, I'm using HTTP-3001.0.4 with GHC 6.8.3 under Mac OS X 10.5 and Debian Lenny. If I open and close many connections, I eventually get the error. Anyone else seen this before? I've never looked into it deeply, but I just wanted to chime in that I've seen this, too. Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTTP package: connection closing bug?
On Thu, Aug 21, 2008 at 11:44 PM, Aaron Tomb [EMAIL PROTECTED] wrote: I've never looked into it deeply, but I just wanted to chime in that I've seen this, too. I may be confusing it with something else, but I seem to recall something very similar from a while back, in a blog post somewhere? I can't remember the details, but someone was writing a server application of some kind and came across a socket leaking error that was a one-line fix line this. The description and the fix just seem so familiar. :-\ Sorry, this is the most incoherent and useless post! Maybe someone else has been paying more attention and can remember who it was, and where. Cheers, D -- Dougal Stanton [EMAIL PROTECTED] // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTTP package: connection closing bug?
Aha, I knew I wasn't dreaming! http://mult.ifario.us/p/a-short-adventure-with-simplehttp Paul Brown posted this discussion back in February. It looks like the same thing. Has there been an update of HTTP since then? Nope, it hasn't been updated. I'm just running a locally patched version. This is the same issue, thanks! Arjun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTTP package: connection closing bug?
On Fri, 22 Aug 2008 11:12:08 Arjun Guha wrote: Aha, I knew I wasn't dreaming! http://mult.ifario.us/p/a-short-adventure-with-simplehttp Paul Brown posted this discussion back in February. It looks like the same thing. Has there been an update of HTTP since then? Nope, it hasn't been updated. I'm just running a locally patched version. This is the same issue, thanks! Beware of the browse function in Browser, there is a connection leak in there as well, at least there was back in March or April. Not sure if it has been fixed in the official repos. I seem to recall the sockets getting put into some half-closed state, presumably when GHC GC'd them, eventually exhausting limits. That may be particular to running on Linux, I guess. Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages)
Can the Debian/Haskell interest parties say something about who's doing what in this area? Is there hope for a concrete effort to import large numbers of hackage apps and tools into Debian? -- Don I'm not a DD, but I think uploading ~500 hackage packages to debian would be a bit of a no-no. Debian packages are expected to have active maintainers both upstream and on the debian side, and to build without a hitch on ten different architectures, or they don't make it into stable and the DD responsible gets whined at. Having a debianized cabal-install would be the biggest win in my book. If there were an unofficial debianized mirror of hackage, I probably wouldn't use it anyway. --Lane ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages)
At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), Christopher Lane Hinson wrote: I'm not a DD, but I think uploading ~500 hackage packages to debian would be a bit of a no-no. Debian packages are expected to have active maintainers both upstream and on the debian side, and to build without a hitch on ten different architectures, or they don't make it into stable and the DD responsible gets whined at. Fundamentally I think Lane is correct, but it is worth noting that the debian perl team maintains 938 CPAN modules. The effort involved is not trivial, but the number of consistently active people involved is not so huge (maybe 5 core people, and lots of people who are interested in one or two packages). Now, there are only 1217 registered installs of ghc6 on debian, compared to 74000+ perl installs (essentially everyone installs perl I guess), so it is not clear that the critical mass exists for a debian perl style team. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages)
At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), Christopher Lane Hinson wrote: I'm not a DD, but I think uploading ~500 hackage packages to debian would be a bit of a no-no. Debian packages are expected to have active maintainers both upstream and on the debian side, and to build without a hitch on ten different architectures, or they don't make it into stable and the DD responsible gets whined at. Fundamentally I think Lane is correct, but it is worth noting that the debian perl team maintains 938 CPAN modules. The effort involved is not trivial, but the number of consistently active people involved is not so huge (maybe 5 core people, and lots of people who are interested in one or two packages). Now, there are only 1217 registered installs of ghc6 on debian, compared to 74000+ perl installs (essentially everyone installs perl I guess), so it is not clear that the critical mass exists for a debian perl style team. One of the main tools that makes this possible is dh-make-perl, which is the moral equivalent of cabal-debian, I guess. Just as important is the shared version control setup and team procedures. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PRE-ANNOUNCE: cabal-debian (automatically debianize cabal packages)
At Thu, 21 Aug 2008 20:52:00 -0400 (EDT), Christopher Lane Hinson wrote: I'm not a DD, but I think uploading ~500 hackage packages to debian would be a bit of a no-no. Debian packages are expected to have active maintainers both upstream and on the debian side, and to build without a hitch on ten different architectures, or they don't make it into stable and the DD responsible gets whined at. Fundamentally I think Lane is correct, but it is worth noting that the debian perl team maintains 938 CPAN modules. The effort involved is not trivial, but the number of consistently active people involved is not so huge (maybe 5 core people, and lots of people who are interested in one or two packages). Now, there are only 1217 registered installs of ghc6 on debian, compared to 74000+ perl installs (essentially everyone installs perl I guess), so it is not clear that the critical mass exists for a debian perl style team. One of the main tools that makes this possible is dh-make-perl, which is the moral equivalent of cabal-debian, I guess. Just as important is the shared version control setup and team procedures. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the process package ...
On Thu, 2008-08-21 at 17:01 -0500, Galchin, Vasili wrote: how do I unbork it? Are darcs version of package same as hackage version of packages teh same contents? To be honest I'd not bother. You already have the version of the process package that came with ghc and there are no new releases that you need. That's why nobody else noticed the problem, because nobody needs to install this package, because it comes with ghc. If you really want to re-install it anyway then you could use the darcs version that goes with the ghc-6.8.x branch: http://darcs.haskell.org/ghc-6.8/packages/process Obviously in principle the version on hackage should have worked. You'll be glad to know that hackage now checks that packages that use build-type Configure do indeed actually have a ./configure file, so this particular error cannot be repeated. Duncan Regards, Vasili On Thu, Aug 21, 2008 at 5:01 AM, Duncan Coutts [EMAIL PROTECTED] wrote: On Thu, 2008-08-21 at 00:36 -0500, Galchin, Vasili wrote: Hi Duncan, In reality there is a complaint about no configure file. In any case, you really mean autoconf and not autoreconf yes? If I should run autoconf, there is no configure.ac or configure.in file under the process directory! ?? Ah, you're using process-1.0.0.0 from hackage. It does indeed appear to be borked because it specifies build-type: Configure and yet contains no ./configure script. Sorry, I assumed that you were missing ./configure because you were using the darcs version. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTTP package: connection closing bug?
On Thu, 2008-08-21 at 19:12 -0400, Arjun Guha wrote: Aha, I knew I wasn't dreaming! http://mult.ifario.us/p/a-short-adventure-with-simplehttp Paul Brown posted this discussion back in February. It looks like the same thing. Has there been an update of HTTP since then? Nope, it hasn't been updated. I'm just running a locally patched version. This is the same issue, thanks! If someone could figure out the right fix and send it to the maintainer that'd be great. We do need a decent working pure-haskell http package. For one thing cabal-install uses the HTTP package and it has to work for downloading dozens or hundreds of packages in a single session. As an aside, cabal-install could use the Network.Browser module better, by using a single call to browse for all downloads rather than one per download. As I understand it, that'd allow it to re-use a single connection. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] parser combinators need how many values to report errors?
I'm looking for a copy of: Predictive Parser Combinators Need four Values to Report Errors. I've poked around on the JFP's web site at Cambridge and they don't seem to have Volume 6 anymore. -- _jsn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] the process package ...
To be honest I'd not bother. You already have the version of the process package that came with ghc and there are no new releases that you need. That's why nobody else noticed the problem, because nobody needs to install this package, because it comes with ghc. problem here Duncan .. when I run cabal install haskelldb e.g. process is rightly seen as a dependency BUT unrightly as not currently installed ??? If you really want to re-install it anyway then you could use the darcs version that goes with the ghc-6.8.x branch: http://darcs.haskell.org/ghc-6.8/packages/process Obviously in principle the version on hackage should have worked. You'll be glad to know that hackage now checks that packages that use build-type Configure do indeed actually have a ./configure file, so this particular error cannot be repeated. Duncan Regards, Vasili On Thu, Aug 21, 2008 at 5:01 AM, Duncan Coutts [EMAIL PROTECTED] wrote: On Thu, 2008-08-21 at 00:36 -0500, Galchin, Vasili wrote: Hi Duncan, In reality there is a complaint about no configure file. In any case, you really mean autoconf and not autoreconf yes? If I should run autoconf, there is no configure.ac or configure.in file under the process directory! ?? Ah, you're using process-1.0.0.0 from hackage. It does indeed appear to be borked because it specifies build-type: Configure and yet contains no ./configure script. Sorry, I assumed that you were missing ./configure because you were using the darcs version. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HTTP package: connection closing bug?
On Fri, 22 Aug 2008 14:15:48 Duncan Coutts wrote: On Thu, 2008-08-21 at 19:12 -0400, Arjun Guha wrote: Aha, I knew I wasn't dreaming! http://mult.ifario.us/p/a-short-adventure-with-simplehttp Paul Brown posted this discussion back in February. It looks like the same thing. Has there been an update of HTTP since then? Nope, it hasn't been updated. I'm just running a locally patched version. This is the same issue, thanks! Looks like there is a patch committed to http's darcs repo, 3rd May, from prb to address this problem. If someone could figure out the right fix and send it to the maintainer that'd be great. We do need a decent working pure-haskell http package. Agreed. I think http needs serious work before it would fit the bill though. For one thing cabal-install uses the HTTP package and it has to work for downloading dozens or hundreds of packages in a single session. As an aside, cabal-install could use the Network.Browser module better, by using a single call to browse for all downloads rather than one per download. As I understand it, that'd allow it to re-use a single connection. It's quite likely you are leaking a connection on every call to browse. I recall someone asking about how to configure hackage's Apache to handle more than 1000 open connections... maybe cabal-install is the reason for it needing so many concurrent connections. I've sent a patch for Network.Browser.browse to Bjorn. Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] question about uploads of code contribution
Hello, 1) I want to upload a version with minor changes. Should I send out an announcement? 2) does the hackage database have a reader/writer lock to protect readers, i.e. people downloading when I am uploading? Regards, Vasili ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] question about uploads of code contribution
At Fri, 22 Aug 2008 00:29:40 -0500, Galchin, Vasili wrote: 2) does the hackage database have a reader/writer lock to protect readers, i.e. people downloading when I am uploading? 1. new versions must have a different version number 2. the version number is in the tarball name therefore: 3. uploading a new version is a non-destructive operation and will not affect anyone downloading older versions. At least, that is my understanding. j. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
