Fwd: [lift] Lift with Scala 2.6.1?

[David Pollak]

Can anyone in Scala-land lend some help as to the meaning of the error below and why it's a problem in 2.6.1 but not in 2.6.0?

Begin forwarded message:

From: Derek Chen-Becker <dchenbecker@...>

Date: December 27, 2007 1:25:28 PM PST

To: liftweb@...

Subject: [lift] Lift with Scala 2.6.1?

Reply-To: liftweb@...

I know David posted a message about moving trunk to 2.6.1-RC2, but has

that gone any further? Are there any plans to get it moved to

2.6.1-final? I tried mucking around in the main pom.xml to change the

scala version but when I compile it I'm getting some really weird type

mismatch errors (looks best in fixed width font):

[WARNING]

/home/dbecker/tools/liftweb/liftweb/lift/src/main/scala/net/liftweb/machine/ProtoStateMachine.scala:194:

error: type mismatch;

[WARNING]  found   : MetaProtoStateMachine.this.State

[WARNING]  required: _124.State where val _124:

MetaProtoStateMachine.this.Meta

[WARNING]       what.unmatchedEventHandler(who, s)

[WARNING]                                       ^

I feel like I'm trying to hotwire a Boeing here. I'm stuck in the

project I'm working on because 2.6.0 has a bug that won't allow my

Hibernate classes to work.

Thanks,

Derek

--~--~---------~--~----~------------~-------~--~----~

You received this message because you are subscribed to the Google Groups "liftweb" 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

-~----------~----~----~----~------~----~------~--~---

--

David Pollak

http://blog.lostlake.org

[Jon Pretty]

Hi David,

David Pollak wrote:
> Can anyone in Scala-land lend some help as to the meaning of the error
> below and why it's a problem in 2.6.1 but not in 2.6.0?
The compiler seems to have been tightened up wrt variable path dependent
types, though that error message is not the most helpful...

You could try ensuring that 'who' and 's' are values rather than variables.

Hope this helps,
Jon

--
Jon Pretty | Sygneca Ltd.

[Martin Odersky]

On Jan 2, 2008 9:20 AM, Jon Pretty <jon.pretty@...> wrote:
> Hi David,
>
> David Pollak wrote:
> > Can anyone in Scala-land lend some help as to the meaning of the error
> > below and why it's a problem in 2.6.1 but not in 2.6.0?
> The compiler seems to have been tightened up wrt variable path dependent
> types, though that error message is not the most helpful...
>
That's correct. This was a bug-fix for ticket 209. Here's an example
that describes the difference:

Say you have a class

  class C { type T; def m(x: T) }

and a call like

  cexpr.m(y)

where `cexpr' is an expression (not a value) of type C.
Before the change, cexpr.m had type C#T. It turns out
this leads to type safety problems. So, after the change,
cexpr.m has now type

  x.T forSome { val x: C }

In reality, instead of the `x', you get some compiler generated
numeric name. That's what you saw in the error diagnostic.

There are two ways to fix this error. The most common fix is to make
cexpr a value. Something like:

  val c = cexpr.
  c.m(...)

Another fix could be to widen the type of the method explicitly.
I.e. declare class C as follows:

  class C { type T; def m(x: C#T) }

As to the error message, I agree that it is kind of cryptic.
Suggestions how to improve iot are welcome!

Cheers

 -- Martin

[David Bernard-3]

> As to the error message, I agree that it is kind of cryptic.
> Suggestions how to improve iot are welcome!

A suggestion to improve "error message", like the old days, where error code was number provide :
* an error code number or text id
* a wiki with one page per error code (+ search)
   * description
   * examples
   * solutions like martin did
   * user comments

a little like findbugs, Oracle,... or the php api

Having this error code knowledge base + "a REST api" would allow ide/editor, builder,... to provide nicer reporter or GUI later.

my 2 cents.

>
> Cheers
>
>  -- Martin

/davidB

[Viktor Klang]

On 1/2/08, David Bernard <david.bernard.31@...> wrote:

> As to the error message, I agree that it is kind of cryptic.
> Suggestions how to improve iot are welcome!

A suggestion to improve "error message", like the old days, where error code was number provide :
* an error code number or text id
* a wiki with one page per error code (+ search)
  * description
  * examples
  * solutions like martin did
  * user comments

 

+Long.MAX_VALUE

a little like findbugs, Oracle,... or the php api

 

The Oracle database is according to my experiences with it, utter crap. But I guess the message came through. :)

 

Quote of the day: "Table of view does not exist"

 

Cheers,

-Viktor

 

 

Having this error code knowledge base + "a REST api" would allow ide/editor, builder,... to provide nicer reporter or GUI later.

my 2 cents.

>
> Cheers
>
>  -- Martin

/davidB

--
_____________________________________
/                                                                 \
        /lift/ committer (www.liftweb.net)
      SGS member (Scala Group Sweden)
  SEJUG member (Swedish Java User Group)
\_____________________________________/

[David Pollak]

On Jan 2, 2008, at 2:59 AM, martin odersky wrote:

> On Jan 2, 2008 9:20 AM, Jon Pretty <jon.pretty@...> wrote:
>> Hi David,
>>
>> David Pollak wrote:
>>> Can anyone in Scala-land lend some help as to the meaning of the  
>>> error
>>> below and why it's a problem in 2.6.1 but not in 2.6.0?
>> The compiler seems to have been tightened up wrt variable path  
>> dependent
>> types, though that error message is not the most helpful...
>>
> That's correct. This was a bug-fix for ticket 209. Here's an example
> that describes the difference:
>
> Say you have a class
>
>   class C { type T; def m(x: T) }
>
> and a call like
>
>   cexpr.m(y)
>
> where `cexpr' is an expression (not a value) of type C.
> Before the change, cexpr.m had type C#T. It turns out
> this leads to type safety problems. So, after the change,
> cexpr.m has now type
>
>   x.T forSome { val x: C }
>
> In reality, instead of the `x', you get some compiler generated
> numeric name. That's what you saw in the error diagnostic.
>
> There are two ways to fix this error. The most common fix is to make
> cexpr a value. Something like:
>
>   val c = cexpr.
>   c.m(...)
>
> Another fix could be to widen the type of the method explicitly.
> I.e. declare class C as follows:
>
>   class C { type T; def m(x: C#T) }
>
> As to the error message, I agree that it is kind of cryptic.
> Suggestions how to improve iot are welcome!

Martin,

This does the trick!  Thanks!

lift is now on 2.6.1... looking forward to the updated Eclipse plugin.

Thanks,

David

>
> Cheers
>
>  -- Martin

--
David Pollak
http://blog.lostlake.org

[Martin Odersky]

On Jan 2, 2008 12:21 PM, David Bernard <david.bernard.31@...> wrote:

> > As to the error message, I agree that it is kind of cryptic.
> > Suggestions how to improve iot are welcome!
>
> A suggestion to improve "error message", like the old days, where error code was number provide :
> * an error code number or text id
> * a wiki with one page per error code (+ search)
>    * description
>    * examples
>    * solutions like martin did
>    * user comments
>

Great idea. This would be very worthwhile in general. To get a good
database we most likely need community support. If we had a unique tag
for error messages, we could then do a wiki or something that
contained pages with the examples and explanations.

However, in the concrete example if this thread, this would not be
much help. The problem is that the error message is very generic. It's
``type error; found: <some type>; required <some other type>''. The
difficulty in explaining the diagnostics lies in the types -- what
they are, and how come that it was theses types that were computed.
Another worthwhile (research?) project would be to
have an interactive type debugger that explained how some particular
type was computed.

Cheers

 -- Martin

[Jon Pretty]

Hi Martin,

martin odersky wrote:
> Great idea. This would be very worthwhile in general. To get a good
> database we most likely need community support. If we had a unique tag
> for error messages, we could then do a wiki or something that
> contained pages with the examples and explanations.
The Scala Wiki could be an immediate place to start, but I suspect
something more specialized would be more appropriate.

I wonder whether error codes, or regex matching would be better?  I
think we could certainly subcategorize "type error; found: ...; required
..." messages where the two types relate to each other in some way with
regexes.  This would not require any change to the compiler, but would
be less maintainable if error messages were to change (even slightly).

I shall think some more about this, but I'd be happy to set a site up
alongside the Scala Wiki for this purpose.  Any further ideas are most
welcome.

Cheers,
Jon

--
Jon Pretty | Sygneca Ltd.

[Stanislas Klimoff-2]

Jon,

Why not to have both? I believe error code is a very viable addition that will allow to build an error database immediately. Regex matching or a full-text search is a feature that can be built on top of such database.

However, from my experience, most errors are likely to be very subtle and tightly coupled with the actual code. I think the errors that can be efficiently described can fit a single FAQ page. Maybe that's exactly the thing that should be done first? No changes are required neither in the compiler nor in the server-side software. 

Stan

On 1/3/08, Jon Pretty <jon.pretty@...> wrote:

Hi Martin,

martin odersky wrote:
> Great idea. This would be very worthwhile in general. To get a good
> database we most likely need community support. If we had a unique tag
> for error messages, we could then do a wiki or something that
> contained pages with the examples and explanations.
The Scala Wiki could be an immediate place to start, but I suspect
something more specialized would be more appropriate.

I wonder whether error codes, or regex matching would be better?  I
think we could certainly subcategorize "type error; found: ...; required
..." messages where the two types relate to each other in some way with
regexes.  This would not require any change to the compiler, but would
be less maintainable if error messages were to change (even slightly).

I shall think some more about this, but I'd be happy to set a site up
alongside the Scala Wiki for this purpose.  Any further ideas are most
welcome.

Cheers,
Jon

--
Jon Pretty | Sygneca Ltd.

--
Best wishes,
  Stan Klimoff
  Grid Dynamics Consulting

[Jon Pretty]

Stanislas Klimoff wrote:
> Why not to have both? I believe error code is a very viable addition
> that will allow to build an error database immediately. Regex matching
> or a full-text search is a feature that can be built on top of such
> database.
Possibly.   I'm thinking that for a given error message, several regexes
might match, and a collection of hopefully relevant responses would be
returned.
> However, from my experience, most errors are likely to be very subtle
> and tightly coupled with the actual code. I think the errors that can
> be efficiently described can fit a single FAQ page. Maybe that's
> exactly the thing that should be done first? No changes are required
> neither in the compiler nor in the server-side software.
You're right, and then the problem remains to find a way to document the
complicated errors.  Unfortunately, these are the errors most likely to
be causing difficulties...

Cheers,
Jon

--
Jon Pretty | Sygneca Ltd.

[Florian Hars-3]

Viktor Klang schrieb:
> +Long.MAX_VALUE

Assuming that the original proposal is an implicit 1 for itself,
your addition may not give the result you want:

scala> 1 + java.lang.Long.MAX_VALUE
res3: Long = -9223372036854775808

(We did not have our regular intergers should/should not overflow thread
this year, did we?)

Yours, Florian.

[Viktor Klang]

On 1/7/08, Florian Hars <hars@...> wrote:

Viktor Klang schrieb:
> +Long.MAX_VALUE

Assuming that the original proposal is an implicit 1 for itself,
your addition may not give the result you want:

scala> 1 + java.lang.Long.MAX_VALUE
res3: Long = -9223372036854775808

 

 

In fact I have an implicit which transforms my longs to BigIntegers ;)

 

;D

 

-V

(We did not have our regular intergers should/should not overflow thread
this year, did we?)

Yours, Florian.

--
_____________________________________
/                                                                 \
        /lift/ committer ( www.liftweb.net)
      SGS member (Scala Group Sweden)
  SEJUG member (Swedish Java User Group)
\_____________________________________/