Hello,

for the first time I tried to use the read-directive and was heavily
disappointed as I noticed that you can nearly write everything to a file, but
are very restricted to read from a text-file. If one would have a directive like
readln in c or c++ which reads a line from a file into a string one could build
parsers only with the existing string-functions (o.k. some more convient ones
would be fine, but the existing like strlen, strcmp or concat are enough to
build macros for text exchanges, substring-detection and so on). So my question
is simple: Is it possible to implent such a feature without too much effort?

Best regards,
Michael

Post a reply to this message

MichaelJF <mi-### [at] t-onlinede> wrote:
> for the first time I tried to use the read-directive and was heavily
> disappointed as I noticed that you can nearly write everything to a file, but
> are very restricted to read from a text-file. If one would have a directive like
> readln in c or c++ which reads a line from a file into a string one could build
> parsers only with the existing string-functions (o.k. some more convient ones
> would be fine, but the existing like strlen, strcmp or concat are enough to
> build macros for text exchanges, substring-detection and so on). So my question
> is simple: Is it possible to implent such a feature without too much effort?

#read was never intended to be a raw byte input stream. Instead, it was
always intended to be used to read comma-separated lists of elements.

(There's a lesser known fact that since #read uses the SDL parser itself
to read the numbers, you can actually embed things like #declares in the
input file and they will be parsed and interpreted properly and
transparently.)

-- 
                                                          - Warp

Post a reply to this message

> #read was never intended to be a raw byte input stream. Instead, it was
> always intended to be used to read comma-separated lists of elements.
>
I can not see a reason for that. I think a feature like readln would be a bigger
improvement to POV as the sslt feature for example since you could parse files.
At the moment I use third party software for that reason (the stastistical
Software SAS which can handle this simple issues easily). Since POV is implemted
with Visual C++, as I learned, it should be very easy to fulfill my requests.

Best regards,
Michael

Post a reply to this message

MichaelJF <mi-### [at] t-onlinede> wrote:
> > #read was never intended to be a raw byte input stream. Instead, it was
> > always intended to be used to read comma-separated lists of elements.
> >
> I can not see a reason for that.

The reason is that reading a list of comma-separated values is very easy
with #read. You don't have to parse anything.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> MichaelJF <mi-### [at] t-onlinede> wrote:
> > > #read was never intended to be a raw byte input stream. Instead, it was
> > > always intended to be used to read comma-separated lists of elements.
> > >
> > I can not see a reason for that.
>
> The reason is that reading a list of comma-separated values is very easy
> with #read. You don't have to parse anything.
>
> --
>                                                           - Warp

Hm, I think you didn't understand me. I will parse everything, or better I would
like to able to. Technically I can see no reason to use the comma or the \n as
seperator. Maybe there is a problem between the operating systems. What I would
like to do is to parse scene-files, e.g. mesh2 objects, change them and write
them to disk. The latter is possible, MakeGrass or MakeClouds are wonderful
examples for this technique. So please forgive me, that I propose such an
option.

Best regards,
Michael

Post a reply to this message

MichaelJF <mi-### [at] t-onlinede> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > MichaelJF <mi-### [at] t-onlinede> wrote:
> > > > #read was never intended to be a raw byte input stream. Instead, it was
> > > > always intended to be used to read comma-separated lists of elements.
> > > >
> > > I can not see a reason for that.
> >
> > The reason is that reading a list of comma-separated values is very easy
> > with #read. You don't have to parse anything.
> >

> Hm, I think you didn't understand me. I will parse everything, or better I would
> like to able to. Technically I can see no reason to use the comma or the \n as
> seperator. Maybe there is a problem between the operating systems. What I would
> like to do is to parse scene-files, e.g. mesh2 objects, change them and write
> them to disk. The latter is possible, MakeGrass or MakeClouds are wonderful
> examples for this technique. So please forgive me, that I propose such an
> option.

I understand what you want, I was simply answering why #read was designed
as it was.

-- 
                                                          - Warp

Post a reply to this message

How about adding a #binaryread command or something, that's supplementary?

--
Tim Cook
http://empyrean.sjcook.com

Post a reply to this message

Le 19/10/2012 06:53, Tim Cook nous fit lire :
> How about adding a #binaryread command or something, that's supplementary?

what would be the usage of it ?
I mean, the SDL is able to handle floating point, vector up to 5
dimensions of floating point, and string of text (and I might be
forgetting some things like square matrix). It cannot handle a binary
blob like a PNG or JPG image or a collection of traced photons directly
(not in a generic way for more manipulation)

#write is there to help you write on the fly files (for simulation:
iteration k-1 saves its data for the next one), as well as easing export.

reading back such file with #read is an option when its content is only
a collection of numbers (which most simulation are just happy with).
more complex files might get in via #include (yes, it's perverse: you
have to spend more time in the #write part to generate a valid SDL
sub-script)

If you expect the SDL to become a multipurpose scripting facility for
importing from something else, I think you might be flogging the wrong
horse.

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 19/10/2012 06:53, Tim Cook nous fit lire :
> > How about adding a #binaryread command or something, that's supplementary?
>
> what would be the usage of it ?
> I mean, the SDL is able to handle floating point, vector up to 5
> dimensions of floating point, and string of text (and I might be
> forgetting some things like square matrix). It cannot handle a binary
> blob like a PNG or JPG image or a collection of traced photons directly
> (not in a generic way for more manipulation)
>
> #write is there to help you write on the fly files (for simulation:
> iteration k-1 saves its data for the next one), as well as easing export.
>
> reading back such file with #read is an option when its content is only
> a collection of numbers (which most simulation are just happy with).
> more complex files might get in via #include (yes, it's perverse: you
> have to spend more time in the #write part to generate a valid SDL
> sub-script)
>
> If you expect the SDL to become a multipurpose scripting facility for
> importing from something else, I think you might be flogging the wrong
> horse.

Hm, again. Now I think I had better placed this idea in the science-fiction
section (pov4.discussion.general). I sense a certain amount of hostility against
this very simple idea, I have not expected. I didn't ask for a read directive
which can accept other, more complex objects. I only asked for a directive which
implements the readln-directive of C or C++ one to one. My idea is to have a
directive like

#readln ( FileHandle, String)

which reads a text-file line by line (seperated by carriage return and/or line
feed) and put the result in a POV-String. The interpretation of the resulting
string is the job of the user alone. With having substr(), strlen(), strcmp()
and concat() handy, one has all to write a parser if one could read a file line
by line.

What could be the usage of this? A very simple example would be that you would
be able to write a POV-macro to convert wavefront-OBJ-Files to POV-mesh2-syntax
in POV itself. I will not say, that this would be an easy job, but it would be
possible. Most likely one had to process a file several times and writing
auxilliary files with the #write-directive). O.K. FlyerX gave us PoseRay which
is really a very excellent tool for this special example and gave a lot of
additional features too.  I can easily implement my issues with my SAS-Software.
But I cannot share the results with you, since most of you will be ignorant to
the existence of such a software completely. Programming POV-Code for POV-users
would solve this problem. Since every POV-user can use the SDL. So please look
beyond your own nose.

Best regards,
Michael

Post a reply to this message

MichaelJF <mi-### [at] t-onlinede> wrote:
> What could be the usage of this? A very simple example would be that you would
> be able to write a POV-macro to convert wavefront-OBJ-Files to POV-mesh2-syntax
> in POV itself.

This has been an idea for years for the hypothetical new SDL that POV-Ray
might get some day. (The idea is for the SDL to be redesigned so that,
while being at least as easy to use as the current SDL, it additionally
supports all kinds of features that would make an expressive and powerful
scripting language where doing things like making an input file parser
would be much easier than with the current SDL. Also, it would be a lot
faster than the current SDL, as it would optimally be byte-compiled.)

The current SDL is far from being optimal for that task.

-- 
                                                          - Warp

Post a reply to this message