I keep on experimenting with Elerea. I'm on my way to achieve a simple
Pong
game, but the display is awfully jerky, however the sampling occurs on
average every 0,0015 sec, which gives 670 FPS.
I had a similar experience under Windows. Never really got to find out
why it happened. You might
I had a similar experience under Windows. Never really got to find out
why it happened. You might try adding a short threadDelay call in your
main loop and see what happens; I think it helped back then.
Wow... it's even worse. Even with a threadDelay of 1ms the FPS drop down to
a chaotic 20~30.
I
I forgot to say: I run Ubuntu 10.10 (32bits), and I use HGL for the
graphics, not GLFW. This may be important since HGL seems to react badly
to threadDelay
Oh, HGL! The Yampa Arcade example (SpaceInvaders) suffered from the same
problem, and it was solved by adding the -threaded switch. Without
Hello,
I keep on experimenting with Elerea. I'm on my way to achieve a simple Pong
game, but the display is awfully jerky, however the sampling occurs on
average every 0,0015 sec, which gives 670 FPS.
All the elerea-examples run perfectly fine on my computer, however I use
FRP.Elerea.Param, which
fromList :: [a] - SignalGen (Signal a)
fromList xs =
stateful xs tail = memo . fmap head
1) It does what I want, but is it the good way to do it?
Yes, I'd do it the same way, assuming that the input is always an
infinite list (so this version should probably be called
unsafeFromList...).
Thanks for your answers. In fact I tried to use Simple with a clock signal
and it's painful to pass it wherever you need it. Param is much more
practical.
I like Elerea, I tried Reactive and Yampa, and I found them (especially
Yampa) heavy and not very practical.
The fact that Elerea is
Patai, I read your paper on Elerea. It wasn't easy :), but I think I got the
picture.
So I would have 2 questions :
I made a simple function which turns an infinite list into a signal :
fromList :: [a] - SignalGen (Signal a)
fromList xs =
stateful xs tail = memo . fmap head
1) It does what I
Thanks you all for your links,
I will read this.
However, Brent, I fail to understand your implementation of Monad... I
understand the purpose, but not the algorithm.
2010/12/18 Matthew Sottile mjsott...@mac.com
Hi-
This may be of some interest:
Okay, I started to experiment things, and I came to some remarks:
First, I cannot use bare lists, because of the way their Applicative
instance is declared.
I have to use the newtype ZipList (in Control.Applicative).
So I have roughly this :
import Control.Applicative
newtype AgentSig a =
On Thu, Dec 16, 2010 at 06:52:58PM +0100, Yves Parès wrote:
Okay, I started to experiment things, and I came to some remarks:
First, I cannot use bare lists, because of the way their Applicative
instance is declared.
I have to use the newtype ZipList (in Control.Applicative).
So I have
So in the result of (a = f), the first element is taken from the
first element of applying f to the first element of a; the second
element is the second element in the result of applying f to the second
element of a; and so on. Off the top of my head I am not sure what
this corresponds to in
Hello Café,
I was wondering if using infinite lists was a viable and efficient solution
in haskell programs (I mean not simple prototypes) :
I was considering using them to model agents in a hierarchical multi-agent
application for school.
A list would representate the state of an agent at a step
On Wed, Dec 15, 2010 at 02:52:11PM +0100, Yves Parès wrote:
Hello Café,
So is it viable or would the use of multiple infinite lists kill the
performances?
Sounds perfectly reasonable to me. I don't see any reason why using
multiple infinite lists would have anything to do with the
try to compute their length
Yes ^^, that's silly.
I don't see any reason why using multiple infinite lists would have
anything to do with the performance
That's comforting. Well, it seems to be a very simple, haskellish and
elegant solution, so basic pragmatism -- with an slice of pessimism
It sounds like a good fit for your problem as stated. One thing to note
is that Haskell will give you great abstractions for very strong amounts
of code, as long as what you want to do is a good fit for the abstraction.
Haskell makes it quite hard to fit a square peg into a round hole, so
if one
if one day you decide you need an agent that generates random numbers
I could say that my agents now run in a certain monad, I just would have to
transform my basic agents to :
agent1 = liftM . fmap (*2)
(or even agen1 = fmap . fmap (*2), however it is less readable IMO)
Thanks for your
On Wed, Dec 15, 2010 at 06:38:04PM +0100, Yves Parès wrote:
try to compute their length
Yes ^^, that's silly.
I don't see any reason why using multiple infinite lists would have
anything to do with the performance
That's comforting. Well, it seems to be a very simple, haskellish and
Excerpts from Yves Parès's message of Wed Dec 15 13:28:11 -0500 2010:
if one day you decide you need an agent that generates random numbers
I could say that my agents now run in a certain monad, I just would have to
transform my basic agents to :
agent1 = liftM . fmap (*2)
(or even agen1
18 matches
Mail list logo
