[M3devel] Fwd: Re: netobj bug report

[mika at async.caltech.edu]

I believe "r" is just a field for the Network Objects system to know
whether the object is a real object or a surrogate.  In that case,
pickling it with it NIL does precisely the right thing for a real,
local object.

I doubt it could be a pointer to the "real" object because the
real object is the same as the NetObj.T itself (a subtype thereof).
r.r would have to point to r in that case.  Which doesn't make
much sense.

     Mika

"Rodney Bates" writes:
>
>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
>>
>