Hi Stephan,
it seems you beat me ;-)
I've been working on the same thing as well.
You'll find my effort at http://bitbucket.org/pao/hsvm/.
What is missing is:
- the final bindings to complete the API
- haddock documentation
- cabal setup
Unfortunately the commit log are in italian (I didn't
pl
Hi all,
I've been recently toying with a small tool inspired by
the Python tool virtualenv [1].
What it basically allows to do is to setup isolated,
disposable package environments.
You can find a small session example in:
http://www.haskell.org/haskellwiki/PkgEnv
The main benefits should be:
Duncan Coutts wrote:
Would it be useful to have cabal-install check a env var for its config
file?
Definitely yes.
This would allow dropping the dependency on bash aliasing and
make porting to Windows fairly easy.
Thanks
Paolo
___
Haskell-Cafe mail
Michael Roth wrote:
Hello list,
maybe I'm just stupid, I'm trying to do something like this:
Ciao Michael,
As an alternative solution to Creighton's:
import Control.Monad.List
foobar :: ListT IO Int
foobar = do
a <- ListT . return $ [1,2,3]
b <- ListT . return $ [4,5
Hi all,
I'm following an interesting thread on the scala mailing list:
http://www.nabble.com/-scala--usefulness-of-OOP-td23268250.html
Martin Odersky advocates the OO features of the scala language
proposing an interesting problem where the OO approach seams
valuable.
I would be very much inte
Hi all,
I'd like to mention an interesting thread on the scala mailing list
about usefulness of OOP.
http://www.nabble.com/-scala--usefulness-of-OOP-td23268250.html
Martin Odersky, scala creator, advocates the use of OOP using
an interesting toy problem.
I would be very interested about the hask
Hi Manlio
Manlio Perillo wrote:
By the way, I have managed to have a working program:
http://hpaste.org/13919
I've made some some minor refinements according
to my own tastes :-)
http://hpaste.org/13919/diff?old=0&new=2
Please note that in both cases IO exceptions are not handled.
I would
Massimiliano Gubinelli wrote:
Hi,
what about avoid the use of the unfold over the tree and construct it
directly (e.g. see http://hpaste.org/13919#a3)?
Nice solution!
I wonder if there is (an
easy) possibility to construct the tree lazily so that output start
immediately for large trees.
Max Vasin wrote:
Wouldn't it be more correct to separate binary IO, which
return [Word8] (or ByteString) and text IO which return
[Char] and deal with text encoding? IIRC that was done in
Bulat Ziganshin's streams library.
That's exactly what I meant.
Text IO could be then implemented on to
Simon Marlow wrote:
The only change to the existing behaviour is that by default, text IO
is done in the prevailing encoding of the system. Handles created by
openBinaryFile use the Latin-1 encoding, as do Handles placed in
binary mode using hSetBinaryMode.
wouldn't be semantically correct fo
Henning Thielemann wrote:
4) hg commit -m "message"
this commits my changes locally. I always do this before pulling since
then I'm sure my changes are saved in the case a merge goes wrong.
In old darcs its precisely the other way round. Since it is so slow on
merging ready patches, you better
Thomas Davie wrote:
On 6 Feb 2009, at 10:12, Paolo Losi wrote:
Henning Thielemann wrote:
4) hg commit -m "message"
this commits my changes locally. I always do this before pulling since
then I'm sure my changes are saved in the case a merge goes wrong.
In old darcs its prec
Hi all,
I would really appreciate if anyone could
give a look to the following problem.
Thanks in advance!!!
Paolo
-- Forwarded message --
From: Paolo Losi
Date: Mon, Sep 14, 2009 at 10:33 AM
Subject: C++ libraries and GHCI
To: glasgow-haskell-us...@haskell.org
Hi all,
I
Hi Roman,
Template Haskell should be the preferred way to
cope with these "boilerplate" code problems.
Template Haskell: http://www.haskell.org/haskellwiki/Template_Haskell
Note: I'm a beginner myself so please wait for a more informed response.
Paolo
2009/9/28 Roman Naumann :
> The followi
Hi all,
while coding recently I came across the need for
a strict mapM (that I indicidently use for m = MaybeT IO).
I implementented this with the following simple code
(it works for my use case):
mapM' :: Monad m => (a-> m b) -> [a] -> m [b]
mapM' _ [] = return []
mapM' f (x:xs) = do y <-
On 14/10/2010 12:01, Michael Snoyman wrote:
I have a recommendation of how to fix this: the MonadCatchIO typeclass
should be extended to include finally, onException and everything
else. We can provide default definitions which will work for most
monads, and short-circuiting monads like ErrorT (
Thanks for you reply, Michael.
See inline ...
On Mon, Oct 18, 2010 at 11:21 AM, Michael Snoyman
>
> >
> > As an haskell newbie, I've got some questions on this matter.
> >
> > Is it using ErrorT instead of extensible exeptions really necessary?
> > I've read your comment stating that we cannot pas
On Mon, Oct 18, 2010 at 2:50 PM, Michael Snoyman wrote:
> It really does seem to me to be
> a typical dynamic-versus-static issue.
I got your point. Thanks for taking the time to explain the difference
between the options.
Grazie!
Paolo
___
Haskell-Caf
Don Stewart wrote:
The Haskell Web News is a monthly summary of the hottest news about the
Haskell programming language, as found in our online communities. If you
want to catch up with what’s been happening in Haskell, this might be
the journal for you.
Don, thank you for the web news. I find
19 matches
Mail list logo