 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
AngleWyrm <no_### [at] hotmail com> wrote:
> oneVal, twoVal, threeVal, dummyVal
> oneVal, twoVal, threeVal
> oneVal, twoVal, threeVal
> and the resulting *.csv file will have trailing commas. Then delete the
> dummyVal from the first row of the file.
I think that if "dummyval" is "//" then you don't even need to remove it.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:401a3011@news.povray.org...
> AngleWyrm <no_### [at] hotmailcom> wrote:
> > oneVal, twoVal, threeVal, dummyVal
> > oneVal, twoVal, threeVal
> > oneVal, twoVal, threeVal
>
> > and the resulting *.csv file will have trailing commas. Then delete the
> > dummyVal from the first row of the file.
>
> I think that if "dummyval" is "//" then you don't even need to remove
it.
I think that this is rather an extra bunch of pre-processing data, that
could be avoided if the end-of-line character were recognized as a valid
data separator. How often is the end-of-line character used as part of a
variable? Most likely only in binary files, not in comma separated files.
I would like to find the source file, and see if I can maybe customize it to
recognize eol markers, but the guys in the programming group keep saying "go
away". Does anyone here know where the parser for file input is located?
Which source file?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:401a2a16$1@news.povray.org...
> "Thorsten Froehlich" <tho### [at] trfde> wrote in message
> news:40192e8c$1@news.povray.org...
>
> > But the problem is not with newlines! POV-Ray does not care about
newlines.
>
> This has come up before - the problem is that it's a common assumption
that a
> newline will regarded as a value seperator. While it would be unreasonable
and
> absurd to list everything that Pov doesn't do in the docs*, this might be
a
> valid exception....
It's also a common assumption that a tomato is a vegetable; but where do the
grocery stores sell it? Where everyone expects to find it, with the
vegetables. Same goes for word meanings--they mean what we agree they mean.
All I'm saying is that if it is a common 'mis-conception' maybe the
definition could be shifted over a little to include that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
AngleWyrm <no_### [at] hotmailcom> wrote:
> I think that this is rather an extra bunch of pre-processing data, that
> could be avoided if the end-of-line character were recognized as a valid
> data separator.
But the thing is that POV-Ray does not read data files. It reads
POV-Ray SDL files which contain items separated by commas. It's not
much different from what you have between parentheses in a macro
call (ie. for example FancyMacro(1, 5*8-1, <1,5,2*3>)).
If the newline character was an alternative character for item separator,
then each item must be written completely in one line. If the item is
a very long statement that can be unreasonable. It's the same as if
when calling a macro you could not split a parameter into several lines
if the parameter is a very long expression.
POV-Ray reads and interprets the input file in a very versatile way.
It can contain much more than just numbers, vectors and strings. It
can contain variables, expressions and even #declares etc.
Making the input file to be a plain data file which is not interpreted
in any way would be a downgrade.
And besides, if the newline character was an item separator, how
several empty lines should be handled?
> How often is the end-of-line character used as part of a
> variable?
But it can be used as a part of an expression.
> I would like to find the source file, and see if I can maybe customize it to
> recognize eol markers
You would be downgrading the versatility of the #read command. You would
have to turn off almost all interpretation of the input data, which would
break many things badly.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <401aeca9@news.povray.org>, war### [at] tagpovrayorg says...
> You would be downgrading the versatility of the #read command. You would
> have to turn off almost all interpretation of the input data, which would
> break many things badly.
>
Just my own 2 cents, but A) if you can't get it to do what you want, how
is that versatile? and B) last I checked #read is used for pulling in
data from a file, not SDL, which is more normally included with and
'include' directive.
What you seem to be implying is that both the SDL parser and the #read
command use the same system to retrieve data and that because of this it
ignores the rules used by probably 90% of all programs, which nearly
universally consider newlines as a break in the data. Now, if this was
BASIC, I would shrug my shoulders and use a 'lineinput' command, then
something else to split the line into the correct data. However, your
'versatile' command can't do that either. The reality is it works one way
and one way only, and the way it works is broken for the output of most
programs you want to use it with. Unlike AngleWyrm though, I think a
better solution is some sort of line-input type command that will
actually read only up to the break. Combined with something like the
split command most languages have, you could break each such line up any
bloody way you want.
Versatility implies the ability to deal with *any* data, not just the
stuff you think everyone should be using imho.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sha### [at] hotmailcom> wrote:
> Just my own 2 cents, but A) if you can't get it to do what you want, how
> is that versatile?
I can't get POV-Ray to play me "happy birthday" from my soundcard, but
that doesn't mean POV-Ray's scripting language is not versatile.
The "PCM4" format is an example of this versatility: I can very
easily include textures in the pcm file thanks to it.
> and B) last I checked #read is used for pulling in
> data from a file, not SDL, which is more normally included with and
> 'include' directive.
Then check again. You can for example put a #declare in the input
file and POV-Ray will interpret it correctly.
> What you seem to be implying is that both the SDL parser and the #read
> command use the same system to retrieve data and that because of this it
> ignores the rules used by probably 90% of all programs, which nearly
> universally consider newlines as a break in the data.
How many programming languages can you mention which consider newline
as some kind of separator which is different from a space in their input
language?
Does a HTML browser consider a newline in a HTML file as some kind of
separator different from a space?
I wouldn't call it a "universal" fact that a newline character is a
separator in a data file.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:401c44b8@news.povray.org...
>
> How many programming languages can you mention which consider newline
> as some kind of separator which is different from a space in their input
> language?
> Does a HTML browser consider a newline in a HTML file as some kind of
> separator different from a space?
I just want to point out that a newline, and a space and a tab, also are
considered "whitespace", and that they are almost always treated as data
separators. The only exception to this that I know of is in the case of
quoted text, which is usually treated as a literal string.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <401c44b8@news.povray.org>, war### [at] tagpovrayorg says...
> Patrick Elliott <sha### [at] hotmailcom> wrote:
> > What you seem to be implying is that both the SDL parser and the #read
> > command use the same system to retrieve data and that because of this it
> > ignores the rules used by probably 90% of all programs, which nearly
> > universally consider newlines as a break in the data.
>
> How many programming languages can you mention which consider newline
> as some kind of separator which is different from a space in their input
> language?
> Does a HTML browser consider a newline in a HTML file as some kind of
> separator different from a space?
>
> I wouldn't call it a "universal" fact that a newline character is a
> separator in a data file.
>
Ok.. The key word here is *DATA*. I was not aware that the #read
directive was intentionally design to also execute code if found. This is
imho not a good thing if your intention is, for instance, to read in SDL
and feed it to part of the script as text, in order to render an overlay
of the SDL on top of the scene it generates. In other words, take a
template scene and add something to the end:
#version 3.5;
#include "colors.inc"
global_settings {
assumed_gamma 1.0
}
// ----------------------------------------
camera {
location <0.0, 0.5, -4.0>
direction 1.5*z
right x*image_width/image_height
look_at <0.0, 0.0, 0.0>
}
{snip...}
// Add in here code that uses #open and #read to pull in *this* file and
// generate text overlayed on top of the rest of the image.
Ooops! If #read automatically interprets everything that is SDL as code,
then this is literally impossible. And even if it somehow worked, you
can't make it read in one line at a time, so POV-Ray would produce lines
of text that are 'its' interpretation of how all the bits fit together,
not the original contents.
Tell me again how this is good? If I want to read in *data* the result
must arrive in the same condition it was stored. If I want to read SDL,
then #read's behaviour makes sense. The two are completely different
situations and therefor #read does not and cannot provide an effective
and universal solution for both. While dumping the SDL as text over top
of the scene is a more extreme example, it is exactly the same situation
as AngleWyrm is talking about. The contents of the file need to be read
in something approximately identical to how something else output them,
without accidentally or intentionally trying to interpret it as something
completely different than the user intends.
As for the idea that is isn't a universal fact that newline is a data
separator. Maybe not universal, however most databases export individual
records with comma delimited fields, but use the newline to seperate
Individual records. A lot of 3D packages also output data with each
individual object, triangle, etc. on its own line. The data for each
object is comma delimited, but the objects themselves may use newlines to
separate them. There are far more cases of this than there are of
programs that dump everything into a file with commas between both
individual data elements and each record. I certainly don't know of any
that I use which behaves the way POV-Ray would expect them to.
The fact is that data may not always have the same number of fields for
each record. So.. You can't just read 3 values, and repeat. Having a way
to use a linefeed as a break is more practical. Even when this is not
true, you would still need to feed any data files that don't conform
through a program that just tacks on an extra ',', or in the case of my
above SDL example, actually generate a separate text file, with every
damn line altered by adding quotes and a comma. Ooops again! That won't
work for any SDL or other files that already contain quotes of any
kind...
Fact is: #read cannot and will not provide a universal method for
retrieving data. It assumes things for the user than the user does not
intend, want or can in many cases even use. This would no doubt be a real
winner for a Microsoft product. They excel at making things that think
for the user, instead of doing what the user actually wants. However it
shouldn't imho be the only way to read data from a file in POV-Ray.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott <sha### [at] hotmailcom> wrote:
> Ok.. The key word here is *DATA*. I was not aware that the #read
> directive was intentionally design to also execute code if found.
I don't know if the #read command was *intentionally* made so that
it can also interpret SDL script. However, this side-effect is useful.
I should specify more clearly what #read does. What I said earlier
may be understood wrongly.
#read expects to find floats literals, vectors (containing literals)
and strings in the input file. The data it will read into the given
identifier needs to be a literal.
However, if while searching for such literal it finds a #-command
(such as #declare) the parsing engine will interpret that.
That is, suppose you have this in your data file:
1,
#declare Var = 5;
2
When you read one item with #read, then '1' will be assigned to the
identifier given to #read and that's it. However, after you read the
next item, '2' will be assigned to the given identifier, but as a
"side-effect" the identifier 'Var' will have the value 5.
This is actually extremely useful. We have used this feature in
the new PCM file format supporting uv-coordinates and textures:
The PCM file can have a declared array containing the textures and
thanks to this property the textures can be used in the PCM macros.
Removing this feature would be a major drawback for the format.
I agree, however, that #read is a bit inconsistent on how it
handles certain things in the input.
For example if you have this in your input file:
1+2, 3+4
then #read will not read the values '3' and '7', nor will it issue
an error message.
This might be something to develop further to either direction.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <401d72cd@news.povray.org>, war### [at] tagpovrayorg says...
> Removing this feature would be a major drawback for the format.
>
I can see it being useful and I don't suggest myself that it should be
removed. However, I wouldn't mind seeing a new command of some sort that
does treat the contents of a file as raw data, instead of trying to
interpret it. There are script languages that do something similar, but
they provide a means to read code *or* data. Currently POV-Ray only does
interpretation and it is the one which tends to be convenient only if you
are aware of the oddity and how to use it.
It is definitely an interesting quirk though.
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
