![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Jeff Houck <jho### [at] northrim net> wrote:
> I've been trying to follow both of the SDL threads and one thing has
> occurred to me, why not expose the core interface API to a language like
> Python?
Changing radically the scripting language is not going to be well received.
Personally I dislike python in particular because of its enforced
whitespace interpretation.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Jeff Houck <jho### [at] northrim net> wrote:
>> I've been trying to follow both of the SDL threads and one thing has
>> occurred to me, why not expose the core interface API to a language like
>> Python?
>
> Changing radically the scripting language is not going to be well received.
Well, that certainly could be an issue though I don't see how it can be
avoided to some extent. It's all speculation I guess...
On the other hand, I could code up an "unofficial" Python binding
anyway... Just need the source and a little time...
>
> Personally I dislike python in particular because of its enforced
> whitespace interpretation.
That's one of the things I like... to each his own they say.... :)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp <war### [at] tag povray org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Bryan Valencia <no### [at] way com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Fa3ien <fab### [at] yourshoes skynet be> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Bryan Valencia <no### [at] way com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Bryan Valencia <no### [at] way com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> Warp wrote:
>> Fa3ien <fab### [at] yourshoes skynet be> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |