I'd like to use AES in a haskell program that I'm writing. I've come
across three libraries in hackage that do AES: the library named AES,
the Crypto library, and the SimpleAES library. The library named AES
says in its documentation for the crypt function that it is not
thread-safe. What
By my reading of the documentation of the AES package in hackage
(http://hackage.haskell.org/packages/archive/AES/0.2.7/doc/html/Codec-Crypto-AES.html),
the sizes of the strict bytestring chunks of the lazy bytestring given
to crypt must be multiples of 16 bytes or the resulting output will
act as
I have a streaming network protocol where each message in the stream
is prefixed by a 64-bit message length marker. Lazy ByteStrings seem
to be an elegant way to wrap network communications, so I'm using
them. I have one concern though: how can I prevent my program from
hanging on to the
No, that need not be. If the compiler sees that it's never referenced
again, it can be garbage collected (assuming the consumption pattern of msg
allows that to be garbage collected incrementally).
Try out whether your programme has a space leak by giving it a long input.
If it has, ask
The wiki page for Haskell Platform is still listing March 5 (today) as
the planned release date. Is this still the plan, or should the page
be updated?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
We're currently testing the installers, with a view to announcing the
release early in the week.
Very cool. Thanks!
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
In my code, I'm doing this quite a lot:
x - someIO
case x of
Opt1 - ...
Having a line for extracting the value from the IO (or STM) and then
acting on the value seems unnatural. Is there a more concise way to
do this? This code:
case someIO of
Opt1 - ...
Doesn't work, but is there
See this
thread: http://www.haskell.org/pipermail/haskell-cafe/2010-October/084291.html
Which links to http://hackage.haskell.org/trac/ghc/ticket/4359 .
Looks like there's already been quite a bit of discussion on this
already :) Thanks for the link.
If you have only one alternative, then you can simply do:
Opt1 - someIO
E.g., if you are _sure_ that foo returns always a 'Just' within a monad you
can perfectly do :
Just x - foo
That's interesting. I had no idea that one could do that. I think
what I'm looking for is something along
I'm trying to write a rolling window variation of the adler32 hash
function (here: https://gist.github.com/1011151), and I got it to a
nearly acceptable speed under ghc 6.12.3 (~35MB/s on my work machine),
so I thought I'd see how the new ghc 7.0.3 treated it. The answer is
not good. I get about
Right now, I'd just like to have the code run
quickly, and to figure out why I'm seeing such a terrible regression
under ghc7.
From the #haskell channel, it looks like the horrible speed issue on
this code is specific to my system. I'm re-building ghc7 now
(bootstrapping ghc7 with ghc7
From the #haskell channel, it looks like the horrible speed issue on
this code is specific to my system. I'm re-building ghc7 now
(bootstrapping ghc7 with ghc7 instead of ghc6), so maybe that will
make something happier.
FWIW, rebuilding ghc7 using ghc7 as the bootstrapping implementation
Oh, you built with ghcquickbuild? I don't remember the details, but
if memory serves it disables a lot of optimisations, etc. just to get
GHC built quicker to test that it compiles. So you probably don't
want that ;-)
That's good to know. It's too bad there doesn't seem to be a warning
in
I'm trying to write a program whose network behaviour is analogous to
a web proxy. A client connects to my server and gives me some data,
my server connects to an upstream server and gives data to it, my
server gets data from upstream, and gives data to the client. I'd
like to write this using
For this specific problem I recommend using a forkIO'd
Iteratee/Enumerator pair with a Chan to shuttle data between them, I
think it's probably the best way of doing it.
Googling for enumerator chan gives me this gist (written by you in
April): https://gist.github.com/932384 . Is that what
I'm trying to write what I think should be a simple Enumeratee, but
I'm just not having any luck getting it to typecheck, and I'm coming
to the realization that I still have no idea what I'm doing. The
essential thing I want to do is adapt
Data.Enumerator.List.concatMapAccum so that the
Well, I got it working. It seems to behave sanely when put in a chain
with other Enumeratee/Iteratee combinations, so I'm happy. My
solution is posted on hpaste: http://hpaste.org/51430 . I'd love any
criticism that anybody has, especially since it seems to me to be an
ideal building block for
What sorts of things can cause a thread to get an asynchronous thread
killed exception? I've been seeing rare, inexplicable thread
killed messages in my Snap handlers for a long time, but they aren't
from Snap's timeout code. I recently upgraded to ghc 7.4.1, and that
caused the kills to happen
That's probably not where the threadKill is being sent *from*, it's where
your thread received it.
Yeah, it's definitely where my thread received it. It's just sort of
crazy, because when I get a ThreadKilled, it's almost always in
Tiger.update. My handler does much slower things, such as
This is a long shot, but it's easy to test - turn off GHC's RTS timer,
+RTS -V0 -RTS. That removes a source of SIGALRM interrupts.
Awesome, I'll give that a try. It's worth a shot, anyhow :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
This is a long shot, but it's easy to test - turn off GHC's RTS timer,
+RTS -V0 -RTS. That removes a source of SIGALRM interrupts.
I was really hoping this one would reveal something interesting, but
it seems to have no effect. Thanks for the hint though.
It's hard to rule Snap timeouts out; try building snap-core with the
-fdebug flag and running your app with DEBUG=1, you'll get a spew of
debugging output from Snap on stderr.
Heh, that was quite a spew. I normally get the exceptions tens of MB
into files that are hundreds of MB, and I
My Snap handlers communicate with various resource pools, often
through MVars. Is it possible that MVar deadlock would be causing the
runtime system to kill off a contending thread, giving it a
ThreadKilled exception? It looks like ghc does do deadlock detection,
but I can't find any docs on how
Whenever I've deadlocked, it terminated the program with thread
blocked indefinitely in an MVar operation.
Well, I guess that's probably not what I'm seeing. I'm currently
trying to simplify the heck out of the code that near where the thread
killed exceptions are emanating; maybe once that's
I think I might know what your problem is. You're accepting file uploads
using handleMultipart, yes? Snap kills uploads that are going too slow,
otherwise you would be vulnerable to slowloris
(http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here
is that you're doing
I think I might know what your problem is. You're accepting file uploads
using handleMultipart, yes? Snap kills uploads that are going too slow,
otherwise you would be vulnerable to slowloris
(http://ha.ckers.org/slowloris/) DoS attacks. What's probably happening here
is that you're doing
Is there anything in Criterion that allows for a benchmark to run some
code before or after the thing that it's timing? As an example, I'd
like to time a bunch of database inserts, but beforehand I want to
create the target table, and afterwards I'd like to delete it. I
don't really care to have
See the second argument of defaultMainWith
http://hackage.haskell.org/packages/archive/criterion/0.6.0.0/doc/html/Criterion-Main.html#v:defaultMainWith.
the prep argument is run before the entire suite is run (i.e. once
per criterion main invocation); I'm looking for some way to run code
before
28 matches
Mail list logo
