Re: [Lazarus] Large program size - 1.8 MB for empty GUI project (uses clause in initialization vs implementation?)
Florian Klaempfl пишет:
This could be simply the influence of a different memory layout of the exe.
It seams that I was wrong. So. Lets do next small test.
The main program is:
program small_test;
{$mode objfpc}{$H+}
uses
Unit1;
begin
Print_Hello_Word;
end.
Uni1.pas is:
Unit unit1;
{$mode objfpc}{$H+}
Interface
Uses
Graphics, SysUtils;
Procedure Print_Hello_Word;
Implementation
Procedure Print_Hello_Word;
Begin
WriteLN('Hello, word! Value is: '+IntToStr(23));
End;
end.
As you see - Graphics unit is really unused here.
Compiler is called this way:
#!/bin/bash
ppc386 -Mfpc -CX -OpPENTIUM -TLinux -Pi386 -XX -Xs -vewnhim -Fu.
-Fu/usr/share/lazarus/ideintf/units/i386-linux/
-Fu/usr/share/lazarus/lcl/units/i386-linux/
-Fu/usr/share/lazarus/lcl/units/i386-linux/gtk2/
-Fu/usr/share/lazarus/packager/units/i386-linux/ -FU/tmp/
-o/tmp/small_test "./small_test.pas"
So - the code is Smart Linkable (-CX), the symbols are stripped (-Xs)
and binary should be linked Smart (-XX).
As a result we will see binary file with the size of 1 MB. ;)
Without Graphics in Uses section we will see binary with the size of 75KB.
Actually - no matter where Graphics unit is listed - the size will be
1MB both for Interface and Implementation sections.
So. The conclusion is: Smart Linking process can not remove
unused unit code. No matter where it is listed - ether in Interface
section or in Implementation section. And we should check all
our sources to cleanup unused units manually.
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Large program size - 1.8 MB for empty GUI project (uses clause in initialization vs implementation?)
Alexey S. Smirnov schreef:
Florian Klaempfl пишет:
This could be simply the influence of a different memory layout of the exe.
It seams that I was wrong. So. Lets do next small test.
The main program is:
|program small_test;
{$mode objfpc}{$H+}
uses
Unit1;
begin
Print_Hello_Word;
end.|
Uni1.pas is:
|Unit unit1;
{$mode objfpc}{$H+}
Interface
Uses
Graphics, SysUtils;
Procedure Print_Hello_Word;
Implementation
Procedure Print_Hello_Word;
Begin
WriteLN('Hello, word! Value is: '+IntToStr(23));
End;
end.|
As you see - Graphics unit is really unused here.
No, the initialization section of the graphics unit and its dependencies
is used. The lesson is: you cannot smart link away initialization (and
finalization) sections of a unit.
Vincent
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Large program size - 1.8 MB for empty GUI project (uses clause in initialization vs implementation?)
Vincent Snijders пишет: No, the initialization section of the graphics unit and its dependencies is used. The lesson is: you cannot smart link away initialization (and finalization) sections of a unit. Vincent But result is very understandable - if we have some unused units (with Initialization section) listed in "Uses" - our code can be 10 times bigger! IMHO - this is main question of the subject of the discussion - "Large program size - 1.8 MB for empty GUI project". So. Ones more - to reduce Lazarus-aware projects code size we shall first check and cleanup "Uses" sections to remove unused units, and next - test Initialization and Finalization sections. Do we really need them? For the Dephi times I remember that those sections were strictly optional and even deprecated. May be there are some other way to initialize global vars and structures? Regards, Alexey. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Large program size - 1.8 MB for empty GUI project (uses clause in initialization vs implementation?)
Alexey S. Smirnov wrote: So. Ones more - to reduce Lazarus-aware projects code size we shall first check and cleanup Uses sections to remove unused units, and next - test Initialization and Finalization sections. Do we really need them? For the Dephi times I remember that those sections were strictly optional and even deprecated. Nope, that was the begin..end. in units. For dlls you're right (iirc) Marc ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Large program size - 1.8 MB for empty GUI project
Marco van de Voort wrote: If Lazarus as the most major user starts avoid these problems instead of reporting them, that is worrying. Paul more or less proves the point with 2 bugs in a version cycle of which one is inlining related. Another known and workarounded in lazarus problem: http://bugs.freepascal.org/view.php?id=13481 Sometimes it is very difficult to avoid it. Best regards, Paul Ishenin. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] subversion mirror
On Thu, Apr 9, 2009 at 11:12 AM, Vincent Snijders vincent.snijd...@gmail.com wrote: Every minute. Vincent Thanks. Doesn't that keep the main server very busy? Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] USB Commincation with Lazarus and libusb library
2009/4/8 Sébastien FLOURETTE sebastien.floure...@gmail.com I have test the test program libusb in C and it work perfectly because I have the list of my device :Dev #0: 05AC - 8005 Dev #0: 05AC - 8005 Dev #0: Apple, Inc. 05AC- Apple Internal Keyboard / Trackpad 0002 Dev #0: http://www.roboticus.org 04D8- USB HID Firmware example - http://www.roboticus.org 0002 Dev #0: 05AC - 8006 Dev #0: 05AC - 8006 Dev #0: 05AC - 8005 Dev #0: 05AC - 8005 Dev #0: 05AC - 8005 Dev #0: 05AC - 8006 Dev #0: Sony 054C- Storage Media 0002 in blue is my board but when I do it on lazarus it don't work. There is options of compilation or specific parameters in lazarus ?? Thanks you for your help Sébastien Le 8 avr. 09 à 15:05, Henry Vermaak a écrit : 2009/4/8 Sébastien FLOURETTE sebastien.floure...@gmail.com: I try that you tell me but the result is not good. so what was the result of the libusb test program in c? do you have permissions to use the device? Have you got an example of use libusb on Lazarus. Perhaps I have a parameters or other is not good. If you have can you send me it. i already pasted the relevant code, there's nothing else that's different in my code. it works for me in linux. you might have to make a test program in c and ask for help on the libusb list. henry -- Bonne journée Sébastien FLOURETTE 1er Etage, 1ère Porte Droite 35, Rue Emile Goeury 94140 ALFORTVILLE 06-74-67-53-44 ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Git mirror of Lazarus SubVersion repository is available
Hi Everybody, A while back I setup a private Git mirror of the Lazarus SubVersion (trunk only) repository. This was for my personal use. Since then I thought others might enjoy a Git mirror as well. Seeing that our company has limited internet bandwidth I decided to move the mirror repository to a more public place. The Git mirror is hosted on GitHub at the following URL and is sync'ed with Lazarus SubVersion trunk every 15 minutes. git://github.com/graemeg/lazarus.git The Lazarus Trunk (exact duplicate) is mirrored in the 'upstream' branch which I'll explain shortly. I just completed a repository clone from GitHub to make sure everything is working properly. The whole history of Lazarus (trunk) gets downloaded by default and is just 57MB!! With the testing I done locally, that is even less than SubVersion's 'svn co /trunk' which only gets ONE revision! To clone Lazarus Git repository with full history - $ git clone git://github.com/graemeg/lazarus.git ...this will download 57MB of data and unpack to around 144MB on your hard drive. This has the whole history of Lazarus. A checkout via SubVersion of only the trunk revision is over 320MB - more than double what Git is with full history. To clone only partial history of Lazarus Git repository --- Lets say we want only the history since the last 10 commits. $ git clone --depth 10 git://github.com/graemeg/lazarus.git ...this will download 14MB of data and unpack to around 96MB on your hard drive. You will now only have the last 10 commits as your history. Considering that the Lazarus source code alone is 82MB in size (excluding all the hidden .svn directories), Git gives you a pretty sweet deal! ;-) About that 'upstream' branch Because I'm mirroring the Lazarus svn repository (GitHub considers it as a fork), I want to make sure I always have a pristine copy of what is in SubVersion. That's what the 'origin/upstream' branch is all about. The default 'master' branch is my playground and might contain my customized version of Lazarus (something like my private fork though it will probably never get used or updated much). So for you to work with the original upstream version of Lazarus (the one that lives in SVN trunk) you need to do the following: $ git checkout -b work origin/upstream ...this creates a new branch called 'work' which tracks the original SVN trunk branch and also allows you to create your own custom changes or bug fixes. That's the one MOST users would want! Now to keep up to date with what's happening in SVN trunk, git 'upstream' branch, you simply need to run the following git command to update your local repository. $ git pull The nice thing about Git's merge is that if you created a patch and it was later included in Lazarus's SVN trunk (assuming it's applied verbatim), it will filter through to 'upstream' and then filter into your 'work' branch. Git is supposedly smart enough to realize that it's the same change you have locally and keep things nice and tidy. Else you can force a merge and trash your local changes. If you want to make local changes like bug fixes (after all, we do love to help the core developers out) and you want to submit those patches to the mailing list or to Mantis, you would have the following workflow. $ git pull(make sure we are up to date with SVN) $ (edit..edit..edit) (create a bug fix) $ git add filename (stage the file for next commit) $ git commit -m 'describe what I changed' $ git format-patch HEAD^..HEAD or replace the last line with $ git log -1 (to see the last commit message and SHA1) $ git format-patch -1 commit_SHA1 ...You will now have a numbered patch file which you can attach to an email or submit via Mantis. If you specified a larger revision range you will have multiple patch files in order which you can submit to Mantis. For more info on any git commands simply type: $ git help command eg: $ git help format-patch $ git help commit $ git help add Or go to the Git website where there are plenty of tutorials, downloadable PDF books etc.. http://git-scm.com/ Hope you enjoy! :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Large program size - 1.8 MB for empty GUI project
On Wed, Apr 8, 2009 at 18:36, Mattias Gaertner nc-gaert...@netcologne.de wrote: In order to break the circles, you must first find them. Move all uses to the interface section and FPC will find them for you. As I already written some time ago, the solution is to introduce a hint/warning for the circular dependencies in implementation sections. This hint should probably be disabled by default, for compatibility reasons. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Large program size - 1.8 MB for empty GUI project
Zitat von Alexander Klenin kle...@gmail.com: On Wed, Apr 8, 2009 at 18:36, Mattias Gaertner nc-gaert...@netcologne.de wrote: In order to break the circles, you must first find them. Move all uses to the interface section and FPC will find them for you. As I already written some time ago, the solution is to introduce a hint/warning for the circular dependencies in implementation sections. This hint should probably be disabled by default, for compatibility reasons. Yes, a hint would be nice. But a hint won't be enough. It would go unnoticed too easy. Circles should not be created accidentally, because it takes extra time to break them afterwards. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Hints usability (was: Re: Large program size - 1.8 MB for empty GUI project)
2009/4/9 Mattias Gärtner nc-gaert...@netcologne.de:
As I already written some time ago, the solution is to introduce a
hint/warning for the circular dependencies in implementation sections.
This hint should probably be disabled by default, for compatibility reasons.
Yes, a hint would be nice.
But a hint won't be enough. It would go unnoticed too easy.
This is another important problem. Easily unnoticed hints are just useless.
There are two related causes here:
1) The message window interface of Lazarus is currently very weak.
(And it hides most of the hints by default, which I consider a bug in design).
This interface is one thing I think is worth borrowing from Visual Studio.
2) The compiler produces _many_ extraneous hints, which is very harmful --
it is impossible to produce hints-free code, so new hints has much
more chances
to go unnoticed.
First point is IMO of patches welcome category (and perhaps I will
provide some,
but don't count on that), but the second one is more fundamental.
There are two main sources of harmful hints now:
1) Parameter unused.
This is by far the main culprit. There are many cases when parameters are
unused deliberately -- e.g. basic implementations of virtual
functions, most events etc.
OTOH, the hint is not _entirely_ useless and can in some rare cases
point to a real bugs.
The solution is to enable per-variable hint suppression. It is done in C/C++
by omitting variable name, but I think a better way would be a
compiler directive.
I see two variants:
a) procedure TMyForm.Button1Click(ASender {$UNUSED}: TObject);
b) procedure TMyForm.Button1Click(ASender: TObject); {$UNUSED ASender}
The first one is slightly messy in case of many unused arguments,
while the second one avoids duplicating their names, so I am not sure
which is better.
Implementing either of them will fix the problem.
2) Uninitialized variable for auto-initialized strings.
See http://bugs.freepascal.org/view.php?id=0013341 and
http://bugs.freepascal.org/view.php?id=13370.
Both issues were resolved as won't fix which IMHO was done without
considering full picture.
Here is my argument:
There are two possible approaches to non-initialized warning:
a) Do not guarantee anything about non-initialized variables, complain
on their usage.
This is C/C++ route. It is not entirely consistent there as well
(global variables of simple types
are still auto-initialized to zero), but that is their problem.
b) Makes some guarantees about variable initialization and complain only for the
variables which are not initialized automatically. This is Object
Pascal/Delphi route.
It does not warn about global variables, object fields, strings and
interfaces since they are guaranteed
to be auto-initialized in a consistent way (and programmers rely on that).
FPC seems to take the third route -- it inconsistently warns[1] about
globals, strings and interfaces but
not object fields. This is the worst of both worlds and should be
fixed one way or another.
Compatibility and language tradition dictate retaining
auto-initialization, but I am not principle
opposed to removing it -- this, however, should be a loudly declared
lack of feature/incompatibility
and have a good reason.
[1] FPC issues this warning even in Delphi mode, which is an outright bug.
--
Alexander S. Klenin
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Git mirror of Lazarus SubVersion repository is available
Windows users? I am downloading TortoiseGit (http://code.google.com/p/tortoisegit/) as we speak, and will try to get the latest 10 revisions :-) Regards, -Reenen On Thu, Apr 9, 2009 at 2:14 PM, Graeme Geldenhuys graemeg.li...@gmail.com wrote: Hi Everybody, A while back I setup a private Git mirror of the Lazarus SubVersion (trunk only) repository. This was for my personal use. Since then I thought others might enjoy a Git mirror as well. Seeing that our company has limited internet bandwidth I decided to move the mirror repository to a more public place. The Git mirror is hosted on GitHub at the following URL and is sync'ed with Lazarus SubVersion trunk every 15 minutes. git://github.com/graemeg/lazarus.git The Lazarus Trunk (exact duplicate) is mirrored in the 'upstream' branch which I'll explain shortly. I just completed a repository clone from GitHub to make sure everything is working properly. The whole history of Lazarus (trunk) gets downloaded by default and is just 57MB!! With the testing I done locally, that is even less than SubVersion's 'svn co /trunk' which only gets ONE revision! To clone Lazarus Git repository with full history - $ git clone git://github.com/graemeg/lazarus.git ...this will download 57MB of data and unpack to around 144MB on your hard drive. This has the whole history of Lazarus. A checkout via SubVersion of only the trunk revision is over 320MB - more than double what Git is with full history. To clone only partial history of Lazarus Git repository --- Lets say we want only the history since the last 10 commits. $ git clone --depth 10 git://github.com/graemeg/lazarus.git ...this will download 14MB of data and unpack to around 96MB on your hard drive. You will now only have the last 10 commits as your history. Considering that the Lazarus source code alone is 82MB in size (excluding all the hidden .svn directories), Git gives you a pretty sweet deal! ;-) About that 'upstream' branch Because I'm mirroring the Lazarus svn repository (GitHub considers it as a fork), I want to make sure I always have a pristine copy of what is in SubVersion. That's what the 'origin/upstream' branch is all about. The default 'master' branch is my playground and might contain my customized version of Lazarus (something like my private fork though it will probably never get used or updated much). So for you to work with the original upstream version of Lazarus (the one that lives in SVN trunk) you need to do the following: $ git checkout -b work origin/upstream ...this creates a new branch called 'work' which tracks the original SVN trunk branch and also allows you to create your own custom changes or bug fixes. That's the one MOST users would want! Now to keep up to date with what's happening in SVN trunk, git 'upstream' branch, you simply need to run the following git command to update your local repository. $ git pull The nice thing about Git's merge is that if you created a patch and it was later included in Lazarus's SVN trunk (assuming it's applied verbatim), it will filter through to 'upstream' and then filter into your 'work' branch. Git is supposedly smart enough to realize that it's the same change you have locally and keep things nice and tidy. Else you can force a merge and trash your local changes. If you want to make local changes like bug fixes (after all, we do love to help the core developers out) and you want to submit those patches to the mailing list or to Mantis, you would have the following workflow. $ git pull (make sure we are up to date with SVN) $ (edit..edit..edit) (create a bug fix) $ git add filename (stage the file for next commit) $ git commit -m 'describe what I changed' $ git format-patch HEAD^..HEAD or replace the last line with $ git log -1 (to see the last commit message and SHA1) $ git format-patch -1 commit_SHA1 ...You will now have a numbered patch file which you can attach to an email or submit via Mantis. If you specified a larger revision range you will have multiple patch files in order which you can submit to Mantis. For more info on any git commands simply type: $ git help command eg: $ git help format-patch $ git help commit $ git help add Or go to the Git website where there are plenty of tutorials, downloadable PDF books etc.. http://git-scm.com/ Hope you enjoy! :-) Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus -- o__ ,_./ _
Re: [Lazarus] Git mirror of Lazarus SubVersion repository is available
git://github.com/graemeg/lazarus.git And for those Windows users still thinking they are left out. There is a native Windows port of Git called msysGit available on SourceForge. http://code.google.com/p/msysgit/ I've tested it and it works perfectly on a Windows 2000 system. I also can't see any performance difference compared to the Linux version of git. They both work the same for me, so you don't need the old Cygwin version anymore. As far as I have heard, the TortoiseGit also has 95% of the features that TortoiseSVN has, so that should be pretty usable as well. I don't use such GUI tools for any version control systems, so can't really answer any other questions regarding them. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Git mirror of Lazarus SubVersion repository is available
On Thu, Apr 9, 2009 at 5:17 PM, Reenen Laurie rlau...@gmail.com wrote: Windows users? I am downloading TortoiseGit (http://code.google.com/p/tortoisegit/) as we speak, and will try to get the latest 10 revisions :-) See my previous post. Windows is well supported now, so you shouldn't have any issues. There is also a Git version for MacOS, but I don't know anything more about it. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Mouse wheel and scroll increment
Hi, I was checking why TScrollBox scrolls so slowly with the mouse wheel. I found out that TControlScrollBar.ScrollHandler doesn't take FIncrement into account when scrolling causing it to scroll typically only three pixels per wheel click. I also noticed that there are a couple of places where higher level scroll handlers are used to get around this issue, but would it make sense to do it in TControlScrollBar instead? I'm thinking about a change like this: Index: controlscrollbar.inc === --- controlscrollbar.inc(revision 19278) +++ controlscrollbar.inc(working copy) @@ -377,7 +377,7 @@ SB_PAGEDOWN: Inc(NewPos, FPage); SB_THUMBPOSITION, SB_THUMBTRACK: - NewPos := Message.Pos; + NewPos := FPosition + (Message.Pos - FPosition) * FIncrement; SB_TOP: NewPos := 0; SB_BOTTOM: Regards, Ere ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Git mirror of Lazarus SubVersion repository is available
2009/4/9 Graeme Geldenhuys graemeg.li...@gmail.com: On Thu, Apr 9, 2009 at 5:17 PM, Reenen Laurie rlau...@gmail.com wrote: Windows users? I am downloading TortoiseGit (http://code.google.com/p/tortoisegit/) as we speak, and will try to get the latest 10 revisions :-) See my previous post. Windows is well supported now, so you shouldn't have any issues. There is also a Git version for MacOS, but I don't know anything more about it. tortoisegit needs msysgit to be installed. quoting from the msysgit home page: Once you installed msysGit, git will be compiled and the repository will be fetched, so you are good to go. Play with git a little, and you will find plenty of stuff that is not quite optimal. it's a bit hard to judge how well it works. i'll have to try it out when i boot into windows again (in a couple of months, probably ;) henry ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Git mirror of Lazarus SubVersion repository is available
On Thu, Apr 9, 2009 at 5:55 PM, Henry Vermaak henry.verm...@gmail.com wrote: tortoisegit needs msysgit to be installed. I see no problem... why double the work of implementing two native versions of Git. when i boot into windows again (in a couple of months, probably ;) :-) I feel the same. I loaded my Windows VM this week, so my quota is done for the next few months. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Hints usability (was: Re: Large program size - 1.8 MB for empty GUI project)
Zitat von Alexander Klenin kle...@gmail.com:
2009/4/9 Mattias Gärtner nc-gaert...@netcologne.de:
As I already written some time ago, the solution is to introduce a
hint/warning for the circular dependencies in implementation sections.
This hint should probably be disabled by default, for compatibility
reasons.
Yes, a hint would be nice.
But a hint won't be enough. It would go unnoticed too easy.
This is another important problem. Easily unnoticed hints are just useless.
There are two related causes here:
1) The message window interface of Lazarus is currently very weak.
(And it hides most of the hints by default, which I consider a bug in
design).
What hints are hidden?
This interface is one thing I think is worth borrowing from Visual Studio.
Can you give more details for the people who don't know VS?
2) The compiler produces _many_ extraneous hints, which is very harmful --
it is impossible to produce hints-free code, so new hints has much
more chances to go unnoticed.
True.
First point is IMO of patches welcome category (and perhaps I will
provide some,
but don't count on that), but the second one is more fundamental.
There are two main sources of harmful hints now:
1) Parameter unused.
This is by far the main culprit. There are many cases when parameters are
unused deliberately -- e.g. basic implementations of virtual
functions, most events etc.
OTOH, the hint is not _entirely_ useless and can in some rare cases
point to a real bugs.
The solution is to enable per-variable hint suppression. It is done in C/C++
by omitting variable name, but I think a better way would be a
compiler directive.
I see two variants:
a) procedure TMyForm.Button1Click(ASender {$UNUSED}: TObject);
b) procedure TMyForm.Button1Click(ASender: TObject); {$UNUSED ASender}
The first one is slightly messy in case of many unused arguments,
while the second one avoids duplicating their names, so I am not sure
which is better.
Implementing either of them will fix the problem.
That's pretty much what I purposed a long time ago. I even implemented it once
via IDE directives.
But the code gets ugly and it worked only in lazarus.
A compiler solution with some synedit sugar might improve this.
2) Uninitialized variable for auto-initialized strings.
See http://bugs.freepascal.org/view.php?id=0013341 and
http://bugs.freepascal.org/view.php?id=13370.
Both issues were resolved as won't fix which IMHO was done without
considering full picture.
... or because they considered an even bigger picture than you.
Here is my argument:
There are two possible approaches to non-initialized warning:
a) Do not guarantee anything about non-initialized variables, complain
on their usage.
This is C/C++ route. It is not entirely consistent there as well
(global variables of simple types
are still auto-initialized to zero), but that is their problem.
b) Makes some guarantees about variable initialization and complain only for
the variables which are not initialized automatically. This is Object
Pascal/Delphi route.
It does not warn about global variables, object fields, strings and
interfaces since they are guaranteed
to be auto-initialized in a consistent way (and programmers rely on that).
FPC seems to take the third route -- it inconsistently warns[1] about
globals, strings and interfaces but
not object fields. This is the worst of both worlds and should be
fixed one way or another.
Compatibility and language tradition dictate retaining
auto-initialization, but I am not principle
opposed to removing it -- this, however, should be a loudly declared
lack of feature/incompatibility
and have a good reason.
Wrong list. Lazarus will not change the compiler.
[1] FPC issues this warning even in Delphi mode, which is an outright bug.
Mattias
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Git mirror of Lazarus SubVersion repository is available
On Fri, Apr 10, 2009 at 03:30, Graeme Geldenhuys graemeg.li...@gmail.com wrote: On Thu, Apr 9, 2009 at 5:55 PM, Henry Vermaak henry.verm...@gmail.com wrote: tortoisegit needs msysgit to be installed. I see no problem... why double the work of implementing two native versions of Git. I have successfully cloned the repo with msysgit. Everything seems to work at the first glance. Will play with it more and report the results. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Hints usability (was: Re: Large program size - 1.8 MB for empty GUI project)
Alexander Klenin wrote: [...] 2) The compiler produces _many_ extraneous hints, which is very harmful -- it is impossible to produce hints-free code, so new hints has much more chances to go unnoticed. While I agree in principle that extra verbosity is a source of bugs, the hint severity is for messages that cannot positively be determined to be potentially dangerous. It goes like this: Fatal error: Something so bad that compilation cannot possibly continue Error: Something that is certainly wrong, but compilation can continue, even though it wont overall succeeed. Warning: Something that is definitely /possibly/ dangerous, but might be safe in the specific circumstance. It's always possible to quench warnings by changing the code. Warnings should always be a sign of some problem in your code (that may or may not make your program behave incorrectly) Hint: Something that can't be ruled out as dangerous, but might just be. For practical reasons, this category can't be merged with warnings, because that would then produce so many warnings that the only useful error category would be error. That would be bad. -- Med venlig hilsen Christian Iversen ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] 0008803: Email notification for changes of *own* reported bugs only
Hello, Please, what's the current status on this issue[1]? Mantis is currently useless to me (and hinders me from helping Lazarus a little bit) since I can't deal with the volume of messages from all bugs and thus don't receive notifications from my reported and monitored items either... Best regards, Flávio [1] http://bugs.freepascal.org/view.php?id=8803 ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Hints usability (was: Re: Large program size - 1.8 MB for empty GUI project)
Hello Christian,
Thursday, April 9, 2009, 7:13:06 PM, you wrote:
CI Hint: Something that can't be ruled out as dangerous, but might just be.
CI For practical reasons, this category can't be merged with warnings,
CI because that would then produce so many warnings that the only useful
CI error category would be error. That would be bad.
Yes but an easy way to tell the compiler that the hint or warning is
expected must exists and I think that {$HINTS OFF} is a too radical
path.
In my case for the Parameter not used I'm using a heavily overloaded
procedure UseParameter which does nothing and my code is clear of
this kind of hints. The problem is that I must updated the
UseParameter each time I use a new parameter type.
--
Best regards,
JoshyFun
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] 0008803: Email notification for changes of *own* reported bugs only
Flávio Etrusco wrote: Hello, Please, what's the current status on this issue[1]? Mantis is currently useless to me (and hinders me from helping Lazarus a little bit) since I can't deal with the volume of messages from all bugs and thus don't receive notifications from my reported and monitored items either... there is no issue, there is only a difference between emails for issues reported to lazarus and reported to fpc. But you should get all mails when you are monitoring Marc ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] 0008803: Email notification for changes of *own* reported bugs only
Hello Marc, Thursday, April 9, 2009, 11:11:53 PM, you wrote: MW there is no issue, there is only a difference between emails for issues MW reported to lazarus and reported to fpc. MW But you should get all mails when you are monitoring I'm also not receiving my own bugs or monitored issues. If I check some of the other options like new, changed... it works fine for that ones, but still no monitored or own bugs notifications :-? Maybe is the gmail spam filter :-? -- Best regards, JoshyFun ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Git mirror of Lazarus SubVersion repository is available
On Thu, Apr 9, 2009 at 23:14, Graeme Geldenhuys graemeg.li...@gmail.com wrote: The Git mirror is hosted on GitHub at the following URL and is sync'ed with Lazarus SubVersion trunk every 15 minutes. git://github.com/graemeg/lazarus.git Hm, apparently sync is not working. -- Alexander S. Klenin ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Hints usability (was: Re: Large program size - 1.8 MB for empty GUI project)
JoshyFun wrote:
Hello Christian,
Thursday, April 9, 2009, 7:13:06 PM, you wrote:
CI Hint: Something that can't be ruled out as dangerous, but might just be.
CI For practical reasons, this category can't be merged with warnings,
CI because that would then produce so many warnings that the only useful
CI error category would be error. That would be bad.
Yes but an easy way to tell the compiler that the hint or warning is
expected must exists and I think that {$HINTS OFF} is a too radical
path.
That's really 2 statements:
A) There should be a way to tell the compiler that the hint is expected
Well, I can't see why this is a given. By definition, hints are things
that _can_ be potentially dangerous, but it's impossible to determine
for sure. Warnings point out things which are always potentially dangerous.
Therefore, for hints, you'll just end up with code that's entirely
plastered in specifications to disable hints. This will make the code
ugly, and remove time that could be spent better.
For warnings, it should always be considered a problem with the code if
it generates a warning. If the code is fine, then the compiler is wrong
for issuing a warning rather than a hint. This is somewhat rare,
however. I think it's a bit of time since a warning was reclassified
(but I have seen it happen).
B) Saying {$HINTS OFF} is too radical
Well, I agree it can be bit radical. Perhaps a switch to disable
certains hints only would work better. Typically, certain hints give you
more trouble than others, depending on coding style.
In my case for the Parameter not used I'm using a heavily overloaded
procedure UseParameter which does nothing and my code is clear of
this kind of hints. The problem is that I must updated the
UseParameter each time I use a new parameter type.
I'm not sure what you mean? Can you give a small example?
--
Med venlig hilsen
Christian Iversen
___
Lazarus mailing list
Lazarus@lazarus.freepascal.org
http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] 0008803: Email notification for changes of *own* reported bugs only
JoshyFun wrote: Hello Marc, Thursday, April 9, 2009, 11:11:53 PM, you wrote: MW there is no issue, there is only a difference between emails for issues MW reported to lazarus and reported to fpc. MW But you should get all mails when you are monitoring I'm also not receiving my own bugs or monitored issues. If I check some of the other options like new, changed... it works fine for that ones, but still no monitored or own bugs notifications :-? Maybe is the gmail spam filter :-? can you give some recent changed bugnumber you should have gotten a notification for ? Marc ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Problem with TFloatSpinEdit component
Hello all, I have converted a small Delphi project to Lazarus but I cannot get the TFloatSpinEdit decimal values to display correctly. The component shows the whole number part and no decimal part. I have set the decimal property to 6 decimal places. The value displayed by the component is either rounded up or down, however the real value is used by the program for calculations. Using FPC 2.2.0 and Lazarus 0.9.24 with Ubuntu 8.10 Thanks Paul ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Git mirror of Lazarus SubVersion repository is available
On Fri, Apr 10, 2009 at 1:13 AM, Alexander Klenin kle...@gmail.com wrote: Hm, apparently sync is not working. Oops, I forgot to make the update script executable on the new server. :-) It should be sync'ed now. Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
