[M3devel] LONGINT -> more bugs in m3tk

Daniel Alejandro Benavides D. dabenavidesd at yahoo.es
Wed May 18 23:49:05 CEST 2011


Hi all:
This is good news (though old) shows up, this is perhaps the problem with Obliq problem (worked in pm3), by the way what could be missing if so from there in CM3? 
Thanks in advance

PS It might be that CM3 once worked Obliq, since there is a thesis reportedly working on Obliq3D of Blair MacIntyre, an augmented reality system, this is probably 1999, so a lot of stuff might came or not after that.

--- El mié, 18/5/11, Coleburn, Randy <rcolebur at SCIRES.COM> escribió:

> De: Coleburn, Randy <rcolebur at SCIRES.COM>
> Asunto: Re: [M3devel] LONGINT -> more bugs in m3tk
> Para: "m3devel at elegosoft.com" <m3devel at elegosoft.com>
> Fecha: miércoles, 18 de mayo, 2011 16:04
> Ok, I found some stuff in my archives
> about a set of documented stubgen problems, but this stuff
> doesn't include the problem I described with the failure to
> generate imports for all interfaces.  Actually, I think
> this interface import problem is with the network objects
> stub generator, so I will either find or create an example
> of this problem and submit later.
> 
> Here is a short program (with comments) that demonstrates
> some stubgen problems.  I generated this program back
> in January 2001, so these are long-standing issues.
> 
> Regards,
> Randy Coleburn
> 
> 
> m3makefile is:
> 
> import("libm3")
> import("netobj")
> Interface("StubGenProblem")
> Netobj("StubGenProblem", "T")
> Library("NetObjProblem")
> 
> 
> 
> StubGenProblem.i3 is:
> 
> INTERFACE StubGenProblem;
> (* Interface demonstrating problem with Network Objects
> Stub Generator *)
> (* R.C.Coleburn, 01/24/2001 *)
> IMPORT
>    NetObj,
>    Thread;
> TYPE
>    MyRecord = RECORD
>       a: INTEGER := 0;
>       b: TEXT := "zero";
>    END;
> CONST
>    Default = MyRecord{1, "one"};
> TYPE
>    MyObject = OBJECT
>       myRec: MyRecord := Default;
>       (* if you change above line to be:
>          myRec: MyRecord;
>          that is, leave out
> the default initializer, the stub
>          generator no longer
> complains when parameters of type
>          MyObject are passed
> to methods of type T. *)
>    END;
> TYPE
>    T = NetObj.T OBJECT
>    METHODS
>       (* method testA is accepted by the
> NetObj Stub Generator *)
>       testA(myRec: MyRecord) RAISES
> {NetObj.Error, Thread.Alerted};
> 
>       (* method testB is accepted by the
> NetObj Stub Generator *)
>       testB(myRec: MyRecord := Default)
> RAISES {NetObj.Error, Thread.Alerted};
> 
>       (* method testC yeilds the following
> error from the NetObj Stub Generator:
>          stubgen: INTERNAL
> ERROR: AstToVal.ProcessExp: unsupported value *)
>       (* Does anyone know why the stub
> generator can't handle this? *)
>       (* Does anyone know of a workaround or
> a fix to the stub generator? *)
>       testC(myObj: MyObject) RAISES
> {NetObj.Error, Thread.Alerted};
> 
>       (* BTW, if you comment out the
> assignment of Default to MyObject.myRec
>       in the declaration on line 16, the
> stub generator no longer complains.
>       So, it seems that the problem is
> passing an object parameter containing
>       a record field member with a default
> initializer.  Note that passing a
>       record parameter with a default
> initializer is not a problem for the
>       stub generator. *)
>    END;
> END StubGenProblem.
> 
> 
> 
> -----Original Message-----
> From: Coleburn, Randy 
> Sent: Wednesday, May 18, 2011 2:28 PM
> To: Mika Nystrom; Rodney M. Bates
> Cc: m3devel at elegosoft.com
> Subject: Re: [M3devel] LONGINT -> more bugs in m3tk
> 
> While we are on the subject of the stub generator, there is
> another long-standing problem.
> 
> I've submitted this one years ago and I think I still have
> the example program I devised to show it.
> 
> So, I'll try to dig this up and put it into the bug
> tracker.
> 
> The basic situation is that there are cases where the stub
> generator doesn't generate imports for all interfaces needed
> by the resulting stub.  You can work around this
> problem by manually editing the generated stub to provide
> the missing imports, but this gets old quickly.
> 
> I'll send a follow-up post with the details once I find
> them in my archives.
> 
> Regards,
> Randy Coleburn
> 



More information about the M3devel mailing list