[M3devel] Fwd: Re: netobj bug report

[Rodney Bates]

Your analysis makes sense to me, though I don't know much about this code.
It certainly seems like it would make the immediate symptom go away.  
However, I wonder if it will do what you want.  

Formal r has type NetObj.T or a subtype thereof, and r has an enlighteningly
named field r.  Is r.r the ordinary object that is being networked?  
And is it the exporting of r that fills in r.r to non-NIL?  If this is
the case, it seems like getting pickling to complete before exporting would
just pickle r with r.r=NIL.  Does that do any good?     

rom: mika at async.caltech.edu
To: "Coleburn, Randy" <rcolebur at SCIRES.COM>
Cc: m3devel at elegosoft.com
Subject: Re: [M3devel] netobj bug report
Date: Fri, 26 Jul 2013 20:07:17 -0700

Hi Randy (or anyone on m3devel),

Have you considered my bug report?  Can someone who knows the code better
than me analyze the situation and either clear my code or justify the
existing code as checked in and tell me what I'm doing wrong?  

I have had to change the code as I described in my old pm3 sources to
get my application working, tired of doing workarounds.

I strongly suspect we're dealing with an annoying bug, and it looks 
present in both Pickle.m3 and Pickle2.m3, all versions (CM3, PM3 at least).

     Mika

"Coleburn, Randy" writes:
>Hi Mika:
>
>I'm deep in the middle of some other stuff, but read your post with interes=
>t because I've done a LOT of work with both Pickles and Network Objects.
>
>On the surface, I'm not sure whether this is a bug or not.  I've never enco=
>untered this problem before.  But, my brain is in left-field right now with=
> all else I have going on.
>
>I know that I always used the Pickle2 (2nd generation of pickles) to get ar=
>ound some problems with the first generation.  I never used PM3, just CM3 a=
>nd the original "SRC-Systems Research Center" versions.
>
>I know you can also write and register special "pickler" procedures for any=
> particular object to get around problems with the default pickling procedu=
>res (read/write).  I've had to do this on occasion both to resolve problems=
> and to increase performance.  I can provide examples if you need them.
>
>--Randy
>
>Randy C. Coleburn, CISSP-ISSEP, GCED
>Corporate Information Security Officer (CISO)
>Scientific Research Corporation
>
>-----Original Message-----
>From: mika at async.caltech.edu [mailto:mika at async.caltech.edu]=20
>Sent: Thursday, June 27, 2013 7:01 PM
>To: m3devel at elegosoft.com
>Subject: EXT:[M3devel] netobj bug report
>
>Hi m3devel,
>
>I think I found a bug in the Network Objects code.
>
>Here is what I was doing: I made an object that I wanted to export using Ne=
>twork Objects, but I *also* wanted to Pickle the object locally (for persis=
>tence).
>
>I find that if I create the object and try to pickle it, I get a Pickle err=
>or "Can't pickle a surrogate object". =20
>
>The source of the error is in StubLib.m3, the Pickle special that is record=
>ed for network objects:
>
>PROCEDURE OutSpecial(self: Pickle.Special;
>                 r: REFANY;
>                 writer: Pickle.Writer)
>  RAISES  {Pickle.Error, Wr.Failure, Thread.Alerted} =3D
>  BEGIN
>    TYPECASE writer OF
>    | SpecWr(wtr) =3D> OutRef(wtr.c, r);
>    ELSE
>      TYPECASE r OF
>      | NetObj.T(x) =3D>
>          IF NOT ISTYPE(x.r, Transport.Location) THEN
>            (* This will gratuitously pickle the ExportInfo ref
>               embedded in x.r.  It would be better to exclude this
>               if and when possible, but it shouldn't hurt for now. *)
>            Pickle.Special.write(self, r, writer);
>          ELSE
>            RAISE Pickle.Error("Can't pickle a surrogate object");
>          END;
>      ELSE RAISE Pickle.Error("Can't Pickle Rd.T or Wr.T");
>      END;
>    END;
>  END OutSpecial;
>
>(In CM3, OutSpecial2 has the same bug for Pickle2 pickles.  PM3 doesn't hav=
>e Pickle2 nor OutSpecial2.)
>
>The problem is the test
>
>         IF NOT ISTYPE(x.r, Transport.Location) THEN
>            (* This will gratuitously pickle the ExportInfo ref
>               embedded in x.r.  It would be better to exclude this
>               if and when possible, but it shouldn't hurt for now. *)
>            Pickle.Special.write(self, r, writer);
>          ELSE
>            RAISE Pickle.Error("Can't pickle a surrogate object");
>          END;
>
>The intent, I think, is that an object that is remote (that is, has x.r of =
>type Transport.Location) should not be pickle-able.
>
>The problem is that x.r is initially NIL, and NIL is a member of Transport.=
>Location.
>
>My workaround is to FIRST export the object before attempting to Pickle it.=
>  This works fine but it shouldn't be necessary, should it?  What if I don'=
>t want to export the object, but just pickle it?
>
>I believe the test should be changed to be
>
>IF x.r =3D NIL OR NOT ISTYPE(x.r, Transport.Location) THEN...
>
>    Mika
>