[M3devel] Target.EOL

[Coleburn, Randy]

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.

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.

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

Regards,
Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Thursday, March 11, 2010 10:41 AM
To: m3devel
Subject: [M3devel] Target.EOL
Importance: Low

I strongly suspect that Target.EOL can go away and just use Wr.EOL instead.
  Or even just \n.


Cross builds are fairly rare, esp. cross between NT and Posix, and very
many tools treat \n, \r\n, and perhaps \r the same, so even
crossing NT <=> Posix doesn't likely matter.
  ie. it works, assuming you have a cross m3cg (ie: mingwin/cygwin hosted for NT hosts)


gcc, Visual C++ compiler, m3front, all treat \r and \r\n the same.
 (witness all our *.h, *.c, *.i3, *.m3 files use \r\n)
I think we have some tools that don't understand \r\n, but in my opinion that is a bug.
  All three formats should be treated the same.


I know notepad doesn't display \n well, and Sun cc might not like \r\n.
  I know some compiler I used recently was picky, but "many" compilers are not.
cmd might be ok with \n.
Python calls it "universal newlines", treating all three formats the same.


C:\dev2\cm3.2\m3-sys\cm3\src\Utils.m3(190):PROCEDURE CopyText (old, new: TEXT) =
C:\dev2\cm3.2\m3-sys\m3middle\src\M3File.m3(61):PROCEDURE CopyText (src, dest: TEXT;  eol: TEXT) RAISES {OSError.E} =


probably leave alone, except that they don't treat \r correctly if you consider the historical Apple behavior.
There are three formats, not two.


Anyway, it's not a big deal. I think my problem here is solved by the change to m3x86.m3 I already made.
I'll put Target.EOL back on my machine.


 - 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100311/65fb39ed/attachment-0002.html>