@JuhaManninen
“You have provided 5 patches. Most of them were minor cleanup and useless formatting.
Still almost all of them were applied, as a sign of good will and to encourage you to also fix bugs.
For example this one I applied against Vincent's will :”
This means that you deserve an explanation.
In order to explain you'll need more than two minutes to read, but that's nothing compared to my efforts of writing this.
"Lagprogramming, can you please explain why you don't fix any of those bugs?"
1) We don't share the same interests. You are interested in closing as many bugs possible, I'm interested in code execution speed.
I lost hope in a good lcl many years ago. The antidote I have for the bugs: I use only basic components and even those might be overridden. For example, a TListbox might be completely drawn by my application(100%, even the text characters don't depend on existing fonts installed). At this level I doubt that mantis bugs will affect me much.
So, I don't have a personal interest in closing mantis bugs.
But this means I'm interested in speed, obviously I've found lots of things that can be improved both in Fpc and Lazarus, things that I've considered can be applied without a big effort from main developers. This is the reason why there were PROPOSALS of minor modifications. If these minor changes are not welcome, what about the big ones!? Those were PROPOSALS, nothing more. I don't expect you to agree with them, you just accept them or not, I don't feel offended no matter what decision you take.
2) You have many bugs that apparently share the same source, but the way lcl is designed makes debugging very hard and you know it. This is why I consider it's useful to pinpoint the areas with problems. Even a function result that may not be assigned is important because nobody can say what is the impact on the bugs(filled or not within mantis). But simply pointing such minor problems will make main developers pretend a patch from the reporter or even worse(developers closing tickets not only without solving the problems, but stating that it's not a problem at all). So, not only that I don't have a reason to fix bugs, but now I have no reason to report within mantis my findings.
3) Many bugs hide additional problems, problems that are hard to spot. Look at the comment I've done at the “0021589: TBitmap.SaveToFile does not work with monochrome Bitmaps” report. It's enough to add 10 characters in the source file to close the ticket, but I've noticed additional problems there. Closing the ticket will hide those problems and again many years might take to implement 64bit bitmaps there. People won't know where is the problem. The transparent bitmaps, again, it remains a workaround, because the original function is so ugly I'd rather stare at the sun than at it. Why should I offer a patch to main developers with a workaround for the bug, knowing that the patch will make even harder to debug other bugs(including not yet reported ones). Also, in my work I don't connect my findings with existing bug reports. For example, I remember that there was a function that didn't created a palette for monochrome bitmaps I think, but without connecting this situation with a ticket, I would have disturbed main developers again. Later I've found another ticket something related to a form save or load, I don't remember now exactly, it was related to monochrome bitmaps.
4) You complain about those minor proposals. If you accept a proposal, I have to keep track of it until next stable release and immediately after for a while. That takes me much more time than you need to analyze the proposal. So, each time I propose something to you, if you accept the change I'd have to work harder than you. For example, between the last stable Lazarus and trunk only about 10 functions/procedures have been modified by both me and main developers. The files presented have more than 200 modifications. Do you realize what would happen if I'd propose all of them to you and you'd accept all of them, each and every one of them with minor variations!?
)
“Instead you blame the developers for treating you bad, which is nonsense.”
I don't blame developers for not sharing the same interests or the same points of view. At the same time main developers should accept that I can offer support to the community without their help. However I can't say that I'm very happy with situations like:
Proposal report for zero and near zero comparisons where main developer says that it's fixed.
“0026794: Slow code generated for for near zero{-1,1} comparisons [feature]”
New report without any response.
“0026925: "For" loops optimizations proposal [feature]”
I tell you what this means. I've written code according to what the main developer said and after a while I've discovered that the code produced was not optimized. I had to modify again the code to manually optimize the zero comparisons. A lot of work for what, and some of you complain about 2 minutes?! Is this reasonable?!
What about this report.
“0026089: Slow code generated for if...then...else”
The support for the workaround came from ordinary developers like me, not from the main ones. That's not a problem, however, the discouraging attitude of the main developers is something unpleasant but probably necessary
. Main Lazarus developers do the same, so it's not like I lack experience in this field.
Last time I've checked the following function was 15 times faster than original.
function TFPReaderBMP.CountBits(Value : byte) : shortint;
var i : shortint;
begin
result:=0;
for i:=0 to 7 do
begin
if (value and byte(1))<>0 then inc(result);
value:=value shr 1;
end;
end;
Why should I fill a ticket knowing that my proposals are not welcome?!
“Do you now feel insulted because I mentioned that formatting changes are not important and we would need bug fixes instead?”
We have different understandings regarding formatting. By formatting change I understand lines, spaces, comments...modifications that don't influence binary produced code.
Formatting change:
1)var x:integer
y:integer;
2)var x,y:integer;
Examples when binary code produced differs(meaning that it's not just a formatting change in my point of view):
1)Begin x:=10;if y=0 then exit;z=6;end;
2)Begin if y=0 then exit(10);z=6;end;
or
1)if pointer=nil then Result:=0 else Result:=1;
2)if pointer<>nil then Result:=1 else Result:=0;
Personal conclusions:
I think there are few Fpc/Lazarus main developers really active. Looking at the code and at the attitude I have reasons to believe that the number won't greatly increase in the future. I consider Fpc rtl sources structured and optimized much better than Lazarus's lcl. I realize that a new developer might have a shock looking at the lcl. I think the way the code is structured is prone to bugs, reason why you have so many reports, bugs that are harder to pinpoint compared to fpc's rtl ones.
Example regarding code structure:
procedure DefaultReaderDescription(AWidth, AHeight: Integer; ADepth: Byte; out ADesc: TrawImageDescription);
The way it's structured, is prone to bugs. There are many routines like this one. This procedure needs total rewrite in my point of view. The files provided by me contain a workaround for one of the reports(static text I think) where this procedure has been modified, but the solution lies in rewriting the procedure so that you won't initialize with default 24bit values and after that modify some of those values as it does now.
“I did not look at your code now but I don't believe it fixes any bugs.
Otherwise you would have mentioned it clearly.”
Anyway, the modifications are not done for main developers and are not intended to close bugs. These correlations appeared as a side effect. Also, I don't need reviews from main Lazarus developers regarding the code modified by me as I know very well what I've modified and why. I just offer an alternative to those that need a little bit of snappiness from the lcl and some additional informations to main developers that may be interested. FOR MAIN DEVELOPERS THE PASCAL CODE IS USELESS, IT'S THE FINDINGS THAT MAY MATTER, like those in P.S.. If I do it in mantis you disagree because I occupy your time, if I do it on the forum you also disagree. It's not like I earn something from any of you, and also you are free to take whatever you find useful from my modifications. I don't care if any of you uses anything at all from these files, meaning that I also don't care much about texts like:
“After that we can talk about what you should do to make your changes available to the main developers in way that they will be interested to spend some time in validating your solution, but as it is now you have no chance on people looking at your code.”
P.S.
I wrote this text off-line so I don't know if I mentioned these before:
procedure TBitmap.LoadFromStream(AStream: TStream; ASize: Cardinal);
It might not work when “{$IFDEF ENDIAN_BIG}”. Swap might require to be treated as a function not a procedure.
function TWinControl.SendDialogChar(var Message : TLMKey): Boolean;
Original function didn't always returned result. Could it be related to a bug, something like: when I open the program if I keep shift pressed the key is not detected, or something like that?!
function TGtk2WidgetSet.GetClipBox(DC : hDC; lpRect : PRect) : Longint;
What happens if "lpRect=nil and IsValidDC(DC)??? TGtk2WidgetSet.GetRgnBox checks for nil better than this function.
function TGtk2WidgetSet.GetClipRGN(DC: hDC; RGN: hRGN): Longint;
A bug may be introduced here. It is advertised that the function has to return values {-1,0,1} but default value is 2(SIMPLEREGION).