[M3devel] Modula-3/C interop in Date/Time?

[Rodney M. Bates]

Coleburn, Randy wrote:
> 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.

I can't think of a way this could be anything but a bug in stubgen.
The very fact (and only the fact) that the generated stub code refers
to Date necessitates the IMPORT Date, regardless of what is coded in
interface Date or what within Date is being referred to.

Is the reference to Date in the generated stub derived from a
reference to Date in the interface that stubgen is processing, or is
it produced within stubgen itself?  Actually, either way, stubgen
should produce the IMPORT.

> 
>  
> 
> 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.