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/include/win32kp.h?revision=49580&view=markup 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 > [email protected] > http://www.reactos.org/mailman/listinfo/ros-dev _______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
