[OT] MultiByteFileStream (was: Re: [Vm-dev] VM Maker: CMakeVMMaker-StasenkoIgor.104.mcz)

[Igor Stasenko]

On 18 May 2011 00:06, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Tue, May 17, 2011 at 2:48 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> On 17 May 2011 23:10, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> >
>> >>
>> >> But why you want to explicitly control line ends?
>> >
>> > 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.
>> >
>>
>> Is MSVC works fine with such line endings as well?
>
> 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).
>>
>> Because the main issue with line endings in C is multi-line macros i.e.:
>>
>> #define foo  line1\
>> line2 ... \
>> line3
>>
>> and if compiler don't detects line ends correctly, then you will have
>> syntax errors.
>
> 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.

yeah.. sorry i actually meant to tell that if you output a macro into
a file which has a following:
#define foo line1\<cr><lf><lf>
line2 ... \

instead of

#define foo line1\<cr><lf>
line2 ... \

or
#define foo line1\<lf>
line2 ... \

then you will have problems.
But if this a "normal" C code, putting extra line ends somewhere in
the middle of file does't causing any problems. i.e.:

void main()<cr><lf>
{

and

void main()<cr><lf><lf>
{

will be compiled absolutely identically (if we don't take a debug
information into account, of course ;).

>
>>
>> For the rest of cases, i think there is no strict dependency on that ,
>> and line ends treated just like
>> any other white-space characters (space, tab etc) without any
>> compilation issues.
>>
>> (Btw that's why i don't like a Python where white space characters are
>> used as a part of syntax,
>> because depending on running platform and which text editor you using,
>> your mileage could vary..
>> And so, instead of spending time on what you really want to do, you
>> spending time on making parser/compiler
>> to be pleased with inputs you providing. As to me this is too 70's
>> approach, but not 2010's ;) ).
>>
>> >>
>> >> Because if you do it like that its not too different to what i have
>> >> proposed: use a stream in binary mode and deal
>> >> with line ends inside VMMaker and don't bother with what
>> >> MultiByteFileStream provides in this regard.
>> >
>> > Seems to be unnecessarily reinventing the wheel.
>>
>> A kind of, but consider that for this reinvention
>> in CMakeVMMaker there are just a single method, which is responsible for that:
>>
>> fixLineEndsOf: string
>>        ^ string copyReplaceAll: String cr with: String crlf
>>
>> and of course for non-windows it has a different implementation:
>>
>> fixLineEndsOf: string
>>        ^ string copyReplaceAll: String cr with: String lf
>>
>> and then its used like this:
>>
>> write: aContents toFile: aFileName
>>
>>        "write a file to current output directory (buildDir).
>>        use line end convention appropriate for config platform"
>>
>>
>>        | bldDir |
>>
>>        bldDir := self buildDir.
>>
>>        bldDir isString ifTrue: [ bldDir := FileDirectory on: (FileDirectory
>> fullPathForURI: bldDir) ].
>>        bldDir assureExistence.
>>
>>        bldDir forceNewFileNamed: aFileName
>>                do: [:stream | stream nextPutAll: (self fixLineEndsOf: aContents) ].
>>
>>
>> This allows me to control output explicitly without relying on clever
>> logic which tries to detect line ends
>> convention based on which platform you running.
>> Because in configs i can be explicit, since i know beforehand where
>> these configs will be used - on Mac, Unix or Windows etc.
>
> As I've said repeatedly there's no need to produce anything other than lf-endings on all these platforms.
>>
>> And because you are also want to explicitly use lf, i think that
>> reinvention which takes 1 method to implement is worth it,
>> because it providing certain guarantees of what output you will get
>> and be future-proof, no matter what 'improvements'
>> we will have in this area tomorrow :)
>> And i think you already spent more time on it, trying to fit VMMaker's
>> feets into new shoes, while you can spend time
>> to simply implement 1 method and be done with it :)
>
> 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.
> .

Yeah. No problem. Just as a remark: i were forced to do that, because
i cannot rely on flaky stuff, because even if today i will fix that in
one image, it doesn't means that this fix will automagically and
instantaneously spread over all VMMaker images over the world. And to
ensure correct behavior, i had to do it like that.



-- 
Best regards,
Igor Stasenko AKA sig.