[Haskell] ANN: Hacanon 0.1

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

== 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

[Lemmih]

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

[Lemmih]

== 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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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?

[Lemmih]

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)

[Lemmih]

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)

[Lemmih]

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)

[Lemmih]

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

[Lemmih]

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.

[Lemmih]

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

[Lemmih]

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.

[Lemmih]

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?

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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?

[Lemmih]

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?

[Lemmih]

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?

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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.

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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

[Lemmih]

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