Re: [Haskell-cafe] [reactive] A pong and integrate
The GHC bugs are now fixed, so it might be stable enough for another adventure like that, but I don't think I would bet on it again. GHC bugs are corrected, but Reactive still have some. (See my previous posts) IMO Haskell is great for writing small clean prototypes, doing interesting research, and maybe making some fun little games, but I wouldn't use it for production reactive game coding, not yet at least. Tim Sweeney (from Epic Games) has another perspective about that [1]. Besides, FRP is not mandatory. You can always make games in Haskell by using a more regular style (more imperative, would some say). For now, the main problem is the small number of Haskell libraries for games when compared to the huge numbers of those which exist in C++, which prevents, for now, Haskell to be used as the main language for big commercial games. But for smaller scale games (like indie), which have less needs, I think it's worth it. [1] http://www.scribd.com/doc/5687/The-Next-Mainstream-Programming-Language-A-Game-Developers-Perspective-by-Tim-Sweeney 2010/5/25 Peter Verswyvelen bugf...@gmail.com Well, first of all, I did not make these PS3 visualization, my former colleagues and I just made the editor, language and runtime that allowed video game artists to do the job for us in a couple of weeks time :-) I wouldn't use Yampa, for performance reasons, and difficulty to get it running on alien platforms (it is well known it performs relatively badly, although the work done by Paul Liu and co on Causal Commutative Arrows looks very promising, but does not support dynamic switching yet). After all, Yampa models a synchronous dataflow language, and compilers for these languages are relatively easy to make IMO. My previous - now defunct - company Anygma spent a lot of money on trying to use Haskell and Reactive for game programming, which unfortunately ended in some nasty GHC bugs popping up (see http://www.haskell.org/haskellwiki/Unamb), and not all problems with Reactive got fixed; it is amazing how difficult this all turned out to be. The GHC bugs are now fixed, so it might be stable enough for another adventure like that, but I don't think I would bet on it again. IMO Haskell is great for writing small clean prototypes, doing interesting research, and maybe making some fun little games, but I wouldn't use it for production reactive game coding, not yet at least. On Tue, May 25, 2010 at 10:49 AM, Limestraël limestr...@gmail.com wrote: Wow... impressive... And now, with your experience, if you'd have to do this again, would you use Yampa or stick up with C#/C++ ? 2010/5/24 Peter Verswyvelen bugf...@gmail.com Yeah. Funny that we're still writing games in C++, while mission critical and hard real time systems are written in much nicer languages :) I made something similar to Lucid Synchrone for a game company I used to work, but with the purpose of making reactive programming accessible to computer artists. The integrated development environment provided the typical boxes-and-links user interface, where the boxes were signal functions. Signals itself were not exposed, like Yampa. The system did type inference so artists never really had to deal with types. Special nodes like feedback and delay where provided to allow transferring values to the next frame. This actually was a great success, digital artists could literally create little interactive applications with it, without much help from programmers. This resulted in a Playstation 3 visual experience Mesmerize (http://www.youtube.com/watch?v=rW7qGhBjwhY). This was before I knew Haskell or functional programming, so it was hacked together in C# and C++... I still believe that the reason why computers artists could work with this environment and were not able to learn imperative programming is functional programming itself: the system had all the goodies of FP: type inference, referential transparancy, etc... But is also provided the possibility to edit literals while the simulation was running, providing zero turnaround times, which was equally important for quick adoption of the software. So IMO Haskell and FRP systems have a huge potential for education of a much broader audience than just computer scientists... On Mon, May 24, 2010 at 6:13 PM, Limestraël limestr...@gmail.com wrote: I assumed also that it was a field which was still under research, however, Lustre, again, is used for critical control software in aircraft, helicopters, and nuclear power plants, according to wikipedia. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] [reactive] A pong and integrate
I work in the games industry and I'm also not convinced of the Haskell+FRP path for games, but for different reasons. I am very fond of Haskell for games however, and think it is achievable. Regarding FRP, I don't think it is the right framework to base a game on. It's great for some stuff, particularly the kind of problem Peter demonstrated, but games are a lot more varied than that and efficiency concerns aside, it's just not the right approach for everything. I see it more as a useful tool for some elements than a framework that should form the backbone of a game. Functional programming on the other hand is a big thing. Games look a lot more functional now days than they ever did before, and C++ doesn't have the right vocabulary to allow you to scratch this itch properly. EDSLs, parallelism, composability, higher order functions, and static typing are really where it's at, and Haskell excels at this. There's a lot of missed opportunities for more elegant and powerful architectures going by at the moment simple because it's not realistic to attempt them in C/C++. One area where Haskell is not so hot and needs a bit of TLC is it's 'embedability'. A large cross-platform 100% Haskell game is not on the cards at the moment, but Haskell could start getting its hands dirty, if only it could be sensibly embedded within an otherwise C++ app. This would allow people to start to take advantage of it, without some wholesale switch over. However, to do this, Haskell implementations at least need to be more compiler and platform agnostic, and we would probably need a lot more control over the Haskell runtime itself, particularly wrt memory handling. Lua (which is very popular in the games industry) and ATS (which isn't used to my knowledge, but has excellent interaction with C) are good examples of languages where this kind of thing is considerably easier. Haskell would have to fit in differently to this, but that's the kind of idea. Interesting things to note are that in this scenario, you could probably ditch IO altogether and just embed 'pure' Haskell. Games have very limited IO which would likely be best handed in C++ anyway. Laziness/space leaks, garbage collection and general performance concerns are obviously also issues, but that's for another day J Cheers, Sam From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Limestraël Sent: 26 May 2010 08:52 To: Peter Verswyvelen Cc: haskell-cafe@haskell.org; Patai Gergely Subject: Re: [Haskell-cafe] [reactive] A pong and integrate The GHC bugs are now fixed, so it might be stable enough for another adventure like that, but I don't think I would bet on it again. GHC bugs are corrected, but Reactive still have some. (See my previous posts) IMO Haskell is great for writing small clean prototypes, doing interesting research, and maybe making some fun little games, but I wouldn't use it for production reactive game coding, not yet at least. Tim Sweeney (from Epic Games) has another perspective about that [1]. Besides, FRP is not mandatory. You can always make games in Haskell by using a more regular style (more imperative, would some say). For now, the main problem is the small number of Haskell libraries for games when compared to the huge numbers of those which exist in C++, which prevents, for now, Haskell to be used as the main language for big commercial games. But for smaller scale games (like indie), which have less needs, I think it's worth it. [1] http://www.scribd.com/doc/5687/The-Next-Mainstream-Programming-Language-A-Game-Developers-Perspective-by-Tim-Sweeney 2010/5/25 Peter Verswyvelen bugf...@gmail.com Well, first of all, I did not make these PS3 visualization, my former colleagues and I just made the editor, language and runtime that allowed video game artists to do the job for us in a couple of weeks time :-) I wouldn't use Yampa, for performance reasons, and difficulty to get it running on alien platforms (it is well known it performs relatively badly, although the work done by Paul Liu and co on Causal Commutative Arrows looks very promising, but does not support dynamic switching yet). After all, Yampa models a synchronous dataflow language, and compilers for these languages are relatively easy to make IMO. My previous - now defunct - company Anygma spent a lot of money on trying to use Haskell and Reactive for game programming, which unfortunately ended in some nasty GHC bugs popping up (see http://www.haskell.org/haskellwiki/Unamb), and not all problems with Reactive got fixed; it is amazing how difficult this all turned out to be. The GHC bugs are now fixed, so it might be stable enough for another adventure like that, but I don't think I would bet on it again. IMO Haskell is great for writing small clean prototypes, doing interesting research, and maybe making some fun little games, but I wouldn't use it for production reactive
Re: [Haskell-cafe] [reactive] A pong and integrate
On Wed, May 26, 2010 at 6:19 AM, Sam Martin sam.mar...@geomerics.comwrote: There’s a lot of missed opportunities for more elegant and powerful architectures going by at the moment simple because it’s not realistic to attempt them in C/C++. I beg to differ on that point. See my presentation[1]/paper[2] I gave at boostcon a couple weeks ago. I have successfully used C++ as a functional language in multiple production software applications, including FRP designs. [1] http://www.filetolink.com/c109d02b [2] http://www.filetolink.com/ff94ea7e David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Well, this does not contradict Sam's point, which was that you may have written nicer, faster and more elegant code in way less time, had you used a true programming language ;-) El 26/05/2010, a las 12:28, David Sankel escribió: On Wed, May 26, 2010 at 6:19 AM, Sam Martin sam.mar...@geomerics.com wrote: There’s a lot of missed opportunities for more elegant and powerful architectures going by at the moment simple because it’s not realistic to attempt them in C/C++. I beg to differ on that point. See my presentation[1]/paper[2] I gave at boostcon a couple weeks ago. I have successfully used C++ as a functional language in multiple production software applications, including FRP designs. [1] http://www.filetolink.com/c109d02b [2] http://www.filetolink.com/ff94ea7e David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Wow... impressive... And now, with your experience, if you'd have to do this again, would you use Yampa or stick up with C#/C++ ? 2010/5/24 Peter Verswyvelen bugf...@gmail.com Yeah. Funny that we're still writing games in C++, while mission critical and hard real time systems are written in much nicer languages :) I made something similar to Lucid Synchrone for a game company I used to work, but with the purpose of making reactive programming accessible to computer artists. The integrated development environment provided the typical boxes-and-links user interface, where the boxes were signal functions. Signals itself were not exposed, like Yampa. The system did type inference so artists never really had to deal with types. Special nodes like feedback and delay where provided to allow transferring values to the next frame. This actually was a great success, digital artists could literally create little interactive applications with it, without much help from programmers. This resulted in a Playstation 3 visual experience Mesmerize (http://www.youtube.com/watch?v=rW7qGhBjwhY). This was before I knew Haskell or functional programming, so it was hacked together in C# and C++... I still believe that the reason why computers artists could work with this environment and were not able to learn imperative programming is functional programming itself: the system had all the goodies of FP: type inference, referential transparancy, etc... But is also provided the possibility to edit literals while the simulation was running, providing zero turnaround times, which was equally important for quick adoption of the software. So IMO Haskell and FRP systems have a huge potential for education of a much broader audience than just computer scientists... On Mon, May 24, 2010 at 6:13 PM, Limestraël limestr...@gmail.com wrote: I assumed also that it was a field which was still under research, however, Lustre, again, is used for critical control software in aircraft, helicopters, and nuclear power plants, according to wikipedia. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Well, first of all, I did not make these PS3 visualization, my former colleagues and I just made the editor, language and runtime that allowed video game artists to do the job for us in a couple of weeks time :-) I wouldn't use Yampa, for performance reasons, and difficulty to get it running on alien platforms (it is well known it performs relatively badly, although the work done by Paul Liu and co on Causal Commutative Arrows looks very promising, but does not support dynamic switching yet). After all, Yampa models a synchronous dataflow language, and compilers for these languages are relatively easy to make IMO. My previous - now defunct - company Anygma spent a lot of money on trying to use Haskell and Reactive for game programming, which unfortunately ended in some nasty GHC bugs popping up (see http://www.haskell.org/haskellwiki/Unamb), and not all problems with Reactive got fixed; it is amazing how difficult this all turned out to be. The GHC bugs are now fixed, so it might be stable enough for another adventure like that, but I don't think I would bet on it again. IMO Haskell is great for writing small clean prototypes, doing interesting research, and maybe making some fun little games, but I wouldn't use it for production reactive game coding, not yet at least. On Tue, May 25, 2010 at 10:49 AM, Limestraël limestr...@gmail.com wrote: Wow... impressive... And now, with your experience, if you'd have to do this again, would you use Yampa or stick up with C#/C++ ? 2010/5/24 Peter Verswyvelen bugf...@gmail.com Yeah. Funny that we're still writing games in C++, while mission critical and hard real time systems are written in much nicer languages :) I made something similar to Lucid Synchrone for a game company I used to work, but with the purpose of making reactive programming accessible to computer artists. The integrated development environment provided the typical boxes-and-links user interface, where the boxes were signal functions. Signals itself were not exposed, like Yampa. The system did type inference so artists never really had to deal with types. Special nodes like feedback and delay where provided to allow transferring values to the next frame. This actually was a great success, digital artists could literally create little interactive applications with it, without much help from programmers. This resulted in a Playstation 3 visual experience Mesmerize (http://www.youtube.com/watch?v=rW7qGhBjwhY). This was before I knew Haskell or functional programming, so it was hacked together in C# and C++... I still believe that the reason why computers artists could work with this environment and were not able to learn imperative programming is functional programming itself: the system had all the goodies of FP: type inference, referential transparancy, etc... But is also provided the possibility to edit literals while the simulation was running, providing zero turnaround times, which was equally important for quick adoption of the software. So IMO Haskell and FRP systems have a huge potential for education of a much broader audience than just computer scientists... On Mon, May 24, 2010 at 6:13 PM, Limestraël limestr...@gmail.com wrote: I assumed also that it was a field which was still under research, however, Lustre, again, is used for critical control software in aircraft, helicopters, and nuclear power plants, according to wikipedia. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
IMO: For AAA game programming? Definitely not. For exploring new ways of doing game programming and having a lot of fun and frustration? Sure! For making casual games? I don't know. Why not casual games? I don't see any immediate difficulty. Do you have any particular bad experience? Limestraël: I find Elerea fine so far, but it is still experimental and more limited than Yampa. Well, it's more expressive in one way and more limited in another. Elerea lifts some limitations of Yampa by extending it with the ArrowApply/Monad interface, and you can certainly reimplement all the crazy switching combinators using the basic building blocks provided by the library. However, you cannot stop a signal in Elerea, while that's trivial in Yampa. I believe Elerea needs two more basic combinators: a simple 'untilB'-like switcher (mainly to be able to tell when a signal ends) and a freezing modifier that allows you to control the updates of a signal (or more like a whole subnetwork). The semantics of the latter is not clear to me yet (I don't intend to introduce a full-fledged clock calculus #224; la Lucid Synchrone if it's possible to avoid), and I want to work it out properly before implementing anything. Gergely -- http://www.fastmail.fm - Choose from over 50 domains or use your own ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
One problem with Elerea experimental branch besides the update time control: the memo function. I can't understand when I have to call it and when I don't. Just to know, have you been told of a language dedicated to reactive programming (even experimental)? I mean, not an embedded language just like Yampa is. 2010/5/24 Patai Gergely patai_gerg...@fastmail.fm IMO: For AAA game programming? Definitely not. For exploring new ways of doing game programming and having a lot of fun and frustration? Sure! For making casual games? I don't know. Why not casual games? I don't see any immediate difficulty. Do you have any particular bad experience? Limestraël: I find Elerea fine so far, but it is still experimental and more limited than Yampa. Well, it's more expressive in one way and more limited in another. Elerea lifts some limitations of Yampa by extending it with the ArrowApply/Monad interface, and you can certainly reimplement all the crazy switching combinators using the basic building blocks provided by the library. However, you cannot stop a signal in Elerea, while that's trivial in Yampa. I believe Elerea needs two more basic combinators: a simple 'untilB'-like switcher (mainly to be able to tell when a signal ends) and a freezing modifier that allows you to control the updates of a signal (or more like a whole subnetwork). The semantics of the latter is not clear to me yet (I don't intend to introduce a full-fledged clock calculus #224; la Lucid Synchrone if it's possible to avoid), and I want to work it out properly before implementing anything. Gergely -- http://www.fastmail.fm - Choose from over 50 domains or use your own ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
2010/5/24 Patai Gergely patai_gerg...@fastmail.fm IMO: For AAA game programming? Definitely not. For exploring new ways of doing game programming and having a lot of fun and frustration? Sure! For making casual games? I don't know. Why not casual games? I don't see any immediate difficulty. Do you have any particular bad experience? Well, I guess it is possible for casual games. Without FRP Monadius runs fine (http://www.youtube.com/watch?v=zqFgQiPKtOI), so Haskell itself seems to be realtime enough for handling the job (with .NET it used to be a problem when the garbage collector started doing a generation 2 collection; the game would stall, might be fixed in .NET 4, not sure how realtime the Haskell garbage collector is in the long run). FRAG (which uses Yampa) (http://www.youtube.com/watch?v=0jYdu2u8gAUfeature=related) also indicates it can be done. So my I don't know should have been a I think it is :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Just to know, have you been told of a language dedicated to reactive programming (even experimental)? I mean, not an embedded language just like Yampa is. Maybe Lucid Synchrone (http://www.lri.fr/~pouzet/lucid-synchrone/) and Timber (http://www.timber-lang.org)? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
One problem with Elerea experimental branch besides the update time control: the memo function. I can't understand when I have to call it and when I don't. Technically, you never have to. However, if you have a signal derived from others by pure application (i.e. fmap or *), keep in mind that its output will be recalculated as many times as you request it. The memo element can be used as a proxy to prevent that. E.g. if you have z = liftA2 f x y, and you request z n times, f will also be called n times. But if you have z - memo (liftA2 f x y) instead, then the calculation will only happen once. If Elerea wasn't an EDSL, these memo elements could be inserted automatically, but now I have no means to tell how many times a certain signal is referred to, so the burden is on the programmer. The old version doesn't have this inconvenience, because it memoises all the applicative nodes too. Since most of them are only referred to once, this is adds a lot of unnecessary overhead. Just to know, have you been told of a language dedicated to reactive programming (even experimental)? I mean, not an embedded language just like Yampa is. Those that Peter mentioned are good examples, and there is also Lustre. But you have to be aware that Elerea, Yampa, Lucid Synchrone and Lustre are all very similar in their foundations. Gergely -- http://www.fastmail.fm - The professional email service ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
But you have to be aware that Elerea, Yampa, Lucid Synchrone and Lustre are all very similar in their foundations. Okay. I just thought that reactive programming was a quite new field of research, but I saw that Lustre and Esterel date back to 1980... I assumed also that it was a field which was still under research, however, Lustre, again, is used for critical control software in aircraft, helicopters, and nuclear power plants, according to wikipedia. 2010/5/24 Patai Gergely patai_gerg...@fastmail.fm One problem with Elerea experimental branch besides the update time control: the memo function. I can't understand when I have to call it and when I don't. Technically, you never have to. However, if you have a signal derived from others by pure application (i.e. fmap or *), keep in mind that its output will be recalculated as many times as you request it. The memo element can be used as a proxy to prevent that. E.g. if you have z = liftA2 f x y, and you request z n times, f will also be called n times. But if you have z - memo (liftA2 f x y) instead, then the calculation will only happen once. If Elerea wasn't an EDSL, these memo elements could be inserted automatically, but now I have no means to tell how many times a certain signal is referred to, so the burden is on the programmer. The old version doesn't have this inconvenience, because it memoises all the applicative nodes too. Since most of them are only referred to once, this is adds a lot of unnecessary overhead. Just to know, have you been told of a language dedicated to reactive programming (even experimental)? I mean, not an embedded language just like Yampa is. Those that Peter mentioned are good examples, and there is also Lustre. But you have to be aware that Elerea, Yampa, Lucid Synchrone and Lustre are all very similar in their foundations. Gergely -- http://www.fastmail.fm - The professional email service ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Yeah. Funny that we're still writing games in C++, while mission critical and hard real time systems are written in much nicer languages :) I made something similar to Lucid Synchrone for a game company I used to work, but with the purpose of making reactive programming accessible to computer artists. The integrated development environment provided the typical boxes-and-links user interface, where the boxes were signal functions. Signals itself were not exposed, like Yampa. The system did type inference so artists never really had to deal with types. Special nodes like feedback and delay where provided to allow transferring values to the next frame. This actually was a great success, digital artists could literally create little interactive applications with it, without much help from programmers. This resulted in a Playstation 3 visual experience Mesmerize (http://www.youtube.com/watch?v=rW7qGhBjwhY). This was before I knew Haskell or functional programming, so it was hacked together in C# and C++... I still believe that the reason why computers artists could work with this environment and were not able to learn imperative programming is functional programming itself: the system had all the goodies of FP: type inference, referential transparancy, etc... But is also provided the possibility to edit literals while the simulation was running, providing zero turnaround times, which was equally important for quick adoption of the software. So IMO Haskell and FRP systems have a huge potential for education of a much broader audience than just computer scientists... On Mon, May 24, 2010 at 6:13 PM, Limestraël limestr...@gmail.com wrote: I assumed also that it was a field which was still under research, however, Lustre, again, is used for critical control software in aircraft, helicopters, and nuclear power plants, according to wikipedia. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
I keep asking myself the question is Haskell and/or FRP even suitable for game programming. And if so are there any design patterns. 2010/5/19 Patai Gergely patai_gerg...@fastmail.fm I that the saw sleep time at each loop is fixed (0.02). So game speed will depend on processor speed, since with a more powerful CPU frames will be computed quicklier? Yes, that's how it works. So we don't have (with the Simple branch) some way to say I want my sprite to move 100 pixels *per second* on the left, except if we provide ourselves a time signal? That's exactly the case, although I'd probably provide a delta time signal. The Simple version is a discrete stream library, and it doesn't pretend to have continuous-time abstractions. Gergely -- http://www.fastmail.fm - Access your email from home and the web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
IMO: For AAA game programming? Definitely not. For exploring new ways of doing game programming and having a lot of fun and frustration? Sure! For making casual games? I don't know. On Sun, May 23, 2010 at 9:09 PM, Ben Christy ben.chri...@gmail.com wrote: I keep asking myself the question is Haskell and/or FRP even suitable for game programming. And if so are there any design patterns. 2010/5/19 Patai Gergely patai_gerg...@fastmail.fm I that the saw sleep time at each loop is fixed (0.02). So game speed will depend on processor speed, since with a more powerful CPU frames will be computed quicklier? Yes, that's how it works. So we don't have (with the Simple branch) some way to say I want my sprite to move 100 pixels *per second* on the left, except if we provide ourselves a time signal? That's exactly the case, although I'd probably provide a delta time signal. The Simple version is a discrete stream library, and it doesn't pretend to have continuous-time abstractions. Gergely -- http://www.fastmail.fm - Access your email from home and the web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
On May 23, 2010, at 15:09 , Ben Christy wrote: I keep asking myself the question is Haskell and/or FRP even suitable for game programming. Well, that's the question. FRP is a research project, not a production framework/paradigm; anyone working on it currently is there to help answer that question. If you're looking for a mature framework, this is not (yet) the place for you. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
On 05/23/2010 02:17 PM, Peter Verswyvelen wrote: IMO: For AAA game programming? Definitely not. Why not? I suppose it may depend on your definition of AAA, since there doesn't seem to be any consensus on it. I have seen it mean various combinations of the following, but rarely, if ever, all of them: * Big development budget * Big marketing budget * High quality * Large number of sales and/or high revenue * High hardware requirements * Released by one of a small group of accepted AAA publishers While I think it's very unlikely that the last one will happen any time soon, I don't see any reason that Haskell and/or FRP (or as I now prefer to call my research in the area, Denotative Continuous-Time Programming, or DCTP) inherently can't be a major part of the development of a game that fits any of the definitions in the list. I suppose DCTP is not itself *ready* for somebody to risk a business investment on it, although it may be in the future, but Haskell as a whole would not be all that risky, in my opinion. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Assuming Haskell is ready has any work gone into creating design patterns or the like. One of the biggest problems is ALL of the literature regarding game programming is written in an imperative style. My goal for learning Haskell is to make a hobby game written in a Functional language but I am at a loss how to go about it. I an imperative language I would set up a central entity management system and then have subsystems register with it and either transform the entities such as AI or user interface or do something with them IE graphics. This paradigm just will not work as far as I can imagine in Haskell. On Sun, May 23, 2010 at 6:30 PM, Jake McArthur jake.mcart...@gmail.comwrote: On 05/23/2010 02:17 PM, Peter Verswyvelen wrote: IMO: For AAA game programming? Definitely not. Why not? I suppose it may depend on your definition of AAA, since there doesn't seem to be any consensus on it. I have seen it mean various combinations of the following, but rarely, if ever, all of them: * Big development budget * Big marketing budget * High quality * Large number of sales and/or high revenue * High hardware requirements * Released by one of a small group of accepted AAA publishers While I think it's very unlikely that the last one will happen any time soon, I don't see any reason that Haskell and/or FRP (or as I now prefer to call my research in the area, Denotative Continuous-Time Programming, or DCTP) inherently can't be a major part of the development of a game that fits any of the definitions in the list. I suppose DCTP is not itself *ready* for somebody to risk a business investment on it, although it may be in the future, but Haskell as a whole would not be all that risky, in my opinion. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
On Mon, May 24, 2010 at 12:30 AM, Jake McArthur jake.mcart...@gmail.com wrote: On 05/23/2010 02:17 PM, Peter Verswyvelen wrote: IMO: For AAA game programming? Definitely not. Why not? I suppose it may depend on your definition of AAA, since there doesn't seem to be any consensus on it. I have seen it mean various combinations of the following, but rarely, if ever, all of them: * Big development budget * Big marketing budget * High quality * Large number of sales and/or high revenue * High hardware requirements * Released by one of a small group of accepted AAA publishers While I think it's very unlikely that the last one will happen any time soon, I don't see any reason that Haskell and/or FRP (or as I now prefer to call my research in the area, Denotative Continuous-Time Programming, or DCTP) inherently can't be a major part of the development of a game that fits any of the definitions in the list. I'm not saying it will never happen, I'm just saying that IMO Haskell is not ready for doing AAA development (and with that I meant your first 5 bullets) right now. I suppose DCTP is not itself *ready* for somebody to risk a business investment on it, although it may be in the future, but Haskell as a whole would not be all that risky, in my opinion. Well, in my opinion - based on hands on experience - Haskell was very risky for serious game development a couple of years ago. Not sure if this is still the case today... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
I guess Im thinking of a overarching pattern for creating games in a functional language similar to http://www.acims.arizona.edu/PUBLICATIONS/PDF/JeffPlummerMSthesis_wo_Appendix.pdf . On Sun, May 23, 2010 at 6:51 PM, Ben Christy ben.chri...@gmail.com wrote: Assuming Haskell is ready has any work gone into creating design patterns or the like. One of the biggest problems is ALL of the literature regarding game programming is written in an imperative style. My goal for learning Haskell is to make a hobby game written in a Functional language but I am at a loss how to go about it. I an imperative language I would set up a central entity management system and then have subsystems register with it and either transform the entities such as AI or user interface or do something with them IE graphics. This paradigm just will not work as far as I can imagine in Haskell. On Sun, May 23, 2010 at 6:30 PM, Jake McArthur jake.mcart...@gmail.comwrote: On 05/23/2010 02:17 PM, Peter Verswyvelen wrote: IMO: For AAA game programming? Definitely not. Why not? I suppose it may depend on your definition of AAA, since there doesn't seem to be any consensus on it. I have seen it mean various combinations of the following, but rarely, if ever, all of them: * Big development budget * Big marketing budget * High quality * Large number of sales and/or high revenue * High hardware requirements * Released by one of a small group of accepted AAA publishers While I think it's very unlikely that the last one will happen any time soon, I don't see any reason that Haskell and/or FRP (or as I now prefer to call my research in the area, Denotative Continuous-Time Programming, or DCTP) inherently can't be a major part of the development of a game that fits any of the definitions in the list. I suppose DCTP is not itself *ready* for somebody to risk a business investment on it, although it may be in the future, but Haskell as a whole would not be all that risky, in my opinion. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
What papers did you read? When I read most of the Yampa papers, most of the design patterns became obvious for AFRP (arrow-based FRP) style of programming. That doesn't mean I could apply the design patterns immediately; I understood them but writing a game in it was difficult since I also was too used to the imperative approach. Note that in AFRP the design patterns are actually functions and combinators itself (dpSwitch and the like), and no fuzzy descriptions like in imperative programming. Regarding user interfaces, FRUIT (also AFRP based) is also nice IMO. But above systems suffer from scalability and performance (and the annoying fact that a random number generator is not embedded in the framework) , although for simple games, I don't think this would be an issue. Newer work like Reactive is much more faithful to functional programming (no arrow syntax needed), but since no pong game was never made with it yet, I would classify this as ongoing research. Elerea finds middle ground between the two, and unlike Yampa, it's examples would still work I guess. On Mon, May 24, 2010 at 12:51 AM, Ben Christy ben.chri...@gmail.com wrote: Assuming Haskell is ready has any work gone into creating design patterns or the like. One of the biggest problems is ALL of the literature regarding game programming is written in an imperative style. My goal for learning Haskell is to make a hobby game written in a Functional language but I am at a loss how to go about it. I an imperative language I would set up a central entity management system and then have subsystems register with it and either transform the entities such as AI or user interface or do something with them IE graphics. This paradigm just will not work as far as I can imagine in Haskell. On Sun, May 23, 2010 at 6:30 PM, Jake McArthur jake.mcart...@gmail.com wrote: On 05/23/2010 02:17 PM, Peter Verswyvelen wrote: IMO: For AAA game programming? Definitely not. Why not? I suppose it may depend on your definition of AAA, since there doesn't seem to be any consensus on it. I have seen it mean various combinations of the following, but rarely, if ever, all of them: * Big development budget * Big marketing budget * High quality * Large number of sales and/or high revenue * High hardware requirements * Released by one of a small group of accepted AAA publishers While I think it's very unlikely that the last one will happen any time soon, I don't see any reason that Haskell and/or FRP (or as I now prefer to call my research in the area, Denotative Continuous-Time Programming, or DCTP) inherently can't be a major part of the development of a game that fits any of the definitions in the list. I suppose DCTP is not itself *ready* for somebody to risk a business investment on it, although it may be in the future, but Haskell as a whole would not be all that risky, in my opinion. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Elerea finds middle ground between the two, and unlike Yampa, it's examples would still work I guess. Yes that's the big problem of Yampa: all of the examples are very old, and some even don't work anymore. It's the same for the papers/tutorials (they're all 6 years old or more), and it would be less of a problem if the functions were documented! (Check hackage, you'll see...) I find Elerea fine so far, but it is still experimental and more limited than Yampa. 2010/5/24 Peter Verswyvelen bugf...@gmail.com What papers did you read? When I read most of the Yampa papers, most of the design patterns became obvious for AFRP (arrow-based FRP) style of programming. That doesn't mean I could apply the design patterns immediately; I understood them but writing a game in it was difficult since I also was too used to the imperative approach. Note that in AFRP the design patterns are actually functions and combinators itself (dpSwitch and the like), and no fuzzy descriptions like in imperative programming. Regarding user interfaces, FRUIT (also AFRP based) is also nice IMO. But above systems suffer from scalability and performance (and the annoying fact that a random number generator is not embedded in the framework) , although for simple games, I don't think this would be an issue. Newer work like Reactive is much more faithful to functional programming (no arrow syntax needed), but since no pong game was never made with it yet, I would classify this as ongoing research. Elerea finds middle ground between the two, and unlike Yampa, it's examples would still work I guess. On Mon, May 24, 2010 at 12:51 AM, Ben Christy ben.chri...@gmail.com wrote: Assuming Haskell is ready has any work gone into creating design patterns or the like. One of the biggest problems is ALL of the literature regarding game programming is written in an imperative style. My goal for learning Haskell is to make a hobby game written in a Functional language but I am at a loss how to go about it. I an imperative language I would set up a central entity management system and then have subsystems register with it and either transform the entities such as AI or user interface or do something with them IE graphics. This paradigm just will not work as far as I can imagine in Haskell. On Sun, May 23, 2010 at 6:30 PM, Jake McArthur jake.mcart...@gmail.com wrote: On 05/23/2010 02:17 PM, Peter Verswyvelen wrote: IMO: For AAA game programming? Definitely not. Why not? I suppose it may depend on your definition of AAA, since there doesn't seem to be any consensus on it. I have seen it mean various combinations of the following, but rarely, if ever, all of them: * Big development budget * Big marketing budget * High quality * Large number of sales and/or high revenue * High hardware requirements * Released by one of a small group of accepted AAA publishers While I think it's very unlikely that the last one will happen any time soon, I don't see any reason that Haskell and/or FRP (or as I now prefer to call my research in the area, Denotative Continuous-Time Programming, or DCTP) inherently can't be a major part of the development of a game that fits any of the definitions in the list. I suppose DCTP is not itself *ready* for somebody to risk a business investment on it, although it may be in the future, but Haskell as a whole would not be all that risky, in my opinion. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
I that the saw sleep time at each loop is fixed (0.02). So game speed will depend on processor speed, since with a more powerful CPU frames will be computed quicklier? Yes, that's how it works. So we don't have (with the Simple branch) some way to say I want my sprite to move 100 pixels *per second* on the left, except if we provide ourselves a time signal? That's exactly the case, although I'd probably provide a delta time signal. The Simple version is a discrete stream library, and it doesn't pretend to have continuous-time abstractions. Gergely -- http://www.fastmail.fm - Access your email from home and the web ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
I heard complaints about this two-layered solution with SignalMonad/SignalGen, so I'm glad you like it. :) Doesn't SignalGen replace SignalMonad in the experimental branch ? They aren't meant to be used together, are they? By the way, I strongly recommend using the Experimental branch instead of the current one Yes, I just looked at FRP.Elerea.Experimental.Simple. I have one question: in the stable branch, 'superstep' takes an amount of time. In the experimental branch, it and 'createSignal' are replaced by 'start', if I'm right. So you do: main = do updater - start gen forever (join $ updater) But there is no notion of time, here. So how do I make sure the network is updated with the right amount of time? 2010/5/17 Patai Gergely patai_gerg...@fastmail.fm I looked at elerea. I found it simple and nice! I heard complaints about this two-layered solution with SignalMonad/SignalGen, so I'm glad you like it. :) I just regret the fact that the SignalMonad can only be run inside IO. That's life. ;) However, there is only a single point where you have to do the conversion, and you can think of everything as a pure abstraction within that top-level SignalGen. By the way, I strongly recommend using the Experimental branch instead of the current one, because sampler (the 'almost join') breaks referential transparency and generally behaves badly if you have more than two Signal layers to break down, which can easily happen in practice. Also, the new stuff is much more efficient. With reactive, you can transform signals in pure code. Sure, but you'll need IO anyway if you want to hook up the signals to peripherals. Both libraries allow you to describe the combinations of reactive values in a pure way, but they inevitably have to face the RealWorld at some point... Yes, as no optimization is done? But as long as you compile the code, you don't have such a problem? No, it's not a matter of optimisation, it's an intrinsic problem. Optimisation just makes it less obvious. I don't know how bad it is in practice though, because the more entities are created, the more often garbage collection should kick in, so it might not hinder scaling as much as one would think. You can also look at the bounce example in the elerea-examples package if you want a minimal test case for dynamic collections. Does reactive work elsewise? Yes. If you don't need a reactive value in Reactive, it is not evaluated. This means that unreferenced values just sit in memory until they are swept up by the garbage collector, as you would expect. This policy has a different unpleasant consequence though: if a stateful reactive value (e.g. our favourite integral) is only requested long after its start time -- which is always the start time of the whole program in the case of Reactive --, all its past has to be kept in memory, and the first evaluation will potentially take a lot of time while the computation is catching up. So it will cause a different kind of space-time leak than Elerea. Grapefruit has an interesting solution to this problem that uses phantom types to keep track of the observers of a signal. Elerea just forces every live signal to be updated to prevent big thunks from building up. I know that every FRP framework will have its own hiccups, as it is a domain which is still in development, but still, I found the time-leak bug (if it is a bug) in reactive very weird. I still haven't managed to find out whether it's just an implementation issue or somehow the consequence of the basic design of the library. Hopefully the former. The run-time behaviour of Reactive is quite complex, so it's difficult to pinpoint the source of the problem. Gergely -- http://www.fastmail.fm - Choose from over 50 domains or use your own ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Doesn't SignalGen replace SignalMonad in the experimental branch ? They aren't meant to be used together, are they? Absolutely, they are incompatible, and play the same role in the respective versions. But there is no notion of time, here. So how do I make sure the network is updated with the right amount of time? Time is just an external parameter. You can use the Param version if you don't want to supply it as an external signal but pass it to the superstep. Since the system doesn't rely on this type in any way (it's basically a globally accessible value for the whole network), you are free to choose whatever structure you want, not just a single Double value like in the old version. Gergely -- http://www.fastmail.fm - mmm... Fastmail... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Time has to be an external signal? I saw dow uses the Simple experimental branch, and I don't see how you synchronize elerea with GLFW (what is done by driveNetwork in the Chase and Breakout examples which use the main branch). 2010/5/18 Patai Gergely patai_gerg...@fastmail.fm Doesn't SignalGen replace SignalMonad in the experimental branch ? They aren't meant to be used together, are they? Absolutely, they are incompatible, and play the same role in the respective versions. But there is no notion of time, here. So how do I make sure the network is updated with the right amount of time? Time is just an external parameter. You can use the Param version if you don't want to supply it as an external signal but pass it to the superstep. Since the system doesn't rely on this type in any way (it's basically a globally accessible value for the whole network), you are free to choose whatever structure you want, not just a single Double value like in the old version. Gergely -- http://www.fastmail.fm - mmm... Fastmail... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Time has to be an external signal? With the Simple version, yes. With the Param (and Delayed) versions it's pretty much like the old one, where you have to pass something (delta time being one possibility) as an additional parameter, and all stateful and transfer nodes will see it. I saw dow uses the Simple experimental branch, and I don't see how you synchronize elerea with GLFW (what is done by driveNetwork in the Chase and Breakout examples which use the main branch). DoW doesn't use any notion of time for the game logic, so there's no need to synchronise. The game speed is determined by the amount of sleep per frame. Gergely -- http://www.fastmail.fm - Access all of your messages and folders wherever you are ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
The game speed is determined by the amount of sleep per frame. I that the saw sleep time at each loop is fixed (0.02). So game speed will depend on processor speed, since with a more powerful CPU frames will be computed quicklier? So we don't have (with the Simple branch) some way to say I want my sprite to move 100 pixels *per second* on the left, except if we provide ourselves a time signal? 2010/5/18 Patai Gergely patai_gerg...@fastmail.fm Time has to be an external signal? With the Simple version, yes. With the Param (and Delayed) versions it's pretty much like the old one, where you have to pass something (delta time being one possibility) as an additional parameter, and all stateful and transfer nodes will see it. I saw dow uses the Simple experimental branch, and I don't see how you synchronize elerea with GLFW (what is done by driveNetwork in the Chase and Breakout examples which use the main branch). DoW doesn't use any notion of time for the game logic, so there's no need to synchronise. The game speed is determined by the amount of sleep per frame. Gergely -- http://www.fastmail.fm - Access all of your messages and folders wherever you are ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
I did not look thoroughly at elerea, but at least, when I tried its sample dungeons of wor it worked properly ;) Elerea has its own 'beauty' though. I suggest unpacking the source of dow and executing it in ghci, the problem will be obvious as you play at length. Unfortunately, Elerea doesn't really work well as an EDSL, however much I'd like it to. Its main issue is that unreferenced entities keep using CPU time until they are garbage collected -- this comes from the necessity to keep them referentially transparent, i.e. behaving the same way regardless of how they are observed --, and currently I don't see any way to solve that without implementing a dedicated runtime for dynamic stream processing. So there, no FRP library without a catch for you. ;) Gergely -- http://www.fastmail.fm - A fast, anti-spam email service. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
I looked at elerea. I found it simple and nice! I just regret the fact that the SignalMonad can only be run inside IO. With reactive, you can transform signals in pure code. I suggest unpacking the source of dow and executing it in ghci, the problem will be obvious as you play at length. Yes, as no optimization is done? But as long as you compile the code, you don't have such a problem? Unfortunately, Elerea doesn't really work well as an EDSL, however much I'd like it to. Its main issue is that unreferenced entities keep using CPU time until they are garbage collected -- this comes from the necessity to keep them referentially transparent Does reactive work elsewise? I know that every FRP framework will have its own hiccups, as it is a domain which is still in development, but still, I found the time-leak bug (if it is a bug) in reactive very weird. 2010/5/17 Patai Gergely patai_gerg...@fastmail.fm I did not look thoroughly at elerea, but at least, when I tried its sample dungeons of wor it worked properly ;) Elerea has its own 'beauty' though. I suggest unpacking the source of dow and executing it in ghci, the problem will be obvious as you play at length. Unfortunately, Elerea doesn't really work well as an EDSL, however much I'd like it to. Its main issue is that unreferenced entities keep using CPU time until they are garbage collected -- this comes from the necessity to keep them referentially transparent, i.e. behaving the same way regardless of how they are observed --, and currently I don't see any way to solve that without implementing a dedicated runtime for dynamic stream processing. So there, no FRP library without a catch for you. ;) Gergely -- http://www.fastmail.fm - A fast, anti-spam email service. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
I looked at elerea. I found it simple and nice! I heard complaints about this two-layered solution with SignalMonad/SignalGen, so I'm glad you like it. :) I just regret the fact that the SignalMonad can only be run inside IO. That's life. ;) However, there is only a single point where you have to do the conversion, and you can think of everything as a pure abstraction within that top-level SignalGen. By the way, I strongly recommend using the Experimental branch instead of the current one, because sampler (the 'almost join') breaks referential transparency and generally behaves badly if you have more than two Signal layers to break down, which can easily happen in practice. Also, the new stuff is much more efficient. With reactive, you can transform signals in pure code. Sure, but you'll need IO anyway if you want to hook up the signals to peripherals. Both libraries allow you to describe the combinations of reactive values in a pure way, but they inevitably have to face the RealWorld at some point... Yes, as no optimization is done? But as long as you compile the code, you don't have such a problem? No, it's not a matter of optimisation, it's an intrinsic problem. Optimisation just makes it less obvious. I don't know how bad it is in practice though, because the more entities are created, the more often garbage collection should kick in, so it might not hinder scaling as much as one would think. You can also look at the bounce example in the elerea-examples package if you want a minimal test case for dynamic collections. Does reactive work elsewise? Yes. If you don't need a reactive value in Reactive, it is not evaluated. This means that unreferenced values just sit in memory until they are swept up by the garbage collector, as you would expect. This policy has a different unpleasant consequence though: if a stateful reactive value (e.g. our favourite integral) is only requested long after its start time -- which is always the start time of the whole program in the case of Reactive --, all its past has to be kept in memory, and the first evaluation will potentially take a lot of time while the computation is catching up. So it will cause a different kind of space-time leak than Elerea. Grapefruit has an interesting solution to this problem that uses phantom types to keep track of the observers of a signal. Elerea just forces every live signal to be updated to prevent big thunks from building up. I know that every FRP framework will have its own hiccups, as it is a domain which is still in development, but still, I found the time-leak bug (if it is a bug) in reactive very weird. I still haven't managed to find out whether it's just an implementation issue or somehow the consequence of the basic design of the library. Hopefully the former. The run-time behaviour of Reactive is quite complex, so it's difficult to pinpoint the source of the problem. Gergely -- http://www.fastmail.fm - Choose from over 50 domains or use your own ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Eventually, I don't think it is a profiling issue.
Maybe a problem with integral. According to a quite recent post on the
reactive mailing list, the following minimal code produces the same problem
:
import FRP.Reactive
import FRP.Reactive.LegacyAdapters
import Control.Applicative
type Velocity = Double
type Position = Double
data Car = Car { vel :: Velocity, pos :: Position } deriving Show
velocity :: Behavior Velocity
velocity = 1
position :: Behavior Position
position = integral (atTimes [0, 0.5 ..]) velocity
car :: Behavior Car
car = Car $ velocity * position
main :: IO ()
main = adaptE $ print $ car `snapshot_` atTimes [0, 0.5..]
1) why is the leak happen?
2) how can I fix this problem?
Some more detailed informations:
* reactive 0.11.4
* GHC 6.12.1
* Gentoo Linux (2.6.32-tuxonice, x86_64) or Ubuntu 9.10 64bits
* compiled with or without -O2 flag
2010/5/16 David Leimbach leim...@gmail.com
On Sat, May 15, 2010 at 8:42 AM, Limestraël limestr...@gmail.com wrote:
Okay,
guess I'll have to bring out the chapter 25 of my Real World Haskell...
I find it's often the most practical chapter that I hit a lot during writes
and changes to my server process I have in Haskell in our control system
code :-)
That plus the information that I had missed that Control.Monad.State
defaulted to the Lazy version (which is consistent, but for some reason it
got by me) helped me to realize why I was leaking so much space in a garbage
collected environment.
I wouldn't have gotten very far with Haskell as this piece of our code
without that chapter. I'd love to see more writing of that sort around
Haskell in book form. One can become fluent in tuning Haskell by trial and
error, but the sharp corners one must bump into are often sharper than in
other languages I've found.
Dave
2010/5/15 Bulat Ziganshin bulat.zigans...@gmail.com
Hello Limestraėl,
Saturday, May 15, 2010, 7:02:38 PM, you wrote:
But when I set my beat to tick every 60 times per second, the
position is well updated, but I clearly see that the display
dramatically slows down after a few seconds of execution. Too heavy
rate for integrate?
it may be due to lot of uncollected garbage that is result of lazy
evaluation. profile program to check its GC times
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
As far as I know, it was never possible to make a pong game in
Reactive, at least not with the versions I tried, but I admit a lot of
never versions got released since then. It would be great to see one
though :)
You might want to try Yampa, that works for sure (although you should
mark all your output data strict, as is done in the examples,
otherwise you might also get space leaks or shaky frame rates). Or
Elerea, which comes with a breakout game.
On Sun, May 16, 2010 at 9:30 PM, Limestraël limestr...@gmail.com wrote:
Eventually, I don't think it is a profiling issue.
Maybe a problem with integral. According to a quite recent post on the
reactive mailing list, the following minimal code produces the same problem
:
import FRP.Reactive
import FRP.Reactive.LegacyAdapters
import Control.Applicative
type Velocity = Double
type Position = Double
data Car = Car { vel :: Velocity, pos :: Position } deriving Show
velocity :: Behavior Velocity
velocity = 1
position :: Behavior Position
position = integral (atTimes [0, 0.5 ..]) velocity
car :: Behavior Car
car = Car $ velocity * position
main :: IO ()
main = adaptE $ print $ car `snapshot_` atTimes [0, 0.5..]
1) why is the leak happen?
2) how can I fix this problem?
Some more detailed informations:
* reactive 0.11.4
* GHC 6.12.1
* Gentoo Linux (2.6.32-tuxonice, x86_64) or Ubuntu 9.10 64bits
* compiled with or without -O2 flag
2010/5/16 David Leimbach leim...@gmail.com
On Sat, May 15, 2010 at 8:42 AM, Limestraël limestr...@gmail.com wrote:
Okay,
guess I'll have to bring out the chapter 25 of my Real World Haskell...
I find it's often the most practical chapter that I hit a lot during
writes and changes to my server process I have in Haskell in our control
system code :-)
That plus the information that I had missed that Control.Monad.State
defaulted to the Lazy version (which is consistent, but for some reason it
got by me) helped me to realize why I was leaking so much space in a garbage
collected environment.
I wouldn't have gotten very far with Haskell as this piece of our code
without that chapter. I'd love to see more writing of that sort around
Haskell in book form. One can become fluent in tuning Haskell by trial and
error, but the sharp corners one must bump into are often sharper than in
other languages I've found.
Dave
2010/5/15 Bulat Ziganshin bulat.zigans...@gmail.com
Hello Limestraėl,
Saturday, May 15, 2010, 7:02:38 PM, you wrote:
But when I set my beat to tick every 60 times per second, the
position is well updated, but I clearly see that the display
dramatically slows down after a few seconds of execution. Too heavy
rate for integrate?
it may be due to lot of uncollected garbage that is result of lazy
evaluation. profile program to check its GC times
--
Best regards,
Bulat mailto:bulat.zigans...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Why isn't it possible to make a Pong with Reactive? Where is the problem?
Conceptually, I don't see where it is. IMO, it's a time-leak issue due to a
Reactive bug, but it is not a limitation of Reactive.
I mean, it's not that it *can't* work, it's that it *should* work, shouldn't
it?
And why would it be more possible with Yampa?
I've already checked Yampa, but I find it much less simple and easy to use
than Reactive.
Moreover, I tried the space invaders sample (the sample that the paper
Yampa Arcade is about), and it lauches but it is completely unusable (I do
have a decent PC, and I get like 5fps and a gun which absolutely doesn't
move correctly). Not very appealing ^^, but maybe the problem is with the
code of the game itself or with my PC, not with Yampa...
I did not look thoroughly at elerea, but at least, when I tried its sample
dungeons of wor it worked properly ;)
I will have a look...
2010/5/16 Peter Verswyvelen bugf...@gmail.com
As far as I know, it was never possible to make a pong game in
Reactive, at least not with the versions I tried, but I admit a lot of
never versions got released since then. It would be great to see one
though :)
You might want to try Yampa, that works for sure (although you should
mark all your output data strict, as is done in the examples,
otherwise you might also get space leaks or shaky frame rates). Or
Elerea, which comes with a breakout game.
On Sun, May 16, 2010 at 9:30 PM, Limestraël limestr...@gmail.com wrote:
Eventually, I don't think it is a profiling issue.
Maybe a problem with integral. According to a quite recent post on the
reactive mailing list, the following minimal code produces the same
problem
:
import FRP.Reactive
import FRP.Reactive.LegacyAdapters
import Control.Applicative
type Velocity = Double
type Position = Double
data Car = Car { vel :: Velocity, pos :: Position } deriving Show
velocity :: Behavior Velocity
velocity = 1
position :: Behavior Position
position = integral (atTimes [0, 0.5 ..]) velocity
car :: Behavior Car
car = Car $ velocity * position
main :: IO ()
main = adaptE $ print $ car `snapshot_` atTimes [0, 0.5..]
1) why is the leak happen?
2) how can I fix this problem?
Some more detailed informations:
* reactive 0.11.4
* GHC 6.12.1
* Gentoo Linux (2.6.32-tuxonice, x86_64) or Ubuntu 9.10 64bits
* compiled with or without -O2 flag
2010/5/16 David Leimbach leim...@gmail.com
On Sat, May 15, 2010 at 8:42 AM, Limestraël limestr...@gmail.com
wrote:
Okay,
guess I'll have to bring out the chapter 25 of my Real World Haskell...
I find it's often the most practical chapter that I hit a lot during
writes and changes to my server process I have in Haskell in our control
system code :-)
That plus the information that I had missed that Control.Monad.State
defaulted to the Lazy version (which is consistent, but for some reason
it
got by me) helped me to realize why I was leaking so much space in a
garbage
collected environment.
I wouldn't have gotten very far with Haskell as this piece of our code
without that chapter. I'd love to see more writing of that sort around
Haskell in book form. One can become fluent in tuning Haskell by trial
and
error, but the sharp corners one must bump into are often sharper than
in
other languages I've found.
Dave
2010/5/15 Bulat Ziganshin bulat.zigans...@gmail.com
Hello Limestraėl,
Saturday, May 15, 2010, 7:02:38 PM, you wrote:
But when I set my beat to tick every 60 times per second, the
position is well updated, but I clearly see that the display
dramatically slows down after a few seconds of execution. Too heavy
rate for integrate?
it may be due to lot of uncollected garbage that is result of lazy
evaluation. profile program to check its GC times
--
Best regards,
Bulatmailto:bulat.zigans...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Yes, it would be very nice to actually pinpoint why this can't be
done. Is it a bug, is it a design flaw, ... I'm just saying that I'm
not aware of a working Pong game in Reactive. Well actually, someone
did make a Tetris game with it once...
Intuitively I would say Reactive gives the programmer too much power
of what can be done with time, making it all too easy to break
causality. And since that's a physical law that can't be broken
(unless Reactive would create a wormhole somehow), it means you too
easily get delays or deadlocks. But that's just an intuition, I can't
describe this formally. This is a general problem of first class
signals IMHO: too open, not restrictive enough. First class signals
are fine for just animation, but not for complex reactivity.
Yampa gives you access to signal transformers, not the signals
themselves, which is more natural to me as a casual game developer.
Yampa looks like dataflow programming, but I agree that's not
something you want to do in a text editor ;-) (stuff like x - f - y
is easier in a graphical boxes/links editor). Also, a lot of global
state needs to be transfered to all the signal functions (e.g. a
random number seed that can't be used statically, e.g. in dynamic
collections), and an arrow is fine for that, just like a state monad
is.
Well, at least that's what I understand from it. But I understand only
tiny bits of pieces of it all :)
On Sun, May 16, 2010 at 11:41 PM, Limestraël limestr...@gmail.com wrote:
Why isn't it possible to make a Pong with Reactive? Where is the problem?
Conceptually, I don't see where it is. IMO, it's a time-leak issue due to a
Reactive bug, but it is not a limitation of Reactive.
I mean, it's not that it can't work, it's that it should work, shouldn't it?
And why would it be more possible with Yampa?
I've already checked Yampa, but I find it much less simple and easy to use
than Reactive.
Moreover, I tried the space invaders sample (the sample that the paper
Yampa Arcade is about), and it lauches but it is completely unusable (I do
have a decent PC, and I get like 5fps and a gun which absolutely doesn't
move correctly). Not very appealing ^^, but maybe the problem is with the
code of the game itself or with my PC, not with Yampa...
I did not look thoroughly at elerea, but at least, when I tried its sample
dungeons of wor it worked properly ;)
I will have a look...
2010/5/16 Peter Verswyvelen bugf...@gmail.com
As far as I know, it was never possible to make a pong game in
Reactive, at least not with the versions I tried, but I admit a lot of
never versions got released since then. It would be great to see one
though :)
You might want to try Yampa, that works for sure (although you should
mark all your output data strict, as is done in the examples,
otherwise you might also get space leaks or shaky frame rates). Or
Elerea, which comes with a breakout game.
On Sun, May 16, 2010 at 9:30 PM, Limestraël limestr...@gmail.com wrote:
Eventually, I don't think it is a profiling issue.
Maybe a problem with integral. According to a quite recent post on the
reactive mailing list, the following minimal code produces the same
problem
:
import FRP.Reactive
import FRP.Reactive.LegacyAdapters
import Control.Applicative
type Velocity = Double
type Position = Double
data Car = Car { vel :: Velocity, pos :: Position } deriving Show
velocity :: Behavior Velocity
velocity = 1
position :: Behavior Position
position = integral (atTimes [0, 0.5 ..]) velocity
car :: Behavior Car
car = Car $ velocity * position
main :: IO ()
main = adaptE $ print $ car `snapshot_` atTimes [0, 0.5..]
1) why is the leak happen?
2) how can I fix this problem?
Some more detailed informations:
* reactive 0.11.4
* GHC 6.12.1
* Gentoo Linux (2.6.32-tuxonice, x86_64) or Ubuntu 9.10 64bits
* compiled with or without -O2 flag
2010/5/16 David Leimbach leim...@gmail.com
On Sat, May 15, 2010 at 8:42 AM, Limestraël limestr...@gmail.com
wrote:
Okay,
guess I'll have to bring out the chapter 25 of my Real World
Haskell...
I find it's often the most practical chapter that I hit a lot during
writes and changes to my server process I have in Haskell in our
control
system code :-)
That plus the information that I had missed that Control.Monad.State
defaulted to the Lazy version (which is consistent, but for some reason
it
got by me) helped me to realize why I was leaking so much space in a
garbage
collected environment.
I wouldn't have gotten very far with Haskell as this piece of our code
without that chapter. I'd love to see more writing of that sort around
Haskell in book form. One can become fluent in tuning Haskell by trial
and
error, but the sharp corners one must bump into are often sharper than
in
other languages I've found.
Dave
2010/5/15 Bulat Ziganshin bulat.zigans...@gmail.com
Hello Limestraėl,
Re: [Haskell-cafe] [reactive] A pong and integrate
Hello Limestraël, Saturday, May 15, 2010, 7:02:38 PM, you wrote: But when I set my beat to tick every 60 times per second, the position is well updated, but I clearly see that the display dramatically slows down after a few seconds of execution. Too heavy rate for integrate? it may be due to lot of uncollected garbage that is result of lazy evaluation. profile program to check its GC times -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Okay, guess I'll have to bring out the chapter 25 of my Real World Haskell... 2010/5/15 Bulat Ziganshin bulat.zigans...@gmail.com Hello Limestraėl, Saturday, May 15, 2010, 7:02:38 PM, you wrote: But when I set my beat to tick every 60 times per second, the position is well updated, but I clearly see that the display dramatically slows down after a few seconds of execution. Too heavy rate for integrate? it may be due to lot of uncollected garbage that is result of lazy evaluation. profile program to check its GC times -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
I'm definitely not good at profiling... But I have something: 4,971,190,736 bytes allocated in the heap 4,392,735,248 bytes copied during GC 13,998,328 bytes maximum residency (573 sample(s)) 3,281,000 bytes maximum slop 38 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 6987 collections, 0 parallel, 3.18s, 3.01s elapsed Generation 1: 573 collections, 0 parallel, 1.74s, 1.90s elapsed INIT time0.00s ( 0.00s elapsed) MUT time6.60s ( 9.54s elapsed) GCtime4.92s ( 4.91s elapsed) RPtime0.00s ( 0.00s elapsed) PROF time0.02s ( 0.03s elapsed) EXIT time0.01s ( 0.01s elapsed) Total time 11.55s ( 14.49s elapsed) *%GC time 42.6%* (33.9% elapsed) Alloc rate752,071,215 bytes per MUT second Productivity 57.2% of total user, 45.6% of total elapsed COST CENTREMODULE %time %alloc MAIN MAIN 92.2 89.9 newPaddle Pong.Types 7.89.9 Apparently, the integral (which is in newPaddle) does not consumes lots of memory and time. It's the main. I don't see where I should add strict evaluation. 2010/5/15 Limestraël limestr...@gmail.com Okay, guess I'll have to bring out the chapter 25 of my Real World Haskell... 2010/5/15 Bulat Ziganshin bulat.zigans...@gmail.com Hello Limestraėl, Saturday, May 15, 2010, 7:02:38 PM, you wrote: But when I set my beat to tick every 60 times per second, the position is well updated, but I clearly see that the display dramatically slows down after a few seconds of execution. Too heavy rate for integrate? it may be due to lot of uncollected garbage that is result of lazy evaluation. profile program to check its GC times -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
Make sure you're profiling with -prof -auto-all And any packages you're using may need -auto-all as well. limestrael: I'm definitely not good at profiling... But I have something: 4,971,190,736 bytes allocated in the heap 4,392,735,248 bytes copied during GC 13,998,328 bytes maximum residency (573 sample(s)) 3,281,000 bytes maximum slop 38 MB total memory in use (0 MB lost due to fragmentation) Generation 0: 6987 collections, 0 parallel, 3.18s, 3.01s elapsed Generation 1: 573 collections, 0 parallel, 1.74s, 1.90s elapsed INIT time 0.00s ( 0.00s elapsed) MUT time 6.60s ( 9.54s elapsed) GC time 4.92s ( 4.91s elapsed) RP time 0.00s ( 0.00s elapsed) PROF time 0.02s ( 0.03s elapsed) EXIT time 0.01s ( 0.01s elapsed) Total time 11.55s ( 14.49s elapsed) %GC time 42.6% (33.9% elapsed) Alloc rate 752,071,215 bytes per MUT second Productivity 57.2% of total user, 45.6% of total elapsed COST CENTRE MODULE %time %alloc MAIN MAIN 92.2 89.9 newPaddle Pong.Types 7.8 9.9 Apparently, the integral (which is in newPaddle) does not consumes lots of memory and time. It's the main. I don't see where I should add strict evaluation. 2010/5/15 Limestraël limestr...@gmail.com Okay, guess I'll have to bring out the chapter 25 of my Real World Haskell... 2010/5/15 Bulat Ziganshin bulat.zigans...@gmail.com Hello Limestraėl, Saturday, May 15, 2010, 7:02:38 PM, you wrote: But when I set my beat to tick every 60 times per second, the position is well updated, but I clearly see that the display dramatically slows down after a few seconds of execution. Too heavy rate for integrate? it may be due to lot of uncollected garbage that is result of lazy evaluation. profile program to check its GC times -- Best regards, Bulat mailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [reactive] A pong and integrate
On Sat, May 15, 2010 at 8:42 AM, Limestraël limestr...@gmail.com wrote: Okay, guess I'll have to bring out the chapter 25 of my Real World Haskell... I find it's often the most practical chapter that I hit a lot during writes and changes to my server process I have in Haskell in our control system code :-) That plus the information that I had missed that Control.Monad.State defaulted to the Lazy version (which is consistent, but for some reason it got by me) helped me to realize why I was leaking so much space in a garbage collected environment. I wouldn't have gotten very far with Haskell as this piece of our code without that chapter. I'd love to see more writing of that sort around Haskell in book form. One can become fluent in tuning Haskell by trial and error, but the sharp corners one must bump into are often sharper than in other languages I've found. Dave 2010/5/15 Bulat Ziganshin bulat.zigans...@gmail.com Hello Limestraėl, Saturday, May 15, 2010, 7:02:38 PM, you wrote: But when I set my beat to tick every 60 times per second, the position is well updated, but I clearly see that the display dramatically slows down after a few seconds of execution. Too heavy rate for integrate? it may be due to lot of uncollected garbage that is result of lazy evaluation. profile program to check its GC times -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
