<br><br><div class="gmail_quote">On Tue, May 17, 2011 at 2:48 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On 17 May 2011 23:10, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
>><br>
>> But why you want to explicitly control line ends?<br>
><br>
> Because all the C compilers I use to build VMs (and have built VMs with) have accepted lf line endings. There is therefore no need and no point in producing source in anything other than lf line ends.<br>
><br>
<br>
</div>Is MSVC works fine with such line endings as well?<br></blockquote><div><br></div><div>Yes, that's what I said. The VisualWorks VM has had line-feed line-endings for decades compiled with MSVC, and Mac's cr-based development tool (whose name escapes me for the moment).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Because the main issue with line endings in C is multi-line macros i.e.:<br>
<br>
#define foo line1\<br>
line2 ... \<br>
line3<br>
<br>
and if compiler don't detects line ends correctly, then you will have<br>
syntax errors.<br></blockquote><div><br></div><div>I don't think so. Either in assembling the macro or in expanding it carriage-returns and line-feeds are eliminated and so in C, AFAIA, it is impossible to embed a line-feed or carriage-return character in a C macro.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
For the rest of cases, i think there is no strict dependency on that ,<br>
and line ends treated just like<br>
any other white-space characters (space, tab etc) without any<br>
compilation issues.<br>
<br>
(Btw that's why i don't like a Python where white space characters are<br>
used as a part of syntax,<br>
because depending on running platform and which text editor you using,<br>
your mileage could vary..<br>
And so, instead of spending time on what you really want to do, you<br>
spending time on making parser/compiler<br>
to be pleased with inputs you providing. As to me this is too 70's<br>
approach, but not 2010's ;) ).<br>
<div class="im"><br>
>><br>
>> Because if you do it like that its not too different to what i have<br>
>> proposed: use a stream in binary mode and deal<br>
>> with line ends inside VMMaker and don't bother with what<br>
>> MultiByteFileStream provides in this regard.<br>
><br>
> Seems to be unnecessarily reinventing the wheel.<br>
<br>
</div>A kind of, but consider that for this reinvention<br>
in CMakeVMMaker there are just a single method, which is responsible for that:<br>
<br>
fixLineEndsOf: string<br>
^ string copyReplaceAll: String cr with: String crlf<br>
<br>
and of course for non-windows it has a different implementation:<br>
<br>
fixLineEndsOf: string<br>
^ string copyReplaceAll: String cr with: String lf<br>
<br>
and then its used like this:<br>
<br>
write: aContents toFile: aFileName<br>
<br>
"write a file to current output directory (buildDir).<br>
use line end convention appropriate for config platform"<br>
<br>
<br>
| bldDir |<br>
<br>
bldDir := self buildDir.<br>
<br>
bldDir isString ifTrue: [ bldDir := FileDirectory on: (FileDirectory<br>
fullPathForURI: bldDir) ].<br>
bldDir assureExistence.<br>
<br>
bldDir forceNewFileNamed: aFileName<br>
do: [:stream | stream nextPutAll: (self fixLineEndsOf: aContents) ].<br>
<br>
<br>
This allows me to control output explicitly without relying on clever<br>
logic which tries to detect line ends<br>
convention based on which platform you running.<br>
Because in configs i can be explicit, since i know beforehand where<br>
these configs will be used - on Mac, Unix or Windows etc.<br></blockquote><div><br></div><div>As I've said repeatedly there's no need to produce anything other than lf-endings on all these platforms. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
And because you are also want to explicitly use lf, i think that<br>
reinvention which takes 1 method to implement is worth it,<br>
because it providing certain guarantees of what output you will get<br>
and be future-proof, no matter what 'improvements'<br>
we will have in this area tomorrow :)<br>
And i think you already spent more time on it, trying to fit VMMaker's<br>
feets into new shoes, while you can spend time<br>
to simply implement 1 method and be done with it :)<br></blockquote><div><br></div><div>Six of one and half a dozen of the other. What I have works fine without adding a buffering step, which is no small issue when the interpreter is nigh on a megabyte. I think I'll stick with what I have thanks.</div>
<div>.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
> cheers,<br>
<div><div></div><div class="h5">> Eliot<br>
<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
</div></div></blockquote></div><br>