Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (538)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (600)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Scala Actor  (Read 914 times)
0 Members and 1 Guest are viewing this topic.
Offline Gudradain
« Posted 2012-07-31 02:49:38 »

Just out of curiosity, has anyone tried to do some networking application using Scala RemoteActor?

I finally decided to try Scala. I must say that the integration with Java is flawless. You can still use everything you were using in Java and you have now access to a few more things : closure, syntax shortcut, operator overloading (kind of), actor concurrency, etc.

First impression? I love it Smiley
Offline sproingie

JGO Kernel


Medals: 202



« Reply #1 - Posted 2012-07-31 02:55:13 »

I use Akka actors quite a bit at work, and I'm working on a new fun project that I'm trying to use Scalaz actors with, though I might give in and switch to Akka actors for that too.  The built-in actors in the scala stdlib aren't all that great.

Scala is definitely my favorite language now, though I do wish the IDE tooling weren't so awful.
Offline Gudradain
« Reply #2 - Posted 2012-07-31 02:58:06 »

I use Akka actors quite a bit at work, and I'm working on a new fun project that I'm trying to use Scalaz actors with, though I might give in and switch to Akka actors for that too.  The built-in actors in the scala stdlib aren't all that great.

Scala is definitely my favorite language now, though I do wish the IDE tooling weren't so awful.


Oh really, what is the problem with Scala actor?

One problem I noticed with Eclipse IDE is that when refactoring a mixed project Java/Scala, the refactor name in scala code won't be apply to the Java part Sad

EDIT : Scala stdlib Actor implements the same actor as Erlang right? I thought Erlang was great in that field.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline sproingie

JGO Kernel


Medals: 202



« Reply #3 - Posted 2012-07-31 03:09:02 »

The main problem with scala.actors is that they silently drop messages that aren't understood, and the implementation of that strategy means that they leak memory every time they drop a message.  They're also not quite as flexible or configurable as akka actors, and til recently they didn't have a decent Future abstraction (now it's more or less using Akka's).

Akka also has all kinds of cool extras that scala.actors doesn't have, like durable mailboxes, coordinated transactions (though not across remote actors AFAIK), agents (basically one-off actors), and supervisor hierarchies.

Scalaz actors are like the absolute barest minimum API, it's a send operator, an effect strategy, an optional error handler, and that's it.  But from that minimal base, you can construct pretty much anything else you want, as long as you're willing to dive into some hairy type theory to do it.  I'm pondering porting scalaz actors to Java, since the implementation is simple enough to do it.  Not going to bother til I have a use case for doing it in Java and not Scala though..


Offline Gudradain
« Reply #4 - Posted 2012-07-31 03:22:08 »

Yeah I found out about scala.actors memory leak while I was struggling to do my first example with actor. I implemented the Box, Producer, Consumer example from Java. Here is how the code look like :

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
package scalasync

import scala.actors.Actor;

object Bonjour {
 
  case object Get;
  case object OK;
 
  class Box2 extends Actor{
    var isEmpty = true;
    var content : Any = null;
    def act(){
      while(true){
         if(isEmpty){
            receive {
            case i:Any => put(i); sender ! OK;
            }
         }else{
           receive {
             case Get => get(); sender ! OK;
           }
         }
      }
    }
    def put(ref : Any){
      content = ref;
      isEmpty = false;
      println("---Put : " + ref);
    }
    def get(){
      println("Get : " + content);
      content = null;
      isEmpty = true;
    }
  }
 
  class Producer(box : Box2) extends Actor{
    def act(){
      for(i <- 0 until 10){
        println("Putting : " + i);
        box ! i;
        receive{
          case OK => ;//Do nothing
        }
      }
    }
  }
 
  class Consumer(box : Box2) extends Actor{
    def act(){
      for(i <- 0 until 10){
        println("Getting : " + i);
        box ! Get
        receive{
          case OK => ;//Do nothing
        }
      }
    }
  }
 
  def main(args: Array[String]){
    var box2 = new Box2();
    var producer = new Producer(box2);
    var consumer = new Consumer(box2);
    box2.start();
    producer.start();
    consumer.start();
  }

}


But the strange thing is that I currently consider that sort of memory leak as wanted behavior... I mean if you look at the code, the consumer is waiting until the producer put something in the box. If the Consumer send the message first, the box will not understand it and that message will be stored and process later when the box will wait for the Get message. Is there another way to get the same behavior?
Offline Gudradain
« Reply #5 - Posted 2012-07-31 03:28:34 »

I'm pondering porting scalaz actors to Java, since the implementation is simple enough to do it.  Not going to bother til I have a use case for doing it in Java and not Scala though..

Sounds like fun Smiley
Offline sproingie

JGO Kernel


Medals: 202



« Reply #6 - Posted 2012-07-31 03:36:19 »

Yeah, the nested receive idiom is the reason why scala.actors scans its mailbox instead of strictly queing it.  Still, there are other ways to do it that don't require a memory leak and silent dropping of mismatches, neither of which I can ever consider to be a feature (since you can always do the latter with a "case _").  Check out "become" in Akka for how you switch out receives.  In scalaz, you'd have to do something really different, probably involving a state monad or something.

1  
2  
3  
            receive {
            case i:Any => put(i); sender ! OK;
            }


This to me looks really wrong.  If your producer is empty and you send it a Get, it will store the Get.  Also, you should be using an Option and not null, but that's just general scala style not apropos of the actor.
Offline Roquen
« Reply #7 - Posted 2012-07-31 05:48:00 »

As an aside. I've always found it interesting (in a bad way) that so few language support a DoesNotUnderstand as that was one of the awesome features of smalltalk.

If I were to goof around with a lightweight actor framework in Java I think I'd muck around with Kilim (but I've never done a feature-set cross comparison).
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (29 views)
2014-12-15 09:26:44

Mr.CodeIt (20 views)
2014-12-14 19:50:38

BurntPizza (40 views)
2014-12-09 22:41:13

BurntPizza (75 views)
2014-12-08 04:46:31

JscottyBieshaar (37 views)
2014-12-05 12:39:02

SHC (50 views)
2014-12-03 16:27:13

CopyableCougar4 (47 views)
2014-11-29 21:32:03

toopeicgaming1999 (113 views)
2014-11-26 15:22:04

toopeicgaming1999 (100 views)
2014-11-26 15:20:36

toopeicgaming1999 (30 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!