Nabble - Scala Programming Language

Re: is the hashmap thread-safe

2009-11-26T14:34:37Z

On Thu, Nov 26, 2009 at 7:42 PM, Jorge Ortiz <jorge.ortiz@...> wrote:

Caesar,

If you're on 2.7.x, you can use TreeHashMap, which is a truly immutable lock-free data structure.

I love that datastructure name, it goes against all Java logic.

On 2.8, unfortunately, it hasn't been reintegrated with the rest of the collections library.

--j

On Thu, Nov 26, 2009 at 5:44 AM, Caesar You <Caesar.Jr@...> wrote:

immutable hashmap use synchronized method for concurrent environment.

so thread-2 must wait until thread-1 *get* something from the map.

but if a map is created and will not be modified, it is no need to synchronized.

what i dont know is, if the "get" action modified some internal state of a hashmap

and make it thread-not-safe.

From: hxliang1982@...

Sent: Thursday, November 26, 2009 9:29 PM

To: Caesar.Jr@...

Subject: Re: [scala-user] is the hashmap thread-safe

Why do you say this? Performance more depends on underlying data structure, I think. Maybe I am wrong for this case...

On Nov 26, 2009, at 9:09 PM, Caesar You wrote:

immutable map is slow, isnt it?

From: hxliang1982@...

Sent: Thursday, November 26, 2009 9:04 PM

To: Caesar.Jr@...

Subject: Re: [scala-user] is the hashmap thread-safe

If it is read only, why not using immutable map?

On Nov 26, 2009, at 8:41 PM, Caesar You wrote:

if i create a mutable.HashMap, and only use the "get(key)" action,

that means i will not modify the hashmap as using "+=", "-=".

in this situation, is it thread-safe?

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

From forum: Scala - User

Re: how does lift work with redis?

2009-11-26T14:21:27Z

So, if I want to use nosql database with LIFT, what I have to use is
JDBC driver, am I right?
Any experienced suggestion? Google has very little searching result on
it.
I'd appreciate any idea on this topic. Thanks.

Regards,

Surfman

On 11月25日, 下午4时06分, Timothy Perrett <timo...@...> wrote:

> Correct - Redis is a nosql database, mapper is only for RDBMS
>
> Cheers, Tim
>
> On 25 Nov 2009, at 20:13, surfman wrote:
>
>
>
> > Thanks. Does it mean I may not use lift mapper and I have to write
> > everything for database manipulation?
>
> > regards,
>
> > surfman
>
> > On 11月24日, 下午5时12分, Timothy Perrett <timo...@...> wrote:
> >> There is no out of the box implementation. You could write a record
> >> back end though - it depends on the features you want I guess.
>
> >> Cheers, Tim
>
> >> Sent from my iPhone
>
> >> On 24 Nov 2009, at 22:00, surfman <chinasmile...@...> wrote:
>
> >>> Is there anything I could learn on how lift works with redis database?
> >>> Thanks.
>
> >>> --
>
> >>> You received this message because you are subscribed to the Google
> >>> Groups "Lift" group.
> >>> To post to this group, send email to liftweb@....
> >>> To unsubscribe from this group, send email to liftweb+unsubscribe@...
> >>> .
> >>> For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en
> >>> .- 隐藏被引用文字 -
>
> >> - 显示引用的文字 -
>
> > --
>
> > You received this message because you are subscribed to the Google Groups "Lift" group.
> > To post to this group, send email to liftweb@....
> > To unsubscribe from this group, send email to liftweb+unsubscribe@....
> > For more options, visit this group athttp://groups.google.com/group/liftweb?hl=en.- 隐藏被引用文字 -
>
> - 显示引用的文字 -

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@....
To unsubscribe from this group, send email to liftweb+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

From forum: liftweb

Re: Trait-local data

2009-11-26T14:16:59Z

2009/11/26 Kevin Wright <kev.lee.wright@...>:

> Sounds like the classic case of not being able to mix in
> a parameterized trait multiple times with different type parameters.
> It's also one of my use-cases for the autoproxy plugin
> This is the example I used on wave:
> class Foo[T] {
>   def method0(t: T) = ...
> }
> class Bar {
>   @proxy val intfoo = new Foo[Int]
>   @proxy val strfoo = new Foo[String]
> }

I don't see what this buys you here. Why not simply:

class Bar {
val intfoo = new Foo[Int]
val strfoo = new Foo[String]
}

val bar = new Bar

and instead of:

bar.method0(5)
bar.method0("test")

we would have:

bar.intfoo.method0(5)
bar.strfoo.method0("test")

Not that bad. Also, this composes more cleanly, e.g. what would happen
if instead of Int and String you chose A and B with A <: B? That would
be some error-prone overloading. It would be even impossible if A == B
:) (I know I extend this beyond what you meant it for though).

Regards,
Dimitris

> expands to...
> class Bar {
>   val intfoo = new Foo[Int]
>   val strfoo = new Foo[String]
>   def method0(t: Int) = intfoo.method0(t)
>   def method0(t: String) = strfoo.method0(t)
> }
>
> Does that help your case any?
>
>
> On Thu, Nov 26, 2009 at 8:01 PM, Daniel Sobral <dcsobral@...> wrote:
>>
>> I'm trying to figure out how to do something, but I'm a bit stuck on a
>> particular approach that just isn't working, so I have come here for help on
>> alternative approaches.
>>
>> I'm building a program to solve a puzzle. I'm separating concerns
>> regarding the puzzle representation (the "board" so to speak), the puzzle
>> rules, and the strategies used to solve the problem. My present plan calls
>> for quite a bit of dependency injection, where the actual solver is a mix of
>> traits.
>>
>> My present problem concerns the game strategies. The initial strategies I
>> were writing were all based on one of two different data structures, though
>> more could be added later on. So I laid out these traits like this:
>>
>> trait StrategyA {
>> // A's data structure
>> def aStrategy(f: A => Unit) = strategies ::= f
>> private var strategies: List[A => Unit] = Nil
>> // plus stuff to call each strategy in turn, when the conditions apply
>> }
>>
>> trait StrategyB {
>> // B's data structure
>> def bStrategy(f: B => Unit) = strategies ::= f
>> private var strategies: List[B => Unit] = NIl
>> // plus stuff to call each strategy in turn, when conditions apply
>> }
>>
>> The idea being that each particular game strategy would be written like
>> this:
>>
>> trait X extends StrategyA {
>> aStrategy { a: A => ... }
>> }
>>
>> This stuff was made a bit more complicated by the fact that StrategyB
>> itself extends StrategyA, as B is derived from A, but that's beside the
>> point.
>>
>> Once I did that, I realized the code was pretty much the same, except for
>> A and B. So I decided to go for a parent trait for both, but that doesn't
>> seem to work. The types clash, I'd end up with a single "strategies" list,
>> etc. So, that's a no go. Any suggestions about how to get around that,
>> eliminate repetition, and use the type system to compose the solver by
>> mixing in traits, all at the same time?
>> --
>> Daniel C. Sobral
>>
>> Veni, vidi, veterni.
>
>

From forum: Scala - User

Re: Trait-local data

2009-11-26T14:09:34Z

You could factor the common parts through composition instead of
inheritance, at the cost of slightly more boilerplate (introducing an
extra field in each trait). It seems hard to avoid the issue while
sticking to inheritance - no trait can assume it "owns" the fields of
a supertype, since these are eventually shared by all mixed-in traits.

I also note that so-called stackable traits cannot be implemented if
the behavior of each stackable method depends on being able to write
to a supertype's field and expect to read back the same value the next
time. So this kind of pushes you to localize in a trait whatever state
is needed, without the use of inheritance - I don't know if it is
coincidental but it has a feel of righteousness to me.

Anyway, I'm just pointing the obvious solution, I can't think of
anything to work around this using inheritance only.

Dimitris

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

> I'm trying to figure out how to do something, but I'm a bit stuck on a
> particular approach that just isn't working, so I have come here for help on
> alternative approaches.
>
> I'm building a program to solve a puzzle. I'm separating concerns regarding
> the puzzle representation (the "board" so to speak), the puzzle rules, and
> the strategies used to solve the problem. My present plan calls for quite a
> bit of dependency injection, where the actual solver is a mix of traits.
>
> My present problem concerns the game strategies. The initial strategies I
> were writing were all based on one of two different data structures, though
> more could be added later on. So I laid out these traits like this:
>
> trait StrategyA {
> // A's data structure
> def aStrategy(f: A => Unit) = strategies ::= f
> private var strategies: List[A => Unit] = Nil
> // plus stuff to call each strategy in turn, when the conditions apply
> }
>
> trait StrategyB {
> // B's data structure
> def bStrategy(f: B => Unit) = strategies ::= f
> private var strategies: List[B => Unit] = NIl
> // plus stuff to call each strategy in turn, when conditions apply
> }
>
> The idea being that each particular game strategy would be written like
> this:
>
> trait X extends StrategyA {
> aStrategy { a: A => ... }
> }
>
> This stuff was made a bit more complicated by the fact that StrategyB itself
> extends StrategyA, as B is derived from A, but that's beside the point.
>
> Once I did that, I realized the code was pretty much the same, except for A
> and B. So I decided to go for a parent trait for both, but that doesn't seem
> to work. The types clash, I'd end up with a single "strategies" list, etc.
> So, that's a no go. Any suggestions about how to get around that, eliminate
> repetition, and use the type system to compose the solver by mixing in
> traits, all at the same time?
> --
> Daniel C. Sobral
>
> Veni, vidi, veterni.
>

From forum: Scala - User

Re: Improvements on this (perhaps with a DSL)?

2009-11-26T14:04:16Z

I assumed ticket would a a val declared somewhere earlier, I wasn't
quite sure how it was supposed to work. So, in your usual code you
would call say:

val ticket = ServiceRegistry().jobticket.createTicketForDocument(1234)
val media = ServiceRegistry().jobticket.setOutputMedia(ticket, "PDF")

yes? If these two functions are returning Options (or Boxes, etc),
then the for comprehension code will work if you added the yield part.
If they're not you can either wrap them in those tryo's you used in
the original post, or something like:

//not tested, working code for comparison: "test" |> { x => x.length/2
|> x.substring }
ServiceRegistry().jobticket |> ( driver =>
driver.createTicketForDocument(1234) |> driver.setOutputMedia(ticket,
"PDF")

which would only return the last value. If you need both out it'd be a
bit more complicated, say:

"test" |> { x => x.length/2 |> { y => (y, x.substring(y))} }

or you could use a for comprehension.

On 26-Nov-09, at 12:36 , Tim Perrett wrote:

> Thanks for the response Justin... yet more brain food! Let me give a
> little more information about the setup...
>
> ServiceLocator() //=> vends a ServiceRegistry
>
> //=> lazy val on the service registry instance for the "jobticket"
> soap endpoint
> ServiceLocator().jobticket
>
> //=> lazy val on the service registry instance for the "production"
> soap endpoint
> ServiceLocator().production
>
> Both of these properties have their own set of methods that can be
> called on that endpoint. So, in your example in your previous mail, im
> a little on confused where ticket came from? Wouldnt it actually be
> passing the driver instance, not the ticket?
>
> Perhaps it would be possible to do:
>
> ServiceRegistry().jobticket |> (driver => for(
> ticket <- driver.createTicketForDocument(1234);
> media <- driver.setOutputMedia(ticket, "PDF")
> )
> )
>
> I've no idea if that would even compile ;-)
>
> Cheers, Tim
>
> 2009/11/26 Justin Reardon <justin.reardon@...>:
>> Hi Tim,
>>
>> So what you're looking for is a way to chop off the
>> ServiceLocator().something bits you keep repeating?
>>
>> If this is just a few one off bits you could use the import trick
>> mentioned
>> earlier, eg:
>>
>> val aString = "test"
>> import aString._
>> length() // same as aString, untested
>>
>> If you want something general, the code Vicktor posted last
>> ( CallWS ), or a
>> more general version, assuming the Thrush code from my last
>> example, I think
>> this works:
>>
>> ServiceLocator().something |> { x =>
>> x.something.anotherThing(ticket, ...)
>> x.moreCallStuff(ticket, ...) }
>>
>>
>> On 2009-11-26, at 7:28, Tim Perrett <tperrett@...> wrote:
>>
>>> Thanks Viktor / Justin,
>>>
>>> I've been reconsidering my use case here, as these have been great
>>> responses and some interesting solutions.
>>>
>>> Most of the calls I make that feel very boiler plate are calling a
>>> stateful web service, e.g:
>>>
>>> val ticket = // make the call
>>>
>>> ServiceLocator().something.anotherThing(ticket, ...)
>>> ServiceLocator().something.moreCallStuff(ticket, ...)
>>>
>>> In light of that, what do you guys think?
>>>
>>> Cheers, Tim
>>
>>

From forum: Scala - User

Re: [scala] New scala blog

2009-11-26T13:36:14Z

I'm always a bit cynical about how much re-use *really* occurs with most in-house corporate development...

But I'm in total agreement about the benefits of refactoring.

Maintainability is important, but too many people still think of software as something that is simply written and then sold.

On Thu, Nov 26, 2009 at 7:03 PM, Colin Howe <colinthehowe@...> wrote:

Nice post :-)

Although, I'd argue that many good things initially lead to more lines but eventually lead to fewer as re-use etc is increased.

Also, testing makes refactoring easier, which makes it easier to prune away excess baggage

On Thu, Nov 26, 2009 at 6:55 PM, Kevin Wright <kev.lee.wright@...> wrote:

Okay, I've been threatening this for quite some time now...
Finally got round to it :)

http://www.artima.com/weblogs/index.jsp?blogger=kevwright

enjoy!

From forum: Scala

Re: Trait-local data

2009-11-26T13:15:48Z

Sounds like the classic case of not being able to mix in a parameterized trait multiple times with different type parameters.

It's also one of my use-cases for the autoproxy plugin

This is the example I used on wave:

class Foo[T] {

def method0(t: T) = ...

}

class Bar {

@proxy val intfoo = new Foo[Int]

@proxy val strfoo = new Foo[String]

}

expands to...

class Bar {

val intfoo = new Foo[Int]

val strfoo = new Foo[String]

def method0(t: Int) = intfoo.method0(t)

def method0(t: String) = strfoo.method0(t)

}

Does that help your case any?

On Thu, Nov 26, 2009 at 8:01 PM, Daniel Sobral <dcsobral@...> wrote:

I'm trying to figure out how to do something, but I'm a bit stuck on a particular approach that just isn't working, so I have come here for help on alternative approaches.

I'm building a program to solve a puzzle. I'm separating concerns regarding the puzzle representation (the "board" so to speak), the puzzle rules, and the strategies used to solve the problem. My present plan calls for quite a bit of dependency injection, where the actual solver is a mix of traits.

My present problem concerns the game strategies. The initial strategies I were writing were all based on one of two different data structures, though more could be added later on. So I laid out these traits like this:

trait StrategyA {

// A's data structure

def aStrategy(f: A => Unit) = strategies ::= f

private var strategies: List[A => Unit] = Nil

// plus stuff to call each strategy in turn, when the conditions apply

}

trait StrategyB {

// B's data structure

def bStrategy(f: B => Unit) = strategies ::= f

private var strategies: List[B => Unit] = NIl

// plus stuff to call each strategy in turn, when conditions apply

}

The idea being that each particular game strategy would be written like this:

trait X extends StrategyA {

aStrategy { a: A => ... }

}

This stuff was made a bit more complicated by the fact that StrategyB itself extends StrategyA, as B is derived from A, but that's beside the point.

Once I did that, I realized the code was pretty much the same, except for A and B. So I decided to go for a parent trait for both, but that doesn't seem to work. The types clash, I'd end up with a single "strategies" list, etc. So, that's a no go. Any suggestions about how to get around that, eliminate repetition, and use the type system to compose the solver by mixing in traits, all at the same time?

--
Daniel C. Sobral

Veni, vidi, veterni.

From forum: Scala - User

Re: derby

2009-11-26T12:54:35Z

Hi David,

Would you care to elaborate in what way Derby is inferior?
I understand H2 is probably faster as speed is one of its main
design goals. Does Derby have any other issues?

Are there any potential issues with using H2 for production?

Thanks,
Jack

> Derby is inferior in every way to H2 (another open source pure Java
> relational database). If you're building something for production,
> Postgresql is your best choice. If you need a simple database that needs no
> separate process and "just works" H2 is your best choice.

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@....
To unsubscribe from this group, send email to liftweb+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

From forum: liftweb

Impossible to use Mapper on GAE?

2009-11-26T12:51:05Z

Hi, I read from the list that Mapper is not supported on Google App Engine
(I see people use JPA instead.) I wonder if this is a matter of non-existent
drivers, or there are some fundamental issues that make it impossible?

Thanks,
Jack

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@....
To unsubscribe from this group, send email to liftweb+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

From forum: liftweb

Re: Re: simple database question

2009-11-26T12:02:25Z

excellent. Thanks. Just what I needed.

On Thu, Nov 26, 2009 at 2:34 PM, harryh <harryh@...> wrote:

Here is what you need for a minimal Person table that contains two
columns: an id for the primary key, and name which is a string:

package com.jacksdomain.model

import net.liftweb.mapper._

class Person extends LongKeyedMapper[Person] with IdPK {
def getSingleton = Person

object name extends MappedString(this, 100)
}

object Person extends Person with LongKeyedMetaMapper[Person] {
override def dbTableName = "person"
}

You can then do things like this:

val person = Person.find(1) // retrieve the person with id = 1 from
the database
val person = Person.find(By(Person.name, "Jack")) // retrieve the
person with name = "Jack" from the database
val people = Person.findAll() // retrieve all people form the database
val people = Person.findAll(By_<(Person.id, 10)) // retrieve all the
people with id < 10

etc.

-harryh

On Nov 26, 1:39 pm, jack <jack.wid...@...> wrote:
> wow. thats impressive. But for this, what does the Person class have
> to look like? Suppose I have the table but I don't have the Person
> class written. What does it need to look like?
>
> On Nov 26, 1:32 pm, harryh <har...@...> wrote:
>
> > val people = Person.findAll()
>
> > On Nov 26, 1:22 pm, jack <jack.wid...@...> wrote:
>
> > > I have my database configured properly in Boot.scala and in my
> > > pom.xml. Suppose I have a table name person with a field called name.
> > > What is the simple code to return all rows of this table using Mapper.
> > > I want to understand the essence of how lift ties tables to objects
> > > with a simple example.

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@....
To unsubscribe from this group, send email to liftweb%2Bunsubscribe@....
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

--
Jack Widman

co-founder / cto, Authoritude, Inc.

203-641-9355

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@....
To unsubscribe from this group, send email to liftweb+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

From forum: liftweb

Trait-local data

2009-11-26T12:01:23Z

I'm trying to figure out how to do something, but I'm a bit stuck on a particular approach that just isn't working, so I have come here for help on alternative approaches.

I'm building a program to solve a puzzle. I'm separating concerns regarding the puzzle representation (the "board" so to speak), the puzzle rules, and the strategies used to solve the problem. My present plan calls for quite a bit of dependency injection, where the actual solver is a mix of traits.

My present problem concerns the game strategies. The initial strategies I were writing were all based on one of two different data structures, though more could be added later on. So I laid out these traits like this:

trait StrategyA {

// A's data structure

def aStrategy(f: A => Unit) = strategies ::= f

private var strategies: List[A => Unit] = Nil

// plus stuff to call each strategy in turn, when the conditions apply

}

trait StrategyB {

// B's data structure

def bStrategy(f: B => Unit) = strategies ::= f

private var strategies: List[B => Unit] = NIl

// plus stuff to call each strategy in turn, when conditions apply

}

The idea being that each particular game strategy would be written like this:

trait X extends StrategyA {

aStrategy { a: A => ... }

}

This stuff was made a bit more complicated by the fact that StrategyB itself extends StrategyA, as B is derived from A, but that's beside the point.

Once I did that, I realized the code was pretty much the same, except for A and B. So I decided to go for a parent trait for both, but that doesn't seem to work. The types clash, I'd end up with a single "strategies" list, etc. So, that's a no go. Any suggestions about how to get around that, eliminate repetition, and use the type system to compose the solver by mixing in traits, all at the same time?

--
Daniel C. Sobral

Veni, vidi, veterni.

From forum: Scala - User

Re: simple database question

2009-11-26T11:34:00Z

Here is what you need for a minimal Person table that contains two
columns: an id for the primary key, and name which is a string:

package com.jacksdomain.model

import net.liftweb.mapper._

class Person extends LongKeyedMapper[Person] with IdPK {
def getSingleton = Person

object name extends MappedString(this, 100)
}

object Person extends Person with LongKeyedMetaMapper[Person] {
override def dbTableName = "person"
}

You can then do things like this:

val person = Person.find(1) // retrieve the person with id = 1 from
the database
val person = Person.find(By(Person.name, "Jack")) // retrieve the
person with name = "Jack" from the database
val people = Person.findAll() // retrieve all people form the database
val people = Person.findAll(By_<(Person.id, 10)) // retrieve all the
people with id < 10

etc.

-harryh

On Nov 26, 1:39 pm, jack <jack.wid...@...> wrote:

> wow. thats impressive. But for this, what does the Person class have
> to look like? Suppose I have the table but I don't have the Person
> class written. What does it need to look like?
>
> On Nov 26, 1:32 pm, harryh <har...@...> wrote:
>
> > val people = Person.findAll()
>
> > On Nov 26, 1:22 pm, jack <jack.wid...@...> wrote:
>
> > > I have my database configured properly in Boot.scala and in my
> > > pom.xml. Suppose I have a table name person with a field called name.
> > > What is the simple code to return all rows of this table using Mapper.
> > > I want to understand the essence of how lift ties tables to objects
> > > with a simple example.

From forum: liftweb

Re: [scala] jvm5 build should be default?

2009-11-26T11:14:20Z

On Nov 25, 2009, at 9:11 PM, Jorge Ortiz wrote:

> LinkedIn has 100+ engineers stuck on Java 1.5 because of a blocker bug in Apple's 1.6 JDK. It certainly doesn't "work just fine".

Out of curiosity, which bug is this?

Blair

From forum: Scala

Re: simple database question

2009-11-26T11:10:20Z

Take a look at the User class example:
http://github.com/dpp/liftweb/blob/master/lift-examples/hellolift/src/main/scala/com/hellolift/model/User.scala

On Nov 26, 1:39 pm, jack <jack.wid...@...> wrote:

> wow. thats impressive. But for this, what does the Person class have
> to look like? Suppose I have the table but I don't have the Person
> class written. What does it need to look like?
>
> On Nov 26, 1:32 pm, harryh <har...@...> wrote:
>
>
>
> > val people = Person.findAll()
>
> > On Nov 26, 1:22 pm, jack <jack.wid...@...> wrote:
>
> > > I have my database configured properly in Boot.scala and in my
> > > pom.xml. Suppose I have a table name person with a field called name.
> > > What is the simple code to return all rows of this table using Mapper.
> > > I want to understand the essence of how lift ties tables to objects
> > > with a simple example.

From forum: liftweb

Re: [scala] New scala blog

2009-11-26T11:03:22Z

Nice post :-)

Although, I'd argue that many good things initially lead to more lines but eventually lead to fewer as re-use etc is increased.

Also, testing makes refactoring easier, which makes it easier to prune away excess baggage

On Thu, Nov 26, 2009 at 6:55 PM, Kevin Wright <kev.lee.wright@...> wrote:

Okay, I've been threatening this for quite some time now...
Finally got round to it :)

http://www.artima.com/weblogs/index.jsp?blogger=kevwright

enjoy!

From forum: Scala

[scala] New scala blog

2009-11-26T10:55:35Z

Okay, I've been threatening this for quite some time now...

Finally got round to it :)

http://www.artima.com/weblogs/index.jsp?blogger=kevwright

enjoy!

From forum: Scala

Re: Package objects, implicits, and imports

2009-11-26T10:52:51Z

On 2009-11-26, Jorge Ortiz <jorge.ortiz@...> wrote:
> Please file a bug on Trac.

Ok; #2709 is created.
--
Robert Macomber
xbymeu@...

From forum: Scala - User

Re: protected modifier bug?

2009-11-26T10:42:52Z

Thanks for pointing me to 'Programming in Scala' and for noting that
g(m: N) = m.f does compile.

Indeed, the chapter on access modifiers is an interesting read.

... it's hard to get Java out of my system but I'm getting there....

-Robbert

On Nov 26, 2009, at 7:30 PM, Daniel Sobral wrote:

> Scala's protected and private differs a lot from Java, but they are
> much more flexible a lot. I recommend reading up on it.
>
> According to Programming in Scala, the Java-equivalent statements are;
>
> private[parent class] = same as private in Java
> private[declaring class] = same as private in Scala
>
> You can also make the private's scope any enclosing class, object or
> package. And, then, there is private[this], which makes a field only
> accessible to the object itself (ie, two objects of the same type
> can't access each other's private[this] fields).
>
> For protected, declaring the scope to be the package makes it the
> same as Java.
>
> The funny thing about your example is that you can't access "f" on
> an "M", but you can access it on an "N". If you declare "m" to be of
> type "N", it works. This is as specified, as you can see in the last
> line below:
>
> A protected identifier
>
> x may be used as a member name in a selection r .x
> only if one of the following applies:
>
> –
>
> The access is within the template defining the member, or, if a
> qualification
> C
>
> is given, inside the package C, or the class C, or its companion
> module, or
>
> 58 Classes and Objects
>
> –
>
> r is one of the reserved words this and super, or
> –
>
> r ’s type conforms to a type-instance of the class which contains
> the access.
> On Thu, Nov 26, 2009 at 4:06 PM, Robbert Dalen <robbert.van.dalen@...
> > wrote:
> So a protected modifier only allows access to subclasses?
> But N is a proper subclass of M, so why shouldn't N be able to
> access f? (albeit via an instance of M)
> (O can access f)
>
> abstract class M {
> protect def: Int
>
> }
> abstract class N extends M {
> def(g: M) = m.f
> }
> abstract class O extends M {
> def g = f
>
> }
>
> It looks as though you're subclassing here simply as a way to allow
> protected method access.
> 'extends' is the tightest possible coupling that you can have
> between two classes, is that really what you want?
> Unless it's *really* true that N is-an M, this could seriously
> confuse anyone who maintains the code after you.
>
> Like you, I don't like subclassing, I'm just demonstrating strange
> behavior.
>
>
>
> A better solution would be to put both classes in a common package:
>
> I agree this is more idiomatic Scala.
> But then again: Java's protected also allows classes within the same
> package to have access.
>
> -Robbert
>
>
>
>
> --
> Daniel C. Sobral
>
> Veni, vidi, veterni.

From forum: Scala - User

Re: is the hashmap thread-safe

2009-11-26T10:42:43Z

Caesar,

If you're on 2.7.x, you can use TreeHashMap, which is a truly immutable lock-free data structure.

On 2.8, unfortunately, it hasn't been reintegrated with the rest of the collections library.

--j

On Thu, Nov 26, 2009 at 5:44 AM, Caesar You <Caesar.Jr@...> wrote:

immutable hashmap use synchronized method for concurrent environment.

so thread-2 must wait until thread-1 *get* something from the map.

but if a map is created and will not be modified, it is no need to synchronized.

what i dont know is, if the "get" action modified some internal state of a hashmap

and make it thread-not-safe.

From: hxliang1982@...

Sent: Thursday, November 26, 2009 9:29 PM

To: Caesar.Jr@...

Subject: Re: [scala-user] is the hashmap thread-safe

Why do you say this? Performance more depends on underlying data structure, I think. Maybe I am wrong for this case...

On Nov 26, 2009, at 9:09 PM, Caesar You wrote:

immutable map is slow, isnt it?

From: hxliang1982@...

Sent: Thursday, November 26, 2009 9:04 PM

To: Caesar.Jr@...

Subject: Re: [scala-user] is the hashmap thread-safe

If it is read only, why not using immutable map?

On Nov 26, 2009, at 8:41 PM, Caesar You wrote:

if i create a mutable.HashMap, and only use the "get(key)" action,

that means i will not modify the hashmap as using "+=", "-=".

in this situation, is it thread-safe?

From forum: Scala - User

Re: simple database question

2009-11-26T10:39:44Z

wow. thats impressive. But for this, what does the Person class have
to look like? Suppose I have the table but I don't have the Person
class written. What does it need to look like?

On Nov 26, 1:32 pm, harryh <har...@...> wrote:
> val people = Person.findAll()
>
> On Nov 26, 1:22 pm, jack <jack.wid...@...> wrote:
>
> > I have my database configured properly in Boot.scala and in my
> > pom.xml. Suppose I have a table name person with a field called name.
> > What is the simple code to return all rows of this table using Mapper.
> > I want to understand the essence of how lift ties tables to objects
> > with a simple example.

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@....
To unsubscribe from this group, send email to liftweb+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

From forum: liftweb

Re: Package objects, implicits, and imports

2009-11-26T10:39:14Z

Please file a bug on Trac.

--j

On Thu, Nov 26, 2009 at 8:58 AM, Robert Macomber <xbymeu@...> wrote:

I've been working a little with the package objects in 2.8, and I've
found a little oddity. Say you've got a package with a package
object:

package com.rojoma

package object pkg {
implicit def enrich(a: A) = new RichA(a)
}

If you're *outside* the package, all works as expected:

import com.rojoma.pkg._
(new A).someRichAMethod() // finds the implicit, great

But if you're *inside* it, you still have to explicitly import the
package's contents for the implicits to be found:

package com.rojoma.pkg

class Cls {
// doesn't find the implicit unless com.rojoma.pkg._ is imported
(new A).someRichAMethod()
}

The enrich method is in scope; calling it explicitly works. It's just
not found by the implicit-resolution machinery. Is this by design or
an oversight?

For completeness, the same thing happens if the code that wants to use
the implicit is in a package nested inside "com.rojoma.pkg".
--
Robert Macomber
xbymeu@...

From forum: Scala - User

Re: Actors don't work with Java 1.5

2009-11-26T10:32:20Z

The question is the Scala distribution being used. A 1.6 Scala distribution won't work with Java 1.5, particularly concerning Actors.

On Thu, Nov 26, 2009 at 4:14 PM, Miles Sabin <miles@...> wrote:

On Thu, Nov 26, 2009 at 6:08 PM, Sciss <contact@...> wrote:
> i have always been using
> http://www.scala-lang.org/scala-eclipse-plugin-nightly ... is there a
> separate eclipse plug-in site for java 1.5?

At the moment, no ... there probably should be.

What JDK are you using to build your application? Even if the IDE code
was built with 1.6 you should be able to select 1.5 for building your
own projects.

Cheers,

Miles

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

--
Daniel C. Sobral

Veni, vidi, veterni.

From forum: Scala - User

Re: simple database question

2009-11-26T10:32:09Z

val people = Person.findAll()

On Nov 26, 1:22 pm, jack <jack.wid...@...> wrote:
> I have my database configured properly in Boot.scala and in my
> pom.xml. Suppose I have a table name person with a field called name.
> What is the simple code to return all rows of this table using Mapper.
> I want to understand the essence of how lift ties tables to objects
> with a simple example.

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@....
To unsubscribe from this group, send email to liftweb+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

From forum: liftweb

Re: protected modifier bug?

2009-11-26T10:31:57Z

>> Perhaps, protected grants access to a member when you're accessing
>> that member through a subclass mechanism, i.e. super.f
>

That sounds plausible, yes.

> N is accessing f as any other external entity would.

I now believe that the Java version compiles *because* the classes N
and M are in the same package, not because N is a subclass of M.

>
> I think.

I think you are right.

Thanks,

-Robbert.

From forum: Scala - User

Re: protected modifier bug?

2009-11-26T10:30:23Z

Scala's protected and private differs a lot from Java, but they are much more flexible a lot. I recommend reading up on it.

According to Programming in Scala, the Java-equivalent statements are;

private[parent class] = same as private in Java

private[declaring class] = same as private in Scala

You can also make the private's scope any enclosing class, object or package. And, then, there is private[this], which makes a field only accessible to the object itself (ie, two objects of the same type can't access each other's private[this] fields).

For protected, declaring the scope to be the package makes it the same as Java.

The funny thing about your example is that you can't access "f" on an "M", but you can access it on an "N". If you declare "m" to be of type "N", it works. This is as specified, as you can see in the last line below:

A protected identifier

x may be used as a member name in a selection r .x

only if one of the following applies:

–
The access is within the template defining the member, or, if a qualification
C
is given, inside the package C, or the class C, or its companion

module, or

58 Classes and Objects

–
r is one of the reserved words this and super, or
–
r ’s type conforms to a type-instance of the class which contains the access.

On Thu, Nov 26, 2009 at 4:06 PM, Robbert Dalen <robbert.van.dalen@...> wrote:

So a protected modifier only allows access to subclasses?
But N is a proper subclass of M, so why shouldn't N be able to access f? (albeit via an instance of M)
(O can access f)

abstract class M {
protect def: Int

}
abstract class N extends M {
def(g: M) = m.f
}
abstract class O extends M {
def g = f

}

It looks as though you're subclassing here simply as a way to allow protected method access.
'extends' is the tightest possible coupling that you can have between two classes, is that really what you want?
Unless it's *really* true that N is-an M, this could seriously confuse anyone who maintains the code after you.

Like you, I don't like subclassing, I'm just demonstrating strange behavior.

A better solution would be to put both classes in a common package:

I agree this is more idiomatic Scala.
But then again: Java's protected also allows classes within the same package to have access.

-Robbert

--
Daniel C. Sobral

Veni, vidi, veterni.

From forum: Scala - User

simple database question

2009-11-26T10:22:39Z

I have my database configured properly in Boot.scala and in my
pom.xml. Suppose I have a table name person with a field called name.
What is the simple code to return all rows of this table using Mapper.
I want to understand the essence of how lift ties tables to objects
with a simple example.

--

You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@....
To unsubscribe from this group, send email to liftweb+unsubscribe@....
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.

From forum: liftweb

Re: Actors don't work with Java 1.5

2009-11-26T10:17:18Z

i'm using JVM 1.5.0, since i'm on OS X 10.4 with a 32-bit intel...
some day i will upgrade to snow leopard, but as for now, i'm stuck
with java 1.5

does that mean that the eclipse plug-in doesn't actually support java
1.5 any more? at least it seems to be working ok here...

cheers, -sciss-

Am 26.11.2009 um 18:14 schrieb Miles Sabin:

> On Thu, Nov 26, 2009 at 6:08 PM, Sciss <contact@...> wrote:
>> i have always been using
>> http://www.scala-lang.org/scala-eclipse-plugin-nightly ... is there a
>> separate eclipse plug-in site for java 1.5?
>
> At the moment, no ... there probably should be.
>
> What JDK are you using to build your application? Even if the IDE code
> was built with 1.6 you should be able to select 1.5 for building your
> own projects.
>
> Cheers,
>
>
> Miles
>
> --
> Miles Sabin
> tel: +44 (0)7813 944 528
> skype: milessabin
> http://www.chuusai.com/
> http://twitter.com/milessabin

From forum: Scala - User

Re: Actors don't work with Java 1.5

2009-11-26T10:14:29Z

On Thu, Nov 26, 2009 at 6:08 PM, Sciss <contact@...> wrote:
> i have always been using
> http://www.scala-lang.org/scala-eclipse-plugin-nightly ... is there a
> separate eclipse plug-in site for java 1.5?

At the moment, no ... there probably should be.

What JDK are you using to build your application? Even if the IDE code
was built with 1.6 you should be able to select 1.5 for building your
own projects.

Cheers,

Miles

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

From forum: Scala - User

Re: protected modifier bug?

2009-11-26T10:13:32Z

Robbert Dalen wrote:

> So a protected modifier only allows access to subclasses?
> But N is a proper subclass of M, so why shouldn't N be able to access
> f? (albeit via an instance of M)
> (O can access f)
>
> abstract class M {
> protect def: Int
> }
> abstract class N extends M {
> def(g: M) = m.f
> }
> abstract class O extends M {
> def g = f
> }

Perhaps, protected grants access to a member when you're accessing that
member through a subclass mechanism, i.e. super.f

N is accessing f as any other external entity would.

I think.

From forum: Scala - User

Re: [scala-tools] Scala plugin for Netbeans 6.8beta - BoxedBooleanArray class not found

2009-11-26T10:11:18Z

Looking forward to it - especially the 'real-time interactive compilation' feature - which, I gather from another thread, works now for the new version of the plugin.

Regards,
- Lalit

:::
Lalit Pant
http://www.kogics.net

dcaoyuan wrote:

That's great.

A new version of Scala plugin for NetBeans 6.8RC1 will be available
all at once in couple of days.

From forum: Scala - Tools

Re: Actors don't work with Java 1.5

2009-11-26T10:08:06Z

i have always been using http://www.scala-lang.org/scala-eclipse-
plugin-nightly ... is there a separate eclipse plug-in site for java
1.5?

thanks, -sciss-

Am 26.11.2009 um 17:57 schrieb Daniel Sobral:

> There are two distributions, 1.5 and 1.6. Are you sure you got the
> 1.5 distribution?
>
> On Thu, Nov 26, 2009 at 3:49 PM, Sciss <contact@...> wrote:
> hi,
>
> using a recent nightly from scala, my previously working code
> breaks with
>
> java.lang.NoSuchMethodError:
> java.util.concurrent.locks.LockSupport.park(Ljava/lang/Object;)V
> and
> java.lang.NoClassDefFoundError: java/util/concurrent/RunnableFuture
>
> when calling the actor method... seems some java 1.6 stuff sneaked
> in here?
>
> ciao, -sciss-
>
>
>
>
> --
> Daniel C. Sobral
>
> Veni, vidi, veterni.

From forum: Scala - User

Re: protected modifier bug?

2009-11-26T10:06:51Z

So a protected modifier only allows access to subclasses?
But N is a proper subclass of M, so why shouldn't N be able to access
f? (albeit via an instance of M)
(O can access f)

abstract class M {
protect def: Int
}
abstract class N extends M {
def(g: M) = m.f
}
abstract class O extends M {
def g = f
}

> It looks as though you're subclassing here simply as a way to allow
> protected method access.
> 'extends' is the tightest possible coupling that you can have
> between two classes, is that really what you want?
> Unless it's *really* true that N is-an M, this could seriously
> confuse anyone who maintains the code after you.

Like you, I don't like subclassing, I'm just demonstrating strange
behavior.

>
> A better solution would be to put both classes in a common package:

I agree this is more idiomatic Scala.
But then again: Java's protected also allows classes within the same
package to have access.

-Robbert

From forum: Scala - User

Re: [scala] jvm5 build should be default?

2009-11-26T10:02:42Z

On Thu, 2009-11-26 at 14:55 +0100, Antonio Cunei wrote:
> Therefore our planned naming scheme is just:
>
> * scala-2.7.x requires jvm 1.5
> * scala-2.7.x-jvm4 runs on jvm 1.4
>
> * scala-2.8.x requires jvm 1.6
> * scala-2.8.x-jvm5 runs on jvm 1.5

I am wondering if it won't be better to have the jvm suffix for both
builds given recent emails I've seen where people use the default build,
expect it to work with Java 5 and then email the list asking what's up.

I would hope that including the expected jvm in the name may improve the
situation. Is there a downside to this?

Best,
Ismael

From forum: Scala

Re: Actors don't work with Java 1.5

2009-11-26T09:57:59Z

There are two distributions, 1.5 and 1.6. Are you sure you got the 1.5 distribution?

On Thu, Nov 26, 2009 at 3:49 PM, Sciss <contact@...> wrote:

hi,

using a recent nightly from scala, my previously working code breaks with

java.lang.NoSuchMethodError: java.util.concurrent.locks.LockSupport.park(Ljava/lang/Object;)V
and
java.lang.NoClassDefFoundError: java/util/concurrent/RunnableFuture

when calling the actor method... seems some java 1.6 stuff sneaked in here?

ciao, -sciss-

--
Daniel C. Sobral

Veni, vidi, veterni.

From forum: Scala - User

Actors don't work with Java 1.5

2009-11-26T09:49:19Z

hi,

using a recent nightly from scala, my previously working code breaks
with

java.lang.NoSuchMethodError:
java.util.concurrent.locks.LockSupport.park(Ljava/lang/Object;)V
and
java.lang.NoClassDefFoundError: java/util/concurrent/RunnableFuture

when calling the actor method... seems some java 1.6 stuff sneaked in
here?

ciao, -sciss-

From forum: Scala - User