put your best forwarder... foot.

I just reenabled forwarders - martin discovering a big pickling bug 
which was causing the really mysterious behavior, and there was another 
unrelated problem which was more self-evident once that was out of the 
way.  I threw every issue I know about at r18434 and everyone came 
through unscathed.  If anyone with particular love (or hate) for 
forwarders would like to give them a spin and perhaps give me a chance 
to reopen zombie ticket #363 yet one more time, that'd be nice.

--

-- 
Paul Phillips      | We act as though comfort and luxury were the chief
Caged Spirit       | requirements of life, when all that we need to make us
Empiricist         | really happy is something to be enthusiastic about.
pal, i pill push   |     -- Charles Kingsley

Re: put your best forwarder... foot.

Cool. I'm glad we cracked that one!

Cheers

 -- Martin

On Mon, Aug 3, 2009 at 1:49 PM, Paul Phillips<paulp@...> wrote:
> I just reenabled forwarders - martin discovering a big pickling bug
> which was causing the really mysterious behavior, and there was another
> unrelated problem which was more self-evident once that was out of the
> way.  I threw every issue I know about at r18434 and everyone came
> through unscathed.  If anyone with particular love (or hate) for
> forwarders would like to give them a spin and perhaps give me a chance
> to reopen zombie ticket #363 yet one more time, that'd be nice.
>
> --
> Paul Phillips      | We act as though comfort and luxury were the chief
> Caged Spirit       | requirements of life, when all that we need to make us
> Empiricist         | really happy is something to be enthusiastic about.
> pal, i pill push   |     -- Charles Kingsley
>
>

Re: put your best forwarder... foot.

Re: put your best forwarder... foot.

Re: put your best forwarder... foot.

Re: put your best forwarder... foot.

On Mon, Aug 03, 2009 at 09:55:31AM -0400, Erik Engbrecht wrote:
> Awfully productive for someone on vacation!  

I'm still on vacation! I did that work before I "left" and hadn't gotten 
around to checking it in yet.  I didn't want to come back from vacation 
to find the patch no longer applied (the curse of perpetually having a 
few dozen git branches.)

--

-- 
Paul Phillips      | A Sunday school is a prison in which children do
Apatheist          | penance for the evil conscience of their parents. 
Empiricist         |     -- H. L. Mencken
pp: i haul pills   |----------* http://www.improving.org/paulp/ *----------

method super$++

I noticed this comment in GenJVM in r18060:

// the following call to 'info' may cause certain symbols to fail loading because we're
// too late in the compilation chain (aliases to overloaded symbols will not be properly
// resolved, see scala.Range, method super$++ that fails in UnPickler at LazyTypeRefAndAlias.complete

Are you sure that reasoning is complete? I ask because your particular 
example of a method which fails in unpickler -- "super$++" -- is also my 
example of a method of interest in a different context, and that is that 
its expanded name is lossy.

My desktop which has this code on it is still not unpacked so I can't be 
100% specific, but I have a branch which records every call to 
originalName and expandName and complains if originalName(expandName(x)) 
!= x.  When building scalac, all the complaints are about constructs 
like super.++ because "super$" + "$plus" == "super$$plus" and "$$" is 
also used in name mangling, but for a different purpose.

I hadn't pinpointed what if any issues this was causing so it's been 
sitting there waiting for me to figure that out, but now that I see it 
mentioned by name in a comment I figured I better share what I know.

--

-- 
Paul Phillips      | Giving every man a vote has no more made men wise
In Theory          | and free than Christianity has made them good. 
Empiricist         |     -- H. L. Mencken
slap pi uphill!    |----------* http://www.improving.org/paulp/ *----------

Re: method super$++

It looks plausible to be that, but I cannot reproduce it anymore, and I 
don't see an obvious code path involving originalName. The crash was due 
to not finding the right overload at line 827 in UnPiclers.scala, 
returning NoSymbol. I initially thought it's a phase ordering problem, 
and names were transformed before the lazy symbol was forced (at the jvm 
phase).

iulian

Paul Phillips wrote:
> I noticed this comment in GenJVM in r18060:
>
> // the following call to 'info' may cause certain symbols to fail loading because we're
> // too late in the compilation chain (aliases to overloaded symbols will not be properly
> // resolved, see scala.Range, method super$++ that fails in UnPickler at LazyTypeRefAndAlias.complete
>
> Are you sure that reasoning is complete? I ask because your particular 
> example of a method which fails in unpickler -- "super$++" -- is also my 
> example of a method of interest in a different context, and that is that 
> its expanded name is lossy.
>
> My desktop which has this code on it is still not unpacked so I can't be 
> 100% specific, but I have a branch which records every call to 
> originalName and expandName and complains if originalName(expandName(x)) 
> != x.  When building scalac, all the complaints are about constructs 
> like super.++ because "super$" + "$plus" == "super$$plus" and "$$" is 
> also used in name mangling, but for a different purpose.
>
> I hadn't pinpointed what if any issues this was causing so it's been 
> sitting there waiting for me to figure that out, but now that I see it 
> mentioned by name in a comment I figured I better share what I know.
>
>   

--

-- 
Iulian Dragos
=============
EPFL-IIF-LAMP 1
INR 321 
http://lamp.epfl.ch/~dragos

rich repl console

Re: rich repl console