Re: [Haskell-cafe] Syntax for lambda case proposal could be \of
On Wed, 2007-08-15 at 11:06 -0700, Stefan O'Rear wrote:
Why not just:
sumTo0 = foldr (\0 k - 0
n k - n + k) 0
Because it would break a very large amount of old code, and I think H'
was supposed to be upward compatible:
Aye, that'd be bad.
foo = getSomethingCPS $ \ arg -
moreStuff
is now a syntax error (\ { varid - } matches no productions).
I'm not sure I follow.
The patterns would have to match up in a column, so
foo = getSomethingCPS $ \ arg -
moreStuff
should be fine, to add another alternative it'd have to be:
foo = getSomethingCPS $ \ Pat1 -
moreStuff
Pat2 -
evenMoreStuff
This case might be tricky though:
foo = getSomethingCPS $ \ Pat1 - foo
moreStuff
since we have to parse all of the moreStuff expression before
discovering it has no following - and so it's party of the body of
the first lambda alternative rather than a pattern starting a new
alternative.
I'm no parsing expert (especially when it comes to layout rules),
perhaps this is all too tricky.
Duncan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: trouble building 6.7 on ubuntu
On Thu, 2007-08-16 at 22:22 +0300, Esa Ilari Vuokko wrote: On 8/16/07, Thomas Hartman [EMAIL PROTECTED] wrote: Setup: Warning: Unknown fields: nhc98-options (line 173) and then a cryptic error involving HsColour I think you run into Cabal bug - you need to remove (or upgrade?) HsColour in your path, if that's the case. Thanks to Esa for tracking down this bug. Now fixed in Cabal. (or it will be shortly in the next batch of patches) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install of HDBC-odbc fails on ghc 6.7, -I flag causes problems
On Mon, 2007-08-20 at 13:10 -0400, Thomas Hartman wrote: problemw with the -I flag to ghc are causing cabal install to fail for hdbc-odbc (darcs head). Any tips on debugging this cabal install would be appreciated. $ runghc Setup.hs configure; runghc Setup.hs build Try with -v3 is: runghc Setup.hs build -v3 this will give extremely verbose output. We'd like to see the last bit to see what ghc command line exactly is failing. It'll show the command line arguments in Haskell show format eg [-I, /] Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install of HDBC-odbc fails on ghc 6.7, -I flag causes problems
On Tue, 2007-08-28 at 18:19 -0400, Thomas Hartman wrote: Well, I built with -v3 as suggested, but the ouptut doesn't seem that helpful to me. ghc compile commands, at any rate, do not appear to be outputted Sorry, I meant to pass -v3 to cabal, not to ghc compiling/running Setup.hs $ echo :main build | /usr/local/bin/ghci-6.7.20070816 -v3 Setup.hs 1build.out 2build.err like: runghc Setup.hs build -v3 Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Gtk2hs-users] [Haskell-cafe] Bug in Gtk2HS 0.9.12/SOE on WinXP? Or is it just me?
On Fri, 2007-08-24 at 11:58 +0200, Malte Milatz wrote: Peter Verswyvelen [EMAIL PROTECTED]: However, in the code below the blue and green triangle should render on top of each other, but the green triangle is rendered incorrectly. Being a newbie, I hesitate to file a bug report... Can anyone reproduce this? Maybe it works fine on unix? I can reproduce this with 0.9.12. I think this is now fixed. It's included in the current Gtk2Hs darcs repo or if you want to use your existing Gtk2Hs-0.9.12 installation you can get the updated soegtk package from hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/soegtk Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 2D game graphics library for Haskell?
On Fri, 2007-08-24 at 12:31 +0200, peterv wrote: Anyway, SOE is great for learning Haskell, but it lacks a couple of fundamental functions to make it really attractive, like: - Support for images - Support for rendering to an “offscreen graphics surface” and reading the pixels from that surface (for pixel-wise collision detection) - Support for detecting non-ASCII key presses (cursor keys, etc) - Support for joysticks Concurrent Clean seems to have a nice 2D game library and PLT/DrScheme also has nice support for basic 2D graphics, but somehow I feel Haskell is more mature and more elegant. So before digging into “advanced” APIs (like GTK itself, which I know nothing about, I’m a Win32 GDI/XNA/WPF expert), I should ask the question if something similar exists? It has to be as simple as SOE. Would it be possible to extend the GTK SOE with support for the features mentioned above? Is this insanely difficult for someone like me who knows a lot about Win32 but little Haskell? Graphics.SOE.Gtk is actually based on a very nice vector graphics library Graphics.Rendering.Cairo which can certainly do nice things like rendering to off-screen surfaces and much more besides, like transparency, arbitrary affine scaling/rotation/translation. It can load and save images in png and svg formats. It's also got a rather nice API, so instead of trying to extend the GTK SOE you might find it simpler just to use Cairo directly. Gtk+'s event processing can certainly detect non-ASCII key presses, it's just the SOE getKey api that's limited to Char. I've no idea how joystick input is implemented in X/Gtk, I expect it's possible. The other alternative though it's getting more low level, is to use the Haskell bindings for SDL. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal install of HDBC-odbc fails on ghc 6.7, -I flag causes problems
On Wed, 2007-08-29 at 10:05 -0400, Thomas Hartman wrote: Ah ok, so I did echo :main build -v3 | /usr/local/bin/ghci-6.7.20070816 Setup.hs 1build.out 2build.err and this does indeed seem more informative. advice? Turns out this was a bug in FilePath that Cabal was hitting. The bug was fixed some days ago in Cabal by not using the offending FilePath function. Hopefully the FilePath function will also be fixed. So the solution is to update your development version of Cabal to the latest version. Note that Cabal-1.1.6.x does not have this problem, only Cabal-1.1.7. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gtk library installation from ubuntu repository
On Fri, 2007-08-31 at 20:32 +0530, Vikrant wrote: Hi, I am using ubuntu 7.04. If I try to install libghc6-gtk-dev package using apt-get (or aptitude) my installation hangs at following stage building GHCi library /usr/lib/haskell-packages/ghc6/lib/gtk-0.9.10.5/HSgtk.o... It's a packaging bug that was fixed in the 0.9.11 debian package. So try and use the 0.9.11 version of the package: http://packages.debian.org/unstable/libdevel/libghc6-gtk-dev You may also like to pester some ubuntu maintainer person to get the ubuntu package up to at least the latest debian version. (I'm also hoping debian will get the Gtk2Hs 0.9.12 package that's been out for a little while now) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: Definition of the Haskell standard library
On Sat, 2007-09-01 at 18:47 +0200, Sven Panne wrote: On Tuesday 31 July 2007 19:39, Duncan Coutts wrote: [...] The docs for those packages would be available for packages installed via cabal (assuming the user did the optional haddock step) and would link to each other. Well, on a normal Linux distro a user should *never* have to call cabal (or any of its cousins) directly, the distro's package manager should be the used instead. On an e.g. RPM system, the .spec file would use Cabal to e.g. (un-)register a package, because RPM has to know what is installed, which other packages are prerequisites, how to cleanly uninstall, etc. IMHO Cabal should not try to mirror a full-fledged package system, simply because on every (non-Windows ;-) platform there are tons of native tools for this purpose, and Cabal is not in the driver's seat when it comes to SW installation. I think it's inevitable that there will always be a mixture of packages that are managed by the system package manager and ones that are too insignificant to be packaged by the distro. So cabal-install should cooperate with the system package manager somehow. Another strategy would be to have tools that the users can use to generate system packages from cabal packages and then install those via the system package manager. We already have such tools for rpm and gentoo ebuilds. Again, these would be for the case of less significant package that the distro does not package itself. For example, gentoo has a tool that can be used to install perl CPAN packages via the system package manager, since there are many 1000's of CPAN packages and only a few hundred of those are included in the main portage collection. There are other cases not covered by system package managers, like unprivileged user installations under $HOME. The problem with generating one of those is what manages it? What package would it belong to etc. Of course we are not the first project to face this kind of problem: Texinfo offers a central contents page as well. To maintain this page, it comes with [..] A install-haddock tool would be the solution IMHO. That re-generates the index page, right. Perhaps haddock itself should be extended with this ability. All it should need to do is read all the .haddock files that ghc-pkg knows about and generate the index page from that. I assume the .haddock files contain enough information to do this, or it could be modified to include enough. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage and GHC 6.8
On Sat, 2007-09-08 at 14:50 +0100, Neil Mitchell wrote: Hi Neil, Given that GHC 6.8 is just around the corner and, given how it has re-organised the libraries so that the dependencies in many (most/all) the packages in the hackage DB are now not correct. Is there a plan of how to get hackage DB up to speed with GHC 6.8 ? I think whatever we go with will be deeply painful. Especially given the switch to Cabal configurations comes at the same time, rather than before. Cabal 1.2 is out now and supports configurations and current ghc: http://haskell.org/cabal/download.html Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting folds over bytestring lists?
In message [EMAIL PROTECTED] Justin Bailey [EMAIL PROTECTED] writes: I have a data structure which is a list of bytestrings, but externally it looks like one big string. A lazy bytestring is a list of strict bytestring which externally looks like one big string. Could you not just use a lazy bytestring and it's take and drop functions? Perhaps you can help me understand what it is you're trying to do? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting folds over bytestring lists?
In message [EMAIL PROTECTED] Justin Bailey [EMAIL PROTECTED] writes: On 9/20/07, Duncan Coutts [EMAIL PROTECTED] wrote: A lazy bytestring is a list of strict bytestring which externally looks like one big string. Could you not just use a lazy bytestring and it's take and drop functions? Perhaps you can help me understand what it is you're trying to do? I'm working on the ICFP contest from this year, and the algorithm frequently prepends long strings to the front of the DNA string being processed. I originally worked only with a lazy bytestring but it 'append' wasn't fast enough, so I'm trying this representation. But you do realise it's exactly the same representation. Append for a lazy bytestring is O(n) in the number of chunks n, this will also be true for your 'new' representation. Your email makes me think I should work directly with a list of strict bytestrings, That's exactly what a lazy bytestring is. You'll not get any performance improvements without changing the data representation. A list is not good enough for what you want to do because so many operations are O(n) in the number of chunks. but in that case what happens when I want to take a large chunk of strings out of the middle of the list? Would that be an O(n) operation? Yes. That's exactly the problem. What you want rather than a list of strict bytestrings is a tree of strict bytestrings. You want a fingertree of strict bytestrings: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fingertree newtype ByteSequence = BS (FingerTree (Sum Int) Strict.ByteString) instance Measured (Sum Int) Strict.ByteString where measure = Sum . Strict.length You'll have to wrap the operations you need, (like split, take, drop and append) to make the ByteSequence look like a single sequence of bytes rather than a sequence of chunks. You probably want to enforce an invariant that no chunk is ever empty (as we do for lazy bytestrings). For best performance over a large number of inserts and deletes you might need to implement merging adjacent small blocks so that the block size does not degrade too much. An alternative structure if you tend to do lots of inserts and deletes at near the same spot is a zipper structure with a cursor. I'm not so sure what the best structure for that might be, perhaps just a pair of finger trees giving the parts of the sequence before and after the insertion point (since finger trees give fast access to the ends but slower O(log n) access to points n chunks from the closer end). Have fun :-) I should point out that other people who did this year's ICFP contest have also looked at structures like this (though mostly after the contest finished), so you might want to talk or collaborate with them. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PROPOSAL: New efficient Unicode string library.
In message [EMAIL PROTECTED] Jonathan Cast [EMAIL PROTECTED] writes: On Wed, 2007-09-26 at 09:05 +0200, Johan Tibell wrote: If UTF-16 is what's used by everyone else (how about Java? Python?) I think that's a strong reason to use it. I don't know Unicode well enough to say otherwise. I disagree. I realize I'm a dissenter in this regard, but my position is: excellent Unix support first, portability second, excellent support for Win32/MacOS a distant third. That seems to be the opposite of every language's position. Unix absolutely needs UTF-8 for backward compatibility. I think you're talking about different things, internal vs external representations. Certainly we must support UTF-8 as an external representation. The choice of internal representation is independent of that. It could be [Char] or some memory efficient packed format in a standard encoding like UTF-8,16,32. The choice depends mostly on ease of implementation and performance. Some formats are easier/faster to process but there are also conversion costs so in some use cases there is a performance benefit to the internal representation being the same as the external representation. So, the obvious choices of internal representation are UTF-8 and UTF-16. UTF-8 has the advantage of being the same as a common external representation so conversion is cheap (only need to validate rather than copy). UTF-8 is more compact for western languages but less compact for eastern languages compared to UTF-16. UTF-8 is a more complex encoding in the common cases than UTF-16. In the common case UTF-16 is effectively fixed width. According to the ICU implementors this has speed advantages (probably due to branch prediction and smaller code size). One solution is to do both and benchmark them. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: On 2007-09-27, Deborah Goldsmith [EMAIL PROTECTED] wrote: On Sep 26, 2007, at 11:06 AM, Aaron Denney wrote: UTF-16 has no advantage over UTF-8 in this respect, because of surrogate pairs and combining characters. Good point. Well, not so much. As Duncan mentioned, it's a matter of what the most common case is. UTF-16 is effectively fixed-width for the majority of text in the majority of languages. Combining sequences and surrogate pairs are relatively infrequent. Infrequent, but they exist, which means you can't seek x/2 bytes ahead to seek x characters ahead. All such seeking must be linear for both UTF-16 *and* UTF-8. And in [Char] for all these years, yet I don't hear people complaining. Most string processing is linear and does not need random access to characters. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
In message [EMAIL PROTECTED] Tony Finch [EMAIL PROTECTED] writes: On Thu, 27 Sep 2007, Ross Paterson wrote: Combining characters are not an issue here, just the surrogate pairs, because we're discussing representations of sequences of Chars (Unicode code points). I dislike referring to unicode code points as characters because that tends to imply a lot of invalid simplifications. Just to be pedantic, Ross did say Char not character. A Char is defined in the Haskell report as a Unicode code point. As you say, that does not directly correspond to what many people think of as a character due to combining characters etc. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: binary 0.4: high performance, pure binary parsing and serialisation
In message [EMAIL PROTECTED] Don Stewart [EMAIL PROTECTED] writes: ketil: Don Stewart [EMAIL PROTECTED] writes: The main thing is porting to ghc 6.8 -- which means the new (*faster*) lazy bytestring representation, and the smp parallel quickcheck driver for the testsuite (it'll use N cores, watch the jobs migrate around). Binary 0.4 seems to require bytestring 0.9, the library formerly known as fps. I just want to mention it, as most network resources (as found by Google) only have discoverd fps 0.7, which is not going to work. (Oh, and yes, it's at darcs.haskell.org/bytestring/ ) It'd be nice - since I know you're at it anyway :-) - if hackage/cabal would have some support for backwards compatibility. I know GHC 6.8 is the thing to get, but some of us still install what comes with our distribution, so I hope 6.6.1 still will be supported. Normally this is farily easy to do, with cabal configurations. (See bytestring's .cabal file for example). However, the binary internals changed in such a way that it wasn't worth preserving backwards buildability. Instead, you should use binary 0.3 with ghc 6.6 libs I'm not convinced that it's not possible. I made my zlib, bzlib and iconv libs work with ghc-6.4, 6.6, and 6.8 which all reply on the internals of Data.ByteString. So just as soon as I get my ADSL working I'll have a look at making binary work with ghc-6.6 too (and getting the newer faster code integrated as well). So much to do... Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why doesn't Hackage link to Haddock documentation anymore?
On Fri, 2007-10-19 at 09:41 -0700, Conal Elliott wrote: Will hackage docs use haddock 2.0 any time soon, for libraries that use language extensions not supported by the older haddock? David Waern told me today that he's working on a new patch to integrate haddock-2.0 support into Cabal. So when that's done and haddock-2.0 is released then I expect we can use it on hackage. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
(moving to haskell-cafe) On Sun, 2007-10-21 at 14:55 +0200, Udo Stenzel wrote: Duncan Coutts wrote: New tarball releases of Cabal-1.2.1, bytestring-0.9, binary-0.4.1, tar and others (zlib, bzlib, iconv) will appear on hackage in the next few days. I just tried one of them, iconv. First it wants a recent cabal; that's fine, I installed the darcs version. Then I get this: | Codec/Text/IConv.hs:64:17: | Could not find module `Data.ByteString': | it is a member of package bytestring-0.9, which is hidden Okay, it obviously tries to be smart, but doesn't know that I upgraded to a separate ByteString library. Right. So I take out the gunk about 'flag(bytestring-in-base)' and try again: | Setup: At least the following dependencies are missing: | base 2.0||=2.2 Of course that was to be expected, since I have base-2.0 hacked to not get in conflict with bytestring-0.9, and you (Duncan) couldn't possibly anticipate this (or could you?). Right. It expects that if you have base = 2.0 2.2 then that version of base exports Data.ByteString. That's not an unreasonable assumption I think. You can hack the .cabal file further to make it work in your situation, but I don't suggest that's a great long term solution. If you wanted to hack it you'd change it to just: build-depends: base, bytestring = 0.9 without any 'if' or flags and without cpp-options: -DBYTESTRING_IN_BASE. Now what am I supposed to do? Give my messed up base a new version number? (Which one?) Rewrite every single cabal file, hoping that they never become Turing complete turning the exercise into a reverse engineering fest rivaling the ICFP contest? Bite the bullet and install GHC from darcs? So you've changed the API of base-2.1.1 so that will break packages that expect that they know what the api of base-2.1.1 actually is. You can either hack the .cabal files of things you try to install (which would be a pain, I don't recommend it) or you could revert your changes to your base package. For the time being, I'll go with 'ghc --make'. And I think that cabal configurations are an exceptionally bad idea carried to perfection. Don't get me wrong, I'm not claiming that the changes in what is in and what is out of the base package could not have been handled better. Configurations just happen to be one mechanism that we have available now to enable packages to build with various versions of the base package. The other alternative seemed to be that they'd only work with an old or a new version but not both. There are plenty of things that we could have done better to make the base changes less disruptive but I really don't think you can blame configurations for that or for adding to that problem. If we had made different decisions at various points we would not need configurations for this purpose right now. We'd still need configurations for other things. Configurations serve other purposes too. They're not just for managing the mess over moving modules between packages. They're generally to allow changes in the way a package is built depending on the environment in which the package is built to reduce the need for non-portable configure scripts and wadges of fragile code in Setup.hs files. They make things worse, not better. (And that's just GHC 6.6... I don't want to even think about what happens on Hugs, JHC and YHC.) It's mostly orthogonal to the Haskell implementation since the base package is shared by all Haskell implementations. What would it take to talk you into giving up on supporting the broken base-2.0 and incorporating a patch to unbreak it into the bytestring setup? Can I stop the insanity by simply writing that patch? What kind of change are you suggesting? We have to support base 2.x because that is the versions of base that come with ghc-6.6.x. We cannot sensibly install the separate bytestring package with ghc-6.6.x because it would clash with the base package there. We cannot easily upgrade base in existing installations of ghc because ghc is just not designed with that in mind at the moment. The solution we're using at the moment is to use the separate bytestring package with ghc-6.4 and ghc-6.8 and to use the version of the bytestring code in base-2.x for ghc-6.6.x. That's what the newest versions of zlib, bzlib, iconv, binary, tar etc do. They all work with ghc-6.4, 6.6 and 6.8 (using Cabal-1.2.x). So all will not be plain sailing for the first few weeks after ghc-6.8 comes out as maintainers update their packages. People will have to be patient and/or stick to ghc-6.6 for a bit. Okay, so now we have *three* almost-stable versions of GHC in wide circulation, all of them broken in different ways with respect to cabal packages. I feel tears welling up... So far this weekend I've uploaded to hackage: Cabal-1.2.1, bytestring-0.9, unix-compat-0.1.1, tar-0.1.1 and Kolmodin uploaded binary-0.4.1. When hackage itself is using Cabal-1.2.1 then I can
Re: [Haskell-cafe] Automatic file closing after readFile
On Sun, 2007-10-21 at 17:15 -0400, Albert Y. C. Lai wrote: Magnus Therning wrote: I'll certainly try to look into all of that. However, I suspect your suggestion doesn't scale very well. On my original code it's easy, it was less than 10 lines, but how do I know where to start looking if it's a program of 100 lines, or 1000 lines? The problem could occur in an updated library that I just use... Well you get the idea :-) A library function is supposed to tell you its time usage, memory usage, file usage, ... generally resource usage, as part of its specification. A 100-line program is not supposed to be a monolith. It is supposed to be a combination of 10 functions (or 10 parts; I'll call them functions anyway), 10 lines each. Each function is supposed to come with its specification too, which again tells you its resource usage. To reason about the 100-line program, you only need to reason about 10 lines of specifications. I'm not sure what semantics we would use to reason about resource use in specifications like this. Our standard semantics abstract over space, time and sharing properties of our programs. For a lazy language, resource specifications of functions do not compose in a simple way. For example we might naively say that [1..m] uses m time and space and that take n takes at most n time and space but then take n [1..m] does not take the sum of these two time/space specifications. In more complex examples the connection is even less obvious. One more accurate way to look at resource use is to say that we only consider time and space to reduce to WHNF and then ask that question when we apply various evaluation functions to the expression. Different evaluation functions would force various parts of the value. Then when we plug an expression into different contexts we see what kind of evaluation function that context is and use that in our question about the resource use to evaluate the expression. Still, that only gives you total resource use, not maximum resource use at any point during evaluation which is important for space. Summary: it's not so simple. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
On Sun, 2007-10-21 at 23:42 +0200, Udo Stenzel wrote: Duncan Coutts wrote: You can hack the .cabal file further to make it work in your situation, but I don't suggest that's a great long term solution. If you wanted to hack it you'd change it to just: build-depends: base, bytestring = 0.9 without any 'if' or flags and without cpp-options: -DBYTESTRING_IN_BASE. Exactly what I did, and I consider that a crock, not a solution. I agree, that's what I said. The solution we're using at the moment is to use the separate bytestring package with ghc-6.4 and ghc-6.8 and to use the version of the bytestring code in base-2.x for ghc-6.6.x. That's what the newest versions of zlib, bzlib, iconv, binary, tar etc do. They all work with ghc-6.4, 6.6 and 6.8 (using Cabal-1.2.x). IOW, on GHC 6.6 I'm stuck with bytestring-0.8 and no package that expects bytestring = 0.9 will work unless it contains an ugly workaround (an #ifdef). Unless my memory is failing me, that was not a design objective of cabal. Indeed. That was not a design objective. However it's not something Cabal can change, it's a property of the underlying Haskell implementations. Currently it is not possible for a program to use two packages that have overlapping exposed modules. Also, it is essentially impossible at the moment to upgrade the base library on an existing ghc installation. These two facts together are why ghc-6.6 users are stuck with the implementations provided by base-2.x and cannot overlay things on top. It is also the motivation for breaking up the base package into smaller pieces which can be upgraded independently. (The base package itself will still not be easily upgradable but the other packages that were split out do become upgradable). What kind of change are you suggesting? We have to support base 2.x because that is the versions of base that come with ghc-6.6.x. We cannot sensibly install the separate bytestring package with ghc-6.6.x because it would clash with the base package there. We cannot easily upgrade base in existing installations of ghc because ghc is just not designed with that in mind at the moment. I'm suggesting to pretend that base never included ByteString, to have an empty bytestring-0.8 package for GHC-6.6 (that just copies the configuration of base) and to have bytestring 0.8 fix the configuration of base for GHC-6.6. GHC-6.6 is broken, and I'm suggesting to fix it instead of accepting the breakage. I see why it's an attractive solution but I just don't think it is practical. We cannot go changing existing installations just like that. For one thing it's only possible for root users. For another one is not supposed to modify packages managed by the system package manger. We'd never get everyone to change. If this was the right time for grand visions, I'd propose a feature comparable to Provides: and Replaces: of Debian's apt, maybe combined with packages that re-export modules and a better mechanism (read: any mechanism) to resolve conflicts between packages. base may not be upgradeable, but parts of it are. Oh, and I think multiple packages providing the same modules and then causing conflicts is just a bad idea, unless of of them took precedence. I agree, any of these things would be great. At the moment none of them are implemented (and they cannot be implemented in Cabal without corresponding support from the Haskell implementations). The right thing to do is to use the latest Cabal-1.2.x with whichever version of ghc you happen to have and not to use a hacked version of base. So the API of ByteString 0.8 is now fixed and nothing is allowed to depend on anything newer, and that will be the case for at least the next 2 years (until GHC 6.8 trickles down into Linux distributions in actual use). Correct? Right. In practise that's not too bad since the public api of bytestring hardly changed. The internal changes only affect extension packages that use the internal api, things like binary. Unless I need recent developments. Then I just copy the Data/ByteString tree into my project directory... Funnily enough that's the only thing that will work, because ghc allows local modules to mask ones from a package like base, but not for modules from two used packages to overlap. There's not a lot Cabal can do to work around that. There is no need to upgrade immediately to ghc-6.8, in fact at the moment that'd make the situation worse since most packages need tweaks to work with it. And does that feel right to you? Should they actually need tweaks? No. I'd have preferred a better solution. Cabal configurations were not designed with this purpose in mind. You listed several better solutions. However the base breakup went ahead without any of them in place. The only currently implemented solution is to take advantage of configurations. As you notice the configurations syntax for this purpose is a bit clumsy, because
Re: [Haskell-cafe] Re: How much of Haskell was possible 20 years ago?
On Mon, 2007-10-22 at 10:05 -0700, Jeremy Shaw wrote: I like Haskell, and use it as my main language. However, compiling a Haskell program usually takes a lot of memory and CPU. Last night I was running top, and noticed cc1 consuming 101MB of RAM :) I have also seen ar (the thing that makes .a files) consume 512MB of RAM. You need to upgrade your binutils! I sent in a patch to binutils to fix exactly this problem that ar/ranlib takes so much memory when building large ghc split-objs libraries. The fix got included in binutils 2.17. I do hope Linspire is using a version with the fix ;-). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: zlib and bzlib 0.4 releases
I'm pleased to announce updates to the zlib and bzlib packages. The releases are on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bzlib What's new in these releases is that the packages work with a wider range of systems and versions of dependent packages. In particular: * Works out of the box on Windows It uses a bundled copy of the zlib C library (version 1.2.3) on Windows and uses the system zlib on all other platforms. * Works with ghc-6.4, 6.6, 6.8 * Works with new bytestring versions * Works with older versions of zlib (eg zlib 1.1 on MacOS X) They require Cabal-1.2.1 (which is also available on hackage and works with all ghc versions). The zlib and bzlib packages provide functions for compression and decompression in the gzip and bzip2 formats. Both provide pure functions on streams of data represented by lazy ByteStrings: compress, decompress :: ByteString - ByteString This makes it easy to use either in memory or with disk or network IO. For example a simple gzip compression program is just: import qualified Data.ByteString.Lazy as ByteString import qualified Codec.Compression.GZip as GZip main = ByteString.interact GZip.compress Or you could lazily read in and decompress .gz file using: content - fmap GZip.decompress (ByteString.readFile file) Both packages are bindings to the corresponding C libs, so they depend on those C libraries. Fortunately both zlib and bzlib2 are available on every OS. It also means that the compression speed is as you would expect since it's the C lib that is doing all the work. The zlib package is now being used in cabal-install to work with .tar.gz files. So it has actually been tested on Windows. The development versions have new homes on code.haskell.org. I'm very happy to get feedback on the API, the documentation or of course any bug reports. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: zlib and bzlib 0.4 releases
On Tue, 2007-10-23 at 16:34 +0200, Yitzchak Gale wrote: Duncan Coutts wrote: I'm very happy to get feedback on the API, the documentation or of course any bug reports. It would be nice if the API could be the same for all character and data codecs. Hmm, though the inputs and outputs are different types in general. With compression we're working with uninterpreted streams of bytes. For character encoding/decoding we're converting between internal Unicode representations and external representations as sequences of bytes. That is, (de)compression does not fit into encode :: [Word8] - String decode :: String - [Word8] If we parametrise over the input and output types we get something far too general. Also, from my point of view there's nothing wrong with giving (de)compression a different function name from character encoding. In my opinion it is easier to read: content - return . decode . decompress = readFile file than content - return . decode . decode = readFile file Where I mean to read a compressed unicode text file. Names are good! :-) Am I missing something or just being curmudgeonly? :-) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linking problems with a fresh gtk2hs build
On Fri, 2007-10-26 at 09:17 -0400, Olivier Boudry wrote: Hello, I just built gtk2hs 0.9.12 using MinGW, GTK_2.0 and ghc-6.8.0.20071016. I just changed some EXTERNALDEPS in the Makefile based on info found in the following page http://haskell.org/haskellwiki/Grapefruit I'm not sure what's going wrong there. I should note that there is a gtk2hs-0.9.12 branch which contains the fixes to build with ghc-6.8.0.x and there will be a gtk2hs point release once ghc-6.8.1 is released. You could try cleaning, and ./configure --disable-split-objs to see if that fares any better. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with PDF/PS backend in GTK2HS
On Sun, 2007-10-28 at 15:07 +0100, Peter Verswyvelen wrote: I have a strange problem, which is so elementary that I think I must be missing something... In GTK2HS, when I draw text using using textPath, the text is located at different locations depending on which backend is used. I'm not talking about a difference of a couple of pixels , but in my case it's half a page off. The PNG and Win32 backend work fine, but the PDF/PS backends get it wrong. For example, I modified the Text.hs demo in the demos/Cairo subdirectory so it also outputs PDF. Here the text is also at different locations, so I guess it's not just my code. Code is pasted below. I'm using Windows, and GTK2HS version 0.9.12 from http://www.haskell.org/gtk2hs Maybe someone could give this a quick test on Linux? I guess this is most likely a Cairo problem, and has nothing to do with the Haskell wrapper? Still this is hard to believe, since these kinds of bugs would be quickly found. Yes, I get the same. It works fine on Linux and the text has the wrong position on Windows. I'm doing a new Gtk2Hs build soon for compatibility with ghc-6.8 and I can try with a more recent version of cairo then and see if the bug has been fixed. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The question of ByteString
On Fri, 2007-11-02 at 21:35 +, Andrew Coppin wrote: Well OK, maybe I was a little vague. Let me be a bit more specific... If you do text processing using ByteString rather than String, you get dramatically better performance in time and space. For me, this raises a number of questions: 1. Why do I have to type ByteString in my code? Why isn't the compiler automatically performing this optimisation for me? (I.e., is there some observable property that is changed? Yes, the semantics are different. ByteString is stricter. In some circumstances you could discover that some list is being used sufficiently strictly (spine and element strict) that you could do a representation change to use strict arrays. It is something I have pondered occasionally and I think that is an interesting avenue for research. One approach might be to do a more sophisticated strictness analysis earlier in the compilation process; one that gives details on strictness of substructure, ie the tail/element strictness in lists. Then if this strictness information were available to the rule matching then we might be able to write rules that change certain functions to work on optimised data representations. However this is likely to be quite fragile. I usually think that it's better to declare the strictness you want up front in one place, and have that be propagated, rather than doing the reverse of inferring that something could be stricter from all the use sites. Strictness annotations on data constructors are a good example of this. Currently the answer is yes: the ByteString interface only provides trancated Unicode characters. But, in principle, that could be changed.) Indeed it could, we could provide a proper Unicode string type. 2. ByteString makes text strings faster. But what about other kinds of collections? Can't we do something similar to them that makes them go faster? There is much less benefit for other collections since the overheads of generic structures are smaller for other types. Note that the NDP parallel arrays stuff uses type functions to calculate optimised data representations for arrays of types. As I understand it, ByteString is faster due to several factors. First of all, it's stricter. Do that's the semantic difference. Secondly, it's an unboxed structure (so you eliminate layers of indirection and there's less GC load). Which is the representation optimisation allowed by the semantic change of making it stricter. Third, it's implemented as an array that looks like a linked list. Given how ubiquitous lists are in Haskell, array that looks like a linked list sounds like one seriously useful data type! Yet ByteString seems to be the only implementation of this concept - and only for lists on unboxed bytes. (Not even unboxed Word16 or anything else, *only* Word8.) If I understand this correctly, a ByteString is actually a linked list of large array chunks. (This presumably yields fastER random access than a plain linked list?) Also, it seems to be possible to create a new array which is merely a subrange of an existing one, without any copying; the standard array API doesn't seem to provide this, yet it sounds damn useful. I think the NDP project should get us most of this stuff actually. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] package maintainers: updating your packages to work with GHC 6.8.1
On Mon, 2007-11-05 at 03:12 +, Duncan Coutts wrote: If you maintain a Haskell package this is for you. flag splitBase description: Choose the new smaller, split-up base package. library if flag(splitBase) build-depends: base = 3, containers else build-depends: base 3 By the way, if you have several common deps it's perfectly ok to factor them out like this: Flag splitBase Description: Choose the new smaller, split-up base package. Library Build-Depends: network, HTTP, HTTP-Simple, MissingH, time=1.1.1 if flag(splitBase) Build-Depends: base = 3, containers else Build-Depends: base 3 In a future version of Cabal we might have this nicer syntax: Library Build-Depends: base, network, HTTP ,HTTP-Simple, MissingH, time=1.1.1 if package(base = 3) Build-Depends: containers Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] package maintainers: updating your packages to work with GHC 6.8.1
On Mon, 2007-11-05 at 12:47 +0100, Henning Thielemann wrote: When Cabal development started I suggested to use Haskell code as configuration file, because there will be much extensions and the package description will not fit into a simple syntax soon. So of course there is a trade-off to be made in the expressiveness of the language used for package descriptions build procedures. My experience with build systems (and as a gentoo packager I've seen quite a few) tells me that a full turing complete language gives developers too much rope with which to hang themselves. Developers make packages which work on their systems; they cannot be expected to test in lots of different environments. So inevitably platform-specificisms creep in because there is no easy way to check for their absence (you'd have to actually go and build on a dozen different platforms). With a less expressive language that hides platform details there is more wiggle room for the packaging system to interpret the package in a way that makes sense for different platforms. The one place we do have general Haskell code in in Setup.hs files. I've seen quite a few of these now and almost every single non-trivial Setup.hs is wrong in some respect. They work in the normal case on the developers machine but fail when building a distro package (where the build and install steps are separated) or would fail on windows or a myriad of other things. By contrast when we have some bug in Cabal on some platform we can fix it in one place, not in the Setup.hs file of every single package. This suggestion was rejected because the Package description should be readable by an IDE. With the flags and package version comparison we move quickly to a Turing complete scripting language in form of a package description. :-) It's pretty important that it never gets there :-). Btw. does the Setup.hs script still serves a purpose? Some, but as little as possible. I'd expect only 10% of the most complex packages will need to use them in future. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell stuff on Windows
On Wed, 2007-11-07 at 17:34 +0100, Arthur van Leeuwen wrote: Hello all, maybe I'm just not used enough to Windows, but let me explain my woes of today. It seems to me to be *much* too hard to get a full install of GHC + GTK2Hs going on Windows, going from the idea that I want the currently released stable versions of everything. It is far too hard. For one thing the released tarball does not build with ghc-6.8.1. That's why I'm working on a new point release. So, this is the way I progressed (from a clean Windows install): - Installed MinGW 5.1.3 - Installed MSYS 1.0.10 - Installed GHC 6.8.1 - edit /etc/fstab in MSYS to correctly bind MinGW - Installed gtk-dev-2.10.11-win32-1 - Downloaded gtk2hs-0.9.12.tar.gz - cd /d/haskell/gtk2hs-0.9.12 - ran configure - discovered I needed happy (this was not documented!) Hmm, that's not right. The gtk2hs tarballs come with the lexer and parser pre generated. The configure script checks for alex and happy but does not (should not) fail if they're not present and the pre-generated code is present. I certainly build on a windows server where alex and happy are not installed. - Downloaded happy-1.17.tar.gz - unpacked, configured, built, installed - ran configure for gtk2hs - discovered I needed alex (this was not documented!) - Downloaded alex-2.10.tar.gz - Setup.lhs of alex-2.10 did not compile due importing Distribution.Simple(compilerPath) - Installed darcs - darcs got alex development tree - Setup.lhs of alex-2.10 compiled - building alex-2.10 failed due to wishing an existing alex - broke down and downloaded alex-2.10 binaries - installed alex-2.10 next to happy in C:\Program Files\Haskell\bin - ran configure for gtk2hs - ran make - discovered alex should not be in C:\Program Files as make breaks on paths with embedded spaces... - copied C:\Program Files\Haskell to C:\Haskell and modified $PATH - reran configure for gtk2hs - ran make - discovered gtk2hs 0.9.12 hides 'containers' That's the bit where we notice gtk2hs-0.9.12 was released well before ghc-6.8.1 and thus does not work with it. Every non-trivial package needs updating in various minor ways to work with ghc-6.8.1. - broke down and darcs got gtk2hs development tree - installed automake - ran autoreconf I've never managed to get automake to work on windows. I always generate tarballs under linux and then build them on windows. This also allows me to avoid installing happy/alex on windows. - discovered automake for MSYS 1.0.10 is too old - installed automake-1.9 - ran aclocal-1.9 - ran autoconf - ran configure - discovered I need to explicitly add GTK libs to aclocal - ran aclocal-1.9 -I with GTK library path - ran autoconf Wow, it actually worked did it? - ran configure for gtk2hs - ran make Oh good, glad that bit works :-) - complained on IRC - ran make install I expect it fails in the package registration stage right? Yes, I never do that, I always build images for the installer and never install direct, so that path is probably bit-rotted. - sighed deeply Ofcourse, on complaining I learned that hackage contains alex 2.2, rather than 2.10, but that is not apparent from the alex webpages. It seems to me that much of this is way too hard to figure out... figuring out the dependency graph should not be necessary, as the developers should know what parts go into their code! Yes it is too hard. In the case of Gtk2Hs I think it'll be easier when Gtk2hs changes to use Cabal for it's build system. Then it will not require mingw/msys which should improve things dramatically. Furthermore, as much as I applaud hackage, it is not ready for use, as it does not afford things you might want, such as searching for latest (stable) releases of packages. Yes, there is nothing to distinguish latest from stable. With sufficiently accurate deps I think this is solvable, and perhaps the ability to tweak the deps after a package is released (to tighten them if they were too lax for example). Plus, it is still not the default go-to place for many things. That's changing reasonably quickly. Especially if you put pressure on maintainers of packages that you get from anywhere other than hackage. Repeat the mantra if it's not on hackage it doesn't exist. Maybe developers that decide to put their most recent versions on hackage could document that on the main webpages of their code? (I've ran into this with FileManip as well, not just with Alex). Good idea. So the good news for you is that the windows installer for Gtk2Hs (which will be compatible with ghc-6.6.1 and 6.8.1) will be released in a day or so. I might ask you to try a pre-release for me. Duncan
Re: [Haskell-cafe] Building Haskell stuff on Windows
On Wed, 2007-11-07 at 23:20 +0100, Arthur van Leeuwen wrote: With kind regards, Arthur. (Who will surely do more Windows development with Haskell soonish) Good! We need more developers to help us with windows stuff. We're in this difficult situation where half of our users use Windows (according to the GHC survey) but the vast majority of developers use Linux, several use Mac OS and approximately 3 use Windows as their primary platform. So supporting Windows becomes difficult. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell performance question
On Thu, 2007-11-08 at 13:00 -0800, Dan Piponi wrote: It looks like my whole question might become moot with ghc 6.8.1, but so far I've been unable to build it due to the cyclic happy dependency. You really do not need happy to build ghc. Just ignore the extralibs tarball. You can install any of those libs that you need later from hackage. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell stuff on Windows
On Thu, 2007-11-08 at 08:56 +0100, Arthur van Leeuwen wrote: Well, honestly, that was a bit of a fib: the tarball's configure did in fact not break on alex and haskell. Just the development version did. Ah yes. Well, I didn't have any Unix available at that point, so I kinda had to, even though I remembered the world of pain that is autoconf and automake. I hates automake and autoconf :-) It does amaze me that while the output of autoconf/automake is highly portable, running autoconf automake is so incredibly fragile. It seems to fail fairly randomly even across different linux distros. Yeah, if you make sure not to have any binaries in paths with embedded spaces... ;) Yes, another problem with shell scripts / make / autoconf etc. The built installer can be installed anywhere, but building from source requires no spaces. That's another issue using Cabal should solve. Cabal always calls rawSystem so there are no quiting issues. No. It actually installed. However, building binaries against the installed gtk2hs then fails with a linker error... Oh. :-( Actually that might be due to registration stuff too. Yes it is too hard. In the case of Gtk2Hs I think it'll be easier when Gtk2hs changes to use Cabal for it's build system. Then it will not require mingw/msys which should improve things dramatically. Should it? I think the big issue is autoconf rather than MSYS, and path troubles related to make and configure... and while this is slightly less painful on Unix systems it still hurts quite a bit, even there. Right, the problem is both msys/mingw because they're hard to install and autoconf/automake because they're a pain. Using Cabal to build Gtk2Hs will allow us to get rid of both. Furthermore, as much as I applaud hackage, it is not ready for use, as it does not afford things you might want, such as searching for latest (stable) releases of packages. Yes, there is nothing to distinguish latest from stable. With sufficiently accurate deps I think this is solvable, and perhaps the ability to tweak the deps after a package is released (to tighten them if they were too lax for example). That would be nice, but having the status bits would be even better. It makes distinguishing between 'this can be used in production code' and 'this is for the brave, beware of lions' possible. Just having the dependencies doesn't. And the distinction is a strong necessity when actually using Haskell... Who do you think would decide what is stable? How would that information be communicated? Perhaps what you really want is a standard platform that's been tested as a unit. Perhaps what we want is automated feedback reporting build successes and failures so we can inform people selecting packages about popularity, maturity and compatibility. Ah, yes, that is a thing. However, googling for alex does not lead me to hackage, nor does the alex webpage. Ditto for Happy. We need to make it the first place to look. We're trying to get to the stage where we can deploy cabal-install widely, then you'd try: $ cabal list foo and only if it was not available then you'd go and google for the package. Help with improving cabal-install from anyone would be much appreciated and very useful. Quite a few people have been trying it out and giving us feedback on how they would expect it to behave. So we know mostly where we need to go, we just need help in terms of development time to get there. So the good news for you is that the windows installer for Gtk2Hs (which will be compatible with ghc-6.6.1 and 6.8.1) will be released in a day or so. I might ask you to try a pre-release for me. Sorry, I've been a bit unavailable due to other work-related issues. No probs. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building Haskell stuff on Windows
On Thu, 2007-11-08 at 22:04 +, Andrew Coppin wrote: Is that why Cabal packages never ever install on Windows? Could you be more specific what your problems are? Not to the point that anybody is likely to be able to help me... According to the instructions, if I'm understanding this correctly, you're supposed to be able to unpack a package, and do runhaskell Setup configure runhaskell Setup make runhaskell Setup install Yep, that's the procedure. Though as I keep telling everyone we're trying to replace that with just: cabal install blah I tested this on Windows the other day, it's nearly working, just a couple bugs to go. However, having so far tried this with not less than 3 different packages downloaded from Hackage, not one single one has ever worked. I suppose it's possible that I just happened to pick 3 packages that all have something wrong with them and normally it would work just fine... but all I've ever seen it do it fail. I tried to install HaXmL. It seemed to install, yet GHC insisted it wasn't installed. Now that one I would expect to work under windows since it's pure Haskell code. OK, so I'm being a little over-harsh here. In the 3rd case, there are some extra instructions that are supposed to make it work - and who knows, maybe when I go try them SDL will work perfectly. But so far, 0 out of 3 isn't very impressive. I had assumed that I'm just doing something wrong, or it isn't documented very well or something. But now I'm just wondering if it hasn't been tested on Windows very much... That's a big part of the problem. Most developers cannot or do not test under windows. This should not be a problem for pure Haskell modules but for anything that binds to C libraries it's a major problem. Under unix we can usually assume that the C library and it's header files are installed in a standard location. Under windows that's never true. Then as you noted, some packages use configure scripts which use sh. That'll never fly on a standard windows install. Hopefully over time we can replace those scripts with some better solution using Cabal. I realise it's much easier to sit here and criticise than to actually do something about fixing the problem. Clearly Cabal must work for somebody, so I was just wondering if my Cabal problems are because I'm on Windows, that's all. So the ones I would expect to work out of the box on Windows are the packages on hackage that use build-type: Simple and do not use extensions: ForeignFunctionInterface. Apart from that, it's going to be hit and miss until we work out a better system for reporting what works and what doesn't from hackage on different platforms. Some packages that use FFI work fine, like Cabal itself, or the zlib, bzlib packages. But those were specifically tested on Windows. (For what it's worth, I actually managed to build Gtk2hs from source under Linux - and I've never built anything on Linux before! It was really quite simple though. I mean, took about 2 hours to think about it, but it's a very old laptop...) :-) (btw the Gtk2Hs INSTALL file describes how to configure for a quicker build) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to do this in Haskell
On Sat, 2007-11-10 at 23:44 -0700, Chris Smith wrote: If you wanted to write a Haskell application that included a WYSIWYG HTML editor, how would you do it? More details: - I'll probably be using Gtk2Hs for the app, though that could change with a (very) good reason. I would look into binding extensions of the GtkMozEmbed widget. The current GtkMozEmbed API does not expose the Gecko engine's html editing features. Alternatively I'd look at binding the GtkHTML3 library. It's used as the html editor in the evolution email client. I'm not sure if WebKit/Gtk has html editing features, it might be worth looking into. As others have said, it's not easy however. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Somewhat random history question - chicken and egg
On Sun, 2007-11-11 at 07:43 -0500, Brent Yorgey wrote: GHC can be compiled with GHC 5.0 (or something around there). If they add a new feature, they don't use it in GHC for years and years. *Can* be compiled with GHC 5.0, or *is* compiled? Can. The version it is compiled with it always itself because it does a two stage bootstrap. I think for 6.8.x the minimum bootstrap version is now 6.0 or 6.2. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: How to do this in Haskell
On Mon, 2007-11-12 at 16:16 -0500, Joe Buehler wrote: Chris Smith wrote: Right, which is why I'm trying to avoid reinventing it. Writing a new HTML editor is not even a consideration. I'm looking at the effort to integrate the Mozilla editor component, and wondering if there are other components that could be used instead in a Gtk2Hs application. A not-so-well-known feature of X11 is reparenting of windows. You should be able to take any X11 app and have it display in a window of your choice inside your app. So pick an HTML editor and integrate it into your app that way. Ah yes, that's a good point. Gtk+ and Gtk2hs support this X11 feature: http://haskell.org/gtk2hs/docs/current/Graphics-UI-Gtk-Embedding-Plug.html http://haskell.org/gtk2hs/docs/current/Graphics-UI-Gtk-Embedding-Socket.html Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal problem?
On Wed, 2007-11-14 at 16:16 +, Jens Blanck wrote: sudo runghc Setup.hs install root's password: Setup.hs : Warning: Unknown field 'build-type' Setup.hs: error reading ./.setup-config; run setup configure command? I suspect your path is different for your root user, so it's picking up an old ghc and an old cabal version. You can tell it's an old version (probably 1.1.x) because it doesn't know about the new build-type field. You can work around it using: ghc --make Setup.hs -o setup sudo ./setup install Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal Main-Is restriction
On Thu, 2007-11-15 at 11:14 -0600, Nicolas Frisby wrote: It seems the meaning of the -main-is switch for GHC and the Main-Is build option for Cabal executables differ. With GHC, I can point to any function main in any module, but in Cabal I must point to a filename with precisely the module name Main. This is tying my hands with regard to organizing a default executable and exposing some of its functionality as a library. Is there a way to get around this restriction? I've filed your feature request in the Cabal trac: http://hackage.haskell.org/trac/hackage/ticket/179 Do please add your suggestions in a comment there. Login with username guest and password haskell' (note the apostrophe at the end). Is this currently possible? I recognize the add a separate Program-Main.hs file workaround, but I'll avoid it if I can. A workaround is to use: main-is: Program/Main.hs ghc-options: -main-is Program.Main Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellforge?
On Thu, 2007-11-15 at 15:56 -0200, Maurício wrote: Hi, Is there a Haskellforge somewhere, i.e., something like a sourceforge for open source Haskell programs, with darcs, automatic cabalization etc.? Has anyone tried that already? There is the Haskell Community server http://community.haskell.org/ It hosts darcs repos at http://code.haskell.org/ You can request an account and projects via: http://community.haskell.org/admin/ There are currently 44 registered developers and 41 hosted projects. It may host more services in future, like bug trackers. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dropSpace not exported in ByteString
On Thu, 2007-11-15 at 21:55 -0500, Olivier Boudry wrote: By the way, what's the reason dropSpaceEnd is defined but not exported nor used through a rule? I'm just curious. We decided when trying to standardise the API to start with just the equivalents of the Data.List functions. We have tracked changes to Data.List, adding intercalate and isInfixOf. If there is a compelling reason to add dropSpaceEnd to the Data.ByteString API then the same would probably apply to Data.List and so it should be proposed for there and then Data.ByteString will track it too. Alternatively, someone should make the case for why it should be added to bytestring but not list. There is probably room for more string oriented list functions in some library somewhere (especially crazy Unicode stuff), like Data.String. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: demanding lazy instances of Data.Binary
On Mon, 2007-11-19 at 13:39 -0800, Don Stewart wrote: nicolas.frisby: I've got a first draft with the newtype and just an instance for list. If you'd prefer fewer questions, please let me know ;) 0) I've cabalised it (lazy-binary), but I don't have anywhere to host it. Would it be appropriate to host on [1]darcs.haskell.org or HackageDB (yet?). Suggestions? You can host it on code.haskell.org, ask for an account here: I think we should consider if a lazier serialisation of lists shouldn't be the default first before thinking about forking the whole library. It depends on how much laziness you want. We could certainly make it so that this is true: (decode . encode) [1..] = [1..] rather than giving _|_. However the approach of Data.Binary is lazy serialisation but in chunks, big chunks. So while the above may be true, this would not be: (head . decode . encode) [1, _|_] = 1 because we generate 32k chunks of data when serialising. But do you really need it to be this lazy? Would it enough for it to be lazy in chunks. There is a good argument I think that the current fully strict serialisation is bad just from a performance perspective, and that instead we should serialise lists semi-lazily, using a chunked representation. For example Neil's serialisation library uses length prefixed chunks with a maximum chunk size of 255. The end of a list is denoted by a 0 length final chunk. This has the advantage that we only have to force a limited number of elements (to find the length) before serialising. If you want it really lazy then it would have to flush after each element to create a new lazy bytestring chunk. Note that flushing this often looses many of the performance advantages of the Data.Binary stuff. 1) The fact that serialisation is fully strict for 32760 bytes but not for 32761 makes the direct application of strictCheck intractable. Do you have any ideas how to circumvent that? Test using a much smaller chunk size. I'd test sizes from 1 to something like one more than the machine word size. 2) Also, any suggestions for other datatypes to provide default instances for? Tree type structures immediately raise the question of which traversal should be the default. I'm learning towards providing none since the goal of constant space usage actually depends on the serialisation order matching how the deserialised tree will be traversed. Lazy Arrays? 3) I don't think it is applicable in anyway whatsoever to strict types like Int, Data.Set, and Data.Sequence? Counter-arguments? Well, atomic types like Int, I don't think it makes sense, but Sets and Sequence are lazy, aren't they? Sequences are like spine strict lists. Sets are strict in as much as the element type's (==) function is strict. 4) Perhaps the tight correspondence between serialisation and traversal necessary for constant space usage does indeed mean that the instance for the lazy list is the only appropriate one to provide. Perhaps the Chunks data type and a function splitN :: Int - [a] - Chunks [a] would also be helpful. Yes, it is probably the only lazy instance anyone cares about, anyway. Yes. So I think we should be clear about what we want and see if we can't just fix the default. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: demanding lazy instances of Data.Binary
On Mon, 2007-11-19 at 20:22 -0600, Nicolas Frisby wrote: On Nov 19, 2007 4:16 PM, Duncan Coutts [EMAIL PROTECTED] wrote: On Mon, 2007-11-19 at 13:39 -0800, Don Stewart wrote: nicolas.frisby: *snip* 1) The fact that serialisation is fully strict for 32760 bytes but not for 32761 makes the direct application of strictCheck intractable. Do you have any ideas how to circumvent that? Test using a much smaller chunk size. I'd test sizes from 1 to something like one more than the machine word size. Let me clarify circumvent that. strictCheck uses a bounded search starting at 1 and proceeds to some limit. The Binary instance used in the example was the fully lazy one for lists: a get/putWord8 for each constructor. Even so, it was effectively spine-strict up to 32k bytes (which was 32k elements b/c of the use of unit) because (I think that) the first chunk of the lazy bytestring wasn't being generated by encode until it was full. If you asked strictCheck to go from 1 to 32k, I don't think it would finish. So by circumvent, I mean: How can we apply the essential ideas of strictCheck when our chunks are so big? We don't. We test it with a variety of small chunk sizes. That is the sensible thing to do. Obviously, the iterative search cannot just proceed by one element at a time; but then we lose the obvious meaning of add one more _|_. I don't see an obvious candidate for how to alter the _|_-ridden test vector generation. Moreover, it's proposed output is wrong when considered from the Big Chunks perspective--we don't necessarily want Chitil's least strictness. Indeed. As I've said, Data.Binary is lazy but in a chunky way where within each chunk it is strict. Sequences are like spine strict lists. Sets are strict in as much as the element type's (==) function is strict. Let me refine how I posed that question. A predicate: if you enter Package.fromList [1..] at the ghci prompt and you get no intermediate results, then that was a strict type. Right, because (==) for Int is strict, and Set.fromList uses (==) on each element. Sorry, I was just being pedantic by saying that it depends on the strictness of (==). I'm assuming that if the Show instance doesn't produce intermediate results, then the serialisation technique can't handle intermediate results (i.e. chunking) either--at least not in a general enough way to include it in a library. So if you did this test with my proposed list instance (and you somehow slowed your computer right down so you could see what was going on) you'd see it wait a sec, then print out 32k of serialised list elements, then wait again and emit another chunk. So lazy, but in strict chunks. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RFC: demanding lazy instances of Data.Binary
On Mon, 2007-11-19 at 20:06 -0600, Nicolas Frisby wrote: In light of this discussion, I think the fully spine-strict list instance does more good than bad argument is starting to sound like a premature optimization. Consequently, using a newtype to treat the necessarily lazy instances as special cases is an inappropriate bandaid. I agree. My current opinion: If Data.Binary makes both a fully strict list instance (not []) and a fully lazy list instance (this would be the default for []) available, then that will also make available all of the other intermediate strictness. I'll elaborate that a bit. If the user defines a function appSpecificSplit :: MyDataType - [StrictList a], then the user can control the compactness and laziness of the serialisation by tuning that splitting function. Niel's 255 schema fits as one particular case, the split255 :: [a] - [StrictList a] function. I would hesitate to hard code a number of elements, since it certainly depends on the application and only exposing it as a parameter maximizes the reusability of the code. Fully lazy is the wrong default here I think. But fully strict is also not right. What would fit best with the style of the rest of the Data.Binary library is to be lazy in a lumpy way. This can give excellent performance where as being fully lazy cannot (because the chunk size becomes far too small which increases the overhead). Has anyone actually said they want the list serialisation to be fully lazy? Is there a need for anything more than just not being fully strict? If there is, I don't see it. If it really is needed it can be added just by flushing after serialising each element. Reaching for the sky idea: Does the Put monad offer enough information for an instance to be able to recognize when it has filled a lazy bytestring's first chunk? It could cater its strictness ( i.e. vary how much of the spine is forced before any output is generated) in order to best line up with the chunks of lazy bytestring it is producing. This might be trying to fit too much into the interface. And it might even make Put an actual monad ;) That is something I've considered. Serialise just as much of the list as is necessary to fill the remainder of a chunk. Actually we'd always fill just slightly more than a chunk because we don't know how big each list element will be, we only know when we've gone over. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Translations and Haskell
On Mon, 2007-11-19 at 23:18 -0200, Felipe Lessa wrote: Hello, I'd like to start a project using Gtk2Hs and one thing is concerning me: what's the current approach on writing portable and translatable GUI programs in Haskell? For the simple case of translating strings in a .glade UI, glade provides a method for that. For translating strings generated by your own code you need something else, like Jeremy's suggestion. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
On Mon, 2007-11-19 at 21:49 -0800, Bryan O'Sullivan wrote: Neil Mitchell wrote: - The packages seem to be of quite variable quality. Some are excellent, some are rather poor (or just not maintained any more). The problem is that only one person gets to comment on the quality of a library, the author, who is about the least objective person. Not necessarily. CPAN has a nice voting system for packages, which is quite widely used. Another useful proxy for quality that CPAN is missing is download statistics. The maintainers handwave about this being due to the wide geographic distribution of mirrors, but I think that any download statistics would be better than none. I'd like to see hackage maintain download stats and have cabal-install report build success and failures (with build logs) along with basic config info like versions of deps, platform, compiler etc. This could make a great distributed testing system. Clearly, we can do both of these things with Hackage, and I think they'd be very useful (particularly the voting). Another small but useful thing that Hackage is missing is a notion of how fresh a package is. You have to hand-construct an URL to get a directory listing from Apache to find out how old a particular release a tarball is. Yes, I would like to see activity info for each package. What I'd really like to see is each package linking to it's darcs repo and generating an activity graph using dons's darcs-graph program. Though I'd also like to annotate the graph with marks for each release. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] expanded standard lib
On Tue, 2007-11-20 at 13:45 +0300, Bulat Ziganshin wrote: Hello Brandon, Tuesday, November 20, 2007, 1:15:34 AM, you wrote: The ability to vote on packages might be interesting here. If there's 4 HTML libraries and one of them gets lots of votes, it's probably the one to look at first. it can be made easy and automatic by just publishing number of downloads on hackage what hackage developers will say? Yes please! Please contribute the feature. Grab the hackage code from: http://darcs.haskell.org/hackage-scripts/ Send patches to the cabal-devel mailing list. Everyone is most welcome to subscribe too. Another thing I'd like to see coming out of this discussion is some feature requests filed in the hackage trac with a summary of some of our conclusions: http://hackage.haskell.org/trac/hackage/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
On Mon, 2007-11-19 at 10:25 -0800, brad clawsie wrote: i would categorize myself as a purely practical programmer. i enjoy using haskell for various practical tasks and it has served me reliably. one issue i have with the library support for practical problem domains is the half-finished state of many fundamental codebases such as networking and database support. So far I am pretty happy with the progress we've been making with hackage. It has massively increased the number of packages that are easily available. Most of our problems with it are down to it being successful so we now need more infrastructure to do searching and help users gauge stability, whether packages work in various circumstances etc. I think these mostly have technical solutions. That said, I think there is a place for a Haskell development platform. This should not be confused with GHC, though GHC obviously takes central place in our standard tool chain. Managing GHC releases has become increasingly difficult so we should continue the trend to reduce the size of GHC releases and not try to synchronise them with the release of every other part of our tool chain. I would like to compare this to the GNOME development platform. It has Gtk+ at it's hart but GNOME releases are not synchronised with Gtk+ releases. The GNOME development platform consists of a collection of standard packages. The collection is released on a time-based schedule, not a feature-based one. It puts a QA stamp on specific versions of its constituent packages that are known to work together. It has a procedure for getting packages included which include standards of API design and documentation. There is an infrastructure for maintaining, testing and releasing this platform. This is a model I think we should consider seriously. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] recursive deriving
On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote: When you want automated deriving of show/read etc., you need all the components of your type also to be instances of show/read but you won't want to *require* them to be automatically generated verions. Standalone deriving does the wrong thing here. Standalone deriving should not cause an overlapping instance error if someone derives an instance manually. Instead, the manually derived instance should be treated as more specific and win out. The other part of this problem is that you can't do automatic recursive deriving and this results in a ridiculous amount of boilerplate. I know some people have a theory that they want to avoid accidentally creating instances for things that shouldn't have them, but the solution to that is probably to add some declaration for types that prohibits automatic deriving for those types. The 99% case is that automatic deriving is ok. Proposed syntax: derive instance Show T recursively data T = T no-deriving (Ord,Eq) I would expect that if the data constructor for T is not exported then standalone deriving should not work. However this appears not to be the case which breaks module abstraction. Foo.hs: module Foo ( T, t ) where data T = T t = T Bar.hs: import Foo deriving instance Eq T $ ghci Bar.hs -XStandaloneDeriving [1 of 2] Compiling Bar ( Bar.hs, interpreted ) [2 of 2] Compiling Main ( Baz.hs, interpreted ) Ok, modules loaded: Bar, Main. *Main t == t True You could write that Eq instance by hand since they do not have access to the T constructor, then StandaloneDeriving should not be able to so either. I think it's a design flaw in standalone deriving. Does anyone else agree? Should we file a bug report? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gtk2hs problem
On Tue, 2007-11-20 at 15:18 -0800, Gregory Propf wrote: I'm using the Gtk.timeoutAddFull function to do the animation. Are you using the threaded rts? Are you linking the program with -threaded? Are you doing the drawing directly in the timeout function or just invalidating the window/widget and letting it get redrawn? See for example the cairo clock demo which animates the hands of the clock every second: timeoutAdd (widgetQueueDraw window return True) 1000 In general it is much better to only ever draw to a window or widget during that widget's expose event. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fun with Cabal on Windows! [Stream fusion for Hackage]
On Tue, 2007-11-20 at 10:35 -0500, Olivier Boudry wrote: On 11/19/07, Andrew Coppin [EMAIL PROTECTED] wrote: Well, I just tried to install this, and as per usual, Cabal has having none of it. C:\fusion\ runhaskell Setup configure Configuring stream-fusion-0.1.1... Setup: ld is required but it could not be found. Hi Andrew, I had the same problem with ghc-6.8.1 and solved it by adding C:\ghc \ghc-6.8.1\gcc-lib to my PATH variable in environment variables. A copy of ld.exe is in this directory. In ghc-6.6.1, ld.exe was in the same place and it was working out of the box for me. I don't understand why it is not found any more with ghc-6.8.1. It turned out that it was a bug that was introduced in Cabal shortly before the release that went with ghc-6.8.1. We added an extra test to check if ld supports the -x flag. This change inadvertently broke the code that finds ld on windows. I can tell you more of the gory details if you care :-). It's fixed now and will be in the release that goes with ghc 6.8.2. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] expanded standard lib
On Wed, 2007-11-21 at 10:59 +, Simon Peyton-Jones wrote: Some random thoughts triggered by this thread 1. I've been bowled over by the creativity unleashed by having a central site (Hackage), with a consistent installation story (Cabal), where you can upload packages with no central intervention. A single issue of the Haskell Weekly (sic) News with 60 library announcements represents a qualitative shift from the Haskell situation 2 years ago. That is fantastic. Yes, it's been amazingly successful. Partly it's new libs, partly it's things that have been sitting around on various home pages or peoples local disks. Both are great of course. 2. We absolutely must not conflate GHC releases with QA-stamped library bundles. The latter would be great, but the two must be separate. (For reasons given by others in this thread.) Yes or GHC HQ would go insane. 3. I think it'd be great if there were bundles of libraries that work together, are available on multiple platforms, and have had some QA testing. (Sounds as if releasing such bundles on a regular basis is the Gnome model.) Its not clear to me that any one is actually volunteering to lead such a thing though. At the moment I think it'd be too much effort so we're not likely to get volunteers. However if we work on more hackage infrastructure I think it should be possible to reduce the effort required to the point where it'd be feasible. There is a separate discussion to be had about what kind of QA standards we might want. 4. Meanwhile, we could get a lot more mileage from de-centralised approaches. Ideas I saw in this thread that sound attractive to me are to make Hackage display, for each package: - date of last update - download statistics - some kind of voting scores, so users can vote for good packages (and add text comments, please) - auto-build system, so that there's a per-platform indication of whether the package builds; ideally, packages should come with a test suite, which could be run too (Is this list complete?) Those are the major things I think. We should file hackage feature requests for each of them. I'd also like to add links to darcs repos and possibly to bug trackers. These are simple extra fields in a .cabal file that hackage can create links for on the package page. There is also the stuff about letting hackage document api changes by comparing the apis of releases. This also relates to the package version policy. It may be implemented via haddock. These things (or some subset) look more feasible to me, because they can each be done with a finite effort, and then computers and library users will do the rest. Yes. I especially like the download stats and stats on development and release activity, that should be easy. For testing I'd like to see cabal-install report build success/failure and have summaries of that information presented on each packages hackage page. That's a slightly harder project. It should allow us to gather an enormous amount of information however so it's probably worth it. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
On Wed, 2007-11-21 at 14:57 +0100, Ketil Malde wrote: No Google page rank-alike? I did a quick popularity count by wget'ting the whole thing, and looking for hrefs under cgi-bin/packages/archive¹. Not exact, as it counts links to the previous version, but a rough approximation. Page rank would be better, as it would ascribe higher importance to a library that is required by a more popular library. Anyway, quick and inaccurate results: That's quite fascinating. Thanks. You've convinced me we should add something like that :-). Please file a feature request: http://hackage.haskell.org/trac/hackage/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] c2hs on Windows?
On Sun, 2007-11-11 at 21:36 +, Alex Young wrote: Hi all, Does anyone know if c2hs should be working on Windows? I'm trying to build it under ghc 6.8.0, but this happens: I just uploaded c2hs-0.15.1 which builds with all recent versions of ghc 6.4-6.8. I also tested that it builds on Windows. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/c2hs-0.15.1 Sorry about the wait. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell code in Wordpress
On Fri, 2007-11-23 at 20:22 +, Paulo J. Matos wrote: Hi all, I'm curious about the best way to typeset haskell code in a wordpress blog. Using blockquote removes all indentation. :-( For the Gtk2Hs website I used a program (partly derived from hscolour) to highlight and adds links to documentation. It generates xhtml which one can just paste in. See the hello world example on this page: http://haskell.org/gtk2hs/documentation/ The program is here: http://darcs.haskell.org/gtk2hs/docs/tools/AddLinks.hs Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] nhc vs ghc
On Fri, 2007-11-23 at 23:33 -0800, brad clawsie wrote: for example, can i build a cabal package with nhc98? As of yesterday the answer is yes! (probably) :-) I'm glad you asked about building and not installing since the answer to that question would be no. Support in Cabal for building with nhc98 and hmake was added yesterday. I expect support for installing will be added soon. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal-install
On Tue, 2007-11-27 at 18:02 -0800, Don Stewart wrote: ben.franksen: Just thought I install the latest version (0.4.0) from hackage and test it. Build and install went fine, but then it gets strange: cabal: dist/Conftest.c: openFile: does not exist (No such file or directory) This one is due to having an out of date cabal. Upgrade to darcs cabal, then rebuild cabal-install, and things should go fine. Yes, this was rather unfortunate. A fix for something else that we put into Cabal at the last minute ended up breaking cabal-install. As Don says, it's fixed in the darcs version of Cabal (HEAD and 1.2 branch) which will also be released with ghc-6.8.2 (or possibly earlier if that looks like it's going to take a while). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings and utf-8
On Tue, 2007-11-27 at 18:38 +, Paul Johnson wrote: Brandon S. Allbery KF8NH wrote: However, the IO system truncates [characters] to 8 bits. Should this be considered a bug? A design problem. I presume that its because stdio.h was defined in the days of ASCII-only strings, and the functions in System.IO are defined in terms of stdio.h. But does this need to be the case in the future? When it's phrased as truncates to 8 bits it sounds so simple, surely all we need to do is not truncate to 8 bits right? The problem is, what encoding should it pick? UTF8, 16, 32, EBDIC? How would people specify that they really want to use a binary file. Whatever we change it'll break programs that use the existing meanings. One sensible suggestion many people have made is that H98 file IO should use the locale encoding and do Unicode/String - locale conversion. So that'd all be text files. Then openBinaryFile would be used for binary files. Of course then we'd need control over setting the encoding and what to do on encountering encoding errors. IMHO, someone should make a full proposal by implementing an alternative System.IO library that deals with all these encoding issues and implements H98 IO in terms of that. It doesn't have to be fast initially, it just has to get the API right and not design the API so as to exclude the possibility of a fast implementation later. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: cabal-install
On Wed, 2007-11-28 at 21:00 +0100, Thomas Schilling wrote: On Wed, 2007-11-28 at 20:46 +0100, Ben Franksen wrote: [EMAIL PROTECTED]: .../software/haskell cd cabal [EMAIL PROTECTED]: .../haskell/cabal runhaskell Setup.lhs configure Distribution/Simple/NHC.hs:77:1: lexical error at character 'i' Ups. Cheers Ben (feels like a real beta-tester now ;-) Well, Cabal cannot automatically compile itself with itself. No actually it can, that was just a bug (which I've just fixed). Ben is indeed being a beta tester by using Cabal HEAD. I'd recommend the 1.2 branch: http://darcs.haskell.org/cabal-branches/cabal-1.2/ Or just darcs pull and try again. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Strings and utf-8
On Wed, 2007-11-28 at 17:38 -0200, Maurício wrote: (...) When it's phrased as truncates to 8 bits it sounds so simple, surely all we need to do is not truncate to 8 bits right? The problem is, what encoding should it pick? UTF8, 16, 32, EBDIC? (...) One sensible suggestion many people have made is that H98 file IO should use the locale encoding and do Unicode/String - locale conversion. (...) I'm really afraid of solutions where the behavior of your program changes with an environment variable that not everybody has configured properly, or even know to exist. Be afraid of all your standard Unix utils in that case. They are all locale dependent, not just for encoding but also for sorting order and the language of messages. Using the locale is standard Unix behaviour (and these days the locale usually specifies UTF8 encoding). On OSX the default should be UTF8. On Windows it's a bit less clear, supposedly text files should use UTF16 but nobody actually does that as far as I can see. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Strings and utf-8
On Thu, 2007-11-29 at 13:05 +, Jules Bean wrote: Language of messages is quite different from language of a file you read. Suppose I am English, and I have a russian friend, Vlad. My default locale is, say, latin-1, and his is something cyrillic. I might well open files including my own files, and his files. The locale of the current user is simple no guide to the correct encoding to read a file in, and not a particularly reliable guide to writing a file out. Locale makes perfect sense for messages (you are communicating with the user, his locale tells you what language he speaks). It makes much less sense for file IO. Yes, it's a fundamental limitation of the unix locale system and multi-user systems. However it's no less wrong than just picking UTF8 all the time. Obviously one needs a text file api that allows one to specify the encoding for the cases where you happen to know it, but for the H98 file api where there is no way of specifying an encoding, what's better than using the unix default method? (at least on unix) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell packaging on Windows cygwin ( POSIX on Windows ; ^)
On Thu, 2007-11-29 at 00:21 -0600, Galchin Vasili wrote: The message I actually receive is: runhaskell Setup.lhs build . ./Haq.hs:6:7: Could not find module `System.Environment': it is a member of a package base, which is hidden BTW I haven't actually checked source in via darcs due to cygwin $PATH problems ... Have you tried adding: build-depends: base you your .cabal file? Cabal enforces that your code may only use packages that you have explicitly stated your code depends on. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal under windows (was Re: Haskell-Cafe Digest, Vol 51, Issue 180)
On Thu, 2007-11-29 at 13:51 +1100, Tim Docker wrote: Well I'd say none of the packages I've tried, build out of the box... I'm not a windows developer, but Is it actually reasonable to expect any cabal packages that depend on external c libraries and headers to build out of the box on windows? How can cabal find out where those files are, without requiring a config file to be edited? It's usually worse than that. The most likely situation is that the C library and header files are not even installed. This is a big problem for all packages that wrap C libs. Sometimes the C code is sufficiently simple that one can just bundle it. My zlib and bzlib packages on hackage do that and that's the only reason they work on Windows. This is not a realistic solution for most other binding packages. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and DB : giving up
On Wed, 2007-11-28 at 19:11 +0100, manu wrote: Hello I've spent a few days trying to install all the packages required to use HaskellDB with either MySQL or SQlite3 (the only 2 DB the host I was thinking about is supporting) Well, I am giving up ! I seriously regret replacing ghc-6.6 with ghc-6.8, I didn't expect that building packages would be so ... unsucessfull and time-wasting. Yes, you were unlucky in that you jumped in just after ghc 6.8.1 was released and before 90% of the packages on hackage had been updated to work with 6.8 yet. In the mean time you would indeed be better off with 6.6. Our hackage infrastructure is still fairly immature and lacks any mechanism for indicating which packages work on which platforms. I agree it's frustrating. Then additionally there is the complication that many packages that use C libs (like DB client libs) just don't build out of the box on windows because the development files are not installed. Probably the best eventual solution for Windows is to build infrastructure to make binary packages for Windows. People are working on that. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: cabal-install
On Thu, 2007-11-29 at 23:56 +0100, Ben Franksen wrote: Duncan Coutts wrote: On Wed, 2007-11-28 at 21:00 +0100, Thomas Schilling wrote: On Wed, 2007-11-28 at 20:46 +0100, Ben Franksen wrote: [EMAIL PROTECTED]: .../software/haskell cd cabal [EMAIL PROTECTED]: .../haskell/cabal runhaskell Setup.lhs configure Distribution/Simple/NHC.hs:77:1: lexical error at character 'i' Ups. Cheers Ben (feels like a real beta-tester now ;-) Well, Cabal cannot automatically compile itself with itself. No actually it can, that was just a bug (which I've just fixed). Ah, I wondered. If even 'the monster' (ghc) can build itself from earlier versions it should be possible for cabal to pull the same trick. Ben is indeed being a beta tester by using Cabal HEAD. I'd recommend the 1.2 branch: I was using HEAD as per Don's suggestion for how to build cabal-install. Now, re-reading this thread I see that you already mentioned that upgrading on the 2.1 branch would have been enough. Apropos beta-testing, cabal-1.3 seems to have introduced an incompatible API change; for instance, it can't build MissingH any longer. Actually it was 1.2.x that made this change. One install of cabal-install later: same error with MissingH. So the package was broken to begin with an it wasn't related to the cabal upgrade! G. Yup. It's not been updated to work with ghc 6.8 and related libs. Not that it matters to me here at home (there is a debian package I can use), but at work we are still using debian /old-stable/ which is just a bit too outdated and anyway I don't have root access so I have to install everything from source. Unpacking MissingH and looking at the Setup.hs I see that I can simply replace it by a generic version, add unix dependency to the cabal file, and all works well. So much for never again runhaskell Setup blabla ;-) I expect it can use configurations to add the unix package dependency conditionally and not need a custom Setup.hs file at all. (I should add that for many packages cabal-install works perfectly well.) Thanks again for your help! Cheers Ben PS: a 'cabal remove' would also be nice to have. http://hackage.haskell.org/trac/hackage/ticket/106 Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] regexen no go with 6.8.1?
On Tue, 2007-12-04 at 02:02 -0800, Jason Dusek wrote: Is it just me, or are all the regex implementations broken with new change in lib layout for 6.8.1? Are fixes available in darcs? Use these ones: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-base-0.72.0.1 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-posix-0.72.0.2 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/regex-compat-0.71.0.1 Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] regex package for yhc?
On Thu, 2007-12-06 at 15:21 -0500, Thomas Hartman wrote: Is there a cabal equivalent for yhc? One day we hope Cabal will support yhc. It currently supports ghc, hugs and has partial support for nhc98 and jhc. The main thing holding it back is dependency chasing in Cabal or the lack thereof. Cabal relies on the build-in dep chasing in hugs, ghc --make. It uses hmake for nhc98. We hope to replace this hodge-podge with proper dependency chasing support in Cabal, that's also extend to pre-processors etc. If anyone is interested in helping with this project, subscribe to cabal-devel and get involved. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Literate HTML
On Fri, 2007-12-07 at 19:14 +, Neil Mitchell wrote: Hi Brandon, You could replace the unlit executable in the GHC library directory with one which knows how to extract Haskell code from HTML. I want a solution so that I can write the tagsoup manual in an way that can actually be run - I'd rather not force any additional dependence on a custom unlit command. However, adding HTML-style literate code to a future Haskell standard might not be a bad idea. In the mean time you could prototype it as a pre-processor in Cabal if you write the unlit code. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with Gtk2hs
On Sat, 2007-12-08 at 13:08 -0800, Stefan O'Rear wrote: On Sat, Dec 08, 2007 at 08:33:36PM +, Andrew Coppin wrote: I just spent the evening writing a library that's a thin layer over Gtk2hs. It took an age to get it to compile, but eventually it worked. Yay! When I ran it, I got this: Test2: gtk/Graphics/UI/Gtk/Gdk/PixbufData.hs.pp:58:0: No instance nor default method for class operation Data.Array.Base.getNumElements Er... wow. OK, at this point, I am completely stumped. Any hints? That's pretty obviously a bug - Graphics.UI.Gtk.Gdk.PixbufData doesn't fully implement the (M)Array class. The MArray class changed in ghc-6.8 and we didn't notice until the gtk2hs release was already out. So there are a couple workarounds, either grab the darcs version of the 0.9.12 branch which contains the fix: http://darcs.haskell.org/gtk2hs-branches/gtk2hs-0.9.12/ Or use the released version with ghc-6.6.x rather than 6.8.x, since 6.6 has the previous different MArray interface. Or use the unsafe indexing operators which bypass the bounds check which calls getNumElements. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with Gtk2hs
On Mon, 2007-12-10 at 10:40 +, Andrew Coppin wrote: What do I need to compile the darcs version? Just GHC? Or do I need the GTK+ header files? (Remember, I'm on Windows here.) Ah, that's a bit harder. It's not for the feint of heart. I've not updated the instructions in a while. The old ones are here: http://haskell.org/gtk2hs/archives/2005/06/24/building-from-source-on-windows/ but we now use the official Gtk+ windows binaries and headers rather than the ones from http://gladewin32.sourceforge.net/ Our new header bundles are here: http://haskell.org/gtk2hs/win32/ and scripts are here: http://darcs.haskell.org/gtk2hs/tools/win32/ You'd want the win32-build-* ones. You also need mingw of course. I would not recommend starting from darcs but from a tarball and then copying over the two changed files from darcs. The reason for that is that trying to get autoconf and automake working on windows is more trouble than it's worth (I've never done it) where as the tarball contains pre-generated autoconf/automake stuff. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] class default method proposal
I'd just like to float an idea that's related to the Class Alias
proposal[1] but is perhaps somewhat simpler.
We all know that Functor should have been a superclass of Monad, and
indeed we now know that Applicative should be too. Making such a change
would break lots of things however so the change does not happen.
However in this case the Monad operations can be used to implement the
Functor and Applicative class methods. So it would be nice if we could
get them for free if the author did not choose to write the Functor and
Applicative instances.
So my suggestion is that we let classes declare default implementations
of methods from super-classes.
class Functor m = Monad m where
{- the ordinary bits -}
fmap f m= m = return . f
So if there already is a Functor instance for m then the default
implementation of fmap is not used.
Does this proposal have any unintended consequences? I'm not sure.
Please discuss :-)
Duncan
[1] http://repetae.net/recent/out/classalias.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote: This is almost exactly the http://haskell.org/haskellwiki/Class_system_extension_proposal; that page has some discussion of implementation issues. Oh yes, so it is. Did this proposal get discussed on any mailing list? I'd like to see what people thought. Was there any conclusion about feasibility? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] class default method proposal
On Tue, 2007-12-11 at 16:38 +, Ross Paterson wrote: On Tue, Dec 11, 2007 at 04:26:52PM +, Simon Marlow wrote: Duncan Coutts wrote: On Tue, 2007-12-11 at 07:07 -0800, Stefan O'Rear wrote: This is almost exactly the http://haskell.org/haskellwiki/Class_system_extension_proposal; that page has some discussion of implementation issues. Oh yes, so it is. Did this proposal get discussed on any mailing list? I'd like to see what people thought. Was there any conclusion about feasibility? Ross proposed this on the libraries list in 2005: http://www.haskell.org//pipermail/libraries/2005-March/003494.html and again in 2003: http://www.haskell.org/pipermail/haskell-cafe/2003-July/004654.html Ross, you need to shout louder! :-) If it really would work ok we should get it fully specified and implemented so we can fix the most obvious class hierarchy problems in a nice backwards compatible way. Things are only supposed to be candidates for Haskell' if they're already implemented. So how about the objection that two sub classes could try and define conflicting defaults for a superclass method? David Menendez had the example of Monad and CoMonad defining Functor's fmap. Can that easily be rejected? I suppose it gives rise to duplicate instance declarations so it'd be an error in the same way that defining clashing instances in two different modules and importing both into a third module. Another error case would be: module A where data Foo module B where instance Functor Foo module C where instance Monad Foo module D import Bar import Baz Now we get slashing instances for Functor, since both Bar and Baz export Functor instances for Foo. Since the instance for Functor Foo was not visible in module C, so we get the default instance defined in C. So the one slightly surprising thing about this suggestion is that we get an instance defined or not depending on whether there is already an instance in scope. In the Functor, Applicative, Monad case I don't see that causing a problem in practise but is it worse more generally? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] c2hs and cabal
On Tue, 2007-12-11 at 19:14 +0100, Stefan Kersten wrote: On 02.12.2007, at 22:34, Eric Sessoms wrote: Just add Build-Tools: c2hs And cabal will take it from there. thanks eric, that's really pleasingly simple (it appears that the Build-Tools: line isn't even needed). Though note that in future Cabal is going to get stricter about stating dependencies on build tools, just like it is very strict about dependencies on libraries. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: dataenc-0.10.1
On Wed, 2007-12-12 at 13:30 +, Magnus Therning wrote: The visible change is the addition of a function, decode', that allows lazier decoding by shifting some responisility to the user. That's interesting. It's in the same spirit as the lazy variant provided in the iconv lib. It'll be interesting to see if this is the best general interface for allowing people to lazily convert and handle conversion errors. The slight difference is that the iconv lib works over bytestring chunks rather than individual Word8 and provides a bit more detail about errors. It's otherwise pretty similar. convertLazily :: EncodingName -- ^ Name of input string encoding - EncodingName -- ^ Name of output string encoding - ByteString -- ^ Input text - [Span] -- ^ Output text spans When nothing goes wrong we expect just a bunch of Spans. If there are conversion errors we get other span types. data Span = Span ByteString | ConversionError ConversionError data ConversionError = UnsuportedConversion EncodingName EncodingName | InvalidChar Offset | IncompleteChar Offset | UnexpectedError Errno http://hackage.haskell.org/packages/archive/iconv/0.4/doc/html/Codec-Text-IConv.html#v%3AconvertLazily Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Execution of external command
On Thu, 2007-12-13 at 15:48 +0300, Bulat Ziganshin wrote: Hello haskell-cafe, please help me with selection of proper function to use i need to run external command with parameter and get its stdout, smth like this: output - system cmd param the code should be compatible with unix and windows, and it should be possible to execute scripts (so afaiu it should execute command via cmd/sh). i use ghc 6.6.1 and it will be great if this function will not require any non-bundled libs and be compatible with later ghc versions There is rawSystemStdout in Cabal which you might like to copy. It is portable to windows and several Haskell compilers but does use cpp to achieve that. It's also rather inefficient as it has to create a temporary file. It seems it is not possible to use pipes to get the stdout and have the resulting code be portable between Haskell implementations (it's a favourite peeve of mine). As the name suggests, rawSystemStdout uses rawSystem so does not necessarily do what you want with cmd/sh but you could easily adapt it to use system rather than rawSystem. http://darcs.haskell.org/cabal/Distribution/Simple/Utils.hs http://darcs.haskell.org/cabal/Distribution/Compat/TempFile.hs Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Execution of external command
On Thu, 2007-12-13 at 16:27 +0300, Bulat Ziganshin wrote: Hello Duncan, Thursday, December 13, 2007, 4:10:26 PM, you wrote: i need to run external command with parameter and get its stdout, smth temporary file. It seems it is not possible to use pipes to get the stdout and have the resulting code be portable between Haskell implementations (it's a favourite peeve of mine). i don't need to interact with program, just get its whole output (one line) after it was finished. btw, afair, there was problems in windows with redirection of cmd.exe output (in particular when running executables from command files) separate windows and unix versions are ok for me, i just need them both. and i need only ghc support taking this all into account, where i should look? Use just the GHC bit from the code I pointed at: bracket (liftM2 (,) (openTempFile tmpDir cmdstdout) (openFile devNull WriteMode)) -- We need to close tmpHandle or the file removal fails on Windows (\((tmpName, tmpHandle), nullHandle) - do hClose tmpHandle removeFile tmpName hClose nullHandle) $ \((tmpName, tmpHandle), nullHandle) - do cmdHandle - runProcess path args Nothing Nothing Nothing (Just tmpHandle) (Just nullHandle) exitCode - waitForProcess cmdHandle output - readFile tmpName evaluate (length output) return (output, exitCode) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Execution of external command
On Thu, 2007-12-13 at 15:06 +0200, Yitzchak Gale wrote: Hi Bulat, You wrote: please help me with selection of proper function to use i need to run external command with parameter and get its stdout, smth like this: output - system cmd param the code should be compatible with unix and windows, and it should be possible to execute scripts (so afaiu it should execute command via cmd/sh). i use ghc 6.6.1 and it will be great if this function will not require any non-bundled libs and be compatible with later ghc versions OK, I'll bite. What's wrong with runInteractiveCommand? It requires threads to use correctly and it is only available in GHC, not in hugs, nhc98 etc. It requires threads because you have to pull from both the stdout and stderr to prevent blocking. You could do it with non-blocking reads but not without busy-waiting. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Execution of external command
On Thu, 2007-12-13 at 17:08 +0300, Bulat Ziganshin wrote: Hello Duncan, Thursday, December 13, 2007, 4:51:20 PM, you wrote: OK, I'll bite. What's wrong with runInteractiveCommand? It requires threads because you have to pull from both the stdout and stderr to prevent blocking. You could do it with non-blocking reads but not without busy-waiting. may be this will be ok (with -threaded)? No need for -threaded. (_, stdout, stderr, _) - runInteractiveCommand script params forkIO (hGetContents stderr = evaluate.length) result - hGetLine stdout hGetContents stdout = evaluate.length Yep, that'll work. awkward, but still shorter than code from Cabal The Cabal code has to work with ghc-6.2 - 6.8, hugs, nhc98 and jhc. It cannot use threads. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Execution of external command
On Thu, 2007-12-13 at 19:38 +0200, Yitzchak Gale wrote: Simon Marlow wrote: It could deadlock if the script produces enough stderr to fill up its pipe buffer If we need to worry about that, then what about this: (_,h,e,_) - runInteractiveCommand script params forkIO (hGetContents e = evaluate . length) output - hGetContents h It requires -threaded in the case of a huge amount It does not require -threaded. GHC's single threaded rts has always been able to cope with multiple haskell threads that want to do file/network IO. of output to both stdout and stderr; maybe that isn't good for Bulat. If that is a problem, you can read a chunk at a time and call yield - but that is getting messier. Calling yield ends up busy waiting if there is no output available from either stdout or stderr. It also requires threads so it's not a portable solution. Something simple would be to allow attaching a pipe to just the stdout and redirecting stderr elsewhere, or connecting both stdout and stderr to the same output pipe. runProcess allows substituting any of stdin/stdout/stderr for other Handles and runInteractiveProcess substitutes them all for pipes. What we need is something in between that allows substituting some for given Handles and connecting others to pipes. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problems with split-objs
On Mon, 2007-11-26 at 22:48 +, Magnus Therning wrote: I've followed the instructions at [1] to create a .deb of vty[2]. It seems the helper scripts for Debian passes `--enable-split-obj' when running `./Setup.lhs configure'. This results in numerous multiple definitions of stuff. I have a few questions regarding this... I find this is usually due to a bad combination of ghc and gcc. eg ghc-6.6.x and gcc-4.2 have this problem on a couple arches. What versions of stuff are you using? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [RFC] benchmarks of bytestrings, teaser
On Sat, 2007-12-15 at 09:25 +0100, Peter Lund wrote:
What do you think the relative speeds are of the six small haskell
programs at the end of this email?
Ok, I presume this is a guessing game and we're supposed to just look at
the code without running and timing them.
All they do is read from stdin and count the number of spaces they see.
There are two that use strict bytestrings, two that use lazy
bytestrings, and two that use the standard Haskell strings. Three use a
recursive function with an accumulator parameter and three use a foldl
with a lambda function.
Say the fastest one takes the time 1. How much time will the others
take?
And how about memory? How much memory do you think they require? Let's
say we feed a 150MB(*) file into each of them, how many megabytes do you
think they end up using (as seen from the OS, not in terms of how big
the live heap is)?
I'm going to post full benchmarks + analysis on Wednesday.
Right'o. I'll have a go. Lets see if I can't embarrass myself with being
completely inaccurate.
PS: For extra credit, what do you think is the peak memory use for this
program when given an input file of 150MB?
Ok.
{-# LANGUAGE BangPatterns #-}
import qualified Data.ByteString.Lazy.Char8 as B
import GHC.Int (Int64)
-- note that D.BS.Lazy.Char8.length is ByteString - Int64
-- D.BS.C8.length is ByteString - Int
Yes, because strict bytestring cannot be bigger than the size of virtual
memory and with ghc at least, Int tracks the size of the machine
pointer.
cnt :: B.ByteString - Int64
cnt bs= B.length (B.filter (== ' ') bs)
main = do s - B.getContents
print (cnt s)
Hmm. So that should work in constant memory, a few 64 chunks at once.
I'd expect this to be pretty fast.
==
hs/space-bs-c8-acc-1.hs:
{-# LANGUAGE BangPatterns #-}
import qualified Data.ByteString.Char8 as B
cnt :: Int - B.ByteString - Int
cnt !acc bs = if B.null bs
then acc
else cnt (if B.head bs == ' ' then acc+1 else acc) (B.tail bs)
main = do s - B.getContents
print (cnt 0 s)
This uses strict bytestrings so will use at least 150Mb and that'll make
it a good deal slower. In fact it'll be worse than that since
getContents does not know in advance how big the input will be so it has
to play the doubling and copying game. So it'll end up copying all the
data roughly twice. cnt is strict and tail recursive so that shouldn't
be any problem, though it's probably not as fast as the first length .
filter since head, tail, null all have to do bounds checks.
==
hs/space-bslc8-acc-1.hs:
{-# LANGUAGE BangPatterns #-}
import qualified Data.ByteString.Lazy.Char8 as B
cnt :: Int - B.ByteString - Int
cnt !acc bs = if B.null bs
then acc
else cnt (if B.head bs == ' ' then acc+1 else acc) (B.tail bs)
main = do s - B.getContents
print (cnt 0 s)
For the same reason as above, I'd expect this cnt to be slower than
B.length . B.filter (== ' ')
==
hs/space-x-acc-1.hs:
{-# LANGUAGE BangPatterns #-}
cnt :: Int - String - Int
cnt !acc bs = if null bs
then acc
else cnt (if head bs == ' ' then acc+1 else acc) (tail bs)
main = do s - getContents
print (cnt 0 s)
Lazy, so constant memory use, but much higher constant factors due to
using String.
==
hs/space-bs-c8-foldlx-1.hs:
{-# LANGUAGE BangPatterns #-}
import qualified Data.ByteString.Char8 as B
cnt :: B.ByteString - Int
cnt bs= B.foldl' (\sum c - if c == ' ' then sum+1 else sum) 0 bs
main = do s - B.getContents
print (cnt s)
This is of course still strict so that's going to make the reading slow.
This is a manually fused B.length . B.filter (== ' ') which hopefully is
the same speed as the automatically fused one if the fusion is working
ok. If not, then the B.length . B.filter (== ' ') will be doing a extra
copy, and memory writes are expensive.
==
hs/space-bslc8-foldlx-1.hs:
{-# LANGUAGE BangPatterns #-}
import qualified Data.ByteString.Lazy.Char8 as B
cnt :: B.ByteString - Int
cnt bs= B.foldl' (\sum c - if c == ' ' then sum+1 else sum) 0 bs
main = do s - B.getContents
print (cnt s)
As above but now in constant memory space.
==
hs/space-x-foldl.hs:
{-# LANGUAGE BangPatterns #-}
cnt :: String - Int
cnt bs= foldl (\sum c - if c == ' ' then sum+1 else sum) 0 bs
main = do s - getContents
print (cnt s)
Oh, no! not foldl that's a killer.
Ok, so best way to summarise I think is to organise by data type since I
think that'll dominate.
So I think the lazy bytestring versions will be fastest due to having
the best memory access patterns and doing the least copying. I think the
foldl's will
Re: [Haskell-cafe] JOB OFFER / Haskell for commercial projects?
On Sat, 2007-12-15 at 14:29 +0100, Wolfgang Jeltsch wrote: Am Samstag, 15. Dezember 2007 13:05 schrieb Paul Johnson: […] The GHC licence is basically a BSD with attribution. Compiled programs include the run-time, so you would just have to include the copyright notice somewhere in your documentation. This would also apply to those libraries that are shipped with the compiler. I think, there is some issue with the GMP library which is used for implementing the Integer type and which is licensed under the GPL, AFAIK. It's the LGPL not the GPL. See http://gmplib.org/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: FFI question -- was: [Haskell-cafe] New slogan for haskell.org
On Wed, 2007-12-19 at 19:07 -0800, Don Stewart wrote: There are three approaches, depending on the size of your project. Write your ow FFI decls manually. - Good when you have a small job - and the C types are simple - example: strlen Use hsc2hs: - good for more complex C code. Scales nicely. But a bit tedious. - examples: pcre.h X11.h Use c2hs: - more automated than hsc2hs - less common The latest version is available on hackage :-) - scriptable - examples: gtk2hs I use hsc2hs mostly. The main advantage of c2hs over hsc2hs is that c2hs generates the correct Haskell types of foreign imports by looking at the C types in the header file. This guarantees cross language type safety for function calls. It also eliminates the need to write foreign imports directly which saves a lot of code. hsc2hs provides no help for writing function imports. The main disadvantage of c2hs compared to hsc2hs is that c2hs's support for marshaling structures is less than stellar while hsc2hs is pretty good at that. In gtk2hs we use both. We use c2hs for all function calls and we use hsc2hs to help us write Storable instances for a few structures. Both are supported by Cabal. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] upgrading regex in GHC 6.8.2
On Fri, 2007-12-21 at 13:58 +1030, Michael Mounteney wrote: Hello, I have an application that uses/used Text.Regex and have just updated GHC from 6.6.1 to 6.8.2 and it seems that Text.Regex is gone, so I'm trying to install the replacement from Hackage. First of all, the procedure is quite tedious as one has to install the hierarchy of dependencies manually but apparently there are moves to automate this process. Yes. You can try cabal-install now if you like: http://haskell.org/cabal/code.html though be prepared to report bugs and limitations: http://hackage.haskell.org/trac/hackage That said, I use it all the time now. It's much quicker than manually downloading and configuring everything. The procedure stalled on regex-base-0.92. None of the 0.9x versions have been updated for the base-3 library that comes with ghc-6.8 now. Instead try using: regex-base-0.72.0.1 regex-posix-0.72.0.2 regex-compat-0.71.0.1 These versions work with ghc-6.8 and earlier. These would be the latest versions if it were not for the 0.9x series. We need some way to tell hackage or cabal-install that the latest version is not necessarily the best or recommended version. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: FFI question -- was: [Haskell-cafe] New slogan for haskell.org
On Fri, 2007-12-21 at 10:25 +0100, Gour wrote: On Thu, 20 Dec 2007 03:41:21 + Duncan Coutts [EMAIL PROTECTED] wrote: In gtk2hs we use both. We use c2hs for all function calls and we use hsc2hs to help us write Storable instances for a few structures. It looks that c2hs does more than hsc2hs and misses less than hsc2hs. Why not equip c2hs to do the rest and have one complete tool instead of the two uncomplete ones? (I understand that time-factor could be the reason.) The reason hsc2hs does the structure bits well is because it asks the C compiler about the sizes and offsets of field members. This means it is always accurate. For c2hs to do the same it has to calculate the sizes, offsets and alignments of types itself and it requires a lot of work and testing to make sure this is always 100% accurate. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] easy cabal tasks
People are often unsure about where they can help out with Cabal. One thing we can do to make that easier is to point out smaller simpler tasks that people might like to have a go at. We have a list of tasks that are marked as easy or very easy: http://hackage.haskell.org/trac/hackage/report/13 This list is also linked from the hackage trac web page (Easy tickets) http://hackage.haskell.org/trac/hackage/ For people reporting bugs and working with the hackage/cabal trac, look out for tasks that you think could be done by a new or relatively new contributor and mark the bug's difficulty appropriately. Please also give plenty of detail on what the solution should involve and pointers to other documentation as appropriate. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hackage web page
In message [EMAIL PROTECTED] Neil Mitchell [EMAIL PROTECTED] writes: Hi, The hackage web page confuses me: http://hackage.haskell.org/packages/hackage.html Hackage has now graduated from being a nice idea to being a critial user-focused thingy, which is great. Perhaps the website needs a little bit of thought along those lines. This isn't intended to be a complaint at all - just a new perspective to the people who develop it and probably don't read the web page at all. You're quite right. We'd welcome a rewrite. You or anyone else is most welcome to send us a new version in .html or any other format. If there are no immediate volunteers then someone should file a bug against the HackageDB component in our tracker so we do not forget. http://hackage.haskell.org/trac/hackage Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN / CFP - LLVM bindings for Haskell
In message [EMAIL PROTECTED] Ross Paterson [EMAIL PROTECTED] writes: On Thu, 03 Jan 2008 03:43:49 -0800, Bryan O'Sullivan wrote: (Hackage can't host code that uses GHC 6.8.2's language extension names yet.) It should be able to now. Thanks very much Ross. BTW, I think we should put some HackageDB hacking and admin instructions on the hackage wiki so we don't have to pester you so much for this kind of routine admin stuff. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage web page
On Fri, 2008-01-04 at 17:53 -0500, [EMAIL PROTECTED] wrote: On 2008.01.02 17:20:04 +, Duncan Coutts [EMAIL PROTECTED] scribbled 0.8K characters: You're quite right. We'd welcome a rewrite. You or anyone else is most welcome to send us a new version in .html or any other format. If there are no immediate volunteers then someone should file a bug against the HackageDB component in our tracker so we do not forget. http://hackage.haskell.org/trac/hackage Duncan Is there any Darcs repo for the Hackage HTML, or does it just sort of exist by itself on the servers? Seems not, though perhaps Ross might correct me. It would indeed be an improvement. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: A triple of new packages for talking to the outside world
On Wed, 2008-01-09 at 09:26 +, Dominic Steinitz wrote: Adam Langley agl at imperialviolet.org writes: But if this is useful to you, make any requests. I'll (hopefully) do them, clean it up and push a new release of binary-strict. How difficult would it be to have a getBits functions as well as a getBytes? That would allow me drop the dependency on NewBinary in the ASN.1 package. The difficulty is in deciding what the api should be. Does it give you a real bitstream or only a byte aligned one? If I ask for 3 bits then 15 bytes what does it do? Does it assume I meant 3 bits, then pad to the next byte boundary and get 15 bytes, or does it mean get 15 bytes but at this 3 bit shift offset? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
On Fri, 2008-01-11 at 01:12 +0100, Achim Schneider wrote: Tillmann Rendel [EMAIL PROTECTED] wrote: Achim Schneider wrote: [1..] == [1..] [some discussion about the nontermination of this expression] The essence of laziness is to do the least work necessary to cause the desired effect, which is to see that the set of natural numbers equals the set of natural numbers, which, axiomatically, is always computable in O(1) by equality by identity. This would make sense if Haskell had inbuild equality and (==) where part of the formal semantics of Haskell, wich it isn't. (==) is a library function like every other library function. How could the language or a system implementing the language decide wether this or any other library function returns True without actually running it? The list instance for Eq might eg. know something about the structure of the lists and be smart enough not to get caught in the recursion of x = 1:1:x and y = 1:1:1:y so it could successfully compare x == y to True in six compares. So let's imagine: ones = 1 : ones ones' = repeat 1 where repeat n = n : repeat n So you're suggesting that: ones == ones = True but ones' == ones' = _|_ Well if that were the case then it is distinguishing two equal values and hence breaking referential transparency. We can fairly trivially prove that ones and ones' are equal so == is not allowed to distinguish them. Fortunately it is impossible to write == above, at least using primitives within the language. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MonadPrompt + Gtk2Hs = ?
On Sun, 2008-01-13 at 14:53 -0200, Felipe Lessa wrote: Problem solved? Not really: - This kind of implementation hides lots of subtle bugs. For example, because of postGUIAsync being used in Print case, the user will see multiple dialog boxes at once and -- strangely enough -- he'll see first the last message printed. It isn't always easy to see this kind of bug at first sight, and it can be very hard to track it down. You could use another thread :-) That is have an output thread that reads a queue from your game engine and only looks for the next output message at appropriate points. - Another problem may happen with scheduling. For some reason, there are times in which it takes some time for the control to pass from the Gtk thread to the forkIO one, effectively 'freezing' the game for some time. Unfortunately this problem doesn't show up above, but I have experienced it on a larger game I'm currently programming using Prompt. Are you linking using -threaded or not? If not then you need another trick to use cooperative scheduling between Gtk and the RTS. - It is possible that the user clicks on the button between f1 and f2. Again, on this very simple example nothing seems to go wrong, but there shouldn't be anything between f1 and f2 as the GUI is on an inconsistent state. It should be noted that the scheduling problem can be mitigated using 'yield' on some key spots. This not only feels hackish, but also doesn't scale very well. You must not be using -threaded then I'm guessing. That'd solve the problem. Another approach that is sometimes adopted to solve this kind of problem is creating a main sub-loop with 'mainIteration'. This essentially removes the need for those nasty evil threads =). That's pretty ugly. I'd avoid that if I were you. Here's my suggestion: use two threads. One thread for the game logic and one thread for communicating with the user interface. Then use an input an output channel to post interesting events between the two. The GUI would then also post interesting events into the incoming channel for the view/ui thread. Of course you'd have to link using -threaded and use postGUISync/Async as appropriate from the view/ui thread. By serialising all button events into a channel it allows you to ignore button presses that happen at certain moments. And as I suggested above, it allows you to serialise the output events so you don't end up showing several dialogues to the user at once. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MonadPrompt + Gtk2Hs = ?
On Sun, 2008-01-13 at 16:37 -0200, Felipe Lessa wrote: On Jan 13, 2008 4:01 PM, Duncan Coutts [EMAIL PROTECTED] wrote: On Sun, 2008-01-13 at 14:53 -0200, Felipe Lessa wrote: Are you linking using -threaded or not? If not then you need another trick to use cooperative scheduling between Gtk and the RTS. [snip] You must not be using -threaded then I'm guessing. That'd solve the problem. Actually I tried with all combinations of -threaded/not -threaded and forkIO/forkOS. Use forkIO not forkOS. I'm using an uniprocessor, but a simple turn-based game shouldn't depend on dual-cores anyway =). Yes, those freezes do seem rather strange, and when I introduced some (unsafePerformIO . putStrLn) with the wall time they magically disappeared. Weirder. I didn't try to pursue those little insects further because I got the feeling that no mather what, they would come back. Is this unix or windows btw? [...] using 'mainIteraction' [...] That's pretty ugly. I'd avoid that if I were you. Yes. =) Here's my suggestion: use two threads. One thread for the game logic and one thread for communicating with the user interface. [..] It seems to be a nice idea. I worry about intermediate states that shouldn't be observable (in my game the inputs the user is allowed to give change over the time -- it's a board game, so which pieces can move vary according to the current board), but what concerns me more after that bad experience with only one forked thread are the delays between the user giving an input ( e.g. moving a piece) and the feedback being given (an animation of the result). The chain would be something like input given -- processed -- new board created -- shown (1) (2) (3)(4) So the interaction between the threads would be gtk: (1) ===\ /=== (4) channel: \===\ /===/ runPromptM: \=== (2) === (3) ===/ That should be fine. Haskell thread are quite sufficiently fast. The delays you're seeing are not because of general thread implementation slowness. I'll try to code that ASAP and see how everything works together. If I do observe the same delay problem, I'll try to at least reproduce it on another machine and maybe create a simple test case. Good plan. If you're using -threaded make sure you really only ever call gui methods from event callbacks or within postGUISync/Async or things will go wrong in various random ways. In fact it might be a better idea to use the cooperative scheduling trick and make sure it works with the single threaded rts. Other than that, I'm surprised you didn't comment about the last solution, as that's where I'm currently heading. =) Oh sorry, I didn't get that far :-) It looks like it works a lot nicer so go with it :-). Remember, in general it is possible to switch between the console IO style where you're in control and the GUI event inversion of control style system. It's the thread/event duality thing. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-Cafe] Add number of downloads to hackageDB page?
On Sun, 2008-01-13 at 23:18 +0100, Hugh Perkins wrote: I seem to remember a thread about this a while back actually, but... Any chance of adding the number of downloads to the hackageDB page? For those packages that are included in ghc, hugs etc, perhaps add a green tick with included in ghc, included in hugs, etc? That way it should be relatively easier to know for newbies which packages are more or less mature/stable. That is indeed the highest priority for hackage at the moment, that is, getting enough information onto the hackage pages for people to make sensible decisions about what packages to choose. This is also closely related to measuring package QA, ie what packages work on what platforms. Optional: perhaps include a tick-box/dropdown to only show packages with more than a certain (configurable) number of downloads? There are loads of great ideas like these floating around and we've had a few discussions on what the most important ones are and how to go about implementing them. The block to progress is enough people with enough time to actually implement these suggestions. So let me take this opportunity to invite everyone who is interested in improving hackage to speak up. If you're interested you should: * Join the cabal-devel mailing list * Take a look at the feature requests in the hackage trac and make sure all your suggestions are properly documented * Post to cabal-devel to say that you're interested and we can discuss things in more detail and suggest where to start and what approach to take http://www.haskell.org/mailman/listinfo/cabal-devel http://hackage.haskell.org/trac/hackage At the moment I am particularly keen on the idea of getting cabal-install to send build reports back to the hackage server and then using that information to show what packages work on what platforms (where platform is the os, compiler version etc etc). So if someone is interested in helping with that then do get in touch. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support
On Tue, 2010-04-06 at 18:51 -0400, Thomas Tuegel wrote: Hello again! Based on the invaluable feedback I've received, I've made some revisions to the proposal I made a few days ago (at the end of this post, after my signature). I apologize for the length of my post, but I'd like once again to solicit feedback on this. Any commentary is very helpful! Hia Thomas. Package Description File Syntax The syntax for designating test executables in package description files will be based on the existing syntax for describing executables. Such a stanza in the hypothetical package's description file would look like: Test foo-tests main-is: foo-tests.hs build-depends: haskell-foo, Cabal, QuickCheck One feature that I consider to be vital (and as Cabal maintainer I get to say that kind of thing! ;-) ) is that the stanza must specify the testing interface that it supports. The importance of this is that it lets us develop improved testsuite interfaces in future. At the moment there are two test interfaces we want to support. One is the simple unix style exit code + stdout interface. This is good because it is a lowest common denominator that all existing testsuites can fit into. Of course that test interface does not provide any detailed machine-readable information (though you do get human-readable test logs). So that's why we want a second interface. That one should let the testing agent (for example cabal test but could be other agents) get much more detail about what tests can be run and then what the results are of various tests. The details of such an interface are up for discussion. I do not mind if that is a command line executable interface or a library interface. Handling of Test Executables by Cabal The changes proposed here will make it possible to build, test, and install a Cabal package with the usual sequence of commands: That all sounds reasonable. I'd like to add that the interface between the testsuite and a testing agent such as the cabal program should be clearly documented and specified. There will likely be dedicated test agents that want to run the tests too and send reports to other systems (e.g. dedicated hackage test agents) and convert to other formats (e.g. integration in companies in-house systems). A cabal test user interface is obviously great for developers. Gregory makes a goof suggestion about using or adapting the existing test-framework package. That was also something I was thinking about. It would be good to work with the maintainer of the test-framework package so that it can be used to implement the interface that Cabal specifies. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] libraries [was GUI haters]
On Fri, 2010-04-02 at 09:39 -0700, gladst...@gladstein.com wrote: As a working engineer, one of my greatest frustrations is my inability to use Haskell in the workplace. The unfortunate fact is that my media industry clients use mostly Windows, some Macs, and no linux except for servers. The core system works everywhere, but many contributed libraries don't. GUIs are the big showstopper. It's really not that bad. I have customers using Haskell GUI applications on Windows (Gtk2Hs). We hardly had any problems at all. -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: GSoC: Improving Cabal's Test Support
On Wed, 2010-04-07 at 16:09 -0400, Thomas Tuegel wrote: On Wed, Apr 7, 2010 at 3:33 PM, Duncan Coutts duncan.cou...@googlemail.com wrote: The importance of this is that it lets us develop improved testsuite interfaces in future. At the moment there are two test interfaces we want to support. One is the simple unix style exit code + stdout interface. This is good because it is a lowest common denominator that all existing testsuites can fit into. Of course that test interface does not provide any detailed machine-readable information (though you do get human-readable test logs). So that's why we want a second interface. That one should let the testing agent (for example cabal test but could be other agents) get much more detail about what tests can be run and then what the results are of various tests. For the purpose of differentiating between these two, would a field in the test section such as interface: stdout (in the first case) or interface: detailed (in the second) suffice? Yep. The details of such an interface are up for discussion. I do not mind if that is a command line executable interface or a library interface. That's something I've been thinking about. The former seems more portable. Maybe cabal could call the test program with test_program --list to produce a list of tests and test_program test1,test2,test3 to run some tests. Having some ideas is good. The details of the interface can be worked out during the project. I also want to ask how strictly this is within the scope of the SoC project, i.e. how well will my proposal be received if it focuses primarily on the first part of the problem (getting everything working for the stdout interface)? I ask because the detailed interface seems like a much larger mandate given that cabal doesn't really support any of the syntax/features for the simple stdout interface. Certainly we want to get the first part working first. My guess is that there is time within the 3-month GSoC period to complete the basic bits and to at least have a go at a prototype of a more detailed interface. That part doesn't need to be final, especially given that it will be possible to create new interfaces in future. Handling of Test Executables by Cabal The changes proposed here will make it possible to build, test, and install a Cabal package with the usual sequence of commands: That all sounds reasonable. I'd like to add that the interface between the testsuite and a testing agent such as the cabal program should be clearly documented and specified. There will likely be dedicated test agents that want to run the tests too and send reports to other systems (e.g. dedicated hackage test agents) and convert to other formats (e.g. integration in companies in-house systems). Rogan mentioned possible upcoming support in test-framework for JUnit XML as an output format for test results. That certainly seems to be widely supported; do you think it is suitable? I think it's important to be able to convert into standard or custom formats. I've no idea if JUnit XML would make sense as the native format. It's plausible. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: GSoC: Hackage 2.0
On Wed, 2010-04-07 at 00:40 -0400, Matthew Gruen wrote: Hi Haskellers, I'm Matt Gruen (Gracenotes in #haskell), and the Hackage 2.0 SoC project at http://hackage.haskell.org/trac/summer-of-code/ticket/1587 really piqued my interest. It seems doable, in a summer, to make the new hackage-server more-than-deployment-ready as well as clearing out some items in the hackage bug tracker[0]; so, I've been working on a proposal. In this email I'd like to consolidate my mental notes for haskell-cafe and formulate a roadmap towards a more social Hackage. Great. The most vital part is getting hackage-server http://code.haskell.org/hackage-server/ to a state where it can be switched in place of hackage-scripts http://darcs.haskell.org/hackage-scripts/, and doing it properly, organizing the code so it can be extended painlessly in the future. Yes. I should warn you that I've become increasingly keen on the latter aspect recently. :-) For putting the 2.0 in Hackage 2.0, any interface changes should help the library users and the library writers/uploaders without hurting either of them. Yes, there can sometimes be a bit of a tradoff between users and uploaders. With some proposed features we have to be careful not to annoy one group or the other. Hackage should contain more of the right kind of information. Statistics help everyone, and they're a pretty good gauge on the direction of Hackage as a whole. Package popularity contents are one form of this. Reverse dependencies and even dependency graphs[1] are great, if I can integrate and expand Roel van Dijk's work[2]. Yep, reverse deps are totally doable and really useful. Number of reverse deps, combined with number of downloads is probably a pretty good popularity metric. There should also be some space on package pages, or on pages a link away from them, for users to contribute information and suggestions. Coders can explain why or why not the package met their needs, as a sort of informal bug/enhancement tracking service. Yeah, that's where we've got to be careful. Many packages already have bug trackers and maintainers do not necessarily want yet another website to have to cover to see where users are complaining. I think a user commenting system is probably one of the most tricky bits to design, because of the social aspects. There are issues like not duplicating existing mailing lists / bug trackers / wikis and trying to keep information relevant as new releases come out (eg imaging a comment saying this package is no good because it does not have feature X and yet the current release has feature X). My suggestion is to put this feature further down the TODO list. Another helpful flavor of information is package relationships beyond dependencies: 'Deprecated in favor of Foo', 'a fork of Foo' Yes, deprecation is important. We currently have some support for that, but it's not very good or easy for maintainers to use. There's also a need for a more interactive form of package documentation, but this should strengthen relationships with existing tools like Haddock and Cabal, not bypass the tools. For example, adding a changelog[3] or making Haddock's declaration-by-declaration commentary more wiki-like[4]. Changelogs seem to be within the scope of Hackage 2.0, integrating with Cabal; Haddock wikification might not be, perhaps deserving a separate student-summer session of its own. These can improve the package page and documentation subtrees. Yes, I'd suggest looking at the changelog issue but probably not wiki haddock editing. That would indeed be cool but is a rather bigger scope. More generally, how can library users find the package they want? Search! Metrics! Categories themselves are great, but a tag system could identify and group specific package functionality. There could be sorting by ratings and reviews (4/5 lambdas!). Metadata searches, like those Sascha Böhme implemented in SoC 2007[5], could be integrated. It's not always obvious which ideas will help and which won't see good returns, which makes it all the more important to bring hackage-server to a state where future extensions can be easily written, submitted and deployed. That's the goal here. Again, I suspect this is a feature too far for a GSoC. If we can build the infrastructure which makes adding such features easier then the project would be a success. On the technical side, I realize I'd need to spend a not-insignificant amount of time on a user account system, dealing with authentication and related issues. One additional bit of functionality to manage is the hackage build system, which is used to ensure that packages build and to generate documentation. When building depends on FFI or OS-specific bindings, specific versions of other packages, compiler choice or compiler version choice, including language extensions, this is not trivial. One of two good routes is running cabal server-side to generate build reports and
[Haskell-cafe] Re: GSoC proposal: Extend Cabal Preprocessors.
On Thu, 2010-04-08 at 22:10 -0400, Diego Echeverri wrote: Hi! I finish writing my proposal (maybe a bit too late). I would be glad to read any feedback. Hi Diego, Generally a good proposal. It would be great for Cabal's Simple build system to be able deal with pre-processor chaining and with pre-processors that do not have a simple 1:1 relationship between .hs and other source files. Here are two closely related issues you might like to think about: * pre-processors that have inter-module dependencies (e.g. c2hs) * pre-processors that generate modules from nothing ie there is no special file extension, simply a program that generates a specific module. This is common for things like adding the darcs context, or project-specific generation. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal-install
On Mon, 2010-03-08 at 17:33 +, Andrew Coppin wrote: Miguel Mitrofanov wrote: See http://www.haskell.org/cabal/ for more information. ^ | + Oh, sure, like I haven't already tried *that*. ;-) BTW, for future reference, the user guide on the cabal home page does mostly document the cabal command line interface. It talks about runghc Setup.hs blah but you can mentally substitute that for cabal blah and the same applies. At some point we'll update the user guide to be more specifically about the cabal program, rather than just about the Setup.hs interface. Volunteers welcome! I did recently switch the user guide from docbook xml to markdown, so it should be a lot easier for contributors. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
