On Sun, Mar 17, 2013 at 3:08 PM, C K Kashyap ckkash...@gmail.com wrote:
It's a small snippet and I've put in the comments stating how I run into
out of file handles or simply file not getting read due to lazy IO.
I realize that putting ($!) using a trial/error approach is going to be
futile.
On 16.03.2013 13:31, Azeem -ul-Hasan wrote:
Nope that isn't the case either. Even if I make use of defaultSeed
through create the problem still remains. The problem seems to be in the
generation of a vector of (a,a) i.e in the part
V.generateM ((round $ p*(fromIntegral $ l*z)) `div` 2) (\i-
I am using
GHC 7.6.1
mwc-random 0.12.0.1
vector 0.9.1
primitive 0.4.1
Azeem
On 16.03.2013 13:31, Azeem -ul-Hasan wrote:
Nope that isn't the case either. Even if I make use of defaultSeed
through create the problem still remains. The problem seems to be in the
generation of a
One thing that typically isn't mentioned in these situations is that
you can add more laziness. I'm unsure if it would work from just your
snippet, but it might.
The core problem is that something like:
mapM readFile names
will open all the files at once. Applying any processing to the file
Aleksey Khudyakov alexey.skladnoy at gmail.com writes:
I've tried to run you program and I've got approximately same results
regardless of optimization level. Which versions of GHC, mwc-random,
vector and primitive do you use?
By approximate do you mean you are getting Monte Carlo noise
Hi Kashyap,
you could also use iteratees or conduits for a task like that. The beauty
of such libraries is that they can ensure that a resource is always
properly disposed of. See this simple example:
https://gist.github.com/anonymous/5183107
It prints the first line of each file given as an
Hi,
I was reading the paper A History of Haskell: being lazy with class (
http://www.haskell.org/haskellwiki/History_of_Haskel) and came on a section
(I 2.1) which briefly explained the work people did on making non-von
Neumann architectures.
It concluded by saying
Much (but not all) of this
On Sun, Mar 17, 2013 at 5:56 PM, OWP owpmail...@gmail.com wrote:
These stock architectures, were they really so good that they out
performed the specialized ones on it's own merits or was this mainly due to
Moore's Law on transistors? In other words, suppose we separate Moore's Law
from the
Hey Jesper:
hrm... have you tried other compilation / ffi choices that can influence
the function call?
eg: using the safe rather than unsafe modifier?
http://www.haskell.org/haskellwiki/GHC/Using_the_FFI#Introduction
(the safe modifier doesn't seem like it matters here, but its a simple
Hello,
Unfortunately I don't have much to add.
On Wed, Mar 13, 2013 at 9:51 PM, Jesper Särnesjö sarne...@gmail.com wrote:
Hi everybody,
This started out on haskell-beginners, as a question about poor
performance for a Haskell program using OpenGL. Thanks to a few good
suggestions there,
On Sat, Mar 16, 2013 at 6:53 PM, Jesper Särnesjö sarne...@gmail.com wrote:
To be clear, I think this isn't really an OpenGL problem, but rather
one related to FFI or event handling. If anyone could explain to me,
in general, how and why a call to a foreign function returning IO ()
might
On Sun, Mar 17, 2013 at 7:58 PM, Jason Dagit dag...@gmail.com wrote:
On Sat, Mar 16, 2013 at 6:53 PM, Jesper Särnesjö sarne...@gmail.comwrote:
To be clear, I think this isn't really an OpenGL problem, but rather
one related to FFI or event handling. If anyone could explain to me,The
release
Thanks everyone,
Dan, MapMI worked for me ...
Regards,
Kashyap
On Mon, Mar 18, 2013 at 12:42 AM, Petr Pudlák petr@gmail.com wrote:
Hi Kashyap,
you could also use iteratees or conduits for a task like that. The beauty
of such libraries is that they can ensure that a resource is always
13 matches
Mail list logo
