New arrays are here

On Mon, Sep 21, 2009 at 03:01:51PM +0200, martin odersky wrote:
> Second, for some to me completely mysterious reason, run/runtime.scala
> fails. I have no idea what this has to do with the changes I did.

I undisabled locally after building r18722, and it passed with no
changes. (java 6, snow leopard.) Can you reproduce the failure?

> New arrays have landed in trunk.

Cool.

> First, structural types need to be adapted. structural.scala is
> disabled for the moment. Gilles, can you take care of this?

Yes. I've already been working on that for a few days.

Cheers,
Gilles.

On Mon, Sep 21, 2009 at 3:45 PM, Paul Phillips wrote:
> On Mon, Sep 21, 2009 at 03:01:51PM +0200, martin odersky wrote:
>> Second, for some to me completely mysterious reason, run/runtime.scala
>> fails. I have no idea what this has to do with the changes I did.
>
> I undisabled locally after building r18722, and it passed with no
> changes.  (java 6, snow leopard.) Can you reproduce the failure?
>
I'll try again. It could be a problem of classpath leakage into partest.

Cheers

On Mon, Sep 21, 2009 at 4:03 PM, Gilles Dubochet
wrote:
>> New arrays have landed in trunk.
>
> Cool.
>
>> First, structural types need to be adapted. structural.scala is
>> disabled for the moment. Gilles, can you take care of this?
>
> Yes. I've already been working on that for a few days.
>
Cool. So now you have something to test against :-)

On Mon, Sep 21, 2009 at 04:15:24PM +0200, martin odersky wrote:
> I'll try again. It could be a problem of classpath leakage into
> partest.

If that's something we know can happen it should be fixed - I took a
look and wasn't able to induce it. There was a trac ticket to similar
effect open for a long time, but it was not specific about where such
leakage might be taking place, and I closed it as fixed.

http://lampsvn.epfl.ch/trac/scala/ticket/1282

If anyone knows of a specific circumstance in which any environmental
classpath info is tainting either the build or partest run, please send
it my way. That's the kind of thing that needs to be mercilessly
stomped, because (among other reasons) it threatens every release build.

Would someone also take a look at:
http://lampsvn.epfl.ch/trac/scala/ticket/2334

On Mon, Sep 21, 2009 at 10:32 PM, Paul Phillips wrote:
> On Mon, Sep 21, 2009 at 04:15:24PM +0200, martin odersky wrote:
>> I'll try again. It could be a problem of classpath leakage into
>> partest.
>
> If that's something we know can happen it should be fixed - I took a
> look and wasn't able to induce it.  There was a trac ticket to similar
> effect open for a long time, but it was not specific about where such
> leakage might be taking place, and I closed it as fixed.
>
>  http://lampsvn.epfl.ch/trac/scala/ticket/1282
>
> If anyone knows of a specific circumstance in which any environmental
> classpath info is tainting either the build or partest run, please send
> it my way.  That's the kind of thing that needs to be mercilessly
> stomped, because (among other reasons) it threatens every release build.
>
> --
> Paul Phillips      | We must respect the other fellow's religion, but only
> Everyman           | in the sense and to the extent that we respect his
> Empiricist         | theory that his wife is beautiful and his children smart.
> pull his pi pal!   |     -- H. L. Mencken
>

On Mon, Sep 21, 2009 at 10:54:49PM +0800, Caoyuan wrote:
> Would someone also take a look at:
> http://lampsvn.epfl.ch/trac/scala/ticket/2334

There's no longer any reference to Companion in the Array bytecode. (I
don't know if that implies this is fixed or not, or if it is, whether it
still needs attention to prevent a recurrence.)

On Mon, Sep 21, 2009 at 11:35 PM, Paul Phillips wrote:
> On Mon, Sep 21, 2009 at 10:54:49PM +0800, Caoyuan wrote:
>> Would someone also take a look at:
>> http://lampsvn.epfl.ch/trac/scala/ticket/2334
>
> There's no longer any reference to Companion in the Array bytecode.  (I
> don't know if that implies this is fixed or not, or if it is, whether it
> still needs attention to prevent a recurrence.)

Yes, as these code removed, this issue should have been fixed now.

>
> --
> Paul Phillips      | Eschew mastication.
> Protagonist        |
> Empiricist         |
> pal, i pill push   |----------* http://www.improving.org/paulp/ *----------
>

On Mon, Sep 21, 2009 at 15:01, martin odersky <martin.odersky@epfl.ch> wrote:

New arrays have landed in trunk. This was the hardest on longest bug
fix I ever did! There are still some things to clean up, but I checked
in anyway because I am seriously running out of time.

First, structural types need to be adapted. structural.scala is
disabled for the moment. Gilles, can you take care of this?

Second, for some to me completely mysterious reason, run/runtime.scala fails. I
have no idea what this has to do with the changes I did. If somebody
can help investigate, that would be most appreciated. (Hudson seems to
be down right now, so I can't check whether the runtime failure was in
fact caused my my checkin or whether it existed before).

hudson is up again, fabien re-started tomcat. the build fails with

[scalacfork] /localhome/hudson/workspace/scala-checkin/scala/src/library/scala/reflect/ClassManifest.scala:92: error: overloaded method value newInstance with alternatives (x$1: java.lang.Class[_],x$2: Array[Int])java.lang.Object <and> (x$1: java.lang.Class[_],x$2: Int)java.lang.Object cannot be applied to (Class[_$1],Int,Int)
[scalacfork]       java.lang.reflect.Array.newInstance(erasure, 0, 0).getClass, len)
[scalacfork]                               ^

 

Cheers

I should have reported that. The time Martin made the announcement, I updated my svn working copy and fired ant, only to get the error below. But since sometimes I mess with the build, I thought something was wrong on my part.

On Sep 22, 2009, at 11:01, Lukas Rytz wrote:

On Mon, Sep 21, 2009 at 15:01, martin odersky <martin.odersky@epfl.ch> wrote:

New arrays have landed in trunk. This was the hardest on longest bug
fix I ever did! There are still some things to clean up, but I checked
in anyway because I am seriously running out of time.

First, structural types need to be adapted. structural.scala is
disabled for the moment. Gilles, can you take care of this?

Second, for some to me completely mysterious reason, run/runtime.scala fails. I
have no idea what this has to do with the changes I did. If somebody
can help investigate, that would be most appreciated. (Hudson seems to
be down right now, so I can't check whether the runtime failure was in
fact caused my my checkin or whether it existed before).

hudson is up again, fabien re-started tomcat. the build fails with

[scalacfork] /localhome/hudson/workspace/scala-checkin/scala/src/library/scala/reflect/ClassManifest.scala:92: error: overloaded method value newInstance with alternatives (x$1: java.lang.Class[_],x$2: Array[Int])java.lang.Object <and> (x$1: java.lang.Class[_],x$2: Int)java.lang.Object cannot be applied to (Class[_$1],Int,Int)
[scalacfork]       java.lang.reflect.Array.newInstance(erasure, 0, 0).getClass, len)
[scalacfork]                               ^

 

Cheers

 -- Martin

-- 
   __~O
  -\ <,       Christos KK Loverdos
(*)/ (*)      http://ckkloverdos.com

On Tue, Sep 22, 2009 at 11:31 AM, Christos KK Loverdos
wrote:
> I should have reported that. The time Martin made the announcement, I
> updated my svn working copy and fired ant, only to get the error below. But
> since sometimes I mess with the build, I thought something was wrong on my
> part.
>
> On Sep 22, 2009, at 11:01, Lukas Rytz wrote:
>
>
> On Mon, Sep 21, 2009 at 15:01, martin odersky
> wrote:
>>
>> New arrays have landed in trunk. This was the hardest on longest bug
>> fix I ever did! There are still some things to clean up, but I checked
>> in anyway because I am seriously running out of time.
>>
>> First, structural types need to be adapted. structural.scala is
>> disabled for the moment. Gilles, can you take care of this?
>>
>> Second, for some to me completely mysterious reason, run/runtime.scala
>> fails. I
>> have no idea what this has to do with the changes I did. If somebody
>> can help investigate, that would be most appreciated. (Hudson seems to
>> be down right now, so I can't check whether the runtime failure was in
>> fact caused my my checkin or whether it existed before).
>
> hudson is up again, fabien re-started tomcat. the build fails with
>
> [scalacfork]
> /localhome/hudson/workspace/scala-checkin/scala/src/library/scala/reflect/ClassManifest.scala:92:
> error: overloaded method value newInstance with alternatives (x$1:
> java.lang.Class[_],x$2: Array[Int])java.lang.Object (x$1:
> java.lang.Class[_],x$2: Int)java.lang.Object cannot be applied to
> (Class[_$1],Int,Int)
> [scalacfork] java.lang.reflect.Array.newInstance(erasure, 0,
> 0).getClass, len)
> [scalacfork] ^
>
>
That's probably because you are running on a 1.5 jvm? It turns out
there's an incompatible change in the signatures of Array.newInstance
between 1.5 and 1.6. 1.5 requires an array where 1.6 requires a
vararg. The two are the same only for Java b ut not for Scala.

Cheers

What I forgot to write: It also means that we need to special case
class reflect.Manifest for JDK 1.5. Essentially, instead of
newInstance(..., 0, 0) we need to pass newInstance(..., Array(0, 0)).

Cheers

On Sep 22, 2009, at 13:09, martin odersky wrote:

> On Tue, Sep 22, 2009 at 11:31 AM, Christos KK Loverdos
> wrote:
>> I should have reported that. The time Martin made the announcement, I
>> updated my svn working copy and fired ant, only to get the error
>> below. But
>> since sometimes I mess with the build, I thought something was
>> wrong on my
>> part.
>>
>> On Sep 22, 2009, at 11:01, Lukas Rytz wrote:
>>
>>
>> On Mon, Sep 21, 2009 at 15:01, martin odersky
>>
>> wrote:
>>>
>>> New arrays have landed in trunk. This was the hardest on longest bug
>>> fix I ever did! There are still some things to clean up, but I
>>> checked
>>> in anyway because I am seriously running out of time.
>>>
>>> First, structural types need to be adapted. structural.scala is
>>> disabled for the moment. Gilles, can you take care of this?
>>>
>>> Second, for some to me completely mysterious reason, run/
>>> runtime.scala
>>> fails. I
>>> have no idea what this has to do with the changes I did. If somebody
>>> can help investigate, that would be most appreciated. (Hudson
>>> seems to
>>> be down right now, so I can't check whether the runtime failure
>>> was in
>>> fact caused my my checkin or whether it existed before).
>>
>> hudson is up again, fabien re-started tomcat. the build fails with
>>
>> [scalacfork]
>> /localhome/hudson/workspace/scala-checkin/scala/src/library/scala/
>> reflect/ClassManifest.scala:92:
>> error: overloaded method value newInstance with alternatives (x$1:
>> java.lang.Class[_],x$2: Array[Int])java.lang.Object (x$1:
>> java.lang.Class[_],x$2: Int)java.lang.Object cannot be applied to
>> (Class[_$1],Int,Int)
>> [scalacfork] java.lang.reflect.Array.newInstance(erasure, 0,
>> 0).getClass, len)
>> [scalacfork] ^
>>
>>
> That's probably because you are running on a 1.5 jvm? It turns out
> there's an incompatible change in the signatures of Array.newInstance
> between 1.5 and 1.6. 1.5 requires an array where 1.6 requires a
> vararg. The two are the same only for Java b ut not for Scala.
>
> Cheers
>

Filed ticket #2381:

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

On Tue, Sep 22, 2009 at 7:27 PM, Christos KK Loverdos
wrote:
>
> On Sep 22, 2009, at 13:09, martin odersky wrote:
>
>> On Tue, Sep 22, 2009 at 11:31 AM, Christos KK Loverdos
>> wrote:
>>>
>>> I should have reported that. The time Martin made the announcement, I
>>> updated my svn working copy and fired ant, only to get the error below.
>>> But
>>> since sometimes I mess with the build, I thought something was wrong on
>>> my
>>> part.
>>>
>>> On Sep 22, 2009, at 11:01, Lukas Rytz wrote:
>>>
>>>
>>> On Mon, Sep 21, 2009 at 15:01, martin odersky
>>> wrote:
>>>>
>>>> New arrays have landed in trunk. This was the hardest on longest bug
>>>> fix I ever did! There are still some things to clean up, but I checked
>>>> in anyway because I am seriously running out of time.
>>>>
>>>> First, structural types need to be adapted. structural.scala is
>>>> disabled for the moment. Gilles, can you take care of this?
>>>>
>>>> Second, for some to me completely mysterious reason, run/runtime.scala
>>>> fails. I
>>>> have no idea what this has to do with the changes I did. If somebody
>>>> can help investigate, that would be most appreciated. (Hudson seems to
>>>> be down right now, so I can't check whether the runtime failure was in
>>>> fact caused my my checkin or whether it existed before).
>>>
>>> hudson is up again, fabien re-started tomcat. the build fails with
>>>
>>> [scalacfork]
>>>
>>> /localhome/hudson/workspace/scala-checkin/scala/src/library/scala/reflect/ClassManifest.scala:92:
>>> error: overloaded method value newInstance with alternatives (x$1:
>>> java.lang.Class[_],x$2: Array[Int])java.lang.Object (x$1:
>>> java.lang.Class[_],x$2: Int)java.lang.Object cannot be applied to
>>> (Class[_$1],Int,Int)
>>> [scalacfork]       java.lang.reflect.Array.newInstance(erasure, 0,
>>> 0).getClass, len)
>>> [scalacfork]                               ^
>>>
>>>
>> That's probably because you are running on a 1.5 jvm? It turns out
>> there's an incompatible change in the signatures of Array.newInstance
>> between 1.5 and 1.6. 1.5 requires an array where 1.6 requires a
>> vararg. The two are the same only for Java b ut not for Scala.
>>
>> Cheers
>>