It depends. You're not supposed to make assumptions on when an interface goes out of scope. If you search the archives, you'll find multiple threads about this, where Jonas (with his legendary patience) explained to people why this assumption is false, and that indeed FPC is not compatible to Delphi in this regard, and that this will not be changed.

Michael.

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.

When you create an instance it logs entry information, and increased the indentation level. When that interface instance went out of scope in decreased the indentation level and logs exit information.

Unfortunately this doesn't have the same affect under FPC (tested with Windows and Linux).

The problem is that under FPC, the Interface instances immediately goes out of scope. It seems Delphi held on to that instance even though you did not store it in a variable. Once the current procedure/method is complete, then only the Interface instance went out of scope.

Why do I need this:
-------------------
* Delphi compatibility of course ;-)
* Due to the bad state of debugging under FPC[*] I am implementing (actually just extending the thread cached log-to-gui class of tiOPF) to recreated a product similar to Raize Components's CodeSite product. http://www.raize.com/DevTools/CodeSite/Default.asp

http://www.ackerson.us/AckersonSoftware/Dev/CodeSite/CodeSiteEx/method_tracing.html
* Allows for easier profiling like in 'fpprofiler' project. The CodeSiteEx product does this as well.
http://www.ackerson.us/AckersonSoftware/Dev/CodeSite/CodeSiteEx/timer.html

Can anybody shed some light on why this doesn't work in FPC, and if it is possible to make FPC delphi-compatible in this regard?

Delphi 7 app output:
--------------------------------------
Y:\tests\logger>Project1

> Main

Here I am

> TryMe

i = 42
42 is the answer to everything
<< TryMe
We are reaching the end
<< Main
--------------------------------------

FPC 2.4.3 (Linux) app output:
--------------------------------------
logger $ ./Project1

> Main

<< Main
Here I am

> TryMe

<< TryMe
i = 42
42 is the answer to everything
We are reaching the end
--------------------------------------

FPC 2.4.3 (Windows) app output:
--------------------------------------
Y:\tests\logger>project1

> Main

<< Main
Here I am

> TryMe

<< TryMe
i = 42
42 is the answer to everything
We are reaching the end
--------------------------------------

Footnotes:
[*] - Inconsistent results between FPC+GDB under 32-bit and 64-bit environments.
- DbugIntf unit can't keep up to fast logging under Windows, and simply looses debug information
- Can't debug expressions via GDB
- Can't debug something as simple as AnsiString's under GDB.
- Can't debug a character index into a ansistring with GDB. ...the list goes one...

Regards,
- Graeme -

Op 2010-11-10 11:31, Graeme Geldenhuys het geskryf:

to recreated a product similar to Raize Components's CodeSite product. http://www.raize.com/DevTools/CodeSite/Default.asp

Here is CodeSiteEx's explanation for why it works under Delphi.

http://www.ackerson.us/AckersonSoftware/Dev/CodeSite/CodeSiteEx/method_trace_magic.html

Regards,
- Graeme -

Indeed, that's what happens in this code and what FPC does. What the code makes working is how delphi handles temporary interfaces. The LogMethod call generates a temp. interface variable for the result. FPC finalizes this temp. interface immediatly after the call because the result is not used. Delphi does this apparently delayed.

Op 2010-11-10 11:30, Michael Van Canneyt het geskryf:

It depends. You're not supposed to make assumptions on when an interface goes out of scope.

I'll search the mailing list archives for those explanations, thanks. I don't immediately understand why this is a problem, because the RTL is not a "managed code" environment with garbage collection. So I guess most developers would expect common "out of scope" rules apply. When a local variable is defined and you leave that method/procedure, it's out of scope.

why this assumption is false, and that indeed FPC is not compatible to Delphi in this regard, and that this will not be changed.

Then this is bad news indeed. Another blow to trying to improve FPC built application debugging. :-(

Regards,
- Graeme -

Well, the original coders made assumptions which they're not supposed to make.

Nowhere is the Delphi behaviour guaranteed, not even by Delphi. They're just taking for granted that Embarcadero will never change this behaviour... For instance, on 64-bits - once it comes out - the code may stop functioning as well.

Michael.

Op 2010-11-10 11:42, Florian Klaempfl het geskryf:

LogMethod call generates a temp. interface variable for the result. FPC finalizes this temp. interface immediatly after the call because the result is not used. Delphi does this apparently delayed.

Correct, and that is how the developers of CodeSiteEx explained it. http://www.ackerson.us/AckersonSoftware/Dev/CodeSite/CodeSiteEx/method_trace_magic.html

So is there still a possibility that this will be fixed in FPC, or is Michael assumption correct, that it will not be fixed? After all, this is a Delphi compatibility bug [just thought I had to add that. ;-)].

Regards,
- Graeme -

Graeme Geldenhuys wrote

a "managed code" environment with garbage collection. So I guess most developers would expect common "out of scope" rules apply. When a local variable is defined and you leave that method/procedure, it's out of scope.

*picky mode* exactly this is true for FPC as well. But it's a "when" relation only, not an "only when" relation. LOL

Micha

Graeme Geldenhuys wrote

am saying is that in the current "released" Delphi versions (at least down to D7, probably D6 too) this feature works. The "mouse cursor" trick using the same Interface behaviour has been in tiOPF code for years, and I think that's where I saw it first.

Should FPC be compatible performance timing wise as well? assembly instruction by assembly instruction? That's what you're talking about it's not language compatibility, but performance compatibility.

Micha

As soon as it becomes spec, yes. Otherwise no.

Just like the 'const is passed by ref'. No, it is not, and won't be: it's up to the compiler's dicretion.

Yes, valid and documented code is supported.
This is invalid code which just so happens to work.

There are more cases where we are incompatible. All of them for good reason.

Michael.

Op 2010-11-10 11:56, Michael Van Canneyt het geskryf:

Well, the original coders made assumptions which they're not supposed to make.

To be fair, it has worked for over a decade already. Plus many IDE and Compiler add-on vendors implement their products based on Delphi behaviour (even though it might not all be documented). The same gets done for Windows apps in general - working on Windows behaviour. Lets not speculate if it will be broken or not in the next Delphi release (nobody knows the answer to that, and there is no reason why it will be broken then). All I am saying is that in the current "released" Delphi versions (at least down to D7, probably D6 too) this feature works. The "mouse cursor" trick using the same Interface behaviour has been in tiOPF code for years, and I think that's where I saw it first.

And the fact that so many developers asked about Interface scope problems in the past [as you mentioned], clearly indicates that that should be the expected behaviour in FPC too.

Nowhere is the Delphi behaviour guaranteed, not even by Delphi.

Well, I can always argue that FPC tries to clone/mimic Delphi behaviour in many ways... it's that little FPC design goal called "delphi compatibility". Think of all the poor developers trying to port their Delphi code to FPC. ;-)

Regards,
- Graeme -

Graeme Geldenhuys wrote

same application behaviour and outcome, using the same source code. That's got nothing to do with performance as far as I'm concerned.

Because you're a brainless moron.

Micha

Op 2010-11-10 12:24, Micha Nelissen het geskryf:

instruction by assembly instruction? That's what you're talking about it's not language compatibility, but performance compatibility.

I'm not sure where you got the "performance compatibility" from? I did not once mention "performance" in any of my messages. I'm talking about the same application behaviour and outcome, using the same source code. That's got nothing to do with performance as far as I'm concerned.

Regards,
- Graeme -

That sort of remarks are not welcome on the FPC lists. If you cannot control your urges to hurl insults at someone, then do so in private.

Jonas
FPC mailing lists admin

Op 2010-11-10 12:32, Micha Nelissen het geskryf:

Because you're a brainless moron.

Oh, that was quick! An instant drop to the name calling level. As usual, I can never have a constructive discussion in this mailing list.

Regards,
- Graeme -

Op 2010-11-10 12:24, Michael Van Canneyt het geskryf:

I'm still searching the archives. Mind you tell me what would be so bad in this case to be delphi compatible? Is there actually any negative points to it?

Regards,
- Graeme -

Op 2010-11-10 12:32, Micha Nelissen het geskryf:

Because you're a brainless moron.

I so hope Embarcadero lives up to the developer expectations when it releases cross-platform support. If it does, I'll be the first person to leave Free Pascal behind.

Regards,
- Graeme -

If you argue that way, we need to make sure that fpc has all the bugs delphi has, too, so that all the workarounds for those bugs work in fpc as they do in delphi. Seriously, there must be a measure, and that measure is the delphi docs. If it's mentioned somewhere in the delphi docs that you can rely on this behaviour, I'm sure that the fpc team will implement it.

Henry

Graeme Geldenhuys wrote

I so hope Embarcadero lives up to the developer expectations when it releases cross-platform support. If it does, I'll be the first person to leave Free Pascal behind.

And this sort of flame bait is also not useful.

Posts in this thread are now moderated.

Jonas
FPC mailing lists admin

Graeme Geldenhuys wrote

I'm still searching the archives.

mail-archive.com is currently not responding for me, but the thread is here:
(it will probably come back online later today).

There's also a long discussion on the same topic at http://bugs.freepascal.org/view.php?id=9472

Mind you tell me what would be so bad in this case to be delphi compatible? Is there actually any negative points to it?

Ensuring compatibility with undocumented code generator details require large amounts of work, and moreover can be completely in vain if Delphi's behaviour changes later on.

In this case, the work would entail determining *under all circumstances* where exactly Delphi creates temporary interfaces and where not, and where the refcounts are increased and decreased. See the bug report and thread above for how Delphi's behaviour is not the same under all circumstances either (because of limitations in inter- procedural analysis -- it's quite possible that when inlining some function calls, Delphi's behaviour will also change). Then you have to adapt the FPC code generator so that it performs the same optimizations as Delphi does under the same circumstances (not more, not less).

Jonas

FPC could implement, document and guarantee the very useful and sometimes necessary behaviour maybe?
I sometimes miss the support from FPC team for framework and user requirements. The framework devels can't develop the compiler them self. But don't you think, a compiler, where the main purpose is to compile it self, is a little bit sparse?
Don't you think the FPC team should ecourage IDE and framework devels to use their compiler and the FPC team should support them as much as they can, same as we (the framework devels) do with our customers? We had that theme already with FCL and RTL, do you remember? Now I don't use FCL and RTL anymore if there are other possibilities because doing it on my own is less work, less time consuming, normally with better results and more fun and less frustration.

Martin

The behaviour how compiler internal temp. variables are used?

maybe?

So other people might complain that the compiler keeps an instance unfreed for no use? Ignoring other people's need is simple.

I sometimes miss the support from FPC team for framework and user requirements. The framework devels can't develop the compiler them self. > But don't you think, a compiler, where the main purpose is to compile

it self, is

a little bit sparse? Don't you think the FPC team should ecourage IDE and framework devels to use their compiler and the FPC team should support them as much as they can,

Maybe we cannot do more?

We had that theme already with FCL and RTL, do you remember? Now I don't use FCL and RTL anymore if there are other possibilities because doing it on my own is less work,

How much targets do you support with your code? 2? 3?

less time consuming, normally with better results and more fun and less frustration.

Yes, that's why I concentrate on compiler development as well. The "do this" or "do that", "if you don't do, I leave FPC and use XXX" discussions are simply too boring.

In our previous episode, Graeme Geldenhuys said:

I'd search for mantis items (closed probably as won't fix). Then maybe in the archives around the same time as activity there.

As on the topic (since I don't know the exact tradeoffs of this feature) is that it is very difficult to correctly judge such bits. It isa slippery slope:

E.g. afaik the Jedi JCL prepares tracebacks using TD32 debug info, and maybe apps and vendors use JCL and JVCL, and many others may have there own traceback routines based on TD32 debug info Does this mean we have to emulate Borland internal debug info to the byte?

Besides this, "all" the versions of Borland that support interfaces are one and the same compiler, for x86. (the 16-bit compiler D1 didn't support interfaces, and Kylix was x86 too). Trying to guarantee these kind of implemenation details could bring you into problems on other architectures, where calling conventions and prologue/epilogue tradeoffs are different.

I'm the first to say more Delphi compat is a good thing, but you have to draw the line somewhere. And this goes pretty far.

It would be wise to try so see further than your immediate pain, and make that the center of the universe.

Sure, if we are agreed on what is necessary.

Martin, I understand your needs. You must understand the limitations of FPC.

This is open source: essentially a hobby project for us.

It's meant to be fun, we spend time on it as we can and as it pleases us. We have pointed this out many times. We also point out that we have paying day-time jobs. Crudely put: I am stealing time from my employer by answering your mails.

It is therefor your (as in 'the users') duty to convince us that the particular features you want (or need) are worth spending our time on. If you fail to convince us, don't fret, because you were warned that this is a hobby project.

We do not refuse features for fun or because the wind happens to blow from a certain direction. We always argue our point. You may or may not agree with the point, but we are the ones you (as in "the users") expect to do the work.

If you think more time should be spent on certain features: organize a foundation that pays a developer to do so. I'm sure that many patches will be welcomed and accepted if they do not violate the basic principles FPC stands for. Percentually, the number of patches that is refused is VERY low. The few ones that are refused, tend to make a lot of noise, and in doing so they of course distort the picture.

The people who base their business on FPC should maybe realize that relying on hobbyists is a risk. We've long reached the point where the FPC core team is stretched to the limit for the tasks at hand, and you're feeling the consequences of this. No-one denies this, on the contrary.

So my advice: get the foundation off the ground. Ensure the future of FPC and your own business, if you happen to rely on FPC.

I will be glad to be the liaison between the foundation and the rest of the team. And yes, it is yet another task I will be taking.

Michael.

Op 2010-11-10 14:32, Marco van de Voort het geskryf:

traceback routines based on TD32 debug info Does this mean we have to emulate Borland internal debug info to the byte?

That's not what I asked.

Trying to guarantee these kind of implemenation details could bring you into problems on other architectures, where calling conventions and prologue/epilogue tradeoffs are different.

Thank you, that's the type of information I wanted to know, and that would be acceptable for me to understand why FPC team wouldn't want to implement such delphi-compatibility. [ignoring all the f**k y** style comments from previous replies].

Remember, I'm a framework and application developer, not a compiler developer. So answering questions accordingly is much appreciated.

It would be wise to try so see further than your immediate pain, and make that the center of the universe.

Well, trying to look at duby for a solution and possibly contributing to that project - seems somewhat outside current skill level at the moment. So I opted to take a different approach to the problem - use something that works (eg: tiOPF's reliable thread & cached based logging), and produce a mini-debugging framework (not tied to tiOPF) for other FPC users to use. Trying to make a opensource version of CodeSite or CodeSiteEx if you will, and as a plus, overcoming all the other GDB, duby issues. But as usual, everything I try to do or even just ask about, just doesn't sit right with some members of the FPC team.

I really do appreciate your constructive answer (as quoted above) though. This gives me a better indication of why the FPC team is reluctant to add such support.

Regards,
- Graeme -

Στις 10/11/2010 3:01 μμ, ο/η Michael Van Canneyt έγραψε:

< SNIP >

Well, something like that happened with the FirebirdSQL when Interbase was released open source.

regards,

As a piece of anecdotal evidence, the fact that FPC does not "properly" support interfaces was the reason for at least one company I worked for to reject it and move to Delphi 2007 instead
(from Delphi 7).

I can understand the reluctance to implement under-specified behavior, but I think FPC would benefit from *some* way to specify auto-disposed objects, even if not Delphi-compatible.

Maybe some "magic" type or a special keyword?
Maybe steal "using" statement from C#?
Or, equivalently, specify interface lifetime when used in "with" statement?

I know this. I watched it being born, it is where I got the inspiration from :-) Just as there is an Apache Foundation, GNU foundation and whatnot.

I've been propagating a FPC equivalent as long as the firebird foundation exists.

Michael.

Alexander Klenin wrote

As a piece of anecdotal evidence, the fact that FPC does not "properly" support interfaces was the reason for at least one company I worked for to reject it and move to Delphi 2007 instead (from Delphi 7).

I think that at that time there were more problems with FPC's interface support than the one Graeme encountered. We fix them as time permits.

It doesn't alter the fact that the company sits on a potential time-bomb if it relies on internal compiler-implementation dependent behaviour. This may well surface with the advent of the 64-bit compiler.

I refer to the docs for an example, and the bugtracker where Jonas demonstrated that
a) The Delphi implementation is not internally consistent. b) It would require intimate knowledge of the internal Delphi compiler implementation to be able to duplicate the behaviour. Clearly this is not feasible.

Those are the reasons we do not support this undocumented behaviour. The day it is documented and guaranteed, we'll do our best to implement it.

Michael.

Why didn't they just set a bounty or pay a compiler dev to fix it? I'm sure that would be cheaper than buying lots of Delphi licences.

Henry

I don't think that this is something that can simply be fixed. As I mentioned before, this behaviour would depend on FPC performing exactly the same kind of optimisations for reference-counted entities as Delphi under all circumstances. That is simply not a requirement that is maintainable.

Jonas

Op 2010-11-11 01:21, Henry Vermaak het geskryf:

Why didn't they just set a bounty or pay a compiler dev to fix it?

Because that is still no guarantee that it will be implemented in a timely fashion. Our company tried that route before without success. We set a $500 bounty, it was accepted very quickly, but 1.5 years later still hardly anything was done, and there was no signs of it ever getting done, so we retracted our bounty and moved on to a different solution. Companies cannot sit around and twiddle their thumbs for people that only think of something as a "hobby", and treat it as such. We run a business that need to pay bills and salaries.

Regards,
- Graeme -

It isn't! Not by a long way.

This "fix" sounds a major redesign and could take up to at least 6- 9 months (in FTE's, hours if you wish) for a seriously good team (like the compiler core team actually is, slime, smile).
I just left a (large) team that is top - notch. Average salary €5500,- monthly (incl. the free pension scheme) , senior seniors more. An XE site license for 20 developers is still *a lot* cheaper than that, with proper negotiations. But it is not X platform. If you want a X platform business and drive it through pascal dialects you are basically stuck to two options: GNU Pascal (written and maintained in C) and FreePascal (written and maintained in Pascal).

That's why sometimes a commercial compiler is hard to beat. What I like about FPC is that I can make my hands dirty and fix the bugs/features myself.
This is especially important for small to middle size companies, because if a big one (company) shouts, Embarcadero squieks... and tries to fix it asap.

Graeme should realize that the Delphi compilers (or MS compilers or Watson, or Intel) can all drive you nuts with behaveour beyond the documentation or beyond logic.
At least with FPC, you can do something about it, like with the GNU compiler set. That one is also prone to a lot of "features", btw, especially cross platform.

Just my two cents. Euro cents are used only virtual anyway.

Thaddy

Ah, right, I misinterpreted Alexander's email. I thought he was referring to other interface bugs, not this specific "incompatibility".

Henry

Yes. While other bugs were declared minor and fixable annoyances, lack of this feature totally undermined most of the company code (which used interfaces primarily as a means to control object lifetimes, and based major parts of the framework on it).

If someone honestly thinks that the hobby approach is not suitable for business, then the following question poses itself:
Why did he decide anyway to base his product on it ? (it is a rethorical question, not in need of an actual answer)

If this person decided to do this anyway, then it means he accepted the risk that some things would not be fixed/changed in a timely fashion. It is inherent in the system. Blaming the hobbyists for a decision he consciently made is simply not correct. No-one forced him to use the product, no one made any guarantees (one can read it in every source file).

If guarantees are needed:
Meanwhile, one can buy a support contract from http://www.lazarussupport.com/. As far as I know, it is a success since the day it was launched; so people can actually order a fix/change and be sure it will be done in time; that's why it is a paying service.

Not that paying is any guarantee. I have still several bugreports open with Borland, both for Delphi and Kylix. Same for other products. More often than not I fix the bugs myself simply; I haven't bought a single product yet without errors. It is why I always require source code.

With MS-Windows, I don't even bother to report bugs, I know they won't get fixed. And still we pay, even though it gets worse with each version.

Michael.

Op 2010-11-11 15:31, Michael Van Canneyt het geskryf:

If guarantees are needed: Meanwhile, one can buy a support contract from http://www.lazarussupport.com/.

A applaud them for starting that, but that business is only related to Lazarus development as far as I understand, it does not touch/affect the Free Pascal Compiler project.

Not that paying is any guarantee. I have still several bugreports open with Borland, both for Delphi and Kylix. Same for other products.

In all due respect Michael, you are missing the point. Using a framework or component set is not the problem. Like you mentioned, simply delve into the code and fix the issue yourself. The language compiler on the other hand, is a totally different beast. If I fix the problem on my side, it doesn't help anybody else, because their compiler doesn't contain that fix (and as this thread shows, not everything will be accepted into the FPC source - no matter who is commissioned to implement the patch).

Creating developer tools has another problem of it's own. Unlike Delphi, there is no stable, long term shipment of compiled units and specific FPC version, so in the world of FPC, developers tools must ship as source code. This again raise the issue with bugs in the compiler itself. I may have my compiler patched, but others will not, so I can't rely on my compiler behaviour in those developer tools for other developers to use.

In fact, I have a crap load of code sitting idle in a private fpGUI branch, simply waiting for FPC to one day ship with "interface delegation" support back-ported to FPC Fixes branch, or to be included in the next major release. So I have a solution for something, but I can't release the code, because I'm waiting on FPC. And FPC having a release rollout that takes longer that 9 months to happen sure doesn't help the process either. 2.4.2 was tagged in June, and we are still nowhere near the actual release as far as I know - almost 6 months later. So by the time it is released, it will immediately be about one year old [taking an estimate here] already.

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

The Delphi version has a different version every version (except 2007) and updates stop 9 months after a version came out (except emergency fixes, which are more like "debugger doesn't work on new versions of Windows", not real fixes.

A typical FPC release frequency is 9 months. (2.2.4 in may 2008, 2.4.0 in january 2009, 2.4.2 today)

You might not be able to patch the FPC compiler and distribute .ppu's, but neither can you patch the Delphi compiler.

So I don't see a difference for released versions.

As long as you don't change the PPU format and the ABI, you can use and ship a patched compiler which uses e.g. the released units. A 2.4.0 or 2.4.2 compiler hacked to do delphi like temp. releasing of interface (if it doesn't require an abi change!) variables should work perfectly with plain 2.4.0/2.4.2 units.

That's not true. It's also for Free Pascal. Both are more or less handled as one product and supported.

Joost