Re: [fpc-devel] performance tests: reference counted vs non-reference counted
On Fri, 16 Nov 2007 14:27:50 +0200
Graeme Geldenhuys [EMAIL PROTECTED] wrote:
On 16/11/2007, Luiz Americo Pereira Camara [EMAIL PROTECTED]
wrote:
A single program like the below leaks memory. To the object be
freed automatically is necessary to declare Obj as IUnknown.
I wonder if your test is leaking memory.
That was an oversight, thanks! Point taken, I was using interfaced
objects incorrectly.
Yet in the last few test modifications, I explicitly free both
Reference Counted and non-Reference Counted objects, so that shouldn't
cause memory leaks.
With all these tests, we have cleared up a few issues. One still
outstanding is why TInterfacedObject performs better that TObject
using FPC?
Either you have still some measurement problems, or see Jonas hint
about wrong alignment.
Attached is the current test.
Make sure you run the program one or two times before, so that the OS
caching does not interfere:
$ ./performancetest
...OS caching polluted...
$ ./performancetest
...OS caching polluted...
$ ./performancetest
1000 iterations in 1169 ms (no reference counting)
1000 iterations in 815 ms (no reference counting)
1000 iterations in 1005 ms (reference counting)
1000 iterations in 1002 ms (reference counting)
1000 iterations in 1160 ms (no reference counting with MyBaseObject)
1000 iterations in 1154 ms (no reference counting with MyBaseObject)
1000 iterations in 1404 ms (reference counting with MyBaseObject)
1000 iterations in 1344 ms (reference counting with MyBaseObject)
$ ./performancetest
1000 iterations in 808 ms (no reference counting)
1000 iterations in 803 ms (no reference counting)
1000 iterations in 992 ms (reference counting)
1000 iterations in 990 ms (reference counting)
1000 iterations in 1294 ms (no reference counting with MyBaseObject)
1000 iterations in 1172 ms (no reference counting with MyBaseObject)
1000 iterations in 1447 ms (reference counting with MyBaseObject)
1000 iterations in 1369 ms (reference counting with MyBaseObject)
Notes:
As you can see I had to run each 10 million times because FPC is so
fast, even without optimizations and there is still an error of 0.1 ms
from the various processes running on todays linux.
Compiler flags: -S2cgi -OG1 -gl
Make also sure, that you have at least 500mb of free RAM. Otherwise you
measure your disk speed.
Mattias
{
This program tests the speed of Reference Counted and non-Reference Counted
objects over a set time period. Default of 5 seconds.
}
program performancetest;
{$mode objfpc}{$H+}
uses
Classes, SysUtils, CustApp, unit1;
const
CTestRunTime = 1; // Seconds
type
TMyApplication = class(TCustomApplication)
protected
procedure DoRun; override;
procedure TestRefCountedObjects;
procedure TestNonRefCountedObjects;
procedure TestRefCountedMyObjects;
procedure TestNonRefCountedMyObjects;
procedure Log(const AMessage: string);
public
constructor Create(TheOwner: TComponent); override;
destructor Destroy; override;
procedure WriteHelp; virtual;
end;
TMyBaseObject = class(TObject, IUnknown)
private
FRefCounting: Boolean;
FRefCount: Integer;
protected
functionQueryInterface(const IID: TGUID; out Obj): longint; stdcall;
function_AddRef: longint; stdcall;
function_Release: longint; stdcall;
public
constructor Create;
destructor Destroy; override;
constructor CreateWithRefCounting;
procedure AfterConstruction; override;
procedure BeforeDestruction; override;
class function NewInstance: TObject; override;
end;
{ TMyBaseObject }
function TMyBaseObject.QueryInterface(const IID: TGUID; out Obj): longint; stdcall;
begin
if GetInterface(IID, Obj) then
Result := 0
else
Result := E_NOINTERFACE;
end;
function TMyBaseObject._AddRef: longint; stdcall;
begin
Result := InterlockedIncrement(FRefCount);
end;
function TMyBaseObject._Release: longint; stdcall;
begin
Result := InterlockedDecrement(FRefCount);
if FRefCounting then
if Result = 0 then
Destroy;
end;
constructor TMyBaseObject.Create;
begin
FRefCounting := False;
end;
destructor TMyBaseObject.Destroy;
begin
inherited Destroy;
end;
constructor TMyBaseObject.CreateWithRefCounting;
begin
Create;
FRefCounting := True;
end;
procedure TMyBaseObject.AfterConstruction;
begin
inherited AfterConstruction;
// Release the constructor's implicit refcount
if FRefCounting then
InterlockedDecrement(FRefCount);
end;
procedure TMyBaseObject.BeforeDestruction;
begin
if FRefCounting then
if FRefCount 0 then
System.Error(reInvalidPtr);
inherited BeforeDestruction;
end;
class function TMyBaseObject.NewInstance: TObject;
begin
Result := inherited NewInstance;
TMyBaseObject(Result).FRefCount := 1;
end;
function tiGetTickCount: Cardinal;
begin
Result := Cardinal(Trunc(Now * 24 * 60 * 60 * 1000));
end;
{
Re: [fpc-devel] Lazarus IDE searching units overwiev inquire (issue#10176 successor)
On Fri, 16 Nov 2007 14:17:46 +0300 Andrey Gusev [EMAIL PROTECTED] wrote: * Mattias Gaertner [EMAIL PROTECTED] [Fri, 16 Nov 2007 11:44:26 +0100]: Can you send me the debug log and tell me the file structure? The --debug-out result is empty (i.e. namely the log file was not created). There is always some output. Are you sure, that you used the --debug-log=C:\lazlog.txt parameter correctly? File with form ancestor (fetched from my combat project) has publised in #10176 issue. Yes, but this example works here (linux,fpc 2.3.1) without errors (except for invalid UTF-8 strings), so I need more information. It seems somewhat pulled what was not included to paths... So full silence also is not good. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus IDE searching units overwiev inquire (issue#10176 successor)
On Thu, 15 Nov 2007 13:04:06 +0300 Andrey Gusev [EMAIL PROTECTED] wrote: I have ask to all at once. == * Mattias Gaertner [EMAIL PROTECTED] [Thu, 15 Nov 2007 You don't need to add every unit to a project or package. It is sufficient to add the the directories to the unit search path. But for update checks, and quick searches it is recommended to assign every unit to a specific project or package AG: i.e. with project-add unit ? Yes. Or Project Inspector / Add / Add files. If a directory is not in the unit search path, then it will not get the project settings. AG: From which (search) paths, have a few tunables ? Sorry, my english is not good enough. What do you mean? Because the IDE does not apply the project settings to everything (like Delphi), the developer finds dangling units quickly and the units can use only those units, that they should use. This reduces version conflicts, accidental auto rebuilds and context switches. AG: That is all fine, but the full control ability (of search process) interested to me ! What do you mean with interested in full control ability? Do you want to know all places/flags that control the final unit search path? Or do you want one more possibility to control/setup the unit search path? AG ... AG knowledge... In present IDE behave itself as old bore, or as AG accountant, it's more clever in expectations. Mattias Can you give an example? AG: What example?, that IDE behaviour remember to me an old bore ? :) An example how to improve it. Vincent SnijdersYiu can compile the IDE with fpc 2.2.0 and develop applications with fpc 2.3.1. AG: You right, for my production-critical tasks i will have deed just so. = and last A have construct a quite simple sample, that demonstrates FPC231=Lazarus lacks. It is only simplified exposition of #10176 issue. I will bring new issue, as soon as manits will available. As was supposed by me, the presence of my own form ancestor is essential to unit-read-error revealing (the IDE-old-bor'ity :) ) The IDE now skips silently missing units when searching for ancestor forms. A think, that discuss subject Must IDE editor be such intelligent (in syntax comprehension sense) as compiler, or syntax highlighting is enough ? would be useful. What thoughts developers respected about this ? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus IDE searching units overwiev inquire (issue#10176 successor)
On Thu, 15 Nov 2007 01:22:33 +0300 Andrey Gusev [EMAIL PROTECTED] wrote: Is somebody (the kind people), who can explain to me about IDE searching units process details ? More concrete: which IDE tunables affects to searching units by IDE (or codetools) ? And problem, that was not cosidered as bug: Why IDE cannot find LCL and others-but-by-path-available units, when i open form, placed to other than project directory (that also included in paths) ? I may have misunderstood your descriptions in the bug tracker. It was not clear to me, that you added the units to the project, because the example showed no package dependency and a lot absolute paths. This phenomenon is strongly obstruct to developing process in few aspects. Many problems were solved by using fpc 2.2.0. What questions are left? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus IDE searching units overwiev inquire (issue#10176 successor)
On Thu, 15 Nov 2007 01:44:22 +0300 Andrey Gusev [EMAIL PROTECTED] wrote: * Andrey Gusev [EMAIL PROTECTED] [Thu, 15 Nov 2007 01:22:33 +0300]: Why IDE cannot find LCL and others-but-by-path-available units, when i open form, placed to other than project directory (that also included in paths) ? It should. And why lazarus IDE have builded with FPC 2.2.0 (thanks to Vincent Snijders for hint) don't have such problem ? Either there is a bug in fpc 2.3.1 or a function changed its behaviour. I think, is that, nevertheless, must considered as bug! Yes. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpmkunit
On Tue, 13 Nov 2007 09:21:36 +0100 (CET) Peter Vreman [EMAIL PROTECTED] wrote: [...] fpc -n -FUunits\i386-win32\ -Fu..\..\src\ -Fuunits\i386-win32\* myexample.pp 1. What strikes me is that the command line has the option -n in it. It appears that this command line option is hard coded in TBuildEngine.GetCompilerCommand. I strongly believe it should become a property named DefaultConfigFile which is by default set to True ie no '-n'. This is by design to prevent dependening on local configuration when building and installing packages. It forces the user to add all options and dependencies to fpmake.pp Can fpmake be used for programs/libraries too? They need the linker options of fpc.cfg. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpmkunit
On Tue, 13 Nov 2007 13:28:47 +0100 (CET) Peter Vreman [EMAIL PROTECTED] wrote: On Tue, 13 Nov 2007 09:21:36 +0100 (CET) Peter Vreman [EMAIL PROTECTED] wrote: [...] fpc -n -FUunits\i386-win32\ -Fu..\..\src\ -Fuunits\i386-win32\* myexample.pp 1. What strikes me is that the command line has the option -n in it. It appears that this command line option is hard coded in TBuildEngine.GetCompilerCommand. I strongly believe it should become a property named DefaultConfigFile which is by default set to True ie no '-n'. This is by design to prevent dependening on local configuration when building and installing packages. It forces the user to add all options and dependencies to fpmake.pp Can fpmake be used for programs/libraries too? They need the linker options of fpc.cfg. For fpmake we can use the same algorithm as currently used in the generated Makefiles. Depending on a fpc.cfg is not an option for installing packages from a repository. That will give more problems than it solves. E.g. people having -Mdelphi in the fpc.cfg and the package expects -Mfpc, because that it the compiler default. Yes, of course. Maybe my question was misleading. I want to know if fpmake is a tool for building packages or if it is a general tool to build all type of pascal code. I know, I can hack it to build everything, but is this supported or is there another tool? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] copyright infringement in FPC code
On Tue, 13 Nov 2007 22:59:50 +0200 ik [EMAIL PROTECTED] wrote: [...] What I found in Lazarus code so far was that somebody _was_ peaking at the Delphi code at some stage. Yes. 1. Many pascal programmers have several years Delphi experience and are used to the Delphi coding style and naming scheme. So when they create a new method/class, the variables will usually have Delphi names, Delphi block sizes, etc. 2. There was a short discussion some years ago when I started the codetools, how the generated code should look like. I feared that when the codetools class completion creates the same code as Delphi, people will eventually come up with copyright. The only strange thing is that it took 6 years. One fourth of the LCL is auto generated code. [...] And it also looks like lack of good imagination, and the wish to make the code more readable :) Many keep Delphi compatibility, because they like it, not only OOP and the Delphi features, but the coding style as well. Good news is that that's where the similarity ends (well in the units I checked). Importantly, the method bodies seem to be implemented differently, except for the very elementary methods. What are the elementary methods ? Attached is an example. Mattias lazarus/lcl/include/control.inc: line 1044-1056|Vcl/Controls.pas: line 3597-3606[55] Function TControl.ScreenToClient(const |function TControl.ScreenToClient(const var|var P : TPoint;|Origin: TPoint; begin |begin P := ClientOrigin; |Origin := ClientOrigin; Result.X := APoint.X - P.X;|Result.X := Point.X - Origin.X; Result.Y := APoint.Y - P.Y;|Result.Y := Point.Y - Origin.Y; end; |end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] copyright infringement in FPC code
On Tue, 13 Nov 2007 23:51:14 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Tue, 13 Nov 2007, schreef Marc Weustink: ik wrote: On Nov 13, 2007 10:51 PM, Graeme Geldenhuys [EMAIL PROTECTED] wrote: [..] Good news is that that's where the similarity ends (well in the units I checked). Importantly, the method bodies seem to be implemented differently, except for the very elementary methods. What are the elementary methods ? methods like: TSomeObject.DoSomeNotify; begin if Assigned(FOnSomeNotify) then FOnSomeNotify(Self); end; You cannot write this another way. You can: Tsomeobject.do_some_notify; begin if Fon_some_notifynil then Fon_some_notify(self); end; That's not the same and will crash since lazarus svn rev 12822. Lazarus now uses the Delphi 'Assigned' trick for design time events as default. I hope this trick is not copyrighted or patented. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Dnamic packages support
On Mon, 05 Nov 2007 12:08:31 +0100 Michael Schnell [EMAIL PROTECTED] wrote: Look, I don't try to convince you that Lazarus or FPC should make extensive use of packages - we worked years without it and we worked very well, If using packages is the way to go to make installing visual components in Lazarus, IMHO it's essential to use them there ASAP. It would be really nice to have a predefined way to do/deploy plugins (that should not depend on compiler versions and maybe should be doable in C, too). Maybe something supporting those could be worth some thoughts, too. If you really want to write C plugin, then I can add a unit to the IDEIntf with some common functions without OOP. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] type classes
Is it possible to use TTranslateStrings = type TStrings? I ask because, the compiler allows it, but stops later with only this message: lcl/interfaces/gtk2/interfaces.pas(1,1) Fatal: Compilation aborted Question: Is it allowed to use NewClass = type SomeClass; ? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007 01:43:51 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Sun, 21 Oct 2007, Mattias Gaertner wrote: On Sun, 21 Oct 2007 00:46:19 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007, Mattias Gaertner wrote: On Sat, 20 Oct 2007 16:29:40 +0200 Tomas Hajny [EMAIL PROTECTED] wrote: On 19 Oct 07, at 13:14, Micha Nelissen wrote: Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. I see the reason is not really coming out, but I'll stop now. Well, I'd certainly have one (more) reason not to put it into RTL - I don't think that support for .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. Are we talking about a complete ppu parser or something to only read the property info? Well, the ppu file is divided in blocks; Each block has a type and a size. If you don't know a block, you can 'skip' it. (If memory serves me right, of course) If the codetools can only read those fields of the ppu, that are supported by the fpc version used for building the codetools, then the ppu reader will always stay merely a fallback parser - only used if there are no sources or to check the user configuration. In this case: The property information can not be read with the released fpc 2.2. And this means probably the next years. IMHO the codetools should be able to read the ppu of all available fpc versions, independent of the fpc used compiling the codetools. So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name? I think such a unit could best go in the packages, since it is tightly bound to FPC, and definitely non-visual ? Well, it should be bound to FPC, but it should not be bound to a specific FPC version. Exactly. That's why we need a copy. The copy (ppuparser or whatever) can maintain knowledge of past versions, as far as that is needed. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007 08:36:24 +0200 (CEST) Daniël Mantione [EMAIL PROTECTED] wrote: Op Sun, 21 Oct 2007, schreef Michael Van Canneyt: .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. This is not true. Take for example: procedure tarraydef.ppuwrite(ppufile:tcompilerppufile); begin inherited ppuwrite(ppufile); ppufile.putderef(_elementdefderef); ppufile.putderef(rangedefderef); ppufile.putaint(lowrange); ppufile.putaint(highrange); ppufile.putsmallset(arrayoptions); ppufile.writeentry(ibarraydef); end; If the arrayoptions for example becomes a large set (32 elements), an old version that will try to read a new version will read too little data. We will of course bump the ppu version, so the compile refuses old ppus. Is the newer ppureader be able to read older ppu? In other words: Does a current ppureader contains the code to read the old format too? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type classes
On Sun, 21 Oct 2007 13:46:57 +0200 Florian Klaempfl [EMAIL PROTECTED] wrote: Mattias Gaertner schrieb: Is it possible to use TTranslateStrings = type TStrings? I ask because, the compiler allows it, but stops later with only this message: lcl/interfaces/gtk2/interfaces.pas(1,1) Fatal: Compilation aborted Question: Is it allowed to use NewClass = type SomeClass; ? In theory yes, in pratice it seems to be buggy :) Thanks for the quick response. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] type classes
On Sun, 21 Oct 2007 14:10:37 +0200 Peter Vreman [EMAIL PROTECTED] wrote: At 14:03 21-10-2007, you wrote: On Sun, 21 Oct 2007 13:46:57 +0200 Florian Klaempfl [EMAIL PROTECTED] wrote: Mattias Gaertner schrieb: Is it possible to use TTranslateStrings = type TStrings? I ask because, the compiler allows it, but stops later with only this message: lcl/interfaces/gtk2/interfaces.pas(1,1) Fatal: Compilation aborted Question: Is it allowed to use NewClass = type SomeClass; ? In theory yes, in pratice it seems to be buggy :) Thanks for the quick response. Also delphi handles things strange. The following code is from webtbf/tw3930a.pp. The code looks correct, but delphi fails with Incompatible types: 'TMyStringList' and 'TStringList'. That makes typed classes not very usefull unless you override all constructors. uses Classes; type TMyStringList = type TStringlist; var list : TMyStringList; begin list:=TMyStringList.Create; end. It might sound strange, but this 'incompatible types' is good. I need it only for RTTI. A TMyStringList will never be created. Basically I need type TTranslateStringsText = type TStrings; TMyComponent = class(TPersistent) ... published property Items: TTranslateStringsText read ... write ...; end; The implementation will always use TStrings, not TTranslateStringsText. Only the RTTI information should show TTranslateStringsText. Especially this must work: Items:=TStringList.Create; BTW, I don't know what other sense is in 'type someclass'. Maybe Borland thought the same. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007 14:22:30 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: [...] Well, the ppu file is divided in blocks; Each block has a type and a size. If you don't know a block, you can 'skip' it. (If memory serves me right, of course) If the codetools can only read those fields of the ppu, that are supported by the fpc version used for building the codetools, then the ppu reader will always stay merely a fallback parser - only used if there are no sources or to check the user configuration. In this case: The property information can not be read with the released fpc 2.2. And this means probably the next years. IMHO the codetools should be able to read the ppu of all available fpc versions, independent of the fpc used compiling the codetools. I understand, but what do you want to say with this ? Only that the codetools can not use a ppureader.ppu from the RTL or FCL. It can use the ppureader.pas, but not the .ppu. Or use the XML approach as Florian/Paul suggested. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007 21:55:45 +0800 Paul Ishenin [EMAIL PROTECTED] wrote: Florian Klaempfl wrote: Only that the codetools can not use a ppureader.ppu from the RTL or FCL. It can use the ppureader.pas, but not the .ppu. Or use the XML approach as Florian I suggested :) Paul didn't like it that much He started also a wiki page: http://wiki.freepascal.org/Property_attributes I still thinking that RTTI is much more useful than separate files. To use separate files you need some framework to find them and parse. If it is RTTI then existing tools can be easily extended to use new feature. In case of Lazarus ppu, xml, rtti is not so different. But lets think of other applications of property attributes. For example FastScript components (scripting engine of FastReports co.) use RTTI to automatically describe pascal classes in order to use them in script. Property attributes can store descriptions, value area, and another useful info. Or my example with database components. TxxxDatabase = class property TransactionModel: TTransactionModel attributes ['engines: ms-sql, oracle, sybase-asa']; end; Using such attribute database components can easily check whether this property applied to current engine. If this is stored in ppu, xml it will not used by component developers. And once again - for Lazarus it is not a big difference. I got a practical question: Where and how should the hint be used/shown in the OI? If it is queried only manually (e.g. user moves mouse over property and waits for a hint), then a find declaration can be done and the comment next to the property can be shown. That's easy and we don't need any change or new syntax. OTOH if you want to check these flags in property editors to color misused properties, then TPropertyEditors must be extended. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sat, 20 Oct 2007 16:29:40 +0200 Tomas Hajny [EMAIL PROTECTED] wrote: On 19 Oct 07, at 13:14, Micha Nelissen wrote: Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. I see the reason is not really coming out, but I'll stop now. Well, I'd certainly have one (more) reason not to put it into RTL - I don't think that support for .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sat, 20 Oct 2007 23:55:31 +0200 (CEST) Daniël Mantione [EMAIL PROTECTED] wrote: Op Sat, 20 Oct 2007, schreef Mattias Gaertner: And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name? Only the global structure stays the same. Fields are being added and removed from defs and syms all the time and compiler development progresses. Then I vote for using a copy, which is manually updated from time to time. Coming back to the real problem: Searching and reading the ppu is as expensive as reading the sources or reading the fpdoc xml files. So, there is no need to put the property information into the ppu - except for closed sources. RTTI: The RTTI as storage has the advantage, that you don't need to explore the code. Comment/Pragma/IDE directive: Using a 'comment' has the disadvantage of expensive finding/reading the source and the advantage, that you don't need the ppu (easier cross exploring, more independent of missing units). Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] property syntax extension
On Sun, 21 Oct 2007 00:46:19 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Sat, 20 Oct 2007, Mattias Gaertner wrote: On Sat, 20 Oct 2007 16:29:40 +0200 Tomas Hajny [EMAIL PROTECTED] wrote: On 19 Oct 07, at 13:14, Micha Nelissen wrote: Jonas Maebe wrote: This is not true. You can perfectly compile a compiler using the previous' release rtl. Sure this is not the question. E.g. the people developing using the fp IDE often do this (because they have a project for the compiler, but that one does not automatically compile the rtl). Adapt the project to use the new RTL ? Anyway, seems dangerous to me, not testing possible RTL regressions then. A while ago, Peter removed several dependencies of the compiler on the new rtl (related to endian swapping routines) for this reason. I see the reason is not really coming out, but I'll stop now. Well, I'd certainly have one (more) reason not to put it into RTL - I don't think that support for .ppu file format is something so general and commonly used by (Free) Pascal programmers that it should become part of our RTL. And another: A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x. Even though the ppu format is very stable, it is not carved in stone. It's built so that a newer version can always read an older PPU file and vice versa: an old ppu unit can read a newer file, but just doesn't know how to interpret certain blocks. Are we talking about a complete ppu parser or something to only read the property info? So, maybe it would be best to keep a working copy of the ppu reader unit in the lazarus svn and give it a distinct name? I think such a unit could best go in the packages, since it is tightly bound to FPC, and definitely non-visual ? Well, it should be bound to FPC, but it should not be bound to a specific FPC version. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] extending platform flag request
On Thu, 27 Sep 2007 23:13:07 +0800
Павел Ишенин [EMAIL PROTECTED] wrote:
Hello, FPC developers' list
I had discussion with Marc about how to mark some properties as
widgetset specific (and show them in object inspector as specific for
widgetset 'xxx'). As result of discussion we found easy solution -
mark that properties with platform flag, but platform flag should be
extended to support list of platforms.
Examples:
TMenu = class(...)
published
property Detachable: Boolean read ... write ... ; platform carbon
qt; { or it can be platform 'carbon,qt' or another easier way }
end;
As result of such declaration RTTI for TMenu will have platform list
array with values 'carbon' and 'qt'. If there was no array of
platforms in declaration, then only platform flag will be set in
RTTI with empty array of platform list.
What fpc developers think? Is it hard to implement?
Note:
You can write a property editor for the property. A property editor can
hide a property in the OI or give hints. Or the TPropertyEditor can
be extended with a hook, so that the IDE can ask the widgetset, if a
property should be shown.
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
On Fri, 17 Aug 2007 10:20:13 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: [...] What local types are/will be allowed? For example, this is currently not allowed: generic TTreeT = class(TObject) type public TTreeNode = specialize TNodeT; end; And this neither: generic TTreeT = class(TObject) type public TTreeNode = class Data: T; end; end; OTOH records and pointers are allowed. Will this stay, or is this just not yet implemented? Is there a need to support this? I don't need them. I'm just asking for the codetools. So I guess the answer is: Will stay. (read: there are no further plans). Well, it seems rather strange that the type block would not allow all possible types. Only a few types can be generic as well. Nested classes cause a lot of hidden pitfalls, that's why they aren't allowed. OK, probably I should add this to the docs. I assume all types can be defined except classes and generics ? .. and objects and interfaces. It seems generic objects and interfaces are allowed, but this is not yet documented. What about generic records? Will they be implemented? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
On Thu, 16 Aug 2007 14:59:47 -0500 (CDT) Jesus Reyes [EMAIL PROTECTED] wrote: --- Jesus Reyes [EMAIL PROTECTED] escribió: --- Michael Van Canneyt [EMAIL PROTECTED] escribió: On Thu, 16 Aug 2007, Mattias Gaertner wrote: What is the state and future plans of generics? I only found the wiki page http://wiki.lazarus.freepascal.org/Generics which does not even mention the current syntax. The current syntax is descibed in the docs, reference manual. There is a chapter about generics. Feel free to comment on it; any omissions, I'll be glad to fill them in (as far as I can, I don't use generics myself). Michael. Images are so big that is difficult to follow the diagrams.. sorry I forgot to put at least a link: http://www.freepascal.org/docs-html/ref/refse38.html Thanks. Maybe the wiki page should be marked as obsolete and a link to the reference should be added? Why is the local variable block needed? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics
On Thu, 16 Aug 2007 23:31:25 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: [...] Why is the local variable block needed? It is not. I asked the same question. It was added for symmetry reasons: if a local type block is allowed, then a var block should also be allowed. But they are not different from local fields. Strange. ok. What local types are/will be allowed? For example, this is currently not allowed: generic TTreeT = class(TObject) type public TTreeNode = specialize TNodeT; end; And this neither: generic TTreeT = class(TObject) type public TTreeNode = class Data: T; end; end; OTOH records and pointers are allowed. Will this stay, or is this just not yet implemented? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] apr.ppu and apr.ppu
On Wed, 18 Jul 2007 01:11:25 +0200 Mattias Gaertner [EMAIL PROTECTED] wrote: FPC installs these ppu in two flavors: apr, apriconv, aprutil, unzip And httpd comes even in 3 flavors. Most fpc.cfg only contain the line: -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/* So it depends on the file system which one is used. Is this a feature or a bug? I reported a bug: http://www.freepascal.org/mantis/view.php?id=9332 Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TWriter writing fake methods
Here is a patch to extend TWriter.OnWriteMethodProperty. Formerly it gives only the ancestor code address, not the method data. And it misses the property path, which is needed to write sub properties like Font.OnChange. With this patch lazarus can get rid of the dirty hack to create methods. Mattias Index: rtl/objpas/classes/writer.inc === --- rtl/objpas/classes/writer.inc (revision 7172) +++ rtl/objpas/classes/writer.inc (working copy) @@ -625,7 +625,7 @@ IntToIdentFn: TIntToIdent; FloatValue, DefFloatValue: Extended; MethodValue: TMethod; - DefMethodCodeValue: Pointer; + DefMethodValue: TMethod; WStrValue, WDefStrValue: WideString; StrValue, DefStrValue: String; AncestorObj: TObject; @@ -710,16 +710,18 @@ begin MethodValue := GetMethodProp(Instance, PropInfo); if HasAncestor then - DefMethodCodeValue := GetMethodProp(Ancestor, PropInfo).Code -else - DefMethodCodeValue := nil; + DefMethodValue := GetMethodProp(Ancestor, PropInfo) +else begin + DefMethodValue.Data := nil; + DefMethodValue.Code := nil; +end; Handled:=false; if Assigned(OnWriteMethodProperty) then OnWriteMethodProperty(Self,Instance,PPropInfo(PropInfo),MethodValue, -DefMethodCodeValue,Handled); +DefMethodValue,Handled); if (not Handled) and - (MethodValue.Code DefMethodCodeValue) and + (MethodValue.Code DefMethodValue.Code) and ((not Assigned(MethodValue.Code)) or ((Length(FLookupRoot.MethodName(MethodValue.Code)) = 0))) then begin Index: rtl/objpas/classes/classesh.inc === --- rtl/objpas/classes/classesh.inc (revision 7172) +++ rtl/objpas/classes/classesh.inc (working copy) @@ -1172,8 +1172,9 @@ TFindAncestorEvent = procedure (Writer: TWriter; Component: TComponent; const Name: string; var Ancestor, RootAncestor: TComponent) of object; TWriteMethodPropertyEvent = procedure (Writer: TWriter; Instance: TPersistent; -PropInfo: PPropInfo; const MethodValue: TMethod; -const DefMethodCodeValue: Pointer; var Handled: boolean) of object; +PropInfo: PPropInfo; +const MethodValue, DefMethodValue: TMethod; +var Handled: boolean) of object; TWriter = class(TFiler) private @@ -1232,6 +1233,7 @@ property OnWriteStringProperty: TReadWriteStringPropertyEvent read FOnWriteStringProperty write FOnWriteStringProperty; property Driver: TAbstractObjectWriter read FDriver; +property PropertyPath: string read FPropPath; end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC dynamic libraries
On Wed, 7 Feb 2007 21:56:54 +0100 Jonas Maebe [EMAIL PROTECTED] wrote: On 07 Feb 2007, at 21:45, Mattias Gaertner wrote: In principle you should be able to do it with make shared in the respective directories. But I would strongly recommend against doing that, since the interface is by no means stable and consequently programs compiled against both newer and older rtl/fcl's are very likely to break if they use a different rtl (and possibly fcl, since the fcl also uses rtl functionality). That's a general problem with libs, isn't it? Yes, but especially with libraries where the developers have not committed to maintaining backwards compatibility with a particular interface and which are often changed in an ad hoc fashion. The main problem is probably that we mix both general and compiler-specific stuff in the system unit. It should probably be split into something like gcc's libgcc.a (which contains compiler-specific helper routines) and the system's libc dynamic library (system and generic C language support) before the rtl is ever distributed as a shared library. We need a version system. That's not something we need, but which most OS'es need (and don't provide, except for hacks like symlinks or different filenames). Moreover, it doesn't really solve much unless you like having 20 different versions of the same shared library on your system (which would more or less defeat the purpose of saving space, although it could still save memory if more than one FPC program is running at the same time). What problem do you want to solve with having a shared library? Plugins. For example installing a design time package. Contrary to normal apps an IDE has the advantage to recompile if needed. So Lazarus has only a subset of the normal dyn lib problems. But I know, that as soon as the IDE can load packages as dynamic libs, programmers will use dyn libs for their apps too and probably use them as shared libs. And then FPC+Lazarus bug tracker will get new trouble. So although I only want plugins, I ask about libs in general. The complaint that Lazarus programs are too large? Personally, I think switching to shared libraries will at this time introduce a lot more complaints that it will solve (and not because of a lack of a versioning system, but simply because the interface isn't anywhere near stable enough imho). Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] FPC dynamic libraries
How can I create dynamic libs of the RTL and FCL units under Linux? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC dynamic libraries
On Wed, 7 Feb 2007 20:00:20 +0100 Jonas Maebe [EMAIL PROTECTED] wrote: On 07 Feb 2007, at 19:51, Mattias Gaertner wrote: How can I create dynamic libs of the RTL and FCL units under Linux? In principle you should be able to do it with make shared in the respective directories. But I would strongly recommend against doing that, since the interface is by no means stable and consequently programs compiled against both newer and older rtl/fcl's are very likely to break if they use a different rtl (and possibly fcl, since the fcl also uses rtl functionality). That's a general problem with libs, isn't it? We need a version system. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Valid macpas syntax ?
On Sun, 3 Dec 2006 18:54:25 +0100
Jonas Maebe [EMAIL PROTECTED] wrote:
On 03 Dec 2006, at 18:05, Marc Weustink wrote:
1) using out as parametername
out is not a reserved word in macpas mode, just like in tp/fpc
modes.
Thanks. I updated the codetools.
2) the * behind msgb (and what does it mean ?)
[FPCMacOSAll:80638]
type
msgbPtr = ^msgb;
msgb = record
b_next: struct msgb *; { next message on queue }
b_prev: struct msgb *; { previous message on queue }
b_cont: struct msgb *; { next message block of message }
It means that this code isn't compiled, otherwise you'd get a parser
error. It's between {$ifc CALL_NOT_IN_CARBON}, and
CALL_NOT_IN_CARBON is defined as false at the start of the file
(since we do not support non-Carbon Mac OS 9 in the Mac OS
interfaces). That's probably why no one ever noticed this error.
I implemented $IFC, $ELSEC, $SETC, $ELIFC, $ENDC, defined identifier,
undefined identifier, 'out' and 'property' as parameter names, 'false'
and 'true' as special $SETC values in the codetools.
Now FPCMacOSAll is parsed without errors.
Can someone explain the meaning of
{$ifc defined __ppc__ and __ppc__}
?
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] sinus extended/double/single
Hi all, I don't know, if this has been answered before. Where are the Sinus/Cosinus/... functions for type single and double? When compiling the following, I get a type size mismatch warning. uses math; var a,b: single; begin a:=sin(b); end; This is because math only provides an extended sin function. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TStringList.CustomSort
On Tue, 07 Nov 2006 10:17:24 +0100 Micha Nelissen [EMAIL PROTECTED] wrote: Chris Cheney wrote: Stating the obvious: but the programmer might wish to sort by the objects or by some combination of the strings and the objects (or even by entries in an external array, unrelated to the StringList) - the indexes are therefore needed in the general case. Oh right, sorting by object contents. Seems strange to me, but perhaps useful, indeed. Of course, the efficient way to build a sorted list is to set Sorted to False and to sort the list after all the items have been added. It doesn't matter in O-time: both are O(n log n). Nevertheless, you probably will save some function call overhead. Insertion Sort is O(n^2). Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] gtk2 include file at wrong place
Maybe there is a deeper meaning, but I guess it a bug. Can someone move packages/extra/gtk2/gtkcellrenderercombo.inc to the other gtk include files packages/extra/gtk2/gtk+/gtk/gtkcellrenderercombo.inc Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gtk2 include file at wrong place
On Fri, 06 Oct 2006 19:13:42 +0200 Florian Klaempfl [EMAIL PROTECTED] wrote: Mattias Gaertner schrieb: Maybe there is a deeper meaning, but I guess it a bug. If you say so, iirc you wrote the gtk2 header conversion :) Yes, but I didn't add this file. Thanks. Mattias Can someone move Done. packages/extra/gtk2/gtkcellrenderercombo.inc to the other gtk include files packages/extra/gtk2/gtk+/gtk/gtkcellrenderercombo.inc Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TLCLMemanager
On Fri, 29 Sep 2006 16:32:23 +0200 (CEST) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Fri, 29 Sep 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Fri, 29 Sep 2006, Vincent Snijders wrote: Hi, The LCL contains the non-visual unit LCLMemManager: http://svn.freepascal.org/svn/lazarus/trunk/lcl/lclmemmanager.pas I would like to propose that you rename it and add it to the FCL. It contains some simple (base) clasess for pooling records and objects. For the binary trees benchmark at http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytreeslang=all I wrote an alternative using the TLCLNonFreeMemManager. The alternative runs in 40% of the time of the original and uses less memory. If the lazarus people agree with this, I see no problem in doing so. I think they will agree, but I will ask to make sure. What name would you suggest ? A name change because of the LCL in the name. But just TMemManager is too generic, IMHO. What about TMemoryPool and TNonFreeMemoryPool? Don't you think the word MemoryManager (MM) should be in it ? This could cause confusion with TMemoryManager. like pooledmm ? (and class TPooledMemoryManager) ? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] h2pas bugs
Under which category should h2pas bugs be reported? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] h2pas bugs
On Wed, 20 Sep 2006 22:22:39 +0200 Micha Nelissen [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: Under which category should h2pas bugs be reported? Probably the 'these-will-only-be-solved-if-you-also-provide-a-patch' category :-). I know, but hope dies last. Maybe I can raise some more interest in this tool: I wrote a h2pas gui as lazarus package (components/h2pas/h2paswizard.lpk). It is also a demonstration of the new text converter tools of the IDE. There are already a few tools, which handle some of the h2pas shortcomings. I will write a wiki page. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
On Mon, 4 Sep 2006 07:13:53 +0200 Martin Schreiber [EMAIL PROTECTED] wrote: On Monday 04 September 2006 02.55, Luiz Americo wrote: I'd like to propose change TComponent.Tag type from longint to PtrInt. I know it's not a good programing practice, but sometimes this property can be used to hold pointers. In 32bit there's not many problems since pointer and longint have the same size, but the thing changes in 64 bit. The choice of PtrInt has the benefit of not modifying nothing in 32bit, while in 64bit you getting a integer of the same size of pointers. What do you think? Agreed. Me2. Just one disadvantage: The Tag is published. If someone stores a 64bit value and the component is stored, the stream can not be read under 32bit anymore. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
On Mon, 04 Sep 2006 11:56:06 +0200 Vincent Snijders [EMAIL PROTECTED] wrote: Daniël Mantione schreef: Op Mon, 4 Sep 2006, schreef Mattias Gaertner: Me2. Just one disadvantage: The Tag is published. If someone stores a 64bit value and the component is stored, the stream can not be read under 32bit anymore. ...which makes it impossible to use streams for anything derived from Tcomponent, which is really a lot. I don't think we should break this feature to allow broken code to work. Really a lot? Can you give examples where numbers maxint are streamed? I agree with Luiz, that there is a lot more code using tag as storage for a pointer, than code streaming big numbers. So for compatibility it should be PtrInt. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Propose: change TComponent.Tag from longint to PtrInt
On Mon, 04 Sep 2006 13:16:11 +0200 Vincent Snijders [EMAIL PROTECTED] wrote: Daniël Mantione schreef: Op Mon, 4 Sep 2006, schreef Vincent Snijders: Daniël Mantione schreef: Op Mon, 4 Sep 2006, schreef Mattias Gaertner: Me2. Just one disadvantage: The Tag is published. If someone stores a 64bit value and the component is stored, the stream can not be read under 32bit anymore. ...which makes it impossible to use streams for anything derived from Tcomponent, which is really a lot. I don't think we should break this feature to allow broken code to work. Really a lot? Can you give examples where numbers maxint are streamed? Even if you stream a zero it breaks. Then Lazarus uses an advanced streaming mechanism, which looks at the size of the value and decides to 1, 2, 4 or 8 bytes for an int64, when streaming a form. I thought this was more or less standard behaviour. It is. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] build unit dependency list
On Fri, 4 Aug 2006 09:53:00 -0300
Mario R. Carro [EMAIL PROTECTED] wrote:
Hi, I have a few hand made makefiles for some (up to now) Delphi projects
that
I use to build the releases. I would want to be able to automagically
generate the dependencies for the units in the projects.
I found that Lazarus has a dependencies view window. So after some browsing I
wrote the following minimal test program:
program getpdeps;
{$mode objfpc}{$H+}
uses
Classes,
CodeCache,
CodeToolManager;
var
IntfFiles, ImplFiles: TStrings;
Cache: TCodeCache;
Buffer: TCodeBuffer;
begin
Cache := TCodeCache.Create;
IntfFiles := TStringList.Create;
ImplFiles := TStringList.Create;
try
Buffer := Cache.LoadFile(ParamStr(1));
CodeToolBoss.ActivateWriteLock;
try
CodeToolBoss.FindUsedUnitFiles(Buffer, IntfFiles, ImplFiles);
WriteLn('intf=' + IntfFiles.CommaText);
WriteLn('impl=' + ImplFiles.CommaText);
finally
CodeToolBoss.DeactivateWriteLock;
Buffer.Free;
end;
finally
Cache.Free;
IntfFiles.Free;
ImplFiles.Free;
end;
end.
It does what I need but it fails because it couldn't find some units. How do
I
tell CodeToolBoss where to find them?
See the codetools example finddeclaration.lpi.
BTW:
CodeToolBos already creates a code cache and many functions expect, that you
only use that one.
To load a file, use Buffer:=CodeToolBoss.LoadFile.
And the ActivateWriteLock is only needed, when doing multiple searches.
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpc 2.1.1, x86_64, gtk crashes
Hi all, I'm hunting a strange bug. The Lazarus IDE works with gtk1 under fpc 2.0.2 on x86_64 without problems. But with fpc 2.1.1 it crashes when opening any modal form. For example open file. Compiling with -gv and starting with valgrind runs without access violation. With heaptrc: bug appears at the same position. With cmem: bug appears with a backtrace without any lineinfo. With cthreads: bug appears with a backtrace without any lineinfo. With -gv, but not in valgrind: bug appears with a backtrace without any lineinfo. I was not yet able to reproduce the error in a small test application. Maybe someone of the fpc devels has an idea, where I can start searching? What x86_64 bugs could be related to this problem? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] opengl unit gl on x86_64
On a x86_64 system I tried to run a program using the opengl 'gl' unit. It failed, because the function 'glAccum' does not exist. Commenting that one 'solved' the problem. Can GetProcAddress be used to load a lib function dynamically, without bombing if the function is missing? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] intel Mac
Are there any known problems running FPC apps with Rosetta? What's the state of the Intel Mac native port? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 17 May 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that pkg is compiled with in package.fpc ? Well, the point is, you could get all source pathes from the currently valid ppus. If they are compiled on this system? Most people use precompiled FPC in combination with lazarus. You don't need the sources. The .ppu contains everything you need. They don't contain implementation in human readable form. For example if I have the TComponent.Name property, I want to be able to jump to TComponent.SetName method declaration and then to the implementation. You need sources for that. Does the ppu provide (relative) source locations? According to daniel: yes But you should separate 2 things: - Provide feedback (tooltips, code completion) - View actual sources. For the first, the .ppu is enough. In Delphi 'Find declaration' also doesn't work half the time... Reading .ppu files is definitely planned for the codetools. But as Daniel pointed out: If the .ppu format changes all ppu become unreadable. While if an include path changes in the FPC sources, only a few files can't be browsed. IMHO parsing .ppu is only a nice-to-have feature. The parsing of sources has higher priority. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On Wed, 17 May 2006 10:58:46 +0200 (CEST) Peter Vreman [EMAIL PROTECTED] wrote: On Wed, 17 May 2006 09:47:00 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Wed, 17 May 2006, Vincent Snijders wrote: Michael Van Canneyt schreef: On Wed, 17 May 2006, Marco van de Voort wrote: Most logical would be to store the conditionals that pkg is compiled with in package.fpc ? Well, the point is, you could get all source pathes from the currently valid ppus. If they are compiled on this system? Most people use precompiled FPC in combination with lazarus. You don't need the sources. The .ppu contains everything you need. They don't contain implementation in human readable form. For example if I have the TComponent.Name property, I want to be able to jump to TComponent.SetName method declaration and then to the implementation. You need sources for that. Does the ppu provide (relative) source locations? According to daniel: yes But you should separate 2 things: - Provide feedback (tooltips, code completion) - View actual sources. For the first, the .ppu is enough. In Delphi 'Find declaration' also doesn't work half the time... Reading .ppu files is definitely planned for the codetools. But as Daniel pointed out: If the .ppu format changes all ppu become unreadable. While if an include path changes in the FPC sources, only a few files can't be browsed. IMHO parsing .ppu is only a nice-to-have feature. The parsing of sources has higher priority. This is incorrect, the generic .ppu format didn't change for the last several years. The code needed to parse ppu's and retrieve symbol info is also stable for the last years. See how good an old ppudump works on current ppu files. The changes in the ppu are only at the end of the entries and doesn't influence the start of the entries that contain the name and location. Great. Then I will take a look. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] darwin - rtl include files
The unit baseunix.pp is available for darwin powerpc (fpc 2.1.1). I guess
FPC_USE_LIBC is disabled for this target, so it seems to include {$i
bsyscall.inc}.
But it seems there is no such file for darwin. Only
./freebsd/i386/bsyscall.inc
./freebsd/x86_64/bsyscall.inc
./linux/arm/bsyscall.inc
./linux/i386/bsyscall.inc
./linux/powerpc64/bsyscall.inc
./linux/powerpc/bsyscall.inc
./linux/sparc/bsyscall.inc
./linux/x86_64/bsyscall.inc
./linux/m68k/bsyscall.inc
Where is the mistake?
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On Tue, 16 May 2006 15:31:16 +0200 (CEST) [EMAIL PROTECTED] (Marco van de Voort) wrote: ... I guess FPC_USE_LIBC is disabled for this target, ... Where is the mistake? See above. Jonas choose to only implement FPC_USE_LIBC for Darwin. Thanks. AFAIK darwin has a libc, but FPC does not provide a unit for it. Right? And the FPC_USE_LIBC is set for all rtl sources under darwin. Right? Is there a somewhere a list of the flags set in the FPC sources? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On Tue, 16 May 2006 15:51:43 +0200 (CEST) [EMAIL PROTECTED] (Marco van de Voort) wrote: [EMAIL PROTECTED] (Marco van de Voort) wrote: ... I guess FPC_USE_LIBC is disabled for this target, ... Where is the mistake? See above. Jonas choose to only implement FPC_USE_LIBC for Darwin. Thanks. AFAIK darwin has a libc, but FPC does not provide a unit for it. FPC doesn't provide a unit for libc at all. BaseUnix/Unix etc define what you get, and how that unit is implemented is not defined, dynlibs the same for shared libs etc. In practice there are two basic implementations; syscalls and getting access to the needed functions by linking to libc. Right? And the FPC_USE_LIBC is set for all rtl sources under darwin. Yes. Note that it can also be set for Linux and FreeBSD (though that might require some minimal maintainance) Right? Yes. But I still have no clue what you are exactly looking for. Maybe I could give you more direct hints if you said what you actually need :-) see also (the bit outdated) docs I made while working on the unix rtl: http://www.stack.nl/~marcov/unixrtl.pdf http://www.stack.nl/~marcov/buildfaq.pdf http://www.stack.nl/~marcov/porting.pdf Is there a somewhere a list of the flags set in the FPC sources? No. Not like that. They often change. That's exactly my problem. How to keep the codetools up2date? How can they find the right include paths and unit paths? Using fpmake is difficult, as a lazarus compiled with fpc 2.0.2 should be able to parse the fpc 2.1.1 fpmake files, which might use newer functions. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] darwin - rtl include files
On Tue, 16 May 2006 16:11:43 +0200 (Romance Daylight Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Tue, 16 May 2006, Mattias Gaertner wrote: On Tue, 16 May 2006 15:51:43 +0200 (CEST) [EMAIL PROTECTED] (Marco van de Voort) wrote: [EMAIL PROTECTED] (Marco van de Voort) wrote: ... I guess FPC_USE_LIBC is disabled for this target, ... Where is the mistake? See above. Jonas choose to only implement FPC_USE_LIBC for Darwin. Thanks. AFAIK darwin has a libc, but FPC does not provide a unit for it. FPC doesn't provide a unit for libc at all. BaseUnix/Unix etc define what you get, and how that unit is implemented is not defined, dynlibs the same for shared libs etc. In practice there are two basic implementations; syscalls and getting access to the needed functions by linking to libc. Right? And the FPC_USE_LIBC is set for all rtl sources under darwin. Yes. Note that it can also be set for Linux and FreeBSD (though that might require some minimal maintainance) Right? Yes. But I still have no clue what you are exactly looking for. Maybe I could give you more direct hints if you said what you actually need :-) see also (the bit outdated) docs I made while working on the unix rtl: http://www.stack.nl/~marcov/unixrtl.pdf http://www.stack.nl/~marcov/buildfaq.pdf http://www.stack.nl/~marcov/porting.pdf Is there a somewhere a list of the flags set in the FPC sources? No. Not like that. They often change. That's exactly my problem. How to keep the codetools up2date? How can they find the right include paths and unit paths? IMHO: Eventually, you'll have to switch to parsing the .ppu files for some parts. Huh? Can you give an example? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Output flush on pipes
On Sun, 14 May 2006 12:03:34 +0200 (CEST)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
On Sun, 14 May 2006, Daniël Mantione wrote:
Op Sun, 14 May 2006, schreef Michael Van Canneyt:
On Sun, 14 May 2006, Daniël Mantione wrote:
Op Sun, 14 May 2006, schreef Martin Schreiber:
Since some time FPC doesn't flush output on pipes after writeln.
On linux I can use a pseudo terminal, what can I do on win32 to
get flushed output from FPC into the message window of MSEide?
It is strongly recommended against to parse the compiler output, as
it is designed for humans, not computers. The formatting of the
compiler output can therefore change in time and can also be
configured by the user in any language. Some people are doing it
anyway, like Lazarus.
The compiler has an interface designed for computers and that is
through the compiler and comphook units. This allows you to
retrieve the messages neatly. If you want process separation,
please write a wrapper that puts the messages in a computer
friendly way, and we'll include it in FPC.
We could do this ourselves by assigning a unique number to each error.
(and keeping these numbers)
I think a command line output for computers needs to be a bit more
advanced, take for example this error message:
testc.pas(11,1) Fatal: Syntax error, BEGIN expected but identifier Z
found
We have:
* The source file
* The error location
* The error severity
* The error message, containing two parameters.
Both the severity and error message are currently unpredictable, i.e.
they can be translated for example. Some IDE's may want to have access
to the error messages their parameters as well.
A command line output for computers also needs to be extendable, if we
want to output more information, this should not break existing
applications.
For example, a good way to output this error message in a computer
friendly format would be:
error:(file='testc.pas';line=11;column=1;message_code='02003_F';
message='Syntax error, $1 expected but $2 found';
parameters=('BEGIN','IDENTIFIER Z'));
I'm all for such a message form; it should be easy to add with some -v
switch... But
- This is no use if the message code changes over time,
because that is still the unique identifier for the error...
- The message itself should not be given, IMHO.
The program can look it up in the error message file...
How can it find out, which message file to use?
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Output flush on pipes
On Sun, 14 May 2006 11:46:33 +0200
Florian Klaempfl [EMAIL PROTECTED] wrote:
Michael Van Canneyt wrote:
On Sun, 14 May 2006, Daniël Mantione wrote:
Op Sun, 14 May 2006, schreef Michael Van Canneyt:
On Sun, 14 May 2006, Daniël Mantione wrote:
Op Sun, 14 May 2006, schreef Martin Schreiber:
Since some time FPC doesn't flush output on pipes after writeln.
On linux I can use a pseudo terminal, what can I do on win32 to get
flushed output from FPC into the message window of MSEide?
It is strongly recommended against to parse the compiler output, as
it is designed for humans, not computers. The formatting of the
compiler output can therefore change in time and can also be
configured by the user in any language. Some people are doing it
anyway, like Lazarus.
The compiler has an interface designed for computers and that is
through the compiler and comphook units. This allows you to retrieve
the messages neatly. If you want process separation, please write a
wrapper that puts the messages in a computer friendly way, and we'll
include it in FPC. We could do this ourselves by assigning a unique
number to each error. (and keeping these numbers)
I think a command line output for computers needs to be a bit more
advanced, take for example this error message:
testc.pas(11,1) Fatal: Syntax error, BEGIN expected but identifier
Z found
We have:
* The source file
* The error location
* The error severity
* The error message, containing two parameters.
Both the severity and error message are currently unpredictable, i.e.
they can be translated for example. Some IDE's may want to have access
to the error messages their parameters as well.
A command line output for computers also needs to be extendable, if we
want to output more information, this should not break existing
applications.
For example, a good way to output this error message in a computer
friendly format would be:
error:(file='testc.pas';line=11;column=1;message_code='02003_F';
message='Syntax error, $1 expected but $2 found';
parameters=('BEGIN','IDENTIFIER Z'));
I'm all for such a message form; it should be easy to add with some -v
switch... But
- This is no use if the message code changes over time,
because that is still the unique identifier for the error...
- The message itself should not be given, IMHO.
The program can look it up in the error message file...
Parsing the current error messages isn't that hard?
For the quick fix items (like eclipse and lazarus), we need the message ID
and parameters, independent of current localization.
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] gtk1 linklib directive under FreeBSD
I heard that the gtk1 libs under FreeBSD are libglib-12.so, libgdk-12.so and
libgtk-12.so.
But at the moment the linklib directive for FreeBSD defines
{$ifdef FreeBSD}
gtkdll='gtk12';
{$linklib gtk12}
without the '-'.
Can someone with FreeBSD please test if changing
packages/extra/gtk/gtk/gtk.pp
packages/extra/gtk/gdk/gdk.pp
packages/extra/gtk/glib/glib.pp
fixes the issue.
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gtk1 linklib directive under FreeBSD
forwarded: -- Two or three months ago I tested Lazarus on FreeBSD 6.0 RELEASE. After installing some missing libs (like pixbuf-devel, etc.) it compiled and run without any problems. Lazarus version was 0.9.12 IIRC. -- To my best knowledge, this naming depends on what version and what packages branch one is using . FreeBSD, when confronted with this says to use pkgconfig, and doesn't want to help out with a couple of symlinks to ease the situation. IOW they don't care about anything but GCC. I recommend filing a send-pr about this. Since there is no way currently to make lazy bound dll names variable without recompiling on target, and most people are using release versions, I chose to wait with this change till more people are over to the -1.2 syntax, to keep the amount of users that have to symlink manually to a minimum. -- This symlink/library practice on linux/unix is simply a mess, and I personally also don't see another portable way but to use tools such as pkgconfig and friends. Afaik the output of pkgconfig is not gcc specific, but ld-specific (at least the output of sdl-config -- libs) is. So if you want to use it for an internal linker, you indeed have to parse that output (as opposed to similar statements in the source). -- I am not fit in Linux and I have only one SuSE-10-Installation running where I had also some trouble when installing Lazarus. But on several PCs I have 5 FreeBSD installtaions running from FreeBSD 5.5RC, 6.0 Release, to 6.1RC in several Patchlevels. I installed Lazarus from source on 4 of them using version 0.9.12, 0.9.14 and 0.9.15 (from SVN). All these FreeBSD installations show the same behavior and set the minus char into the library name. So for me, this seems to be FreeBSD specific. But I could live with this problem (if documented) when installing a Lazarus beta version in FreeBSD from source. gmake's Makefile additionally could test the 3 libs and set (if missing) those symlinks or can patch the Free Pascal source files if needed. But this behavior is of course not acceptable for a final 1.0 binary installation. Here those libs _must_ be linked and later unlinked by a deinstaller (even this symlinking is not so nice). But a severe problem seems for me, that the produced and distributed apps which are linked against glib, gdk und gtk will have the same problem and may not run if the wrong filename is used on different FreeBSD target. But on the other hand I am a little bit confused about the answer and that pixbuf-devel had to be installed? There are no *-devel packages in (Free/Net/Open)-BSD. These are typical Linux names. Did he really compile a native FreeBSD version or did he install the Linux version in the Linuxulator? The Linux version of course uses the RedHat-libs in /usr/compat/linux/... without the -. All BSDs install always complete libraries. a glib, gtk oder gdk-pixbuf includes the libs themselves and all headers etc. There are no additional developer libraries available! (I never tried to use such a combination for Lazarus except on NetBSD. There Lazarus/Linux is working but Free Pascal/Linux traps :-( so Lazarus is unusable in any combination at the moment.) I use different versions of the FreeBSD ports for the different installations, mostly actual ones installed via ctm. The behavior is the same when the ports are installed with the release.) I hope, that these informations will help a bit to fix the problem. --- Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ReallocMem with CMem
On Wed, 8 Mar 2006 18:19:40 +0100 Micha Nelissen [EMAIL PROTECTED] wrote: On Wed, 8 Mar 2006 18:10:38 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Wed, 8 Mar 2006, schreef Micha Nelissen: Shouldn't ReallocMem in CMem zero the newly allocated bytes ? No, it is the responsibility of the programmer. Good. Nope. At least the compiler depends on it being zeroed. The FPC heap manager zeroes it, as well. Not under linux. Are you sure? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus
On Mon, 23 Jan 2006 12:20:29 -0200 Felipe Monteiro de Carvalho [EMAIL PROTECTED] wrote: On 1/21/06, VisionForce [EMAIL PROTECTED] wrote: So where would I need to start if I wanted to add this to Lazarus? On Lazarus website, click on Project Roadmap. There you will find the status of Docking (= the combination of forms). It is marked as In Progress, so probably someone is already started working on this. Now you need to find who is working on Docking and ask him how you can help. Vincent probably knows who is working with docking (if someone is at all). Well, I'm working on it. At least from time to time I am. To implement this feature, I would: * Search (google) how docking can be done using the Windows API on a standard Windows API program * Search (google) how docking can be done using Gtk on a standard Gtk program (if you want to add Linux support too) * Research how to use the Delphi docking interface and try to make methods compatible with it. I know at least that a few methods needs to be implemented on TControl: function ManualDock(NewDockSite: TWinControl; DropControl: TControl = nil; ControlSide: TAlign = alNone): Boolean; procedure Dock (NewDockSite: TWinControl; ARect: TRect); dynamic; function ManualFloat(ScreenPos: TRect): Boolean; Use ManualFloat to undock the control programmatically. ScreenPos is the rectangle in which the control is displayed when it starts floating These already work. But some messages are not properly delegated in the win32 interface. Although this is more a CustomForm.Parent issue, than docking. function GetDockEdge(MousePos: TPoint): TAlign; dynamic; Use GetDockEdge to get the edge on which another control should be docked when it is dragged over the control. MousePos is the position of the mouse. GetDockEdge is called automatically during drag-and-dock operations involving the control. IMHO docking with TAlign alone is not intuitive for the user. It requires an internal tree of rows and columns, which the user can't see and limits the users choices for dock layouts. That's why I started another approach: Anchor docking. Here the internal representation fits to what the user sees - WYSISWYG. It already works, even docking in pages. see below for the ToDos. There are probably many other things that need to be implemented =) Yes. - A good dock manager with smart save and restore abilities. Especially for hidden/reshown forms. - Fix the win32 message delegation. - Frames for gtk forms - Form.BoundsRect changes. I'm not sure yet, how. - DragDrop docking Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus
On Sat, 21 Jan 2006 17:16:02 -0600 VisionForce [EMAIL PROTECTED] wrote: Is there a way I can change Lazarus to an MDI style instead of having that floating desktop style? No. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] LibC for darwin
Is there a libc for MacOSX? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList or TFPList - a Linked list ?
On Wed, 14 Dec 2005 21:33:34 +0100 Micha Nelissen [EMAIL PROTECTED] wrote: Hi, I've been thinking about adding a linked list implementation to either TList or TFPList. The basic problem to that is of course 1) space overhead of linked list is quite large 2) Index[..] will be O(N) For (1) I was thinking about making a linked list of an array of items, for example 14 pointers (so that 8 bytes are left for next pointer and memory manager needs on 32 bit platform). To solve (2), we can make the observation that generally people access lists in a linear fashion, and we might cache the previous and next list entry. This will break all random access uses. For example sorting a TList. The big advantage is getting rid of the many reallocs needed to grow the lists, because one usually doesn't set Capacity in advance, but keeps adding items until done. TFPList/TList grows exponentially, which is pretty good for a generic dynamic array. It results in O(n). Using aggregation possibly, TStringList must benefit from it too. What do you think about it ? Your trick will only give a constant factor on growing/shrinking the list memory, gives an extra O(n) factor for sorting a TList, the caching costs time, and the memory usage will also grow. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList or TFPList - a Linked list ?
On Wed, 14 Dec 2005 22:40:40 +0100 Micha Nelissen [EMAIL PROTECTED] wrote: On Wed, 14 Dec 2005 21:53:58 +0100 Mattias Gaertner [EMAIL PROTECTED] wrote: Your trick will only give a constant factor on growing/shrinking the list memory, gives an extra O(n) factor for sorting a TList, the caching costs time, and the memory usage will also grow. You may be underestimating the impact of the heap manager. I just checked the code in lists.inc. When there are less than 128 items, the list is increased by 8 items. So when adding 1000 (to take a number) items, the list is copied at least 10, possibly 13 times, 12 - 28 - 44 - 60 - 76 - 92 - 108 - 124 - 140 - 206 - 325 - ~500 - ~780 - ~1000. For the linked list case, no memory is copied. It was not my decision to increase TList by only one fourth. But still the list grows exponentially, which means for 1000 items there will be only c times 1000 copies. For a growing of 25% as it is now c is less than 4. Sure, if you're going to sort a list, you should not use linked list of course, but an array (or tree maybe). Due to memory fragmentation, it is debatable whether memory usage will really grow significantly more for linked list. Indeed. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList or TFPList - a Linked list ?
On Wed, 14 Dec 2005 15:03:58 -0700 Sterling Bates [EMAIL PROTECTED] wrote: Mattias Gaertner wrote:Your trick will only give a constant factor on growing/shrinking the list memory, gives an extra O(n) factor for sorting a TList, the caching costs time, and the memory usage will also grow. Just saw this last statement. The memory usage is very comparable to TList, even with bi-directional (doubly-linked) lists, since TLists tend to grow by leaps. For example, assuming a linked list item comprises of only a next pointer, it requires 8 bytes of memory (4 for the structure itself, 4 for the next pointer). Plus some bytes for the memory manager for each mem block. Typically 8. In this case, 10,000 entries occupy 80,008 bytes (80,000 + 4 for pointer to First + 4 for pointer to Last), ~160,000 distributed around the memory table. Also keep in mind that the data payload for the linked list item is usually contained within the structure itself. A TList (stripped down for this case) requires 4 bytes for the list allocation, plus 4 bytes per list entry. 10,000 entries occupy 80,004 bytes. ~40,000 Now, two things: 1. With automatically growing lists you have a very high likelihood of unused pointers, so while a linked list of 10,000 items is utilizing all 80,004 bytes of memory, the TList allocated (10,000-TList.Count)*4 unused bytes of memory. i.e. plus a maximum of 25% with the current implementation ~50,000 2. The TList entry only points to the actual data payload, meaning another 4+n bytes must be allocated to store the data. This means an additional 40,000 bytes is required for a TList vs. a linked list. Huh? On the other hand, this is equalized in a doubly-linked list. Disclaimer: this is all based on the Delphi implementation of TList, and may differ slightly (but probably not much) for the FP lists. The main problem is the mem fragmentation. Here a growing TList can need up to 4 times its used memory. So in worst case it will need the memory of a single linked list. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList or TFPList - a Linked list ?
On Wed, 14 Dec 2005 16:22:53 -0700 Sterling Bates [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: If the linked list item contains the whole data, then you are either not talking of the generic list this thread is about, or you use templates. In the later case a TList will also use templates and the 'payload' is the same. That's true of records, sure. Someone could also create a TLinkedListItem base class from which to descend and store their data there. The next prev pointers can be stored in the base class. Well, if you use objects, then you get even more mem overhead ... :) Anyway, thanks for the discussion :) With pleasure. We could discuss it endless. Micha's original idea was even to use a block linked list. :) Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On Thu, 17 Nov 2005 10:27:08 +0100 (CET) [EMAIL PROTECTED] (Marco van de Voort) wrote: Dani?l Mantione [EMAIL PROTECTED] wrote: In other words, you still need to duplicate an awfull lot of code. That is the same for 8bit and widestring. No, that is not true. There would be two rtls based on the same code. Can you give some examples, what parts of the RTL should change for widestring? All typecasts to OS parts, libraries and functions. E.g. accessing mysql is now done with pchar(ansistring) And they should be replaced by what? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On Thu, 17 Nov 2005 11:04:01 +0100 (CET) [EMAIL PROTECTED] (Marco van de Voort) wrote: [EMAIL PROTECTED] (Marco van de Voort) wrote: Dani?l Mantione [EMAIL PROTECTED] wrote: In other words, you still need to duplicate an awfull lot of code. That is the same for 8bit and widestring. No, that is not true. There would be two rtls based on the same code. Can you give some examples, what parts of the RTL should change for widestring? All typecasts to OS parts, libraries and functions. E.g. accessing mysql is now done with pchar(ansistring) And they should be replaced by what? Nothing. You can't. It was meant to illustrate that there is more to it than simply declaring an tbasicstring or so alias and fixing some internal routines. It will just mean full checking and ifdeffing of/in every part of the entire fpc/lazarus repository, and maintaining that, the added support burden etc. :) That's exactly why I asked the trick questions. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On Thu, 17 Nov 2005 11:31:45 +0100 Dr. Karl-Michael Schindler [EMAIL PROTECTED] wrote: Hi Following this discussion, I want to throw in my 2 cents as well: On a real long term (like 5 or 10 years from now), the solution should be as clean as possible with as little awkward parts because of backward compatibility. This favors of a more separate solution with a compatibility layer. Sure enough, this means more work to set it up and maintain it. Therefore, it will take longer to have it running, but in the end it will prevent the situation, I'd like to call the A20 gate situation. Who knows the future? Maybe in 10 years 16bit non multi 'byte' encoding is sufficient for all remaining languages. Or maybe 32bit encodings will become the default. Speaking for lazarus: we want to support the whole unicode and UTF8 is the easiest to achieve that. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode RTL
On Wed, 16 Nov 2005 17:25:29 +0100 (CET)
Daniël Mantione [EMAIL PROTECTED] wrote:
Op Wed, 16 Nov 2005, schreef Tomas Hajny:
You're right that strings are used everywhere, but I don't think that
this really means that you need to add special support for widestrings
everywhere. In many places you can pass a DBCS/MBCS string to it today
(e.g. encoded using UTF-8) and it wouldn't cause any harm. From my point
of view, you need some kind of special support mainly for sort
operations (which includes your TList) and then for visual classes
(length of text for controls, etc.). In addition, you certainly need to
have a proper routines for I/O. However, e.g. your particular example in
the forum discussion is IMHO conceptually wrong. Turning a string around
just cannot be performed this way (this is unsupported by design for
DBCS/MBCS texts; not even mentioning the fact that the example is
somewhat artificial). People who want to perform such an operation
need to analyse and design the implementation properly, probably by
translating the ansistring to a widestring first in this case. How this
translation is performed is another question and it depends on
programmer's decision. It could be that the string already _is_ an UCS2
string (and translation to widestring means that you just copy it byte
by byte), it could be UTF-8 and it could be even a simple string created
in particular codepage (SBCS). This is programmer's decision (trade-off
between the widest support and the best performance); the same way that
he has to decide whether he'd use multi-platform APIs or native API of a
particular platform, or whether he'd use/import XxxxW or XxxxA API
function for his Win32 application.
Maybe I'm still overlooking the real issues. Please, give me more
concrete examples which cannot be resolved at the moment, we could
discuss them (and then possibly come to a conclusion that separate RTL
would be better/necessary).
*Sigh*, this going to be a long e-mail for a subject I don't interrest
myself not much. Here we go.
There are a few models you can use:
Model 1: Be ignorant about multibyte character sets.
UTF-8 was designed to behave well with programs that assume US-ASCII,
therefore you reasonable results.
If you assume nothing about the ordering of characters in the string, do
not try to break it into pieces, do not modify them (i.e. uppercase),
things work out in many situations.
The limitations of this model is that there are situations were the
ordering is important, strings need to be broken up into pieces etcera.
Reversing a string is an extreme example where strings need to be broken
into pieces, but there are way more examples.
Obviously, if code should be ignorant about the charset, people wouldn't
be asking about Unicode support.
You can also be partially ignorant about charsets. I.e., you leave pos,
insert etc as is and leave it up to the programmer not to do tricks like
reversing strings.
In the case you are ignorant pos('ë','Daniël'); is a substring search
of a string of 2 bytes into a seven byte long string.
I don't understand, why you connect UTF8 with 'ignorant of MBCS'.
UCS-2 can be used as ignorant as UTF8.
Even UCS-4 and UTF32 will not solve all problems. Think about arabic RTL.
You must extend old souce code if you want to support all languages anyway.
Widestrings lets you keep some old code and introduces some new problems.
The same is true for UTF8.
That's a matter of choice and heavily depends on the old code.
What's more important, is that widestring needs sometimes two widecharacters
for one character. So, you have MBCS problems too.
For Lazarus we decided to use UTF8, because
- UCS-4/UTF32 is too much memory overhead. That means we must use a 1 or 2
byte encoding, which implies, that we have to implement MBCS functions
anyway.
- UTF8 works with ASCII without conversion
Model 2: Use an internal encoding
-
The UCS-2 widestring stuff is an example of this. You could also use
UCS-4. The advantage is you can do any operation on the string you like,
you do not get into trouble. Trouble is a lot of conversions when talking
with the external world.
In this case pos('ë','Daniël'); is a widechar search into a widestring.
You can also decide that your internal encoding is UTF-8, no problem. In
that case pos('ë','Daniël') is a widechar search into an ansistring.
The desirability versus UCS-2 and UTF-8 is a matter of taste. You can walk
through UCS-2 strings with for-loops. You cannot do this with UTF-8,
unless we would implement [] in O(n) time (or you are ignorant, model 1).
With UCS-2 you can reuse a lot of code by just changing the string type.
You must include all stuff twice (either by making a separate Unicode rtl,
or doubling code in your units).
With UTF-8 you can reuse
Re: [fpc-devel] Templates / Generics
On Tue, 08 Nov 2005 21:06:10 +0100 [EMAIL PROTECTED] wrote: [...] ECMA Standard 334 But this is a standard for C#, so totally useless for Pascal syntax-wise. Why useless? You can do exactly the same in a Pascal-styled way. We need just a minor part from the standard for the FPC compiler. Why do you think, that Borland will use ECMA Standard 334 for C# for the Delphi generics? Is there any official page, document, statement? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Mon, 07 Nov 2005 19:29:51 +0100 Bram Kuijvenhoven [EMAIL PROTECTED] wrote: Micha Nelissen wrote: On Mon, 07 Nov 2005 14:45:19 +0100 Bram Kuijvenhoven [EMAIL PROTECTED] wrote: Does for generics fit into Pascal? Well, we use [] for array indexing, and () for parameter passing to procedures/functions/methods. So why not use for passing parameters to generic types? And, similar to the case of function calls and array indexing, these could follow the type identifier directly. You got a point here, but the where T is Foo stuff is crap then, don't you agree? TGTypeT: TBaseType = class(...) ... end; is better then, when compared to your parameter example. I indeed don't like the where T is foo of Chrome :) So you are totally right, TGTypeT : TBaseType is a lot better and a lot more consistent (with e.g. function parameter syntaxis). Let's sum up the different points for the syntax so far: - will probably be used by Delphi - bites the operator - makes the parser more difficult and slow - makes pascal more ambigious - alternatives: modifiers or not yet used brackets like (! !) or (# #) It seems to me, it's a question of: Follow Delphi generics or not. And we don't know, where Delphi will go. They will not have generics in the next one and a half year and as always: They will do a few things completely different than expected. If we follow, then we will do, as Florian et al said. If not, then the is not the best solution. Is this correct so far? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Mon, 07 Nov 2005 22:41:06 +0100 Florian Klaempfl [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: On Mon, 07 Nov 2005 19:29:51 +0100 Bram Kuijvenhoven [EMAIL PROTECTED] wrote: Micha Nelissen wrote: On Mon, 07 Nov 2005 14:45:19 +0100 Bram Kuijvenhoven [EMAIL PROTECTED] wrote: Does for generics fit into Pascal? Well, we use [] for array indexing, and () for parameter passing to procedures/functions/methods. So why not use for passing parameters to generic types? And, similar to the case of function calls and array indexing, these could follow the type identifier directly. You got a point here, but the where T is Foo stuff is crap then, don't you agree? TGTypeT: TBaseType = class(...) ... end; is better then, when compared to your parameter example. I indeed don't like the where T is foo of Chrome :) So you are totally right, TGTypeT : TBaseType is a lot better and a lot more consistent (with e.g. function parameter syntaxis). Let's sum up the different points for the syntax so far: - will probably be used by Delphi - bites the operator No, as I said, we should allow template instantiation only in type blocks. type TMyType = boolean(ab)..(ab); :) - makes the parser more difficult and slow See above. - makes pascal more ambigious See above. - alternatives: modifiers or not yet used brackets like (! !) or (# #) Ugly :) Sure. But some people like emoticons. !) It seems to me, it's a question of: Follow Delphi generics or not. And we don't know, where Delphi will go. They will not have generics in the next one and a half year and as always: They will do a few things completely different than expected. If we follow, then we will do, as Florian et al said. If not, then the is not the best solution. Is this correct so far? Ok. So, FPC will follow chrome/Delphi? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Templates / Generics Syntax
On Fri, 04 Nov 2005 12:56:03 +0100 Thomas Schatzl [EMAIL PROTECTED] wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. No, already after the second token after the opening . It must either be a ,, or the closing bracket. .. or '.'. E.g. genericunit.type Assuming that you disallow something like generic_typegeneric_type2... Even that limitation can be overcome by disallowing directly nested generic use specification. Something like type TGeneric2 = generic_type2...; generic_typeTGeneric2 ... could be allowed however. I second that. We should try to avoid anonymous types (genericgenerictype). It's bad programming style. [...] From: Mattias Gaertner [EMAIL PROTECTED] On Thu, 3 Nov 2005 19:59:40 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Right. I didn't think of that. What about edged brackets? type TGenericClass[T,F] = class public procedure Add(Item: T; Flag: F); end; procedure TGenericClass.Add(Item: T; Flag: F); // Note: No redundant [T,F] after TGenericClass. begin end; type TListOfComponent = TGenericList[TComponent]; Analog: type TGenericListClass[T] = class of TGenericList[T]; type PGenericRecord[T] = ^TGenericRecord[T]; procedure GenericProc[T](Param: T); begin end; I think this has a similar problem to the other one. Consider this: my_procedure[... where my_procedure isn't an instantiation of a method using the generic but a function returing an array of something. You mean for example: function my_function: TList; where TList has a default indexed property. Ok, so (! !) would be better. But see other mails, about where Delphi goes. It seems they will use the syntax. Not completely sure whether this is a problem though... depends on the implementation. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Fri, 04 Nov 2005 10:47:42 +0100 Marc Weustink [EMAIL PROTECTED] wrote: Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. On the wiki pages some of my remarks got lost (or I didn't write them down) but when I first looked at the notation style it looks very unpascalish for me. I like more to add a new keyword for it, like the samples wiht generic or template) BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); What about proc generics: GenericProc(TObject) This can be ambigious. var MSC: TMySpecificClass; begin MSC := TMySpecificClass.Create Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Fri, 04 Nov 2005 08:38:03 +0100 [EMAIL PROTECTED] wrote: Alexey Barkovoy wrote: Delphi 11 .Net 2.0 will support Generics. Maybe Delphi 11 Win32. This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? Not Delphi 2006, but Delphi 2007 Thanks for the hint. Although the interesting question is: Will Delphi get generics this decade and how will they work? It seems, they want the same syntax as their C compilers and their .NET code. So, there is a good chance, that it will be the notation, which gives additional trouble for the parser. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Fri, 04 Nov 2005 13:44:55 +0100 Marc Weustink [EMAIL PROTECTED] wrote: Mattias Gaertner wrote: On Fri, 04 Nov 2005 10:47:42 +0100 Marc Weustink [EMAIL PROTECTED] wrote: Daniël Mantione wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. On the wiki pages some of my remarks got lost (or I didn't write them down) but when I first looked at the notation style it looks very unpascalish for me. I like more to add a new keyword for it, like the samples wiht generic or template) BTW, what woud be the problem with type TMySpecificClass = TGenericClass(TObject, Integer); What about proc generics: GenericProc(TObject) This can be ambigious. How would you have declared the proc, and how do you call it. I don't see a problem yet. GenericProc(TObject)(some params) you mean ? Example: procedure MyProc(T); // generic procedure without parameters ver i: T; begin ... end; procedure MyProc(T: TClass); // non generic procedure begin end; Call MyProc(TObject); What will happen? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Templates / Generics Syntax
Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; procedure TGenericClass.Add(Item: T; Flag: F); // Note: No redundant T,F after TGenericClass. begin end; I think, the parameters should be at the identifier name, not in the class block, because that's the way you use them: type TListOfComponent = TGenericListTComponent; Analog: type TGenericListClassT = class of TGenericListT; type PGenericRecordT = ^TGenericRecordT; procedure GenericProcT(Param: T); begin end; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Problems
There are some unsolved problems of generics in free pascal: 1. See wiki: http://www.freepascal.org/wiki/index.php/Generics#Notes The generic should not use private parts of a unit: interface generictype declar implementation procedure helper; begin end constructor generictype.create begin helper end end. IMO this can be allowed. But maybe it is a problem for the compiler? 2. Circle dependencies: unit a; interface generictypeA implementation uses B end. unit b; interface uses a implemenation begin generictypeAinteger.create end. Same: a problem for the compiler? 3. Name space. The unit, where the template is defined, has different uses clauses, than the unit, where the template is declared. In which order are the units searched? a) Ignore uses clause of template unit b) First uses clause of template unit, then uses clause of using unit. c) ? 4. Automatic generic parameters: var List: TGenericListinteger; begin List:=TGenericList.Create; // Note: ^ missing integer end; I'm against automatic generic parameters. I don't even like the generic declaration without a type name. I would only allow named types: type TListOfInteger = TGenericListinteger; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Thu, 3 Nov 2005 19:59:40 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. Right. I didn't think of that. What about edged brackets? type TGenericClass[T,F] = class public procedure Add(Item: T; Flag: F); end; procedure TGenericClass.Add(Item: T; Flag: F); // Note: No redundant [T,F] after TGenericClass. begin end; type TListOfComponent = TGenericList[TComponent]; Analog: type TGenericListClass[T] = class of TGenericList[T]; type PGenericRecord[T] = ^TGenericRecord[T]; procedure GenericProc[T](Param: T); begin end; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Thu, 3 Nov 2005 20:10:35 +0100 Mattias Gaertner [EMAIL PROTECTED] wrote: On Thu, 3 Nov 2005 19:59:40 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Here is a proposal of the syntax: type TGenericClassT,F = class public procedure Add(Item: T; Flag: F); end; This syntax is almost impossible to implement since in one of your other mails the symbols to mark the parameters appear in regular source code: begin generictypeAinteger.create end. It will be very hard for the parser to see the difference in advance between: variableinteger(another_var) generic_typeinteger Only when the symbol is parsed the result is known. Maybe the parser may be able lookup the type first and make a decision based on that, but it would be in the middle of a recursive expression parse designed for infix operators. Also in C++ this sometimes causes trouble where you need to change your code notation so the compiler eats it. I don't know if this proposal suffers from this mess, but we should avoid at all cost to import it into Pascal. Right. I didn't think of that. What about edged brackets? type TGenericClass[T,F] = class public procedure Add(Item: T; Flag: F); end; procedure TGenericClass.Add(Item: T; Flag: F); // Note: No redundant [T,F] after TGenericClass. begin end; type TListOfComponent = TGenericList[TComponent]; Analog: type TGenericListClass[T] = class of TGenericList[T]; type PGenericRecord[T] = ^TGenericRecord[T]; procedure GenericProc[T](Param: T); begin end; And a proposal for bounding: TGenericClass[T: TComponent] = class end; Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Thu, 3 Nov 2005 20:25:07 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Right. I didn't think of that. What about edged brackets? type TGenericClass[T,F] = class public procedure Add(Item: T; Flag: F); end; At first sight it looks okay. If necessary it is possible to introduce a two character bracket, i.e. (# #) or (! !), Hmm. Emoticons in Freepascal. Nice idea. (:T:) or with whatever character you want as long as it is not a prefix or postfix operator. Yes. As I said, I will implement it first in Lazarus, so we can see what it bites. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics Syntax
On Thu, 03 Nov 2005 22:35:34 +0100 Peter Vreman [EMAIL PROTECTED] wrote: At 20:41 3-11-2005, you wrote: On Thu, 3 Nov 2005 20:25:07 +0100 (CET) Daniël Mantione [EMAIL PROTECTED] wrote: Op Thu, 3 Nov 2005, schreef Mattias Gaertner: Right. I didn't think of that. What about edged brackets? type TGenericClass[T,F] = class public procedure Add(Item: T; Flag: F); end; At first sight it looks okay. If necessary it is possible to introduce a two character bracket, i.e. (# #) or (! !), Hmm. Emoticons in Freepascal. Nice idea. (:T:) or with whatever character you want as long as it is not a prefix or postfix operator. Yes. As I said, I will implement it first in Lazarus, so we can see what it bites. The syntax is the easy part. Yes. But the WIKI was not even finished on this part. How to parse the body of procedures of a generic type is the crucial part. The normal pascal parser can't be used because that requires knowledge of the types. The easiest way to implement generics are like macro's with parameters. Something like that I have in mind. My main goal is to reduce boring paste/copy/replace, not to moisten FPC. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Templates / Generics
On Fri, 04 Nov 2005 01:06:42 +0100 [EMAIL PROTECTED] wrote: Hi *, Delphi 11 .Net 2.0 will support Generics. Maybe Delphi 11 Win32. There is already proposal: http://qc.borland.com/wc/qcmain.aspx?d=11168 The FPC syntax must be at least a subset of the Borland syntax to be compatible. This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? Mattias Mattias Gaertner wrote: Hi all, I want to push generics to the next level. For those not familar, there is already a wiki about this topic: http://www.freepascal.org/wiki/index.php/Generics The page still contains a couple of different proposals, so I guess, the syntax is not yet defined. And there are still some unsolved problems, before we can start implementing it. My goal is to extend Lazarus first, so we can play with the new features, before extending the compiler, which is much more complicated. The syntax: The wiki contains a few proposals, but does not mention the advantages/disadvantages. So, here are some thoughts. Please comment and tell, where you see problems or a better solution. - Templates should work at least for: classes, classes of, interfaces, objects, records, pointers, procedures/functions. - Templates may also work for: procedure types - Template parameters can be any type. - Template parameters may be specialised (e.g. only) Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc.cfg format
On Mon, 22 Aug 2005 16:25:26 -0700 Robert Reimiller [EMAIL PROTECTED] wrote: On the off chance that the new ppcarm compiler and units I just built will work with a big endian ARM, I am trying to figure out how to actually build a test program. Is it possible to use the Lazarus IDE to edit and compile/assemble/link? Yes. We just need to add the new target and maybe add some paths, so that the IDE finds all arm sources in the fpc sources. At least that's what was needed to get sparc support. What's the OS, what's the processor? linux, arm? Where can I get the cross .ppu to test it? Mattias I changed the compiler path to the new compiler and made sure spurious command line options were off. I get a message indicating it can't run the assembler and is switching to external assembling. Someone else had this problem back in May and got the response The newer compilers requires an updated fpc.cfg and that the assembler is called e.g. arm-linux-as and arm-linux-ld. I haven't been able to find any documentation that shows the format of this new fpc.cfg and how you set the assembler and linker. Can anybody help? If Lazarus can't be used, how about Kdevelop? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gtk2 bugfix gfloat
On Wed, 15 Jun 2005 09:20:48 +0200
Micha Nelissen [EMAIL PROTECTED] wrote:
On Tue, 14 Jun 2005 23:33:17 +0200
Mattias Gaertner [EMAIL PROTECTED] wrote:
On Tue, 14 Jun 2005 22:34:19 +0200
Micha Nelissen [EMAIL PROTECTED] wrote:
On Tue, 14 Jun 2005 22:11:40 +0200
Mattias Gaertner [EMAIL PROTECTED] wrote:
A c float is a fpc single, right?
So why did you do:
- {$IFDEF KYLIX}
- gfloat = single; // Don't know why, but some routines requires
this - {$ELSE}
- gfloat = double;
- {$ENDIF}
+ gfloat = double;
If you weren't using KYLIX, nothing has changed :S, shouldn't that be:
+ gfloat = single;
?
You are right, I'm right, but my patch was insufficient.
Of course it must be single.
Marko Peric pointed me to a strange bug with some gtk2 examples translated
to pascal. After some debugging I saw, that with double it doesn't work, but
with single it works. According to the gtk2 sources and docs, gfloat must be
a c float. So definitely double is wrong and single works in my test cases.
I tested it with gtk2forpascal. But at the moment I have some trouble
building fpc and its rpms. Maybe the gfloat bug explains some of the strange
lazarus gtk2 interface bugs.
The reason, why this bug was not spotted before, is that the gtk2 always
bounds all gfloat input. This results in most cases to no effect, not even a
warning.
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] gtk2 bugfix gfloat
A c float is a fpc single, right? If yes, then there was a heavy bug in the gtk2 bindings. Attached patch fixes the gfloat. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] gtk2 bugfix gfloat
On Tue, 14 Jun 2005 22:34:19 +0200 Micha Nelissen [EMAIL PROTECTED] wrote: On Tue, 14 Jun 2005 22:11:40 +0200 Mattias Gaertner [EMAIL PROTECTED] wrote: A c float is a fpc single, right? Yes, AFAIK. If yes, then there was a heavy bug in the gtk2 bindings. Attached patch fixes the gfloat. There is no patch ? Take this. Mattias gtk2.patch Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] gtk2 gdk_draw_pixbuf
Here is a patch to add the missing gdk_draw_pixbuf function to the gtk2 bindings. Mattias gtk2.diff Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] out parameters in RTL/FCL
At the moment there are a lot of warnigns for uninitialised var parameters. Is it possible to replace the 'var' with 'out' specifiers? Can I send patches for that? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] cthreads OR adding a first unit
Problem: Some units require the cthreads unit, but only under linux and it must be added as first unit to the main source. Questions: Will the cthreads unit will be added as default someday under linux ? Or will it become obsolete by some other unit/feature? Or will it stay this way: If you need threads under linux, you need to add cthreads as first unit? Is it possible to compile a unit A, so that the need for cthreads is inherited to every unit using A? Some kind of extended -Fa flag with inheritage? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Modernising Pascal
On Wed, 23 Feb 2005 13:45:51 +0100 (CET) [EMAIL PROTECTED] (Marco van de Voort) wrote: one less variable to manually declare Implement something in lazarus that auto-adds the variable to the local var section. It already exists. Example: i:=0; Place cursor on i and press Code Completion (Ctrl+Shift+C) and it will add var i: integer;. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TShiftState as enum
On Thu, 17 Feb 2005 08:58:01 +0100 (CET) [EMAIL PROTECTED] (Marco van de Voort) wrote: TShiftState is defined as TShiftState = set of (...); How can I iterate through the enums? If not, can we split and add an enum: TShiftStateEnum = (...) TShiftState = set of TShiftStateEnum; ? Of course that is possible. It requires some imagination though (and a feel for obfuscated Pascal) The example fails in Delphi 6 btw, but works in FPC :-) Interesting :) But in this case: why not simply add one line to classes.pp? Delphi does not allow low/high on sets (I vote to keep this FPC extension btw) Yes. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TShiftState as enum
TShiftState is defined as TShiftState = set of (...); How can I iterate through the enums? If not, can we split and add an enum: TShiftStateEnum = (...) TShiftState = set of TShiftStateEnum; ? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Two classes.pp - why?
There are two classes.pp in the fpc sources for every OS. First question: Why? Second question: Are there any other double units? Third: Do I need to add a workaround in Lazarus to find the right one, or will one of them be removed soon anyway? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Portability Standards
On Mon, 3 Jan 2005 10:40:10 +0100 (Romance Standard Time) Michael Van Canneyt [EMAIL PROTECTED] wrote: On Mon, 3 Jan 2005, Marco van de Voort wrote: 2) File Restructuring I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS and UNIX sections, each containing complete procedures. These sections could be moved into dedicated OS specific include files - what's the preferred way? I (and FPC in general) prefer that. Jedi prefers to ifdef ad infinitum, they are (used to be is a better word) afraid of include files. The reason is very simple: They are all Delphi programmers, and the Delphi IDE has NO understanding of include files. Codetools don't work at all if you use include files. That said: $ifdefs confuse it as well... I guess you mean Code Insight (R) don't work at all .. . ;) Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList slowness in classes
On Fri, 24 Dec 2004 10:56:24 +0100 (W. Europe Standard Time)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
If the answer is yes, then maybe it's safe to compile parts of FPC
sources in lists.inc (like TList.Get) inside {$IMPLICITEXCEPTIONS OFF} ?
Why not put it into a sub proc:
function TList.Get(Index: Integer): Pointer;
procedure RaiseIndexError;
begin
Error(SListIndexError,Index);
end;
begin
If (Index0) or (Index=FCount) then
RaiseIndexError;
Result:=FList^[Index];
end;
?
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TList slowness in classes
On Fri, 24 Dec 2004 11:49:10 +0100 (W. Europe Standard Time)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
On Fri, 24 Dec 2004, Mattias Gaertner wrote:
On Fri, 24 Dec 2004 10:56:24 +0100 (W. Europe Standard Time)
Michael Van Canneyt [EMAIL PROTECTED] wrote:
If the answer is yes, then maybe it's safe to compile parts of FPC
sources in lists.inc (like TList.Get) inside {$IMPLICITEXCEPTIONS OFF} ?
Why not put it into a sub proc:
function TList.Get(Index: Integer): Pointer;
procedure RaiseIndexError;
begin
Error(SListIndexError,Index);
end;
begin
If (Index0) or (Index=FCount) then
RaiseIndexError;
Result:=FList^[Index];
end;
The compiler detects that the sub can raise an exception.
And creates the implicit exception frame only in RaiseIndexError.
Mattias
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Creating new classes at runtime
I don't know, if this is the right list, but the topic is quite fpc specific and needs some compiler gurus: The Lazarus IDE needs to create new classes at runtime. For example when loading/creating a descendent of TDataModule named TMyDataModule, it needs a unique TMyDataModule = class(TDataModule) complete with vmt, method table (empty), field table (empty), typeinfo (no properties), and .. ? At the moment lazarus only supports TDataModule and TForm, so I was able to just define the two and copy. But for inheriting I need 'real' custom classes. Creating the empty method table, field table and new typeinfo seems to be easy. But I found some fields, which I don't know: In objpash.inc there is const vmtInstanceSize = 0; vmtParent = sizeof(ptrint)*2; The fields behind vmtParent are easy (at least I think so). But what about the 8 bytes (i386) behind vmtInstanceSize and in front of vmtParent? They seem to be a negative number and a pointer? What are they are good for? And: Is this solution portable or will I get into trouble? Mattias ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Creating new classes at runtime
On Fri, 12 Nov 2004 22:32:48 +0100 (CET) [EMAIL PROTECTED] wrote: On Fri, 12 Nov 2004, Mattias Gaertner wrote: I don't know, if this is the right list, but the topic is quite fpc specific and needs some compiler gurus: The Lazarus IDE needs to create new classes at runtime. For example when loading/creating a descendent of TDataModule named TMyDataModule, it needs a unique TMyDataModule = class(TDataModule) complete with vmt, method table (empty), field table (empty), typeinfo (no properties), and .. ? At the moment lazarus only supports TDataModule and TForm, so I was able to just define the two and copy. But for inheriting I need 'real' custom classes. Creating the empty method table, field table and new typeinfo seems to be easy. But I found some fields, which I don't know: In objpash.inc there is const vmtInstanceSize = 0; vmtParent = sizeof(ptrint)*2; The fields behind vmtParent are easy (at least I think so). But what about the 8 bytes (i386) behind vmtInstanceSize and in front of vmtParent? They seem to be a negative number and a pointer? What are they are good for? And: Is this solution portable or will I get into trouble? What are you trying to do ? Well, that's a long story ... As soon as you have the class, you know everything there is to know or that you need to know. You don't need to have more than the TMyClass class pointer. Wow. That would be great. In the case of TMyDatamodule, you have the TMyDataModule class pointer, so You can create an instance and 'show' that on screen ? Where do I get this TMyDataModule class pointer? I also want TMyDataModule1, TMyOwnDataModule, TAnotherMyDataModule, ... . The classname should be different. And I want a TMyGrandChildDataModule = class(TAnotherMyDataModule) = class(TMyDataModule) = class(TDataModule). I only have a TDataModule class pointer. The rest should be created by the IDE just from class names. But maybe I think too complicated. Fact is, I have class names and I need class pointers. For forms you must only assume it is a descendant of TCustomForm. The Delphi IDE also can only handle things that descend from TCustomForm and TDatamodule. That's not sufficient. I want at least TComponent. When registering custom forms or datamodules in the IDE, you need to supply Delphi with the actual class pointer, and then it knows what to do... If you want I can show you code that registers custom forms in the Delphi IDE, I use it myself at work. Yes, please enlighten me. :) Mattias ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpcversion for rpm
The file install/fpc.spec still uses $version instead of $fpcversion when calling samplecfg (line 121). This creates unusable /etc/fpc.cfg. Can anyone fix this please. Mattias ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel]PowerPC, TypInfo
On Sun, 15 Aug 2004 00:20:47 +0200 Florian Klaempfl [EMAIL PROTECTED] wrote: Jonas Maebe wrote: On 14 aug 2004, at 21:07, Mattias Gaertner wrote: The GetOrdProp is used to read boolean values. It reads a longint and applies and $ff to get only the lowest byte. Under PowerPC the boolean value is stored just like under i386 in the first byte. Reading the longint under i386 works, but of course it does not under powerpc. So, either the compiler is wrong or the GetOrdValue function is wrong. Which one should I report? I just found out, that this is also the case for ShortInt, SmallInt, Word and Byte, but not for enums. To me, the fact that it always reads a longint regardless of the size of the property seems to be inherently wrong. What if the last field of a class is a byte? Then you can read past the end of the class, possibly into unallocated memory causing a crash, no? No. Classes are always allocated on the heap so the memory block is always at least a multiple of 4. The longint is read from the start of the SmallInt, so if the class is packed, its adress is not a multiple of 4. Or are all class variables 4 byte aligned? Mattias ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel]FPC Source Paths under darwin
Which system.pp is used for darwin/system.ppu? Mattias -- ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel]PowerPC, TypInfo
I found a bug in the RTTI under powerpc. Boolean properties stored in fields (e.g. properrty MyBoolean: boolean read FMyBoolean) always returns false. The GetOrdProp is used to read boolean values. It reads a longint and applies and $ff to get only the lowest byte. Under PowerPC the boolean value is stored just like under i386 in the first byte. Reading the longint under i386 works, but of course it does not under powerpc. So, either the compiler is wrong or the GetOrdValue function is wrong. Which one should I report? It's one of the last show stoppers for Lazarus under Mac OS X. Mattias -- ___ fpc-devel maillist - [EMAIL PROTECTED] http://lists.freepascal.org/mailman/listinfo/fpc-devel
