Warp <war### [at] tagpovrayorg> wrote:
>   A precompiled library alone is useless in C/C++. You need the non-compiled
> public interface to use the library.

That's a problem with C/C++ and their reliance on header files for function
prototypes AFAIK.  Besides, even then, with documentation about functions
written in other languages, even in a C/C++ enviroment you can call these:
just write the proper header files by prototyping the functions as
documented.

Say you write a class in JRuby and bytecompile it.  You can use that class
from a regular Java problem without worries.

> It must
> be usable from POV-Ray directly, using its native scripting language.
> How are you going to use it without an interface?

I agree povray *must* have its own scripting language.  And if it's JITted,
only the better.  I was just pointing out that it is possible to interface
with compiled code given a common binary format, documentation and support
from the infrastructure (compilers, linkers, runtime).

Post a reply to this message

Let me give the perfect example of what I mean.

I work at a mortgage company.  We internally use a third-party system to 
write our mortgage application software.  This tool is rife with handy 
components to make processing mortgage applications easier.

In the current version of the system, they are using a scripting 
language that's built in.  But while the mortgage tools are awesome, the 
programming language (to borrow from Shakespeare) "bloweth chunks".

So, their next-gen suite, which we are just starting to convert to, is a 
set of components that are integrated into Visual Studio.  Not just a 
DLL, but a whole mortgage processing component suite, all placed right 
into the toolbar for dragging and dropping into our software.

The net (bad pun) result: a great tool package that was held back by a 
weak script language has been set free.  We can now create anything from 
ASP.NET and webservices to C#.NET VB.NET, J#, or even console apps.  And 
it doesn't matter which development language we use, the CLR understands 
it all.

If there was a suite of POV components that plugged into Visual Studio 
Express (the FREE version), we could let Microsoft's strong languages 
enhance POV's incredible rendering engine.

Now, the current POV SDL bloweth not chunks, but I still contend that 
opening the architecture so that we CAN access the POV internal 
structures would make it a far more powerful tool.

Plus, it should still be possible to keep the existing SDL and use it as 
a standalone app, even if they integrate the POV engine into a framework 
like .net.

Post a reply to this message

Warp wrote:
> Bryan Valencia <no### [at] waycom> wrote:
>> The Rendering engine should accept only strictly formatted bytecode.
> 
>   Btw, this is a bad idea. It ties the hands of the developers.
> It would make it impossible to change and improve the format of the
> bytecode without breaking existing libraries.
> 
>   It would work if the bytecode format could be PERFECTLY designed on
> the very first try, and then fixed and engraved in stone. However,
> developers are imperfect humans, so it's not gonna happen.
> 
thats just wrong.  thats like saying that Microsoft can never improve 
Word because Word for DOS version 1 doesn't have that.

Bytecode format can be versioned just like all applications and 
languages are today.  Like in HTML, they are getting rid of <b> and </b> 
and changing to <span style="font-weight:80"> this </span>





-- 
---
Bryan Valencia

- I'd rather live with false hope than with false despair.

Post a reply to this message

Warp wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> The libraries would be written in C++, like the rest. No need for
>> proprietary or non-free stuff.
> 
>> This would allow POV-Ray to be controlled by something else than
>> "official" SDL (in a more open architecture), though the normal user 
>> would only see SDL.
> 
>   How would the average user then use those libraries from the SDL?
> 
in this environment, libraries can be written in any .net language 
(assuming that Visual Studio is the "framework" being used)

-- 
---
Bryan Valencia

- I'd rather live with false hope than with false despair.

Post a reply to this message

Christian Froeschlin wrote:
> I was under the impression that the POV-Team sadly objects
> to POV as a library backend and that this is even prohibited
> by the distribution license, so the point seems to be moot.

It's ok, we're just brainstorming.

-- 
---
Bryan Valencia

- I'd rather live with false hope than with false despair.

Post a reply to this message

Bryan Valencia <no### [at] waycom> wrote:
> Bytecode format can be versioned just like all applications and 
> languages are today.  Like in HTML, they are getting rid of <b> and </b> 
> and changing to <span style="font-weight:80"> this </span>

  Dragging backwards compatibility is a bad thing for improvement.

  HTML is a mess exactly because of that.

-- 
                                                          - Warp

Post a reply to this message

Bryan Valencia <no### [at] waycom> wrote:
> in this environment, libraries can be written in any .net language 
> (assuming that Visual Studio is the "framework" being used)

  Could we *please* stop talking about making Windows-only features.
Pretty please? POV-Ray is not. So just stop, please.

-- 
                                                          - Warp

Post a reply to this message

> Warp wrote:
>> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>>> The libraries would be written in C++, like the rest. No need for
>>> proprietary or non-free stuff.
>>
>>> This would allow POV-Ray to be controlled by something else than
>>> "official" SDL (in a more open architecture), though the normal user 
>>> would only see SDL.
>>
>>   How would the average user then use those libraries from the SDL?
>>
> in this environment, libraries can be written in any .net language 
> (assuming that Visual Studio is the "framework" being used)
> 
I'll have to put it in this language, sorry: Screw .NET

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Rather than have an entire CLR, you could have the program structured to 
>> have C libraries (or C++ classes, I suppose), and clearly document how 
>> they're used. Then the SDL parser would invoke constructors building the 
>> classes, then invoke the "render" method.
> 
>   That would mean that 1% of the povray community could benefit from that,

The point of doing it that way would primarily be to allow those writing 
the SDL to use one of the many languages that already exist to avoid 
having to reimplement anything in the SDL except the ray-tracing. Need 
formatted input/output? Need to read CSV files? Want to store objects or 
libraries in a database, or in google-file-system? Want to send a 
message over a socket each time a frame finishes? If you use an existing 
language that can interface to C, like Java, Tcl, Python, Lisp, etc etc 
etc, you get all that sort of stuff "for free". Of course, munging your 
SDL syntax to match the language you pick can be a bit problematic, but 
it's not *that* hard to solve, especially if you pick an appropriate 
"base" langauge.

Hope that clarifies.

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?

Post a reply to this message

Bryan Valencia wrote:
> If there was a suite of POV components that plugged into Visual Studio 
> Express (the FREE version), we could let Microsoft's strong languages 
> enhance POV's incredible rendering engine.
> 
You are forgetting (or ignoring) that VS is Windows only.  POV-Ray is 
*NOT* limited to Windows only.

      -=- Larry -=-

Post a reply to this message