Something came to my mind.

Considering

  1) POV4 will be as close as possible to current POV,
  2) new syntax might have some (simplified) Java features,
  3) separation between front-end and back-end should be kept,
  4) need for JIT and user-callable code from within the renderer
  5) portability concerns through platforms and OSes
  6) other items evocated in the discussion

I had one thought: why not compile SDL into Java code, with runtime classes
and shipped-in POV4 stuff (like we have now with POV), and control the
generation process by the front-end, so that it is quick and transparent to
the user?
Generating Java from new SDL should be VERY simple provided we have smart
runtime classes.

If we organise and define things properly (POV4 syntax <--> Java classes,
runtime, renderer data structure&API), it would not be so much more
complicated from what we have today (even less if we are smart), but it
opens to new possibilities.

Instead of words, here is a diagram I made quickly in order to illustrate
the global approach related with this concept. It is just a sketch, nothing
more.

Bruno.

Post a reply to this message

Attachments:
Download 'pov4arch.jpg' (173 KB)

Preview of image 'pov4arch.jpg'

"Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:
> I had one thought: why not compile SDL into Java code, with runtime classes
> and shipped-in POV4 stuff (like we have now with POV), and control the
> generation process by the front-end, so that it is quick and transparent to
> the user?

well, I guess if we can ship a JVM with povray or expect the user to have it
installed, my crazy idea of shipping GCC with povray or expecting the user
to have it installed would be acceptable as well.

And we'd even economize one step, as in:
SDL -> C -> native code interfacing with native povray binaries

rather than:
SDL -> Java -> bytecode -> JNI calls to native code...

but I still guess we're pulling ourselves ahead of our times since, while
discussing SDL possibilities is nice, we have first to code infrastrucure
in C/C++ to handle it...

Post a reply to this message

nemesis wrote:
> "Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:
>> I had one thought: why not compile SDL into Java code, with runtime classes
>> and shipped-in POV4 stuff (like we have now with POV), and control the
>> generation process by the front-end, so that it is quick and transparent to
>> the user?
> 
> well, I guess if we can ship a JVM with povray or expect the user to have it
> installed, my crazy idea of shipping GCC with povray or expecting the user
> to have it installed would be acceptable as well.
> 
> And we'd even economize one step, as in:
> SDL -> C -> native code interfacing with native povray binaries
> 
> rather than:
> SDL -> Java -> bytecode -> JNI calls to native code...
> 
> but I still guess we're pulling ourselves ahead of our times since, while
> discussing SDL possibilities is nice, we have first to code infrastrucure
> in C/C++ to handle it...
> 
> 

Better yet, Lets get a fully-working released copy of 3.7 first, the 
start discussing 4.0 ... No use in speculating a future long-off version 
of POV-Ray..

Post a reply to this message

"nemesis" <nam### [at] gmailcom> wrote:
> "Bruno Cabasson" <bru### [at] alcatelaleniaspacefr> wrote:
> > I had one thought: why not compile SDL into Java code, with runtime classes
> > and shipped-in POV4 stuff (like we have now with POV), and control the
> > generation process by the front-end, so that it is quick and transparent to
> > the user?
>
> well, I guess if we can ship a JVM with povray or expect the user to have it
> installed, my crazy idea of shipping GCC with povray or expecting the user
> to have it installed would be acceptable as well.
>
> And we'd even economize one step, as in:
> SDL -> C -> native code interfacing with native povray binaries
>
> rather than:
> SDL -> Java -> bytecode -> JNI calls to native code...
>
> but I still guess we're pulling ourselves ahead of our times since, while
> discussing SDL possibilities is nice, we have first to code infrastrucure
> in C/C++ to handle it...

Thinking of what we have today at our disposal that allows OO, modularity,
bytecode, JIT, callable user code from within the renderer, script syntax
simplicity, ease of writing a parser for it, add & enhance  features,
cross-platorm (develop and execute), cross-OS, debuggable SDL, etc ...
without re-inventing all from scratch, and that is mature enough to ensure
perennity and long-term health, I found that Java was a good thing to think
with, and could be involved in the new SDL.

Java is mature, popular, so the developpers of this new SDL would be in a
well known world, and it is likely to be a good intermediate between SDL
and the rendering engine (which does not really cause problems to develop
and optimize for speed, whatever rendering feature is implements). Our
concern is not the renderer, but the langage and related aspects.

I sketched this idea to show how Java could be utilized, and this sketch
might be re-worked several times. It was just a "pop-up". As it is on the
picture, it can implement the main features that were discussed so far. I
am still convinced that this solution/approach, or something equivalent,
can achieve what we want, and lead to a nice, simple, effective,
user-friendly, flexible SDL, compatible with current syntax, but opening
new perspectives.

If we want this new SDL, we have to collect and mix ideas, try to extract
what can be kept, and mature all this in order to get something acceptable.
The sooner we begin, the better.

Are there people here that know about development processes, software
industry know-how, or whatsoever? Their advise could be useful.


Bruno.

Post a reply to this message

Le 04.10.2007 21:48, Bruno Cabasson nous fit lire :
> If we want this new SDL, we have to collect and mix ideas, try to extract
> what can be kept, and mature all this in order to get something acceptable.
> The sooner we begin, the better.
> 
> Are there people here that know about development processes, software
> industry know-how, or whatsoever? Their advise could be useful.

Ok... I am. And I'm opening my big mouth now.
And, IMHO, everybody is going mad about the "new" SDL without
thinking about the basic architecture or defining the quality
criteria they should first have for such a project.

Allow me an image, that just looks like a group of teenagers ready
for a party: everybody is playing "I have a bigger one than you..."
game, trying to push its own way into the group without even
listening. Things might go fine, for a moment. But when trouble
happens, and it always happens, there would be nobody left to assume
the mess.

Or, if you want another picture: The CEO just get excited by the new
website technology, the flashy colours, the scrolling text around
the screen, and the so lovely puppies jumping at the bottom, chasing
the mouse pointer. He wants one too!
He does not know about its own internal business, he is the CEO, but
he wants one.
He does not know about the data-organisation, but he wants that kind
of site.
He does not which kind of resource would be needed, but he wants a
cute site.
The website is the future, no discussion, even for the business of
the CEO, which is just making nails!

Enthusiasm is a great thing. But it's dangerous.
You need to plan and design carefully your target, so that it will
cost you only twice as scheduled.
If you do not plan, you will take curves, and it will cost you a
minimal of PI instead... if you ever reach a stable target (you do
not choose it in such case).

So, what about ordering your prioriities first, using iso 9126 for
instance:
How would you order the following list ?

Functionality
Reliability
Usability
Efficiency
Maintainability
Portability

Beware, that ordering would be used later to arbitrate any decision
should a conflict occurs between them (and there is always some
conflicts, as you can not have all of them without infinite budget &
time. So, ponders wisely your decision, it is very important: do you
want to save the pregnant-mother or the soon-to-be-baby ? there is
no time for both, and it's all your choice! On one hand, it's your
wife, on the other hand, it's your blood and path to immortality...)

The ISO9126 is more detailled, spliting each lines into subgroup,
but that is just a starter.

Last question: Who is Linus Torvald here ? Just think about it for a
moment, I'm afraid we have far too more candidats and no clean
vision at all. In a business full of CEO, nothing is made as there
is no workers. That's fine for government, but not when the
objective is to produce some real value.
And all workers without a common direction are just wasting their
efforts.

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

Le Forgeron <jgr### [at] freefr> wrote:
> Le 04.10.2007 21:48, Bruno Cabasson nous fit lire :
> > If we want this new SDL, we have to collect and mix ideas, try to extract
> > what can be kept, and mature all this in order to get something acceptable.
> > The sooner we begin, the better.
> >
> > Are there people here that know about development processes, software
> > industry know-how, or whatsoever? Their advise could be useful.
>
> Ok... I am. And I'm opening my big mouth now.
> And, IMHO, everybody is going mad about the "new" SDL without
> thinking about the basic architecture or defining the quality
> criteria they should first have for such a project.
>

That's the reason why I focus my posts on the WHAT, rather than HOW. That's
the reason why I would like people to suggest some fragments of POV4 code
as they envision. This will force us to formalize the ideas that were
stated in the whole discussion so far. By confronting and assembling the
pieces of the puzzle, something can emerge.

This is a bottom-up approach for preliminary specifications (a bit like
SADT), for grossly outline the problem. In parallel, we can have a top-down
pass and think hierarchical. For that I posted earlier something about
modules and higher level control statements which will embody the rest of
the syntax, and proposed a syntax for it.

However, by posting the schema involving Java as an intermediate language
for POV4, and as an available/reliable/envisionnable solution, I tried to
address the 'HOW' (a little).

Bruno.

Post a reply to this message

Le 05.10.2007 02:05, Bruno Cabasson nous fit lire :

> That's the reason why I focus my posts on the WHAT, rather than HOW. That's
> the reason why I would like people to suggest some fragments of POV4 code
> as they envision. This will force us to formalize the ideas that were
> stated in the whole discussion so far. By confronting and assembling the
> pieces of the puzzle, something can emerge.

just make me think of a huge kitchen, full of apprentices, cooking
whatever they can put their hands on.
A decent meal might emerge... or not.
Would it be a vegeterian meal ?
A kosher meal ?
An hallal meal ?
A festive meal ?
A diabetic meal ?
A memorable meal ?

Is mixing tomato with almond a good idea ? Salmon & Beef in the same
plate ?
Duck in pasta ?

>>In a business full of CEO, nothing is made as there is no workers.
>> And all workers without a common direction are just wasting their
efforts.


> 
> This is a bottom-up approach for preliminary specifications (a bit like
> SADT), for grossly outline the problem. In parallel, we can have a top-down
> pass and think hierarchical. For that I posted earlier something about
> modules and higher level control statements which will embody the rest of
> the syntax, and proposed a syntax for it.

Gluing together the back of a horse and of an awk does not make a
pegasus.
The design-by-committee is not that far away. But it's not the worst
anti-pattern active for the time being for povray 4.


> 
> However, by posting the schema involving Java as an intermediate language
> for POV4, and as an available/reliable/envisionnable solution, I tried to
> address the 'HOW' (a little).

Yep, you get your hands on some sugar, rice, eggs, salmon and cheese.
I'm not sure it will give an edible meal for the big guys in the
dining room.

For the time being, jumping in the 4.0 madness is not the thing to
do. If you have some spare energy, I would recommend joining the 3.7
testing group. The sooner 3.7 is out, the sooner you will be able to
push again for that 4. And the more tested 3.7 is before final, the
better!

And in the meantime, you can always orders the quality criteria from
my previous post, and try to get a consensus on your order.

(the people next to you just get their hands on some anchovies...
and some chili sauce...)
-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

"Le Forgeron" <jgr### [at] freefr> wrote in message 
news:47066744$1@news.povray.org...

   You've made me hungry!   ;)

      ~Steve~

Post a reply to this message

On Thu, 04 Oct 2007 08:38:48 -0400, Bruno Cabasson wrote:

> 
> I had one thought: why not compile SDL into Java code, with runtime
> classes and shipped-in POV4 stuff (like we have now with POV), and

Sure, let's throw in some fortran and AP and basic just for
completeness.  let's make povray 4 overcomplicated and
overlarge.  Let's do it!

Post a reply to this message

Unknown <spa### [at] morepsamorg> wrote:
> On Thu, 04 Oct 2007 08:38:48 -0400, Bruno Cabasson wrote:
>
> >
> > I had one thought: why not compile SDL into Java code, with runtime
> > classes and shipped-in POV4 stuff (like we have now with POV), and
>
> Sure, let's throw in some fortran and AP and basic just for
> completeness.  let's make povray 4 overcomplicated and
> overlarge.  Let's do it!

Absolutely not! I don't think that, with Java as intermediate language, the
development of POV4 would be that complicated. Perhaps on the contrary:
writing a parser would be quite easy, as well as the related code
generator! However, POV4 will have enhanced features, will have more
completeness, and therefore its developement might imply a little
complexity. So what? It makes no problem to me. We can envision more
complexity in POV4's developement process, whatever solution we implement,
provided we keep it not too voluminous AND easy to use.

Java as an intermediate language was just an idea that came to me because it
has interesting features, well mastered, available, perenial, etc ...

What is important now is to define the new syntax and focus on it: what
features for POV4, and how to express them with the syntax? That's what I
am trying to do, and submit actual fragments of code. Everybody wants
something new, but only a few proposed something significant. (BTW: waiting
for criticisms ...)


Bruno

PS#1: Concerning FORTRAN: Not suitable to write the parser/compiler, of
course! BUT:
Many people are demanding 'more speed, more speed'. I can assure you that
Fortran is still the best solution for computational efficiency in
number-crunching applications. Since Fortran90, the language is very easy
to code, benefits of the best scientific libraries ever and it has a
vectorised nature which matches that of a renderer, and the compilers are
f... optimized and processor-efficient. I can assure you that Fortran is
still a major language in the industry and in labs. Disregarding it would
be a mistake in some cases. It is quite specialized, but isn't it a good
thing for our purpose? Fortran can be considered for the core part of
renderer. The renderer could be designed with a vectorized nature:
ray-tracing is, obviously to me, very SIMD. What language would allow to
match that better?


PS#2: I prefer contructiveness to sarcasms. Btw, were you ever involved in
large projects, involving tens and tens of people, 300000+ lines of code
and all what that implies? The development aspects of POV4 should not be
neglected, or it might get lost in a dead end if we don't pay attention to
that.

Post a reply to this message