On Wed, 10 Nov 2010, Dimitrios Chr. Ioannidis wrote:
Στις 10/11/2010 3:01 μμ, ο/η Michael Van Canneyt έγραψε:
On Wed, 10 Nov 2010, Martin Schreiber wrote:
On Wednesday, 10. November 2010 11.24:52 Michael Van Canneyt wrote:
Nowhere is the Delphi behaviour guaranteed, not even by Delphi.
On Thu, 11 Nov 2010, 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
Hi,
what code style does fpc have?
There is a lot of inconsistency in the units, for example the
assembler units with "tai" in lower case everything and in other rtl
units a clear camel case..
Is there a style guideline? (link)
thanks
___
fpc-dev
On 10.11.2010 21:52, Vincent Snijders wrote:
2010/11/10 Sven Barth:
On 10.11.2010 21:39, Sven Barth wrote:
I'll update to today's trunk version.
Also no error. Would you please send the compiler's output?
Maybe a different mode switch? Add {$mode delphi} to the source?
Same (successful)
2010/11/10 Sven Barth :
> On 10.11.2010 21:39, Sven Barth wrote:
>>
>> I'll update to today's trunk version.
>
> Also no error. Would you please send the compiler's output?
>
Maybe a different mode switch? Add {$mode delphi} to the source?
Vincent
___
f
On 10.11.2010 21:39, Sven Barth wrote:
I'll update to today's trunk version.
Also no error. Would you please send the compiler's output?
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listi
On 10.11.2010 21:20, Thaddy wrote:
Small example, 2.5.1 trunk from today
---
program Project2;
{$APPTYPE CONSOLE}
uses windows;
{$DEFINE SHOULD_COMPILE_IN_FPC } // add dot after "{"
{$IFDEF SHOULD_COMPILE_IN_FPC}
type
PPValueA = ^TPValueA;
PPValue = PPValueA;
pvalueA = packed record
pv_valuen
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
Στις 10/11/2010 3:01 μμ, ο/η Michael Van Canneyt έγραψε:
On Wed, 10 Nov 2010, Martin Schreiber wrote:
On Wednesday, 10. November 2010 11.24:52 Michael Van Canneyt wrote:
Nowhere is the Delphi behaviour guaranteed, not even by Delphi.
Well, I can always argue that FPC tries to clone/mimic
Small example, 2.5.1 trunk from today
---
program Project2;
{$APPTYPE CONSOLE}
uses windows;
{$DEFINE SHOULD_COMPILE_IN_FPC } // add dot after "{"
{$IFDEF SHOULD_COMPILE_IN_FPC}
type
PPValueA = ^TPValueA;
PPValue = PPValueA;
pvalueA = packed record
pv_valuename: PAnsiChar;
Is this a documented issue or should I submit a bugreport?
Can you please provide an example? The following code compiles for
2.4.0, 2.4.2rc1 and 2.5.1 (from the weekend):
Regards,
Sven
I will try to isolate it. kol.pas is a little fat bastard :)
_
On 10.11.2010 19:46, Thaddy wrote:
Hi,
When I was adapting KOL for 2.5.1 (trunk) I noticed a delphi
incompatibility:
PSomeType = ^TMySomeType;
TMySomeType = tagSometype;
This doesn't compile. I have to change this to
TMySomeType = tagSometype;
PSomeType = ^TMySomeType;
It potentially breaks
Hi,
When I was adapting KOL for 2.5.1 (trunk) I noticed a delphi
incompatibility:
PSomeType = ^TMySomeType;
TMySomeType = tagSometype;
This doesn't compile. I have to change this to
TMySomeType = tagSometype;
PSomeType = ^TMySomeType;
It potentially breaks a lot of code that is syntacticall
On Wed, 10 Nov 2010, Martin wrote:
As for the argument: it's not a feature, it's a bug:
- A bug is if software doe not behave as documented.
- FPC documents that you can not make any assumption when an interface is
released.
But it IS documented since a long time:
See the section 'Ref
Hi,
Please take this discussion to the fpc-other list, where it belongs.
Thanks,
Jonas
FPC mailing lists admin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
On Wed, Nov 10, 2010 at 9:13 AM, Graeme Geldenhuys
wrote:
> Maybe this little fact should be made public, and very clear on the front
> page of the FPC website. This will ensure no commercial entity will ever
> fall foolishly into the FPC trap. This will obviously benefit the FPC team
> too, becau
On 10/11/2010 15:13, Graeme Geldenhuys wrote:
Original Message
Subject: Interface scope incompatibility with Delphi
Date: Wed, 10 Nov 2010 16:57:13 +0200
Op 2010-11-10 15:01, Michael Van Canneyt het geskryf:
This is open source: essentially a hobby project for us.
[not direc
On Wed, 10 Nov 2010, Graeme Geldenhuys wrote:
Original Message
Subject: Interface scope incompatibility with Delphi
Date: Wed, 10 Nov 2010 16:57:13 +0200
Op 2010-11-10 15:01, Michael Van Canneyt het geskryf:
This is open source: essentially a hobby project for us.
[not
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 ot
Am 10.11.2010 16:13, schrieb Graeme Geldenhuys:
>
>
> Original Message
> Subject: Interface scope incompatibility with Delphi
> Date: Wed, 10 Nov 2010 16:57:13 +0200
>
> Op 2010-11-10 15:01, Michael Van Canneyt het geskryf:
>>
>> This is open source: essentially a hobby project
On 10 November 2010 15:13, Graeme Geldenhuys wrote:
>
>
> Original Message
> Subject: Interface scope incompatibility with Delphi
> Date: Wed, 10 Nov 2010 16:57:13 +0200
>
> Op 2010-11-10 15:01, Michael Van Canneyt het geskryf:
>>
>> This is open source: essentially a hobby proje
Original Message
Subject: Interface scope incompatibility with Delphi
Date: Wed, 10 Nov 2010 16:57:13 +0200
Op 2010-11-10 15:01, Michael Van Canneyt het geskryf:
>
> This is open source: essentially a hobby project for us.
[not directed specifically to you as a person, just th
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
10.11.2010 18:04, Jonas Maebe wrote:
Is there a way to make it dump the constructor crash as well (maybe
before calling destroy)?
By adding your own try/except code and manually dumping the backtrace.
As I remember D2007 has a new feature to store inner exception inside
the try-except block.
If a constructor crashes, the the object that it was constructing will
be destroyed. (fpc inserts an exception frame to ensure that).
So far so good, all correct.
But if the destructor (e.g Destroy) also crashes, then if you have -gl
it will dump the stack for the destructor.
The stack for th
On Wednesday, 10. November 2010 11.24:52 Michael Van Canneyt wrote:
>
> >> 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
> > compatib
On 10 Nov 2010, at 11:42, 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 a
On 30 Oct 2010, at 13:20, Matthias K. wrote:
the last days I've done a first step in Porting the i386 data flow
analyzer, asmcse and peephole optimizations.
Quite impressive!
Main motivation is: target instruction level optimization is always a
good thing especially for bottlenecks.
That
On 10 November 2010 10:26, Graeme Geldenhuys wrote:
>
> 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. ;-)
If y
Op 2010-11-10 12:24, Michael Van Canneyt het geskryf:
>
> 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.
I'm still searching the archives. Mind you tell me what w
On Wed, 10 Nov 2010, Martin Schreiber wrote:
On Wednesday, 10. November 2010 11.24:52 Michael Van Canneyt wrote:
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 des
On 10 Nov 2010, at 12:00, Martin wrote:
But if the destructor (e.g Destroy) also crashes, then if you have -
gl it will dump the stack for the destructor.
The stack for the constructor is never dumped at all.
That's because backtraces are only dumped when an exception is not
caught. Otherw
Am 10.11.2010 12:09, schrieb Martin Schreiber:
> On Wednesday, 10. November 2010 11.24:52 Michael Van Canneyt wrote:
>>
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
In our previous episode, Graeme Geldenhuys said:
> > 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.
>
> I'm still searching the archives. Mind you tell me wh
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 o
On Wed, 10 Nov 2010, Graeme Geldenhuys wrote:
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
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 i
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 -
--
fpGUI Toolki
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 -
--
fpGUI Toolkit - a cross-platform GUI toolki
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/C
On Wed, 10 Nov 2010, Graeme Geldenhuys wrote:
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 cur
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
___
fpc-devel maillist - fpc-devel@lists.freepas
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. B
On 10 Nov 2010, at 11:40, Graeme Geldenhuys wrote:
I'm still searching the archives.
mail-archive.com is currently not responding for me, but the thread is
here: http://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg11126.html
(it will probably come back online later today).
The
On 10 Nov 2010, at 11:32, Micha Nelissen wrote:
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 [snip]
That sort of remarks are not welcome on the FPC lists. I
Am 10.11.2010 10:42, schrieb Graeme Geldenhuys:
> 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 immediate
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 no
On Wed, 10 Nov 2010, Graeme Geldenhuys wrote:
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 understa
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 co
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
50 matches
Mail list logo
