Thorsten,

I am becoming increasingly upset with you attiude towards other programmers.
"Ignorance", "broken compilers", etc. is all I hear most of the time. I have
been professionally programming for more than 12 years, and have developed 2
commercial compilers among other stuff. So the word "ignorance" is not what
I would like to hear in a responce to a viable suggestion.

I demand that you soften your stance.

Wake up, Thorsten. You're part of the POV-Ray community, but you're starting
to ignore all but the most trivial inputs. And this starts to worry me a
lot, since the POV-Ray is seamingly completely in your hands.

I could defend each and every my point; at the very least, as viable
alternatives -- but this is becoming almost impossible, as you are becoming
increasingly hostile. I prefer to listen rather than to speak, but on all
those few occations that I spoke, you appeared to be deaf (your right, so
it's OK :-) and offensive. Previously, I used to just give up (although
always have had more to say to defend my point) and just save my nerves...
but this time it just gone too far.

Could you pleas just "discuss", and not "explain" as you always do?

ABX has provided a better-style alternative to your code. I seconded that,
and gave my reason why I really think this code is a BETTER QUALITY code (==
following what is often referred to as "good programming habits"). NOT more
or less "correct" / "broken" etc. given its CURRENT use in POV-Ray. The
integer values of sequences like (('a'<<8)|'b') are NOT implementation
dependent AS LONG as we stick with ASCII (i.e. the only implementation
dependent things are integer values of 'a' and 'b'). With multi-character
constants, endianness comes into play as well.

I can reword my point this way: if you use multi-character constants, then
integer value of the constant depends upon BOTH character values and
endianness of the target machine. If you use defines (similar to FOURCCs),
then integer value (NOT internal representation of that value!) of the
expression depends upon JUST character values. Therefore, I consider the
latter code of a better quality. And if two compilers both use ASCII for
character representation (and have at least 32-bit longs, of course), then
yes, the read/write code I quoted is portable, even regardless of the
endianness of the target platform. How many C/C++ compilers out there are
not using ASCII codes for alphanumeric characters these days? What
compilers/environments were you talking about?

If you do believe some/all of my points are not valid, I would be glad to
hear from you. But PLEASE be more specific and less personal.

Regards,
Vadim.

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3d998790$1@news.povray.org...
> In article <3d9980e2$1@news.povray.org> , "Vadim Sytnikov"
<syt### [at] rucom>
> wrote:
>
> > 1) generates less warning messages and thus
>
> It only generates warnings on broken compilers.  If the compiler you use
is
> broken, the solution is to switch to a compiler which is not broken or to
> workaround the broken compiler by disabling the particular warning by
hand.
>
> > 2) is less likely to fail.
> <snip>
> > As to the second... Thorsten, believe it or not, compiler writers are
not
> > idiots. Not all of them. There ARE cases when simple multi-character
> > constants would not work, while #defines or similar means would rectify
the
> > situation...
>
> No, this is nonsense.  They do work as specified everywhere!
>
> Your example is yet again one of those reading data from disk misuse
cases.
> Maybe you do not understand that "implementation defined" is exactly what
> you show?  It does not even have to work when using two compilers on the
> same platform.  An "implementation" is a single compiler on a single
> platform.
>
> Maybe you have not noticed, but POV-Ray neither reads nor writes
> multicharacter constants.  It does not because that behavior is
> implementation defined.  So there is absolutely nothing wrong and nothing
> that can ever break anywhere either.
>
> >   unsigned long prog = FOURCHARS_TO_INT('A','B','C','D');
> >   fprintf(outfile," %lu", prog);
> >   ...
> >   fscanf(infile," %lu",&prog);
> >   if( prog==FOURCHARS_TO_INT('A','B','C','D')) { ... }
> >
> > This code would work ACROSS MOST platforms. While alternative (your)
> > approach would fail if files are to be transferred between e.g. PCs and
old
> > Macs (with their Motorola 68k BE CPUs). And even if we are to port it to
> > some EBCDIC-based dinosaur, we still can just modify the macro
definition
> > accordingly, not every piece of code dealing with constants. So the code
is
> > MORE portable and thus BETTER. Please note: not "absolutely portable and
> > thus the BEST", but still worth trying.
>
> I am not really sure if I should be upset or offended by such ignorance as
> this issue has already been discussed and explained well in this thread.
> Please read the whole thread first before repeating something already
> discussed.  If you don't want to read the whole thread, please stop adding
> noise to the discussion.
>
>
>     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 <3d999f1b$1@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> If you do believe some/all of my points are not valid, I would be glad to
> hear from you. But PLEASE be more specific and less personal.

Let me explain this first.  I do not and cannot know what you know or don't
know.  I can only judge from what I see here.  And that is simple.  There is
a list of known problem as <http://www.povray.org/download/3.5-bugs.php>.  I
can tell that you have done nothing to fix any of those bugs and contribute
those fixes anywhere, so your contribution to the POV-Ray source code is
zero.  There is nothing wrong with that, what you do with your free time is
your business.

However, if a discussion, rather then focusing on what really needs to be
fixed starts to go into "this code is no good and that code is no good and I
don't like this and I don't like that" and you waste time making it look
like you like it, well, then you are definitely concentrating on the *wrong*
aspect of programming and contributing to POV-Ray.  What you do in your code
is your business, but maybe it occurred to you that bringing POV-Ray to you
requires some understanding of programming and I think all POV-Ray team
members have proven the ability to make a cross-platform application.

Then someone comes along and tells us what we should have done.  Now, what
do you say if someone goes along your code, without actually looking into
for what it does and what it is not even supposed to do and starts
complaining despite there being no real problem.

It is always easy to complain; it is much harder to create something.

> I am becoming increasingly upset with you attiude towards other programmers.
> "Ignorance", "broken compilers", etc. is all I hear most of the time. I have
> been professionally programming for more than 12 years, and have developed 2
> commercial compilers among other stuff. So the word "ignorance" is not what
> I would like to hear in a responce to a viable suggestion.

Well, I had explained for what the multicharacter constants are being used,
and if you had bothered to read the thread or check the source code you
would have known that your argument simply misses the point completely.

> Wake up, Thorsten. You're part of the POV-Ray community, but you're starting
> to ignore all but the most trivial inputs. And this starts to worry me a
> lot, since the POV-Ray is seamingly completely in your hands.

Well, why should I fix something that is not broken when there is a list of
things that are broken.  With your attitude of development we would still be
at POV-Ray 0.1 or be releasing buggy software with well-looking code.

Neither is reasonable.  It is not my responsibility to defend anything in
the POV-Ray source code unless you can show that in the way it *is* used
will not work.  And there have been such problems like the "long" in the
octree float trick code that really was not portable.

I do not care for the tons of hypothetical or impractical or already known
to be wrong examples given in the whole thread of discussion.

Oh, and as a matter of fact, multicharacter character codes have worked fine
on Macs since 1984.  And they work well elsewhere, even Windows!  So you
obviously have no broad foundation of experience with cross-platform code.
You claim that what is used in millions of programs is not possible.  How
could I possibly take you serious given this fact?

> I can reword my point this way: if you use multi-character constants, then
> integer value of the constant depends upon BOTH character values and
> endianness of the target machine.

Well, I have been saying it is implementation defined all along.  So I am
not sure why you repeat it.

I can reword my point this way:  If you want to teach people what you think
is good coding style, feel free to do so, but don't dare to teach me _your_
coding style on _my_ turf ;-)


So can we end this endless and useless complaining now and get back to
fixing real problems...?


    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

I have to say that the first paragraphs, once again, sound like a (this
time) polite way to tell "shut up"...

The real (yes, real) problem is the number of warnings 3.5 generates. I just
tried to defend an easy way to get rid of some of them. It's up to you to
follow, or not follow suggestions, to respond or not respond at all; but
please do not get personal/offensive IF you do respond.

P.S. Although close to EPSILON, my input is not zero; Alan Kong may still
keep my posts describing several bug fixes to POV 3.02 that made it into the
official code. Plus ftp://ftp.ru.com/pub/gamos/povpro/. Not much. So what?
As Ron once wrote, "should I get a lawyer?"

"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3d99a644@news.povray.org...
> In article <3d999f1b$1@news.povray.org> , "Vadim Sytnikov"
<syt### [at] rucom>
> wrote:
>
> > If you do believe some/all of my points are not valid, I would be glad
to
> > hear from you. But PLEASE be more specific and less personal.
>
> Let me explain this first.  I do not and cannot know what you know or
don't
> know.  I can only judge from what I see here.  And that is simple.  There
is
> a list of known problem as <http://www.povray.org/download/3.5-bugs.php>.
I
> can tell that you have done nothing to fix any of those bugs and
contribute
> those fixes anywhere, so your contribution to the POV-Ray source code is
> zero.  There is nothing wrong with that, what you do with your free time
is
> your business.
>
> However, if a discussion, rather then focusing on what really needs to be
> fixed starts to go into "this code is no good and that code is no good and
I
> don't like this and I don't like that" and you waste time making it look
> like you like it, well, then you are definitely concentrating on the
*wrong*
> aspect of programming and contributing to POV-Ray.  What you do in your
code
> is your business, but maybe it occurred to you that bringing POV-Ray to
you
> requires some understanding of programming and I think all POV-Ray team
> members have proven the ability to make a cross-platform application.
>
> Then someone comes along and tells us what we should have done.  Now, what
> do you say if someone goes along your code, without actually looking into
> for what it does and what it is not even supposed to do and starts
> complaining despite there being no real problem.
>
> It is always easy to complain; it is much harder to create something.
>
> > I am becoming increasingly upset with you attiude towards other
programmers.
> > "Ignorance", "broken compilers", etc. is all I hear most of the time. I
have
> > been professionally programming for more than 12 years, and have
developed 2
> > commercial compilers among other stuff. So the word "ignorance" is not
what
> > I would like to hear in a responce to a viable suggestion.
>
> Well, I had explained for what the multicharacter constants are being
used,
> and if you had bothered to read the thread or check the source code you
> would have known that your argument simply misses the point completely.
>
> > Wake up, Thorsten. You're part of the POV-Ray community, but you're
starting
> > to ignore all but the most trivial inputs. And this starts to worry me a
> > lot, since the POV-Ray is seamingly completely in your hands.
>
> Well, why should I fix something that is not broken when there is a list
of
> things that are broken.  With your attitude of development we would still
be
> at POV-Ray 0.1 or be releasing buggy software with well-looking code.
>
> Neither is reasonable.  It is not my responsibility to defend anything in
> the POV-Ray source code unless you can show that in the way it *is* used
> will not work.  And there have been such problems like the "long" in the
> octree float trick code that really was not portable.
>
> I do not care for the tons of hypothetical or impractical or already known
> to be wrong examples given in the whole thread of discussion.
>
> Oh, and as a matter of fact, multicharacter character codes have worked
fine
> on Macs since 1984.  And they work well elsewhere, even Windows!  So you
> obviously have no broad foundation of experience with cross-platform code.
> You claim that what is used in millions of programs is not possible.  How
> could I possibly take you serious given this fact?
>
> > I can reword my point this way: if you use multi-character constants,
then
> > integer value of the constant depends upon BOTH character values and
> > endianness of the target machine.
>
> Well, I have been saying it is implementation defined all along.  So I am
> not sure why you repeat it.
>
> I can reword my point this way:  If you want to teach people what you
think
> is good coding style, feel free to do so, but don't dare to teach me
_your_
> coding style on _my_ turf ;-)
>
>
> So can we end this endless and useless complaining now and get back to
> fixing real problems...?
>
>
>     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 <3d99b4fb@news.povray.org> , "Vadim Sytnikov" <syt### [at] rucom>
wrote:

> The real (yes, real) problem is the number of warnings 3.5 generates.

It simply depends on the compiler and settings you use.

    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:
> 
> [...]
> 
> I do not care for the tons of hypothetical or impractical or already known
> to be wrong examples given in the whole thread of discussion.

I have no way enough knowledge about the matters discussed here to form a
justified opinion, but in the end it really does not matter much who is
right and who not about these specific questions.

What i have been missing in your posts of this thread is a statement of
understanding to those who compile POV-Ray with gcc every day and
therefore have problems with all those warnings without any conncetion to
the reason of the warning in the first place.  To me it seems that both
ABX and Vadim respect your opinion on the matter of the warnings and their
reasons but your arguments would probably be much better received if you
better show your understanding of someone's motives for working and making
thoughts on that matter.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3D99CB0F.5DE476A8@gmx.de> , Christoph Hormann 
<chr### [at] gmxde>  wrote:

> What i have been missing in your posts of this thread is a statement of
> understanding to those who compile POV-Ray with gcc every day and
> therefore have problems with all those warnings without any conncetion to
> the reason of the warning in the first place.  To me it seems that both
> ABX and Vadim respect your opinion on the matter of the warnings and their
> reasons but your arguments would probably be much better received if you
> better show your understanding of someone's motives for working and making
> thoughts on that matter.

Well, reading the documentation of gcc suggests to use "-Wno-multichar" as a
command line option to turn those warnings off.  In fact it can be found in
all versions of the gcc online documentation at

<http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC8>
<http://gcc.gnu.org/onlinedocs/gcc-3.0.4/gcc_3.html#SEC11>
<http://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/Warning-Options.html#Warning%20
Options>
<http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Warning-Options.html#Warning%20Op
tions>

Really trivial, if you ask me.  I could find it within seconds at the place
I would expect it (warning command line options) yet I really do not use gcc
frequently at all.

It is also trivial to find in google, which returns currect help for this
problem at least behind every link of the first three result pages!

<http://www.google.com/search?q=multicharacter+constant+gcc+warning>

So it is really not difficult to turn it off and no longer have any
problems.  And indeed, if it is that easy to turn off, I do not understand
their problem with 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

"Vadim Sytnikov" <syt### [at] rucom> wrote in news:3d99b4fb@news.povray.org

> The real (yes, real) problem is the number of warnings 3.5 generates. 

-w 

:) ?

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Vadim Sytnikov <syt### [at] rucom> wrote:
> The real (yes, real) problem is the number of warnings 3.5 generates.

  I have to go to Thorsten's side in this: I don't really see how
this is a "real problem".
  As far as I know, none of the warnings is about code which is buggy
and does not work as expected. Of course this doesn't mean that most
of the warnings could not be handled (eg. by making double -> int
conversions explicit), and IMHO it would be good if this was done
(to make the code cleaner) but those are just minor details, not major
problems, as you are implying.

  The only problem I personally have with them is that the warnings
flood my terminal when I'm compiling POV-Ray. Not a major problem.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote:
>   I have to go to Thorsten's side in this: I don't really see how
> this is a "real problem".

This is how: I have a lot of my own modifications, and am constantly working
on new ones. For you to understand the degree of those modifications, I
would list some of them here:
- it is a Win32 console executable (running with detached console, i.e. w/o
standard Win32 character console),
- output to hi-color (16-bit) DirectDraw full-screen window,
- own custom console *within* that window,
- own means of synchronization with other Win32 applications (set of Events,
plus a memory-mapped file),
- numerous own patches (representing major modifications to POV-Ray; like,
say, building density maps),
- etc.

Once again, I'm constantly working on that, making my own (sic!) errors in
the process. Common sense (as well as many years of experience) suggests
that I do not turn off warnings, since absolute majority of them are indeed
very helpful in spotting bugs. Just as I said on a number of accations,
compiler writers are not idiots.

And now I have to use Tcl/Tk scripts for my build procedure to sort out
warnings. Tell me, is that OK?

Post a reply to this message

Vadim Sytnikov wrote:
> 
> "Warp" <war### [at] tagpovrayorg> wrote:
> >   I have to go to Thorsten's side in this: I don't really see how
> > this is a "real problem".
> 
> This is how: I have a lot of my own modifications, and am constantly working
> on new ones. For you to understand the degree of those modifications, I
> would list some of them here:
> - it is a Win32 console executable (running with detached console, i.e. w/o
> standard Win32 character console),
> - output to hi-color (16-bit) DirectDraw full-screen window,
> - own custom console *within* that window,
> - own means of synchronization with other Win32 applications (set of Events,
> plus a memory-mapped file),
> - numerous own patches (representing major modifications to POV-Ray; like,
> say, building density maps),
> - etc.
> 
> Once again, I'm constantly working on that, making my own (sic!) errors in
> the process. Common sense (as well as many years of experience) suggests
> that I do not turn off warnings, since absolute majority of them are indeed
> very helpful in spotting bugs. Just as I said on a number of accations,
> compiler writers are not idiots.
> 
> And now I have to use Tcl/Tk scripts for my build procedure to sort out
> warnings. Tell me, is that OK?

One could argue that if you are doing such serious work with the POV-Ray source
code then it might benefit you to use the same development tools that the
POV-Ray developers use, thereby avoiding any potential warning messages from the
original code base. The POV-Ray developers cannot in anycase be expected to
aniticipate how the source code will behave on compilers that they themselves
do not use and expecting them to is unrealistic.

-- 
Ken Tyler

Post a reply to this message