- Libraries - Haskell.org

FW: Cross platform file manipulations
by Simon Peyton-Jones 24 Jul '10

24 Jul '10

Libraries folk: please respond to Kazu's questions. Kazu: there is a standardisation process, for proposing library changes, described here: http://www.haskell.org/haskellwiki/Library_submissions Simon -----Original Message----- From: Kazu Yamamoto [mailto:kazu@iij.ad.jp] Sent: 22 July 2010 03:38 To: Simon Peyton-Jones Subject: Cross platform file manipulations Hello Simon, I have posted this to Haskell cafe but I did not have good responses. So, I need your suggestion. I'm converting my Ruby script to Haskell. I found several problems of Haskell which does not exist in another script languages: - getModificationTime exists in System.Directory. But getAccessTime, getStatusChangeTime, getCreationTime do not exist. - getModificationTime returns obsoleted type, ClockTime. It should return modern type, UTCTime, I believe. - Path separator is not unified. Even though Windows accepts '/' as a file separator, getCurrentDirectory in System.Directory returns '\\' as a file separator. So, we need to specify regular expression like this: "[/\\]foo[/\\]bar[/\\]baz". - getHomeDirectory returns HOMEDRIVE/HOMEPATH instead of the HOME environment variable on Windows. To fix these portability problems, I'm creating cross platform library to manipulate files: http://github.com/kazu-yamamoto/file Here are questions: 1) I use System.File as module name at this momoent. Is this too radical? Should I use System.EasyFile or System.PortableFile? 2) Are there any standardization process for this? Should I wait for the conclusion before releasing this package? Or can I register the package to hackageDB whenever I like? 3) Do you know other people who are interested in this area? Thanks in advance. --Kazu

2 1

"New FGL" naming survey
by Ivan Lazar Miljenovic 24 Jul '10

24 Jul '10

Whether or not the new FGL that Thomas Bereknyei and I are working on should keep the name was a semi-hot issue when we first mentioned the fact that we were working on a new version about a month ago. As such, I've created a survey here to try and find out what the Haskell community overall thinks we should call it: https://spreadsheets.google.com/viewform?formkey=dGpzMmFnUWY3Uktodk5wdHlLQk… More info can be found on the actual survey page. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

2 2

ANNOUNCE: Haskell Platform 2010.2.0.0
by Don Stewart 23 Jul '10

23 Jul '10

We're pleased to announce the fifth release of the Haskell Platform: a single, standard Haskell distribution for everyone. Download the Haskell Platform 2010.2.0.0: http://hackage.haskell.org.nyud.net/platform/ (Caching server). The specification, along with installers (including Windows, Apple and Unix installers for a full Haskell environment) are available. The Haskell Platform is a single, standard Haskell distribution for every system, in the form of a blessed library and tool suite for Haskell distilled from the thousands of libraries on Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. When you install the Haskell Platform, you get the latest stable compiler, an expanded set of core libraries, additional development tools, and cabal-install – so you can download anything else you need from Hackage. What you get is specified here: http://hackage.haskell.org/platform/contents.html Thanks! -- The Platform Infrastructure Team

1 0

Re: #4159: move Monad and MonadFix instances for Either from mtl to base
by John Lato 22 Jul '10

22 Jul '10

> From: Ross Paterson <ross(a)soi.city.ac.uk> > > On Thu, Jul 01, 2010 at 11:35:24AM +0100, Simon Marlow wrote: >> I don't know all the ins and outs of the discussion here, but before >> proposing to reverse this decision someone should do a careful >> assessment of the prior rationale and results of subsequent >> experience. > > The general question of fail is a side issue -- the question here is > just whether the Monad instance for Either should define fail, and if > so to what. I think it should not define fail (or define it to error). I've never been happy with the semantics of this instance. I thought the point of Either was that neither value had any special meaning attached to it, and in particular that "Left" and "Right" were chosen as being free of any connotations of correct, incorrect, or other. Defining fail as "Left x" seems wrong because it codifies the left value as an error. In my opinion those semantics belong to another type. John

8 12

darcs patch: Lower depends down to match ghc-6.8
by Sergei Trofimovich 22 Jul '10

22 Jul '10

1 patch for repository http://darcs.haskell.org/packages/parallel: Thu Jul 22 07:48:25 EEST 2010 Sergei Trofimovich <slyfox(a)community.haskell.org> * Lower depends down to match ghc-6.8

1 0

darcs patch: Lower depends down to match ghc-6.8
by Sergei Trofimovich 22 Jul '10

22 Jul '10

1 patch for repository http://darcs.haskell.org/packages/deepseq: Thu Jul 22 07:29:51 EEST 2010 Sergei Trofimovich <slyfox(a)community.haskell.org> * Lower depends down to match ghc-6.8 tested on ghc-6.8.2: Prelude Control.DeepSeq> let a = [1..] Prelude Control.DeepSeq> a `deepseq` 1 <hung> Prelude Control.DeepSeq> let a = [1..100] Prelude Control.DeepSeq> a `deepseq` 1 1

1 0

Re: [GHC] #4192: Proposed process piping function to be added to the "process" package
by Dimitry Golubovsky 20 Jul '10

20 Jul '10

Ian, > Changes (by igloo): > > * milestone: => Not GHC > > > Comment: > > Did you post to the mailing list about this? I can't see a thread. Now posting (I thought a ticket would create a thread automatically...) > > Something that jumps out at me is: What about stderr? The pipe is built of pre-created CreateProcess structures which have to have something in their stderr fields (most likely, Inherit). The function I propose does not touch that. Thanks. -- Dimitry Golubovsky Anywhere on the Web

1 0

[GHC] #4192: Proposed process piping function to be added to the "process" package
by Dimitry Golubovsky 20 Jul '10

20 Jul '10

Forwarding the proposal ticket to the mailing list ---------- Forwarded message ---------- From: GHC <cvs-ghc(a)haskell.org> Date: Jul 14, 2010 11:55 PM Subject: [GHC] #4192: Proposed process piping function to be added to the "process" package To: Cc: glasgow-haskell-bugs(a)haskell.org #4192: Proposed process piping function to be added to the "process" package ---------------------------------+------------------------------------------ Reporter: golubovsky | Owner: Type: proposal | Status: new Priority: normal | Component: libraries/process Version: 6.12.3 | Keywords: pipe Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown ---------------------------------+------------------------------------------ Hi, I'd like to propose the following function to be added to the System.Process module (see attached). This function allows for easy piping processes together using their CreateProcess descriptors. The existing "Pipe" package [1] provides similar functionality, yet without access to CreateProcess structures (thus no separate environment tuning, etc.) The function was tested in capri and hsffig. [1] http://hackage.haskell.org/package/Pipe -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler -- Dimitry Golubovsky Anywhere on the Web

1 0

cryptohash and an incremental API
by Thomas DuBuisson 20 Jul '10

20 Jul '10

Sorry for the double Vincent, forgot to include libraries(a)h.o > Just a quick stab in the dark, what about in the class a "hashName :: String" ? > it would be easy to have in DRBG a function that match name to strength: I've considered something more like data HashName = Tiger | MD5 | SHA1 | SHA256 | ... | OtherHash String hashName :: HashName Forcing a standardized name so tools such as DRBG won't have to guess or try to normalize: (`elem` ["SHA2-256", "SHA-256", "SHA256" ]) . map toUpper . filter (not . isSpace)) > Regardless of either strength is implemented this way or not, would that be a > good idea to have a name field for ciphers and hashes ? Its been I thought but one I'm not convinced of enough yet because we either have a problem of name standardization or crypto-api enumerating hashes. [wrt IVs] > That's still sounds quite odd. When initializing my IVs usually, this is not > something randomly generated, but something known on both side. So for an example IPSec with AES CBC we have a ByteString of IV ++ Ciphertext: decryptRFC3602 :: (BlockCipher k) => k -> B.ByteString -> Maybe (B.ByteString) decryptRFC3602 ctInfo = let m = runGetState get ctInfo 0 in case m of Left err -> Nothing -- Serialize decode error getting IV Right (iv,ct) -> snd (unCbc k iv ct) In IPSec the IV is randomly generated by the encryptor, so the 'getIV' method might be of use (or just use "liftM decode $ readFile "/dev/urandom"). If both sides know an IV they wish to start with void of any randomness then the job is even simpler: encryptCBCknownIV :: (BlockCipher k) => k -> Bytestring -> ByteString encryptCBCknownIV k pt = let iv = decode $ Lazy.pack [0..] in snd (cbc k iv pt) decryptCBCknownIV k ct = let iv = decode $ Lazy.pack [0..] in snd (unCbc k iv ct) > To me an IV should just be a function of a input byteString, and that let the > application of the interface pull the IV bytes from any place it need to. crypto-api is giving the developer certainty that any "iv :: IV k" is "blockSize `for` k" bits long - which is a nice guarantee. The cost is that people wanting non-random IVs need to place their IV in a bytestring and decode it via cereal or binary - not a high cost. Cheers, Thomas

1 0

Re: cryptohash and an incremental API
by Thomas DuBuisson 20 Jul '10

20 Jul '10

On Thu, Jul 15, 2010 at 2:24 PM, Vincent Hanquez <tab(a)snarc.org> wrote: [Re: Semantics of Hash "updateCtx" and my desire for semantics option 1.2 (replacing my original preference for semantics 1.1) > > I'm not sure which document you are refering to here. http://www.haskell.org/pipermail/libraries/2010-June/013782.html > While thinking about it, i'm not sure if tracking the remainder should be left > at the higher level; The change will trickle through the finalize function, > which might not be very pratical. I'm not a fan of changing the API because some particular C bindings would be inconvenienced. I can sympathize but it doesn't seem like a strong enough argument when the argument on the other side is that we are removing duplicate code from all hash implementations. Anyone else reading? Could other people weigh in on this issue too? [Re: 'strength' field of the Hash class] > indeed, just that strenght looks like a warm-fuzzy-feeling value, that might be > wrongly used to choose a hash algorithm automatically or something. Otherwise i > really don't mind. I'm considering this, how its loss would impact DRBG, and how many (if any) other libraries can make any reasonable use of "strength" without being overly dumb about its use. Still tempted to keep it, bad users of hashes can always be bad without our help anyway. >> buildIV :: (BlockCipher k, MonadRandom m) => m (IV k) > > I'm not sure i understand this however. In particular the MonadRandom bits, > why is it there ? Is this pulling bits from a random generator to construct an > iv ? Right, this was my turn to be dumb. I just now implemented it as: getIV :: RandomGen g => g -> (IV k, g) So yes, I'm pulling bits from an RNG to construct an IV but we should avoid the dependency on MonadRandom. If someone doesn't like RandomGen then they can always build a random bytestring of sufficient length (using whatever method) and run Data.Serialize.decode. [re: the RC4 implementation and StreamCipher class] > No, it's not hackage yet, I'll clean it up and put somewhere accessible in the > next couple of days. I'm not sure I can be considered a stream cipher expert > yet though. I'll try to gather some different algorithms implementation to see > how it can be generalized to. Sounds good. Cheers, Thomas

2 1