<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Serial I/O is used plenty, for debugging.<BR>
Though the protocols are generally "binary" not "text".<BR>
Even any world with multiple systems messes with historical notions that one system is one way, other systems are another, and that they rarely see each other or exchange files. File exchange is very common these days, so it behooves every piece of new code to understand either format and possibly detect what the old code on the other side wants and be willing to write any of the three formats. "Constants" end up not useful.<BR>
<BR>
<BR>
This isn't the EOL you care about.<BR>
Target.EOL is written to .m3ship, foo.molog.<BR>
It is used in m3front, m3middle, m3back, cm3 packages.<BR>
It is exposed from m3middle/Target.i3.<BR>
<BR>
<BR>
It is used by the old bootstrapping code, which is strewn around cm3, which I do use some of as part of my automation, uses it. (I don't use e.g. the makefile fragments that it outputs, but I use the behavior that stops after producing assembly, doesn't run the assembler or linker or C compiler)<BR>
<BR>
<BR>
For example if you cross from NT386 to Posix, any \r\n in .man, .c, .h files will be changed to \n, and copied to the target directory. The thing is though, we don't have any \r\n anyway so that is a no-op. If you cross from Posix to NT386, \n will changed to \r\n. But it doesn't matter. Native builds just leave the \n alone -- which is what we always have -- and they work fine. If you cross from a hypothetical old Macintosh with its \r format, the newlines get completely destroyed because the code is wrong. Oops.<BR>
<BR>
<BR>
Target.EOL can be changed to Wr.EOL or a hardcoded \n and almost nothing would change.<BR>
The difference is that if we hardcoded \n, native NT386 users who happened to look at .m3ship with notepad, wouldn't have a good experience. Almost nobody ever looks at those files. Use Wr.EOL and then the only downside would be .m3ship files when crossing to NT386. And even still, .m3ship files don't participate in cross builds as I do them. My cross build only produces cm3, and then I build the rest native. Though there is a place for this perhaps. A cross build that builds everything, leaving final assembly, C compilation, linking and shipping to the target. We should consider that as a future distribution format. Similar to today's packages, but cross. But still, Wr.EOL will be fine.<BR>
<BR>
<BR>
I'm very tempted to say the same thing about / and \, except that I recently experienced the pain of using an older NT386 cm3 that doesn't accept \. It behooves me to use \ "where appropriate" so I can be compatible with that. I need to fix scripts/python and/or cminstall/src/config-no-install a little.<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>
<HR id=stopSpelling>
From: rcolebur@SCIRES.COM<BR>To: jay.krell@cornell.edu; m3devel@elegosoft.com<BR>Date: Thu, 11 Mar 2010 17:03:30 -0500<BR>Subject: RE: [M3devel] Target.EOL<BR><BR>
<STYLE>
.ExternalClass p.ecxMsoNormal, .ExternalClass li.ecxMsoNormal, .ExternalClass div.ecxMsoNormal
{margin-bottom:.0001pt;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass a:link, .ExternalClass span.ecxMsoHyperlink
{color:blue;text-decoration:underline;}
.ExternalClass a:visited, .ExternalClass span.ecxMsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
.ExternalClass p
{margin-right:0in;margin-left:0in;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass span.ecxEmailStyle18
{font-family:'Calibri','sans-serif';color:#1F497D;}
.ExternalClass .ecxMsoChpDefault
{font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;}
.ExternalClass div.ecxSection1
{page:Section1;}
</STYLE>
<DIV class=ecxSection1>
<P class=ecxMsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I don’t think I’ve used Target.EOL, but I’ve definitely used some EOL definition somewhere, maybe it was Wr.EOL, I’d have to check to be sure.</SPAN></P>
<P class=ecxMsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"> </SPAN></P>
<P class=ecxMsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I’m not sure the implications of removing Target.EOL, but whatever is done, we need to maintain a way to distinguish at runtime the proper line ending format for the host environment. </SPAN></P>
<P class=ecxMsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"> </SPAN></P>
<P class=ecxMsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">I’ve written a lot of code in the past where this is important. Some of my code interfaces with other systems whose line ending formats have to be compared and/or reconciled with the host when doing serial data transfer (yes there are still systems that rely on good ‘ol serial I/O, particularly legacy DoD systems).</SPAN></P>
<P class=ecxMsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"> </SPAN></P>
<P class=ecxMsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Regards,</SPAN></P>
<P class=ecxMsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'">Randy</SPAN></P>
<P class=ecxMsoNormal><SPAN style="FONT-SIZE: 11pt; COLOR: #1f497d; FONT-FAMILY: 'Calibri','sans-serif'"> </SPAN></P>
<DIV>
<DIV style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; BORDER-LEFT: medium none; PADDING-TOP: 3pt; BORDER-BOTTOM: medium none">
<P class=ecxMsoNormal style="MARGIN-LEFT: 0.5in"><B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'">From:</SPAN></B><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Tahoma','sans-serif'"> jayk123@hotmail.com [mailto:jayk123@hotmail.com] <B>On Behalf Of </B>Jay K<BR><B>Sent:</B> Thursday, March 11, 2010 10:41 AM<BR><B>To:</B> m3devel<BR><B>Subject:</B> [M3devel] Target.EOL<BR><B>Importance:</B> Low</SPAN></P></DIV></DIV>
<P class=ecxMsoNormal style="MARGIN-LEFT: 0.5in"> </P>
<P class=ecxMsoNormal style="MARGIN-LEFT: 0.5in"><SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: 'Verdana','sans-serif'">I strongly suspect that Target.EOL can go away and just use Wr.EOL instead.<BR> Or even just \n.<BR> <BR> <BR>Cross builds are fairly rare, esp. cross between NT and Posix, and very<BR>many tools treat \n, \r\n, and perhaps \r the same, so even<BR>crossing NT <=> Posix doesn't likely matter.<BR> ie. it works, assuming you have a cross m3cg (ie: mingwin/cygwin hosted for NT hosts)<BR> <BR> <BR>gcc, Visual C++ compiler, m3front, all treat \r and \r\n the same.<BR> (witness all our *.h, *.c, *.i3, *.m3 files use \r\n)<BR>I think we have some tools that don't understand \r\n, but in my opinion that is a bug.<BR> All three formats should be treated the same.<BR> <BR> <BR>I know notepad doesn't display \n well, and Sun cc might not like \r\n.<BR> I know some compiler I used recently was picky, but "many" compilers are not.<BR>cmd might be ok with \n.<BR>Python calls it "universal newlines", treating all three formats the same.<BR> <BR> <BR>C:\dev2\cm3.2\m3-sys\cm3\src\Utils.m3(190):PROCEDURE CopyText (old, new: TEXT) =<BR>C:\dev2\cm3.2\m3-sys\m3middle\src\M3File.m3(61):PROCEDURE CopyText (src, dest: TEXT; eol: TEXT) RAISES {OSError.E} =<BR><BR> <BR>probably leave alone, except that they don't treat \r correctly if you consider the historical Apple behavior.<BR>There are three formats, not two.<BR> <BR> <BR>Anyway, it's not a big deal. I think my problem here is solved by the change to m3x86.m3 I already made.<BR>I'll put Target.EOL back on my machine.<BR> <BR> <BR> - Jay</SPAN></P></DIV><BR>
<HR>
<FONT face=Arial color=gray size=1>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.<BR><BR>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.<BR></FONT> </body>
</html>