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

In article <lnm### [at] tritonimagicode>, chr### [at] gmxde 
says...
> 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.
> 
Actually it is more of an issue with an external program. It is called 
wasted time. It may only be 4-5 minutes, but it is still time you spend 
screwing with an external program (that may even crash in some cases with 
an image 1G in size), instead of doing a relatively trivial clipping of 
the image in the program you need to actually use the result in. I think 
it is a good option, but then I also can't afford on my system to 
generate x number of 100-200MB, or whatever, files containing all the 
images I clipped out, on top of the original 1G file. And if you are 
doing a panorama, where you may want/need those things to overlap, you 
may end up using 2G of extra space, tripling how much room the images 
take up, instead of merely doubling it. God forbid you don't have a DVD 
burner (such images won't fit on a CD-R) and you decide to make 30-40 of 
these images, each using a 1G file. Even the 80G hard drives most people 
can now get cheap won't last long in such a situation. lol Imho, this is 
actually a good idea.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Thorsten Froehlich 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. 

> 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.
> 
I cannot comment on that beause I did not see them. 
(And as other peple out here do not see them, they can hardly come up 
with something better.)

> 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...
>
[I am skipping this paragraph in an attempt to not feed the trolls.]
 
> 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. 

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

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

> 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.
> 
This is clear (although I think that "just converting" the parametric 
object will not be that easy...)

As you are talking about version 4.0, I think it should not only be 
a re-write but a re-design in that it allows several things being 
done which one would like to do with the current version but cannot 
due to design resaons. 
But probably design is already being discussed in the group?

>> 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.  
>
Correct. And my terms of "use" of software imply that I change that 
software in case it does not fit my use. 

> 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.  
>
These lists do by no means contain all issues which should be improved. 

My mode of contribution is to write something which is immediately 
useful for _me_and_ the other users. 

It is unlikely that I start writing a fix for the "fog+media" problem 
because I do not use fog. So this problem is simply irrelevant for me 
(at least currently). 

> 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...)

> 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.
> 
Then I am probably the third one :)

I did not look at the 
"Known bugs in POV-Ray version 3.5 that will be fixed in soon"
because it already says that obviously the solution already exists. 

The "Known bugs in POV-Ray version 3.5" either seem unimportant to 
me (superflouos warnings) or I have no clue about them (radiosity). 

About the "Bugs inherited from POV-Ray 3.1 and older versions", 
I read them, then thought that some more clever people failed to correct 
them and that I would try to fix and of them in case I actually 
hit one myself. As for the bugs in the parser, I'd suggest a complete 
rewrite anyways. 

>> 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.
> 
(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. 
(2) If some people do not want to take responsibility for their code 
    once it is included in povray, than that is sad. A solution has 
    to be found which does not hurt those people who behave "correctly". 

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

> 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.
> 
I was aware of these arguments before. 
The most basic idea against what I called "hindering" is to 
make available devel code (or at least beta versions) to those who 
want to "work". 

> In conclusion, contribute fixes for the real bugs that concern users, or
> quit complaining.
> 
Why not give people who want to do that the current code?

(I am not saying here that you send me the code and then I fix all the 
bugs -- just to be sure.) 

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. 

If I am the only non-team member thinking so, them this can be 
considered irrelevant by the team. But most people doing code review 
or open source development will probably consent. 

But probably nobody will read these lines because the posting is too long.

Wolfgang

Post a reply to this message

In article <4012a910@news.povray.org>, wwi### [at] gmxde says...
> Christopher James Huff wrote:
> 
> >> Basically, the patch allows you to select a rectangular region of
> >> an image_map so that only this part is read in and stored in RAM.
> >> Pixels outside this region are all considered 50% gray (some other
> >> solution like quick_color could also be thought of).
> > 
> > Pixels outside that region should probably be fully transparent, to be
> > consistent with the "once" option. 
> >
> I would prefer the pixels to be of configurable color...
Considering that 'color' can be rgbf <1,1,1,1>, I would have to agree 
there. You want transparent, make it transparent. lol

> 
> > And why not read in the region as the
> > entire image, filling the entire area of the image_map? Simpler, and
> > avoids the above problem completely.
> > 
> I do not completely understand what you plan there but it seems to me 
> that this requires the used to do additional scaling and 
> rotation/translation of the texture (which may not be trivial for 
> some projections). 
> Furthermore, for my current personal use, the 50% gray is a "feature" 
> (sea level on Mars). 
However, I agree with Christopher's view that actually clipping the image 
completely, instead of filling the rest of a color, could be better for 
some uses. Like an actually image map, instead of the what you are doing 
with it. It wouldn't necessarily require extra scaling and the like, 
since in this case you would be using the clipped region as though it was 
the complete image, so in some situation like an animation you just move 
the clipping you plan to do in the direction you want and that becomes 
the new image. POV-Ray would save memory a lot by only loading the region 
piece of the image it actually needs, instead of the whole thing.

I am still not 100% sure what you are actually doing in the case of your 
patch, the only explanation you give is a vague reference to "(sea level 
on Mars)", which doesn't say if you are using it as a) and image map, b) 
a height field, c) some other thing... You might have better luck 
convincing people that filling the image, instead of simply clipping is 
better, if we had an example of what you are doing with it. ;)

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

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

> > Pixels outside that region should probably be fully transparent, to be
> > consistent with the "once" option. 
> >
> I would prefer the pixels to be of configurable color...

This would be a good option. And ideally, one would be able to specify 
both the domain (the area of the input image used) and the range (the 
area it maps to). Another possible feature would be to allow specifying 
the resolution to store the image as...maybe you need a low res version 
for some uses. The ability to reference frames of an animation for image 
maps would be nice. So would the ability to refer to specific channels. 
But none of this is going to make it into 3.6, it's just too late.

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

Patrick Elliott wrote:
> 
> Actually it is more of an issue with an external program. It is called 
> wasted time. It may only be 4-5 minutes, but it is still time you spend 
> screwing with an external program (that may even crash in some cases with 
> an image 1G in size)[...]

Sorry but this is complete nonsense, i have been cutting subsets from 
large images for a long time now and it does not take any longer than to 
parse such images in POV (why should it - it is essentially the same 
operation).  And the  memory use while doing that is minimal.

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