Jeff Houck <jho### [at] northrimnet> wrote:
> Personally, I like the SDL just the way it is... Simple, mostly 
> predictable and easy to use...

  ... very limited and very slow.

  Also, from core developement point of view, it's quite horrible.
For example, why do you think there's no eval() function in POV-Ray?
That is, a function which takes a string and evaluates this string
as if it was SDL (similar to how an #include "file" would do, but
with a string instead)?
  Answer: Because the parser is a mess, full of kludges, burdened with
backwards-compatibility. For example, #macros are handy and powerful...
too powerful for their own good. #macros are one of the major reasons
why there's no eval() function in POV-Ray.

  Adding new features to the parser is a real pain sometimes (I have
recent personal experience), mainly due to how the SDL works and is
parsed. For example, being able to insert a #declare almost anywhere
may feel handy, but is a nightmare to parse properly.
  One thing I recently tried to achieve was string concatenation using
the + operator (as an alternative to the concat function). In the end
it seems that this would be really, really difficult to implement in
the current parser due to how interpreting # commands (which can appear
almost everywhere) works.

-- 
                                                          - Warp

Post a reply to this message

> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>>>   How would the average user then use those libraries from the SDL?
> 
>> He would not.  I mean : it would be transparent for the end user.
>> The "official SDL" parser will take that in charge.
> 
>   So what you are suggesting is that you can change the behavior of
> existing features but you can't add new features?

No, I'm not.

If the libraries exposes every single renderer functionnality, up to its
lowest level (such as trace a ray, get turbulence at point,...), nothing
would prevent accessing them from the SDL to create new functionality.
All I suggest here is an abstraction layer between renderer and SDL,
but no limitations of what can be done in SDL.

(I have things to add, but I must go home, more later...)

Fabien.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Bryan Valencia <no### [at] waycom> wrote:
> > This would open the doors to things like...
>
> people writing powerful libraries for POV-Ray which are not portable and
> would require for people to install development environments in their
> system just to get the thing working.
>
>   Also since the library is probably written in a language only 1% of
> POV-Ray users like, use or even understand, it would probably be pretty
> useless for almost everyone but the author himself.
>
>   The good thing about the SDL is that the only requirement to use it
> is POV-Ray. That's it.
>
> --
>                                                           - Warp


I have to completely agree with Warp.  I'd certainly write them in Scheme.
:)

Of course, it wouldn't be a problem if they were bytecompiled to some common
binary representation.

But, what really bothers me is that I'm not sure povray artists bother about
writing their own SDLs just to render a scene.  I'd be interested to see the
opinion of guys like Gilles Tran, Jaime Vives, Jim Charter, Tek and other
advanced SDL users...

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Of course, it wouldn't be a problem if they were bytecompiled to some common
> binary representation.

  A library needs an interface to be used. That can't be bytecompiled.

> But, what really bothers me is that I'm not sure povray artists bother about
> writing their own SDLs just to render a scene.  I'd be interested to see the
> opinion of guys like Gilles Tran, Jaime Vives, Jim Charter, Tek and other
> advanced SDL users...

  I'm sure they use libraries for many things.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > Of course, it wouldn't be a problem if they were bytecompiled to some common
> > binary representation.
>
>   A library needs an interface to be used. That can't be bytecompiled.

There're docs for that purpose.  And if I'm not wrong, .Net's CLR provides
that interoperation between libraries written in different languages.

> > But, what really bothers me is that I'm not sure povray artists bother about
> > writing their own SDLs just to render a scene.  I'd be interested to see the
> > opinion of guys like Gilles Tran, Jaime Vives, Jim Charter, Tek and other
> > advanced SDL users...
>
>   I'm sure they use libraries for many things.

A library is not the same as a language.  Except perhaps in the Lisp
world... :)

BTW, I replied this in the other thread, but find it relevant here too:

andrel <a_l### [at] hotmailcom> wrote:
> As you might have noticed, not everybody is convinced we should have one (SDL).

hello?!  Drop povray's SDL and povray is just among many rendering engines.
I believe to be the crown jewel of povray!

We should have one and only povray SDL and it should have easy syntax and
semantics, should be mostly declarative interspeced with a few useful
control flow commands and should be modular.  If someone wishes to program
in another language which suits his needs best, do it and create a program
in said language which compiles his scene or library to povray SDL, just
like today.

I think if povray loses its SDL, it'd lose its identity.  If it shipped just
with some sort of bytecode VM for which lots of languages could compile to,
it'd still lose its identity.

Povray needs its own unique SDL, period.

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> >   A library needs an interface to be used. That can't be bytecompiled.

> There're docs for that purpose.

  How is documentation going to help creating an interface to use a
precompiled library?

-- 
                                                          - Warp

Post a reply to this message

> "Rarius" <rar### [at] rariuscouk> wrote in message 
> news:47041646$1@news.povray.org...
>> I must admit to liking the idea of a POV library... especially a .POV. 
>> Being a software engineer by trade thats not really surprising!
>>
>> For many of us hard core coders that wouldn't be a bad solution. But it 
>> would require a .NET developement environment and they don't come cheap 
>> (unless your boss provides one like mine does!)
>>
>> POVRay has always been free and I hope it will remain so. If it suddenly 
>> requires an expensive developement suite like VisualStudio that blows the 
>> whole "free" thing out of the water.
> 
> uhm, VisualStudio Express is free, isn't it ?
> 
> cu!

They would have to pay me to get me to install VisualStudio.

Post a reply to this message

Well, I'm home, here's the rest...

Let me tell something about an app that I use daily.

AutoCAD provides several ways to being programmed
and controlled by other programs.  It has libraries
which exposes almost all of its functionalities.

At the lowest level, it's something called "ObjectARX",
which allows even the creation of new kind of objects,
and fully automated control rom another app.  But it
requires the use of C++ or similar languages (using
it with C++ is documented, but there are people who
use delphi...)

At a slightly higher level, there are ActiveX controls,
which exposes less, but still allows most (except
the deepest ones) manipulations over the drawing's
database.

You can control it with anything that can control ActiveX,
but there are mainly two languages that are provided
and used to do this : good old LISP, which has been
extended to allow ActiveX calls, and VBA (which does
that naturally).  Both have their pro and cons, but
are quite user friendly and allow both quick and simple
programs, and much more sophisticated stuff.

So, there is both an abstraction between the core and
and the highest level languages, while these languages
aren't that hard to learn for the end user (and there's
even a legacy one).

I simplified things a little, and, in fact, AutoCAD, being
20+ years old, is becoming a huge mess of piled stuff, especially
with their obsession of relea$ing a new one each f****** year.

Nevertheless, it's still a good example of an open architecture.

POV-Ray, which have the chance of being rewritten (most) entirely
would greatly benefit from that kind of openness, without sacrifying
ease AND power of a dedicated (new, enhanced) SDL.

BTW, someone talked about Flash ActionScript, I think that,
as part of these discussions, analysing how other apps does is
absolutely required.

Now, at this point of discussion, please note that

1) while I am not a total novice in programming and computing in
general, I am not an expert either, and expressing some high-end
programming concepts becomes difficult to do well in a conversation
with professionnal (or so) programmers.

2) this group is not the ideal space for such discussions, we would
really benefit of something where thematic discussions (general 
architecture,
rendering, SDL(s), effects, materials, objects...) could take place.
We should beat it while it's hot.

Fabien.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> > >   A library needs an interface to be used. That can't be bytecompiled.
>
> > There're docs for that purpose.
>
>   How is documentation going to help creating an interface to use a
> precompiled library?

It won't.  The infrastructure is supposed to take care of that.  If Visual
Basic or C# programs are compiled to the same "Common Language
Infrastructure", the .NET runtime knows how to handle the binary
interfacing of the code.  The document documents the interface:  here's a
function foo, which takes an argument bar of type foobar etc... should be
called from any language, using a particular syntax.

It's not different from calling precompiled native code from any language,
including C/C++:  the linker is the infrastructure here providing the
glueing together of binaries compiled from different languages into the
same native interface.

Post a reply to this message

nemesis nous apporta ses lumieres en ce 2007/10/04 14:31:
> Warp <war### [at] tagpovrayorg> wrote:
>> nemesis <nam### [at] gmailcom> wrote:
>>>>   A library needs an interface to be used. That can't be bytecompiled.
>>> There're docs for that purpose.
>>   How is documentation going to help creating an interface to use a
>> precompiled library?
> 
> It won't.  The infrastructure is supposed to take care of that.  If Visual
> Basic or C# programs are compiled to the same "Common Language
> Infrastructure", the .NET runtime knows how to handle the binary
> interfacing of the code.  The document documents the interface:  here's a
> function foo, which takes an argument bar of type foobar etc... should be
> called from any language, using a particular syntax.
> 
> It's not different from calling precompiled native code from any language,
> including C/C++:  the linker is the infrastructure here providing the
> glueing together of binaries compiled from different languages into the
> same native interface.
> 
> 
> 
I don't think that .NET works on anything BUT Windows 2000, XP and Vista. Visual 
Basic is a proprietary Microsoft implementation of Basic, and only run on a 
Windows platform. C# comes from where? Is it from Microsoft?

-- 
Alain
-------------------------------------------------

Did you know that Al Capone's business card said he was a used furniture dealer.

Post a reply to this message