POV-Ray : Newsgroups : povray.programming : Extending #read, another option... Server Time
5 Jul 2024 15:01:52 EDT (-0400)
  Extending #read, another option... (Message 12 to 21 of 21)  
<<< Previous 10 Messages Goto Initial 10 Messages
From: ABX
Subject: Re: Extending #read, another option...
Date: 13 May 2003 11:05:50
Message: <7622cvo1dl2s2ufihr1upetlfl6ntmfc87@4ax.com>
On Tue, 13 May 2003 10:50:10 EDT, "Kitsune_e" <kit### [at] hotmailcom> wrote:
> It occures to me that C has generaly the same data structures
> accrossed multiple platforms (string int double etc).

It occures to me that POV has the same data structures accrossed multiple
platforms (string, float, color objects pigments etc).

>  C is ment to be portable,

So and POV-Ray

> the compiler should handle any non-system specific code on any
> system.  I do not know if that is the case in practice though.

Of course not. How many portable C compilers have plugin feature ?
How many C compilers opens its own _internal_ structure for other apps ?

ABX


Post a reply to this message

From: ABX
Subject: Re: Extending #read, another option...
Date: 13 May 2003 11:08:50
Message: <rc22cvgt6j1co1r03knk6lc9kna0b7bunv@4ax.com>
On Tue, 13 May 2003 10:40:56 EDT, "Kitsune_e" <kit### [at] hotmailcom> wrote:
> > > What Povray needs is a plug-ins API...
> >
> > They are called "patches" here. And the initial API is at
> > http://megapov.inetart.net/manual/internals.html :-)
>
> This is not what I am discussing.

But that's the only possible discussion which can be continued from your feature
request (and then in povray.unofficial.patches).

ABX


Post a reply to this message

From: Kitsune e
Subject: Re: Extending #read, another option...
Date: 13 May 2003 11:10:10
Message: <web.3ec109ee2a3b3a27f73ed81b0@news.povray.org>
Kitsune_e wrote:

Well, I attemted to give an intelligent sugestion instead of the "Please add
feature" I was ment to request, and I have been stoned and humiliated by
people whom I respected.  I don't think my request was foolish, I do think
it was rediculesly difficult to impliment.  Of course so would be creating
a raytracing render engine which could successfuly re-create real world
phenomena...

I knew this idea would most likely be met by opposition, I just wish more of
the comments I had recieved had been useful feedback instead of flame.  I
found here an elitist attitude I had not expected to find in the Povray
community.  I will not be asking any more questions on this forum... your
sanctum is safe.  Please go on about your buisness.  You select few have
given many powerful features to Povray.  I have no doubts that you could
extend the Povray engine.


Post a reply to this message

From: ABX
Subject: Re: Extending #read, another option...
Date: 13 May 2003 11:46:24
Message: <ba32cv8bj7v41tq1qaoopsm1kadcnq74pj@4ax.com>
On Tue, 13 May 2003 11:06:22 EDT, "Kitsune_e" <kit### [at] hotmailcom> wrote:
> I have been stoned and humiliated

I will try to list general 'mistakes' you made:

1. You proposed feature (plugin) which comes here very often and which was many
times refused with clear explanation.
2. You proposed feature (plugin) which is impossible to implement in portable
way (or if possible then over skills of people here).
3. You are saying it is possible to implement it and at the same time you say
you do not know how to do it.

I'm really under impression of your art work but this does not change that it is
irritating to repeat the same discussion again and again. Personally I see a lot
of benefits from plugin idea but much more I do not want features dedicated to
one operating system becouse nobody made plugin for other platform or used OS
specific features. The amount of work for coding algorithm in C++ is the same
for patch and for plugin so is there anything what can't be done with patch but
can be done with plugin based architecture ?

ABX


Post a reply to this message

From: Warp
Subject: Re: Extending #read, another option...
Date: 13 May 2003 12:18:53
Message: <3ec11aec@news.povray.org>
Kitsune_e <kit### [at] hotmailcom> wrote:
> C is ment to be
> portable, the compiler should handle any non-system specific code on any
> system.

  What do you think all the patches out there are doing? Exactly this.

  The problem is, of course, that this is not a plug-in system. You need
to compile the C source code with a compiler.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Extending #read, another option...
Date: 13 May 2003 12:28:15
Message: <3ec11d1f$1@news.povray.org>
In article <web.3ec109ee2a3b3a27f73ed81b0@news.povray.org> , "Kitsune_e" 
<kit### [at] hotmailcom> wrote:

> I knew this idea would most likely be met by opposition, I just wish more of
> the comments I had recieved had been useful feedback instead of flame.
> I found here an elitist attitude I had not expected to find in the Povray
> community.

You have to realize that developing a program and its logic is a very
difficult task that requires a good understanding of computer science.  Also
you can learn "programming" in school these days, this has very little to do
with computer science.

This is no different from, say, being a car mechanic.  Sure you (not "you"
personally, this is in the general sense of "you") know something about
cars; and you can even detect if something like the exhaust is broken.  But
would you go to your car mechanic and tell him what to fix and how to fix
it, maybe bring a new exhaust with you already even you don't know anything
about the old one?  Unlikely, and if you did, what do you think he would
say?  Or if you wanted to add a spoiler, would you discuss with the car
mechanic how to add it, or tell him you saw the same spoiler on another car
model, and ask him _why_ that one doesn't fit your car?  I suppose no
because you know by doing so you would most likely make a fool out of
yourself.

And this is essentially what you did with your question.  You said: Here is
a spoiler, why can't one mount it on this car if it fits so well on another?
Just like owning a car doesn't make you a car mechanic, owning a computer
doesn't make you a computer scientist.  That is not elitist.  It is reality.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Christoph Hormann
Subject: Re: Extending #read, another option...
Date: 13 May 2003 12:44:52
Message: <3EC120FF.1C93E81@schunter.etc.tu-bs.de>
Kitsune_e wrote:
> 
> Kitsune_e wrote:
> 
> Well, I attemted to give an intelligent sugestion instead of the "Please add
> feature" I was ment to request, and I have been stoned and humiliated by
> people whom I respected.

No.

Considering the fact that the matters discussed in this thread are - as
explained - off-topic here and also considering that the main topic of
your posting - the 'plugin' idea - has been covered in depth in previous
discussions all replies you got were relatively friendly and trying to
explain things as much as possible.  Your posting is the first getting a
touch of personal insults which is not appropriate.

As you write yourself:

> As for non-sense I do not understand why how giving other programs access to
> Povray's internal data is non-sense, or why it cannot be made portable
> among machines with similar architecture?

you don't understand why the idea of plugins is not so trivial for
POV-Ray.  If you want an explanation for this you should ask for one in
the appropriate group or even better read up where this has been covered
before, for example in:

http://news.povray.org/povray.programming/28666/
http://news.povray.org/povray.general/2743/
http://news.povray.org/povray.programming/17195/
http://news.povray.org/povray.programming/20476/

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______


Post a reply to this message

From: Kitsune e
Subject: Re: Extending #read, another option...
Date: 13 May 2003 18:35:07
Message: <web.3ec172332a3b3a279e46361d0@news.povray.org>
Thorsten Froehlich wrote:
>In article <web.3ec109ee2a3b3a27f73ed81b0[at]news.povray.org> , "Kitsune_e"
><kit### [at] hotmailcom> wrote:
>
>This is no different from, say, being a car mechanic.  Sure you (not "you"
>personally, this is in the general sense of "you") know something about
>cars; and you can even detect if something like the exhaust is broken.  But
>would you go to your car mechanic and tell him what to fix and how to fix
>it, maybe bring a new exhaust with you already even you don't know anything
>about the old one?  Unlikely, and if you did, what do you think he would
>say?  Or if you wanted to add a spoiler, would you discuss with the car
>mechanic how to add it, or tell him you saw the same spoiler on another car
>model, and ask him _why_ that one doesn't fit your car?  I suppose no
>because you know by doing so you would most likely make a fool out of
>yourself.
>
>And this is essentially what you did with your question.  You said: Here is
>a spoiler, why can't one mount it on this car if it fits so well on another?
>Just like owning a car doesn't make you a car mechanic, owning a computer
>doesn't make you a computer scientist.  That is not elitist.  It is reality.
>
>    Thorsten

Thankyou,
this response is a much better answer then the unqualified "_no_" which I
recieved before.  I do understand why my comment recieved such negitive
responses, this is why I attempted to make my comments more of a topic for
intelligent discussion of the possability then a features request.  It
appears though that no one is currently open to or interested in discussing
this possability.

It is true that it would be arrogant to suggest in ignorance to the mechanic
how to do his or her job.  this stupid topic is taking up to much of my
time and yours.  The things done so far in Povray are amazing, and I am
certain greater things are planned in the future.  I would appreciate it if
no one else would reply to this post, and would continue on instead with
more important matters.


Post a reply to this message

From: Christopher James Huff
Subject: Re: Extending #read, another option...
Date: 13 May 2003 22:43:42
Message: <cjameshuff-B9CE06.22440113052003@netplex.aussie.org>
In article <web.3ec106c02a3b3a27f73ed81b0@news.povray.org>,
 "Kitsune_e" <kit### [at] hotmailcom> wrote:

> It might be a waste of space, but why not expand .programming to its own
> section:
> 
> povray.programming.engine .general .patches etc.
> 
> just to make it more clear.

The group gets relatively little traffic as it is...spreading it out 
over more would not make sense, and would not make anything clearer.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/


Post a reply to this message

From: Christopher James Huff
Subject: Re: Extending #read, another option...
Date: 13 May 2003 22:54:56
Message: <cjameshuff-DD79B8.22551413052003@netplex.aussie.org>
In article <web.3ec106212a3b3a27f73ed81b0@news.povray.org>,
 "Kitsune_e" <kit### [at] hotmailcom> wrote:

> I have read no articles on building plug-ins, I do not know specific
> methods.  It occures to me that C has generaly the same data structures
> accrossed multiple platforms (string int double etc).  C is ment to be
> portable, the compiler should handle any non-system specific code on any
> system.  I do not know if that is the case in practice though.

C source code is portable unless it uses something specific to a 
platform. Binary data structures and compiled code are not portable. And 
there is no standard way to dynamically load compiled code in the form 
of plugins, this requires platform-specific code. This is why patches 
are used instead of some plugin system...the plugin system would have to 
be rewritten for each platform. The plugins themselves would be a 
nightmare for support, with people trying to use plugins compiled for 
the wrong systems and potential for conflicts between plugins.

One possible compromise would be to use a platform-independant bytecode 
format, similar to Java class files. However, this has a speed penalty 
because the bytecode has to be interpreted instead of directly running 
machine code, and it would be easier to just load the files from the 
source code as is now done with include files. So, one form of plugin is 
impossible, the other is slower than the alternatives.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/


Post a reply to this message

<<< Previous 10 Messages Goto Initial 10 Messages

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.