Re: [Haskell-cafe] [reactive] A pong and integrate

Patai Gergely

17 May 2010 17 May '10

10 a.m.

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.

Show replies by date

Limestraël

17 May 17 May

4:36 p.m.

New subject: [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

...

...
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

Patai Gergely

5:33 p.m.

New subject: [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

Limestraël

18 May 18 May

9:04 a.m.

New subject: [reactive] A pong and integrate

...

I heard complaints about this two-layered solution with SignalMonad/SignalGen, so I'm glad you like it. :)

...

By the way, I strongly recommend using the Experimental branch instead of

Doesn't SignalGen replace SignalMonad in the experimental branch ? They aren't meant to be used together, are they? 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

...

...
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

Patai Gergely

10:18 a.m.

New subject: [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...

Limestraël

1:45 p.m.

New subject: [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

...

...
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

Patai Gergely

5:48 p.m.

New subject: [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

Limestraël

7:52 p.m.

New subject: [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

...

...
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

Patai Gergely

19 May 19 May

2:41 a.m.

New subject: [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

Ben Christy

23 May 23 May

3:09 p.m.

New subject: [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

...

...
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

Peter Verswyvelen

3:17 p.m.

New subject: [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 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

...
...
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

Jake McArthur

6:30 p.m.

New subject: [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

Ben Christy

6:51 p.m.

New subject: [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 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

Ben Christy

6:57 p.m.

New subject: [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_Appendi... . On Sun, May 23, 2010 at 6:51 PM, Ben Christy 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 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

Peter Verswyvelen

7:06 p.m.

New subject: [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 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 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

Limestraël

8:39 p.m.

New subject: [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

...

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.

...
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 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

On Mon, May 24, 2010 at 12:51 AM, Ben Christy wrote: 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

Peter Verswyvelen

6:55 p.m.

New subject: [reactive] A pong and integrate

On Mon, May 24, 2010 at 12:30 AM, Jake McArthur 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...

Patai Gergely

24 May 24 May

3:45 a.m.

New subject: [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?

...

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

Limestraël: 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 à 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

Limestraël

5:15 a.m.

New subject: [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

...

...
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 à 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

Peter Verswyvelen

5:54 a.m.

New subject: [reactive] A pong and integrate

...

2010/5/24 Patai Gergely

...
...
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=0jYdu2u8gAU&feature=related) also indicates it can be done. So my "I don't know" should have been a "I think it is" :-)

Peter Verswyvelen

5:56 a.m.

New subject: [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)?

Patai Gergely

7:22 a.m.

New subject: [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

Limestraël

12:13 p.m.

New subject: [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

...

...
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

Peter Verswyvelen

3:41 p.m.

New subject: [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 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.

Limestraël

25 May 25 May

4:49 a.m.

New subject: [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

...

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 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.

Peter Verswyvelen

3:34 p.m.

New subject: [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 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

...
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 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.

Limestraël

26 May 26 May

3:52 a.m.

New subject: [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.

...

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 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

...
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

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.

Sam Martin

6:19 a.m.

New subject: [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-bounces@haskell.org [mailto:haskell-cafe-bounces@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-Ga... 2010/5/25 Peter Verswyvelen 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 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

...
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 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.

David Sankel

12:28 p.m.

New subject: [reactive] A pong and integrate

On Wed, May 26, 2010 at 6:19 AM, Sam Martin 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)

Pierre-Etienne Meunier

2:32 p.m.

New subject: [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 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

Brandon S. Allbery KF8NH

23 May 23 May

3:30 p.m.

New subject: [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] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

5474

Age (days ago)

5483

Last active (days ago)

List overview

Download

30 comments

9 participants

participants (9)

Ben Christy
Brandon S. Allbery KF8NH
David Sankel
Jake McArthur
Limestraël
Patai Gergely
Peter Verswyvelen
Pierre-Etienne Meunier
Sam Martin