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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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
[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
[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] 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
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
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] 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] 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] 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] 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] 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] 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] 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: [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] 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: [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] 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] 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] Pure functional GUI (was
On Thu, 2007-08-09 at 08:59 +0800, Hugh Perkins wrote: To be fair, GTK is pretty standard. This is so even for big name gc'd imperative languages such as C#. Sure, you can use Windows.Forms in C#, but you often wouldnt, because of the patent burden. Also, gtk in partnership with glade rocks! How easy is gtk to use from haskell by the way? In gc'd imperative languages, typically only one thread is allowed to communicate with the GUI, and you need to set up a whole bunch of message-parsing stuff to communicate with other threads. To what extent is this easier in Haskell? The story on this isn't as nice as it could be. It depends on which GHC runtime system you choose to use. In the single threaded rts, you can use threads willy nilly as they all run in the context of one OS thread (though it requires a little bit of code to set up cooperative scheduling). In the fully threaded rts you have to be very careful to only use GUI stuff from a single OS thread. Gtk2Hs provides a couple functions to post actions to the main GUI thread. We've been thinking of ways to make this more transparent but it's not so easy. Other question on using gtk from haskell: how easy is it to integrate with glade? ie, can we directly bind glade form elements to haskell variables? How easy is it to bind events to glade form elements from within Haskell? It's pretty easy, see the Gtk2Hs/Glade tutorial: http://haskell.org/gtk2hs/docs/tutorial/glade/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
re: [Haskell-cafe] Pure functional GUI (was a regressive view of support for imperativeprogramming in Haskell)
On Wed, 2007-08-08 at 19:14 +, Peter Verswyvelen wrote: So could you please tell me more about the problem with pure functional GUIs and why this is not part of the Haskell library? I mean a GUI library completely written in Haskell, not wrapping a popular library. Partly because just getting the drawing and interaction behaviour to be acceptable would be many person-years of work. GUI toolkits are not especially simple things. Even if you could do it in just 1/10th of the number of lines of code of Gtk+ or Qt it'd be a massive undertaking. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] c2hs and structs?
On Sat, 2007-08-04 at 23:59 +0100, Magnus Therning wrote: I can't seem to find any information on how to deal with C functions that return a (pointer to a) struct. C2hs tells me there's no automatic support for marshalling structs (I'm using version 0.14.5). If I'm to do it by hand, is there a preferred way? (E.g. make the type adhere to the type Storable.) Yes, you want to make it an instance of Storable. You can use c2hs's get and set hooks to help with this. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: encoding-0.1 release
On Thu, 2007-08-02 at 18:44 +0200, Wolfgang Jeltsch wrote: Am Donnerstag, 2. August 2007 12:22 schrieb Henning Günther: […] ISO 8859-* (alias latin-*) Not every ISO-8859-* encoding is a Latin-* encoding. […] Wouldn’t it be good to use some already existing library like iconv or do you think, this is not feasible (because you want to support lazyness, for example)? Yes, I was talking to Henning about this. I've got an iconv binding[1] that use lazy bytestrings (so it does support lazyness of course) and is pretty quick. Henning has been thinking much more about what the appropriate api should be, I've just got: type Encoding = String convert :: Encoding - Encoding - Lazy.ByteString - Lazy.ByteString so we might be able to use iconv underneath (if it's available). Duncan [1] darcs get http://haskell.org/~duncan/iconv/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re : Re : Re : [Haskell-cafe] Indentation woes
On Wed, 2007-08-01 at 16:05 +0200, david48 wrote: On the topic of indenting, it would be nice if there was a way to tell the compiler the size of the tab characters. The way it is now, I have to use space characters to indent. Good! You're doing exactly the right thing according to the Haskell style guide: http://urchin.earth.li/~ian/style/haskell.html :-) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS swapping and haskell data structures
On Wed, 2007-08-01 at 11:31 -0700, Bryan O'Sullivan wrote: Alex Jacobson wrote: If you create a Data.Map or Data.Set larger than fits in physical memory, will OS level swapping enable your app to behave reasonably or will things just die catastrophically as you hit a memory limit? Relying on the OS to page portions of your app in and out should always be the fallback of last resort. You are fairly guaranteed to get terrible performance because the VM subsystem can't anticipate your app's memory access patterns, and catastrophic death of either your app or other system processes is a strong possibility (Google for OOM killer if you want some horror stories). In many cases, you can't even rely on paging being possible. Furthermore, as I understand it, GC does not interact well with paging since the GC has to traverse the data structures on major GCs it'll force it all to be kept in memory. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS swapping and haskell data structures
On Wed, 2007-08-01 at 12:32 -0700, Alex Jacobson wrote: Ok, so for low throughput applications, you actually need a disk strategy. Got it. Ok, is there a standard interface to BerkleyDB or some other disk based store? Well on hackage there's anydbm and BerkeleyDB. The former is probably the older and more mature of the two. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some Haskell platformish questions
On Wed, 2007-08-01 at 13:48 -0700, David Pollak wrote: So... on to the questions: First of all I recommend you check out these resources: The standard libraries: http://haskell.org/ghc/docs/latest/html/libraries/ A large collection of other libraries: http://hackage.haskell.org/ Another directory of apps and libraries, many of which are not yet available through hackage: http://haskell.org/haskellwiki/Applications_and_libraries * Can GHC generate stand-alone executables with all the dependencies linked in such that I can distribute the single file without worrying about including a bunch of DLLs/SOs? The answer seems to be yes, but I wanted to confirm. Yes, but the same is not true of any C dlls you link to, eg GUI libs like gtk or wx. * How much of a distribution footprint is the Haskell runtime? If I have a Hello World app, roughly how big will the EXE be (if one includes the JRE in the runtime, a Java/Scala program has a minimum footprint of 20M... that's big.) Statically linked hello world is 470K on my amd64 linux box. An equivalent GUI hello world with Gtk2Hs is 540K. These are still dynamically liked to libc and libgmp. * Same goes for the runtime... I've looked at the stats on the Language Shootout home page and these look encouraging, but I wanted to see if the reasonable footprint is a reality. Not sure what you're asking here. The ghc rts is linked into the program. * How real/solid/stable is the wxHaskell widgets package? Is it being well maintained? Is there (okay... this is pie in the sky) an GUI Builder for it? Perhaps someone who uses wxHaskell can help you with that. I help maintain Gtk2Hs so can tell you about that... Gtk2Hs is well maintained imho :-) We do releases roughly every 6 months. The last one was a couple weeks ago. It has an installer for Windows and it's included in several other platforms like debian, fedora, gentoo, freebsd and macports. The glade GUI builder can be used with Gtk2Hs on all platforms. * How are the Windows/COM bindings in Haskell... would it be possible to, for example, embed an IE Browser COM control in a a wxHaskell window? There is a COM tool, not sure about embedding IE. Gtk2Hs supports embedding the mozilla rendering engine, though not on Windows at the moment. HDirect has not seen much maintenance but apparently there is an updated version that was used in VisualHaskell. Perhaps someone else can tell you more about HDirect, I'm not especially familiar with it. http://www.haskell.org/hdirect/ http://www.haskell.org/visualhaskell/ * I found a package to do HTTP requests in Haskell but it does not seem to support HTTPS. Is there an HTTPS client package for Haskell? There's work on a libcurl binding going on at the moment. * How are Strings internally represented? Are they single byte or multi-byte characters? How easy it is to translate to/from internal representation to UTF-8? Strings are represented as ordinary Haskell lists of Unicode code points. There are functions available for converting to and from byte sequences in UTF8 and other encodings (though not in the base packages at the moment). Both Gtk2Hs and wxHaskell support Unicode. * How's the XML support? Will the XML parser handle non-Latin characters and properly encode stuff? Does XML get parsed down into easily mappable/filterable collections? There are 2 major xml packages, HaXml and HXT. You can download them and find their documentation on http://hackage.haskell.org/ * Is there support for SHA256 (I saw an SSLeay package which had support for a lot of stuff, but not SHA256)? The Crypto package supports SHA1. * I understand that Haskell has a better approach to parallelizing tasks, but I have not seen much about the actual manifestation of this... would someone be so kind as to give me a pointer? Look for Haskell's lightweight threads, STM and parallel strategies: Control.Concurrent Control.Concurrent.STM Control.Parallel.Strategies * On a related note, I have become a fan (via Scala) of Erlang-style Actors and asynchronous message passing. Are there any similar packages for Haskell? Not so far as I know, though the concurrency library supports channels so you can use a pattern where a thread reads messages from a channel and post's messages to other channels. * I tend to do most of my coding in either Emacs or Eclipse... how's the Haskell support in either? Is there a preferred editor (I don't mean to start any wars here... :-) Emacs, vim, nedit, gedit and others support Haskell syntax highlighting. Emacs has some additional ghci integration mode. There's a project to add Haskell support to Eclipse, though I'm not sure how mature it
Re: [Haskell-cafe] Some Haskell platformish questions
On Wed, 2007-08-01 at 15:31 -0700, David Pollak wrote: Duncan, Many thanks to you as well! On 8/1/07, Duncan Coutts [EMAIL PROTECTED] wrote: On Wed, 2007-08-01 at 13:48 -0700, David Pollak wrote: * Can GHC generate stand-alone executables with all the dependencies linked in such that I can distribute the single file without worrying about including a bunch of DLLs/SOs? The answer seems to be yes, but I wanted to confirm. Yes, but the same is not true of any C dlls you link to, eg GUI libs like gtk or wx. Okay... so I'll have to include the (for example GTK2 DLLs) with the distribution... Yes. Those are available here: http://haskell.org/gtk2hs/win32/ As a demo of an windows installer for a prog that uses Gtk2Hs, see: http://haskell.org/~duncan/gtk2hs/LSystemSetup.exe (3.5Mb) At some point I intend to write some more detailed instructions on this, but in the mean time you can probably figure it out from the example. It's just a matter of putting the right dlls and other file in the right place, the .zip files have the right directory structure all ready, so that's pretty easy. I just grabbed a copy and installed it (on Ubuntu... my preferred development platform.) Note that it looks like Ubuntu doesn't have the latest version yet: http://packages.ubuntu.com/feisty/libdevel/libghc6-gtk-dev but that version should be ok for most stuff you want to do. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some Haskell platformish questions
On Wed, 2007-08-01 at 17:29 -0700, David Pollak wrote: Duncan, Okay... I'm pretty darned impressed. I downloaded the packages and got my first Haskell/Glade app running in about the same amount of time as it took me to get my first VS.Net app up and running. Excellent :-) Thanks for the pointer to GTK2hs. You're welcome. I hope to have a nice app to add to the list of Haskell apps pretty soon. We're always very happy to showcase applications of Gtk2Hs on the website: http://haskell.org/gtk2hs/archives/category/screenshots/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Conditional compilation of Setup.hs
On Tue, 2007-07-31 at 13:46 +0100, Bayley, Alistair wrote: I'd like to add a #ifdef to Takusen's Setup.hs, so that we can have a single source file that will compile with ghc-6.6 and ghc-6.6.1. With ghc-6.6 and Cabal-1.1.6.1 we use splitFileName and joinPaths from Distribution.Compat.FilePath. With ghc-6.6.1 (which includes Cabal-1.1.6.2) these have been moved to System.FilePath. I'd like to do something like the following: #ifdef __CABAL_VERSION__ 117 import System.FilePath (splitFileName, combine) joinPaths = combine #else import Distribution.Compat.FilePath (splitFileName, joinPaths) #endif Is something like this possible with Cabal? No, Cabal does not define any cpp defines like that. It's either that, or make Takusen's install depend on filepath. I'm not sure which is the least desirable, but I'm open to suggestions. To be fair, we already require our ghc-6.6 users to upgrade Cabal from 1.1.6 to 1.1.6.1, so making them install filepath instead perhaps isn't so bad, and is no more effort. I'd got with filepath in that case. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Definition of the Haskell standard library
On Tue, 2007-07-31 at 10:15 +0100, Simon Peyton-Jones wrote: All true, but not so helpful for Joe User. For Joe, I think it might be helpful to have some easily-discoverable notion of which package quality and stability. - Package X is blessed; lots of people have argued over its design, it's stable, widely used, and actively maintained. Changes to this package goes through a quality-control process. - Package Y is a bit specialised, but it's the result of work by a small group, and it's actively maintained. - Package Z is designed, written, and maintained by one person. That person has kindly put it on Hackage so that others may share it, but you probably don't want to rely on it unless you are happy to help maintain it. Then, in effect, the standard library is all the X packages. Yes. I wonder if it'd help to have some descriptions such as those above (better worded), and use them? Cabal already has a stability indication, and that might serve, but we'd want to articulate much more clearly what it meant. I'm not sure that belongs in the cabal file, afterall, being blessed is a central community consensus thing, not a distributed decision taken by each person writing the cabal file for their package. I can't make a blessed package by just saying that it is so. So it's clear at the moment that the base package is blessed, changes to it go through the library submissions process. It's not so clear for the other packages that ghc has distributed and have often been taken to be the standard library. Many of them look more like Y's above (like parsec, regex-*). So yes, I think we should make this clear, and that blessed packages that are covered by the library submission process should be clearly recorded and publicised centrally. Even then though, I think Chris was looking for something slightly wider. For example ghc has distributed quite a range of packages that would probably not be classified as X above, eg OpenGL, GLUT, OpenAL, FGL, HGL, etc. These are not necessarily blessed packages but are known to be of a high quality (ok, except HGL). Chris wanted to know this to distinguish from the many other packages on hackage. What is not clear to me yet is if we should just rely on mechanisms in hackage to distinguish the gems from the failed experiments or something more centralised. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Conditional compilation of Setup.hs
On Tue, 2007-07-31 at 17:20 +0400, Bulat Ziganshin wrote: Hello Duncan, Tuesday, July 31, 2007, 5:06:35 PM, you wrote: #ifdef __CABAL_VERSION__ 117 Is something like this possible with Cabal? No, Cabal does not define any cpp defines like that. фафшкб one of this year GSOC projects is Cabal sections impelementation which should allow to make parts of cabal files specific, for example, for windows and unix. may be this new feature will allow to check library version too? This allows conditional compilation in the library/program code but not in Setup.hs itself. 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 Tue, 2007-07-31 at 17:26 +0100, Simon Peyton-Jones wrote: | I see it as a really big deal that documentation becomes fragmented when | one is using many packages, so that it's harder to find what you want. | In fact, I'd classify that as the single biggest reason that I don't use | many packages now When you install packages A,B,C, the documentation for A,B,C (and nothing else) ought to be locally available as an integrated whole, much as at the GHC web site. I don't know whether Cabal does, or could do, that, but it's surely what one would expect. 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. What is missing from the local docs is a single integrated index page that lists all the modules and then links off to the various packages's docs like we have on the ghc website. The problem with generating one of those is what manages it? What package would it belong to etc. On some systems (windows, gnome) there are dedicated help viewers that can help with this contents/index issue. haddock supports both (mshelp, devhelp). I'm not sure everyone would find that a sufficient solution however. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Knuth Morris Pratt for Lazy Bytestrings implementation
On Wed, 2007-08-01 at 01:51 +0100, Tim Docker wrote: Now I wonder what that 7MB file might be? :-) We (team TNT) implemented KMP over lazy bytestrings as part of our icfp 2007 contest entry. As I remember, for the DNA evaluator it gave modest speed improvements over more naïve searching. Our implementation was based upon this blog post: http://twan.home.fmf.nl/blog/ If anyone can come up with a fast search implementation for strict and/or lazy ByteStrings I'll include it in the bytestring package. The current Data.ByteString search uses a rather under-optimised KMP implementation. I say under-optimised as I think it typically gets beaten by a naive search. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Definition of the Haskell standard library
On Mon, 2007-07-30 at 09:19 -0600, Chris Smith wrote: Can someone clarify what's going on with the standard library in Haskell? As of right now, I can download, say, GHC from haskell.org/ghc and get a set of libraries with it. I can visit http://haskell.org/ghc/docs/latest/html/libraries/, linked from the haskell.org home page, and see descriptions of all of those libraries. I can build with --make (or if I'm feeling masochistic, add several lines of -package options) and it works. That's all great. I've seen some stuff lately on -libraries and this list indicating that there's an effort to change this. People asking whether something should be included in the standard library are being told that there is no standard library really. I'm hearing that the only distinction that matters is used by GHC or not used by GHC, and that being on hackage is as official as it gets. Am I misunderstanding? Is there something awesome about Hackage that I'm not seeing? It's not finished yet :-) I hope one of those two is the case. Otherwise, there's a serious mistake being made here. Having a web site where people can download any of hundreds of independent libraries is not the same thing as having a good standard library for the language. I don't want to see the day when setting up Haskell involves a day-long effort of figuring out what libraries to download and install from Hackage, and in what order to do it to satisfy all the dependencies, We have tools to solve the downloading and installing all deps problem. It's called cabal-install. It's sort-of almost ready for wider testing. and new Haskellers poring over web sites for the thousandth time before realizing that so-and-so's GUI library hasn't actually been touched since they finished their class project in 1998 and doesn't build with the latest version of Qt or whatever. So, yes, at the moment hackage looks like a big list of packages, but the tools for automatically downloading and installing will mature. Also we expect further improvements to hackage to do more automated QA and gather testing feedback, so we can detect and manage bitrot. People have also been talking about gathering usage stats, so one can see which out of a collection of packages in a similar area are most used. I'm sure there are other ideas that can be borrowed from CPAN and similar things. On the other hand, it's not entirely true that there's no standard library, it's just that it's borders are slightly fuzzy. For example, we do have the library change submission process for modifying the standard libraries. Up until now that has been taken to mean changes to the base package. That package is now being split up, so we'll have to think about what it'll apply to in the future. My opinion is that in the past it has been too difficult to get changes into the base library, that there's been too much stability at the expense of improving scope and quality. Making it easy to install new packages and upgrade existing standard libraries should make it easier to trial more major changes outside of the standard libs before proposing getting those changes integrated. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Definition of the Haskell standard library
On Mon, 2007-07-30 at 11:05 -0700, brad clawsie wrote: On Mon, Jul 30, 2007 at 05:27:21PM +0100, Duncan Coutts wrote: We have tools to solve the downloading and installing all deps problem. It's called cabal-install. It's sort-of almost ready for wider testing. duncan - will this have an interactive prompt? i have found perl -MCPAN -e shell immensely useful over the years At the moment it doesn't, but you're not the only one to suggest that it should. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Questions about threads
On Sun, 2007-07-29 at 17:35 -0500, John Goerzen wrote: Hi everyone, I have been confused by some things about threads for a long time. I'm hoping someone out there can help clear this up. I'll clean up and document on the wiki if we get conclusive answers. So it seems there are four scenarios for firing off threads: A) Threaded RTS, forkIO B) Threaded RTS, forkOS C) Non-threaded RTS, forkIO D) Non-threaded RTS, forkOS If I recall correctly, D throws a runtime error because the guarantees that forkOS is supposed to provide are impossible without the threaded rts. (I think) You generally do not want forkOS. It's really only for wierd foreign libs that require that they be called from the same OS thread every time eg because they keep thread local state (like OpenGL). Using forkOS will get you no extra parallelism. You get parallelism linking with the threaded rts and running your program using multiple capabilities. http://haskell.org/ghc/docs/latest/html/users_guide/sec-using-smp.html So the questions, for each of the four models, are: 1) What is the impact of firing off a thread to execute a pure (non-IO) computation under each model? Will multiple pure computations be allowed to run in parallel, or will only one run at a time? (While the computation may be outside the IO monad, of course at the end it will have to use IO to communicate the result back.) You only get parallelism (as opposed to concurrency) of pure code when using the threaded rts, and then only when running the program using more than one capability (+RTS -N2 -RTS). 2) What is the impact of IO under each model? Will GHC internally use select/poll/whatever? Or will each thread get a dedicated OS thread that uses synchronous I/O? In both ghc only uses on OS thread for IO. In the threaded rts it's an *additional* OS thread but it's still only one. In the single threaded rts, it's the rts that does the select/poll. In the threaded rts it's a Haskell IO manager thread that uses select/poll on behalf of other Haskell threads that need to block until the completion of I/O. 3) When signals are received, which thread receives them? Each signal gets handled by a new unbound Haskell thread. 4) When forkProcess is executed, which thread(s) are duplicated to the forked process? Only the calling one. All other Haskell threads disappear. 5) What does an FFI import safe mean under each model? single-threaded: all Haskell threads block until the foreign call returns. multi-threaded: other Haskell threads continue in parallel. 6) What does an FFI import unsafe mean under each model? single-threaded: all Haskell threads block until the foreign call returns. multi-threaded: other Haskell threads in the same 'capability' block until the foreign call returns. If the program is using more than one capability then Haskell threads in the other capabilities should continue to run. In both cases, unsafe should only be used for short-running, non-blocking foreign calls that do not make callbacks into Haskell. 7) What is the expected future level of support for each model? This is of significant concern to me, as it appears that the threaded RTS is only supported on an extremely limited set of architectures (most programs won't even link on Debian's autobuilders if I use -threaded). Also I have heard comments that the non-threaded RTS may be dropped in the future. The non-threaded rts is not going to get many improvements though it probably will not be dropped while the threaded rts doesn't work on those other arches. The threaded rts will probably become the default in some upcoming release. 8) What is the expected level of support for STM in combination with each threaded model? No idea, but bear in mind the threaded rts is where the attention is going. 9) How does par mix with each threaded model? Is it equivolent to forkOS or forkIO? forkIO. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Using Gtk2Hs version 0.9.12 on a PPC Mac
On Sat, 2007-07-28 at 12:16 +0200, Thorkil Naur wrote: Hello, (From the archives:) [Haskell] ANNOUNCE: Gtk2Hs version 0.9.12 released Duncan Coutts duncan.coutts at worc.ox.ac.uk Fri Jul 27 15:20:57 EDT 2007 Gtk2Hs - A GUI Library for Haskell based on Gtk+ Version 0.9.12 is now available from: ... Duncan (on behalf of the Gtk2Hs team) Following the advice of nominolo_ from #haskell yesterday, I added -L/opt/local/lib to my ghc command and then the helloworld demo of Gtk2Hs worked. The problem seems to be the order in which the two library directories /usr/X11R6/lib and /opt/local/lib appear on the link command: For the GTK+ example that worked, /opt/local/lib comes first. For the Gtk2Hs demo that failed, /usr/X11R6/lib comes first. That's very interesting. I compared these two directories and found these common files: [...] Since some of these (Xrender, fontconfig, and freetype) are actually used in GTK+ (and therefore also Gtk2Hs) applications, there is clearly a potential for conflict here. Certainly and if I recall correctly, the gdb backtrace you got showed that it was failing in a call to a fontconfig function. In any case, adding -L/opt/local/lib to the ghc command makes this library appear before /usr/X11R6/lib on the link command and this seems to solve the problem. Subsequently, I have tried a handful of the other demos, and as far as they didn't require something that wasn't available (glade, for example), they seemed to work. So what I wonder is how we can make this work reliably. We use the flags that pkg-config tells us to use, I'd rather not add platform-specific hacks if we can get the pkg-config settings fixed. So I presume when you run pkg-config --libs gtk+-2.0 it does not list -L/opt/local/lib, or if it does it lists it after -L/usr/X11R6/lib. Is that the case? Where did you install Gtk+ from? DarwinPorts or somewhere else? If it's the pkg-config setting for Gtk+ that we think are wrong then we should get that fixed upstream in the package that installed Gtk+. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Using Gtk2Hs version 0.9.12 on a PPC Mac
On Sat, 2007-07-28 at 17:08 +0200, Thorkil Naur wrote: So what I wonder is how we can make this work reliably. We use the flags that pkg-config tells us to use, I'd rather not add platform-specific hacks if we can get the pkg-config settings fixed. So I presume when you run pkg-config --libs gtk+-2.0 it does not list -L/opt/local/lib, or if it does it lists it after -L/usr/X11R6/lib. Is that the case? For the GTK+ tutorial helloworld.c program: $ pkg-config --libs gtk+-2.0 -L/Users/thorkilnaur/tn/install/gtk+-2.10.14/lib -L/opt/local/lib -L/usr/X11R6/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lSM -lICE -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv -lfreetype -lz -lfontconfig -lpng12 -lXrender -lX11 $ gcc -v -Wall -g helloworld.c -o helloworld `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` ... Scrutinizing the link arguments output by gcc, it appears that the -Ls and the -ls specified on the gcc command have been separated and inserted between other -Ls and -ls supplied by gcc. But the order of the -Ls produced by pkg-config is retained and, as mentioned, this is the case that works without change. Ok. For the Gtk2Hs demo World.hs program, the matter is more complex, especially since the link arguments generated by ghc presumably goes via ghc-pkg that I have never studied in detail before. But let me venture a guess anyway. First we look at the gtk package and its dependents: $ for p in gtk-0.9.12 glib-0.9.12 cairo-0.9.12; do echo $p: `ghc-pkg field $p depends`; done gtk-0.9.12: depends: base-2.0 mtl-1.0 glib-0.9.12 cairo-0.9.12 glib-0.9.12: depends: base-2.0 cairo-0.9.12: depends: base-2.0 mtl-1.0 glib-0.9.12 $ Further: $ for p in gtk-0.9.12 glib-0.9.12 cairo-0.9.12; do echo $p: `ghc-pkg field $p library-dirs`; done gtk-0.9.12: library-dirs: /Users/thorkilnaur/tn/install/gtk+-2.10.14/lib /usr/X11R6/lib /Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs glib-0.9.12: library-dirs: /opt/local/lib /Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs cairo-0.9.12: library-dirs: /opt/local/lib /usr/X11R6/lib /Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs $ The actual link arguments constructed by ghc when compiling World.hs are: $ ghc -v --make World.hs -o helloworld ... Linking helloworld ... *** Linker: gcc -v -o helloworld World.o -L/Users/thorkilnaur/tn/install/gtk+-2.10.14/lib -L/usr/X11R6/lib -L/Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs -L/opt/local/lib -L/Users/thorkilnaur/tn/install/ghc-6.6-for-buildbot-20070221_1000/lib/ghc-6.6.20070220 -lHSgtk -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lSM -lICE -lgmodule-2.0 -lfreetype -lz -lfontconfig -lpng12 -lXrender -lX11 -lgthread-2.0 -lHScairo -lcairo -lSM -lICE -lfreetype -lz -lfontconfig -lpng12 -lXrender -lX11 -lHSglib -lgobject-2.0 -lglib-2.0 -lintl -liconv -lHSmtl -lHSbase -lHSbase_cbits -lHSrts -lm -u _base_GHCziBase_Izh_static_info -u ... $ The -Ls are: -L/Users/thorkilnaur/tn/install/gtk+-2.10.14/lib -L/usr/X11R6/lib -L/Users/thorkilnaur/tn/install/gtk2hs-0.9.12/lib/gtk2hs -L/opt/local/lib -L/Users/thorkilnaur/tn/install/ghc-6.6-for-buildbot-20070221_1000/lib/ghc-6.6.20070220 My guess is now that ghc constructs this list from the package library-dirs, heaping new ones onto the growing list at the end. World.hs refers only gtk-0.9.12 which for some reason doesn't refer /opt/local/lib. However, gtk depends on glib and glib includes /opt/local/lib before /usr/X11R6/lib, but because the latter already appears in the current list, the new one (/opt/local/lib) is simply tucked onto the end. And so on, thereby explaining why /opt/local/lib ends up appearing after /usr/X11R6/lib. Yes, that's the culprit. I don't know what could be done about this, but certainly, the problem cannot be said to be caused by GTK+. Really, the basic problem is this horrendously primitive manner which is used on many of our systems of letting the order of appearance in certain lists influence the outcome of important processes. Plus, of course, the lack of possibility of warning users about this, for example by reporting on ambiguous references in case symbols are defined in multiple libraries. Indeed, it's not Gtk+'s fault. It's the fact that we're splitting up the flags pkg-config tells us about glib, and gtk+, assigning them to the ghc packages glib and gtk and then reconstructing the link command line - but in the wrong order. I'll have to think about this. Thanks for the detailed investigation Thorkil. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] i need wxHaskell compiled for ghc 6.6.1 on Windows
On Wed, 2007-07-25 at 16:57 +0400, Bulat Ziganshin wrote: Hello Duncan, Monday, July 23, 2007, 4:02:42 AM, you wrote: i've taken a look at gtk2hs, but 2 reasons forced me to give wxHaskell a try: - native appearance I think that's pretty good these days, the native theme on Windows has been getting better and better from Gtk+ 2.6 to the current 2.10 it's good and i don't complain about its quality. what i mean here is just what it looks like Unix apps, not like native windows ones. afaiu, GTK paints all controls itself without using native controls and therefore controls look at Windows just the same as in Unix There's really no such thing as Windows native controls any more, at least not ones that any apps actually use. You'll note that Internet Explorer, MS Office and VisualStudio all paint their own custom control set that are similar but not exactly the same as the native controls (eg those used by NotePad/WordPad). Gtk+ uses themes too, and on Windows it uses a Windows theme. This uses the native WinXP themeing dll. It's possible to use any of the Unix themes on windows, but nobody would ever want to do that. As noted before, the differences between the Gtk+ Windows theme and the common 'native' windows control sets have been getting less and less with each recent release of Gtk+. - current lack of high-level properties machinery in gtk2hs Actually Gtk2Hs and wxHaskell have a very similar properties api (they both stole it off of an older Haskell GUI lib) and we're planning to make further improvements to that in the current development cycle. yes, there is API but as far as i see, it's not yet fully implemented for each type of control. for example, in TreeDemo.hs and DirList.hs examples there are lots of handmade calls - compare them to FileBrowse.hs wxHaskell example (although i may be unfair here, but it seems that wxHaskell example uses properties more extensively) Yes, that's what we're addressing in the current dev cycle, making more extensive use of properties and removing the duplication between the properties and the direct set/get calls. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] i need wxHaskell compiled for ghc 6.6.1 on Windows
On Wed, 2007-07-25 at 14:58 +0100, Neil Mitchell wrote: Hi There's really no such thing as Windows native controls any more, at least not ones that any apps actually use. You'll note that Internet Explorer, MS Office and VisualStudio all paint their own custom control set that are similar but not exactly the same as the native controls (eg those used by NotePad/WordPad). But the native controls are a lot nicer. The fact that MS Office, IE and VS are all annoying doesn't meant that Haskell developers should be excluded from writing non-annoying user interfaces. Sure :-) Gtk+ uses themes too, and on Windows it uses a Windows theme. This uses the native WinXP themeing dll. Either 1) it does, but very very badly, or 2) it doesn't. Even the ones that look similar are not quite right. It is getting better though, but I'm not sure they are using the theme DLL (purely from the results, I have no idea what the code says) I think it uses it mainly when you're using the TellyTubbies WinXP themes. It also uses it for colours etc. Yes, that's what we're addressing in the current dev cycle, making more extensive use of properties and removing the duplication between the properties and the direct set/get calls. :( - please let the set/get calls remain, since the properties are likely to only be available with non-H98 types. My PropLang wrapper also has to use set/get directly. The current plan is to mark them as deprecated and remove them from the haddock documentation but not to remove them completely yet. The properties themselves do not have non-H98 types, but the current set function uses existential types. We could provide a simpler version of set that doesn't have the nice syntax and uses H98 types. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC or HSQL
On Wed, 2007-07-25 at 21:04 +0300, George Moschovitis wrote: Dear devs, I am a Haskell newbie and I would like to hear your suggestions regarding a Database conectivity library: HSQL or HDBC ? which one is better / more actively supported? My impression (as a packager not a user) is that HDBC is more actively supported. Also, as I understand it, HDBC was designed with the aim of having a better API than that of HSQL. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] i need wxHaskell compiled for ghc 6.6.1 on Windows
On Sun, 2007-07-22 at 18:02 +0400, Bulat Ziganshin wrote: Hello Neil, Saturday, July 21, 2007, 11:46:59 PM, you wrote: can anyone provide wxHaskell already compiled/compilable with ghc 6.6.1 on Windows? This is precisely the reason I switched to Gtk2Hs - Duncan provides Windows installers as each new GHC release comes out. If wxHaskell wants to stand any chance as an alternative GUI framework there really _must_ be Windows binaries released concurrently with GHC versions... i've taken a look at gtk2hs, but 2 reasons forced me to give wxHaskell a try: - native appearance I think that's pretty good these days, the native theme on Windows has been getting better and better from Gtk+ 2.6 to the current 2.10 - current lack of high-level properties machinery in gtk2hs Actually Gtk2Hs and wxHaskell have a very similar properties api (they both stole it off of an older Haskell GUI lib) and we're planning to make further improvements to that in the current development cycle. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.6.1: Where is Graphics.SOE ?
On Fri, 2007-07-20 at 13:47 +0400, Dmitri O.Kondratiev wrote: Oliver, thanks! I tried that, yet have some problems. Questions: 1) Should I ignore autoreconf errors? I've never managed to get autoconf working on windows. I always generate a tarball under linux and build that on Windows. 2) I thought that building Gtk2hs is done with GHC only. Is it right that build requires C compiler? Yes, it does need a C compiler, but mingw has one so that's ok. 3) Any other ideas what is wrong with this build? Almost certainly the autoconf problem messed things up. It's sadly not all that easy to build from source on Windows, much easier to use a pre-built version: http://haskell.org/gtk2hs/gtk2hs-0.9.11.3.exe The final 0.9.12 will be announced soon and of course that final version will be announced and linked from the Gtk2Hs website. If you really want to build from source on Windows I can give you more detailed instructions, and I should probably update the FAQ on this issue too: http://haskell.org/gtk2hs/archives/2005/06/24/building-from-source-on-windows/ I've also got some semi-automated win32 build scripts: http://darcs.haskell.org/gtk2hs/tools/win32/ and also Gtk+ SDK bundles: http://haskell.org/gtk2hs/win32/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
On Thu, 2007-07-19 at 12:07 +0100, Claus Reinke wrote: the idea is well known: build your app as a server, and put an ajax-based gui in front of it, even if server and browser run on the same machine. A more desktopy alternative: http://www.gtk-server.org/ that looks promising. does that mean one could have the best of both worlds - gtk2hs were available, gtk-server everywhere else? or does this require different code? It'd certainly requires different code internally to present the same API that Gtk2Hs provides. even so, it might be worth it to get a single gui framework working with all haskell implementations and all ghc versions. It would not change the problem with ghc versions. Gtk2Hs does and (almost) always has worked with all versions of GHC, the problem is only the Windows binary builds that are specific to one version of ghc - as are all other binary builds of ghc packages. Using gtk-server would not change that. or perhaps gtk2hs could offer a bridge to hide any differences between direct and server style code? That sounds like a lot of work, probably more work than making the current Gtk2Hs code base work with hugs and yhc. And as I say, it would not solve the ghc binary build version issue. One advantage though would be that a GUI api that used gtk-server would not use any FFI and so would not require any header files installed on the target machine so it'd be easier to distribute as source that any end user could build (where as building Gtk2Hs or wxHaskell from source on Windows is non-trivial.) Personally I'd rather spend any effort elsewhere, like binding more of the Gtk+ api, or providing new simple graphics apis on top of Gtk2Hs, or setting up automatic Windows builds so that there are always installers available for all current and recent ghc versions. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
On Thu, 2007-07-19 at 10:06 +0100, Simon Peyton-Jones wrote: | You're right, that's annoying. It's particularly a problem for Windows | GHC users who expect pre-built binaries, since GHC currently requires | all libs to be rebuilt with each new minor GHC version. Are you sure? We try hard not to change interface-file format or calling conventions between minor releases, so you should not need to recompile with minor releases. Major ones are a different matter, I grant you. Yes, I've always been confused by that. You go to some effort to not change the binary format of .hi files or change the ABI of the RTS etc and yet ghc explicitly checks that the .hi files are exactly the same version preventing any mixing anyway: Foo.hs: module Foo where foo = 3 Bar.hs module Bar where import Foo bar = foo + foo $ ghc-6.6 -c Foo.hs $ ghc-6.6.1 -c Bar.hs Bar.hs:3:0: Bad interface file: Foo.hi mismatched interface file versions: expected 6061, found 6060 So yes, that's why the Gtk2Hs 0.9.11 Windows installer checks for exactly ghc-6.6 and not 6.6.x in general. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
On Thu, 2007-07-19 at 12:02 +0100, Claus Reinke wrote: is there even tool support for i've got a new major version of ghc, please rebuild and register everything i had registered for the old major version.? Gentoo has such a tool. The ghc ebuild instructs users to run ghc-updater after upgrading ghc. It identifies all ghc library packages that portage installed for all other versions of ghc and re-emerges them in the correct order (possibly upgrading them at the same time). It'd probably be a useful feature to include in cabal-install. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] gui libs? no thanks, i'm just browsing.. ;-)
On Thu, 2007-07-19 at 00:12 +0100, Claus Reinke wrote: gui libs are wonderful, but haskell sometimes has too few and sometimes has too many. and those we have do not work with every haskell implementation. and when they do work (usually with ghc, these days), they need to be rebuilt whenever ghc is updated, even if the gui lib hasn't changed at all (one gui lib binding per ghc version). still, we put up with that when we need all those gui lib features, because we have to, and we're happy to live in one of those periods when there are such bindings to full-featured gui libraries. You're right, that's annoying. It's particularly a problem for Windows GHC users who expect pre-built binaries, since GHC currently requires all libs to be rebuilt with each new minor GHC version. It's particularly annoying for GUI libs which are non-trivial to build from source (due to needing so many C header files and such) and so there is always a lag between when GHC gets updated and when someone (me) gets round to making a new binary build for Windows. Our hope is that we can get Gtk2Hs working with Yhc some day. That'd be interesting because it shouldn't have the same versionitis issues and the same compiled GUI program should run unaltered on Windows, Linux or OSX (and several others). but what about quick and dirty/cheap and cheerful graphics? over the years, HGL/SOEGraphics has served as a persistent reminder that things keep changing, and that when they do, something breaks. even if all people want to do is draw some simple graphics, or animations. There's a SOEGraphics implementation with Gtk2Hs, but then of course see problem 1. :-) i don't have a solution, but i'd like to throw another alternative into the ring, based on the ongoing fight between web browsers and other guis for world dominance.. [..] Sounds fun! :-) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] When is extra-libraries config in .cabal
On Fri, 2007-07-13 at 12:05 -0400, Edward Ing wrote: I am building and running some haskelldb/HDBC/HSQL libraries on Windows XP (using the MinGW minimals system (MSYS)) with GHC environment. I ran into runtime link problems, foreign functions would not found. eg. atoi,from C standard; recv from sockets. To solve the problem, I added dll's to the build configuration field extra-libraries, MSVCRT (c runtime), KERNEL32, WSOCK32 (sockets). This solved the problem. 1. But is there a better way to solve the problem? I am expecting that those libraries are available through the OS and do not need explicit loading. I am confuse by what does the loading of the libraries. 2. Does a UNIX/POSIX system not have this problem? On unix the C compiler generally links to the standard C library without you having to ask for it explicitly. I'm not sure that if we automatically linked to msvcrt that everyone would be happy. Many people seem to think msvcrt is to be avoided in preference of 'native' win32 calls. Information for understanding this problem would be great. This is a slightly tricky problem because the names of the libraries to link to are different on different operating systems. We don't have a proper solution to this at the moment. I'm posting this to the cabal-devel list in case anyone has any good practical realistic suggestions. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Gtk2Hs, Glade, Multiple windows/dialog in one interface file.
On Sun, 2007-07-08 at 16:40 -0400, Brandon S. Allbery KF8NH wrote: On Jul 8, 2007, at 16:36 , D.V. wrote: I finally got it to work with onResponse : I traced each possible response to see which one was fired when clicking the close button And what was the result? Great, another place where the documentation's wrong. :/ (onActivateLeaf vs. onActivateItem (and after- versions) also found to be wrong. Must submit a bug report at some point.) That would be most appreciated. Or even better would be to darcs send a patch with your suggested documentation improvements :-). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Nix for Hackage/Cabal
On Fri, 2007-07-06 at 16:47 +0200, apfelmus wrote: Hello, http://nix.cs.uu.nl/index.html Nix is a purely functional package manager. This means that it treats packages like values in purely functional programming languages such as Haskell - they are built by functions that don't have side-effects, and they never change after they have been built. To me, it sounds like the ideal solution to package/make/build management in general and Cabal/Hackage/Cabal-install in particular. After all, compilation is just a _pure_ function compile :: Source - Dependencies - Object So, the suggestion is to use Nix for Hackage/Cabal. This way, we get package installation/deinstallation for free. I didn't look into it, but it seems that the package description language can express most content from .cabal files and I guess that it even eliminates the need for most of Cabal's functionality like finding compilers and such. I was under the impression that it didn't work on Windows. From another quick look at the website, it looks like that's right. Does anybody happen to know otherwise? Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Binary serialization, was Re: Abstraction leak
On Fri, 2007-07-06 at 08:26 +0200, Ketil Malde wrote: On Thu, 2007-07-05 at 18:08 +0100, Duncan Coutts wrote: - Found that on hackage, downloaded and built OK. Lots of scary warnings about happy, greencard etc, not being found during configure, but let's go on. I've complained about these before, although I don't think anyone considered doing anything about it. We know what needs to change, but it's not a trivial change. The problem is that currently .cabal files to not specify what build tools they need, A possible stop-gap might be to only report the build tools that were actually found? The way it is now, it looks too much like an error message. Mmm, good point. Perhaps we could just change the verbosity of that message for now, so that it doesn't appear at the default verbosity level. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Binary serialization, was Re: Abstraction leak
On Thu, 2007-07-05 at 17:07 +0100, Paul Moore wrote: On 05/07/07, Bulat Ziganshin [EMAIL PROTECTED] wrote: * Gzip compress a data stream zlib * Send an email * Parse an ini file The one thing off the top of my head that Python had was Base64, but that's MissingH * Calculate the MD5 checksum of a file crypto Thanks. The need I had for these is no longer current, but sometime I'll try an experiment and see how easy it is, on a relatively clean Windows box with just GHC installed, to grab and use these libraries. Just to warn you, a lot of haskell packages that bind to C libs are much harder to get working on Windows, the zlib package for example. This is because on all other platforms zlib comes with the system and is installed in a location where any application can link to it. On Windows there is no equivalent of /usr/lib you cannot easily install a C lib somewhere that it can be used by any .exe on the system. To make things easier yuo could avoid using -fvia-C and then at least the zlib header files would not need to be installed, but to run a program that uses the zlib package you'd still have to copy the zlib.dll into the same dir as your .exe. There is a mechanism in newer versions of Windows that allows installing .dlls systemwide where any .exe can use them, however ghc and the gcc toolchain do not support them yet. It requires embeding xml manifests into the .dll and .exe files and you have to be the admin user to install one of these systemwide .dll things. It's all a bit of a pain. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Binary serialization, was Re: Abstraction leak
On Thu, 2007-07-05 at 17:39 +0100, Paul Moore wrote: I see you've already responded, and we're in broad agreement. So I won't labour the point. It's an infrastructure issue rather than a technical one, and it *will* improve. What will be interesting is how much the generally lousy Windows experience can be improved - We have this slightly odd problem where half our user base use Windows (according to the GHC user survey) but almost every active developer uses Linux or OSX (or a few other BSD/Unix OSs). So we could enormously improve the Windows user experience (and a few heroes work hard on doing just that) but basically there just aren't enough developers who use windows to give it a satisfactory level of support. This is of course a slightly circular problem, since using/developing Haskell on Windows is a pain, developers avoids it and so there are not enough developers irritated by how difficult it is to motivate developers to fix it! Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Sparse documentation
On Tue, 2007-07-03 at 15:11 -0400, Brent Yorgey wrote: Is there a reason why the documentation for virtually every module in Control.Monad simply begins with a line that says Inspired by some paper (http://www.ogi.edu/csee/~mpj/) It's probably because it was felt that the paper itself is better documentation than anything that could be written in the comments. Of course, this may or may not be actually true. It just seems to be a particular quirk of the way the Haskell community generates, disseminates, and consumes information. Actually, the code was documented in comments in the code, just not in haddock format. :-( Fortunately, some kind soul has gone through and converted the documentation to haddock format: http://hackage.haskell.org/trac/ghc/ticket/1410 So it'll all appear in the html docs in the next version. In the mean time one can look at the haddock comments in the source: http://darcs.haskell.org/packages/mtl/Control/Monad/ Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: Re: [Haskell-cafe] avoiding command window with wxHaskell on Windows?
On Fri, 2007-06-29 at 23:22 -0400, Dean Herington wrote: Date: Mon, 25 Jun 2007 20:19:50 -0400 With gtk2hs, using -optl-mwindows as a command line option for GHC lets me get rid of this window. Perhaps it will do the same for wxHaskell? Yes, that did the trick! Thanks a lot! But now I've discovered that using -optl-mwindows creates a program that doesn't work when invoked from a command line. Is there any way to create a program that can work when invoked either from a command line or through double-clicking? You'll have to be a bit more specific about what you mean. Perhaps you mean that when launched from the command line you cannot interact with the program via that command line interface. That is indeed standard windows behaviour. You can create new terminals at runtime using Win32 functions, but I'm not sure if you can figure out if the program was launched from a terminal and associate with that terminal. But perhaps you meant something else. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Collections
On Fri, 2007-06-22 at 15:34 +1000, Thomas Conway wrote: On 6/22/07, Duncan Coutts [EMAIL PROTECTED] wrote: You might find that lazy IO is helpful in this case. The primitive that implements lazy IO is unsafeInterleaveIO :: IO a - IO a Personally, unsafeInterleaveIO is so horribly evil, that even just having typed the name, I'll have to put the keyboard through the dishwasher (see http://www.coudal.com/keywasher.php). Also, I need to support concurrent querying and updates, and trying to manage the locking is quite hard enough as it is, without trying to keep track of which postings vectors have closures pointing to them! Ah yes, fair enough. If you're doing updates at the same time then lazy IO isn't appropriate as you need control over when the IO happens. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] haskell crypto is reaaaaaaaaaally slow
On Fri, 2007-06-22 at 10:52 +0400, Bulat Ziganshin wrote: i tried it once and found that ByteArray# size is returned rounded to 4 - there is no way in GHC runtime to alloc, say, exactly 37 bytes. and don't forget to add 2 unused bytes at average Right, GHC heap object are always aligned to the natural alignment of the architecture, be that 4 or 8 bytes. that i'm trying to say is that one need to store exact string size because value returned by getSizeOfByteArray is aligned to 4 Ah yes, you're quite right. To allow GHC's ByteArray# to be used to implement a compact string type it'd have to be changed to store the length in bytes rather than words. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] haskell crypto is reaaaaaaaaaally slow
On Thu, 2007-06-21 at 08:14 +0400, Bulat Ziganshin wrote: Hello Duncan, Thursday, June 21, 2007, 7:36:13 AM, you wrote: The smallest possible would be 2 words overhead by just using a ByteArray#, i tried it once and found that ByteArray# size is returned rounded to 4 - there is no way in GHC runtime to alloc, say, exactly 37 bytes. and don't forget to add 2 unused bytes at average Right, GHC heap object are always aligned to the natural alignment of the architecture, be that 4 or 8 bytes. Try the same experiment with C's malloc. I'd be very surprised if you can allocate 37 bytes and not end up using 40 (plus some extra for remembering the allocation length). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Collections
On Fri, 2007-06-22 at 09:38 +1000, Thomas Conway wrote: The actual case that I'm dealing with, where I believe Data.Map (or similar, incl finger trees) has a benefit is one in which it's not simply a case of lists of items, yielding a list of items. I'm manipulating an on-disk inverted index, so rather than a simple list of items, the code is actually monadic, doing IO to retrieve the items off disk, and the cost of creating the intermediate lists is unwearable. The key problem is that you loose the laziness because of the IO monad, so if you're not careful, you end up trying to store the complete intermediate lists. You might find that lazy IO is helpful in this case. The primitive that implements lazy IO is unsafeInterleaveIO :: IO a - IO a Note that using a Map will probably not help since it needs to read all the keys to be able to construct it so that'd pull in all the data from disk. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Reading/writing packed bytes from file
On Wed, 2007-06-20 at 09:54 -0400, Jefferson Heard wrote: What about the Data.Binary module from the Hackage database? I can call C, no problem, but I hate to do something that's already been done. The current version of the binary package does everything you want *except* for reading ieee float formats. So it's not suitable for you yet sadly. It's pretty obvious that lots of people need this so it'll probably get into the next version. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Haskell mode for emacs - some questions
On Wed, 2007-06-20 at 21:29 +0200, peterv wrote: Yes this was also very very confusing for me because I had the same idea about that. I almost gave up on learning Haskell because of that (I wanted to practice stuff from the SOE book using the latest versions), until I suddenly found out that GHC *did* work. Oh dear, if it's having that kind of effect I really had better fix it then :-) Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell crypto is reaaaaaaaaaally slow
On Wed, 2007-06-20 at 16:53 -0700, Stefan O'Rear wrote: On Wed, Jun 20, 2007 at 04:49:55PM -0700, David Roundy wrote: To expand on that terse (but very true) statement, a list of Word8 increases the space usage by a factor of probably around an order of magnitude (two pointers + 1 byte vs 1 byte), completely destroys your Three pointers. [ INFO PTR (like a tag but not quite) ] [ PTR to Word8 (these are hashconsed, thankfully) ] [ PTR to next value ] So that's 12 bytes on a 32bit box, or 24 or a 64bit one, to represent one byte of data. For comparison, ByteStrings have a bigger overhead but a lower linear factor: sizeof [Word8] of length n : 32bit: n * 12 64bit: n * 24 sizeof ByteString of length n : 32bit: 40 + n (or 32 + n for shared bytestrings like substrings) 64bit: 80 + n (or 64 + n for shared) Incidentally a more space efficient representation that could preserve the same operations speeds (like O(1) substring) would be: data ByteString = BS ByteArray# Int Int which would be 4 unshared words and 2 shared words rather than the current 5 unshared and 4 shared that we get from using ForeignPtrs. The smallest possible would be 2 words overhead by just using a ByteArray#, but that sacrifices O(1) substring which is pretty important for a functional style. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GTK2HS
On Thu, 2007-06-07 at 16:42 +0100, Andrew Coppin wrote: Neil Mitchell wrote: Hi Andrew, I just tried to install Gtk2hs and got an error message to the effect that it cannot be installed since I have GHC 6.6.1, which isn't 6.6 or 6.4. Anybody know how to fix this? Am I being dumb? After a new GHC release comes out, new Gtk2Hs packages are required. I usually find that pointing out that you can't use Gtk2Hs gives Duncan the motivation to put aside a little time to build the Windows installer. Ah. OK... Yeah, there'll be a new release and a Windows installer for GHC 6.6.1 when I get back from holiday. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
