andrel <a_l### [at] hotmailcom> wrote:
> My suggestion for a 'new' language would be to have an as simple as 
> possible language (without loops and control structures)

  Bad idea. The new language should be more powerful, not less.

  For example, I envision that with the new language you could, for example,
create a function which opens and parses a JPEG2000 file and returns an
image map from it. Or that you could create render-time code with it (like
shaders and such) as well as post-processing code (which could very well
benefit from things like loops and control structures).

  The current user-defined functions are a step towards this goal (after
all, they can be evaluated at render-time, and you can even create loops
with them).

-- 
                                                          - Warp

Post a reply to this message

andrel wrote:
> My suggestion for a 'new' language would be to have an as simple
> as possible language (without loops and control structures) that
> is easy to parse for a machine but not necessarily for a human.
> Plus an easy way to integrate that with a front end, one of those
> should be a pov 3.6 style language. Or perhaps as the only front
> end, because if everybody can make his own language we may not be
> able to share our sources.

This would COMPLETELY DESTROY the way this community works. The language 
*must* be human-friendly.

===> Machine friendly scenario:
An advanced user would bypass the 3.6-like front end and create his own 
front-end which produces non-human-friendly code. The 3.6-like front-end 
would only be used by beginners.

A beginner asks, "How do I create an oriented area-light?"
The advanced user (ignorant of 3.6-like front-end) replies:
<start non-friendly code>5d$#34gs#$%3gf3$%$#</end>

===> Human friendly scenario:
An advanced user may write his own front-end, but that front end would 
communicate with the renderer in a human-friendly language. Users of all 
levels would be familiar with this human-friendly language.

A beginner asks, "How do I create an oriented area-light?"
The advanced user replies:
light_source { .....

  -Shay

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
>
> My suggestion for a 'new' language would be to have an as simple as
> possible language (without loops and control structures) that is easy to
> parse for a machine but not necessarily for a human. Plus an easy way to
> integrate that with a front end, one of those should be a pov 3.6 style
> language. Or perhaps as the only front end, because if everybody can
> make his own language we may not be able to share our sources.


I've used povray in the office to do some image processing of a sort that
was not available in any commercial software I know of.  I hand-coded the
routine in SDL.  I've also taken great joy in coding projects for fun like
flocking algorithms and a car race with AI drivers.   Need loops for that.


As to Chris' statement about the future license.  First of all, I say thanks
for all you have done-- I understand you're trying to avoid legal problems
associated with code contributed from folks who are no longer active on the
team.

But I'm surprised that you appeared to be more worried about OSI than GPL3.
Right now, some linux distros turn their nose at the current license, and I
thought you were already OSI-approved. Now I'd respect your choice either
way, but wondering why you'd strive for OSI if GPL3 were in the bag. As far
as "acceptance," wouldn't GPL3 suffice?
thanks.

Post a reply to this message

in news:46E### [at] hotmailcom andrel wrote:

> My suggestion for a 'new' language would be to have an as simple as 
> possible language (without loops and control structures) that is easy
> to parse for a machine but not necessarily for a human.

The one doesn't exclude the other imo. You could have a language that is 
easy for humans, preferably even easier than the current SDL. You can 
write in this language from any other language, as I do with Python and 
you with matlab. Now give this new, or even the current SDL the ability to 
rewrite itself, by unrolling all loops and structures (kinda parsing) and 
you have your machine version.

Eventhough we're talking about a raytracer, where every bit of speed is 
still essential, I'm happy with offering some of this speed to a human 
readable language.

Ingo

Post a reply to this message

Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> My suggestion for a 'new' language would be to have an as simple as 
>> possible language (without loops and control structures)
> 
>   Bad idea. The new language should be more powerful, not less.
> 
A small misunderstanding, I guess. What I proposed was to have a well 
defined low level language (think RISC) and on top of that a very user 
friendly one that directly communicates to the backbone.
That would separate the POV design into two more or less disjunct 
concerns. One with a focus on low level features and one with a focus on 
a user friendly interface. It is my experience that the set of people 
that are able to solve difficult mathematical problems and are able to 
implement those (provable) bugfree and understand the subtleties of 
language design is almost empty.
>   For example, I envision that with the new language you could, for example,
> create a function which opens and parses a JPEG2000 file and returns an
> image map from it. Or that you could create render-time code with it (like
> shaders and such) as well as post-processing code (which could very well
> benefit from things like loops and control structures).
> 
>   The current user-defined functions are a step towards this goal (after
> all, they can be evaluated at render-time, and you can even create loops
> with them).
>

Post a reply to this message

andrel wrote:
> A small misunderstanding, I guess. What I proposed was to have a well 
> defined low level language (think RISC) and on top of that a very user 
> friendly one that directly communicates to the backbone.

Perhaps something like a well-defined byte-code interpreter is what you
mean? With calls that allow access to all of the ABI?

I'd already raised the issue that I felt that a byte-coded (or JIT'd) back-
end to any SDL was necessary for speed. If this was exposed and formally
documented then, firstly, more or less any language could be used with it
(assuming someone wants to write the translator), and secondly, portability
is at least vaguely possible by providing a reverse-compiler that outputs
some form of 'standard' SDL (whatever we end up calling 'standard' is up to
question of course).

This wouldn't be ideal for portability as you'd lose comments and the code
may be unreadable (especially if the front-end optimized it), but it's
possible it's better than nothing.

Note I am not necessarily advocating doing this: I am merely pointing out
that it is possible.

-- Chris

Post a reply to this message

gregjohn wrote:
> But I'm surprised that you appeared to be more worried about OSI than GPL3.

Where do you get that from?

> way, but wondering why you'd strive for OSI if GPL3 were in the bag. As far
> as "acceptance," wouldn't GPL3 suffice?

IIRC this is exactly what I said.

-- Chris

Post a reply to this message

Chris Cason wrote:
> Warp wrote:
> 
>>  Does this mean that 4.0 will *not* have any kind of revised SDL language?
> 
> 
> I have to be realistic here and take the approach that attempting to write a
> new SDL prior to releasing the tree for folks to work on would not be
> practical. On the other hand, the existing parser has to be replaced since it
> is fairly cumbersome and hard to maintain.

How hard would it be to separate the parser and the renderer as much as 
possible, and thereby allow for both a parser based on the current SDL, 
and another parser based on an entirely different SDL (as well as a 
rendering engine that is not primarily a ray-tracer)?

Regards,
John

Post a reply to this message

gregjohn wrote:
> But I'm surprised that you appeared to be more worried about OSI than GPL3.
> Right now, some linux distros turn their nose at the current license, and I
> thought you were already OSI-approved. Now I'd respect your choice either
> way, but wondering why you'd strive for OSI if GPL3 were in the bag. As far
> as "acceptance," wouldn't GPL3 suffice?
> thanks.

OSI is a non-profit institution that owns the phrase "Open Source". If 
they "like" your license, then you can call your program Open Source. 
The current POV license does not meet the OSI's criteria to be called 
Open Source.

GPLv3 has not yet received the OSI's approval as an Open Source license, 
but it's pretty much a given that it will. The first two versions of the 
GPL, along with the BSD license (and possibly the MIT license), were 
what pretty much defined Open Source in the first place.

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you start wishing you were 
actually in that futuristic mandelbrotian landscape you just rendered.
     -- fish-head

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> andrel wrote:
> > My suggestion for a 'new' language would be to have an as simple
> > as possible language (without loops and control structures) that
> > is easy to parse for a machine but not necessarily for a human.
> > Plus an easy way to integrate that with a front end, one of those
> > should be a pov 3.6 style language. Or perhaps as the only front
> > end, because if everybody can make his own language we may not be
> > able to share our sources.
>
> This would COMPLETELY DESTROY the way this community works. The language
> *must* be human-friendly.

I second that.  So far, I've not seen any other renderer out there with such
friendly and easy-going DSL like povray's SDL.  I hate the XML or structured
ones with no loops or conditionals.

I like Warp's proposal for Lua as the embedded language.  The language has
many strong points going for it, including being free software (MIT
license), easy integration to C/C++ code, simple, friendly syntax, powerful
and flexible constructs, and offers a very lightweight and fast interpreter.
 It even features the infamous tail call optimization from functional
languages!  Seems to have learned a lot from past Scheme, Tcl and Forth
experiments...

and last but not least, it was developed here in Brazil... :)

Post a reply to this message