Re: [fpc-devel] Closures via interfaces
Paul, I think the OP meant the unit called 'rtti' in recent XE versions of Delphi. kind regards, Dimitri Smits - Oorspronkelijk e-mail - Van: Paul Ishenin i...@kmiac.ru Aan: FPC developers' list fpc-devel@lists.freepascal.org Verzonden: Maandag 27 mei 2013 02:30:40 Onderwerp: Re: [fpc-devel] Closures via interfaces 27.05.2013 5:52, Maciej Izak пишет: So I am waiting impatiently ^^. I think it's interesting time for FPC! To be completely happy, there is only one seriously lack - extended RTTI. :) RTTI has been extended recently: http://wiki.lazarus.freepascal.org/User_Changes_Trunk#RTTI_changes Please tell what exactly you are waiting for? Best regards, Paul Ishenin ___ 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] Re: Comparison FPC 2.6.2 - Kylix 3
Van: Vittorio Giovara vittorio.giov...@gmail.com On 04/mar/2013, at 16:57, luiz americo pereira camara luiz...@oi.com.br wrote: Personally, i don't care much about compilation speed since is faster enough (at least for me). I'm more interested in better generated code. This is were i'd like to see the efforts going. Sorry for the +1 style mail but I just wanted to say that completely agree with your statement! Compilation speed is nice, but better code (size/speed) is... better! as a bonus, when the code that is output performs faster, so will the compiler itself after the recursive build. or one would think so :-) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
- Oorspronkelijk e-mail - Van: Florian Klaempfl flor...@freepascal.org Aan: FPC developers' list fpc-devel@lists.freepascal.org Verzonden: Dinsdag 25 december 2012 14:15:24 Onderwerp: Re: [fpc-devel] Forwarded message about FPC status I see no way to speed up the 2.x FPC significantly only by stripping something down or whatever. The whole 2.x design is geared towards portability and maintainability, speed is only 2nd level goal (and being honest, self compilation in ~10 sec even on my 5 year old Core 2 Duo is not that bad ;)). I'm guessing that is NOT on a Windows platform? Every full build (it has been a while) I've ever done of the compiler on windows was at least a few minutes. what I *think* is a large hog on compilation/linking is the spawning of multiple executables in the different steps as opposed to the monolithic exe(+dll) that dcc32.exe is. The only approach I see to speed it up is to kick the whole back end and generate directly some close to i386 intermediate code directly in the parser. lovely, but isn't that what Embarcadero is doing for their future compiler? Using the llvm toolchain, they will provide a front compiler to an intermediate language or interpreted code. Then they have a few optimisations for the middle layer and use the back-ends that are already available to make stuff architecturally compile to whatever back-end (ARM v?, intel x86, powerpc, motorola 68k, jvm, dalvik, .net il, compiled php, ... or any community or custom backend) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Forwarded message about FPC status
As Sven wrote, I guess the FPC community needs to think about this. XE2 already supported MacOS X (but through fpc). Haven't checked the OS-X in XE3 though. As for the multi-platform: they are rewriting their compiler to be a front for llvm. Probably they will make a few code-generators and optimisations as well for the middle and back-end. But I doubt the bpl idiom was or will get ported past Windows variants (if it even gets done in the new compiler format). Don't forget that with FireMonkey^2, and a Firemonkey component model, they plan to tackle facade-type implementations to make Android/IOS an output target as well from the same code-base. As is today with the MacOSX target in XE2 and XE3, there are restrictions as to what you can use (i.e. must be firemonkey HD or 3D app if you want Mac or x-platform, meaning 2 platforms ... well, 3 if you count Win32 and Win64 as separate :-)) That said, what is stopping us (the community) to at least start on this? a branch? core-buy-in? kind regards, Dimitri Smits - Oorspronkelijk e-mail - Van: Hans-Peter Diettrich drdiettri...@aol.com Aan: FPC developers' list fpc-devel@lists.freepascal.org Verzonden: Maandag 17 december 2012 16:20:39 Onderwerp: Re: [fpc-devel] Forwarded message about FPC status Sven Barth schrieb: Am 17.12.2012 14:06, schrieb Hans-Peter Diettrich: Sven Barth schrieb: still no Delphi-like packages... They are planned long term, but they are no cheesecake feature. We need to implement them in a way so that at least the major platforms (Windows, Linux, Mac OS X) can make use of it and already the difference regarding procedure name resolution between Windows and Unix can cause headaches... We should wait for and explore how the multi-target Delphi handles that. No. We need to think about this ourselves as we support more targets than Delphi ever will support. Nonetheless it would be wise to wait for an Embarcadero solution. They might invent a new cross-platform model for their packages, in which case we ended up in yet another package model. DoDi ___ 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] Re: Faster Implementation for IntToStr
- Oorspronkelijk e-mail - Van: Graeme Geldenhuys gra...@geldenhuys.co.uk Aan: fpc-devel@lists.freepascal.org Verzonden: Maandag 3 september 2012 12:42:11 Onderwerp: Re: [fpc-devel] Re: Faster Implementation for IntToStr On 03/09/12 10:19, Daniël Mantione wrote: Certainly, but the code used in that asm implementation is quite out of reach for compilers. Certainly, but there is always scope for improvements right? eg: Delphi is well know for generating more optimised ASM than FPC. I'm by no means saying that it is easy, I'm just saying that in the long run it is easier to maintain Object Pascal code [in the case of IntToStr and similar functions], than ASM code. Not to forget the fact that such Object Pascal implementations are much more portable. true, but... Delphi uses some hand-coded asm optimisation as well. There are pure pascal implementations to functions in the RTL as well as x86 and 64bit implementations. That is for the RTL. As for the compiler itself, I've heard it was written in C(++), so usually a better fit to asm. :-) Let's not forget by the way that a lot of much-used functionality was rewritten in asm in the fastcode project, later included by CodeGear and Delphi-compiled programs went faster from those versions on (methinks Delphi 2007). On the other hand, the hand-optimised ASM code may have been fast(est) in that era, but with each new processor, other ways/opcodes/sequences may be faster. Anybody remember introduction of U/V pipes, L1 cache optimisation of data-access or even code-access (jmps etc), general stalling when using registers for O then I within x instructions... ? A compiler can choose to optimise those type of things in a more generic way, whereas when you have it in ASM, it is set in stone: that way and no compiler-optimisation. Either way, both have their uses and use cases. I've even seen implementations of much used functionality where on startup (x86 and Delphi), a cpuid query is done and according to certain compatibilities a set of functionality is registered. Then they used wrapper inline functions that used the underlying record-of-function-pointers. All they needed to do then is optimise for certain combinations of cpuid flags and architectures to make it as fast as it gets on every PC of that architecture. Needless to say it was not as maintainable as pascal versions, but they did get a speed-increase (even over Delphi compiler) on the time-critical and heavily used functionality, even with the indirect call in place. kind regards, Dimitri Smits___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: Faster Implementation for IntToStr
- Oorspronkelijk e-mail - Van: Graeme Geldenhuys gra...@geldenhuys.co.uk Aan: fpc-devel@lists.freepascal.org Verzonden: Maandag 3 september 2012 16:06:14 Onderwerp: Re: [fpc-devel] Re: Faster Implementation for IntToStr On 03/09/12 14:05, Mark Morgan Lloyd wrote: Except that modifying the compiler to generate highly-optimised code for specific high-level tasks is probably more work than having a fragment of assembler that needs to be written once per target CPU. And writing the assembler for that one task fixes ONE problem, but still needs to be rewritten for all other target CPU's. Improving the assembler generated by FPC improves many tasks at once. wouldn't the different target CPU's have their own optimisations then, so in effect you still have as much tasks as a per cpu implementation? granted, it could be useful and speedup other code on the go as well, but like you said: optimisation is a difficult problem. There is not always a one-size-fits-all, and it usually is a compromise leaning towards generability of applicability or pure speed. kind regards, Dimitri Smits___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode support (yet again)
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: On 16/09/2011 00:01, Dimitri Smits wrote: errrm, utf-8 can have 6 octets representing one character, Last time I checked, that was only in the very early stages of developing the utf-8 specification. Since then, the maximums size of a utf-8 code point is 4 bytes. If you know otherwise, please post a URL. Here is the information I have: The original specification allowed for sequences of up to six bytes, covering numbers up to 31 bits (the original limit of the Universal Character Set). In November 2003 UTF-8 was restricted by RFC 3629 to four bytes covering only the range U+ to U+10, in order to match the constraints of the UTF-16 character encoding. http://en.wikipedia.org/wiki/UTF-8#History good to know. I've learned about unicode/utf8 from the following links http://www.joelonsoftware.com/articles/Unicode.html http://www.cl.cam.ac.uk/~mgk25/unicode.html never bothered to look into the rfc's and/or official unicode site(s). when I follow the link to the rfc you mentioned in the second link above, I indeed see that it is 4 octets according to the rfc. However, when I follow the link to the unicode appendix (http://www.cl.cam.ac.uk/~mgk25/ucs/ISO-10646-UTF-8.html), mentioned in that second page (anchored link: http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8), I see that according to the iso spec, it still is (was?) 6. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode support (yet again)
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: On 15 September 2011 19:09, Hans-Peter Diettrich wrote: What data type would you use, to store an UTF-8 character? And how to access the n-th character in an UTF-8 string? I already showed how in a previous post. For more details on how fpGUI does this, have a look at the fpg_base.pas and fpg_stringutils.pas units in the fpGUI repository. TfpgChar= type string[4]; The maximum size any UTF-8 code point can be. Basically a character is treated just like a string - only a small string. errrm, utf-8 can have 6 octets representing one character, not forgetting those dioretics that are separate characters. (so I doubt representing it as above is so correct, with a short(ansi)string) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unicode support (yet again)
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: Why? We simply hired average people (not programmers) to translate your English resource strings into German, Portuguese, French etc.. No other modifications where required. No code or programs had to be recompiled. Our resource strings are stored in external .po file that ship with our application. Graeme, while I concur with your first part as a way to go, it is maybe not-so-average people (linguists/interpreters), but other than that I agree. Although there is a whole lot more involved with multilingual apps than that in my experience. Sometimes a form is to be redesigned slightly/heavily due to real-estate and constraints (either by system like screen resolution; or directly on demand by the client). That is why I never really grasped the whole .po stuff as in my experience that is not always enough. but I digress... kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: the debugger to limit what I am allowed to do. eg: Delphi allows it without *anybody* complaining!. You are a programmer, you should know what you are doing. If you didn't want the getter method to execute, then you should have debugged the field variable instead. Yes, and maybe for those developers that like to have there hands held while debugging, there should be some option to same don't execute getters. when you add a watch in Delphi (7) on a property, you have to allow explicitly (checkbox) calling functions. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] bounty: FPC based debugger
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: On 12/09/2011 13:30, Martin Schreiber wrote: ??? EUR 100'000..200'000? Really? Yes, we all know your rates a much higher than others - so we will not ask you to do the work. Graeme, I think you underestimate the work required when doing it from scratch (or from Duby, which, from what I can see hasn't released anything to tinker with yet on their sf.net page). That said, even when I think of the entry-level programming fee (no freelance/consultant) a professional developer gets a month in my country (Belgium), and divided by 20 to get a daily fee from it, it still is 125 euro before taxes etc (after which you have about 3/5 left). When you take into account the black market or undeclared sidejob as opposed to hobby, that could go down to 50 or so. But still, it would take quite some more effort than a few 1000 euro's in manhours, especially for those programmers with experience (whom have a higher cost ofcourse). I don't disagree with the need for a prime debugger, nor with the amounts of bounty everyone is offering, just with the statements above. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] delphi 2010/XE/XE2 - like rtti and packages
Hi, A few times the latest weeks, I noticed on this list (and the Lazarus list(s)) a need for the Delphi rtti extra's and the Delphi meaning of packages (program/library/*package*/unit). I am willing to reboot what I started and give it another shot with rtti. Both are at least partly intertwined, so I might need some help of you all with a system more exotic than a Wintel machine ;-) First off: * Delphi's RTTI starts from package/unit/type tree that is registered on startup/loadup of a binary with the RTL. Be it executable or dynlib. = what units/objects/classes/... in the fpc compiler would I need to alter to allow the following additions on windows, but eventually all platforms: - a smartlinkable section per module (=executable/dynlib) for the package info (preferably, here the init/finit block may be expanded/replaced with a link to the unitblock) - a smartlinkable section per unit for the typeinfo for when used in a package module - a smartlinkable section per unit for the typeinfo for when used in a program or library module I know that I might/would need to alter some types in respective typinfo/sysutils to accomodate in the rtl, but I would first like to know how to generate them in the output. :-) optimally, one wouldn't need 2 different versions of the unit-typeinfo, but I was thinking that in package we take all the types, in one section. And in the other for program/library, we would allow smartlinking to take out subsections that are not needed. So, any help/redirection to documentation or units is greatly appreciated (as well for the section and what can be done with them). once I get a tree-hierarchy of module/package-units-typeinfos working, I intend to go on with the RTTI unit implementation and subsequent questions on that topic. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] delphi 2010/XE/XE2 - like rtti and packages
- Sven Barth pascaldra...@googlemail.com schreef: Am 11.08.2011 16:38, schrieb Dimitri Smits: once I get a tree-hierarchy of module/package-units-typeinfos working, I intend to go on with the RTTI unit implementation and subsequent questions on that topic. Please note that for a fully compatible implementation of the RTTI unit you'll need generic methods (and maybe a working Create for records, don't remember that...). I plan to work on these once I've finished implementing the Delphi compatible generic syntax in my branch. Regards, Sven that's why I wrote the first off. generics are for somewhat further down the road. First implementation of the rtti unit would omit/replace the TArrayT dynamic arrays. (as well as TCustomAttribute and the newer TVirtualMethodInterceptor and Aspect-Oriented-stuff) first phase for me would be: can I get a set/linked-list of loaded package(s)/module(s) and from there the units in them, and from them the PInfoType data in them. And for that there is a need for what I asked first. Sven, just out of curiosity: is there a rough ETA for the Delphi compatible generic syntax finalization in trunk? kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
Makes you wonder, will they start submitting patches for FPC too? that was what I was wondering about as well. Why not participate in fpc/lazarus development and add the missing features (packages etc; some language features) or update the D7-isms to XE standards instead of doing it themselves? In exchange they would get the benefit of the x-platform bit. and when they are at it, they could then deploy their own additional packages/components/libraries/helpfiles with their packaged product. fpc might then even benefit from their x86 speedup knowledge and we could get rid of the comments delphi compiler is x times faster than fpc that pop up every once in a while. :-) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: Florian, has anybody from Embarcadero approached you on this? I wonder if they know that any modifications they make to the FPC compiler must be made available as open-source? The compiler is GPL'ed after all. contrary to popular belief, it is not so that if you GPL something, everyone gets your source (ie: the community; by way of give back). If you take a open source project ((L)GPL that is, not talking about MPL/MIT/BSD/...), and you modify it, then sell it, the licence does not require you to give away the source to everyone! Only to your customers(/competitors) who bought the program! Likewise, when you take such a project with such a licence, maybe even straight GPL, and modify it, but only use it in-house, then you owe nobody anything. (since the source is handed over to the client, ie: yourself) btw, I even believe that you can devise a licence that is GPL compatible (copyleft), but that disallows redistribution/resell. Like a bit of an NDA. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RFC: Delphi style class helpers
- Jonas Maebe jonas.ma...@elis.ugent.be schreef: On 21 Dec 2010, at 00:16, Jonas Maebe wrote: On 20 Dec 2010, at 21:37, Sven Barth wrote: - should abstract methods be forbidden? Yes, since a) they are virtual b) even if it were possible to have virtual methods, there would be no way to override them with implementations that do something (since you cannot inherit from a class helper) Actually, it seems that inheritance is in fact allowed for Delphi-style class helpers: http://qc.embarcadero.com/wc/qcmain.aspx?d=76577 (it's not for Objective-C categories). But I'm still quite sure you cannot do anything that requires changes to the VMT of the helped class. There are also at some extra checks that must be added for constructors/destructors introduced via class helpers (Objective-C/Pascal doesn't have constructors or destructors, so it doesn't matter there): * http://docwiki.embarcadero.com/RADStudio/en/E2295_A_class_helper_cannot_introduce_a_destructor_(Delphi) * http://docwiki.embarcadero.com/RADStudio/en/E2296_A_constructor_introduced_in_a_class_helper_must_call_the_parameterless_constructor_of_the_helped_class_as_the_first_statement_(Delphi) * http://docwiki.embarcadero.com/RADStudio/en/E2358_Class_constructors_not_allowed_in_class_helpers_(Delphi) hi, it seems that the virtual methods can be overridden (AOP style) using the TVirtualMethodInterceptor that comes with Delphi XE. It can also be on a per instance base (as opposed to on a per type) if I've read up on it correctly. I'd say that would be a better candidate for that purpose/intent/use case. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Component FTag and Tag should be int64
- michael vancanneyt michael.vancann...@wisa.be schreef: On Mon, 22 Nov 2010, Andrew Brunner wrote: I was looking at the code for Tag property in classes unit and noticed I can't safely use Tag to keep runtime pointers (at least on a 64 bit compile). What is the likelihood of getting tags changed to support universal access under 64/32 bit compiles? What is the logic behind the shortfall? I suspect just legacy and it could be easily fixed. ___ The logic is that it is bad programming to use an integer to store a pointer. And we don't want to encourage bad programming. Yes, I know it's easy, and yes I know it's common practice. Neither make it right to do so. +64 Never EVER fall into the VB bullshit trap that is the Tag property. Related to that matter, Windows/delphi has a few of these Data pointers, especially the stuff that is lower-level and is used to invoke the winapi with as a parameter (callbacks anyone?). Always try to stay clear of it as much as possible, because it does encourage and even invite bad programming. We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - forces us to follow suit. sad to read this part though... kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Interface scope incompatibility with Delphi
ok, answering my own mail after a small test below
- Dimitri Smits smi...@telenet.be schreef:
what I DON'T do is use it like in your example, Graeme. I always
assign the result to a local variable, which goes out of scope in an
implicit finally block at method-exit. Haven't tried if this does
(not) work in fpc though.
tested with following program and 2.4.0 (can someone verify on trunk)
it gives somewhat the desired result, but not completely. This IS a bug, I
believe.
the expected behaviour is the next output:
Entering: DoSomething 1
Entering: DoSomething 2
random message 1
random message 2
Exiting: DoSomething 2
Exiting: DoSomething 1
but I got this output:
Entering: DoSomething 1
Entering: DoSomething 2
random message 1
random message 2
Exiting: DoSomething 1
Exiting: DoSomething 2
it seems that the stackvariables are NOT unloaded in the correct order (ie:
reverse order of declaration).
It shouldn't matter in what order you fill them, but in the order they are
declared. (like good practice in constructor vs destructor, but then in stack
variables setup/cleanup)
---8---8---8---8---8---
program project1;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes,
SysUtils
{ you can add units after this };
{$R *.res}
type
{ TWriteLog }
TWriteLog=class(TInterfacedObject)
private
FLogMessage: String;
public
constructor Create(str:string); overload;
destructor Destroy; override;
end;
{ TWriteLog }
constructor TWriteLog.Create(str: string);
begin
inherited Create;
FLogMessage := str;
writeln(Format('Entering: %s', [ FLogMessage ]));
end;
destructor TWriteLog.Destroy;
begin
writeln(Format('Exiting: %s', [ FLogMessage ]));
inherited Destroy;
end;
procedure DoSomething;
var logMsg1, logMsg2: IInterface;
begin
logMsg1 := TWriteLog.Create('DoSomething 1');
logMsg2 := TWriteLog.Create('DoSomething 2');
writeln('random message 1');
writeln('random message 2');
end;
begin
DoSomething;
readln;
end.
---8---8---8---8---8---
mind you, you could explicitly nillify one of the logMsg variables to force
order as well.
Usually this is being used by our company for things like Screen.Cursor
replacements and making sure that any unforseen errors in additional
call(stacks) are handled without cluttering everything up with additional
try/finally blocks.
other stuff we used this trick for includes 'DataSet.DisableControls',
profiling/timing and transactionmanagment to name a few.
oh, and by the way: I get 2 warnings that the logMsg variables are assigned but
not being used. This is too strict for tag-interfaces, as they actually are
used due to assignment and ref-counting.
should I file (2/a) bug report(s)? or is there no point in doing so since they
won't be fixed either?
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Interface scope incompatibility with Delphi
- Thomas Schatzl tom_at_w...@gmx.at schreef: Hi, On Fri, 12 Nov 2010 00:46:43 +0100 (CET), Dimitri Smits smi...@telenet.be wrote: it seems that the stackvariables are NOT unloaded in the correct order (ie: reverse order of declaration). It shouldn't matter in what order you fill them, but in the order they are declared. (like good practice in constructor vs destructor, but then in stack variables setup/cleanup) Imho the compiler should generally be free to reorder/remove/reuse/add temporary variables on the stack as it sees fit. What you experience is only an artifact of the current implementation. Making assumptions about exact stack layout (in particular of local variables) beyond what is specified by the calling convention is generally not a good idea. [snip] Imo: Jonas already stated, the time of the release for interfaces is not guaranteed - afaik the docs/specs only state that they will be released if the reference count gets zero (I have not read the docs for the exact wording). I was looking in the online docs for a mention of this behaviour regarding managed types and stack unwinding. cannot find it. anyway, I never mix dependent variables like that in the same method, so it would not matter a lot to me. Was just stating that this is how delphi does it and that some code may depend on it. tagging interfaces and their use in local variables are supposed to be in scope until exit of procedure (be it by reaching 'end;', explicit exit or exception). Then they are to be nilled (and _release'd), which may result in refcount=0 = Free. So what if the runtime system internally keeps a reference for en masse garbage collection using a background thread? (I.e. the refcount starting at one. This is a totally valid use case for interfaces, and which btw, also makes the stack ordering issue a moot point too. Or, this interface memory management may be implemented using tracing garbage collection in some future target (LLVM, JVM, CLR, ...) the same way. What most of you do not understand is that you CAN override the AddRef and Release methods to NOT do ref_counted free's. Also, Interface use automatic garbage collection, not even when you use a refcounted-with-free-on-0 interface. COM interfaces are semi-unmanaged objects either way. (interface vars are managed, but the implementations have explicitly coded provisions for assistence) The argument for an external garbage collector can be made for object-references, not for interfaces (although variables of interface type can be the reason why an instance of the implementation is not garbage collected) that some people use it as autoptr implementations does not mean that interface-use = garbage-collector. What would be interesting would be how garbage-collected Delphis handle this, can anyone help? Other than that, there is imo nothing else to say than that Pascal/Delphi(*) does not have explicitly scoped lifetimes with automatic destructor call for classes/objects at the moment. argument is moot. .Net has provisions for object-instance assignment and internal ref-counting in the CLI and/or VM/interpreter. Java the same with its bytecode jvm. (*) maybe newer Delphis have the C# using keyword or something similar (maybe with recycling?). I would be interested to hear about that. newer delphi's .net = both are different beasts entirely. win32 is NOT garbage collected. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Interface scope incompatibility with Delphi
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: Hi, Attached is a simple console application that outputs a hierarchy of log information. Under Delphi 7 we used to use a TInterfacedObject descendant to track the call stack. This same trick was very handy for changing and restoring the mouse cursor too. I still use that trick daily in Delphi: the cursor handling stuff, that is. It makes it possible to keep the code readable without cluttering it with extra (explicit) try/finally and try/except blocks. what I DON'T do is use it like in your example, Graeme. I always assign the result to a local variable, which goes out of scope in an implicit finally block at method-exit. Haven't tried if this does (not) work in fpc though. as for the codesite stuff, there is an open source ( free as in beer) variant for that as well with a Delphi interface. Maybe it can be made portable as well to fpc and x-platform. http://tracetool.sourceforge.net/ kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] AnsiString in DWARF2 vs DWARF3
I'm just getting sick of the sad state that FPC debugging (with our only choice GDB) is in. It's near unusable and currently only good for stepping through code. So I'll take the cue and see if I can do something about it. +1 although it must be said that is mainly for lazarus. The fpc-ide debugger for instance is the only way to get assembler-viewing+stepping to work. (to some extend) at least on win32 kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] win debugging in gdb
was Re: [fpc-devel] AnsiString in DWARF2 vs DWARF3 - Anton Kavalenka anto...@tut.by schreef: На 26.10.2010 13:33, Felipe Monteiro de Carvalho напісаў(ла): On Tue, Oct 26, 2010 at 12:08 PM, Anton Kavalenka anto...@tut.by wrote: I know at least two developers who stand - the only thing preventing them of using FPC is GDB. Windows-only developers? Or else I don't know another compiler which will offer better debugging in the rest of the platforms. Yes, windows only. But they fully understand bonuses from FPC and Lazarus but really hate GDB. Their last argument - we need assembly-line stepping debugger like in Delphi. I count myself in that category as well. Assembler stepping is maybe not for everyone, but if you want some fine grained control, you sometimes need to delve deeper into the internals. This is especially so with compiler-code or RTL speedups. I've been trying to see if I could write a better/faster FillChar last weekend. My asm was a bit rusty (and I definately have some learning curve to go through with gasm ATT syntax), so I wanted to test something out looking at registers. For that (and the include-file mess in RTL that needs some getting used to), I needed to see the compiled version of a regular FPC FillChar for Win32. I suspected it to be in i386.inc, but wasn't sure. In lazarus = complete fail. lots of tries to get debuginfo/mapfiles generated. Nothing usefull came out for use in a debugger. I didn't try the build with asm files of the RTL, as I inherently evolved past makefiles years ago (Delphi/ant/want/VisualStudio build systems are more in my current skillset). tried a disassembler like PE Explorer (trial) = no exported methods, so I got a somewhat 'guess where everything is' -asm. fpc-ide on vista = no fullscreen support, so practically unusable in too high res, but finally managed to asm-step and confirm. While I get that gdb is a powerfull debugger (and cross-architecture/platform), it too has a steep learning curve. So, aside from the build-system, most of the complaints I have about missing features are not inherent to fpc, but more to the tools around it (like lazarus with it's subpar debugging compared to D7). I guess it's time to put my code where my mouth is, but some of the issues above make it nearly a catch 22. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] faster FillChar for IA32/IA64?
Hi, I was wondering why on several occasions in discussions regarding compiler design and parser branches it was mentioned (especially by Florian) that FPC is in need of a faster FillChar. The reason for this bewonderment is that I see code regarding the fastmove that is by John O'Harrow of fastcode fame in the i386 dir. Was this donated by him, or was it an adaptation of the fastcode code with another licence slapped onto it? If so, why not contact him for his fillchar routine (or do the same as with the fastmove) that was entered in the fastcode contest for a fillchar method? http://fastcode.sourceforge.net/ ps: the current fillchar implementation has 2 caveats and one heavy instruction * misaligned buffers are not handled, resulting in misaligned 32bit memory-writes and possibly penalty's. Donno if this can happen, but still. (shortstring initialisation?) * the check for count = 0 can be done sooner * the imul is not as expensive as before, but still is heavy. Especially when the fillchar is 0, this is heavy and can better be replaced by a xor %eax,%eax or maybe even better if the value is always extended to 32bit/64bit in this special case. As I understand its mostly used use case is for zero'ing memory when used in compiler/runtime memory initialization/finalization, it might bring a small upgrade in speed (more so if it is for lots of small memory-block zero'ing). kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Alternative parsers
- Michael Schnell mschn...@lumino.de schreef: On 10/20/2010 02:04 AM, Hans-Peter Diettrich wrote: I would like to see my C parser working as an FPC front-end, I feel that there in fact is a decent cause for doing a C(++) front-end for the FPC compiler: importing existing C++ code into a Pascal project. I suppose this is not possible completely without modifying the C++ code this will not be possible in many cases (please don't start discussing multiple inheritance ;-) ), but this would be a lot better than the current situation where linking FPC and C++ is completely impossible due to the different ABI. and let's not forget the other argument Delphi does it too :-) just kidding, different compiler is invoked as for the linking of C++/FPC: good argument, but then your fpc-compiled c++ will be incompatible with everything else. Come to think of it, no 2 C++ compilers mangle the same due to VMT and other abi-stuff anyway. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
- Marco van de Voort mar...@stack.nl schreef: In our previous episode, Willibald Krenn said: I don't like the Delph all-or-nothing philosophy here. I'd prefer to specify the packages, that shall be loaded at runtime, while all other You can always load packages at runtime.. That is, after the RTL supports that of course. Runtime loading of loading is quite a different process from startup loading, and only used for plugin system (where the baseclass is statically linked, and the plugins implement the baseclasses). Dynamic loading for enormous amounts of symbols might be costly (since they are resolved with a call per symbol, instead of by one call to the system, as during startup). only the symbols that are used are imported in the dyn-loaded package. And it exports all publicly available types/procs/consts/vars. The KDE suites startup speed problems have shown that very complicated dynloading schemes are not desirable. The RTL is always loaded on startup btw. to say even more, when you run with runtime packages, it's units are initialized first (before any other units/bpl's/the main exe). packages can be linked into the executable. This would allow to use an minimal set of external modules, which are shared by the exe and the really self-contained packages. What you probably(?) could do is to link all basic packages into the executable but still export all symbols, so that when the shared object is loaded it finds all necessary entry points. Problem is that that leads to a dependancy circle (pkg-exe-pkg). Maybe not a blocker problem, but more a complication. when you use packages, it requires some discipline, that is right. Consider following scenario: pkg1: your plugin-base classes, requires RTL package exe: imports pkg1 as a runtime package requirement, statically binds the gui components in lcl/vcl since it was not defined as a runtime package link requirement pkg2: a plugin for runtime loading, requires RTL package and VCL/LCL package what would be result when you want to import this at runtime through a loadlibrary call? I would suspect that you then have duplicate units-error. Compiler cannot defend against it due to the runtime information vs compile-time information. Just to show that packages bring their own set of problems and pitfalls. But definately not all is bad ;-) However, at the moment I don't see why this is better than shipping all necessary ppl files. BTW: I realize that ppl might be a bad TLA - since it probably means people for quite a number of ppl ;-) Nah. Just wonder if that is necessary, if Delphi .bpl's are not compatible too eachother anyway. that is why versionnrs are included: RTL70.BPL (Delphi 7) vs RTL150.BPL (Delphi XE aka 2011) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
- Hans-Peter Diettrich drdiettri...@aol.com schreef: Dimitri Smits schrieb: It is therefore simple to say in delphi that you want to build with rtlXXX.bpl only, but still have the vclXXX.dcp statically linked into your executable when you use a TForm and include the Forms unit somewhere in your code. This sounds like a post-D7 feature? nope, D7 does this too. (maybe even D5, but cannot verify) if you say you want to build with runtime packages x, y and z, the linker/compiler take into account that you implicitly dynamically link to the (units contained in) the packages that package x,y and z depend on (and recusively until no additional dependencies remain). if in none of the above x,y,z (and the bpl's they depend upon) is contained a unit you use in your current build-target (exe, dll, ...), then the unit is implicitly included into that build-target. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
- Hans-Peter Diettrich drdiettri...@aol.com schreef: Willibald Krenn schrieb: Here comes my 'official' plan on how I want to implement Delphi-like Package Support for FPC on Win64. Feel free to comment. [...] -K File[ File]* Command line arg to tell fpc to compile program/dll with runtime package support. I don't like the Delph all-or-nothing philosophy here. I'd prefer to specify the packages, that shall be loaded at runtime, while all other packages can be linked into the executable. This would allow to use an minimal set of external modules, which are shared by the exe and the really self-contained packages. The same effect could be achieved by a separation of packages into (Lazarus-type) static libraries, and packages *designed* for dynamic loading (plug-ins...). Delphi compiler does this as well. One caveat in this discussion is for instance: when you build with runtime packages vclXXX.bpl, db*.bpl; even though you didn't specify them, all packages your bpls depend on are loaded runtime only as well. (rtlXXX.bpl for instance) the reason is simply: there can only be one instance loaded of EVERY unit you use in your program (or that is included in some bpl). It is therefore simple to say in delphi that you want to build with rtlXXX.bpl only, but still have the vclXXX.dcp statically linked into your executable when you use a TForm and include the Forms unit somewhere in your code. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi-like Packages, Plan
- Willibald Krenn willibald.kr...@gmx.at schreef: Willibald can get access to a branch to commit his work. Also an idea. But you might outline some rules for commits so that not the same problems happen as with DoDi's branches. A branch would be nice, I guess. So everyone had a chance to see what I am doing. Just to be clear about my intensions: I don't want to change existing code. Only if there is no other way I will introduce changes, but these will be minimized as much as possible. maybe others want to contribute too. Will this be a Willibald-only branch? [OT] one showstopper (besides loads of time) I have is getting the fpc-trunc to compile and create a specific bin folder. as far as I've gathered is that you need to do a make clean all and then copy all the resulting exe's to somewhere (find and retrieve yourself strategy). But all those configuration files etc that you get with a binary release download are a mystery to get right. [/OT] if I got this to work, then I'd be happy to volunteer some time on that branch as well. dcp can also contain implementation part of .dcu which is .o in FPC. Yes, they probably do. For the beginning (and with generics in mind) it's probably easier if they do. don't forget inline as well, not just generics. Regarding M1 If you want this TPackageModule or whatever in system.pp (e.g in the RTL, not in the compiler) you should use records, because objpas.pp is not loaded inside system.pp (and thus TObject isn't available). Good to know. Actually I hope I can hide the package-thing from the RTL, which probably is a bit unrealistic ;-). Well, at least for M1 I'll concentrate more on compiler internals than RTL aspects. you'd have a bit more dependency-hell when you want to make your LoadPackage/UnloadPackage methods and need to either re-implement the dynamic-lib loading or use the standard x-platform one. also: TPackagemodule should indeed better be a record (maybe have a look at versions beyond D7, to TLibModule for instance) Which reminds me: ALL your build-targets should register their contents through packagemodule and consorts. That means the main exe or shared-lib as well. Otherwise it is impossible to detect duplicate units and double-initialisation and other troubles with the runtime linking. A tree-structure emerges in the newer delphi's: Module - unit - types A module contains x units A unit contains y types careful for smartlinking those structures. Regarding M2 What do you want to mangle here? [RTTI] RTTI for types needs to be exported, so it needs to have a name. I don't know yet whether there already is one. I think you mean replacing RTTI_ with @xp@ or something you are more familiar with for starters? RTTI is already provided. Try building with retaining assembler output to see what I mean. Some link-names are indeed easily becoming too long, others would think the all uppercase is unneccecary. I'd say they are there, they work and were the personal taste of the core-team biased to it through experience and other arguments. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
- Sven Barth pascaldra...@googlemail.com schreef: Am 13.09.2010 14:46, schrieb Dimitri Smits: as said before, inspiration can be had from how they do it, but that doesn't mean fpc should do it that way. Especially in a crossplatform context, and more so cross-architecture, it is not a one-size fits all per se. Basically the package system needs the following: - The ability to import/export functions, procedures AND variables from binaries (although export from shared library only should be sufficient). This works on Windows, but on Linux I had problems. - The ability to declare init and finit procedures for shared images. This works on Windows with the entry point and on Linux with special symbols. I don't know about the other platforms. - The ability to add the init/finit entries (which call the unit initialization/finalization sections) uniquely to the shared RTL and execute them. This is of yet a todo as it means a bit of work in the RTL. The first two points must be provided by the platform/OS while the third one is defined by us (at best as the same for all platforms). What would you do different/better then the Delphi developers when implementing such a package system in a crossplatform way? I can't imagine currently what should be done additonally, but that might be because I don't use every feature that FPC provides. So please share your ideas. :) a few cleanups and improvements I'd sneak in are due to the fact that Delphi comes as a whole: VCL and compiler are distributed. Building for a version is building that version. FPC and it's close companion Lazarus are not like that. Compiler is released a few times a year (?), IDE and visual componentset are separate. There is not really a maximum requirement for what compiler you use to build the IDE and components. There is sometimes a minimum version requirement. DLL-hell is bigger, I know. However, take for instance LCL 1.0. (LCL-win32-1.0_fpc2.4.fpl ?) The requires could take just LCL-win32-1.0 as package name and rtl. Another thing I'd place inside the packageinfo is the compiler with which the package was build (for runtime checking). I do not believe that a version like 2.4.2 should contain other EABI/RTTI or even as worse: other interfaces. They are bugfixes (?). So 2.4.0 can work with 2.4.2 packages. Also, some packageinfo+unittableentry stuff is less than optimal in alignment with the shortstrings iso pchar? Something I've found bizarre with Delphi 7 RTTI in typeinfo as well. Every unit has a local tunitinfo block generated: tunitinfo=record ... unitname: shortstring; end; punitinfo=^tunitinfo; tunittableentry=record init, finit: pointer; unitinfo: Punitinfo; typecount: cardinal; unittypes: pptypeinfo; // array[0..typecount-1] of ptypeinfo for all the types in interface implementation end; Every package/exe(!)/library(!) has a packageinfo table with all the contained (implicitly/explicitly) units in order (like now) of dependencies containing a link like punittableentry. Yes, the executable is a package too! Another thing is what to do with weak packages or what with if you include this unit first in your project, then it will be initialized after system... for instance a memorymanager-swap? Packages and the used/described register-init order implies that when you use a memory manager like that, a lot of memory can have been allocated during init of units using the default manager before a swap happens. one can mediate that a bit if one can indicate the order of build with runtimepackages and if rtl contains no units that allocate memory (direct/indirect) in their init sections. So, working further on the register packages first, then initialize in order doctrine, one can make the above records and especially the unittableentries and/or table as a doubly linked list. But that is just an idea. I'm gonna stop here, because packages entail ofcourse a lot more than RTTI or dll generation/ini/fini. This is just the top of the iceberg. kind regards Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison Delphi7/FPC2.4.0 compiled MSEide exe's
- Florian Klaempfl flor...@freepascal.org schreef: Am 13.09.2010 13:47, schrieb Martin Schreiber: On Monday, 13. September 2010 13.24:18 Florian Klaempfl wrote: Am 13.09.2010 11:15, schrieb Martin Schreiber: Delphi 7 FPC Exe size: 3131392 3689304 Code: 2128524 2138240 Data: 752085 1541256 Do you use a lot of resource strings? I can not use resource strings because FPC resource strings are not unicode capable AFAIK. In MSEgui there are many local classdefs in the form of type ttheclass1 = class(ttheclass); in order to access protected class members This should not create any additional data. not even rtti-related and vmt-surrounding-data? kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Packages, Generics
- Sven Barth pascaldra...@googlemail.com schreef:
Am 13.09.2010 11:44, schrieb Willibald Krenn:
But enough about generics, back to packages: I'll start doing an
implementation for the non-generic part first. Let's see how this
goes. Since I need to read into fpc source (and do this in my spare
time), don't expect any spectacular results soon. In case there are
more people interested in implementing this, some branch in the repo
would be needed - if I am the only one, I will do this locally on my
disk.
You might want to start compiler/pmodules.pp. There is already some
code
to parse package projects and some code that allows all symbols to
be
exported (this code also appears in ppumove, but only for Linux and
DOS).
I've stumpled upon this code last week and tested it on a Linux
system.
Compiling a simple package with a single unit works if I use Win32 as
target. A .dll (wrong file extension) is generated which exports all
functions/procedures that are in the interface of my unit or the RTL
units, but no variables are exported although the Win32 target
supports
this (tested before the package). Using Linux as a target results in
an
internal error and I've not yet found the time to investigate this.
Also requires sections aren't parsed yet.
how about contains sections?
In theory(!) it should be rather simple to implement shared cross
platform packages (those that are loaded on app startup by the OS and
not dynamically during the run).
that would require a change in sysinit, sysutils system units as well, all
types of linked-target modules (executable, shared lib, package) should
register their moduleinfo ('hinstance' of the module, list of contained
units' table entries = init, finit pointers) in startupcode for the module.
shutdown code for the module should deregister that moduleinfo.
for somewhat of a breakdown, look at TLibModule, LoadPackage, UnloadPackage and
related functions for inspiration:
http://docwiki.embarcadero.com/VCL/en/System.TLibModule
http://docwiki.embarcadero.com/VCL/en/System.LibModuleList
http://docwiki.embarcadero.com/VCL/en/System.RegisterModule
http://docwiki.embarcadero.com/VCL/en/System.UnregisterModule
http://docwiki.embarcadero.com/VCL/en/SysUtils.LoadPackage
http://docwiki.embarcadero.com/VCL/en/SysUtils.UnloadPackage
and related
http://docwiki.embarcadero.com/VCL/XE/en/System.TModuleUnloadProc
http://docwiki.embarcadero.com/VCL/XE/en/System.AddModuleUnloadProc
http://docwiki.embarcadero.com/VCL/en/System.RemoveModuleUnloadProc
http://docwiki.embarcadero.com/VCL/en/System.EnumModules
http://docwiki.embarcadero.com/VCL/en/System.EnumResourceModules
http://docwiki.embarcadero.com/VCL/en/SysUtils.InitializePackage
http://docwiki.embarcadero.com/VCL/en/System.PackageInfoTable
http://docwiki.embarcadero.com/VCL/en/System.UnitEntryTable
http://docwiki.embarcadero.com/VCL/en/System.PackageUnitEntry
sysinit, system, sysutils:
the initialization of an executable/package/library needs to be completed with
filling in the libmodule structure (needs to be generated as well) with the
moduleid (portably!) and the pointer needs to be given to registermodule. In
delphi a check occurs somewhere on all the included units of a
package/dll/exe to see if there is a duplicate unit loaded.
loadpackage does nothing more than dlopen() of a file, and then the resulting
recently added libmodules that were added are then initialized by init-ing
their unittable entries.
conversely, unloadpackage finit's all those units and dlclose().
finalization of an executable/package/library unhooks the libmodule
addmoduleunloadproc/removemoduleunloadproc are invoked either by unloadpackage
or by unregistermodule.
---
as said before, inspiration can be had from how they do it, but that doesn't
mean fpc should do it that way. Especially in a crossplatform context, and more
so cross-architecture, it is not a one-size fits all per se.
kind regards,
Dimitri Smits
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
- Marco van de Voort mar...@stack.nl schreef: I partially agree with you in the fact that the exact reasons are not known. I'm no expert on profiling the compiler, but if I read the various threads over the years I see defensive and conflicting statements: In discussions with Hans, it is said that I/O is not a factor, since after one run everything is cached anyway, and then in this thread I/O is to blame for a huge difference in speed. that may be the case for reading, not necessarily for the files being written. in ppu.pas, everything you put results in a blockwrite of x bytes. Wouldn't a cached memory stream be better, not resulting in those int21h calls or windows equivalent calls? Haven't looked at .s creation (donno where to start looking, but I guess this is the same???) The same with the fact that we use shortstring for performance in many places where delphi in fact allows longer mangled names and is faster. That leaves the maintainability bit. I think that is certainly true, and it probably can be tweaked to be a bit better. It won't be easy though and is more likely to be a lot of things that add a little than few that matter a lot. Which makes it a permanent positions instead of a one-off effort. Any takers? As far as the I/O performance discussion goes, some observations: - To find something interesting, probably the test has to be done for various sizes of code. To see if maybe some startup factor (Rather than actual processing) is a cause. agreed - FPC has to read at least twice the number of files (.ppu/.o). So if opening or number of files in the dir path is a factor, it will do worse by default. actually, this is a false statement. The units that come with delphi (rtl and others) are packaged in .dcp (and .bpl). That means that not only those x2 files, but a factor of those x2 can be done. Admitted that you probably load way to much in some cases as well as that it is not easy to know in what .dcp your needed unitinfo is included. Or at least isn't obvious. - Possibily, a defaultly installed windows searches through a larger unit path (more dirs, more file) than Delphi _default_ - For that to be found, more has to be known about dcc.cfg during the tests. - THis means that tests will have to be repeated with various sizes of unitpath trees (both dirs and files) to see if this is a discussion. - Most profiling recently afaik has been done by Jonas, and thus not on Windows. Yet the delphi comparisons are on windows. - Actually linking should be avoided in the test. It might obscure things. in that case, all external tools should be avoided. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
- Mattias Gaertner nc-gaert...@netcologne.de schreef: On Sun, 12 Sep 2010 10:25:22 +0200 (CEST) mar...@stack.nl (Marco van de Voort) wrote: In our previous episode, Mattias Gaertner said: Agreed. My opinion is that before we start to implement difficult and error-prone multi-threading into FPC we should find out why the hell Delphi 7 can compile so much faster and produces even better code? Seeing that dcc is only 800K: maybe it fits into the cpu cache. I assume dcc.exe uses more data than code :-) CPU caches do not work FIFO. If FPC does not fit into the CPU cache, then the CPU has to constantly load code mem additionally to the data. in that case, can splitting up the .exe into .exe + more .dll's help? aka a compiler package, a rtl, a assembler package, ...? kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
- Martin Schreiber mse00...@gmail.com schreef: On Saturday, 11. September 2010 12.25:14 Juha Manninen (gmail) wrote: One would think Delphi and FPC need the same disk IO? I read the threads. My guess is also that the slowness comes from searching and writing many files in big directory structures. It is slow even if the files are cached. Also starting a new process is slow. These OS kernel tasks are difficult to measure and process monitors don't give reliable results. Suggestion: Create an API for integrating FPC with IDEs and special make programs. The API would pass info about exact file names and locations. It could also pass the whole source memory buffers. And why does the Delphi commandline compiler (dcc32) not need this IDE assistance? it does. Delphi IDE passes extra assumptions/directories that the commandline tool does not know about (for instance $(DELPHI)/Projects/Bpl). Juha's idea is the way Borland did it with D7. That is: a shared lib with api a commandline tool. Unfortunately the DLL is not linked from the cmdline tool, so it seems those 2 are separately compiled and statically linked with 'the same' code. Donno for sure if that still is the case with 2010/XE. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
- Juha Manninen (gmail) juha.mannine...@gmail.com schreef: On Saturday 11 September 2010 13:40:26 Martin Schreiber wrote: And why does the Delphi commandline compiler (dcc32) not need this IDE assistance? My guess is that dcc32 works as an integrated make program + compiler and thus doesn't start external processes for each file. Or, if it starts an external process then it can use some (hidden) temporary file with pre-scanned info of the project. So the compiler would only open one info file instead of scanning the whole search paths. I used the IDE always when working with Delphi and don't really know dcc32. Guessing only. no, the bin directory of D7 is filled with extra .exe's (tlib, tasm32, ...) and the dcc32.exe is 800K big. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
- Michael Van Canneyt mich...@freepascal.org schreef: On Sat, 11 Sep 2010, Juha Manninen (gmail) wrote: On Saturday 11 September 2010 13:40:26 Martin Schreiber wrote: And why does the Delphi commandline compiler (dcc32) not need this IDE assistance? My guess is that dcc32 works as an integrated make program + compiler and thus doesn't start external processes for each file. No it does not. dcc32 compiles 1 file only, but does compile any additional units it needs. You'll need makefiles as well if you use dcc32 (or any other build tool). I have an extended build system using dcc32, and it takes easily up to 15 minutes to compile a 1.5 million lines project. that is my experience as well. (using 'want.exe' aka windows 'ant') it implies though that you can merely compile your .dpk and .dpr files to get everything compiled ;-) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC/Lazarus Rebuild performance
- Florian Klämpfl flor...@freepascal.org schreef: Am 11.09.2010 20:50, schrieb Martin Schreiber: On Saturday 11 September 2010 20:27:46 Florian Klämpfl wrote: What machine? Because with hot disk cache, I just build MSEide in about 10 s (15 s cold) on W7 64 Bit: The same as for all other tests, win2000, AMD Athlon XP 3000+, 1GB RAM ... Linking mseidefp.exe 308574 lines compiled, 10.6 sec , 2577952 bytes code, 1618920 bytes data Then Delphi7 probably uses about 1 sec on your machine. ;-) ... mseide.pas(63) 280491 lines, 2.18 seconds, 2110568 bytes code, 752073 bytes data. Anyways, before this ends in an endless discussion: if anybody is interested in improving FPC compilation speed (for my needs is sufficient) and have a look at fillchar and, have a look at FPC's unit loading algorithm (not the actual i/o itself but how all the symbols classes etc. are restored). This two points are bottlenecks which might help when they are improved, though it's pretty unlikely that this will improve things more than a few percent. I am not as intimately familiar with the compiler internals as most of you, but the writing/reading of those .ppu files looks to me like a prime candidate. other things that I do not know if they are already implemented this way: 1) if the .ppu/.ppl + .o are merged and they give better results then why not go the extra mile and implement packages (or at least the .dcp)? Although I fail to see why (except for linking) both have to be opened during compilation. With packages I mean the .dcp/.bpl equivalent. It is my understanding that .dcp is like a .lib + all the stuff in the unitinfo (.dcu / .ppu), and ofcourse the more simpler .bpl = .dll with extra's. That way, you need to dive into much less files. 2) when fetching / checking the files, does it happen according to the unit include paths and those paths appended by targetos en architectures for every file? Wouldn't it be more efficient to fetch/cache some dir-info first for all files in those dirs and then fetch the necessary info from there? For instance: get filenames + size + timestamp for all .ppu files or .pas files first. 3) It is my understanding that the .ppu structures are written with size-footprint in mind, not processing efficiency? Maybe the structures need changing too? kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Status of Delphi-like packages (Class+RTTI aware DLL/SO)?
- Willibald Krenn willibald.kr...@gmx.at schreef: Hi! Please forgive my ignorance on this topic, but I'd like to know whether someone is working on adding Delphi-like packages to FPC. (At least for the windows/linux platforms.) Somehow the lack of this feature always has stopped me from using fpc/lazarus: For a change, I am thinking of contributing to the efforts unless - of course - the feature's already in the works :). Cheers, Willi P.S.: Way back in time, I did some investigation on the Delphi (6) name mangling, see http://edn.embarcadero.com/article/27758 (german only). aparantly you beat me to it, but I was planning on compiling a mail like this one later today (at home). Besides you (an me), is there anyone else interested in implementing this? My angle (besides from the obvious dynamic pluginsystem vs the lazarus/*nix FOSS way aka rebuild everything when you want something included) is that there are some additions to RTTI that need to be done as well regarding packages, units en the relationships with current RTTI and startup-initialization. I would be nice to know who wrote/compiled the packages page in the fpc wiki and to get in contact with ppl that want to discuss/implement delphi packages. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] regarding RTTI unit mail
- Marco van de Voort mar...@stack.nl schreef: In our previous episode, Dani?l Mantione said: and C++ you can get hell when you change the order of elements, with interleaved #defines and #ifs (what's possible in Pascal as well). If the order of elements is enforced, it is not a creative decision, thus both programmers can make the same decision without violating each others copyright. This sidestep thread over the EU directive misses the main point. Legal or not, the question is do we really copy interfaces straight from Borland source? Afaik not. At least I never did, I always looked up header definitions from places as Delphi.about.com I doubt that site is going further then D7 in it's documentation. Is the following enough/too much/dangerous to start from? A nice tutorial/breakdown with a lot of stuff (read: interfaces definitions) in it can be found here: http://robstechcorner.blogspot.com/2009/09/so-what-is-rtti-rtti-is-acronym-for-run.html WARNING: official documentation on the web, from which one can deduce the interface(s) and how to use it. So don't read it if it taints you. http://docwiki.embarcadero.com/VCL/en/Rtti.TRttiProperty http://docwiki.embarcadero.com/CodeSamples/en/TRttiContextGetMethods_(Delphi) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Michael, thank you for the reply. It makes a few things a lot clearer for me. I'll comment a bit more below. - Michael Van Canneyt mich...@freepascal.org schreef: On Sat, 28 Aug 2010, Dimitri Smits wrote: What I want to do: Since Delphi 2010, there is a new unit in the RTL that makes RTTI more of a breeze. I'd like to port (meaning: compatible interface, fpc implementation) this unit to fpc-rtl. Initially port over what is there already. Later maybe include in the compiler stuff like scoped RTTI (not just published alone) and customattributes if there is need for that level of compatibility. Also, adding more methods on the current interface is possible too. It is more than just a readable substitute for TypInfo. Well, the compiler doesn't support custom attributes. I know, neither does it support RTTI-scoping (only published members of a class, and other types are 'public') or run-time unit per package registration or ... Like I said: first implement what is there and can be ported to fpc. That way I do not have to dive into compiler-output and parsing (for now). Later on, it can be expanded with those features that DO get implemented or not if they'll never be. After initial porting, I might extend the interfaces with a few methods (e.g.: getters+setters with AsString+AsInteger+As... etc). But first: port what is there. For this I'd like to know a few things: - First off: would this kind of thing even be considered for inclusion? Yes. Any unit to increase Delphi compatibility is worth of inclusion. good to know. to be placed next to types unit in objpas, I presume. - How to get it into repository/feedback from core? (through feature request with attachment in mantis?) I'll handle that; Just post it on mantis, I'll look into it. attach the unit, or in patch form? - Codestyle conventions for fpc-code? (including licence-header etc) Modified LGPL header (see any rtl file). Code style: follow the Borland style guide. that header, with your name Florian or mine or 3? :-) - Is there (besides System, SysUtils, Types and the Variant-units) another place to look for RTTI-types? Not sure I know what you mean by this ? Is there another unit other than those that contains structures defs mapping to what the compiler generates? (like ptypeinfo, but also for punittype, or packages) anything I've missed regarding lowlevel info on types language constructs - Where do I need to take care off (how to include it in rtl package, ..., unit-dependencies )? Nothing. I'll take care of that, you just write the code. what i meant was: don't use generic types like fpglist and/or consorts that are not in the rtl package. (what files can I check to see what is included in the rtl so I don't accidentally make cyclic dependencies. - I've read somewhere that nothing gets included if no unit-tests are - provided. Is this using fpcunit? Any pointers on the testingsystem, - do's and don'ts are welcome. You can use fpcunit; there are sample tests in the fcl-fpcunit directory. to be placed under what dir? fpcunit would have been my choice nevertheless. :-) All other daily test programs use a different mechanism: they must return a zero exit code. Nonzero exit code means that there is an error. You're free to choose one over the other; Personally, I favour fpc-unit style. I find it works most easily, definitely if you use Lazarus. so, lpi files and the like are acceptable in fpc? Since I work on win32 (only), I'm not that familiar with makefiles. So, if I need to add anything to makefiles or copy+edit another makefile, please redirect me to more information. (mainly for testing-app, I guess) Let me handle that. Focus on the code. will do. Have to start, and probably will go through a few iterations before I post it in mantis (also, when time permits). And even then it might be something to discuss first and take a few posts to get it feature complete. if that's allright by you ;-) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
Hi Paul, thanks for the input. - Paul Ishenin webpi...@mail.ru schreef: 29.08.2010 3:46, Dimitri Smits wrote: What I want to do: Since Delphi 2010, there is a new unit in the RTL that makes RTTI more of a breeze. I'd like to port (meaning: compatible interface, fpc implementation) this unit to fpc-rtl. Initially port over what is there already. Later maybe include in the compiler stuff like scoped RTTI (not just published alone) and customattributes if there is need for that level of compatibility. Also, adding more methods on the current interface is possible too. It is more than just a readable substitute for TypInfo. At the present state of fpc compiler it is technically imposible to port delphi rtti unit. To do this you need first to implement the next compiler features: 1. Extended records (methods, class operators) 2. Generics as in delphi 3. Attributes 4. scopeable RTTI ($RTTI directive) Once I tried to implement extended records in the compiler but the changes were too big for the time I had and I had left that idea for the better time. incremental changes. First try the basic types, then classes/objects/records. And leave out those types for now that cannot be ported. In a next phase, then include what is needed either in compiler or fpc-specific rtti objects (in same style/spirit). As for that (4) above. The last few months I've seen this requested a few times (either direct or indirect) on mailinglists. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RTTI unit
- Michael Van Canneyt mich...@freepascal.org schreef: On Sun, 29 Aug 2010, Marco van de Voort wrote: In our previous episode, Michael Van Canneyt said: There is nothing in Delphi X (due in 3 days) that will not build on these existing things. We need those first. Delphi Xe is not the multiplatform version anyways. From what I've heard, the Mac version is unlikely to appear soon, if at all. Let alone a linux version. I have browsed through the system.pas file of 2010 on one occasion (when I had the chance). Was full of MACOS and Linux IFDEF's already! kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] RTTI unit
Hi, I was wondering if anybody could direct me in the right direction (either mail, wiki) with regard to following questions. What I want to do: Since Delphi 2010, there is a new unit in the RTL that makes RTTI more of a breeze. I'd like to port (meaning: compatible interface, fpc implementation) this unit to fpc-rtl. Initially port over what is there already. Later maybe include in the compiler stuff like scoped RTTI (not just published alone) and customattributes if there is need for that level of compatibility. Also, adding more methods on the current interface is possible too. It is more than just a readable substitute for TypInfo. For this I'd like to know a few things: - First off: would this kind of thing even be considered for inclusion? - How to get it into repository/feedback from core? (through feature request with attachment in mantis?) - Codestyle conventions for fpc-code? (including licence-header etc) - Is there (besides System, SysUtils, Types and the Variant-units) another place to look for RTTI-types? - Where do I need to take care off (how to include it in rtl package, ..., unit-dependencies )? - I've read somewhere that nothing gets included if no unit-tests are provided. Is this using fpcunit? Any pointers on the testingsystem, do's and don'ts are welcome. Since I work on win32 (only), I'm not that familiar with makefiles. So, if I need to add anything to makefiles or copy+edit another makefile, please redirect me to more information. (mainly for testing-app, I guess) Anyhow, the first question is the more crucial one. If anybody is interested in the (public) interfaces of the tobjecttypes, I can provide those. If there needs to be a debate first, fine by me ;-) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] regarding RTTI unit mail
Hi, (just hate it when you send something after re-reading it a few times, and a minute later you know that there is something important you forgot to ask) Since objectnames and interfaces are cloned from Delphi everywhere in the fpc-rtl, I was wondering if this is legitimate use and not a copyright violation? ie: the interface is the same, the implementation is different (unless trivial). Is this, or is this not an issue? kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] [patch] pscanner: differentiate between EOL Tab characters from general Whitespace
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: On 22 August 2010 13:35, Marco van de Voort wrote: He wants the source as a kind of DOM model. That is IMHO a valid use, but I doubt it is unifiable with the current parser. Not nearly as complicated as a DOM model really. I just want to insert some timing calls and a new entry to the uses clause. See my reply to Michael to understand what I am trying to accomplish. This is typically one of the reasons why the one parser to rule them all approach is flawed. For fpGUI IDE, I hope to do more code modification/generation using fcl-passrc, so then I'll can answer that question. :) mmm, looks to me that you are trying to implement some kind of AOP (Aspect Oriented Programming) for this. (which IS interesting) The way most profilers that I've worked with did it was adding those timing-stuff (and counting) on a link-phase. (or through a custom exe-loader). Every PIC/method-table or VMT was replaced by a stubb. Or is it something else you want? (custom attributes, the .net way, with AOP methods and a method sink?) Anyway, if so, would this profiling stuff be optional, on/off all or on/off for a specific method/class/unit/package/program? kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Conditional Breakpoints using FPC and GDB
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: On 13 August 2010 13:11, Michael Van Canneyt wrote: Can you explain this ? As far as I know, there no member of the core team that objects to having properties inspectable in the debugger ? I was obviously generalized a bit too much. If you really want me to, I can search the mailing list archive to find out who said what. Anyway, it was told many times before that inspecting a property with Getter and Setter methods may change underlying data - so the whole debugging of Properties are frowned upon. I'm simply stating that developers should know what they are doing, and that I have never seen a Delphi developer ever complain about that possible data change issue. It's only FPC developers that keep mentioning it. Delphi's debugger has had the possibility to inspect properties for ages. In fact, for watches you had to tick an extra checkbox to allow for function-calling. Using a property in delphi is ALWAYS a function-call, even when you use a read=FSomeField specifier. The debugger knows to inspect through the RTTI property-tables and finds which call to make and type to expect. As for why Delphi devs who don't complain: I for one couldn't get the lazarus-bundled/integrated-debugger to work on windows except for a few trivial cases. (about half a year ago) Also, using Delphi for this many years now (10+), I guess I must have been spoiled because GDB just doesn't do it for me (and the 1000 windows lazarus opens are a nightmare). Stepping in assembler or changing a register didn't work at that time (both trunk and official release) without AV's. At that time it was stated that the debugger was under construction. So I did the next best thing ever since: develop+debug on Delphi then port to fpc. But instead of complaining, I'd better check the current status. My point being: when working on windows, coming from Delphi, the debugger needs getting used to and has it's limitations. When you have Delphi, you can use it's debugger. btw, the whole debugger back-end was written for *nix anyway, especially when you consider the whole I need a outputwindow for console debugging vs that problem does not exist on *nix, just open another terminal and problem solved discussion of a few weeks back. ps: will check if my problems still exist with more current Lazarus (latest trunk update was 3 or 4 months ago) and if so, will complain in mantis :-) kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Conditional Breakpoints using FPC and GDB
- Graeme Geldenhuys graemeg.li...@gmail.com schreef: On 13 August 2010 13:11, Michael Van Canneyt wrote: Can you explain this ? As far as I know, there no member of the core team that objects to having properties inspectable in the debugger ? I was obviously generalized a bit too much. If you really want me to, I can search the mailing list archive to find out who said what. Anyway, it was told many times before that inspecting a property with Getter and Setter methods may change underlying data - so the whole debugging of Properties are frowned upon. btw, what I forgot to respond to in my last mail of a few mins ago: a getter is not supposed to change anything, when working in a correct OO way. a modifier/setter is the way to change data. The inspector can use both. Watches only getters. So I fail to see the problem: when you CHANGE the value, it is because you explicitly did so through the inspector (ad-hoc expression evaluator should not allow this, just through inspector). Those who frown upon that, need to reschool themselves in OO practices, because then they are using it incorrectly ;-) Correcting/contradicting myself a little bit: The reason that the checkbox in delphi watches is needed and the only thing that CAN change something in the internals of an object is when you have somesort of lazy-loading (be it from cache, db, ...) behind a getter. That is the reason why you need to explicitize to the developer who is supposed to know what (s)he is doing. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] C++ linking questions
Jonas Maebe wrote: On 22 Mar 2010, at 11:19, Anton Kavalenka wrote: Don't UNITS in Pascal intended to separate NAMESPACES? But unfortunately this prevents nested namespaces. The discussion is not about adding support for C++-style namespaces to Pascal, but for how to specify the C++ namespace in which an (externally implemented) C++ class is defined (as this influences the name mangling). Anton Kavalenka wrote in reply to that: I understand :) The most amazing thing will start later (during linking). In what order = runtime initialization should be performed (first Pascal the C++ or vice = versa)? Obviously C++ object files has lots of references to C++ runtime so in = best case we get exe file with 2 runtimes inside, in worst case we get crash on initialization. it even gets worse than that. Is this even possible? WHAT C++ compiler-mangling are you going to support? Every C++ compiler has its own mangling scheme, which individual versions of it can change at will as well. GNU C++ on linux/whatever system? = changed mangling between versions Borland/(open)Watcom/Digital Mars/Microsoft/... on Windows and some on other systems = same there. there are some ABI's, but they do not contain name-mangling conventions. ps: sorry to mess up your thread. I'm using digest. kind regards, Dimitri Smits ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
