date:20110206

Re: [GHC] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)

2011-02-06 Thread GHC

#4867: ghci displays negative floats incorrectly (was: Incorrect result from 
trig
functions)
---+
Reporter:  gwright |Owner:  gwright
Type:  bug |   Status:  new
Priority:  high|Milestone:  7.0.2  
   Component:  GHCi|  Version:  7.0.1  
Keywords:  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  MacOS X | Blocking: 
Architecture:  x86_64 (amd64)  |  Failure:  Incorrect result at runtime
---+

Comment(by gwright):

 I was half right: rather than being missing, another piece of the OS X 64
 bit linker was just sketched in.  This code incorrectly calculated some of
 the less common relocations.  The fix was just to replace the erroneous
 code with a call to `relocateAddress`.

 Here's what happens now:
 {{{
 gwright-macbook inplace/bin/ghc-stage2 --interactive
 GHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/  :? for help
 Loading package ghc-prim ... linking ... done.
 Loading package integer-gmp ... linking ... done.
 Loading package base ... linking ... done.
 Loading package ffi-1.0 ... linking ... done.
 Prelude -1.0
 --1.0
 Prelude
 }}}

 I don't yet understand the double minus sign in the result.  It's probably
 caused by the messing about I did with `Float.lhs` when trying to track
 down the bug.  I hope there isn't another real bug here, but you never
 know.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4867#comment:25
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4902: Create a primop for getting the size of an Array#

2011-02-06 Thread GHC

#4902: Create a primop for getting the size of an Array#
-+--
Reporter:  tibbe |Owner:  
Type:  feature request   |   Status:  patch   
Priority:  normal|Milestone:  
   Component:  Runtime System|  Version:  7.0.1   
Keywords:| Testcase:  
   Blockedby:|   Difficulty:  
  Os:  Unknown/Multiple  | Blocking:  
Architecture:  Unknown/Multiple  |  Failure:  None/Unknown
-+--
Changes (by tibbe):

 * cc: johan.tibell@… (added)


Comment:

 I've added a test to the test suite. All tests pass (for arrays of size
 [0..1000]). Please review.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4902#comment:6
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4867: ghci displays negative floats incorrectly (was: Incorrect result from trig functions)

2011-02-06 Thread GHC

#4867: ghci displays negative floats incorrectly (was: Incorrect result from 
trig
functions)
---+
Reporter:  gwright |Owner:  gwright
Type:  bug |   Status:  new
Priority:  high|Milestone:  7.0.2  
   Component:  GHCi|  Version:  7.0.1  
Keywords:  | Testcase: 
   Blockedby:  |   Difficulty: 
  Os:  MacOS X | Blocking: 
Architecture:  x86_64 (amd64)  |  Failure:  Incorrect result at runtime
---+

Comment(by altaic):

 Not sure if you had already discovered this, but it appears the bug is
 limited to `Double`, while `Float` appears to be fine:
 {{{
 Prelude -1.0 :: Float
 -1.0
 Prelude -1.0 :: Double
 -3.666940035476786e76
 }}}

 Oddly, the transform that's producing the garbage value is reversible
 (guessing there'd be loss of bits at extremes):
 {{{
 Prelude -1.0 :: Double
 -3.666940035476786e76
 Prelude -3.666940035476786e76 :: Double
 -1.0
 }}}

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4867#comment:26
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4852: cabal doesn't tell ./configure which gcc to use

2011-02-06 Thread GHC

#4852: cabal doesn't tell ./configure which gcc to use
+---
  Reporter:  kazu-yamamoto  |  Owner:  
  Type:  bug| Status:  closed  
  Priority:  highest|  Milestone:  7.0.2   
 Component:  libraries (other)  |Version:  7.1 
Resolution:  fixed  |   Keywords:  
  Testcase: |  Blockedby:  
Difficulty: | Os:  Unknown/Multiple
  Blocking: |   Architecture:  Unknown/Multiple
   Failure:  Other  |  
+---

Comment(by kazu-yamamoto):

 OK. I understand. I installed cabal-install again and confirmed that the
 following cabal-install can compile the network 2.3.0.1
 {{{
 cabal-install version 0.9.5
 using version 1.10.1.0 of the Cabal library
 }}}
 Thank you very much.

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4852#comment:29
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

System.Posix.Signals weirdness

2011-02-06 Thread Matthias Kilian

Hi,

I'd expect the following program (compiled with ghc and without any
specieal flags) to produce

Just (Exited ExitSuccess)
True

but it produces

Just (Exited ExitSuccess)
False

on Debian Lenny (ghc-6.8), OpenBSD-current (ghc-6.12.3), OpenBSD-current
(ghc=7.0 from the 7.0 branch).

module Main where

import Data.IORef
import System.Posix.Process
import System.Posix.Signals
import System.Posix.Unistd

main = do
caughtCHLD - newIORef False
installHandler sigCHLD (Catch $ writeIORef caughtCHLD True) 
Nothing
pid - forkProcess $ sleep 2  return ()
s - sleep 8
getProcessStatus False False pid = print
readIORef caughtCHLD = print

The sigCHLD handler is never called in this program. Is this expected
behaviour? If so, why?

Ciao,
Kili

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Question about Haskell AST

2011-02-06 Thread Tim Chevalier

On Mon, Jan 10, 2011 at 9:21 AM, Jane Ren j2...@ucsd.edu wrote:
 Hi,

 I need to be able to take a piece of Haskell source code and get an 
 simplified, typed, intermediate representation of the AST, which means I need 
 to use compiler/coreSyn/CoreSyn.lhs

 So I'm first trying to get the desguaredModule of the source code with
        ...
        modSum - getModSummary $ mkModuleName ...
        p - parseModule modSum
        t - typecheckModule p
        d - desugarModule t

 Now I'm really stuck on figuring out how to connect the variable d of type 
 desugaredModule to compiler/coreSyn/CoreSyn.lhs to get Expr patterns like 
 App, Let, Case, etc.

 Also, is it correct to get the deguaredModule first?  At least CoreSyn.lhs 
 seems to suggest this.


Sorry for the very late reply, but have you considered using External Core?
http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/ext-core.html
http://hackage.haskell.org/package/extcore

IMO, it's less pain than linking with the GHC library unless your
application really needs to get transformed Core back into the GHC
back-end.

Cheers,
Tim

-- 
Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt
an intelligent person fights for lost causes,realizing that others
are merely effects -- E.E. Cummings

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

a compiled program is slower than byte code

2011-02-06 Thread 山本和彦

Hello, 

If I compile the attach code with GHC of the newest ghc-7.0 darcs
branch, the compiled program is much slower than byte code. This
phenomenon does not exist in GHC 6.12.3.

6.12.3  runghc   -- 6.23s user 0.59s system 98% cpu 6.912 total
ghc  -- 5.72s user 0.70s system 99% cpu 6.422 total
ghc -O   -- 5.70s user 0.67s system 99% cpu 6.376 total
ghc -O2  -- 5.69s user 0.67s system 99% cpu 6.373 total

ghc-7.0 runghc   -- 6.43s user 0.10s system 99% cpu 6.593 total
ghc  -- 9.20s user 0.09s system 99% cpu 9.302 total
ghc -O   -- 9.20s user 0.09s system 99% cpu 9.298 total
ghc -O2  -- 9.38s user 0.09s system 99% cpu 9.478 total

Is this a bug?

My environment is Mac which runs Snow Leopard.

--Kazu


import System.IO

n :: Int
n = 1

main :: IO ()
main = withFile /dev/null WriteMode $ \h -
hPutStr h . foldr1 (++) . replicate n . replicate n $ 'a'


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Dictionaries and full laziness transformation

2011-02-06 Thread Akio Takano

Hi,

I'm using GHC 7.0.1. I found that recursive overloaded functions tend
to leak memory when compiled with full-laziness optimization on. Here
is a simple case.

-- TestSub.hs
{-# LANGUAGE BangPatterns #-}
module TestSub where

{-# NOINLINE factorial #-}
factorial :: (Num a) = a - a - a
factorial !n !acc = if n == 0 then acc else factorial (n - 1) (acc * n)

-- main.hs
import TestSub

factorial1 :: Int - Int - Int
factorial1 = factorial

main = do
n - readLn
print $ factorial1 n 1

main

This program should run in constant space, and compiled with -O0 or
-O2 -fno-full-laziness, it does. However with -O2, it takes a linear
amount of memory. The core for factorial looks like this:

TestSub.factorial =
  \ (@ a_ajm) ($dNum_slz :: GHC.Num.Num a_ajm) -
let {
  a_slA :: GHC.Classes.Eq a_ajm
  [LclId]
  a_slA = GHC.Num.$p1Num @ a_ajm $dNum_slz } in
let {
  lvl2_slC :: a_ajm - a_ajm - a_ajm
  [LclId]
  lvl2_slC = TestSub.factorial @ a_ajm $dNum_slz } in
...

The problem is that lvl2_slC closure is created whenever factorial is
applied to a Num dictionary, and kept alive until that application is
GCed. In this program it never happens, because an application to the
Num Int dictionary is referred to by the factorial1 CAF, and it
recursively keeps the whole chain of closures alive.

I know that full laziness transformation *sometimes* causes a space
leak, but this looks like a bad result to me, because:

- It looks like there is no point building a lot of equivalent
closures, instead of one.
- A lot of code can suffer from this behavior, because overloaded
recursive functions are fairly common.
  For example, unfoldConvStream function from the latest iteratee
package suffers from this problem, if I understand correctly.

Does anyone have an idea on whether this can be fixed in GHC, or how
to work around this problem?

Regards,

Takano Akio

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell] SLE 2011 - 2nd Call for papers

2011-02-06 Thread João Fernandes




 2nd CALL FOR PAPERS

 SLE 2011
4th International Conference on Software Language Engineering

   Braga, Portugal, 3-6 July 2011

   http://planet-sl.org/sle2011/

 Co-located with the 4th Summer School on Generative and
 Transformational Techniques in Software Engineering
 (GTTSE 2011)

=

IMPORTANT DATES

* 2011:
Paper submission: April 08 (midnight Apia Samoa time)
Author notification: May 13
Paper submission for online proceedings: June 17
Conference: July 03-06
Camera-ready copy submission for post-proceedings: August 29

-

Software language engineering is devoted to topics related
to artificial languages in software engineering. The foremost
mission of the International Conference on Software Language
Engineering (SLE) is to encourage and organize communication
between communities that traditionally have looked at soft-
ware languages from different, more specialized, and yet
complementary perspectives. Thus, technologies, methods,
experiments and case studies from modelware, grammarware,
and ontologyware serving the objectives of software languages
are of particular relevance to SLE.

We invite high-quality submissions to all conference tracks.
Submissions must be PDF files following the Springer LNCS
style and will be managed using the EasyChair submission system.
Please check the conference web site for further information.

SLE 2011 will include a Doctoral Symposium that will provide a
supportive yet questioning setting in which PhD students can
present their work, including goals, methods, and preliminary
results. The Symposium aims to provide students with useful
guidance and feedback on various aspects of their research from
established researchers and the other student attendees.

Please forward this call to anyone who might be interested.

http://planet-sl.org/sle2011/

-
PAPER SUBMISSION

Submitted papers must be original work and must not be
previously published in, currently submitted to, or currently
in consideration for any journal, book, conference, or
workshop. Each submitted paper will be reviewed closely by
at least three members of the program committee. Accepted
papers will be distributed at the conference via the online
proceedings as well as published in the post-proceedings,
which will appear in the Springer Lecture Notes in Computer
Science (LNCS) series. Authors will have the opportunity
to revise their accepted paper(s) for the pre- and post-
proceedings. For an accepted paper to appear in the proceedings,
at least one author must attend the event and present the work.

-
RESEARCH PAPERS

Research papers should report a substantial research contribution
to SLE and/or a successful application of SLE techniques.  We
solicit high-quality contributions in the area of SLE ranging
from theoretical and conceptual contributions to tools, techniques,
and frameworks that support the aforementioned lifecycle activities.
We list examples of tools, techniques, applications, and problems of
interest to clarify the types of contributes that we seek:

* Formalisms used in designing and specifying languages and
tools that analyze such language descriptions
* Language implementation techniques
* Program and model transformation tools
* Composition, integration, and mapping tools for managing
different aspects of software languages or different
manifestations of a given language
* Transformations and transformation languages between
languages and models
* Language evolution
* Approaches to elicitation, specification, or verification
of requirements for software languages
* Language development frameworks, methodologies, techniques,
best practices, and tools for the broader language lifecycle
covering phases such as analysis, testing , and documentation.
* Design challenges in SLE
* Applications of languages including innovative domain-specific
languages or little languages

The preceding list is neither exclusive nor exhaustive.  Visit
the conference web site for more information about the scope
and topics of interest of SLE, or contact the program co-chairs
with questions.

Page limit: 20

-
SHORT PAPERS

Short papers may describe interesting or thought-provoking
concepts that are not yet fully developed or evaluated, make
an initial contribution to challenging research issues in SLE,
or discuss and analyze controversial issues in the field.

Page limit: 10

-
TOOL DEMONSTRATION PAPERS

Because of SLE's ample interest in tools, we seek papers
that present software tools related to the field of SLE.
These papers will

[Haskell] ANN: monad-control-0.1

2011-02-06 Thread Bas van Dijk

Dear all,

Several attempts have been made to lift control operations (functions
that use monadic actions as input instead of just output) through
monad transformers:

MonadCatchIO-transformers[1] provided a type class that allowed to
overload some often used control operations (catch, block and
unblock). Unfortunately that library was limited to those operations.
It was not possible to use, say, alloca in a monad transformer. More
importantly however, the library was broken as was explained[2] by
Michael Snoyman. In response Michael created the MonadInvertIO type
class which solved the problems. Then Anders Kaseorg created the
monad-peel library which provided an even nicer implementation.

monad-control is a rewrite of monad-peel that uses CPS style
operations and exploits the RankNTypes language extension to simplify
and speedup most functions. A very preliminary and not yet fully
representative, benchmark shows that monad-control is on average about
2.6 times faster than monad-peel:

bracket:  2.4 x faster
bracket_: 3.1 x faster
catch:1.8 x faster
try:  4.0 x faster
mask: 2.0 x faster

Note that, although the package comes with a test suite that passes, I
still consider it highly experimental.


API DOCS:

http://hackage.haskell.org/package/monad-control


INSTALLING:

$ cabal update
$ cabal install monad-control


TESTING:

The package contains a copy of the monad-peel test suite written by
Anders. You can perform the tests using:

$ cabal unpack monad-control
$ cd monad-control
$ cabal configure -ftest
$ cabal test


BENCHMARKING:

$ darcs get http://bifunctor.homelinux.net/~bas/bench-monad-peel-control/
$ cd bench-monad-peel-control
$ cabal configure
$ cabal build
$ dist/build/bench-monad-peel-control/bench-monad-peel-control


DEVELOPING:

The darcs repository will be hosted on code.haskell.org ones that
server is back online. For the time being you can get the repository
from:

$ darcs get http://bifunctor.homelinux.net/~bas/monad-control/


TUTORIAL:

This short unpolished tutorial will explain how to lift control
operations through monad transformers. Our goal is to lift a control
operation like:

foo ∷ M a → M a

where M is some monad, into a transformed monad like 'StateT M':

foo' ∷ StateT M a → StateT M a

The first thing we need to do is write an instance for the
MonadTransControl type class:

class MonadTrans t ⇒ MonadTransControl t where
  liftControl ∷ (Monad m, Monad n, Monad o)
  ⇒ (Run t n o → m a) → t m a

If you ignore the Run argument for now, you'll see that liftControl is
identical to the 'lift' method of the MonadTrans type class:

class MonadTrans t where
lift ∷ Monad m ⇒ m a → t m a

So the instance for MonadTransControl will probably look very much
like the instance for MonadTrans. Let's see:

instance MonadTransControl (StateT s) where
liftControl f = StateT $ \s → liftM (\x → (x, s)) (f run)

So what is this run function? Let's look at its type:

type Run t n o = ∀ b. t n b → n (t o b)

The run function executes a transformed monadic action 't n b' in the
non-transformed monad 'n'. In our case the 't' will be a StateT
computation. The only way to run a StateT computation is to give it
some state and the only state we have lying around is the one from the
outer computation: 's'. So let's run it on 's':

instance MonadTransControl (StateT s) where
liftControl f =
StateT $ \s →
  let run t = ... runStateT t s ...
  in liftM (\x → (x, s)) (f run)

Now that we are able to run a transformed monadic action, we're almost
done. Look at the type of Run again. The function should leave the
result 't o b' in the monad 'n'. This 't o b' computation should
contain the final state after running the supplied 't n b'
computation. In case of our StateT it should contain the final state
s':

instance MonadTransControl (StateT s) where
liftControl f =
StateT $ \s →
  let run t = liftM (\(x, s') → StateT $ \_ → return (x, s'))
(runStateT t s)
  in liftM (\x → (x, s)) (f run)

This final computation, StateT $ \_ → return (x, s'), can later be
used to restore the final state. Now that we have our
MonadTransControl instance we can start using it. Recall that our goal
was to lift foo ∷ M a → M a into our StateT transformer yielding the
function foo' ∷ StateT M a → StateT M a.

To define foo', the first thing we need to do is call liftControl:

foo' t = liftControl $ \run → ...

This captures the current state of the StateT computation and provides
us with the run function that allows us to run a StateT computation on
this captured state.

Now recall the type of liftControl ∷ (Run t n o → m a) → t m a. You
can see that in place of the ... we must fill in a value of type 'm
a'. In our case this will be a value of type 'M a'. We can construct
such a value by calling foo. However, foo expects an argument of type
'M a'. Fortunately we can provide one if we convert the supplied 't'

[Haskell] ANN: case-insensitive-0.1

2011-02-06 Thread Bas van Dijk

Dear all,

I had this old module laying around that I wrote some time ago. I
dusted it off and uploaded it to Hackage:

http://hackage.haskell.org/package/case-insensitive-0.1

The package provides the module Data.CaseInsensitive which exports the
CI type constructor which can be parameterised by a string-like type
like: String, ByteString, Text, etc.. Comparisons of values of the
resulting type are then insensitive to cases.

It is my hope that one day packages like snap-core[1], http-types[2]
or wai[3] all use this common way of making strings case insensitive.

Regards,

Bas

[1] 
http://hackage.haskell.org/packages/archive/snap-core/latest/doc/html/Data-CIByteString.html
[2] 
http://hackage.haskell.org/packages/archive/http-types/0.3.0/doc/html/Network-HTTP-Types.html#t:CIByteString
[3] 
http://hackage.haskell.org/packages/archive/wai/latest/doc/html/Network-Wai.html#v:CIByteString

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: pwstore 1.0 (Secure password storage)

2011-02-06 Thread Peter Scott

Hi everyone,

If you need to store and verify passwords, the usual advice is to use
bcrypt. It neatly handles all the security issues, with a simple API. But
Haskell doesn't have bcrypt bindings, so people are tempted to roll their
own password storage methods, and perhaps get it wrong. I decided to fix
that. The pwstore library handles all the details of password storage for
you, in a way that should be so easy to use that there's no reason not to
use it.

WHAT IT DOES

You hash and salt passwords with one function, and verify user input against
these password hashes with another function. For more information, see the
API docs:

http://hackage.haskell.org/packages/archive/pwstore-fast/1.0/doc/html/Crypto-PasswordStore.html

HOW IT WORKS

The basic algorithm is this:

* Combine the user's password with a randomly-generated salt.

* Hash this slowly. By iterating SHA-256 a few thousand times, we make
brute-force guessing a lot less practical.

* Store this has along with the salt.

This scheme is essentially an implementation of the PBKDF1 key derivation
function (as specified in RFC 2898) with some convenience code around it to
make it easy to use and really hard to mess up.

WHERE TO GET IT

There are two packages on Hackage, which you can get with cabal-install:

1. pwstore-fast is the preferred version.

2. pwstore-purehaskell has the same API, but only pure Haskell dependencies.
It's usable, but about 25 times slower than pwstore-fast.

http://hackage.haskell.org/package/pwstore-fast
http://hackage.haskell.org/package/pwstore-purehaskell

The source code is on GitHub:

https://github.com/PeterScott/pwstore/

Any comments, questions, or patches are welcome.

-Peter
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: pwstore 1.0 (Secure password storage)

2011-02-06 Thread Mark Wotton

If you're going to use C anyway, why not bind bcrypt?

mark

On 07/02/2011, at 2:13 PM, Peter Scott wrote:

Hi everyone,

If you need to store and verify passwords, the usual advice is to use bcrypt.
It neatly handles all the security issues, with a simple API. But Haskell
doesn't have bcrypt bindings, so people are tempted to roll their own
password storage methods, and perhaps get it wrong. I decided to fix that.
The pwstore library handles all the details of password storage for you, in a
way that should be so easy to use that there's no reason not to use it.

WHAT IT DOES

You hash and salt passwords with one function, and verify user input against
these password hashes with another function. For more information, see the
API docs:

http://hackage.haskell.org/packages/archive/pwstore-fast/1.0/doc/html/Crypto-PasswordStore.html

HOW IT WORKS

The basic algorithm is this:

* Combine the user's password with a randomly-generated salt.

* Hash this slowly. By iterating SHA-256 a few thousand times, we make
brute-force guessing a lot less practical.

* Store this has along with the salt.

This scheme is essentially an implementation of the PBKDF1 key derivation
function (as specified in RFC 2898) with some convenience code around it to
make it easy to use and really hard to mess up.

WHERE TO GET IT

There are two packages on Hackage, which you can get with cabal-install:

1. pwstore-fast is the preferred version.

2. pwstore-purehaskell has the same API, but only pure Haskell dependencies.
It's usable, but about 25 times slower than pwstore-fast.

http://hackage.haskell.org/package/pwstore-fast
http://hackage.haskell.org/package/pwstore-purehaskell

The source code is on GitHub:

https://github.com/PeterScott/pwstore/

Any comments, questions, or patches are welcome.

-Peter
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: pwstore 1.0 (Secure password storage)

2011-02-06 Thread Thomas Davie


On 7 Feb 2011, at 03:23, Mark Wotton wrote:

 If you're going to use C anyway, why not bind bcrypt?

Better yet, bind the password storage API on platforms where it exists (e.g. 
keychain access on OS X)

Tom Davie


___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: Announce: ~Haskell 2011

2011-02-06 Thread Ian Lynagh

On Fri, Jan 07, 2011 at 06:39:11PM +, Malcolm Wallace wrote:

  (b) this delta will be applied to the 2010 Report to form a new  
 baseline;

Did this happen? If so, where is it?

I only found:
http://darcs.haskell.org/haskell-prime-report/
which hasn't had a patch since Jul 21 2009, and:
http://darcs.haskell.org/haskell98-report/
http://darcs.haskell.org/haskell2010-report/
which are for older versions of the standard.

  (a) we wish to accept the NoDatatypeContexts proposal
  http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts

Shouldn't
http://hackage.haskell.org/trac/haskell-prime/ticket/139
be state accepted and closed now, then?


Thanks
Ian


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime

46 matches

Mail list logo