[Haskell] ANN: Hacanon 0.1
What is Hacanon? Hacanon is a Template Haskell library which automates the process of binding Haskell to libraries written in C++. It's designed to capture common patterns and allow the programmer to specify the desired behaviour accordingly. Hacanon is capable of generating a usable binding, without any interaction, to almost any piece of C++. This binding is of relatively high level, because Hacanon translates enumerations to Haskell data structures, has transparent callback support and overloads every function. Unfortunately, such a binding would, in most cases, be flawed. Is 'int*' an array, variable which holds a second result or something third? Here Hacanon provides a data interface scheme (aka DIS) system which allows the programmer to concisely describe how an argument should be handled. DISs can be derived from other DISs because they're nothing more than data structures. This gives rise to increased code reuse and minimizes the burden on the programmer. These DISs can be used in the appliance system where the programmer can guard on function name (via regex), argument type and argument number. Some of the features sound familiar. Is Hacanon related to GreenCard or HDirect? I've borrowed the DIS concept from GreenCard and directional arguments from HDirect. I would like to think I've taken the best of both worlds and added some innovation in form of automation. Dependencies: * Recent version of GHC. Tested with ghc-6.4.20050209 and ghc-6.4.20050219. http://www.haskell.org/ghc * HaXml 1.12. http://www.cs.york.ac.uk/fp/HaXml/ * GCCXML from CVS hacked to include template information. Hack is distributed with Hacanon. Author and availability: Hacanon is written by David Himmelstrup and published under a MIT-style license. Darcs repository: http://www.scannedinavian.org/repos/hacanon/ -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANN: Hacanon 0.1
On Mon, 21 Feb 2005 13:47:02 +0100 (MET), Henning Thielemann <[EMAIL PROTECTED]> wrote: > So I ask again, what I always ask: Is there someone working on a Haskell > backend for SWIG? Not that SWIG is outstandingly well organised, but it > provides an extensive framework for several odd C++ features. Once I have > prepared a SWIG wrapper description say for Modula-3 I could faster add a > wrapper for Haskell. SWIG was one of the first I looked at but something about it turned me off so badly. But comparing the two ways of doing the same thing would be neat so send me mail once your finished. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Proposal: Allow "\=" for field update in record update syntax
On Fri, 4 Mar 2005 15:26:52 +0100, Benjamin Franksen <[EMAIL PROTECTED]> wrote: > On Sunday 20 February 2005 14:19, Keean Schupke wrote: > > TH has supported multi-parameter classes for a while... new in 6.4 is > > support for fundeps. > > Yes, but unfortunately TH cannot create instances for them which is usually > the boilerplate you want to avoid. From Language.Haskell.TH: > > data Dec = > ... > ClassD Cxt Name [Name] [FunDep] [Dec] > InstanceD Cxt Type [Dec] > ... > > Only one 'Type' can be given for an instance. And there _should_ only be one type. Checkout 'appT'. Some real documentation for TH would clear misconceptions such as this. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] URLs in haskell module namespace
On Mon, 21 Mar 2005 23:06:25 +0100, Sven Moritz Hallberg <[EMAIL PROTECTED]> wrote: > Greetings Alexander, > > I have been thinking about something very much similar for some time. > But: > > Am 21. Mrz 2005 um 21.47 Uhr schrieb S. Alexander Jacobson: > > > As I move from machine to machine, it would be nice not to have to > > install all the libraries I use over and over again. I'd like to be > > able to do something like this: > > > > import http://module.org/someLib as someLib The extra complexity outstrips the gain since installing a package will soon be as easy as this: 'cabal-get install myPackage'. Checkout the Cabal/Hackage project. > I'm not sure a URL is the right thing to use. For instance, what about > the http part? In the end, the URL gives a certain location for the > module, which might change. Programs using the module should not become > invalid just by movement of the dependency. > > > > If the requested module itself does local imports, the implementation > > would first try to resolve the names on the client machine and > > otherwise make requests along remote relative paths. > > > > If would be nice if implementations cached these http requests and did > > If-Modified-Since requests on each compile. If the document at the > > URL has been modified it might show the diff and ask the user if it is > > appropriate to upgrade to the new version. > > Exactly. I think, even, that this kind of handling is what we _need_. I > routinely feel, in writing my own modules, the hassle of questions like > "how do I package this?". It would be much easier and accessible to > just put my modules up one by one on the Web, advertise them (by > posting the documentation, preferably ;)) and know that people's GHC or > whatnot will just auto-fetch them. This is exactly what Cabal and Hackage is solving. > The next thought of course is versioning. To make sure my Haskell > system gets the version I meant when I wrote my program, modules need > version numbers. I'd propose the following. > > module A [1,5.2] (...) where ... > > The bracketed expression after the module name is an interval of > interface numbers: This version of the module exports interface 5.2, > the decimal indicating the second revision since no. 5. The module > further declares to be backwards-compatible with all interfaces down to > version 1, inclusively (i.e. they form a sequence of subsets). Nota > bene this scheme is the same as that used by GNU libtool (although > libtool explains it much too complicated). > > A module author would start with interface 1 (i.e. write [1,1]) and > upon changing the module: > > - If the change was only a code revision with no interface or semantic > changes at all, raise the fractional part, e.g. [1,1.1] > - If there was any change in the module exports, or the semantics of > existing exports, raise the interface number (upper bound) to the next > integer, e.g. [1,2] > - If the change broke compatibility with the last version (i.e. > removed or changed any of the existing exports), snap the lower bound > up to reduce the interval to a single element again, e.g. [3,3]. > > import A 2 (...) > > The import statement includes a single integer interface number which > is the number of the interface this module was written against. It > indicates that any version of module A whose interface interval > contains 2 is compatible. Cabal is using package based versioning and you can show/hide packages. > Obviously, the Haskell system should be able to provide some > convenience for managing the interface numbers. It should also be > possible to devise a smart way of handling omitted interface info (both > on the ex- and import side). > > Finally, one will wish for a system of providing adaptor modules to > interface old importers to new versions of their importees. That way, > interfaces can be evolved rapidly because backwards-compatibility need > not be retained, as long as one provides a suitable adaptor (to be > auto-installed by an importing system). In such a setting, the simple > "latest compatible interval" approach also becomes sufficient to handle > even strong interface fluctuation because gaps can always be bridged > with adaptors. You don't need a new package system for this. > Does this make sense? I understand your desire but all of this can/will be handled by Cabal and Hackage. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] URLs in haskell module namespace
On Mon, 21 Mar 2005 22:06:25 -0500 (Eastern Standard Time), S. Alexander Jacobson <[EMAIL PROTECTED]> wrote: > Lemmih, > > The current Haskell/Cabal module and packaging system is substantially > annoying for the typical non-sysadmin end-user. In particular, if > they move their code to another machine they have to do a bunch of > different administrivia including: > >1. knowing the source package for each module used in their code > even if they didn't insall the packages in the first place i.e. > import Foo.Bar just worked on my development machine. I'm not sure I completely understand what you're saying but knowing the exact URL for every single module import seems more of a hassle than installing a few packages. You could perhaps even make a shell script containing 'cabal-get install package1 package2 ...'. >2. knowing the current location of those packages even if they > didn't obtain them for installation on the original machine > where they used them and aren't on the mailing list for them. I assume you meant something like "The developer don't know where to find the packages". The location of the packages is irrelevant to the developer since it's handled by Cabal/Hackage. >3. going through the hassle of doing a "cabal-get install" for each > of them once they have figured it all out. See the above mentioned shell script or cabalize your software. > I'd rather have a system that takes care of 1-3 for me and just > reports errors if particular modules are irretrievable. > > That being said, Cabal definitely solves a lot of problems that my > original proposal left unaddressed (e.g. producing executables needed > to build modules, handling C code, versioning?). Perhaps the correct > answer is to import Cabal packages rather than haskell source e.g. > >import http://package.org/package-1.0.cabal#Foo.Bar as Baz >import http://package.org/package-2.0.cabal#Foo.Bar as Baz2 >--note use of HTTP fragment identifier for module name Requiring Haskell implementations to honor this would be very bad, IMHO. A preprocessor which looks for package pragmas ({- USE somepackage -} perhaps) and install those packages via Cabal would be way easier to hack. But then again, a small script to fetch the packages or a .cabal file would be even simpler. > And a big bonus here is we get a simple solution to the problem of > Haskell's global module namespace. There was a problem with module name spaces? Wouldn't there only be a problem if two packages used the same module name for different functionality? > Now module namespace is local to > individual packages. > > If cabal also has a "cabal-put package MyPackage http://myhost.com/dir"; > then we have a really simple and beautiful system for sharing > libraries over the Internet as well! This is essentially what Hackage does. > If the change of import syntax is blessed by the powers that be, would > it be hard to adapt Cabal to work like this? Extending the Haskell syntax to include something which could easily be handled by a preprocessor would be inadvisable. > -Alex- > > __ > S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com > -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] URLs in haskell module namespace
On Tue, 22 Mar 2005 06:40:02 -0500 (Eastern Standard Time), S. Alexander Jacobson <[EMAIL PROTECTED]> wrote: > Proposal restatement: > > Import statements should be allowed to include URL of Cabal packages. > Module namespace in these import statements should be with respect to > the package and not the local environment. e.g. these import > statements allow us to import two different versions of Network.HTTP > >import http://domain.org/package-1.0.cabal#Network.HTTP as HTTP >import http://hage.org/package-2.1.cabal#Network.HTTP as HTTP2 > --note use of HTTP fragment identifier for module name > > Advantages: > > * Simplified place for user to track/enforce external dependencies. > > If you are using non-standard modules, you had better know where they > came from and how to get another copy. This proposal provides a sane > way to do that (see below). > > * It makes it easy to move code between machines. > > The implementation takes care of retreiving and building the packages > automatically and as necessary. There is no need for a separate > retrieve/build/install cycle. > > * Eliminates the horrible globality of Haskell's module namespace > > You can use two modules with the same name and different functionality > and you can use two modules that use different versions of the same > module. (see below). > > * Users no longer need to think about package installation scope. > > Package installation is with respect to the current use. Whether > multiple users are able to share the same installation is up to the > installation. User's can't infest the machine's local namespace by > adding new packages. > > On Tue, 22 Mar 2005, Lemmih wrote: > >>1. knowing the source package for each module used in their code > >> even if they didn't insall the packages in the first place i.e. > >> import Foo.Bar just worked on my development machine. > > > > I'm not sure I completely understand what you're saying but knowing > > the exact URL for every single module import seems more of a hassle > > than installing a few packages. You could perhaps even make a shell > > script containing 'cabal-get install package1 package2 ...'. > > I am assuming that I may want to move my code to another machine and > that therefore I need to keep a record *somewhere* of the source > package of every module I actually use. If I don't, then moving will > be much more difficult. Yes, keeping track of these packages is a > hassle, but I don't see how it can be avoided. > > Once I am keeping track, the *somewhere* that it makes the most sense > to me to do so is the point in the code where I am importing the > module. That way the implementation can enforce correspondence and if > I stop using the module, the package dependency automatically > vanishes. > > Doing this sort of work in a separate script strikes me as a > maintenance headache and means that all modules I use have to coexist > in a shared namespace which seems likely to create more headache. > > >>2. knowing the current location of those packages even if they > >> didn't obtain them for installation on the original machine > >> where they used them and aren't on the mailing list for them. > > > > I assume you meant something like "The developer don't know where to > > find the packages". > > The location of the packages is irrelevant to the developer since it's > > handled by Cabal/Hackage. > > I don't understand. Are you saying that there will be only one > Hackage server ever and it will have all information about all > packages everywhere and that the location of this hackage server will > be hard coded into every cabal implementation? Hackage and (the soon to come) cabal-get are tools layered on the Cabal but they are not a part of it. Hard coded URLs are evil in almost every context, IMHO. But defaulting to some server when the user hasn't specified otherwise would greatly increase the ease of use. > If so, I find that vision incredibly unappealing. I believe there > should/will be multiple hackage servers with carrying different > hackages under control of different parties (e.g. a corporation might > have one for its own private code). The idea with Hackage was to create a central place for people to put software or links to software, so keeping only one server for free (as in beer) packages would be desirable. However, this does in no way limit how Hackage can be used for private code repositories. > And, if there are multiple hackage servers, we are going to need to > indentify the serv
Re: [Haskell] Announce: Haskell Server Pages 0.2
On 5/13/05, Niklas Broberg <[EMAIL PROTECTED]> wrote: > == Haskell Server Pages == > > Release early, release often. I know, I know, but better late than > never, so here it is: > > Haskell Server Pages (HSP), a Haskell-based language for writing > dynamic web pages. > Webpage and darcs repo available at http://www.cs.chalmers.se/~d00nibro/hsp > > Features: > * Embedded XML syntax > * A (low-to-mid-level) programming model for writing dynamic web pages > * A runtime system, in the guise of a server utility, with support for: > - session (through cookies) and application (through the server) state > - interfacing to the HTTP request-response model > - on-request compilation of pages (using hs-plugins) > * A cgi-handler utility for use where the server can't be used (i.e. > if you have no control over the resident web server). Supports > everything the server does except application state and setting > outgoing headers (plus it is atm considerably slower to respond). > > Things not working yet: > * The server /only/ handles .hsp-pages (i.e. no images or the like), > as it is intended to work as a plugin to general-purpose servers like > Apache or HWS that should handle any other file types. To properly > plug the HSP server in, I (or someone else so inclined) need to write > bindings to such servers, currently the server utility only works in > stand-alone mode. > * No support for POST data yet. > * Session handling needs improvement, currently session ids are > generated from 1 up (I thought the hashUnique function had a more > spread-out distribution...). > * Probably a lot more things that I cannot remember right now. > > Things sorely missing: > * Libraries, libraries, libraries and more libraries. > * A "nice" model for continuations. > > Comments, critique, patches or whathaveyou most welcome. I'm having problems building hspr from the darcs repo. The HSPR.CGI.ErrorHandler module seems to be missing. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] HaskellForge
On 5/13/05, Gour <[EMAIL PROTECTED]> wrote: > Dear Haskellers, > > I'd like to suggest one idea which is going on in my mind for quite some > time... > > Recently the project where I am offering some help (gtk2hs) had to move > part of its web site from SourceForge to haskell.org since SF site has > some limits which we were not able to overcome. > > So, why not form HaskellForge and thereby form powerful Haskell > alliance, ie. common site which can host many/most present Haskell > projects offering appropriate web & other (eg. darcs) services? > > If we take a look on new HCAR, we can see that many Haskell projects are > scattered all around, so it would be nice to have them on one place. > > Ruby (which is not so long around, at least in the Western part) has > RubyForge site which at the moment hosts 653 projects with 2159 > registered users. > > Then there is also, Ruby Application Archive (RAA) with 1190 projects. > > Haskell community is a very friendly one and has lot of brain-power on > disposal. Why not add some (more) organizational skills to make it even > more friendlier place? > > Any comment? I'm currently working on Hackage[1] plus its integration with Cabal, and extending it to include SourceForge-like features would definitely be desirable. It is, however, a one-man project so don't hold your breath. -- Friendly, Lemmih [1] http://haskell.galois.com/cgi-bin/hackage ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] HaskellForge
On 5/17/05, Lemmih <[EMAIL PROTECTED]> wrote: > On 5/13/05, Gour <[EMAIL PROTECTED]> wrote: > > Dear Haskellers, > > > > I'd like to suggest one idea which is going on in my mind for quite some > > time... > > > > Recently the project where I am offering some help (gtk2hs) had to move > > part of its web site from SourceForge to haskell.org since SF site has > > some limits which we were not able to overcome. > > > > So, why not form HaskellForge and thereby form powerful Haskell > > alliance, ie. common site which can host many/most present Haskell > > projects offering appropriate web & other (eg. darcs) services? > > > > If we take a look on new HCAR, we can see that many Haskell projects are > > scattered all around, so it would be nice to have them on one place. > > > > Ruby (which is not so long around, at least in the Western part) has > > RubyForge site which at the moment hosts 653 projects with 2159 > > registered users. > > > > Then there is also, Ruby Application Archive (RAA) with 1190 projects. > > > > Haskell community is a very friendly one and has lot of brain-power on > > disposal. Why not add some (more) organizational skills to make it even > > more friendlier place? > > > > Any comment? > > I'm currently working on Hackage[1] plus its integration with Cabal, > and extending it to include SourceForge-like features would definitely > be desirable. It is, however, a one-man project so don't hold your > breath. Correction: I'm the only one who hacks on Hackage. Much of the design and administration is handled by Isaac Jones (aka SyntaxNinja). Apologies to anyone who might have contributed somehow without being credited. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] HaskellForge
On 5/21/05, Sven Panne <[EMAIL PROTECTED]> wrote: > Lemmih wrote: > > I'm currently working on Hackage[1] plus its integration with Cabal, > > and extending it to include SourceForge-like features would definitely > > be desirable. It is, however, a one-man project so don't hold your > > breath. > > I had a look at RubyForge, and it looks very much like a modified GForge > (http://gforge.org/). Might this be an option for HaskellForge, too? Someone would have to hack support for Darcs and HaskellDB in PHP and that someone will not be me. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] HaskellForge
On 5/21/05, Sven Panne <[EMAIL PROTECTED]> wrote: > Lemmih wrote: > > On 5/21/05, Sven Panne <[EMAIL PROTECTED]> wrote: > >>I had a look at RubyForge, and it looks very much like a modified GForge > >>(http://gforge.org/). Might this be an option for HaskellForge, too? > > > > Someone would have to hack support for Darcs and HaskellDB in PHP and > > that someone will not be me. > > I understand the need for Darcs, but why HaskellDB? Just curious... HaskellDB might not be necessary if GForge already has some way for clients to query the database. > And I wonder how much effort that would be, anyway, compared to the rest of > GForge. I agree that we could benefit from using GForce but we still have to find a guy willing to hack PHP. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell SOE Question
On 7/27/05, Alex Edelsburg <[EMAIL PROTECTED]> wrote: > > Hello! > I'm a student in Professor John Peterson's Elements of Computing (class > site located here: http://cs.yale.edu/cs110-05) and he's having me learn > Haskell with Paul Hudak's SOE book. I'm working on the PaddleBall in 20 > lines at the end of Chapter 15 and I'm having a problem with HUGS. I > downloaded the version from > http://haskell.org/soe/software.htm which is recommended > but I'm still having trouble. I copied the code verbatim from the book and I > still get the following error. > > ERROR "Animation.hs" - Unknown entity "word32ToInt" imported from module > "Word" 'word32ToInt' is 'fromIntegral' now. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] do notation and type synonym
On 8/7/05, mt <[EMAIL PROTECTED]> wrote: > hi, > > first one : > i've read in different places that "there is nothing magic with do" > and that > > do { x <- m ; return x } > > is the *same* as > > m >>= \x -> return x > > however i've came up with : > > m :: Maybe Int > m = return 4 > > check5 = do { 5 <- m ; return 0 } > check5' = m >>= \5 -> return 0 > > the first check5 is ok and return Nothing while the second check5' will raise > an "Exception: Non-exhaustive patterns" (which is what i've expected). > > the sentence "there is nothing magic with do" with its reason are important > for me to understand monads and do notation, so maybe someone can rephrase > "there is nothing magic with do" and explain the exposed behavior? Read http://www.haskell.org/onlinereport/exps.html, section 3.14. > second one: > is it possible to write something like > type Point = (Float, Float) > type Vector = (Float, Float) > and still have type safety (i.e. not be able to mix Point and Vector) (and > still have (*,*) without constructor)? No, that's not possible. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: ghc-src version 0.2.0
ghc-src 0.2.0 has been released. ghc-src is a Haskell parser with full support for every GHC extension. It is a refactored version of the Haskell parser used internally by GHC and is meant as a replacement for haskell-src-exts, although it might have other uses. The package is cabalized and lives under Langauge.Haskell.GHC.* in the module hierarchy. Darcs repo: http://scannedinavian.org/~lemmih/ghc-src/ -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: ghc-src version 0.2.0
On 8/23/05, John Meacham <[EMAIL PROTECTED]> wrote: > On Tue, Aug 23, 2005 at 04:10:51PM +0200, Lemmih wrote: > > ghc-src 0.2.0 has been released. > > > > ghc-src is a Haskell parser with full support for every GHC extension. > > It is a refactored version of the Haskell parser used internally by > > GHC and is meant as a replacement for haskell-src-exts, although it > > might have other uses. > > The package is cabalized and lives under Langauge.Haskell.GHC.* in the > > module hierarchy. > > > > Darcs repo: http://scannedinavian.org/~lemmih/ghc-src/ > > ooh. neat. any chance it could be extended to preserve haddock comments > and attach them to the right places? I thought it would be really cool > if compilers could use the haddock documentation when printing out error > messages and be able to query documentation as well as type info from > inside the interpreter. Parsing Haddock comments would be pretty easy. However, compilers probably wont find ghc-src very usable since it has no placeholders for post-parsing information (such as inferred types). -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: ghc-src version 0.2.0
On 8/24/05, Krasimir Angelov <[EMAIL PROTECTED]> wrote: > 2005/8/24, John Meacham <[EMAIL PROTECTED]>: > > ooh. neat. any chance it could be extended to preserve haddock comments > > and attach them to the right places? I thought it would be really cool > > if compilers could use the haddock documentation when printing out error > > messages and be able to query documentation as well as type info from > > inside the interpreter. > >John > > I think that it could be more useful to preserve all comments. Haddock > can filter out only the haddock style comments but there are tools > that use another style of comments. I can't really imagine what the AST would look like if it should support comments in arbitrary places. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCEMENT: HAskell Server Pages version 0.3.0
== HAskell Server Pages == HASP is an experimental framework for combining the flexibility of Haskell with the popularity/necessity of web-pages. HASP offers you an embedded XML syntax, without you having to dispense with any of the Glasgow Haskell extensions we hold dear. By using the FastCGI library, HASP has obtained Independence of server type while keeping performance at a max. HASP supports dynamic loading of Haskell code, sessions, persistent values of arbitrary types, POST data and file uploads, and thus provides a sound foundation for the creation of high level programming models for writing dynamic web-pages. A few features have yet to see the light of day: Session storage should be at the users discretion, and supported reconfiguration of HASP at run-time are possible improvements. While HASP isn't in it self a high level programming model for designing dynamic web-pages, it does provide a sound foundation for the creation of such. HASP: darcs get http://scannedinavian.org/~lemmih/hsp FastCgi: http://fastcgi.com/ I would appreciate any feedback. -- Friendly, Lemmih PS: I owe great thanks to Niklas Broberg for his excellent work on HSP. In truth, the idea of combining XML and Haskell I have through him, and I also adapted much of his code. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: ghc-api 0.1.0
I'm pleased to announce ghc-api 0.1.0, a cabalization of the ghc api, plucked from ghc 6.5, making the api available for stable versions of ghc. The ghc-api 0.1.0 has been developed as a part of the running hIDE project, and has so far been succesfully built with ghc 6.4 and 6.4.1. [1] ghc-api: http://scannedinavian.org/~lemmih/ghc-api [2] hIDE: http://haskell.org/hawiki/hIDE -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCEMENT: HAskell Server Pages version 0.4.0
== HAskell Server Pages == HASP is an experimental framework for combining the flexibility of Haskell with the popularity/necessity of web-pages. HASP offers an embedded XML syntax without dispensing with the Glasgow Haskell extensions we hold dear. By using the FastCGI library, HASP is independent of webserver type, and keeps maximum performance. HASP supports sessions, POST data and file uploads, persistent values of arbitrary types, dynamic loading of Haskell code, and thus provides a sound foundation for higher level programming models for dynamic web-pages. Changes since 0.3.0: * Use the bytecode generator from GHC instead of hs-plugins. * Removed the need for Alex, Happy, plugins, ghc-src, trhsp and haspr-config. Changes from Niklas Broberg's original HSP: * GHC bytecode instead of hs-plugins. * Dropped the support for Harp. * Dropped the support for xml in patterns. * Full support for every GHC extension. * HASP uses FastCGI where HSP implements its own web server. HASP: darcs get http://scannedinavian.org/~lemmih/hasp HSP: http://www.cs.chalmers.se/~d00nibro/hsp/ FastCgi: http://fastcgi.com/ -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: System.FilePath survey
On 2/6/06, Simon Marlow <[EMAIL PROTECTED]> wrote: > Isaac Jones wrote: > > > Has anyone yet volunteered to do the hard work of defining an ADT and > > made a proposal for how it should interact w/ the System.IO functions? > > > > I think that lacking a FilePath module is a serious problem that is > > holding haskell back. Lots of languages use String for filepath, like > > Python, which is hugely popular for these uses, but has nothing on > > Haskell, IMO, except this single library. > > > > Lots of people have written home-grown FilePath modules. How long can > > we wait for an implementation to appear? > > The reason we can't just go right ahead and do The Right Thing (i.e. > introduce a new ADT for FilePaths) is because it touches so much other > stuff, including stuff that also needs revising, so it doesn't feel > right to just fix the FilePath library. > > Experience with GHC releases has left me with the opinion that it's > better to group breaking changes together rather than dribble them out - > people only have to modify their code once, and conditional compilation > gets fewer cases. > > So I'm of the opinion that introducing an ADT for FilePaths is something > that should wait until the I/O library is revised. In the meantime, we > should include a String-based Data.FilePath library in Haskell'. It's > not as elegant, but it's terribly practical, and that's one goal of > Haskell'. > > As a first step, can someone package up Data.FilePath as a Cabal package > so that at least we can all start using the same one? Already done. Darcs repository: http://scannedinavian.com/~lemmih/FilePath/ Tarball: http://hackage.haskell.org/packages/FilePath-0.1.0.tgz -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Problems compiling hs-plugins
On 3/5/06, Duncan Coutts <[EMAIL PROTECTED]> wrote: > Hi Ben, > > Yes, I did what dons recommended and copied the Typeable.h from > ghc-6.4.1 to make it compile with ghc-6.5, however in the end I couldn't > get all the hIDE plugins to load with hs-plugins anyway (even though > they would all load in ghci). Why didn't you use the forked vesion? The sole reason I forked hs-plugins was to avoid problems with AltData (which is pure evil and should be gutted, IMHO). -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] DownNova-0.1
Greetings, I hearby announce the release of DownNova-0.1. Description: 'downNova' is a program designed for automating the process of downloading TV series from mininova.org. It will scan your downloaded files to find out what your interests are and download missing/new episodes to your collection. Advanced classification techniques are used to interpret the file names and 'downNova' will correctly extract series name, season number, episode number and episode title in nigh all cases. This might be abused for illegally downloading copyrighted material. That is however not the intended use of this program and I do not condone such activities. Dependencies: fps: http://www.cse.unsw.edu.au/~dons/fps.html HaXml: http://haskell.org/HaXml Installation: runhaskell Setup.lhs configure [--help] runhaskell Setup.lhs build sudo runhaskell Setup.lhs install $EDITOR downnova.cfg sudo cp downnova.cfg /etc/downnova.cfg sudo cp `which downnova` /etc/cron.hourly/ Repository: darcs get http://darcs.haskell.org/~lemmih/downNova -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Milfoh image to texture loading library
On 5/14/06, Maurizio Monge <[EMAIL PROTECTED]> wrote: > > The design rationale for the OpenGL/GLUT/OpenAL/ALUT packages is that they > should exactly mirror the standardize native API behind them in a > Haskell-friendly way. GLUT is only a simple, portable GUI for OpenGL-based > program (handling windows, menus, callbacks, etc.) and it has no support for > loading images, therefore the GLUT package will never have such a facility, > either. Sure, only the GLUT api should be mirrored, but i was thinking that since ALUT do have a few facilities to load audio files, why should not have GLUT itself some facility to load images? BTW, this was just a (slightly offtopic) personal consideration. > > It might be an interesting project to write a nice Haskell binding to the > Developer's Image Library (DevIL, see http://www.imagelib.org/) or Imlib2 > (http://www.enlightenment.org/Libraries/Imlib2/). An alternative is to mirror > only the design and actually do a re-write of the whole library in Haskell. And imagemagick would be another possibility too. Sure, but this is problably is quite a bit of work (even just a binding, without rewriting all funcionalities), i just wrote a bare minimum library to create a texture from an image in an opengl program. i think it will be useful for instance if you want to write a program using just GLUT, to be able to load some texture, because you can just incude it. That's it, nothing more and nothing less. > > An IIRC, there is already a Haskell binding for SDL, but I am not so sure > about how complete it is and if it is still maintained. hSDL is not complete, most important for me was that the OpenGL part and the SDL bindings are not yet done. Of course a more definitive solution would be to complete the hSDL bindings (BTW i don't know if it is still maintained, last release is of 2005 April 12), as SDL is a much more general purpose library than GLUT. There's also hsSDL which is maintained and pretty complete (covering libsdl, libsdl-mixer, libsdl-image and libsdl-ttf). Documentation at: http://darcs.haskell.org/~lemmih/hsSDL/doc/ -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] STM applications and examples?
On 6/13/06, Simon Marlow <[EMAIL PROTECTED]> wrote: Hi Folks, I'm interested in gathering information about existing STM applications and example code that people might be working on or have lying around. It would be great to maintain a list of such applications and example code on the wiki somewhere, and use it as a resource for learning STM and research into STM implementations. If you have an application using STM, please let us know. If you can supply the code, even better. Similarly if you have some STM code that might be suitable as samples or benchmarks, we'd love to collect it. Conjure (a bittorrent client) is using STM quite heavily. It isn't usable as a whole but it has some interesting parts. Darcs repository: http://darcs.haskell.org/~lemmih/conjure/ -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Haskell Communities & Activities Report (10thed., June 2006)
Paolo Martini will most likely continue the development of HackageDB as part of his SoC project. On 6/15/06, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: I believe that this is just what HackageDB is for (described in HCAR p20). I have no idea of how complete Hackage is, thus far, though. Simon | so, the best media will be some sort of online database, like CPAN. | it should | | - have enough fields to allow any required searches - by date of | publication, category, author | - automatically extracts this information from cabal files | - support various entry types, such as individuals, papers and all | other mentioned in current HCAR | - allow anyone to add new entries, with or without uploading actual | implementations | | this database should allow to find information about all | the new/updated packages for last week, making possible automatic | generation of this HWN part. in this case to announce his work, | developer should just describe it at this server, and then | | 1) automatic announcement for this mail list will be generated | 2) next week HWN will automatically include description of this package | 3) anyone interested to see new/updated packages for last year or last | month can run appropriate query on this server site | 4) anyone who want to see full list of described packages or list | split by categories can do it again using this site interface | | the good news is what we already have this database - yes, it's HCAR | itself, what is internally keeps as database, afaik. it has many | fields required, although we should add more following the .cabal | file structure. so we can start this online database just | now. the only thing required is the web interface for | editing/searching data | | the next important things will be keeping history of updates | (especially version updates to allow search for libraries whose major | version was updated during, for example, last 6 months); adding | "subscription to package" that allows to be warned via email when | libraries i interested are updated; interaction with Hackage ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Re[2]: [Haskell] ANNOUNCE: Haskell Communities & Activities Report (10thed., June 2006)
On 6/15/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: Hello Lemmih, Thursday, June 15, 2006, 12:11:50 PM, you wrote: > Paolo Martini will most likely continue the development of HackageDB > as part of his SoC project. are you have plans to implement all things i mentioned? can we now import HCAR database into HackageDB? can HackageDB work with external libraries, non-cabalized libraries, hold information about individuals and so on? HackageDB is only for keeping track of Cabal packages and that's how it's gonna stay (with the possible exception of hosting documentation and darcs repositories, etc). A separate user-editable community report could then refer to packages on HackageDB. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: Re[4]: [Haskell] ANNOUNCE: Haskell Communities & Activities Report (10thed., June 2006)
On 6/15/06, Bulat Ziganshin <[EMAIL PROTECTED]> wrote: Hello Lemmih, Thursday, June 15, 2006, 1:25:27 PM, you wrote: > HackageDB is only for keeping track of Cabal packages and that's how > it's gonna stay (with the possible exception of hosting documentation > and darcs repositories, etc). A separate user-editable community > report could then refer to packages on HackageDB. yes, now we returns to the reasons why i propose to create separate database from HCAR data. one possible distinction may be that HackageDB is for robots that need to automatically install packages required in the TRUSTED way, while HcarDB is for humans searching for information about any haskell-related activity just an example - i know about existence of XYZ library, but i'm not the author. i want to just describe it so that anyone can find info about this lib. can i go to HackageDB? i think no - it's only for authors that upload their libs there. using of unstructured wiki pages is bad - it don't allow to search on complex criteries, don't allow to track history, don't allow to automatically notify about new versions, don't allow to make automatic HWN reports and so on so i propose either to extend HackageDB to allow inclusion of descriptions without libs itself, inlusion of papers, individuals and so on, or develop new web database with such abilities. A new web database is needed. we definitely need a libraries repository! but HackageDB on this moment contains only about 10 projects, mostly your own. why? lack of advertisement, or just because there are too many places where developer should register his library (maillist, hcar, wiki, hackage)? It's most likely because cabal-get and cabal-put are really difficult to install. Of course, this will change when the tools are distributed with Cabal (which a paid hacker will be working on). I believe that the mailing list, the community report, the wiki and HackageDB all serve different needs. The mailing list is for announcements, the report is for semi-formal listing, the wiki is for casual listing and HackageDB is for automatic downloads. There is some overlap but it's not a lot. i propose to search for the way that will allow to move information from HCAR and wiki pages to some web database, be it Hackage or new db. this should allow to create cpan-like database just now and don't wait while developers will grok advantages of HackageDB We all want a neat, central package-database but few are willing to take the first step. (: -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Strange type inference
On 7/7/06, Emil Axelsson <[EMAIL PROTECTED]> wrote: Hello! I'm observing a strange type inference result in the program at the end of the message. term1 and term2 have the same definitions, except for a type annotation for term2, but GHCi infers the following types: *Main> :t term1 term1 :: Term () *Main> :t term2 term2 :: forall a. Term a Could anyone please explain this? It's because of the monomorphism restriction which is widely regarded as one of the uglier parts of Haskell. You can turn it off with -fno-monomorphism-restriction and read more about it here: http://haskell.org/onlinereport/decls.html#sect4.5.5 -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] AngloHaskell: Gathering at Cambridge.
Greetings fellow Haskellers, As you may or may not know, the great folks at Microsoft Research are interviewing people from the end of this month to the 11th of August. In light of this event, I hereby call attention to the AngloHaskell gathering: http://haskell.org/haskellwiki/AngloHaskell Everyone is welcome. Our agenda includes beer, hacking and other fun. -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] AngloHaskell: Call for Participation
Greetings fellow hackers, It is my great pleasure to call attention to the informal gathering of the Haskell community. The event will take place at Cambridge, UK, on Friday and Saturday the 4-5th of August. Don't miss this opportunity to: * associate IRC handles with faces, * drink beer, * ride unicycles and * much more. The event is of course free and non-haskellers are welcome as well. More information can be found here: http://haskell.org/haskellwiki/AngloHaskell -- Friendly, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Repeated evaluation of a constant value.
On 9/25/06, Paul Johnson <[EMAIL PROTECTED]> wrote: I recently wanted to pass a lookup table around a program. Rather than having something explicitly typed as Map.Map I wrote a function that assembled a Map and then used Map.lookup to return a function, like this: > module Main where > > import qualified Data.Map as Map > import Debug.Trace > > alist :: [(String, Integer)] > alist = map (\i -> (show i, i)) [1..100] > Change: > table :: [(String, Integer)] -> String -> Maybe Integer > table ls str = Map.lookup str fm >where fm = trace "Trace: making the map" $ Map.fromList ls to: > table :: [(String, Integer)] -> String -> Maybe Integer > table ls = \str -> Map.lookup str fm >where fm = trace "Trace: making the map" $ Map.fromList ls "table" can be seen as a function from an association list to a look-up function. > demo :: [(String, Integer)] -> IO () Change: > demo ls = do to: > demo ls = func `seq` do > showLookup "5" > showLookup "70" > showLookup "164" > showLookup "wibble" >where > func = table ls > showLookup str = > putStrLn $ "Look up " ++ show str ++ " gives " ++ > show (func str) ++ "." > > main :: IO () > main = demo alist I reasoned that closure returned by "table ls" would contain a thunk for "fm", which in turn would be evaluted the first time it was called. But it isn't: instead "fm" gets evaluated for every call to "table", as shown by the repeated trace messages. Store this message as "Thunk.lhs". Compile with ghc -O2 and run "main". What you get is: Trace: making the map Look up "5" gives Just 5. Trace: making the map Look up "70" gives Just 70. Trace: making the map Look up "164" gives Nothing. Trace: making the map Look up "wibble" gives Nothing. So my question is: how do I write "table" to return a function which does not build the lookup table for every call? Or is this a bug in GHC? (I should add that my real "table" function is rather more complicated, and only invokes Map.lookup on a subset of its arguments.) Paul. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell I've just given it a quick look so it may be flawed. -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Haskell Packages 6.6?
On 10/4/06, Isaac Jones <[EMAIL PROTECTED]> wrote: Hello good Haskell Hackers. We're pretty well along the way to getting cabal-install and friends working nicely. We've got almost 30 packages in the database. I added a few more. We have 32 now. Let's imagine something that would be awesome. A set of Haskell packages which are all known to work together with a particular version of cabal (the one that GHC comes with), and a particular version of GHC. GHC version 6.6 will be released soon, and I think we should try to make this happen. Currently, we have a set of 27 "unstable" packages. They may or may not work with each-other and such: http://hackage.haskell.org/packages/ I just created an empty directory "testing". I propose that we start testing packages, starting with the cabal release candidate that'll go into GHC 6.6, and make sure they work nicely together. Once they're known to work, we can migrate them from the "unstable" directory to the "testing" directory. Once we have a sufficient collection of packages, and once ghc 6.6 is released, we can make a snapshot of this directory, call it "stable-6.6" or something. Then if you have ghc 6.6 and cabal-install, you should be able to "cabal-install p" for any package, and it'll definitely work. What about the packages that have external dependencies? They won't necessarily be buildable on the server. So what will we need for this to happen? 1. An installed version of ghc 6.6 on the hackage/darcs server. Maybe in a chroot or something. Maybe from the nightly build tree or the previous snapshot? 2. Some initial set of packages (maybe just cabal-install) to start off. 3. Some script that goes through and builds all of the "unstable" packages in dependency order. I think cabal-install can do this already. In fact, it would be ideal if we used cabal-install for this. 4. The script should also run ./setup haddock and ./setup test. If the packages seem to work w/ 6.6 and the other packages in "testing", it should get migrated from "unstable" to "testing". 5. A web interface (lemmih is working on it) HackageDB is as good as it's gonna get for now. Btw, why is this step necessary? 6. A script to upload packages to "unstable" (Paolo is working on it). 7. Someone to spearhead all of this! I have time. However, I also see a lot of problems. -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: package mounting
On 10/30/06, Frederik Eaton <[EMAIL PROTECTED]> wrote: On Sun, Oct 29, 2006 at 10:03:32PM -0400, Samuel Bronson wrote: > On 10/25/06, Frederik Eaton <[EMAIL PROTECTED]> wrote: > > >http://hackage.haskell.org/trac/ghc/wiki/PackageMounting > > It looks nice, but don't you think the -package-base flag ought to > take both the package name *and* the mountpoint? My intention was that -package-base specifies a base for the package specified in the preceding -package flag, but I'll clarify it in the document. In other words, it is an optional argument and the syntax is ghc ... -package PACKAGE -package-base BASE ... (giving package PACKAGE mount point BASE) > Otherwise, this looks like what I've wanted all along, if only I knew it ;-). Excellent, thanks. What about packages with multiple module trees like, say, Cabal? -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] SimonPJ and Tim Harris explain STM - video
On 11/24/06, Tomasz Zielonka <[EMAIL PROTECTED]> wrote: On Thu, Nov 23, 2006 at 12:56:00PM -, Bayley, Alistair wrote: > http://channel9.msdn.com/Showpost.aspx?postid=231495 > > The links to the video are a couple of yellow buttons at the bottom of > the article: "Watch" or "Download". > > I haven't watched this yet (it's nearly an hour long, I think). Found > via reddit (http://reddit.com). > > Haskeller's on TV (sort of...) woot woot! Does anybody know how to watch this on Linux? I would prefer to simply download the movie file and use MPlayer on that, but I failed. .. or on Mac OS X (haven't tried yet) Worked for me with mplayer+w32codecs. -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Announcement: cabal-test
Greetings fellow hackers, It's my great pleasure to announce cabal-test, the automatic tester for Cabal projects. The cabal-test tool is capable of testing embedded quickcheck properties in any and all cabalized projects. The tests are currently executed in parallel with pqc. QC properties can reside anywhere in the code and don't have to be exported. Requirements: * GHC-6.6 * pqc (http://www.cse.unsw.edu.au/~dons/code/pqc/) Future goals: * Use Haddock information when printing test names. * Ability to test multiple targets simultaneously. Example usage: $ ./cabal-test Testing cabal-test-0.1 No library Testing executable: cabal-test 2: Tests.prop_sort2 : OK, 100 tests. 2: Tests.prop_sort3 : OK, 100 tests. 2: Tests.prop_sort4 : OK, 100 tests. 2: Tests.prop_sort6 : OK, 100 tests. 1: Tests.prop_sort1 : OK, 100 tests. 2: Tests.prop_sort5 : OK, 100 tests. $ ./cabal-test --help Usage: cabal-test [OPTION] [PATH] Options: -h, -? --help Show this help text -v[n]--verbose[=n]Control verbosity (n is 0-5, normal verbosity level is 1, -v alone is equivalent to -v3) -w path --ghc-path=path Use this command as ghc -n n --threads=n Use 'n' threads. Default is 2 -t n --tests=nDepth of test. Default 100 -p prop --proptag=prop Tests must contain this tag. Default 'prop_'. The darcs repository is available at: http://darcs.haskell.org/~lemmih/cabal-test -- Cheers, Lemmih PS: I'm so glad we're not using Makefiles anymore. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Announcement: cabal-test
On 11/26/06, Benjamin Franksen <[EMAIL PROTECTED]> wrote: Lemmih wrote: > It's my great pleasure to announce cabal-test, the automatic tester > for Cabal projects. > [...] > http://darcs.haskell.org/~lemmih/cabal-test What about changing #!/usr/bin/env runhugs to #!/usr/bin/env runhaskell in your Setup.lhs? Oops, didn't notice that. Thanks. -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] How to use STM in GUI applications?
On 12/4/06, Thorsten Seitz <[EMAIL PROTECTED]> wrote: Hello, I'm very intrigued by the concepts of STM but I'm having difficulties to see how a TVar based model can be used by a GUI application (e.g. Gtk2hs): For example, I'd like to update the GUI (e.g. changing widget sensitivity) upon changes in the model. But changing the sensitivity of a widget is an IO operation which cannot be initiated atomically by a model change which is an STM operation. Therefore the GUI change cannot be executed atomically together with the model change. This means for example that I can still press a button although the model has changed such that the button action is not allowed anymore. All I can do is check the condition of the model when the button is pressed and then ignore the button press which is not very satisfying for the user. Is it simply not appropriate to use TVar based models in a GUI application? Maybe STM should be more used like a service for MVar based GUI models? How about making a list of IO actions to be executed when the transaction commits? -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] How to make sure that a function is evaluated only once?
On 12/21/06, Axel Jantsch <[EMAIL PROTECTED]> wrote: Hello, I have a function with type f :: Int -> Int -> Int -> Int -> Int -> NRup -> NRdown and I want to make sure it is evaluated only once for the same set of arguments but I observe that it is always evaluated several times. f is implemented in C and called via the FFI. The C function may or may not be pure. In principle it is but it is convenient to keep some state for debugging and monitoring. Anyway, even if it is pure, I want it to evaluate only once for a set of arguments because of performance. How can I enforce this? Is there a GHC option for that? Is there a way to write the Haskell code to achieve this? I have asked the same question in the context of FFI, but now it seems to me this question is not directly related to the FFI. Haskell implementations are free to evaluate expressions as many times as they feel like. If you want to be absolutely sure, use the IO monad. On the other hand, you might get the same effect with a few cleverly placed {-# NOINLINE #-} pragmas. Do you have a minimal test case showing the undesirable behaviour? -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] How to make sure that a function is evaluated only once?
On 12/22/06, Axel Jantsch <[EMAIL PROTECTED]> wrote: Thanks to all who replied. I still haven't figured out a solution. I thought about memoizing the result, as several of you have suggested, but I am scared by the huge argument space. Lemmih <[EMAIL PROTECTED]> wrote: > Do you have a minimal test case showing the undesirable behaviour? gf (actCnt,sndCnt, sizex, sizey, locx, locy) iPack = (newSndCnt sndCnt outPack, outPack) where outPack = fWrapper sizex sizey locx locy actCnt iPack newSndCnt n (Abst,_) = n newSndCnt n (Prst _,_) = n + 1 This is a simplified context for the call to the C function, which is wrapped by fWrapper. I figured out that one reason for double evaluation is that outPack is used twice in the return expression of gf. So my question now is, can I force the evaluation machine to evaluate fWrapper once and use the same result value in both places where outPack is used? I tried the NOINLINE pragma both on outPack and on fWrapper, but to no avail. Again, I am grateful for any hint to a work-around. Try using a let-expression and/or make the tuple arguments strict. -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] GHC6.8.1 can not compile the simple example
On 11/12/07, david yu <[EMAIL PROTECTED]> wrote: > Link error is: > [EMAIL PROTECTED] test]$ ghc c.hs Try: ghc --make c.hs -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: [Haskell-cafe] GSoC 2008
On Tue, Feb 26, 2008 at 8:43 PM, Johan Tibell <[EMAIL PROTECTED]> wrote: > On Mon, Feb 25, 2008 at 3:28 PM, Malcolm Wallace > <[EMAIL PROTECTED]> wrote: > > Google has today announced that they will be running their Summer of > > Code programme again this year. > > http://code.google.com/soc/2008/ > > > > haskell.org has had many student projects funded by this programme, in > > 2006 and 2007. Would you like to participate? Either as a student or > > a mentor? > > I'd like to see a Unicode equivalent of ByteString and I'm willing to > mentor someone who's willing to implement it. Doesn't compact-string support unicode? -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANN: uuid-0.1.0 Haskell bindings to libuuid
On Sun, Mar 23, 2008 at 7:11 PM, Antoine Latter <[EMAIL PROTECTED]> wrote: > Haskell bindings to libuuid. The library libuuid is available as a > part of e2fsprogs: http://e2fsprogs.sourceforge.net/. > > This library is useful for creating, comparing, parsing and printing > Universally Unique Identifiers. See http://en.wikipedia.org/wiki/UUID > for more details on UUIDs. Tarball and documentation can be found here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/uuid -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANN: Hackage.
Hey, For the last two weeks I've been playing around with the idea of a package listing page to replace (or coexists with) the current library page [1]. After some experimenting with different approaches, I've found that a Halipeto [2] like template system together with HaskellDB [3] would be acceptable. Then, after some hacking, the idea came to life in the form of Hackage [4], which currently supports adding, updating and searching based on Cabal description files. But my time is limited and it would be great if someone would tweak it into something useable. Lemmih [1] http://www.haskell.org/libraries/ [2] http://www.acooke.org/jara/halipeto/ (not directly used but it has inspired me) [3] http://haskelldb.sourceforge.net/ [4] source: http://www.scannedinavian.org/~shae/Hackage.tgz demo: http://www.scannedinavian.org/cgi-bin/hackage/hackage ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: hsSDL-0.6
Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power." hsSDL is a nigh one-to-one Haskell binding to libSDL (and a few auxiliary library such as SDL-image, SDL-mixer and SDL-ttf). This release contains no API changes but signifies a new era of even greater stability. Version 0.6 also contains a much improved guide for building and using hsSDL on Macs. My thanks goes out to Johannes Krause. Without his contribution of time and expertise, this release wouldn't have happened. http://hackage.haskell.org/package/SDL http://hackage.haskell.org/package/SDL-image http://hackage.haskell.org/package/SDL-mixer http://hackage.haskell.org/package/SDL-ttf http://hackage.haskell.org/package/SDL-gfx -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: lhc-0.10
Hiya, It's time for a new release of LHC. LHC is a backend for the Glorious Glasgow Haskell Compiler, adding low-level, whole-program optimization to the system. It is based on Urban Boquist’s GRIN language, and using GHC as a frontend, we get most of its great extensions and features. Essentially, LHC uses the GHC API to convert programs to external core format - it then parses the external core, and links all the necessary modules together into a whole program for optimization. We currently have our own base library (heavily and graciously taken from GHC.) This base library is similar to GHC’s (module-names and all,) and it is compiled by LHC into external core and the package is stored for when it is needed. This also means that if you can output GHC’s external core format, then you can use LHC as a backend. Changes in this release include: * LHC requires GHC-6.12 instead of GHC-6.10. * Much simplified support infrastructure to help minimize software decay. Installation instructions can be found in this blog post: http://lhc-compiler.blogspot.com/2010/05/limited-release.html It should be noted that LHC is in its infancy and should be seen more as a toy than anything else. So, if you want a good Haskell compiler, use GHC. If you want play around with GRIN, LHC might be right for you. The following URLs are of relevance: Wiki: http://lhc.seize.it/ Blog: http://lhc-compiler.blogspot.com/ Hackage: http://hackage.haskell.org/package/lhc-0.10 GRIN: http://www.cs.chalmers.se/~boquist/phd/ -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: acid-state-0.3
Greetings, With acid-state-0.3, you can use regular Haskell data structures without worrying about data loss or durability. Your state will simply always be available to you even after software crashes or power outages. For examples of how to use the library, see: http://mirror.seize.it/acid-state/examples/ http://hackage.haskell.org/package/acid-state http://acid-state.seize.it/ -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: acid-state-0.4
Greetings, With acid-state-0.4, you can use regular Haskell data structures without worrying about data loss or durability. Your state will simply always be available to you even after software crashes or power outages. Acid-state-0.4 improves over the previous version by leveraging the might of 'cereal' and 'safecopy'. Those two packages provide better error handling and improved data safety. Additionally, acid-state-0.4 contains yet more examples and a handful of general wibbles. For examples of how to use the library, see: http://mirror.seize.it/acid-state/examples/ Hackage page for acid-state: http://hackage.haskell.org/package/acid-state Wiki site: http://acid-state.seize.it/ -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: acid-state-0.6
Greetings, With acid-state-0.6, you can use regular Haskell data structures without worrying about data loss or durability. Your state will simply always be available to you even after software crashes or power outages. Important: acid-state-0.6 is not immediately backwards compatible with previous versions. To restore states from previous versions you first need to create a checkpoint and then modify your data structure to use the 'Prim' wrapper from safecopy-0.6 wherever built-in types are used. More information on this will be on the wiki soonish. I hope this slight inconvenience will be worth it in the long run. Acid-state-0.6 also includes a new Remote backend that enables concurrent access by multiple processes. For examples of how to use the library, see: http://mirror.seize.it/acid-state/examples/ Hackage page: http://hackage.haskell.org/package/acid-state Wiki site: http://acid-state.seize.it/ -- Cheers, Lemmih ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell