Hi Tom,

Tom Melly wrote:

> Hmm, that's okay, but this version fails without a comma (e.g. ",1,2,\n")
> 
This is because a line-feed is not counted as an item separator, only commas are.


Bye for now,
	Mike Andrews.

Post a reply to this message

On Mon, 07 Jan 2002 10:41:01 +0000, Michael Andrews <M.C### [at] readingacuk>
wrote:
> > Hmm, that's okay, but this version fails without a comma (e.g. ",1,2,\n")
> 
> This is because a line-feed is not counted as an item separator, only commas are.

But why you need separator after third component when you end reading at this
third component ? "\n" is only white space.

ABX

Post a reply to this message

"Michael Andrews" <M.C### [at] readingacuk> wrote in message
news:3C3### [at] readingacuk...
> Hi Tom,
>
> Tom Melly wrote:
>
> > Hmm, that's okay, but this version fails without a comma (e.g. ",1,2,\n")
> >
> This is because a line-feed is not counted as an item separator, only commas
are.
>

Hmm, yes I realise that - all I can say is that I have never come across a
scripting lang. that behaves in this way. Could someone confirm that this is the
way that POV is meant to behave. If it is, then I would suggest some
clarification in the docs, since this will confuse Perl users for a start....

Post a reply to this message

news:pbvi3uomd9n7427fp390jbr9mpvmsqjutg@4ax.com...
>
> But why you need separator after third component when you end reading at this
> third component ? "\n" is only white space.
>

It would appear that in some ways POV is behaving as though it is globbing the
whole input file in one operation, and yet it isn't. Could someone confirm that
this is the intended behaviour?

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3c3ac7f4$1@news.povray.org...

<snip>

Hmm, no further comment. Anyone want to confirm whether this is a bug or not?

Post a reply to this message

Hi Tom,

Tom Melly wrote:

> 
> Hmm, no further comment. Anyone want to confirm whether this is a bug or not?
> 

Well, it seems to be doing exactly as it should, to me.

Outputting lines 3 & 4 of your test code 'nothing.txt' is

"hello",1,2,
"hello",1,2

which is read correctly.

With lines 2 & 4 you get

"hello",1,2
"hello",1,2

which causes a parsing error when it tries to read the second "hello" 
because it is not preceded by a comma.

So IMHO this works as given in the documentation (ss6.2.3.3).

Bye for now,
	Mike Andrews.

Post a reply to this message

On Thu, 10 Jan 2002 13:58:24 +0000, Michael Andrews <M.C### [at] readingacuk>
wrote:
> So IMHO this works as given in the documentation (ss6.2.3.3).

I have rechecked all scripts from this thread and all works for me as expected,
but I remember there was something wrong imo.

Btw: there is general rule that commas are optional but it probably applies only
to script.

ABX

Post a reply to this message

"Michael Andrews" <M.C### [at] readingacuk> wrote in message
news:3C3### [at] readingacuk...
> Hi Tom,
>
> Well, it seems to be doing exactly as it should, to me.
>

Well, it's counter my experience with other scripting langs, where separate
line-reads do not affect each other, but it is fine.

My only reason for raising this is:

a) is this what was intended?
b) if so, could the docs be clarified?

<snip>

>
> So IMHO this works as given in the documentation (ss6.2.3.3).
>

The trouble with the doc. is that it only gives a one-line example (with no
comma at the end of the line, since it is not required with a one-line file).

IMHO if the following was added to the descrip:

Note that data read by the #read directive must have comma delimiters between
values [ (even when a newlines separates the values, with each line processed by
a separate call to #read) ]

things would be a little clearer.

Post a reply to this message

In article <3c3db3a9$1@news.povray.org> , "Tom Melly" <tom### [at] tomandlucouk>
wrote:

> Note that data read by the #read directive must have comma delimiters between
> values

I think it is really perfectly clear already.  It does not imply a newline
substitutes a comma in any way, nor does it suggest commas are optional.  To
the contrary, it says "must have", which could not be more obvious, at least
to me.

IMO the problems arise because you make some assumptions that it would work
like some other program despite the manual never saying it does and clearly
stating the opposite.  The manual cannot cover for the behavior of other
programs.  In this place it can only give a concise description of what
POV-Ray expects, and I think it does a good job.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3c3dc4c7@news.povray.org...
>
> I think it is really perfectly clear already.  It does not imply a newline
> substitutes a comma in any way, nor does it suggest commas are optional.  To
> the contrary, it says "must have", which could not be more obvious, at least
> to me.
>

You misunderstand - it isn't that I think newlines should work as well as a
comma - rather that I expected #read to process each line as a separate
operation (and therefore not care whether the preceding line had a comma or
not).

> IMO the problems arise because you make some assumptions that it would work
> like some other program despite the manual never saying it does and clearly
> stating the opposite.  The manual cannot cover for the behavior of other
> programs.  In this place it can only give a concise description of what
> POV-Ray expects, and I think it does a good job.

It doesn't state the opposite - it makes no reference to multi-line i/o at all.
All the examples deal with a single line. Still, you are correct, I made an
assumption. If I am the only one likely to make such an assumption, then the
docs do not need clarification.

Post a reply to this message