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

Fa3ien nous apporta ses lumieres en ce 2007/10/04 11:29:
> Alain a écrit :
> 
>> You must make sure that the new, revamped SDL remain compatible with 
>> the actual SDL, and remain capable to render existing scenes.
> 
> That will be a big issue.
> 
> Personally, I think that, while it might be possible to keep a good
> amount of compatibility, 100% backwards compatibility shouldn't block
> POV-Ray's evolution.  Some things will have to be broken, for the best.
> 
> I think (but might be wrong) that writing some kind of converter, to take
> care of what's been broken, should be preferred instead of making an 
> half-baked
> SDL for the sake of compatibility.
> 
> Compromises...
> 
> Fabien.
In a new SDL, you won't be able to maintain 100% backward compatibility.
One possible thing that may be done is to create some external scene converter 
to recompose some droped features to the new features set, but that can be 
almost impossible in several cases. Ever tried to convert the droped "halo" 
feature to something else?

-- 
Alain
-------------------------------------------------
'Every man has his price.  Mine is $3.95.'

Post a reply to this message

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

Aaaah, the beauty of LISP.

I thought of proposing LISP as the new POV SDL language, but
I'm too young to die.

(for those who wonders, there's no difference between data and
  functions, in LISP)

Fabien.

Post a reply to this message

Alain a écrit :

> 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?

I think that .NET is just to been seen as an *example* of such
interfacing concept, not as the way to go for POV-Ray.

Fabien.

Post a reply to this message

Alain a écrit :

> In a new SDL, you won't be able to maintain 100% backward compatibility.

Yep.

> One possible thing that may be done is to create some external scene 
> converter to recompose some droped features to the new features set, but 
> that can be almost impossible in several cases. Ever tried to convert 
> the droped "halo" feature to something else?

If the converter manages to do it right in, say, 95% of cases, won't it
already be good enough ?  That's a trade-off I would accept readily, in
exchange of more speed and flexibility.

Fabien.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> 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?

it was just an example.  But anyway, yes, you can get .NET to run under
Linux via mono.  Of course, be sure to get yourself patent coverage from
the lame Novell/M$ deal... :P

I was just pointing out to Warp that once you get a common binary
infrastructure and get your code compiled to it, documentation is all you
need to call functions written in other languages:  name of the function,
arguments, argument types and returned values.  It's how you are able to
call C/C++ routines from, say, a Delphi program:  in the end it's just
binary routines calling other native binary routines.

Post a reply to this message

> I was just pointing out to Warp that once you get a common binary
> infrastructure and get your code compiled to it, documentation is all you
> need to call functions written in other languages:  name of the function,
> arguments, argument types and returned values.  It's how you are able to
> call C/C++ routines from, say, a Delphi program:  in the end it's just
> binary routines calling other native binary routines.

COM is a binary interface too, it's also from Microsoft but I doubt 
there is any patent hell about it.

Post a reply to this message

Warp wrote:
> 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.
> 

I was unaware that the parser was in such sad shape... I'm more of an 
end-user than developer in this case...

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? It's cross-platform, object oriented and has been used 
successfully as a scripting interface to a number of projects. 
Currently, we're using Python-Ogre to prototype a game framework and the 
implementation works great! Python has a number of programming tools 
available across a number of OS platforms, AND, it's not a hard language 
to learn or master...
Just a thought...

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> 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.

  A precompiled library alone is useless in C/C++. You need the non-compiled
public interface to use the library.

  That's exactly the problem: If you create a POV-Ray library using
language X, it must be usable without the need for the user to have
the developement environment necessary to write in language X. It must
be usable from POV-Ray directly, using its native scripting language.
How are you going to use it without an interface?

-- 
                                                          - Warp

Post a reply to this message