Re: Actors performance, was: mem leak

Hi Alex,

That's a good point.

The only issue is that we'd have to make sure that it is still possible 
to override the def `scheduler` in the `Actor` trait. Also, we probably 
have to change the `SchedulerAdapter` trait, so that it wraps 
`Runnable`s into `FJTask`s.

I didn't have time to look into it in detail, yet. But, if we can make 
sure that your suggested changes integrate well with all the rest of the 
scheduler framework, I'd be very happy to integrate your patch.

Thanks,
Philipp

Alex Yakovlev wrote:
> Hi Philipp,
> 
> performance-wise, have you considered inheriting Reaction from FJTask
> instead of wrapping it? I mean:
> 
> class Reaction extends FJTask {
> ...
> }
> 
> and in Scheduler.scala:
> 
>   def execute(task: Runnable) {
>     currentThread match {

Re: Actors performance, was: mem leak

Hi Philipp,

Philipp Haller-2 wrote:
> 
> The only issue is that we'd have to make sure that it is still possible 
> to override the def `scheduler` in the `Actor` trait.
> 

Since it is important to change actor's schedulers, I suppose it is better
to completely hide current implementation with FJTask and leave Runnable in
all *Scheduler traits and classes. So that alternative scheduler
implementations will not depend on FJTask and don't even need to know about
it.

The only overhead will be is checking in object Scheduler.execute if task is
FJTask or general Runnable. IMHO, it is small and worth avoiding of strong
binding of all scheduler framework to current FJTask-based implementation.

So what I suggest is the following:

1. in Reaction.scala:

class Reaction extends FJTask // instead of Runnable

2. in Scheduler.scala:

object Scheduler extends IScheduler {
...
  def execute(task: Runnable) {

ProGuard incompatible with current Scala trunk build

I filed this bug report with on the ProGuard tracker:

https://sourceforge.net/tracker/?func=detail&aid=2725052&group_id=54750&atid=474704

I don't know whether it's a ProGuard 4.3 bug or a scalac (2.8.0.r17416)
bug or both.  I'll see what the ProGuard guy thinks.

In the meantime, if anyone wants to use ProGuard with the Scala trunk,
here's how.  In the ProGuard 4.3 source, at line 114 of
src/proguard/classfile/ClassPool.java, in the classesAccept method,
replace this line with:

  clazz.accept(classVisitor);

with:

  if( ! clazz.getName().equals( "scala/util/parsing/combinatorold/syntactical/BindingParsers" ) &&
      ! clazz.getName().equals( "scala/util/parsing/ast/Binders" ) )
    clazz.accept(classVisitor);

and rebuild ProGuard.  There must be something odd about those two
classes.  (Fortunately they happen to be two classes I don't need.)
Another option would be to remove those classes from scala-library.jar
before running it through ProGuard.  (Though that might cause a bunch of
missing-class warnings unless you ripped out a bunch of associated
classes, too.)

--

-- 
Seth Tisue / http://tisue.net

DTO in Scala

Does Data Transfer Object pattern make sense in Scala? Are there
better options? Is there a kind of BeansUtils/Dozer API for mapping
scala objects?
Thanks in advance.

- Andrés

aspectJ experiment: observing property changes

Re: aspectJ experiment: observing property changes

Re: aspectJ experiment: observing property changes

Re: aspectJ experiment: observing property changes

Shunting Yard Algorithm

As a newbie to parser combinators, I'd appreciate feedback on this:
http://cleverlytitled.blogspot.com/2009/04/shunting-yard-algorithm.html

Especially if there is a way to eliminate my chainLeft(...) and
chainRight(...) methods with something in the std library.

-Mitch

Re: DTO in Scala