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

Christoph Hormann wrote:

> 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 
>
No, they are not. The header file contains a small comment on the 
functionality of the methods. I normally put my docu into the header 
and not into the .cpp files because when I want to use the code 
lateron, I using the headers is more convenient. 

But of course, more comments explaining some general ideas and 
workings should be added. 

> 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).
> 
Ah, you are right. In case there are other patches or parts of the code 
which need the complete image in memory, one should design and implement 
exactly one class which can do so if needed and can be used by all other 
parts. This class should be able to handle 16 bit precision if required. 

It should, however, not be the default, because the row-by-row 
working of povray enables users to generate images of real large size 
(6000x6000 which would use 200Mb for the PRT image buffer alone). 

BTW, Since when did I have access to HDR output and post processing code?

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> [...]
> 
> I consider the introduction of these two classes as good design. 

Speaking of good design:

static inline void PRT_interpolate_linear(COLOUR *dest,
	COLOUR *l,COLOUR *r,float p)
{
	for(unsigned int ii=0; ii<sizeof(COLOUR)/sizeof(float); ii++)
	{  (*dest)[ii]=PRT_interpolate_linear((*l)[ii],(*r)[ii],p);  }
}

For constructions like this you deserve to get shot.

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

Wolfgang Wieser wrote:
>>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).
>>
> 
> Ah, you are right. In case there are other patches or parts of the code 
> which need the complete image in memory, [...]

No, this is not about keeping the whole image, it is about keeping the 
unclipped full precision color values.

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 <ofa### [at] tritonimagicode> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> Speaking of good design:
>
> static inline void PRT_interpolate_linear(COLOUR *dest,
>  COLOUR *l,COLOUR *r,float p)
> {
>  for(unsigned int ii=0; ii<sizeof(COLOUR)/sizeof(float); ii++)
>  {  (*dest)[ii]=PRT_interpolate_linear((*l)[ii],(*r)[ii],p);  }
> }
>
> For constructions like this you deserve to get shot.

Hey, that is *my* line! ;-)

    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:
>>>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).
>>>
>> Ah, you are right. In case there are other patches or parts of the code
>> which need the complete image in memory, [...]
> 
> No, this is not about keeping the whole image, it is about keeping the
> unclipped full precision color values.
> 
...probably including transparency and filter which sums up to 20 bytes 
per pixel which may get a problem when storing the whole image. 

So, my idea would be a class which can save the complete image at 
different resolutions: 8bit, 16bit, full float. If there are several 
code parts in need of such a storage, the one with the highest resolution 
demand will set the internally used format. 
The interface would use COLOUR, but the internal data representation 
would allow different formats to save memory. 

(And I am not only talking about it, I would also consider writing 
such a class if it is needed.)

Wolfgang

Post a reply to this message