20 Nov
2010
20 Nov
'10
7:40 p.m.
Who the hell do you think you are?! The day I'll need lesson, don't worry I know
who you are and where to find you.
I won't waste my time answering. Understand whatever you want, imagine whatever you
want.
Just for your information:
http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/in…
And be sure I'll question your commitment whenever it's needed.
"Discussion" is over for me.
Hi,
It appears your arguments are because you don't seem to understand what you have done
wrong.
Let me spell it out:
" I know that r49463 only added INIT_FUNCTION to HAL, but I reverted both, just to
be sure. I can get back ntoskrnl as they don't seem to be concerned."
ie:
"I know that my fix went beyond what was needed, but I did it anyway "just to
be sure"".
ie:
"I know that A is impossible, yet I check for A anyway" -> logical fallacy
Next:
"- This has never be presented as a fix (but as a test)"
Yet your email said "this will not be reverted". A test, by definition, should
be reverted. Again, logical failure.
Next:
- Win32k INIT_FUNCTION is not defined for GCC
(only for MSVC)
Strange, because Timo used objdump to let me know how big the .INIT section was. Maybe he
was lying, I don't have information, so I'll pass.
Next:
- Testbot is now stuck in ARM³ MM bugs
I can't seem to access builds.reactos.org to check, but I think this argument really
nails it: you really don't get it (you don't get the scientific method).
You've just proven that the test samples are corrupted (ie: the compiler is broken),
and now you expect me to hunt for bugs (ie: you expect me to analyze test results on
samples that are now corrupted).
The answer is no, I will not fix "bugs" which might be due to a broken
compiler. Fix the compiler, than I'll spend time hunting bugs.
- You are away after breaking trunk (as usual)
How am I away? I've been posting to this mailing list, haven't I? I've been
working on ARM porting, which, in case you don't know, is my job. I've posted
screenshots of FreeLDR booting up on a real ARM board (I don't think you understand
the complexity involved). I've almost got the keyboard working. The fringe benefits of
C changes and new memory management code, which don't seem to be appreciate, are just
bonuses out of the kindness of my heart, and they set back my port significantly. It was
booting to user-mode with the old memory manager, now much of the work had to be
restarted/refactored (obviously, it benefits the ARM port too, but I could've skipped
this and done it the easy way).
My last 20 commits or so have ALL been bug fixes, and I still have more in the pipeline.
I've fixed bugs that were more than 10 years old.
Don't ever question my commitment again.
- Said "_Some_ people" include our
testbot and some of our devs
That's _exactly the point_. You've obviously got a strange
system/os/host/compiler issue going on, which is why it works for some, but not for
others. I wasn't saying there isn't a problem, I was saying the problem is subtle
and could be responsible for other subtle "bugs" as well. You're ignoring
this, and forging ahead (with corrupted test samples). What is this, the movie Splice?
By your analysis, because GCC is broken, we should only use MSVC. I refuse to do so (and
MSVC has its share of bugs). This "feature" is called PE sections. So you are
saying GCC cannot/fails at generating PE sections. In other words, we can't use .data,
.rsrc, .idata, etc anymore. In other words, the compiler is 100% broken and cannot be
used. How do we know it's not failing because putting stuff in a different section
doesn't somehow corrupt the code? Well, that means that it's also possible for
code/data in .data, or in .idata to get corrupted in the exact same way. In other words,
the compiler is broken and WE CAN'T TRUST ANYTHING.
Finally "> - Being mean won't fix anything".
Don't be a child. I was being harsh on your premise, to, I quote "not revert the
commit", which implied that "well, the compiler is broken, but we'll just
ignore that and assume there's no other side effects". Being "mean" is
an entirely different emotion and outside the scope of the technical/professional
communication I'm attempting to have with you. I am trying to educate/teach you. Being
mean (and unprofessional) would've involved reverting your changes and calling you an
idiot (I never once attacked you personally -- I called your decision braindead, that is
different).
-r
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev