Re: [Lazarus] OT: Namespaces?
Zitat von Hans-Peter Diettrich drdiettri...@aol.com: Mattias Gärtner schrieb: why aliases units names are required? E.g. when you have multiple third-party units of the same name. Isn't that already supported by the 'in' modifier? For example: uses unit1, unit1B in '../test/unit1'; Heureka :-) While Delphi 7 requires that the unit name matches the file name, even when using IN, and AFAIR allows for IN only in the project file (*.DPR), FPC imposes no such restrictions. Now we can go on-topic: While FPC already supports true unit alias, FPC supports unit alias in a unit, but it does not support two different ppu with the same name. At least 2.2.3 does not. You will get linker errors, because identifiers of the second unit1 have still the same prefix. It is probably a bug, that FPC does not check and gives an error in this case. Lazarus (code completion...) cannot handle unit1B in your example :-( Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OT: Namespaces?
Mattias Gaertner schrieb:
Now we can go on-topic: While FPC already supports true unit alias,
Lazarus (code completion...) cannot handle unit1B in your example :-(
Have you updated to svn 19249?
I've just updated to svn 19273, and the problem persists.
Though, Lazarus says SVN 19172 in the About dialog, after a full rebuild?
If yes: please provide an example.
unit Unit2;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, Forms;
function MyText: string;
implementation
uses
myform in 'unit1.pas';
function MyText: string;
begin
Result := myform.Form1.Edit1.Text + '+';
end;
end.
Unit1 is a simple form with an edit control.
In the above line, starting from myform none of the identifiers is
recognized. No jump to declaration, no code completion, nada :-(
DoDi
___
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 2009-04-03, Marc Weustink marc.weust...@cuperus.nl wrote: Alexey S. Smirnov wrote: SmartLink problem is quite simple. It seems that all units, mentioned in Interface-Uses section will be fully linked. Only units mentioned in Implementation-Uses section can be checked during SmartLink. So, to enhance linking process and to reduce binary size we shell check all Interface sections of all LCL units to reduce units list. We have all units listed in the interface section to avoid unit circles. This is needed since the compiler will fail to compile the LCL sooner or later if there are to many circles. I strongly agree with Alexey here. The bug in FPC should be fixed and Lazarus source updated to remove unnecessary units from 'uses' clauses. Not so much for executable size, but for mantainabilty of the source. Yes. Avoid uses sections in implementations. This golden rule is true since the start of FPC. Using implementation uses sections is asking for trouble. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OT: Namespaces?
Zitat von Marco van de Voort mar...@stack.nl: On Tue, Apr 07, 2009 at 11:36:43AM +0200, Mattias G?rtner wrote: Now we can go on-topic: While FPC already supports true unit alias, FPC supports unit alias in a unit, but it does not support two different ppu with the same name. At least 2.2.3 does not. You will get linker errors, because identifiers of the second unit1 have still the same prefix. It is probably a bug, that FPC does not check and gives an error in this case. Isn't the ..IN.. syntax is more created to correct case differences between unitname and filename ? From Delphi pov I don't see why that should matter. AFAIK under Delphi the 'in' modifier has two purposes: - mark the unit as part of the project - use a unit from a directory which can not be added to the unit search path, because there is a duplicate. Mattias ___ 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
2009/4/7 Graeme Geldenhuys graemeg.li...@gmail.com: I believed that is why the smartlinking works so well with fpGUI - I can create a GUI application that is only 340KB in size. Can somebody explain to me why smartlinking works better when a unit is in the implementation section than when it is in the interface section? I thought for smartlinking it doesn't make a difference, the unit is used anyway. Vincent ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OT: Namespaces?
On Tue, 7 Apr 2009 15:32:28 +0200 zeljko zel...@holobit.net wrote: On Tuesday 07 April 2009 15:11, Mattias Gärtner wrote: AFAIK under Delphi the 'in' modifier has two purposes: - mark the unit as part of the project - use a unit from a directory which can not be added to the unit search path, because there is a duplicate. Lazarus uses same logic isn't it ? It does not. What belongs to the project is stored in the .lpi. The codetools support the 'in' modifier and so does the lazarus IDE a bit. But the IDE does not update the 'in' file names and it does not have any special consistency checks for them. So use them only if you know what you are doing. The converter for delphi projects supports them (fix the file cases, adds them to the lpi). I already have such projects where I must use in like in delphi. Please give a complete example. Maybe you are doing something wrong. Mattias ___ 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 2009-04-07, Mattias Gärtner nc-gaert...@netcologne.de wrote: I strongly agree with Alexey here. The bug in FPC should be fixed and Lazarus source updated to remove unnecessary units from 'uses' clauses. Not so much for executable size, but for mantainabilty of the source. Yes. Avoid uses sections in implementations. This golden rule is true since the start of FPC. Using implementation uses sections is asking for trouble. Eh... you mean 'no'? Because I argue _for_ 'uses' sections in implementation. Oops. Sorry, then I misunderstood you. Uses sections in implementation sections are buggy as long as I know fpc. The problems are known but apparently too hard to track and fix. The bugs appear at random and with various degrees depending on platform and fpc version. In some years you think the bugs are fixed, and then they come back. You have been warned: Don't use the imp sections. I thought this was known: http://wiki.lazarus.freepascal.org/DesignGuidelines Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] OT: Namespaces?
On Tuesday 07 April 2009 16:59, Mattias Gaertner wrote: On Tue, 7 Apr 2009 15:32:28 +0200 zeljko zel...@holobit.net wrote: On Tuesday 07 April 2009 15:11, Mattias Gärtner wrote: AFAIK under Delphi the 'in' modifier has two purposes: - mark the unit as part of the project - use a unit from a directory which can not be added to the unit search path, because there is a duplicate. Lazarus uses same logic isn't it ? It does not. What belongs to the project is stored in the .lpi. The codetools support the 'in' modifier and so does the lazarus IDE a bit. But the IDE does not update the 'in' file names and it does not have any special consistency checks for them. So use them only if you know what you are doing. I must use them :) The converter for delphi projects supports them (fix the file cases, adds them to the lpi). I already have such projects where I must use in like in delphi. Please give a complete example. Maybe you are doing something wrong. I have two dirs with projects, both have main.pas, but project2 uses some units from project1 dir. So: 1.I must include project1 dir into project2, but sometimes , when building project2 lazarus (eg. when have some error in code), raised main.pas from project1 , but it shouldn't, it must open project2/main.pas. In kylix this is normal (because of in), so each unit is properly recompiled. I've seen that it's little bit messy and tricky with fpc, so my settings for eg. project2 are: 1.project1 units , which are used in project2 ARE included inside .lpr with in like myunitfromproj1 in '../project1/myunitfromproj1.pas' etc.. 2.project1 dir is removed from my units path. 3.-FU is setted up to project2 dir. 4.Laz application output path is at third place ... eg. myBuilds/project2 Now it does not make any mess. Maybe I'm wrong ... but it works for me. z. ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] tiOPF oprm dia dia2pas
Any one could help me with OOP and Business Objects Persistence ? I lookfor change from dbaware programs for Object/DBAware programs. How can i use datasets with tiOPF or oprm? Any one could give me a diagram in dia for exemple and procedures for convert it in a .pas code? Thanks. ___ 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 Tue, 07 Apr 2009 17:32:58 +0200 Bogusław Brandys bran...@o2.pl wrote: Marc Weustink wrote: Graeme Geldenhuys wrote: 2009/4/7 Mattias Gärtner nc-gaert...@netcologne.de: Uses sections in implementation sections are buggy as long as I know fpc. The problems are known but apparently too hard to track and fix. The bugs appear at random and with various degrees depending on platform and fpc version. In some years you think the bugs are fixed, and then they come back. You have been warned: Don't use the imp sections. I thought this was known: http://wiki.lazarus.freepascal.org/DesignGuidelines This is the first I here of this. I was always taught to limit the usage of the Interface section's uses clause, so you can prevent circular unit issues. So is FPC the opposite of Delphi in this regards? No, but the problem is caused by the way fpc stores info in the .ppu Somehow it is possible that the checksum of the interface part stored in the .ppu is affected by the implementation section. When editing sources this can lead to strange results, the compiler might think in some cases an interface is changed or not. When Lazarus started we put a lot in the uses section of the implementation part. When some source was changed, sometimes a 3 or fourtime compile attempt was needed to compile the while LCL, since everytime the compiler thought a unit was changed whil it was not. Restarting compilation (and keeping the existing units) in most cases resulted in a compiled LCL. To avoid this and to make the LCL usabole as library, most unit cirles were removed. One way to ensure that is by putting all uses in the interface section. I have used FPC since 2.0.2 under Linux and Windows and haven't had any issues. I limit the usage of interface uses clause as much as possible. I believed that is why the smartlinking works so well with fpGUI - I can create a GUI application that is only 340KB in size. It might depend on how you compile fpGUI. Anyway, back to the subject, I cannot imagine why FPC when smartlinking makes a difference between interface and implementation uses. Especially if you use an external linker, like on linux. Marc Doesn't it require anyway recompilation of all lcl units with -CX option (smart linkable) ? Btw a little different question : what is needed to allow lineinfo reading stack trace from external file (in case of exception) for example of the name corresponding to exe name but with different extension. FPC can now dump debug info into such separate file. Such feature would be very useful as compilation option for example. Write a lineinfo unit that supports the external file. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
