[M3devel] LONGINT -> more bugs in m3tk

[Mika Nystrom]

Ah, ok... such bugs ought to be fairly easy to fix.  Maybe...

To be clear, there are at least three stub generators that use m3tk that
I know of (and probably others too)

"stubgen" for Network Objects

"stablegen" for some sort of stable storage database 

"sstubgen" (not in CM3 yet!) that generates stubs for the "Modula-Scheme
           system" (what I referenced below)

   Mika

"Coleburn, Randy" writes:
>While we are on the subject of the stub generator, there is another long-st=
>anding problem.
>
>I've submitted this one years ago and I think I still have the example prog=
>ram 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 ca=
>n work around this problem by manually editing the generated stub to provid=
>e 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
>
>-----Original Message-----
>From: Mika Nystrom [mailto:mika at async.caltech.edu]=20
>Sent: Tuesday, May 17, 2011 9:36 PM
>To: Rodney M. Bates
>Cc: m3devel at elegosoft.com
>Subject: Re: [M3devel] LONGINT -> more bugs in m3tk
>
>I think you'll get that error if you run stubgen on anything that reference=
>s
>a type from BasicCtypes (e.g., int, char_star ...)
>
>I'm pretty sure I actually got it running the stub generator for my
>Scheme interpreter, which I have posted links to here a few times, but I
>haven't had time to push into CM3 yet.
>
>     Mika
>
>"Rodney M. Bates" writes:
>>Mika, can you tell me what main program and command you used to get these =
>erro
>>rs?
>>It would help me to test changes to m3tk.
>>
>>On 04/26/2011 11:28 AM, Rodney M. Bates wrote:
>>> I just checked in a patch tp M3CExpValue.m3 in m3tk, in the head, which =
>I be
>>lieve will fix this
>>> bug. I compiled it, but have not tested it, as I am sure Mika has this c=
>ase=20
>>to retry
>>> more quickly than I can.
>>>
>>> On 04/19/2011 06:51 AM, Mika Nystrom wrote:
>>>> Hello m3devel,
>>>>
>>>> If anyone knows how to fix the following trivially, please go ahead.
>>>>
>>>> "/usr/local/cm3/pkg/m3core/src/C/64BITS/BasicCtypes.i3", line 18,45: ty=
>pe e
>>rror in arguments to binary operator
>>>> "/usr/local/cm3/pkg/m3core/src/C/64BITS/BasicCtypes.i3", line 18,25: ba=
>d nu
>>meric literal
>>>> "/usr/local/cm3/pkg/m3core/src/C/64BITS/BasicCtypes.i3", line 18,51: ba=
>d nu
>>meric literal
>>>>
>>>> (errors reported by m3tk).
>>>>
>>>> The offending line is:
>>>>
>>>> INTERFACE BasicCtypes;
>>>>
>>>> IMPORT Word, Long;
>>>>
>>>> TYPE
>>>> (* the four signed integer types *)
>>>> signed_char =3D [-16_7f-1 .. 16_7f];
>>>> short_int =3D [-16_7fff-1 .. 16_7fff];
>>>> int =3D [-16_7fffffff-1 .. 16_7fffffff];
>>>> long_int =3D [-16_7fffffffffffffff -1 .. 16_7fffffffffffffff ];
>>>> long_long =3D [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]; (** H=
>ERE **
>>)
>>>>
>>>> (* the four unsigned integer types *)
>>>> unsigned_char =3D [16_0 .. 16_ff];
>>>> unsigned_short_int =3D [16_0 .. 16_ffff];
>>>> unsigned_int =3D [16_0 .. 16_ffffffff];
>>>> unsigned_long_int =3D Word.T;
>>>> unsigned_long_long =3D Long.T;
>>>>
>>>> (* the three floating types *)
>>>> float =3D REAL;
>>>> double =3D LONGREAL;
>>>> long_double =3D EXTENDED;
>>>>
>>>> (* char *)
>>>> char =3D signed_char;
>>>>
>>>> END BasicCtypes.
>>>>
>>>> I'll look at it myself, but not immediately (no time). Workaround for n=
>ow.
>>>>
>>>> Mika
>>>>
>>>