Nabble - Scala - User

Re: Re: lazy filtering

2009-11-08T21:06:56Z

Hmm, I'm not sure - unlike your bug description the predicate is not getting called more than once, its just surprising (to me) that it is eagerly called - iterating through the first few elements until it finds the first match, after which, any subsequent calls to Iterator.take(n) work as expected.

As I said, not really a bug for my use-case - though I could well imagine that there must be use-cases where you'd expect to not have to call an expensive predicate till the absolute last moment possible.

Ishaaq

2009/11/9 Eric Willigers <ewilligers@...>

Ishaaq Chandy wrote:

Cool, thanks David, yes that works - and is much simpler than some of the monstrosities I was trying out, though the method to get the Iterator from a List is "elements" not "iterator".

interestingly though, running the for comprension over the Iterator instead of the List eagerly runs foo() on the first few foos to pre-fetch the first result before the call to take(n) - not really a problem for what I want to do but I found it a bit surprising.

You might be seeing
http://lampsvn.epfl.ch/trac/scala/ticket/2552

The Iterator returned by Iterator.filter evaluates the predicate more times than it needs to: a call to next after hasNext need not call the predicate, but currently does, and repeated calls to hasNext need not call the predicate, but currently do.

Re: lazy filtering

2009-11-08T20:35:03Z

Ishaaq Chandy wrote:
> Cool, thanks David, yes that works - and is much simpler than some of
> the monstrosities I was trying out, though the method to get the
> Iterator from a List is "elements" not "iterator".
>
> interestingly though, running the for comprension over the Iterator
> instead of the List eagerly runs foo() on the first few foos to
> pre-fetch the first result before the call to take(n) - not really a
> problem for what I want to do but I found it a bit surprising.

You might be seeing
http://lampsvn.epfl.ch/trac/scala/ticket/2552

The Iterator returned by Iterator.filter evaluates the predicate more
times than it needs to: a call to next after hasNext need not call the
predicate, but currently does, and repeated calls to hasNext need not
call the predicate, but currently do.

Re: lazy filtering

2009-11-08T20:08:27Z

On Sun, Nov 8, 2009 at 8:01 PM, Ishaaq Chandy <ishaaq@...> wrote:
> Cool, thanks David, yes that works - and is much simpler than some of the
> monstrosities I was trying out, though the method to get the Iterator from a
> List is "elements" not "iterator".

It is right now. In 2.8 it becomes iterator, and I forgot to
back-translate it. (elements will remain as deprecated)

>
> interestingly though, running the for comprension over the Iterator instead
> of the List eagerly runs foo() on the first few foos to pre-fetch the first
> result before the call to take(n) - not really a problem for what I want to
> do but I found it a bit surprising.

Indeed.

-- David

>
> Ishaaq
>
>
>
> 2009/11/9 David Hall <dlwh@...>
>>
>>
>> do the for comprehension on on foos.iterator, and then on the result
>> take(n).toList
>>
>> -- David
>>
>

Re: lazy filtering

2009-11-08T20:01:57Z

Cool, thanks David, yes that works - and is much simpler than some of the monstrosities I was trying out, though the method to get the Iterator from a List is "elements" not "iterator".

interestingly though, running the for comprension over the Iterator instead of the List eagerly runs foo() on the first few foos to pre-fetch the first result before the call to take(n) - not really a problem for what I want to do but I found it a bit surprising.

Ishaaq

2009/11/9 David Hall <dlwh@...>

do the for comprehension on on foos.iterator, and then on the result
take(n).toList

-- David

Re: lazy filtering

2009-11-08T19:30:08Z

On Sun, Nov 8, 2009 at 7:23 PM, Ishaaq Chandy <ishaaq@...> wrote:

> Hi guys,
> I have a list of Foo instances. The Foo trait defines a single method call
> bar() which returns either a Some(Baz) or None.
>
> I need to find the first n instances that return a Some and collate those
> Somes to return a List[Some[Baz]] of length <= n.
>
> Here is my naive first cut at this (warning non-compiler-checked code
> ahead):
>
> val allResults: List[Some(Baz)] = (for
> foo <- foos
> result = foo.bar()
> if(result != None)
> ) yield result
> val filteredResults = (allResults.length <= n) allResults else
> allResults.dropRight(allResults.length - n)

do the for comprehension on on foos.iterator, and then on the result
take(n).toList

-- David

>
> But this is ineficient as it evaluates bar() on every instance not just the
> first n results - what I did not mention above is that bar() is an expensive
> operation and I would like to avoid calling it if I can.
>
> My intuition tells me I should be able to formulate a construct with
> takeWhile and a projection but my attempts at it can't get past calling
> bar() twice - once for the check and a second time for the yield. I fear my
> scala-foo is not up to scratch yet - hints/insights anyone?
>
> I know how to solve the problem with imperative code - my object is to find
> the functional equivalent.
>
> Ishaaq
>

lazy filtering

2009-11-08T19:23:54Z

Hi guys,
I have a list of Foo instances. The Foo trait defines a single method call bar() which returns either a Some(Baz) or None.

I need to find the first n instances that return a Some and collate those Somes to return a List[Some[Baz]] of length <= n.

Here is my naive first cut at this (warning non-compiler-checked code ahead):

val allResults: List[Some(Baz)] = (for
foo <- foos
result = foo.bar()
if(result != None)
) yield result
val filteredResults = (allResults.length <= n) allResults else allResults.dropRight(allResults.length - n)

But this is ineficient as it evaluates bar() on every instance not just the first n results - what I did not mention above is that bar() is an expensive operation and I would like to avoid calling it if I can.

My intuition tells me I should be able to formulate a construct with takeWhile and a projection but my attempts at it can't get past calling bar() twice - once for the check and a second time for the yield. I fear my scala-foo is not up to scratch yet - hints/insights anyone?

I know how to solve the problem with imperative code - my object is to find the functional equivalent.

Ishaaq

Cannot get FeatureSpec structure to show up in the output when combined with JUnitSuite

2009-11-08T13:21:25Z

Given the following code:

port collection.mutable.Stack
import org.junit.Test
import org.scalatest.junit.JUnitSuite
import org.scalatest.matchers.MustMatchers
import org.scalatest.{GivenWhenThen, FeatureSpec}

class ExampleSpecTest extends FeatureSpec with JUnitSuite with
GivenWhenThen with MustMatchers
{

@Test
def featureSpecExample() {
feature("The user can pop an element off the top of the stack") {

info("As a programmer")
info("I want to be able to pop items off the stack")
info("So that I can get them in last-in-first-out order")

scenario("pop is invoked on a non-empty stack") {

given("a non-empty stack")
val stack = new Stack[Int]
stack.push(1)
stack.push(2)
val oldSize = stack.size

when("when pop is invoked on the stack")
val result = stack.pop()

then("the most recently pushed element should be returned")
result must be === 2

and("the stack should have one less item than before")
stack.size must be === oldSize - 1
}

scenario("pop is invoked on an empty stack") {

given("an empty stack")
val emptyStack = new Stack[String]

when("when pop is invoked on the stack")
then("NoSuchElementException should be thrown")
evaluating { emptyStack.pop() } must produce
[NoSuchElementException]

and("the stack should still be empty")
emptyStack must be ('empty)
}
}
}
}

when I run this version of ExampleSpecTest, I am getting the following
output:
Run starting. Expected test count is: 1
ExampleSpecTest:
Test Starting - ExampleSpecTest: featureSpecExample
Test Succeeded - ExampleSpecTest: featureSpecExample
Run completed in 255 milliseconds.
Total number of tests run: 1
Suites: completed 1, aborted 0
Tests: succeeded 1, failed 0, ignored 0, pending 0
All tests passed.

I am not getting any of the expected given/when/then output in the report

Expected:

Run starting. Expected test count is: 1
ExampleSpecTest:
Test Starting - ExampleSpecTest: featureSpecExample
Feature: The user can pop an element off the top of the stack
As a programmer
I want to be able to pop items off the stack
So that I can get them in last-in-first-out order
Scenario: pop is invoked on a non-empty stack
Given a non-empty stack
When when pop is invoked on the stack
Then the most recently pushed element should be returned
And the stack should have one less item than before
Scenario: pop is invoked on an empty stack
Given an empty stack
When when pop is invoked on the stack
Then NoSuchElementException should be thrown
And the stack should still be empty
Test Succeeded - ExampleSpecTest: featureSpecExample
Run completed in 96 milliseconds.
Total number of tests run: 2
Suites: completed 1, aborted 0
Tests: succeeded 1, failed 0, ignored 0, pending 0
All tests passed.

This email and any files included with it may contain privileged,
proprietary and/or confidential information that is for the sole use
of the intended recipient(s). Any disclosure, copying, distribution,
posting, or use of the information contained in or attached to this
email is prohibited unless permitted by the sender. If you have
received this email in error, please immediately notify the sender
via return email, telephone, or fax and destroy this original transmission
and its included files without reading or saving it in any manner.
Thank you.

Re: Ranges.Double produces BigDecimal

2009-11-08T09:37:02Z

Sorry, it is already fixed in latest nightly build.

On Sun, Nov 8, 2009 at 5:26 PM, Jan Kotek <opencoeli@...> wrote:

> Hi,
>
> I thing I found problem in 2.8 library. Double range does not return
> doubles, but BigDecimals.
>
> Problem is in object: scala.collection.immutable.Range.Double
>
> This is actual type definition produced by Scala decompiler:
>
> object Double extends java.lang.Object with scala.ScalaObject {
> def this() = { /* compiled code */ }
> def apply(start : scala.Double, end : scala.Double, step :
> scala.Double) :
> scala.collection.immutable.GenericRange.Exclusive[scala.BigDecimal] =
> { /* compiled code */ }
> def inclusive(start : scala.Double, end : scala.Double, step :
> scala.Double) :
> scala.collection.immutable.GenericRange.Inclusive[scala.BigDecimal] =
> { /* compiled code */ }
> }
>
> From source code, it seems that BigDecimals are used internally. At
> output there is conversion, but it fails. So BigDecimal range is used
> in result.
>
> Jan
>

Ranges.Double produces BigDecimal

2009-11-08T09:26:58Z

Hi,

I thing I found problem in 2.8 library. Double range does not return
doubles, but BigDecimals.

Problem is in object: scala.collection.immutable.Range.Double

This is actual type definition produced by Scala decompiler:

object Double extends java.lang.Object with scala.ScalaObject {
def this() = { /* compiled code */ }
def apply(start : scala.Double, end : scala.Double, step :
scala.Double) :
scala.collection.immutable.GenericRange.Exclusive[scala.BigDecimal] =
{ /* compiled code */ }
def inclusive(start : scala.Double, end : scala.Double, step :
scala.Double) :
scala.collection.immutable.GenericRange.Inclusive[scala.BigDecimal] =
{ /* compiled code */ }
}

From source code, it seems that BigDecimals are used internally. At
output there is conversion, but it fails. So BigDecimal range is used
in result.

Jan

Re: trait X extends Y vs trait X {this: Y=> }

2009-11-08T05:51:16Z

Dimitris Andreou a écrit :
> Hmm. Now I realize that both " this: A =>" and "self: A =>" are there.
> Strange redundancy (assuming they are equivalent). Anyone knows why
> this is so?

It's just a binding name. You can use whatever is meaningful for your
use case, and "self" or "this" are conventional name.

But you can rebind "this" to something else without the type annotation,
for example to make reference to that "this" in inner classes.

Ex:
class Outer(name:String) {
outer =>
class Inner {
def whoOwnsMe() {
println( outer.name )
}
}
}

--
Francois Armand
http://fanf42.blogspot.com

Re: trait X extends Y vs trait X {this: Y=> }

2009-11-08T05:21:30Z

Hmm. Now I realize that both " this: A =>" and "self: A =>" are there.
Strange redundancy (assuming they are equivalent). Anyone knows why
this is so?

2009/11/7 Daniel Sobral <dcsobral@...>:

> Well, let me put it another way. If you say X extends Y, then you are saying
> X has Y's implementation. If you say self: Y =>, you are saying the class
> you are mixed into must implement interface Y.
> In the first case, the class mixing X in can't choose a descendant of Y, in
> the second it can.
>
> On Fri, Nov 6, 2009 at 10:35 PM, Ken Scambler <ken.scambler@...>
> wrote:
>>
>> Hi everyone,
>> I am a little confused by the two ways to indicate that a trait must form
>> part of a given concrete class: extension versus self-types, as shown in
>> the
>> subject. I have noticed that there are some differences in behaviour
>> between the two.
>>
>> Can anyone help explain the difference between them, and what situations
>> benefit from using one or the other?
>>
>> Thanks for you time,
>> Ken
>> --
>> View this message in context:
>> http://old.nabble.com/trait-X-extends-Y-vs-trait-X-%7Bthis%3A-Y%3D%3E-%7D-tp26233138p26233138.html
>> Sent from the Scala - User mailing list archive at Nabble.com.
>>
>
>
>
> --
> Daniel C. Sobral
>
> Veni, vidi, veterni.
>

Re: trait X extends Y vs trait X {this: Y=> }

2009-11-07T11:43:36Z

On Sat, Nov 7, 2009 at 7:33 PM, Daniel Sobral <dcsobral@...> wrote:
> Well, let me put it another way. If you say X extends Y, then you are saying
> X has Y's implementation. If you say self: Y =>, you are saying the class
> you are mixed into must implement interface Y.
> In the first case, the class mixing X in can't choose a descendant of Y, in
> the second it can.

It can in both cases,

scala> class A
defined class A

scala> class B extends A
defined class B

scala> trait C extends A
defined trait C

scala> class D extends B with C
defined class D

Cheers,

Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Re: trait X extends Y vs trait X {this: Y=> }

2009-11-07T11:33:44Z

Well, let me put it another way. If you say X extends Y, then you are saying X has Y's implementation. If you say self: Y =>, you are saying the class you are mixed into must implement interface Y.

In the first case, the class mixing X in can't choose a descendant of Y, in the second it can.

On Fri, Nov 6, 2009 at 10:35 PM, Ken Scambler <ken.scambler@...> wrote:

Hi everyone,
I am a little confused by the two ways to indicate that a trait must form
part of a given concrete class: extension versus self-types, as shown in the
subject. I have noticed that there are some differences in behaviour
between the two.

Can anyone help explain the difference between them, and what situations
benefit from using one or the other?

Thanks for you time,
Ken
--
View this message in context: http://old.nabble.com/trait-X-extends-Y-vs-trait-X-%7Bthis%3A-Y%3D%3E-%7D-tp26233138p26233138.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
Daniel C. Sobral

Veni, vidi, veterni.

Re: how does += work

2009-11-07T11:17:14Z

That made me wonder whether the following would work (it doesn't):

scala> class A(var x: Int) { def m_(y:Int) = new A(y) }
defined class A

scala> var a = new A(10)
a: A = A@57baae

scala> a = a m_ 5
a: A = A@6d6c90

scala> a m_= 5
<console>:7: error: value m_= is not a member of A
a m_= 5
^

scala>

(m_= is not an 'operator' so the = magic doesn't apply)

On Sat, Nov 7, 2009 at 7:13 AM, Paul Phillips <paulp@...> wrote:

Re: 2.8.0 and explicit implicit import fails

2009-11-07T09:43:58Z

On Nov 6, 2009, at 10:09 PM, Blair Zajac wrote:

> Using r19410 importing a single implicit def fails:
>
>
> scala> import scala.collection.JavaConversions.asMap
> import scala.collection.JavaConversions.asMap
>
> scala> val sm : scala.collection.Map[Int,Int] = new java.util.HashMap
> [Int,Int]
> <console>:5: error: type mismatch;
> found : java.util.HashMap[Int,Int]
> required: scala.collection.Map[Int,Int]
> val sm : scala.collection.Map[Int,Int] = new java.util.HashMap
> [Int,Int]
>
>
> but importing all the implicits works:
>
>
> scala> import scala.collection.JavaConversions._
> import scala.collection.JavaConversions._
>
> scala> val sm : scala.collection.Map[Int,Int] = new java.util.HashMap
> [Int,Int]
> sm: scala.collection.Map[Int,Int] = Map()
>
>
> Is this a bug?

After chatting on IRC, Paul Philips also thought that this may be a
bug, so I opened:

https://lampsvn.epfl.ch/trac/scala/ticket/2591

Blair

Re: Using actors to access a shared resource

2009-11-07T08:51:28Z

One can @synchronized methods in Scala, so your Java example is directly translatable into Scala. Using the Actor paradigm one would use some sort of Store and Get message. Both ultimately use monitors to coordinate thread access. The Actor however has some additional overhead associated with Message construction/deconstruction/queueing/dequeueing.

Both approaches allow one to ensure one and only one thread is accessing state at any given time. Personally I would not use an Actor whose sole function was no more than synchronizing a collection data structure. One certainly could however.

On a complete aside I do use Actors frequently and there is a usage pattern I use that I'm not sure I've seen mentioned. I'm think its safe. :)

Often my Actor compartmentalizes quite a bit of state and all state updating behaviour occurs via messages. However, I may have one or more readers of simple internal state such as a counter, FSM state value etc. The Actor approach requires some variation of the following message set for the Actor {RequestCounterValue, CounterValueResponse, SetCounterValue}.

However if one can ensure that state is mutated by one and only one thread, then multiple readers of state can safely read state values which are volatile. The single thread mutation constraint is given by the Actor. So I think the following is safe, but is unpure Actor behavior.

case class SetCounter (x: Int)

val a = actor {
@volatile private counter: Int

def count () = counter

def act () {
while (true) {
receive {
case SetCounter (x) => counter = x
}
}

Multiple parallel readers should be able to invoke a.count without requiring a lock and safely read the counter value. In a sense a low level ReadWriteLock.

On Sat, Nov 7, 2009 at 10:58 AM, David Copeland <davec@...> wrote:

Asked this on stackoverflow, but my example domain kinda got in the way.

I wish to hash items and look them up by hash later. I wish to do this in a mult-threaded context, but have a single shared key/value/hasher.

In Java, I would have something like:

public class Hasher {
/** Stores and returns hash */
public synchronized String store(Object o) { /* .. */ }

/** Given hash, gets the stored object */
public synchronized Object get(String hash) { /* .. */ }
}

I'm told that the actor/message paradigm is a better way to handle concurrency, plus I'd like to learn more about how this works in Scala.

So, if the key/value/hasher is an actor that receives messages and sends hashes/objects back to the sender, I see two ways to do this, neither of which is appealing:

Client uses either a future or !? to block on the return
Client is also an actor that receives hash/Object in his act() method
Is there another way, or is this just not something one should do with Actors, or are the two options above not that bad?

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

Re: Using actors to access a shared resource

2009-11-07T08:39:49Z

If you're using 2.8, there's always
scala.collections.mutable.SynchronizedMap, which gives you the nicely
atomic getOrElseUpdate() method. I'm not sure what the 2.7 equivalent
is.

Out of curiosity, why do you think that neither of your proposed
options is appealing?

On Sat, Nov 7, 2009 at 3:58 PM, David Copeland <davec@...> wrote:

> Asked this on stackoverflow, but my example domain kinda got in the way.
>
> I wish to hash items and look them up by hash later. I wish to do this in a
> mult-threaded context, but have a single shared key/value/hasher.
>
> In Java, I would have something like:
>
> public class Hasher {
> /** Stores and returns hash */
> public synchronized String store(Object o) { /* .. */ }
>
> /** Given hash, gets the stored object */
> public synchronized Object get(String hash) { /* .. */ }
> }
>
> I'm told that the actor/message paradigm is a better way to handle
> concurrency, plus I'd like to learn more about how this works in Scala.
>
> So, if the key/value/hasher is an actor that receives messages and sends
> hashes/objects back to the sender, I see two ways to do this, neither of
> which is appealing:
>
> Client uses either a future or !? to block on the return
> Client is also an actor that receives hash/Object in his act() method
>
> Is there another way, or is this just not something one should do with
> Actors, or are the two options above not that bad?
>
>
> Dave
>
> ---
> My Blog: http://www.naildrivin5.com/blog
> Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
> Fork me on Github: http://davetron5000.github.com
>
>
>

Scala XMPP?

2009-11-07T08:15:49Z

I've asked about this once before, but it was more tangentially and some months ago, so let's check again: has anyone yet written, or is anyone working on, a serious Scala-based XMPP server? IMO, Scala and XMPP are a natural match -- Scala actors look to be one of the better ways to write a scalable, reliable, modular XMPP server. But so far, I haven't found one.

I know that you can use Scala inside Openfire, but frankly, that kinda sucks -- I've spent a number of months working in that environment, and the impedance mismatch is pretty serious. You need a lot of shims to adapt Openfire to actors, and it's a pain in the ass to translate Openfire's XML model to and from Scala's.

There's ESME, but that doesn't appear to really be an XMPP server; rather, it seems to be a general protocol-neutral micromessaging infrastructure, which isn't what I'm looking for here.

You can get actor-style behaviour with ejabberd, of course -- but I just plain don't *like* Erlang.

And Lift appears to have XMPP *client* behaviour in it, but as far as I can tell, it isn't really an XMPP server.

The impetus here is Google Wave. One aspect of the Wave project is that Google is trying to foster an open protocol, and open-source development of reference servers for that protocol. The server-to-server protocol is XMPP; there seems to be rough consensus that the client-server protocol should be, as well. The first cut is written in Java (on Openfire), but many of us feel that we could do better. Personally, I think a Scala implementation would rock.

So the first step towards that is a raw XMPP server framework -- it would eventually need some of the conventional XMPP capabilities, but a pretty idiosyncratic subset. Before I start (very slowly) writing that, I want to make sure somebody's not already working on it.

For that matter, are there folks who would be interested in helping with this, if I started it? I don't have much experience creating an open-source project, but this seems like it should definitely be one...

Using actors to access a shared resource

2009-11-07T07:58:13Z

Asked this on stackoverflow, but my example domain kinda got in the way.

I wish to hash items and look them up by hash later. I wish to do this in a mult-threaded context, but have a single shared key/value/hasher.

In Java, I would have something like:

public class Hasher {
/** Stores and returns hash */
public synchronized String store(Object o) { /* .. */ }

/** Given hash, gets the stored object */
public synchronized Object get(String hash) { /* .. */ }
}

I'm told that the actor/message paradigm is a better way to handle concurrency, plus I'd like to learn more about how this works in Scala.

So, if the key/value/hasher is an actor that receives messages and sends hashes/objects back to the sender, I see two ways to do this, neither of which is appealing:

Client uses either a future or !? to block on the return
Client is also an actor that receives hash/Object in his act() method

Is there another way, or is this just not something one should do with Actors, or are the two options above not that bad?

Dave

---
My Blog: http://www.naildrivin5.com/blog
Scala Tour for Java Developers: http://www.naildrivin5.com/scalatour
Fork me on Github: http://davetron5000.github.com

Re: how does += work

2009-11-07T07:47:02Z

Excellent!
Yet another use for our friend the underscore :)

On Sat, Nov 7, 2009 at 3:13 PM, Paul Phillips <paulp@...> wrote:

> On Sat, Nov 07, 2009 at 07:01:58PM +0530, Himanshu wrote:
>> scala> var a = new A(10)
>> a: A = A@1ca6954
>>
>> scala> a m= 5 *//Notice, this does not work*
>> <console>:8: error: reassignment to val
>> a m= 5
>> ^
>
> m= is not even a legal token. Operators can only be composed of
> operator characters (see the specification) or if you want to mix
> alphanumerics, they have to be underscore separated liked foo_++.
>
> --
> Paul Phillips | Every election is a sort of advance auction sale
> Future Perfect | of stolen goods.
> Empiricist | -- H. L. Mencken
> pull his pi pal! |----------* http://www.improving.org/paulp/ *----------
>

Re: how does += work

2009-11-07T07:13:54Z

On Sat, Nov 07, 2009 at 07:01:58PM +0530, Himanshu wrote:
> scala> var a = new A(10)
> a: A = A@1ca6954
>
> scala> a m= 5 *//Notice, this does not work*
> <console>:8: error: reassignment to val
> a m= 5
> ^

m= is not even a legal token. Operators can only be composed of
operator characters (see the specification) or if you want to mix
alphanumerics, they have to be underscore separated liked foo_++.

--
Paul Phillips | Every election is a sort of advance auction sale
Future Perfect | of stolen goods.
Empiricist | -- H. L. Mencken
pull his pi pal! |----------* http://www.improving.org/paulp/ *----------

Re: how does += work

2009-11-07T05:31:58Z

Thanks. But looks like my earlier response was not sent properly, anyway here it is again..

>>>
>>> Scala has special handling of operators of the form "?=", where ? is
>>> an operator. Specifically, if there is no ?= method on the LHS, and
>>> there is no implicit conversion to an object that has a ?= method,
>>> then the expression is treated as "x = x ? y" (but only if that would
>>> compile...)

> Scala's rules for lexing splits up "op=" into two tokens, and then
> attempts to compile (a op) = 5. It won't if "op" is replaced with a
> sequence of operator characters.

Can we explain why following is not working?

scala> class A(var x: Int) { def m(y:Int) = new A(y) }
defined class A

scala> var a = new A(10)
a: A = A@1ca6954

scala> a m= 5            //Notice, this does not work
<console>:8: error: reassignment to val
       a m= 5
          ^

scala> (a m) = 5         //This does not work either
<console>:1: error: ';' expected but '=' found.
       (a m) = 5
             ^

scala> a = a m 5       //But this does.
a: A = A@d1e32d

Why the Java Code Editor of Java IDE (e.g. Eclipse) can`t detect the methods (or Functions) of Scala Class ?

2009-11-07T03:53:40Z

Hello, friends:
When call the methods write by Scala in Java Code, why the Java Code Editor of Java IDE (e.g. Eclipse) can`t detect the methods (or Functions) of Scala Class ?

Please see the email attachment.

--
We are the best ! ! ! !

1.jpg (52K) Download Attachment
2.jpg (72K) Download Attachment

Re: how does += work

2009-11-07T02:07:43Z

sorry, forgot cc'ing scala-user...

On Sat, Nov 7, 2009 at 3:33 PM, Himanshu <g.himanshu@...> wrote:

Thanks David, But why, then following doesn't work...

scala> class A(var x: Int) { def op(y:Int) = new A(y) }
defined class A

scala> var a = new A(10)
a: A = A@914272

scala> a op= 5                                //Note that this does not work, even though it should be same as a = a op 5
<console>:6: error: reassignment to val
       a op= 5
           ^

scala> a = a op 5                           //and indeed a = a op 5 works
a: A = A@7691c0

scala> a.x
res15: Int = 5

On Sat, Nov 7, 2009 at 2:41 PM, David Hall <dlwh@...> wrote:

On Sat, Nov 7, 2009 at 1:02 AM, Himanshu <g.himanshu@...> wrote:
>
> scala> var x = 10
> x: Int = 10
>
> scala> x += 2
>
> scala> x
> res12: Int = 12
>
> How does += work when It is neither a method defined in Int nor in RichInt ?

Scala has special handling of operators of the form "?=", where ? is
an operator. Specifically, if there is no ?= method on the LHS, and
there is no implicit conversion to an object that has a ?= method,
then the expression is treated as "x = x ? y" (but only if that would
compile...)

This means that you can define +, and get += (on vars) for free.

-- David

>
> It seems that one can use any method name suffixed with '=' to do assignment
> but its not clear to me how its happening.
>
> Thanks,
> Himanshu
>

Re: GroupPanel

2009-11-07T02:07:12Z

I've done some work in scala.swing. At first glance this looks good
to me, good work Naftoli, this'll be a welcome addition!

Given this brave new world of code reviews I'd be happy to look at it
in more detail later today, but can't see any obvious flaws... :)

On Fri, Nov 6, 2009 at 2:10 PM, martin odersky <martin.odersky@...> wrote:

> Thanks for the contribution, Naftoli. Ingo is currently doing an
> internship, so it might be a while until he can respond. From what I
> can see it looks good to me, but I am not that much of an expert. Can
> other people comment? In any case the class would need to be
> documented before it can be included.
>
> Cheers
>
> -- Martin
>
>
>
> On Tue, Nov 3, 2009 at 5:40 AM, Naftoli Gugenheim <naftoligug@...> wrote:
>> I wrote a potential contribution to scala-swing: GroupPanel, a Panel for
>> GroupLayout.
>> Here's my code (demo at the end)
>> package chavrusa.frontend
>> import javax.swing.{JPanel, GroupLayout}
>> import scala.swing._
>>
>> trait GroupPanel extends Panel {
>>   override lazy val peer: javax.swing.JPanel = {
>>    val p = new javax.swing.JPanel with SuperMixin
>>    p.setLayout(new GroupLayout(p))
>>    p
>>   }
>>   private lazy val layout = peer.getLayout.asInstanceOf[GroupLayout]
>>
>>   def autoCreateGaps = layout.getAutoCreateGaps()
>>   def autoCreateGaps_=(b: Boolean) = layout.setAutoCreateGaps(b)
>>
>>   def autoCreateContainerGaps = layout.getAutoCreateContainerGaps
>>   def autoCreateContainerGaps_=(b: Boolean) =
>> layout.setAutoCreateContainerGaps(b)
>>
>>
>>   sealed case class Size(value: Int)
>>   case object SizePreferred extends Size(GroupLayout.PREFERRED_SIZE)
>>   case object SizeDefault extends Size(GroupLayout.DEFAULT_SIZE)
>>   implicit def intToSize(value: Int) = Size(value)
>>
>>   case class SizeRange(min: Size, pref: Size, max: Size)
>>   object DefaultSizes extends SizeRange(SizeDefault, SizeDefault,
>> SizeDefault)
>>   def Rigid(size: Size) = SizeRange(size, size, size)
>>
>>   object ComponentPlacement extends Enumeration {
>>    import javax.swing.LayoutStyle.ComponentPlacement._
>>    val Indent = Value(INDENT.ordinal)
>>    val Related = Value(RELATED.ordinal)
>>    val Unrelated = Value(UNRELATED.ordinal)
>>   }
>>   object Alignment extends Enumeration {
>>    import GroupLayout.Alignment._
>>    val Leading = Value(LEADING.ordinal)
>>    val Trailing = Value(TRAILING.ordinal)
>>    val Center = Value(CENTER.ordinal)
>>    val Baseline = Value(BASELINE.ordinal)
>>   }
>>   implicit def convertAlignment(a: Alignment.Value): GroupLayout.Alignment =
>>    GroupLayout.Alignment.values()(a.id)
>>
>>   sealed trait GroupItem
>>   sealed trait AnyGroupItem extends GroupItem
>>   sealed trait SeqGroupItem extends GroupItem
>>   sealed trait ParGroupItem extends GroupItem
>>   case class ComponentItem(component: Component, sizes: SizeRange) extends
>> AnyGroupItem
>>   case class BaselineComponentItem(component: Component, sizes: SizeRange)
>> extends SeqGroupItem
>>   case class Gap(sizes: SizeRange) extends AnyGroupItem
>>   case class Subgroup(group: Group) extends AnyGroupItem
>>   case class BaselineSubgroup(group: Group) extends SeqGroupItem
>>   case class ContainerGap(pref: Int, max: Int) extends SeqGroupItem
>>   case class PreferredGap(placement: ComponentPlacement.Value, pref: Int,
>> max: Int) extends SeqGroupItem
>>   case class AlignedComponentItem(component: Component, alignment:
>> Alignment.Value, sizes: SizeRange) extends ParGroupItem
>>   case class AlignedSubgroup(alignment: Alignment.Value, group: Group)
>> extends ParGroupItem
>>   implicit def convertGroup(g: Group): Subgroup = Subgroup(g)
>>
>>   implicit def componentItem(component: Component): ComponentItem =
>> ComponentItem(component, DefaultSizes)
>>
>>   case class Group(group: GroupLayout#Group) { self =>
>>    def addItem(item: GroupItem): Unit = item match {
>>    case i: AnyGroupItem =>
>>    i match {
>>    case ComponentItem(c, SizeRange(Size(min),Size(pref),Size(max)))
>> => group.addComponent(c.peer, min,pref,max)
>>    case Gap(SizeRange(Size(min), Size(pref), Size(max))) =>
>> group.addGap(min, pref, max)
>>    case Subgroup(g) => group.addGroup(g.group)
>>    }
>>    case _ => error("Unhandled GroupItem: " + item)
>>    }
>>    def add(items: GroupItem*) = items foreach addItem
>>   }
>>   class SequentialGroup(override val group: GroupLayout#SequentialGroup)
>> extends Group(group) {
>>    def this() = this(layout.createSequentialGroup)
>>    override def addItem(item: GroupItem) = item match{
>>    case i: SeqGroupItem =>
>>    i match {
>>    case BaselineComponentItem(c,
>> SizeRange(Size(min),Size(pref),Size(max))) => group.addComponent(true,
>> c.peer, min,pref,max)
>>    case BaselineSubgroup(g) => group.addGroup(true, g.group)
>>    case ContainerGap(pref, max) => group.addContainerGap(pref,max)
>>    case PreferredGap(placement, pref, max) =>
>> group.addPreferredGap(javax.swing.LayoutStyle.ComponentPlacement.values()(placement.id),
>> pref, max)
>>    }
>>    case _ => super.addItem(item)
>>    }
>>   }
>>   class ParallelGroup(override val group: GroupLayout#ParallelGroup) extends
>> Group(group) {
>>    def this() = this(layout.createParallelGroup)
>>    override def addItem(item: GroupItem) = item match {
>>    case i: ParGroupItem =>
>>    i match {
>>    case AlignedComponentItem(c, align,
>> SizeRange(Size(min),Size(pref),Size(max))) =>
>>    group.addComponent(c.peer, align, min,pref,max)
>>    case AlignedSubgroup(align, g) =>
>>    group.addGroup(align, g.group)
>>    }
>>    case _ => super.addItem(item)
>>    }
>>   }
>>   A
>>   def sequential(items: GroupItem*) = new SequentialGroup {
>>    add(items: _*)
>>   }
>>   private type P = (GroupItem*)=>ParallelGroup
>>   private def par(group: GroupLayout#ParallelGroup): P =
>>    items => new ParallelGroup(group) {
>>    add(items: _*)
>>    }
>>   def parallel(align: Alignment.Value, resize: Boolean): P =
>>    par(layout.createParallelGroup(align, resize))
>>   def parallel(): P = parallel(Alignment.Leading, true)
>>   def parallel(align: Alignment.Value): P = parallel(align, true)
>>
>>   def baseline(resize: Boolean, anchorTop: Boolean): P =
>>    par(layout.createBaselineGroup(resize,anchorTop))
>>
>>   def honorsVisibility = layout.getHonorsVisibility()
>>   def honorsVisibility_=(b: Boolean) = layout.setHonorsVisibility(b)
>>   def honorsVisibility_=(c: Component, b: Option[Boolean]) =
>>    layout.setHonorsVisibility(c.peer, b match {
>>    case None => null
>>    case Some(true) => java.lang.Boolean.TRUE
>>    case Some(false) => java.lang.Boolean.FALSE
>>    })
>>
>>   def replace(c1: Component, c2: Component) = layout.replace(c1.peer,
>> c2.peer)
>>
>>   def linkSizes(cs: Component*) = layout.linkSize(cs.map(_.peer): _*)
>>   def linkWidths(cs: Component*) =
>> layout.linkSize(javax.swing.SwingConstants.HORIZONTAL, cs.map(_.peer): _*)
>>   def linkHeights(cs: Component*) =
>> layout.linkSize(javax.swing.SwingConstants.VERTICAL, cs.map(_.peer): _*)
>>
>>   def horizontalGroup(g: Group) = layout.setHorizontalGroup(g.group)
>>   def verticalGroup(g: Group) = layout.setVerticalGroup(g.group)
>> }
>>
>> object TestGroupPanel extends SimpleGUIApplication {
>>   val top = new Frame {
>>    contents = new GroupPanel {
>>    val label1 = new Label("Label 1")
>>    val label2 = new Label("Label 2")
>>    val text1 = new TextField
>>    val text2 = new TextField
>>    autoCreateGaps = true
>>    autoCreateContainerGaps = true
>>    horizontalGroup {
>>    sequential(
>>    parallel()(label1, label2),
>>    parallel()(text1, text2)
>>    )
>>    }
>>    verticalGroup {
>>    sequential(
>>    parallel(Alignment.Baseline)(label1, text1),
>>    parallel(Alignment.Baseline)(label2, text2)
>>    )
>>    }
>>    }
>>   }
>> }
>>
>

Re: how does += work

2009-11-07T01:11:52Z

On Sat, Nov 7, 2009 at 1:02 AM, Himanshu <g.himanshu@...> wrote:

>
> scala> var x = 10
> x: Int = 10
>
> scala> x += 2
>
> scala> x
> res12: Int = 12
>
> How does += work when It is neither a method defined in Int nor in RichInt ?

Scala has special handling of operators of the form "?=", where ? is
an operator. Specifically, if there is no ?= method on the LHS, and
there is no implicit conversion to an object that has a ?= method,
then the expression is treated as "x = x ? y" (but only if that would
compile...)

This means that you can define +, and get += (on vars) for free.

-- David

>
> It seems that one can use any method name suffixed with '=' to do assignment
> but its not clear to me how its happening.
>
> Thanks,
> Himanshu
>

how does += work

2009-11-07T01:02:31Z

scala> var x = 10
x: Int = 10

scala> x += 2

scala> x
res12: Int = 12

How does += work when It is neither a method defined in Int nor in RichInt ?

It seems that one can use any method name suffixed with '=' to do assignment but its not clear to me how its happening.

Thanks,
Himanshu

Re: trait X extends Y vs trait X {this: Y=> }

2009-11-06T22:33:35Z

On Fri, Nov 6, 2009 at 4:47 PM, Josh Suereth <joshua.suereth@...> wrote:
> The self type only enforces that you are *mixed-into* a particular type. A
> trait that extends another could possibly be used standalone.
>
> I would reserve self-types for things that truly are just mixins, and a
> "class instantiation concern". This means the following:

It can also be used to influence the linearization order of the
traits. Maybe one should be careful in using this feature, but notice
the difference in:

scala> trait Foo { def foo = println("Foo") }
defined trait Foo

scala> trait Bar extends Foo { override def foo { println("Bar"); super.foo } }
defined trait Bar

scala> trait Baz extends Foo { this : Bar => override def foo {
println("Baz"); super.foo; } }
defined trait Baz

scala> val a = new Bar with Baz;
a: java.lang.Object with Bar with Baz = $anon$1@ee13d0

scala> a.foo
Baz
Bar
Foo

scala> val b = new Baz with Bar;
b: java.lang.Object with Baz with Bar = $anon$1@4deff4f

scala> b.foo
Bar
Baz
Foo

<<<<<Versus>>>>

scala> trait Foo2 { def foo = println("foo"); }
defined trait Foo2

scala> trait Bar2 extends Foo2 { override def foo { println("bar");
super.foo } }
defined trait Bar2

scala> trait Baz2 extends Bar2 { override def foo { println("baz");
super.foo } }
defined trait Baz2

scala> new Bar2 with Baz2 foo
baz
bar
foo

scala> new Baz2 with Bar2 foo
baz
bar
foo

-- David

>
> trait X extends Y // X *is a* Y
>
> trait X { self : Y => ... }    // X is a helper that can be used with a Y.
> I would tend to prefer this over aspects for specific kinds of mixin
> functionality.
>
> An example from EJB (yes... I know)
>
> trait BaseDataAccessEJB {
>    def tx : UserTransaction
>    def entityManager : EntityManager
> }
>
>
> trait TransactionHelper { self : BaseDataAccessEJB =>
>
>    //This is a toy implementation, in reality there are far more concerns to
> worry about in this method
>    def transactional(f : => A) : A = {
>           tx.start()
>          try {
>               f
>           } finally {
>               tx.commit()
>           }
>    }
> }
>
>
> Then when creating a new EJB I can do   class MyEJB extends
> BaseDataAccessEJB with TransactionHelper
>
>
>
> I hope that helps,
>
> - Josh
>
> On Fri, Nov 6, 2009 at 7:35 PM, Ken Scambler <ken.scambler@...> wrote:
>>
>> Hi everyone,
>> I am a little confused by the two ways to indicate that a trait must form
>> part of a given concrete class: extension versus self-types, as shown in
>> the
>> subject. I have noticed that there are some differences in behaviour
>> between the two.
>>
>> Can anyone help explain the difference between them, and what situations
>> benefit from using one or the other?
>>
>> Thanks for you time,
>> Ken
>> --
>> View this message in context:
>> http://old.nabble.com/trait-X-extends-Y-vs-trait-X-%7Bthis%3A-Y%3D%3E-%7D-tp26233138p26233138.html
>> Sent from the Scala - User mailing list archive at Nabble.com.
>>
>
>

2.8.0 and explicit implicit import fails

2009-11-06T22:09:56Z

Using r19410 importing a single implicit def fails:

scala> import scala.collection.JavaConversions.asMap
import scala.collection.JavaConversions.asMap

scala> val sm : scala.collection.Map[Int,Int] = new java.util.HashMap[Int,Int]
<console>:5: error: type mismatch;
found : java.util.HashMap[Int,Int]
required: scala.collection.Map[Int,Int]
val sm : scala.collection.Map[Int,Int] = new java.util.HashMap[Int,Int]

but importing all the implicits works:

scala> import scala.collection.JavaConversions._
import scala.collection.JavaConversions._

scala> val sm : scala.collection.Map[Int,Int] = new java.util.HashMap[Int,Int]
sm: scala.collection.Map[Int,Int] = Map()

Is this a bug?

Could this be due to the fact that there are two asMap's defined in
scala.collection.JavaConversions?

Regards,
Blair

--
Blair Zajac, Ph.D.
CTO, OrcaWare Technologies
<blair@...>
Subversion training, consulting and support
http://www.orcaware.com/svn/

Re: trait X extends Y vs trait X {this: Y=> }

2009-11-06T16:47:32Z

The self type only enforces that you are *mixed-into* a particular type. A trait that extends another could possibly be used standalone.

I would reserve self-types for things that truly are just mixins, and a "class instantiation concern". This means the following:

trait X extends Y // X *is a* Y

trait X { self : Y => ... }    // X is a helper that can be used with a Y.   I would tend to prefer this over aspects for specific kinds of mixin functionality.

An example from EJB (yes... I know)

trait BaseDataAccessEJB {
   def tx : UserTransaction
   def entityManager : EntityManager
}

trait TransactionHelper { self : BaseDataAccessEJB =>

   //This is a toy implementation, in reality there are far more concerns to worry about in this method
   def transactional(f : => A) : A = {
          tx.start()
         try {
              f
          } finally {
              tx.commit()
          }
   }
}

Then when creating a new EJB I can do   class MyEJB extends BaseDataAccessEJB with TransactionHelper

I hope that helps,

- Josh

On Fri, Nov 6, 2009 at 7:35 PM, Ken Scambler <ken.scambler@...> wrote:

Hi everyone,
I am a little confused by the two ways to indicate that a trait must form
part of a given concrete class: extension versus self-types, as shown in the
subject. I have noticed that there are some differences in behaviour
between the two.

Can anyone help explain the difference between them, and what situations
benefit from using one or the other?

Thanks for you time,
Ken
--
View this message in context: http://old.nabble.com/trait-X-extends-Y-vs-trait-X-%7Bthis%3A-Y%3D%3E-%7D-tp26233138p26233138.html
Sent from the Scala - User mailing list archive at Nabble.com.

trait X extends Y vs trait X {this: Y=> }

2009-11-06T16:35:06Z

Hi everyone,
I am a little confused by the two ways to indicate that a trait must form part of a given concrete class: extension versus self-types, as shown in the subject. I have noticed that there are some differences in behaviour between the two.

Can anyone help explain the difference between them, and what situations benefit from using one or the other?

Thanks for you time,
Ken

[ANN] CfP: "Multiparadigm Programming" Special Issue of IEEE Software

2009-11-06T15:24:53Z

I'm one of the guest editors for a special issue of IEEE Software on "Multiparadigm Programming". This community knows something about that topic ;)

http://www.computer.org/portal/web/computingnow/swcfp5

Please consider submitting a paper. Feel free to email me directly with questions. We're also looking for reviewers.

Thanks,

Dean

--
Dean Wampler
coauthor of "Programming Scala" (O'Reilly)
- http://programmingscala.com

twitter: @deanwampler, @chicagoscala
Chicago-Area Scala Enthusiasts (CASE):
- http://groups.google.com/group/chicagoscala
- http://www.meetup.com/chicagoscala/ (Meetings)
http://www.linkedin.com/in/deanwampler
http://www.polyglotprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org

Re: Is there a Scala equivalent of package-info.java?

2009-11-06T14:13:54Z

> You need to use Scala 2.8 to gain access to package objects.

Yeah I know. I do use the latest 2.8 nightly I think. Package objects
seem to compile, and they don't seem to require a file named
`package.scala'. Only I don't know how to use annotations for package
objects. I believe it just doesn't work ...

---Ph.

Re: Is there a Scala equivalent of package-info.java?

2009-11-06T13:55:20Z

You need to use Scala 2.8 to gain access to package objects.

On Friday 06 November 2009 21:16:46 Philip Köster wrote:

> > Package objects must be in files named "package.scala"
>
> I don't get this to compile. Here is my `package.scala':
>
> package com.phrood
> @javax.annotation.Resource // Just a test
> package object scarab
>
> Compiler says:
>
> C:\Users\phkoester\Data\phrood\scarab\src\main\java\com\phrood\scarab\pack
> age.scala:3: error: expected start of definition
> package object scarab
> ^
>

Re: Is there a Scala equivalent of package-info.java?

2009-11-06T12:48:48Z

> I don't get this to compile. Here is my `package.scala':
>
> package com.phrood
> @javax.annotation.Resource // Just a test
> package object scarab

On a side note, the `Resource' annotation cannot be applied to packages,
but that's not the reason why compiling fails. I just checked it with a
custom annotation that is capable of annoting packages, and the result
is the same.

---Ph.