immortal profiling
https://ghc.haskell.org/trac/ghc/ticket/10235#ticket Would be really useful to be able to profile code without dying, especially in the context of a long-lived server. Am I missing something that would allow me to do this? cheers mark ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] good lightweight web-framework like sinatra?
On Fri, Mar 23, 2012 at 10:37 AM, Conrad Parker con...@metadecks.orgwrote: On 23 March 2012 04:55, Mark Wotton mwot...@gmail.com wrote: Try Miku. https://github.com/nfjinjing/miku some oddnesses around redefining (-) (I guess Jinjing Wang doesn't like the way $ looks?) but you don't need to import the Air.Light stuff. Otherwise more or less a straight port of sinatra, and you can run it on heroku... Hi Mark, Is it possible to use Miku without hack2-handler-snap-server? Heya Conrad, not sure, I haven't tried. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] good lightweight web-framework like sinatra?
Try Miku. https://github.com/nfjinjing/miku some oddnesses around redefining (-) (I guess Jinjing Wang doesn't like the way $ looks?) but you don't need to import the Air.Light stuff. Otherwise more or less a straight port of sinatra, and you can run it on heroku... mark On Wed, Mar 21, 2012 at 1:45 PM, serialhex serial...@gmail.com wrote: i'm looking for something lightweight, that dosnt need it's own server, can easily run on cgi on an apache with minimal work, and dosn't have many dependancies. i was looking at yesod, but it is bigger than i need for my site (at this point) and would take too much work to get running on my webhost. though i am looking forward to learning it and using it in the future, i just need something that will play nicely with apache cgi... justin p.s. if anyone is interested to know i'm using nearlyfreespeach.net as my host... haskell is one of the many languages they support via cgi, but, at the moment, it is kind of difficult to get yesod or rails or the like to work on it... :-/ -- * The wise man said: Never argue with an idiot. They bring you down to their level and beat you with experience. * As a programmer, it is your job to put yourself out of business. What you do today can be automated tomorrow. ~Doug McIlroy No snowflake in an avalanche ever feels responsible. --- CFO: “What happens if we train people and they leave?” CTO: “What if we don’t and they stay?” ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] [ANN] majordomo-0.1.1
Sean Seefried and I have just released an implementation of the client and worker protocols for Majordomo, as specified at http://rfc.zeromq.org/spec:7 While it's not yet complete (the client won't try reconnecting, for instance, and has a hardcoded timeout), we're already finding it useful for ninjablocks.com The mdp_client executable is also useful for poking majordomo servers from the command line. http://hackage.haskell.org/package/majordomo https://github.com/ninjablocks/majordomo Cheers, Mark Wotton ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: pwstore 1.0 (Secure password storage)
If you're going to use C anyway, why not bind bcrypt? mark On 07/02/2011, at 2:13 PM, Peter Scott wrote: Hi everyone, If you need to store and verify passwords, the usual advice is to use bcrypt. It neatly handles all the security issues, with a simple API. But Haskell doesn't have bcrypt bindings, so people are tempted to roll their own password storage methods, and perhaps get it wrong. I decided to fix that. The pwstore library handles all the details of password storage for you, in a way that should be so easy to use that there's no reason not to use it. WHAT IT DOES You hash and salt passwords with one function, and verify user input against these password hashes with another function. For more information, see the API docs: http://hackage.haskell.org/packages/archive/pwstore-fast/1.0/doc/html/Crypto-PasswordStore.html HOW IT WORKS The basic algorithm is this: * Combine the user's password with a randomly-generated salt. * Hash this slowly. By iterating SHA-256 a few thousand times, we make brute-force guessing a lot less practical. * Store this has along with the salt. This scheme is essentially an implementation of the PBKDF1 key derivation function (as specified in RFC 2898) with some convenience code around it to make it easy to use and really hard to mess up. WHERE TO GET IT There are two packages on Hackage, which you can get with cabal-install: 1. pwstore-fast is the preferred version. 2. pwstore-purehaskell has the same API, but only pure Haskell dependencies. It's usable, but about 25 times slower than pwstore-fast. http://hackage.haskell.org/package/pwstore-fast http://hackage.haskell.org/package/pwstore-purehaskell The source code is on GitHub: https://github.com/PeterScott/pwstore/ Any comments, questions, or patches are welcome. -Peter ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] community server hasktags learned recursing into directories
On Sat, Feb 5, 2011 at 6:43 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 5 February 2011 10:14, Luke Palmer lrpal...@gmail.com wrote: I host all my modules on github. It is a very supportive environment for spontaneous collaborative development. c.h.o is a nice place, but lacks in maturity in comparison. As long as there is a complete, free place like github around, why not use it? 1) Github uses git, not darcs. Git is good enough for serious use. 2) I know who runs/controls c.h.o, but not github (so if something goes wrong...) If something goes wrong, the maintainer of c.h.o can commiserate with you about it being down. I suspect he/she doesn't have a large team of dedicated sysadmins to put it right, or a set of redundant servers. 3) Maturity? I can put darcs repos there, how mature does it need to be? integrated pull requests, commenting systems, notifications of updates, issue trackers... if you particularly want to use something else for each of these, that's fine, but it's nice to have a reasonable default. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: haskell-src-meta 0.1.0
Nice work, Ben - good to see someone's going to take it on in a slightly less half-arsed way than I was :) cheers mark On Thu, Aug 19, 2010 at 12:43 PM, Ben Millwood hask...@benmachine.co.uk wrote: Hello cafe, The haskell-src-meta package was originally written by Matt Morrow, to provide a translation from the syntax tree parsed from String by the haskell-src-exts package to Template Haskell's representation of Haskell source code, making possible a variety of interesting quasiquoters and metaprogramming. However, while the package was still fairly embryonic and incomplete, Matt disappeared from the haskell community, and his work no longer compiles with the latest versions of template haskell and GHC. Many people still had use for it, so there was some discussion about its future in a haskell-cafe thread [1] resulting in a fork [2]. After I and at least one other person duplicated the work of updating haskell-src-meta, ignorant of the fork, it was decided that maintaining forks was a less-than-ideal solution, so I volunteered to take up maintainership of a package that had by now been untouched for some ten months. Hence, haskell-src-meta-0.1.0, from a new maintainer (hello!). The functionality changes in this release are minimal, but nonzero: its primary purpose is to let the original work be used with updated TH. However, there have been some changes and additions since 0.0.6: * The previously somewhat lengthy Language.Haskell.TH.Instances.Lift is now mostly generated with template haskell using the th-lift package. * Contexts, kinds, bang patterns, unboxed word literals, newly supported in template-haskell-2.4.0.0, are used where necessary. * Use of haskell-src-exts is brought in line with newer versions. * Thanks to a patch by Jonas Duregard, a new ToDecs class has been added to handle cases where more than one Dec must be returned. I don't have any big plans for future releases: there is a lot that could do with tidying up, and some small aspects of the syntax conversion that aren't covered, but I mostly just intend to ensure it keeps building and that anyone with patches to contribute has a prompt response. How You Can Help: the easiest way is to tell me that I've put the version constraints too tightly on some dependency or other -- I have erred on the conservative side. Any other comments on the package in general are appreciated too, since this is the first time I've ever uploaded anything to Hackage. There is a github repository at http://github.com/benmachine/haskell-src-meta if you want to submit patches. Yours sincerely, Ben Millwood [1] http://www.haskell.org/pipermail/haskell-cafe/2010-July/080390.html [2] http://hackage.haskell.org/package/haskell-src-meta-mwotton __ -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On Wed, Aug 4, 2010 at 1:36 AM, Ben Millwood hask...@benmachine.co.uk wrote: On Sun, Jul 18, 2010 at 3:02 AM, Mark Wotton mwot...@gmail.com wrote: I've uploaded haskell-src-meta-mwotton, using the development version. It seems to work fine for my applications. It's a bit of a hack, but I can't think of a better way to do it for now. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe I've just come up against one of the drawbacks of this approach - having needed haskell-src-meta for a personal project, I downloaded the source and updated it to work with GHC 6.12, fixed various bits and bobs, and only now found out that much of that work had already been done elsewhere :) Matt Morrow has been missing for a long time and I think it's reasonable to suppose he won't suddenly spring out of the darkness to fix things for us. I propose that someone just take up maintainership of the package. I am quite willing to do this with my version, or Mark if you think you'd like to keep a closer eye on your dependencies you could do it instead. I further propose that we should write up a haskellwiki page about absent maintainers and what the community thinks is reasonable in terms of attempting contact before assuming them missing, presumed gone. This kind of depends also on how big an indignity we consider it to be if someone updates a package while the maintainer is just on holiday or something. So we need to decide on: first, who will take haskell-src-meta, and second, what we think is good as a more general policy. I would think the process would go something like: 1. email maintainer, wait 2 weeks for reply 2. email cafe and maintainers of reverse dependencies with proposed changes, wait a week or so for people who know the maintainer to show up or other people to object to your changes 3. chomp package I'm happy to let you do it, I don't understand much of the actual source. Not sure who's the grand gatekeeper of Hackage, though. Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Handling absent maintainers
On Thu, Aug 5, 2010 at 1:29 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 5 August 2010 13:23, Mark Wotton mwot...@gmail.com wrote: Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal. Huh? Cabal doesn't care who the maintainers are: it just has a text field where you list a maintainer[s]. See for example http://hackage.haskell.org/package/fgl-5.4.2.3 Currently, AFAIK Hackage allows anyone with an account to upload anything. Can you have two people uploading versions of the same package, though? Presumably it's not possible for me to upload a version of bytestring which makes monkeys fly out of your ethernet port when you try to concatenate strings. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Handling absent maintainers
That works fine for my own stuff, but I'd like it to work for people using my software that relies on those packages. mark On Sat, Jul 24, 2010 at 4:10 PM, Roman Beslik ber...@ukr.net wrote: I patch broken packages in my local repository. I increment a version so the local repository get a precedence over the Hackage. On 16.07.10 03:54, Mark Wotton wrote: 2. run my own hackage server and tell my users to use that instead. -- Best regards, Roman Beslik. -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] build and use ghc's rts without a full unregistered ghc port?
can't speak as to how difficult it is to get GHC built unregisterised, but you might want to consider JHC if you don't need to use a lot of Hackage. It compiles to C without a special RTS needed, which might make it a lot easier. mark On Sat, Jul 24, 2010 at 8:45 PM, Korcan Hussein korca...@hotmail.com wrote: Hi, I was just wondering if this is possible, I would like to use a gcc port which cross compiles to the PPC architecture (Wii DevkitPPC to be specifically: http://wiibrew.org/wiki/DevkitPPC) for a platform that is not POSIX compatible I believe (at least not fully or maybe I'm wrong entirely). Ideally I would make an unregistered port of GHC but the problem is because GHC doesn't support true cross compiling yet I need to bootstrap on to the target machine, which isn't running a POSIX environment. Still I did try to attempt to build with both the host and target set to 'powerpc-unknown-linux' and build it with devkitPPC, I did use a custom build.mk which should pull in all the required dependencies, defines, etc for devkitPPC. In the end I didn't get very far with it, it looked like missing posix functions. I didn't want to spend to much time trying to make it work this way (maybe i'm doing it wrong completely). It's quite possible that I could make this work more easily if I used a linux port for the wii but I would like to avoid the need of using linux on the wii because I guess most home-brew users don't have such a setup. So I thought maybe it's possible with less effort to build GHC's RTS and then compile Haskell in C with the RTS as a library dependency. Is this possible? maybe I'm missing something or doing something stupid? Thanks in advance. _ http://clk.atdmt.com/UKM/go/19780/direct/01/ We want to hear all your funny, exciting and crazy Hotmail stories. Tell us now___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal, Setup.lhs example
On Fri, Jul 23, 2010 at 12:33 PM, wren ng thornton w...@freegeek.org wrote: Magnus Therning wrote: On Thu, Jul 22, 2010 at 11:52, Ross Paterson r...@soi.city.ac.uk wrote: On Thu, Jul 22, 2010 at 11:31:21AM +0100, Magnus Therning wrote: On Thu, Jul 22, 2010 at 10:59, Ross Paterson r...@soi.city.ac.uk wrote: Magnus is building by directly running the Setup.hs himself, which ignores the Build-Type. To get cabal-install to use his Setup.hs, the Build-Type must be set to Custom. Oh, why*2? Why is the header there if it's not used by Cabal, and why does cabal care? The field allows cabal to avoid compiling the Setup.hs in this case. It might also be used by other tools, e.g. one might only trust Simple packages. Not all fields are used by all tools, and several of them do not affect the operation of the library (e.g. Home-page). All right, so why would cabal want to avoid compiling the Setup.hs? Of course this behaviour of cabal's means that I in the future will use *Custom* all the time, since I otherwise have to remember this surprising feature of a tool I never use. Is there any reason *not* to do this? The main reason I could think of to avoid compiling it is for performance reasons. I'm not sure how compelling that is, but... As for why not to always use Custom, as mentioned there are cabal-aware tools out there besides cabal-install. For these other tools, there is a big difference between Simple and Custom. With Simple we (ideally) already know all the semantics of what Setup.hs does, and so we can wire that into our tools. With Custom we're forced into the position of doing Haskell source analysis since we now have to discover the semantics of an arbitrary Turing machine. That's a very high wall to climb if you're just wanting to write a simple tool for doing some kind of package analysis. (I don't think the behavior is surprising since I interpret Simple to mean that the Setup.hs file is unused/optional. Though clearly YMMV) Ah, this clears up one of my bugs. Perhaps cabal should print a warning if you have a Setup.hs file, _and_ try to use Simple? It'd at least give the hint that they're unhappy together. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Handling absent maintainers
On Fri, Jul 16, 2010 at 10:54 AM, Mark Wotton mwot...@gmail.com wrote: Hello all, I've recently had problems with haskell-src-meta. While it's a great package, it doesn't currently compile on GHC 6.12, and Matt Morrow doesn't seem to be around to push the version that does to Hackage. Our one-world approach with cabal seems to discourage forking as a casual act, so when a package that others rely on goes AWOL, it's very awkward to fix it. I can think of a few ways to get around my current problems: 1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton, or something similar - this could be said to pollute the namespace, but would solve my immediate problem. I'd have to similarly specialise the chain of packages up to the one I actually want to use as well, though. I've uploaded haskell-src-meta-mwotton, using the development version. It seems to work fine for my applications. It's a bit of a hack, but I can't think of a better way to do it for now. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Handling absent maintainers
Hello all, I've recently had problems with haskell-src-meta. While it's a great package, it doesn't currently compile on GHC 6.12, and Matt Morrow doesn't seem to be around to push the version that does to Hackage. Our one-world approach with cabal seems to discourage forking as a casual act, so when a package that others rely on goes AWOL, it's very awkward to fix it. I can think of a few ways to get around my current problems: 1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton, or something similar - this could be said to pollute the namespace, but would solve my immediate problem. I'd have to similarly specialise the chain of packages up to the one I actually want to use as well, though. 2. run my own hackage server and tell my users to use that instead. 3. ... profit? Ideally, I'd like to be able to say something like cabal install my-hacked-package --as original-package - are there fundamental reasons that wouldn't be possible, or a bad idea? mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Handling absent maintainers
On Fri, Jul 16, 2010 at 11:49 AM, Jason Dagit da...@codersbase.com wrote: On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton mwot...@gmail.com wrote: Ideally, I'd like to be able to say something like cabal install my-hacked-package --as original-package - are there fundamental reasons that wouldn't be possible, or a bad idea? I haven't (yet) run into a completely AWOL maintainer. Usually I can contact the maintainer and offer to upload a new version for them. I'm currently in this role with Takusen. I'm not the Takusen maintainer, but I expect to be uploading the next version soon as it looks like I've been given permission. I've had this happen with a couple other packages and it was always a similar situation. Negotiate with the listed maintainer to do an upload on their behalf. I've found that offering to do the work for them usually helps tremendously. And it makes a lot of practical sense. This is great when it works, but it does add friction on top of the process of forking and experimentation. One of the things I've noticed in myself is that I'm much more likely to try something out if I can fork it, make my changes and start using it right away (including distributing easily to other users). If I have to wait to go through the gatekeeper, motivation has to be very high. One of the interesting consequences of cheap forking is that projects like the emacs starter kit have a very different model: it's designed to be forked, and to have the user's personal changes committed, so you can stay up to date without having to extract everything into a small set of config files. This is more or less impossible under the cabal model. Now, what you're proposing is interesting. I believe github/patch-tag have this model? Everyone has their own branch of everything they contribute to, listed right on the website? This is inline with another idea I've heard where we'd have a 'stable' hackage and 'unstable/dev' versions. But, how does this work for resolving and communicating dependencies? In terms of Cabal? I don't know enough about it to be authoritative. Conceptually, it seems clear enough: if you specify a variant package explicitly by name, that one gets used - if you don't specify a variant, use the canonical package. So long as forking is cheap and not socially awkward, this is fine: you fork the chain of packages you need to show that it all works, and submit a pull request to the maintainer of the real package. If he doesn't like it, fine - you can still use your changed version. It might be nice to be able to mark a variant as no longer relevant once the changes have been pulled into the parent repo, but it's a frill. On a philosophical note about cabal, cabal wants to be able to reason statically about the API (types, functions, modules) a package provides. So flags should primarily be used to configure platform specific bits necessary for compilation or implementation details, but not to change the API of a compiled library. From this point of view it seems to me that what your describing needs to be baked into either the package name or the version -- that is whatever cabal is going to look at during constraint satisfaction. Yes, I tend to agree. I like your idea and I'd like to hear more about how we could accomplish it within the philosophical framework that cabal already has. Me too.:) mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Australian Hackathon
On 16/03/2010, at 4:28 PM, Ivan Miljenovic wrote: Would other Australians be interested in having our own Hackathon (why should all those northerners have all the fun)? I'm thinking about organising it to be in the July break between university semesters. There was a previous consideration a few years back to have an OzHaskell group (http://www.haskell.org/haskellwiki/OzHaskell) but nothing seems to have eventuated out of it. In terms of projects, here are some ideas: * A plotting library using Ben's newly released Gloss library (for people who can't or won't install Gtk2Hs to get Chart working; Alex Mason is interested in this) * Various graph-related project (graphviz, generic graph class, etc.; this assumes someone else apart from me cares about this stuff) * Hubris if Mark Wotton comes along I'm keen. Would be be elated to have some help on Hubris, but happy to hack on other stuff too. Like Erik, weekends are probably better. mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] compiler management for Haskell a la RVM?
RVM (at http://rvm.beginrescueend.com) is a rather nice tool for managing multiple ruby installations - it gives support for switching between ruby environments (similar to gcc_select and friends), and also exporting lists of packages so that you can easily bring up a given set of gems in any of the interpreters. Do we have any similar system for ghc/cabal? I quite frequently find myself switching between 6.10 and 6.12 for various things, and it's always a bit painful to get your environment up to speed. Is there a golden road for this stuff, or do the compiler hackers here just munge the PATH? cheers Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling a shared library on MacOS X
There's a patch for it in GHC HEAD by Stephen Blackheath and me, and an accompanying patch for Cabal. http://hackage.haskell.org/trac/ghc/ticket/3550 http://hackage.haskell.org/trac/hackage/ticket/591 has the details. mark On Mon, Jan 4, 2010 at 10:36 AM, Ivan Miljenovic ivan.miljeno...@gmail.com wrote: If I recall correctly, dynamic linking/shared library support is not yet available for OSX, as the Industrial Haskell Group does not have any knowledge of OSX (but is willing to pay someone who does to do the work). 2010/1/4 Jean-Denis Koeck jdko...@gmail.com: Hello, I'm using the following cabal file to build a shared library with ghc: Build-Type: Simple Executable libmylibrary.dll If os(windows) CPP-Options: -DWIN32 Extensions: ForeignFunctionInterface Build-Depends: ... Main-Is: libmylibrary.hs Ghc-Options: -W --make -no-hs-main -optl-shared -optl-s -O2 The resulting library is called from a C++ graphical user interface (using Qt), which worked great so far on Windows and Linux. However, the compilation fails on MacOS X: Undefined symbols: _ZCMain_main_closure, referenced from: _ZCMain_main_closure$non_lazy_ptr in libHSrts.a(Main.o) ___stginit_ZCMain, referenced from: ___stginit_ZCMain$non_lazy_ptr in libHSrts.a(Main.o) ld: symbol(s) not found collect2: ld returned 1 exit status I don't know much about shared libraries, even less about them on MacOS X :( Any idea ? Jean-Denis Koeck ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com Joan Crawford - I, Joan Crawford, I believe in the dollar. Everything I earn, I spend. - http://www.brainyquote.com/quotes/authors/j/joan_crawford.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] ANNOUNCE: Hubris 0.0.2, the Ruby-Haskell bridge
The first vaguely usable version of Hubris is out on Hackage now. New stuff * now capable of building dynamic libs so that you don't need to have GHC installed on the production server. * extensible marshalling through a pair of typeclasses * automatically generated interface to Haskell from Ruby rather than the hacked-up manual packing/unpacking solution the first version had. For example: strings.rb: -- require 'hubris' class HsString hubris :module = 'Data.ByteString', :packages = ['bytestring'] end HsString.new.reverse(abcd) = dcba It requires the ghc 6.12 release candidate, and if you're on Mac, you'll need to apply the cabal patch at http://hackage.haskell.org/trac/hackage/ticket/591 and the ghc patch at http://hackage.haskell.org/trac/ghc/ticket/3550 You'll need to follow the installation instructions at http://github.com/mwotton/Hubris , as it needs a little extra info about ruby headers etc. Let me know if it works, if it breaks, if I've missed an obvious better way, if it's at all useful to you... Cheers Mark ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Re: Libraries for Commercial Users
On 11/10/2009, at 8:11 AM, Don Stewart wrote: brad.larsen: With this hypothetical ``import foreign jvm'' mechanism, what would the be type of imported Java stuff? Would it all be done in IO? The more I think about it, the trickier it seems. Beside the purity mismatch of Haskell and Java, there is an OO/functional mismatch. That's more of an issue. But the prior work has been done. At the risk of exposing my ignorance: would you recommend any particular papers? Hubris has a particularly restricted model of this, simply because I don't know how to approach it in a more comprehensive fashion. Cheers Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] killer app sought
Hi, I've been writing a little binding from Ruby to Haskell called Hubris (http://github.com/mwotton/Hubris ) which I think has some potential both for making Haskell web apps easier to write, and also for bringing the more adventurous Ruby programmers into the Haskell community. Code-wise it's coming along nicely, and once 6.12 is out it'll run without modifications at least on Linux (remains to be seen how long it'll take to get the Mac patches into shape). My real problem is marketing: I need a killer app that shows it's easy either to 1. wrap a kickarse Haskell library in a convenient Ruby web app shell 2. speed up a poorly performing Ruby web app I've been badgering the Ruby guys in Sydney that I know on the second point, but either none of them have performance problems, or none of them want to admit it. The first is entirely possible - if you only attack the subset of problems where your runtime is dominated by the database and network latency, language performance is moot. Conversely, if that's your worldview, the other problems that could be attacked won't ever come to mind (to monstrously abuse the Sapir-Whorf hypothesis). So, I'm asking you guys. What are some really nice Haskell libraries or apps that could benefit from being shown off in one of the plethora of slick, mature web frameworks that exist in Ruby? Manuel Chakravarty suggested something with vector operations in order to take advantage of his 'accelerate' library (once it gets a GPU backend, of course), and more generally, something taking advantage of Haskell's support for multicore would be cool. (The standard edition of Ruby is still unicore, I believe.) Parenthetically yours, Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] killer app sought
On 04/10/2009, at 4:22 PM, James Britt wrote: Mark Wotton wrote: So, I'm asking you guys. What are some really nice Haskell libraries or apps that could benefit from being shown off in one of the plethora of slick, mature web frameworks that exist in Ruby? Manuel Chakravarty suggested something with vector operations in order to take advantage of his 'accelerate' library (once it gets a GPU backend, of course), and more generally, something taking advantage of Haskell's support for multicore would be cool. (The standard edition of Ruby is still unicore, I believe.) I've been trying to think of a nice back-end app to run via a Ramaze Web front end, to combine the best of Ruby Web dev with the speed and elegance of Haskell. As mentioned, something that demonstrated multi-core-ability out of the box would be sweet. Some thoughts came to mind on image or audio manipulation, though details escape me.Or maybe text analysis. Showing that using Haskell is faster than using Ruby would be nice, but unimpressive, insomuch as people can already do that with C. So, a good example might also play off of the benefit of writing in Haskell instead of C. The interesting thing is speed _and_ safety, I guess. although writing fast C on multicore is arguably harder than in Haskell. The Parsec suggestion is interesting, but from the outside, it wouldn't seem significantly different to doing it in C. Maybe if you could specify your own grammars from outside? Hm. Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cal, Clojure, Groovy, Haskell, OCaml, etc.
If there's an Example section, it might actually be a good idea to include it on the package's hackage page, too. From a usability point of view, CPAN is much more helpful than the relatively spartan hackage description - if you're looking for a particular set of functionality, being able to filter out misses quickly is really nice. mark On 29/09/2009, at 1:11 PM, Hong Yang wrote: A Cook Book is good but relies on people specifically working on it. I think most of the package authors submit their packages because they themselves need the modules in his real world. I think package authors adding examples in the Descriptions section is a good start when they submit their packages. You do want to facilitate people understanding and using your modules, right? Maybe later on we can add an Example section to Description, Synopsis, and Documentation sections produced by Haddock. Also, having a section for comments is helpful. This is the case especially when there are several similar packages coexisting, comments can help people choose which one to use. Thanks, Hong On Mon, Sep 28, 2009 at 9:55 PM, Casey Hawthorne cas...@istar.ca wrote: On Mon, 28 Sep 2009 21:50:14 -0500, you wrote: Good libraries are not enough for a language to go beyond mere existence. There must exist good documents, i.e., good tutorials, good books, and good explanations and examples in the libraries, etc, that are easy for people to learn and use. In my humble opinion, Haskell has a lot of libraries, but most of them offer few examples of how to use the modules. In this regards, Perl is much much better. Good thought! Is there a good way to add Haskell examples to the libraries? A Haskell CookBook might be just the ticket, also. -- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do I have this right? Remembering Memoization!
On 14/09/2009, at 9:28 AM, Casey Hawthorne wrote: Do I have this right? Remembering Memoization! For some applications, a lot of state does not to be saved, since initialization functions can be called early, and these functions will remember - (memoize) their results when called again, because of lazy evaluation? You don't get memoisation for free. If you define a variable once in a where block, it's true that you'll evaluate it at most once, but if you repeatedly call a function foo that then calls bar 12 each time, bar 12 will be evaluated once per foo call. Cheers Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can GHC produce dylib on MacOSX/Intel?
On 02/09/2009, at 8:09 PM, Pavel Perikov wrote: Is it possible? Is it possible with binary distribution? My understanding: It was possible with ghc 6.8. It's not with 6.10. Duncan's managed to get it going at some point on Linux (I assume) with GHC HEAD (http://blog.well-typed.com/2009/05/buildings-plugins-as-haskell-shared-libs/ ). I haven't been able to replicate that on either Mac or Linux, but getting HEAD working is always slightly iffy. It does work with jhc rather nicely, but most libraries don't build with jhc, sadly. If anyone's got it going, I'd be really keen to know. mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Slow IO?
On 02/09/2009, at 2:26 PM, Eugene Kirpichov wrote: I've got a Centrino Duo 2000 (I'm on a notebook), Ubuntu 9.04 and ghc 6.10.2. However, we have not set up on what exact input file we're using :) I'm using one where it is written 1000 3 and then 1000 lines of 9 follow. Also, I wonder what one'd get if one compiled this program with jhc, but I don't know whether jhc is able to compile Data.ByteString. It couldn't last time I tried - choked on some INLINE pragmas. Might not be a massive job, but there aren't enough hours in the day... mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Examples
On 10/08/2009, at 9:29 AM, John D. Ramsdell wrote: Usually I include the example program in the package, but make its compilation conditional using a Cabal flag like buildExamples. But then the binaries generated from the example program get installed. I think the poster wants to share the source code, not install a demo. I haven't figure out a way to specify test programs that don't get installed, but are only intended to be built and run within the context of a source distribution. Couldn't resist a chance to spruik TBC (Testing By Convention) http://hackage.haskell.org/package/TBC - it's a framework Pete Gammie and I are developing to run tests in Haskell. In addition to a few other neat features like not having to write boilerplate main functions by way of some conventions about how to run tests, it knows enough about Cabal to use the package information etc to link your tests together, and provides a command line tool (tbc) to run your tests and provide a report. If you use it and it's helpful to you, or you have any suggestions for how it could be improved, please let me or Pete know. Cheers Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell embedded
On 09/08/2009, at 11:24 AM, Kevin Smith wrote: Hello, Could someone point me in the the direction of any references for using Haskell as an embedded language in an application. Xmonad seems to come to mind because the configuration files are written using Haskell. Any other information ? Thanks in advance. In a Haskell application or a foreign one? Xmonad and lambdbabot are probably not bad places to start looking at methods to load new Haskell at runtime into a Haskell process. If you're looking at embedding it in a C program, http://www.haskell.org/haskellwiki/Calling_Haskell_from_C is helpful, although it does require that you compile everything together at one time. I've been looking into ways to load haskell code into Ruby programs at run-time lately, which you can check out at shimweasel.com if you like. Briefly: dynamic library support doesn't work in ghc 6.10.1 at the moment, although it has at some point worked in GHC HEAD. I'm unable to get HEAD to build with --enable-shared on either Mac or Linux currently, you might have better luck. mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A typeclass for Data.Map etc?
On Thu, Feb 19, 2009 at 9:51 PM, Eugene Kirpichov ekirpic...@gmail.com wrote: Greetings, Is there a typeclass for mappings with a Data.Map-like interface, with stuff like: empty, insert, insertWithKey, unionWith etc. ? And, probably, a similar typeclass for mutable mappings like Data.Hashtable. Looks like such a thing would be useful; as for now, I see at least two applications: Data.Map and Data.Trie (bytestring-trie) - it's a pity that they have rather similar interfaces, but the latter lacks many methods and some are named in a different way. Also, Data.Map has some inconsistensies, too: for instance, it has an insertWith' but lacks a unionWith'. One typeclass for all would eliminate these inconsistencies. I'm asking mainly because I've been wondering why noone has yet written a mutable hashtable package with a MArray-like interface, I wrote a small thing myself and I am unsure as to what interface it should have. Probably not adding anything terribly useful to this except to say that it'd be useful to me too - I've written a binding to a perfect hashing library (PerfectHash on hackage) which implements only 'fromList' and 'lookup', so a slightly more fine-grained type class hierarchy would be nice. (This particular implementation is useful when you have a lot of keys, but all known at run-time.) Mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can this be done?
On Thu, Feb 12, 2009 at 12:41 AM, Cristiano Paris cristiano.pa...@gmail.com wrote: On Wed, Feb 11, 2009 at 2:30 PM, Peter Verswyvelen bugf...@gmail.com wrote: I haven't looked at the details, but I think this is what a library like Reactive from Conal Elliott could do, but as far as I understand it, it is still work in progress. I'm interested in the possibility of stopping/pickling/unpickling/resuming a computation. I've been looking into something similar... currently, my best option is looking like deliberately causing a core dump and editing the core file to run as a binary (or even more hackishly, just using gdb.) If there's a less filthy way to do it, I'd love to hear about it. (I know about Data.Binary, but it seems inelegant to have to write out instances for something that exists already in memory - you should be able to just blat it back in.) Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Haskell problem
Hi, I'm trying out some combinatorial parsers, and I ran into a slightly inelegant construction. To parse a sequence of things, we have a function like pThen3 :: (a-b-c-d) - Parser a - Parser b - Parser c - Parser d pThen3 combine p1 p2 p3 toks = [(combine v1 v2 v3, toks3) | (v1, toks1) - p1 toks, (v2, toks2) - p2 toks1, (v3, toks3) - p3 toks2] The problem with this is that this structure has to be duplicated for pThen2, pThen4, and so on. These other forms are very similar to pThen3, but there seems to be no way to capture this in Haskell's type system, as the combine function has a different signature for each pThenX. (This is actually the first time the Haskell type system has got in my way rather than helping.) Is there a way around this problem? mrak ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
