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

[Eliot Miranda]

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.


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

>
> > cheers,
> > Eliot
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110517/39be4194/attachment.htm