In article <38cc2ddc$1@news.povray.org>, "Johannes Hubert" 
<jht### [at] mailacom> wrote:

> No, what I mean is this: Don't interfere with the POV-parser at all,
> just at the very first function call, where the POV-parser is initially
> called:
> Here, insert a call to your own parser code which pre-translates the
> code it reads from the input file *before* passing it to the standard
> POV-parser.
> For this, you can leave the POV-parser totally alone.
> This is also why I mean that blending C and C++ isn't too hard: Between
> your code and the rest of the POV code there would be only one single
> function call to a global function in your module, which is passed the
> current script as a parameter, and which returns the same script, but
> with all CSDL blocks replaced by their POV equivalents.

Ah, I see what you mean now. My module would be called whenever a source 
file is opened. It would probably be possible to cache the translated 
files in case one is included multiple times(per parse, that is. I don't 
think caching from render to render would be easy.), so it doesn't have 
to be translated for every time it is included.


> Probably the best step is to do a separate tool like you are planning
> now, and see how it gets accepted. If people like it, integrating it
> into a POV patch (the mega-patch?) would be a great idea, I think.

Yes, that sounds like what I have been thinking of. 


> This is an interesting project. I would be happy to offer any help I can
> give (both in the language design and/or programming).

I will post a "concept sketch" of the language design in a few minutes. 
It is incomplete, but should give an idea of what I am thinking.
I have never written a parser before, so that might be a little 
difficult(well, a simple keyword-value thing, but that doesn't really 
count). But I guess I have to learn sometime... :-)
I do have a couple ideas about parsing the language, I think it would be 
easiest to parse the scene into a data structure and then have the data 
structure output the POV code for each scene element.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

It is perfectly possible to link C object files and C++ object files as long
as they are defined in the right way.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <38ccd3af@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

>   It is perfectly possible to link C object files and C++ object files as 
> long as they are defined in the right way.

I know, but it would be easier to develop the translator as a separate 
program. That way I could have faster compile times, a specialized 
interface for testing various portions, and I could directly see the 
output translation. Both writing and testing would be faster.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Hello,

Nieminen Juha wrote:
> 
>   Well, I personally don't like Java.
>   A C++-binding would be more pleasant to me.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

I agree, I' also would prefer a C++binding, because I hate Java (don't
ask why).

Yours Axel Baune

Post a reply to this message

Hi,

Chris Huff wrote:
> 
> In article <38CBA3C0.3254B378@pacbell.net>, lin### [at] povrayorg
> wrote:
> 
> > It would have to be in Qbasic or I wouldn't use it.
> 
> Would you use it even if it *was* in Qbasic? :-)
> 
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/

No I don't think so. 

Axel Baune

Post a reply to this message

"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-4039AC.06380313032000@news.povray.org...

> I will post a "concept sketch" of the language design in a few
minutes.
> It is incomplete, but should give an idea of what I am thinking.
> I have never written a parser before, so that might be a little
> difficult(well, a simple keyword-value thing, but that doesn't really
> count). But I guess I have to learn sometime... :-)
> I do have a couple ideas about parsing the language, I think it would
be
> easiest to parse the scene into a data structure and then have the
data
> structure output the POV code for each scene element.

Just don't reinvent the wheel!

Parsing and compiling is a well researched subject in computer science.
I recommend that you take a look at lex/yacc for example
One of the standard books is: "The Theory and Practice of Compiler
Writing" by Jean-Paul Tremblay and Paul G. Sorenson (McGraw Hill). It
covers everything you need...
(you probably have it already :)

Johannes

Post a reply to this message

Johannes Hubert wrote:

> Chris Huff made the suggestion of creating some sort of POV-CSDL ("C
> like Scene Description Language") in the thread "Programming in
> Highshool" in off-topic. That would be a language based on C or C++ to
> be used to create POV-scenes. The scene would then be run through a sort
> of "compiler" to create a "real" POV-Script from it.
> The idea was, that only the "programmers" among us would want to write
> CSDL scripts (for example for complex includes/plug-ins) and that normal
> users could simply include the produced "normal" POV-Script into their
> scenes, not having to worry about the CSDL at all - they could simply
> ignore that part.

 One thing I am slightly confused about is if you are using a complicated
scene description language to make a new scene and then convert it to
POV-Ray won't you still be limited to what POV-Ray can actually do
proceeduraly ?

 If POV-Ray can already do it proceeduraly why not do it in native Pov
in the first place ?

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38cd0388$1@news.povray.org>, "Johannes Hubert" 
<jht### [at] mailacom> wrote:

> Just don't reinvent the wheel!

What if I want to learn how to make wheels? And what if I can't find a 
wheel that fits?


> Parsing and compiling is a well researched subject in computer science.
> I recommend that you take a look at lex/yacc for example

While those might be good for people who want rapid development, I am 
not sure they would apply in my case. I do think there is a set of 
Bison/Flex(or is it Flexx?) tools for CodeWarrior, but I have never used 
that kind of thing.


> One of the standard books is: "The Theory and Practice of Compiler
> Writing" by Jean-Paul Tremblay and Paul G. Sorenson (McGraw Hill). It
> covers everything you need...
> (you probably have it already :)

Actually, I don't have it. All the books I have are a couple standard 
"learn C++" books:
Teach Yourself C++ in 21 Days(got this when I took C++ at school)
Programming with C++
Rescued by C++
C++ Primer Plus(this one is actually my favorite, I rarely use the 
others)
And a couple C and Java books, and one Pascal book(also from a class I 
took at school).

I don't have any books on algorithms or programming theory. I don't have 
much money to buy them either... :-(

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CD5D57.247F8422@pacbell.net>, lin### [at] povrayorg 
wrote:

>  One thing I am slightly confused about is if you are using a complicated
> scene description language to make a new scene and then convert it to
> POV-Ray won't you still be limited to what POV-Ray can actually do
> proceeduraly ?
> 
>  If POV-Ray can already do it proceeduraly why not do it in native Pov
> in the first place ?

POV can do these things(or fake them), but to do them while restricted 
to the POV syntax would take a long time and be nearly impossible to 
read and understand. You could write a scene in C-SDL and then convert 
to POV, but you probably wouldn't want to read the POV file, while the 
C-SDL code would be much simpler and easier to read/write. For 
programmers, at least. :-)

Another thing that could be done instead of or in combination with is 
doing most of the parsing work in the converter and outputing a bunch of 
POV objects. This would be especially useful for tree/particle system 
generators. The POV file would parse much faster than the equivalent 
generator written in POV-Script. Of course, this couldn't be done for 
most includes...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

"Chris Huff" <chr### [at] yahoocom> wrote in message
news:chrishuff_99-DBD0D6.16302013032000@news.povray.org...
> In article <38cd0388$1@news.povray.org>, "Johannes Hubert"
> <jht### [at] mailacom> wrote:
>
> > Just don't reinvent the wheel!
>
> What if I want to learn how to make wheels? And what if I can't find a
> wheel that fits?

Find a wheel that fits? Great!
Learn how to make wheels? Good idea! But best done by learning from
examples of the pros. If you can't get a book, search on the net, there
should be loads of stuff about parser and compiler writing out there.

Johannes.

Post a reply to this message