[M3devel] example of bug in NetObj Stub Generator

Fri Apr 16 23:07:04 CEST 2010

Jay / Rodney / et al:

I’ve attached a ZIP file containing a stripped-down source package and NT386 folder that demonstrates the problem I am having with the stub generator.

The generated file “NT386\CV_Server_T_v2.m3” is missing the import of the “Date” interface.

The source interface that I wrote is in “src\CV_Server.i3”.

Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, April 15, 2010 7:13 PM
To: Coleburn, Randy; m3devel
Subject: RE: [M3devel] Modula-3/C interop in Date/Time?

Randy,  I think I understand but yes please commit a small concrete example like in m3-sys/m3tests/src/p2/p237 or such. I think this is a bug in the stub generator. Probably time/date could workaround it with slight restructuring/renaming. But probably should fix the stub generator. While at it, maybe have it stop outputing unused stuff that triggers so many warnings...

 - Jay

________________________________
From: rcolebur at SCIRES.COM
To: m3devel at elegosoft.com
Date: Thu, 15 Apr 2010 18:10:44 -0400
Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
Jay:

I’m still catching up after being in hospital, but noticed you are working on the Date.i3/m3 interface and module.

There is a problem that I’d like to post on the newsgroup that may be related.

I’m not sure if the problem is due to the way Date.i3/m3 is coded, or perhaps a problem in the network objects stub generator, but I thought whilst you are looking at Date.i3/m3 something might trigger in your mind about how to fix the problem.

I have several interfaces that export a Network Object.  Of course, these get processed by the network objects stub generator at compile time.  For some of these, the generated files fail to compile due to Date.i3 not being listed in the IMPORT list.

Since these offending modules are generated at compile time, it’s not a programming error in the new source package that is being compiled.

The way I work around the problem is by editing the generated files after the compile fails.  Namely, I go to the target folder (in this case NT386) and edit the generated m3 files by adding “IMPORT Date;”, then recompile and all is well.

Of course, the next time you erase the target folder, change the underlying interface, or run “cm3 -clean”, the generated file has to be created again and you have to go thru the compile-edit-compile cycle again to repair the problem.  If you are delivering source code to a customer, you then have to document the work-around for them so that they can get the package to compile.

I reported this problem years ago, but that was back before we were tracking bugs using the new system.

It could be that the way Date.i3/m3 is coded is causing the stub generator not to think it needs to import it, or it could be that the stub generator isn’t doing its job right in the first place.

Now after saying all this, I know I should provide a concrete example.  I’ll have to go back and see if I ever reduced the code to a smaller set that demonstrates the problem.  Otherwise, I can’t give anyone the full source code because it was a “work-for-hire” and I don’t have the right to publish these sources.

Let me know if you want a concrete example and I’ll see what I can do.

Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, April 15, 2010 5:26 PM
To: Tony
Cc: m3devel
Subject: Re: [M3devel] Modula-3/C interop in Date/Time?

Oops, right, of course. Important to get the things right I know to keep the question clear/narrow.

 - Jay

________________________________
From: hosking at cs.purdue.edu
Date: Thu, 15 Apr 2010 12:55:52 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] Modula-3/C interop in Date/Time?
Excepting that INTEGER is not the same as int on 64-bit platforms.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Office +1 765 494 6001 | Mobile +1 765 427 5484

On 15 Apr 2010, at 02:45, Jay K wrote:

Is this legal/correct?

Date.i3:
TYPE TimeZone <: REFANY;
VAR Local, UTC: TimeZone; (* granted, will maybe change these to extern *)

Date.m3:　
REVEAL TimeZone = BRANDED "Date.TimeZone" REF INTEGER;

DatePosixC.c:
static const int Local = 0;
static const int UTC = 1;
extern const int const * const Date__Local = &Local;
extern const int const * const Date__UTC = &UTC;

- Jay

________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.

________________________________
CONFIDENTIALITY NOTICE: This email and any attachments are intended solely for the use of the named recipient(s). This email may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, you are prohibited from reviewing, copying, using, disclosing or distributing to others the information in this email and attachments. If you believe you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts of the email or attachments.

EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100416/b58da3f7/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BugExample.zip
Type: application/x-zip-compressed
Size: 8839 bytes
Desc: BugExample.zip
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100416/b58da3f7/attachment-0002.bin>