Wolfgang Wieser wrote:
> [...]
> 
> Hmm... What would you suggest should be done differently? 

I'd suggest to implement it like the other render techniques are 
implemented (Start_Adaptive_Tracing() and Start_Non_Adaptive_Tracing()). 


And if you want to have a chance that someone else implements the 
frontend for the other platforms you seriously need a documentation of 
the interface between the core code and the platform specific part.  It 
might be a good idea to completely leave out the interactive part so you 
just need POV_DISPLAY_UPDATE_RECT and nothing more.

Christoph

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

Post a reply to this message

In article <4012dca5@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> And about POV and C++, I'm a bit puzzled when reading the rest of the
> code, especially the image IO. It seemed to me that decision was taken
> to C++ify the C code for 3.5 and above ending up in a lot of C in cpp
> files with a little bit of C++. I'm not having a very good feeling when
> it comes to that.

Why?  C++ is just a superset of C (well, with a few very minor exceptions).
So features that are in a need for a rewrite get rewritten using some C++
features.  However, that does not imply there should be a wild mix of
designs.  If a particular section of code uses a C++ features (in particular
is put in a class), then every similar module should also do so.  So, just
don't create a mess.  Either go all the way or don't go it at all.  To only
do something because it seems convenient without any direct benefit isn't
the idea behind the code structure and allowing the use of C++ features.

    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

Thorsten Froehlich wrote:
> And promtly distribute binary versions without a timeout in them. No!
> 
??!

Wolfgang

Post a reply to this message

In article <4012cd76@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>> Why?  The policy to not make development source code accessible has a good
>> reason, because it simply did not work in the past.  Considering that back
>> in that "past" far fewer users with a lot more technical clue has access
>> to online resources, the internet of today does only make matters worse.
>>
> The proper reaction IMO is to find those people which do have a clue.

You really think we have the time to manage read access rights for many
developers?  It is really hard to tell somebody who just wants to lurk at
the code to someone who is going to contribute something.  So the
alternative would be to make the source code readable for everybody, which
in turn would result in people make distributions based on that code, which
is something they absolutely should not make.

>> And periodically looking at various "open source" development projects
<snip>
> [I am skipping this paragraph in an attempt to not feed the trolls.]

Take a look at the Debian povray package.  How they fixed the code to
compile on 64 bit platforms says a whole lot about the quality of their
"fix".  Especially as a correct solution had been available on this server
for a very long time before they "fixed" it.

>> My personal opinion is that no future patches' source code from MegaPOV
>> should be added to an official POV-Ray at all.  This is from the very bad
>> experience with patch quality that caused massive problems getting a
>> timely release of POV-Ray 3.5, and even in 3.6 not all of the flaws in
>> some patches have been corrected.
>>
> I do not completely understand that. In order to advanve/innovate one
> needs to add code to existing code, hence "patch" it. If you do not
> patch code, you stop development.

If the next release, which will be 4.0 and is a rewrite, what point would
there be in adding new minor patches to the official 3.x code base?

> So what is the alternative?
> Direct implementation by a POV team member (with inspiration from
> the patch code)?
>
> In this case we definitely need megapov as a patch playground because
> the above tends to take quite long...

Indeed, it takes so long because quality software development takes long.
That way we don't need to release hot fixes every other day like many other
companies and projects do.  And users don't have to hunt down the latest and
greatest version every other day either.

> Maybe we are using slightly differrent meanings for "patch".

Nope.

> This is clear (although I think that "just converting" the parametric
> object will not be that easy...)

As I said, "most" objects.  And the parametric object is one with the most
bugs still in it.

> As you are talking about version 4.0, I think it should not only be
> a re-write but a re-design

That is obvious!

>> And you can be sure the community as well as the POV-Team will
>> greatly appreciate bug fix contributions.
>>
> (And any bug fix writer will appeciate access to up-to-date source code...)

Why?  It is much easier to track down a bug if the source code does not
change while you are tracking it down, so it is irrelevant if you have the
most recent source code and can't update it or you have the release source
code of the last official version and can't update it until you have found
the bug.

>> I strongly disagree.  All "those people who want to work" usually do only
>> want to add features.  They have no desire to go through the very time
>> consuming, boring and frequently frustrating process of fixing bugs.  So,
>> when pushing for a quick including of a patch into the official POV-Ray,
>> these people also want to leave at least some of the work of fixing the
>> bugs to the POV-Team.
>>
> (1) One does not need to integrate patches quickly into povray.
>     But one could at least make it easier for people to write their
>     patches.

It is very easy to write patches that add new objects and patterns.  You
don't need any non-final source code to do that.  As far as other features
are concerned, those should really not be added unless they add something
truly useful to most users, the code outside objects and textures has enough
problems already.

> If one threatens to de-integrate the patch, there will probably be
> somebody who finds it useful and takes over the responsivbility.
> If tere is not, there seems to be no interest at all and one can live
> without that functionality.
> I don't think this is the best solution but a fallback...

You miss an important point: Also no developer is interested in a particular
patch does not say anything about no user being interested in a patch.  You
make the typical mistake all these "open source" proponents do, in assuming
that everybody who uses a program is also able to fix it.  That is of course
nonsense.  Even the average advanced user of POV-Ray does not know
programming...

> It's just that I learned to never fix bugs in old versions. I tracked
> down other bugs for other projects and the correct behaviour always was
> use the current development code and not a one-year-old code base.

I think you are mistaken.  The correct behavior always is to use the version
they make available.  In many of those projects individual developers in
turn keep large changes private and only contribute them when they are
"ready".  Thus, it just moves the problem around, but does not help to solve
it.


    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

Christoph Hormann wrote:

> Wolfgang Wieser wrote:
>> [...]
>> 
>> Hmm... What would you suggest should be done differently?
> 
> I'd suggest to implement it like the other render techniques are
> implemented (Start_Adaptive_Tracing() and Start_Non_Adaptive_Tracing()).
> 
I wrote a class PRTImageData holding the image for PRT. 

Then there is PRTTileHeap which implements a heap of rectangular 
tiles to be rendered. 

I consider the introduction of these two classes as good design. 

And then there is PRTRenderer. It may be better design to get rid 
of this class especially because I am unhappy with the static 
self-reference to the one existing instance. This would, most likely 
require a further global variable (pointer). 

If you think that I should re-implement PRTRenderer's functionality 
using plain C and use PRTImageData and PRTTileHeap for their 
purposes, I will very likely consider doing that. 

> And if you want to have a chance that someone else implements the
> frontend for the other platforms you seriously need a documentation of
> the interface between the core code and the platform specific part.  It
> might be a good idea to completely leave out the interactive part so you
> just need POV_DISPLAY_UPDATE_RECT and nothing more.
> 
I will not get rid of the interactive part because that is the more 
useful part for me. If you think that non-interactive PRT should be 
included into megapov, removing that functionality for doing so would 
be easy. 

Wolfgang

Post a reply to this message

In article <4012eb95@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>> And promtly distribute binary versions without a timeout in them. No!
>
> ??!

The consequence would be users coming years later and reporting bugs in
versions they think are current.  This is exactly what happened in the days
when source code was available.  And it was before the WWW was around...

    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

Thorsten Froehlich wrote:

> alternative would be to make the source code readable for everybody, which
> in turn would result in people make distributions based on that code,
> which is something they absolutely should not make.
> 
Okay, the distribution problem is something I was not thinking about. 
OTOH, if one distributes binary betas, why not source betas?

> If the next release, which will be 4.0 and is a rewrite, what point would
> there be in adding new minor patches to the official 3.x code base?
> 
If 4.0 is supposed to come in several years, then "time" could be a 
reason. 

And as 4.0 will probably use the same numeric maths, fixing that would 
IMO make sense even if minor. 

> Indeed, it takes so long because quality software development takes long.
> That way we don't need to release hot fixes every other day like many
> other
> companies and projects do.  And users don't have to hunt down the latest
> and greatest version every other day either.
> 
No non-trivial software is completely bug-free. 

So, if one waits with releases until there are really no bugs left, 
one will never release it. 
OTOH, if one includes patches and releases without testing, there will 
be tons of bugs. 

This is nothing new. 

But given that problem the solution is to find a way between the two 
extrema. Where the cut is to be placed depends on one's opinion. 

As for me personally and considering POVRay, I'd actually prefer some 
more features (now) even if they come with some more bugs. Because I 
belong to those people who (potentially) fix those bugs they find. 

So, I benifit from the features. And when I find a bug, oh well, then 
time needs to be spent on that but _somebody_ would have to do just that 
anyways sooner or later. 

> Why?  It is much easier to track down a bug if the source code does not
> change while you are tracking it down, so it is irrelevant if you have the
> most recent source code and can't update it or you have the release source
> code of the last official version and can't update it until you have found
> the bug.
> 
...as long as I do not spend 10 hours tracking something down which 
has already be fixed by someone else!

> You make the typical mistake all these "open source" proponents do, in
> assuming
> that everybody who uses a program is also able to fix it. 
>
Yes, but it is enough if _one_ such person exists. 
And what is the use of fubar code nobody wants to care about? 
It's like cancer...

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:
>>> And promtly distribute binary versions without a timeout in them. No!
>>
>> ??!
> 
> The consequence would be users coming years later and reporting bugs in
> versions they think are current.  This is exactly what happened in the
> days
> when source code was available.  And it was before the WWW was around...
> 
(1) That is why I always get the newest release before reporting a bug. 
(2) Every bug report needs to contain a version number. And if a user 
    reports stoneage bugs, automatic reply would be "update your system"
    There is nothing else one could do against that. I do not see any 
    difference, especially as under the current model, is is not only 
    the version "they think is the current" but it _IS_ the current, 
    or to express is easier: 
(3) So what? The current code is year(s) old -- what makes the difference ;)

Wolfgang

Post a reply to this message

In article <4012f4d8@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

>> The consequence would be users coming years later and reporting bugs in
>> versions they think are current.  This is exactly what happened in the
>> days
>> when source code was available.  And it was before the WWW was around...
>>
> (1) That is why I always get the newest release before reporting a bug.

If you do it doesn't mean everybody else will.  Just look at all those
Outlook Express exploiting "emails" around even after bugs had been fixed a
long time ago and there is a rather easy update feature...

> (2) Every bug report needs to contain a version number.

Tell that to users.  You would be surprised how many even manage to report
the *wrong* version number...

> (3) So what? The current code is year(s) old -- what makes the difference ;)

I explained that before.  That there was no 3.5.1 had no developmental
reasons.  Apart from that, inn general, there is a huge difference between a
current version that has been released a year ago and a outdated long
replaced version that has been released five years ago!

    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

Wolfgang Wieser wrote:
> [...]
> 
> If you think that I should re-implement PRTRenderer's functionality 
> using plain C and use PRTImageData and PRTTileHeap for their 
> purposes, I will very likely consider doing that. 

PRTImageData and PRTTileHeap are both completely undocumented and they 
do some really strange things - using 16 bit values for the image for 
example is understandable for memory size reasons but this makes it 
essentially incompatible to other patches (HDR output, post processing).

Christoph

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

Post a reply to this message