Wolfgang Wieser wrote:
> 
> Yes, but there are two reasons for my approach: 
> (1) Opening a 1Gb file in an external program, selecting some part, 
>     saving it... all that for every view port is too much work for me. 
> (2) The cut-down chunk needs extra calculations to make sure the 
>     image map projection is exactly correct. 
> My patch saves me from both these. 
> [...]

I don't understand (2) and (1) of course is no more an issue with an 
external program than it is with a POV-Ray patch.

> I was told the same argument some time ago. It read like "we did a 
> complete rewrite of unix.cpp but you can do everything with the old 
> version so feel free to send us patches for the old code". 

No, please reread the past postings in this concern.  The proposal to 
work on the unix specific part of the 3.5 code did only involve the X11 
display code.  This is exactly as it is in 3.5 and the changes you made 
there could be merged with the 3.6 code without any trouble.

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

Thorsten Froehlich wrote:
> Well, then  start your own ray-tracer project.  Oh, well, wait, every
> single
> one ever started has died about as quickly.  Quality software development
> takes time, otherwise you would end up with bloated junk and broken 1.0
> designs!  For example Mozilla is a great example for a design broken from
> the beginning...
> 
Thorsten, PLEASE!

I actually bet my evening dinner on you writing just that. 

Please reduce a tiny bit your expression of the "POV-code-is-the-best-
code-in-the-world-and-all-other-programs-are-full-of-bugs-or-trivial"
theoreme. 

From those bugs I have found myself in POV code, the code is not as 
high-quality as you consider it to be. I am really sorry to say that 
but sometimes it is healthy to face truth. 

[BTW, I do not remember my mozilla ever crashing. But I remember 
POVRay 3.5c (official) crashing. But I am using mozilla only when 
konqi does not get along with a page...]

But stop. I do NOT want to start a discussion here about mozilla, the 
linux kernel, XFree86, the different development models around etc. 

Especially, I would ask you not to answer here, that if we would put 
POVRay code in a public CVS and let all the world contribute, then the 
code will be fubar within very short time. 

This is correct. 

And this has already been discussed long enough. 

Regards,
Wolfgang

Post a reply to this message

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

> I was told the same argument some time ago. It read like "we did a
> complete rewrite of unix.cpp but you can do everything with the old
> version so feel free to send us patches for the old code".
>
> I could consider that as an expression of no interest in what other
> people are doing. It's a bit like preaching water and drinking wine.

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.

> Don't you think that this effectively hinders futher development?
> It makes me waste time writing patches for old code which have to
> be converted to the new code. It makes the POVRay team waste time
> getting patches based on one-year old code base. And finally, most
> of the bugs I see come from looking at the source, not from using
> a binary.

But you have access to the source code.  Use it.  Honestly I have to say
several of the contributed bug fixes we so far got for 3.5 cannot (well,
should not) be used as is in the source code.  While many bug fixes
correctly identify the problem, they frequently tend to be more of a "hack"
than a solution.

And periodically looking at various "open source" development projects makes
me worry a lot about even considering using that software.  Despite its age,
the POV-Ray source code is in a very good shape compared to many much
younger "open source" projects whose individual modules are rewritten every
three or four years...

> But I see a further possibility using the following roadmap:
> (1) get povray 3.6 out
> (2) bring out long awaited new megapov based on 3.6
> (3) more frequent megapov updates

The reason for there being no MegaPOV updates is that early on in the 3.5.1
development the MegaPOV sources were tried to that version and its release.
Due to purely administrative (and not going to be discussed in public), not
developmental reasons, the release of 3.5.1 had to be delayed far beyond our
expectations.  That is why there is POV-Ray 3.6 now, because we did not
simply stop development while having to deal with administrative issues.

> In this case I'd be more happy to see current megapov development
> and to be able to write patches for (or even contribute to) megapov
> [than to mainline povray] anyways.

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.

Apart from that, with 4.0 being a rewrite, producing patches, especially
some that just add minor individual tweaks (usually by parser or
preprocessing data later rendered) rather than new objects, are of very
little use because those parts of POV-Ray are in a major need for a rewrite
while most of the objects can just be converted.

> To me (as looking at it from outside) it seems like there would be
> enough ideas, code and manpower around here for quite some innovation
> but there is somebody somewhere out there actively pulling the break.

Well, POV-Ray is a program for users, not for developers.  Just adding
features is the absolute wrong way of doing development.  If you want to
contribute, there is a long list of outstanding bugs on www.povray.org and
p.bugreports that definitely have a higher priority than adding new
features.  And you can be sure the community as well as the POV-Team will
greatly appreciate bug fix contributions.

Still, also said list has been available since the release of POV-Ray 3.5, I
am only aware of two people only ever to look into any of them.

> I learned that in most cases it turns out negatively to hinder those
> people who want to work (and have the ability to do it well) from
> doing their work.

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.

Honestly, I find such behavior very disrespectful towards both the community
as well as the POV-Team members.  On the one hand the community is shown
some great new feature, but when there are bugs, frequently in the past more
than one original developer did not have any time to finish their work.  I
have no problem with someone turning to other interests, but I have a
problem if they do so only after they made the community curious about their
work.

In the end, the POV-Team frequently did add such features, and by doing that
had to go through all the source code they didn't write, fix the bugs, fix
the design flaws, and in many cases even write the documentation.

THIS IS NO FUN At ALL!  It takes a real lot of time and patience!!!  Time
and patience the original developer could not be bothered to find in several
cases.  So, if you consider the POV-Team being careful about adding new
features "to hinder those people who want to work", fine, I call it
prevention of wasting even more of our free time on something simply nobody
else wanted to waste their free time doing.

In conclusion, contribute fixes for the real bugs that concern users, or
quit complaining.

Of, course, this is only my personal opinion, nothing else.

    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:
>> 
>> Yes, but there are two reasons for my approach:
>> (1) Opening a 1Gb file in an external program, selecting some part,
>>     saving it... all that for every view port is too much work for me.
>> (2) The cut-down chunk needs extra calculations to make sure the
>>     image map projection is exactly correct.
>> My patch saves me from both these.
>> [...]
> 
> I don't understand (2) and (1) of course is no more an issue with an
> external program than it is with a POV-Ray patch.
> 
(1) is easier with POVRay than with an external program and much faster 
    because POVRay simply reads part of the info while the external proggy 
    requires reading the complete info, processing it, write a part and 
    then make POVRay read that part. 
(2) the cut-down image will be projected around the complete e.g. sphere. 
    To make use of it, I need to scale and rotate the texture in a way 
    that the original size is restored. The patch does not require that. 

I just write that because you asked. 

I am NOT actively demanding inclusion of that patch. All I wanted to 
express by my first posting was that in case there are several people 
who find it useful, one could consider doing it. That was unlikely 
from the beginning...

> No, please reread the past postings in this concern.  The proposal to
> work on the unix specific part of the 3.5 code did only involve the X11
> display code.  This is exactly as it is in 3.5 and the changes you made
> there could be merged with the 3.6 code without any trouble.
> 
IMO, it was pure luck that the code parts did not interfere. 
And it effectively hinders me to think of any more useful things 
in that concern. 

I may describe my situation as follows. 

(A)
For the partial image reading patch, watiting is no solution. 
I need it now, so I implement it now. I asked if there is interest 
but that fact that there is none does not pose any trouble because 
I am writing it for _my_ purpose in the first place. It currently is 
a not very clean hack anyways (but I would have considered writing 
it cleanly in case real interest exists). 

(B)
For unix.cpp the situation is differently. I think one can live with 
it but there are some things to be improved. So, due to the fact that 
I am using a great tool written by some clever people who share it with 
me (I mean POVRay), there are some days where I simply think that it 
would be the apropriate action to give something back by sitting down 
and writing some improvements. (I do not talk about simple bug fixes.) 

But these people effectively tell me that they don't care. 
So, I say "Well... I can spend my time more usefully."
It simply does not make sense to re-write old code. Or to quote you 
again: 
> You'd probably save some time [...]

The sad thing is that this does not help either party. 

BTW, you did not comment on megapov. 

Wolfgang

Post a reply to this message

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

> Please reduce a tiny bit your expression of the "POV-code-is-the-best-
> code-in-the-world-and-all-other-programs-are-full-of-bugs-or-trivial"
> theoreme.

I didn't say that at all.  And I definitely never said such a thing to the
contrary.

On the other hand, how old is the Mozilla code base, or the Linux kernel?
The POV-Ray code dates back to the mid 1980s.  And it has not required a
rewrite since.  Yet, the two projects mentioned have had their whole design
turned over how many times in just the last five years?

> From those bugs I have found myself in POV code, the code is not as
> high-quality as you consider it to be. I am really sorry to say that
> but sometimes it is healthy to face truth.

Read my other post.  It is very easy to complain about bugs and then to do
nothing about them.  Of course, you just want to do the fun part, but hey,
guess what, everybody want to do just that.  The difference between a
POV-Team member (or everybody with source code access) and the average patch
writer is that a POV-Team member takes the responsibility of a feature's
bugs getting fixed and to make it bug free eventually.

> [BTW, I do not remember my mozilla ever crashing. But I remember
> POVRay 3.5c (official) crashing. But I am using mozilla only when
> konqi does not get along with a page...]

Sure, Mozilla never crashing, not consuming a gigabyte of memory and taking
an hour to start up the first time.  Even Konqueror crashes if fed with the
"right" page.  At least my "version" of it does.  And I tend to use IE 5.2
to view pages in such cases.  Yet, compare Konqueror to Mozilla.  The first
one is well structured with a simple yet powerful and considerate design,
the later is a huge waste of compilation time with *much* more code to do
the same thing.  Code quality is more than just not crashing.  In fact,
crashing bugs are the easiest to find and solve.  The design on the other
hand...

> But stop. I do NOT want to start a discussion here about mozilla, the
> linux kernel, XFree86, the different development models around etc.

Ah, yes, the other two high-profile projects showing clear signs of forking
and serious code quality problems.  Of course, monolithic kernels are such a
great idea, so they flaw must be elsewhere than in the fool who conceived
it.

> Especially, I would ask you not to answer here, that if we would put
> POVRay code in a public CVS and let all the world contribute, then the
> code will be fubar within very short time.

CVS, sure.  Ever looked into the CVS source code?  I had the stupid idea to
do so just three weeks ago.  Two hours later, I rushed to delete it from my
harddisk again.  There are things I don't even want to know, and I really
don't want to know what holds CVS together.  But this shouldn't be the point
here:

Even if the code would not be "fubar within very short time", the ability of
every user to use any new feature would be very quickly.  Of course, I don't
want to point at the contribution of anybody (after all the POV-Team did
pick them up and was and still is committed to the original work and it was
all very useful), but if you look at how some patches had to be used (even
putting their flaws with fixed buffers and such aside) prior to being
included in 3.5, it should not be too hard to get an idea why I am
concerned.  Of course, you cannot know this because you probably never tried
to fix any of the old patches before they were added to 3.5...

    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

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

>  (I do not talk about simple bug fixes.)

But that is what is needed.  Don't you think POV-Team members cannot think
of more than "simple bug fixes"?  Yet, if all we get is *more* than "simple
bug fixes", which is what takes the real time of any serious software
development project, how are we supposed to actually do more?  By not doing
the "simple bug fixes"?

Anyway, let me rewrite this in my favorite and brutally honest style; but
please don't it personal, I am just saying exactly what I am thinking:

I don't want to get personal, and I don't know your background, but if you
think about bug fixes as "simple", you either never had to fix bugs, or you
don't know anything about software development.  I know absolutely no
professional (who I know isn't a fool, and even they usually have realised
fixing bugs is hard) that considers fixing bugs something that is simple.
So, given I know very little about you, using only what you say to judge the
validity of your arguments, your statement about "simple bug fixes" does not
give those arguments much credibility...

    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:
> 
> (1) is easier with POVRay than with an external program and much faster 
>     because POVRay simply reads part of the info while the external proggy 
>     requires reading the complete info, processing it, write a part and 
>     then make POVRay read that part. 
> (2) the cut-down image will be projected around the complete e.g. sphere. 
>     To make use of it, I need to scale and rotate the texture in a way 
>     that the original size is restored. The patch does not require that. 

Surely it is a matter of opinion if this is a useful patch - i can only 
say that i personally never felt nor now feel the necessity for such a 
feature and it offers nothing that would be impossible with external tools.

If you like this feature and therefore implement it that is of course 
all right, i just have the impression that you interpret the lack of 
interest in this patch as a lack of interest in people working on 
improving POV-Ray in general.

> 
> BTW, you did not comment on megapov. 

There is nothing to comment on i think.  Thorsten pretty much summarized 
the current situation of MegaPOV.  If you wanted to ask about inclusion 
of your patch, this is mainly a matter of:

- quality of the patch and its documentation
- if it is regarded as useful and well usable by the MegaPOV Team
- if there is interest in the patch among users

And in any case not for MegaPOV 1.1 which already contains more than 
enough new features.

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

Thorsten Froehlich wrote:

>> Please reduce a tiny bit your expression of the "POV-code-is-the-best-
>> code-in-the-world-and-all-other-programs-are-full-of-bugs-or-trivial"
>> theoreme.
> 
> I didn't say that at all.  And I definitely never said such a thing to the
> contrary.
> 
You did it and are doing it right here again. 
I just made an exaggeration to make the point obvious. 

> On the other hand, how old is the Mozilla code base, or the Linux kernel?
> The POV-Ray code dates back to the mid 1980s.  And it has not required a
> rewrite since.  Yet, the two projects mentioned have had their whole
> design turned over how many times in just the last five years?
> 
[I won't feed the trolls.]

>> From those bugs I have found myself in POV code, the code is not as
>> high-quality as you consider it to be. I am really sorry to say that
>> but sometimes it is healthy to face truth.
> 
> Read my other post.  It is very easy to complain about bugs and then to do
> nothing about them.  Of course, you just want to do the fun part, but hey,
> guess what, everybody want to do just that.  The difference between a
> POV-Team member (or everybody with source code access) and the average
> patch writer is that a POV-Team member takes the responsibility of a
> feature's bugs getting fixed and to make it bug free eventually.
>
(1) I did something against all bugs I found in POVRay where I could. 
    I remember only the parametric object bug and I looked into it a 
    month ago and sill do not know what to do about it. 
(2) You should read it like that: all the closed source & design 
    effords did not prevent the code from being as good as you would 
    like to have it. So...
 
> Sure, Mozilla never crashing, not consuming a gigabyte of memory and
> taking
> an hour to start up the first time.  Even Konqueror crashes if fed with
> the
> "right" page.  At least my "version" of it does.  And I tend to use IE 5.2
> to view pages in such cases.  Yet, compare Konqueror to Mozilla.  The
> first one is well structured with a simple yet powerful and considerate
> design, the later is a huge waste of compilation time with *much* more
> code to do
> the same thing.  Code quality is more than just not crashing.  In fact,
> crashing bugs are the easiest to find and solve.  The design on the other
> hand...
> 
[I won't feed the trolls here. Just a statement: I had more konqui 
crashes than mozilla crashes. Maybe because I am using beta versions 
from time to time.]

> Ah, yes, the other two high-profile projects showing clear signs of
> forking
> and serious code quality problems.  Of course, monolithic kernels are such
> a great idea, so they flaw must be elsewhere than in the fool who
> conceived it.
> 
[I don't feed the trolls here. And I would have liked you for not 
doing so as well.]

> CVS, sure.  Ever looked into the CVS source code?  
>
Yes, because it had some trouble with symlinks. 
And after doing so I thought one should make a complete re-write 
because the design is flawed. 
Then I wondered why so many people are using it. 

Wolfgang

Post a reply to this message

Christoph Hormann wrote:
> If you like this feature and therefore implement it that is of course
> all right, i just have the impression that you interpret the lack of
> interest in this patch as a lack of interest in people working on
> improving POV-Ray in general.
> 
No, stay assured that I do not. My impression is older. 

> - quality of the patch and its documentation
> - if it is regarded as useful and well usable by the MegaPOV Team
> - if there is interest in the patch among users
> 
> And in any case not for MegaPOV 1.1 which already contains more than
> enough new features.
> 
I was not thinking about partial image reading. 

But about things like my "radial slope pattern" (rather small and simple) 
or the "progressive refinement patch" (which would require somebody else 
write the windows/mac - related part). 

Especially, the latter may be considered useful by other people; there 
even once was a posting about someone demanding something similar being 
implemented. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:

> Anyway, let me rewrite this in my favorite and brutally honest style; but
> please don't it personal, I am just saying exactly what I am thinking:
> 
No problem. 

> I don't want to get personal, and I don't know your background, but if you
> think about bug fixes as "simple", you either never had to fix bugs, or
> you don't know anything about software development. 
>
Well, neither is true. I've been writing code during a decade now, 
currently O(1Mb) per year and I know that fixing the bugs in the code 
can take you 5 hours for something as stupid as a missing semicolon. 

What I was referring to with "simple bug fix" was a patch which 
does changes to O(1) lines to fix some bug and which is pretty trivial 
to understand. We had several such bugs in POVRay. 

It was to say that the patches are "simple" to understand and "simple" to 
integrate into the code. 

I did not say that they were "simple" to find. But for some of them 
even that is true because I accidentally found them because I read the 
code and not because I saw the bug appearing in program behaviour. 

> I know absolutely no
> professional (who I know isn't a fool, and even they usually have realised
> fixing bugs is hard) that considers fixing bugs something that is simple.
>
Fixing a bug which is only known by misbehaviour can be extremely hard. 
Fixing a bug which you see in the source code _can_ be extremely easy. 
Or it can open your eyes for a huge design flaw which demands a large-scale 
rewrite. I already had both cases myself...

> So, given I know very little about you, using only what you say to judge
> the validity of your arguments, your statement about "simple bug fixes"
> does not give those arguments much credibility...
> 
Then re-read them with my actual intend (as explained above) in mind :)

Wolfgang

Post a reply to this message