BytecodeRewriter bug

Now I'm getting walkbacks trying to load D5 a ViewResource into D6 because the
BytecodeRewriter is throwing errors attempting to update an embedded
BlockClosure.

This time I'm stuck...

The BlockClosure was created (under D5) by saving a View which contains, as the
value of an instvar, the answer from the following method:

identity
    ^ (self new)
        getCellContentsBlock: [:it | it];
        yourself.

The bytecodes for the whole method in my D5 image are:

 1 Push self
 2 Special Send #new
 3 Dup
 4 Block Copy, 1 args, skip +6 to 11
 8 Store Temp[0]
 10 Return From Block
 11 Send[1]: #getCellContentsBlock: with 1 args
 12 Pop
 13 Return

Otherwise known as:
    #[
        16r39 16r92 16r64 16rFB
        16r01 16r03 16r00 16rD1
        16r00 16r6A 16rAE 16r61
        16r69
    ]

The error is
    Invalid double byte instruction: 229
which is puzzling since the input bytecodes (in my D5 image) don't contain 229
(16rE5).  However the bytecodes of the CompiledMethod which is being passed to
the BytecodeRewriter  (by #convertBlockToClosure) are:

    #[
        16r39 16r92 16r64 16rFC
        16r01 16r00 16r01 16r01
        16r04 16r00 16r11 16rE5
        16r20 16r6A 16rB0 16r61
        16r69
    ]

which the D6 inspector is quite happy to disassemble to:

 1 Push Self
 2 Special Send #new
 3 Dup
 4 Block Copy, 1 args, needs self, needs outer, skip +4 to 15
 11 Push Temp[0]
 12 Store Outer[1] Temp[0]
 14 Return From Block
 15 Send[0]: #getCellContentsBlock: with 1 args
 16 Pop
 17 Return

So I suspect that somehow the decoding is being done twice.

How can I work around this please ?  Currently I don't see how to load the
package with this walkback.  If I could, then regenerating the ViewResources is
easy (scripted).

    -- chris

I wrote:

> How can I work around this please ?  Currently I don't see how to load the
> package with this walkback.  If I could, then regenerating the
> ViewResources is easy (scripted).

I wrote too soon.  Figured out a way to make the package load, but now I can't
use the technique I use *A LOT* for building the initial ViewResources.  E.g
this class-side helper method for the root of a tree of View classes.

=====================
installViewResources
 "private -- install instances as named resources associated
  with various Presenter classes.

  self installViewResources.
 "

 self allSubclassesDo:
  [:each || ri v |
  ri := ResourceIdentifier class: GridPresenter name: each installableViewName.
  ri owningClass addView: each asResource: ri name.
  v := ri load.
  each massageInstallableView: v.
  ri save: v].
=====================

ViewResource>>load is now #shouldNotImplement !

What gives ?

Annoyed.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:441809af$0$1173$[hidden email]...
> Now I'm getting walkbacks trying to load D5 a ViewResource into D6 because
> the
> BytecodeRewriter is throwing errors attempting to update an embedded
> BlockClosure.
>
> This time I'm stuck...
>

Is the package available somewhere for me to try?

Regards

Blair

Blair,

> Is the package available somewhere for me to try?

Not readily, I'm afraid, it's not part of my published stuff, and is embedded
in sprawling mammoth of a package (which long overdue for a complete redesign),
not to mention dependent on the other packages I'm having problems with :-(.
I'll try to extract and/or create a smaller example of the problem.  If I can't
then I'll email you the mammoth if that's OK with you ?

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:44192f96$1$1170$[hidden email]...
Yup, that's fine.

Regards

Blair

Blair,

> Is the package available somewhere for me to try?

I've just sent you an example package.

In case anyone else is interested, it seems to be because there are two
different Blocks in the same Resource which were created by executing the same
method.  The de-STB-ing process seems to try to convert the bytecodes for the
CompiledMethod instance twice.

    -- chris