On Thursday 10 September 2009 19:42:22 Ivo Steinmann wrote:
> Florian Klaempfl schrieb:
> > Ivo Steinmann schrieb:
> >> 1. Using =nil or Assigned should result in the same.
> >
> > Afaik not, this was one of the reasons for assigned.
> >
>
> well, nobody seems to know it... eg. if you go through c
On Sat, 12 Sep 2009 09:33:11 +0200
Martin Schreiber wrote:
> On Thursday 10 September 2009 19:42:22 Ivo Steinmann wrote:
> > Florian Klaempfl schrieb:
> > > Ivo Steinmann schrieb:
> > >> 1. Using =nil or Assigned should result in the same.
> > >
> > > Afaik not, this was one of the reasons for as
On Saturday 12 September 2009 10:07:55 Mattias Gaertner wrote:
> On Sat, 12 Sep 2009 09:33:11 +0200
>
>
> Martin, I hope you mean Data=ID and Code=nil.
>
Yup, you are right, thanks for correcting.
Martin
___
fpc-devel maillist - fpc-devel@lists.freepa
It seems the order of parameters in the RTTI is different for 2.5.1 on
x86_64.
On i386 it is still the same as 2.2.5.
I didn't find a flag telling me what order the RTTI is using.
Is this a bug, a feature, will i386 follow?
See TTypeData in unit typinfo: tkMethod
Mattias
___
On 12 Sep 2009, at 11:20, Mattias Gaertner wrote:
It seems the order of parameters in the RTTI is different for 2.5.1 on
x86_64.
On i386 it is still the same as 2.2.5.
I didn't find a flag telling me what order the RTTI is using.
Is this a bug, a feature, will i386 follow?
I guess it's beca
On Sat, 12 Sep 2009 11:25:02 +0200
Jonas Maebe wrote:
>
> On 12 Sep 2009, at 11:20, Mattias Gaertner wrote:
>
> > It seems the order of parameters in the RTTI is different for 2.5.1
> > on x86_64.
> > On i386 it is still the same as 2.2.5.
> >
> > I didn't find a flag telling me what order the
On 12 Sep 2009, at 11:49, Mattias Gaertner wrote:
On Sat, 12 Sep 2009 11:25:02 +0200
Jonas Maebe wrote:
The parameter order was simply wrong in the rtti for x86_64, afaik.
For i386, the parameter order depends on the used calling convention
(and this was used correctly for the rtti), but oth
On Sat, 12 Sep 2009 11:54:04 +0200
Jonas Maebe wrote:
>
> On 12 Sep 2009, at 11:49, Mattias Gaertner wrote:
>
> > On Sat, 12 Sep 2009 11:25:02 +0200
> > Jonas Maebe wrote:
> >
> >> The parameter order was simply wrong in the rtti for x86_64, afaik.
> >> For i386, the parameter order depends on
On 12 Sep 2009, at 12:02, Mattias Gaertner wrote:
On Sat, 12 Sep 2009 11:54:04 +0200
Jonas Maebe wrote:
Previously, the order was reversed for non-i386 platforms depending
on the calling convention. Now it should always be correct, both for
i386 and for other architectures. Or do you mean th
On Sat, 12 Sep 2009 12:14:07 +0200
Jonas Maebe wrote:
>
> On 12 Sep 2009, at 12:02, Mattias Gaertner wrote:
>
> > On Sat, 12 Sep 2009 11:54:04 +0200
> > Jonas Maebe wrote:
> >
> >> Previously, the order was reversed for non-i386 platforms depending
> >> on the calling convention. Now it should
Jonas Maebe wrote:
Where is the calling convention in the RTTI stored?
I don't think it is stored anywhere (does Delphi specify whether e.g.
register or stdcall is used?). But you shouldn't need it for the
parameter order, because depending on whether the calling convention
specifies left-to
Paul Ishenin wrote:
Just tested with D2009:
TStdcallMethod = procedure(Sender: TObject; Something: LongInt) of
object; stdcall;
If it is stdcall then methods must be listed in the rtti right-to-left
but delphi stored Sender as first and Something as second.
To prove my founds I just wrote a
On Saturday 12 September 2009 12:14:07 Jonas Maebe wrote:
>
> Or do you use this information only for display or code completion
> purposes (so you always want the parameters in left-to-right order)?
> In that case, I don't think that's possible with rtti.
>
:-(
Bad news for MSEide. MSEide uses RT
On 12 Sep 2009, at 15:10, Paul Ishenin wrote:
Paul Ishenin wrote:
Just tested with D2009:
TStdcallMethod = procedure(Sender: TObject; Something: LongInt) of
object; stdcall;
If it is stdcall then methods must be listed in the rtti right-to-
left but delphi stored Sender as first and Some
On Sat, 12 Sep 2009 16:14:05 +0200
Jonas Maebe wrote:
>
> On 12 Sep 2009, at 15:10, Paul Ishenin wrote:
>
> > Paul Ishenin wrote:
> >> Just tested with D2009:
> >>
> >> TStdcallMethod = procedure(Sender: TObject; Something: LongInt)
> >> of object; stdcall;
> >>
> >> If it is stdcall then metho
Jonas Maebe wrote:
I've checked it with Kylix 3 and there it's indeed also always the
same order. Apparently I made a mistake while testing. The FPC logic
of storing the parameters in the rtti in the same order as the calling
convention uses them dates from before my changes though. I'm not
aw
Paul Ishenin wrote:
And the best would be take the full d2010 tkMethod declaration since
it stores much more info there.
Small correction:
Every delphi stores this info (except new attributes field) but only
d2010 has the mostly full description of that info.
Best regards,
Paul Ishenin.
On Sat, 12 Sep 2009, Jonas Maebe wrote:
On 12 Sep 2009, at 15:10, Paul Ishenin wrote:
Paul Ishenin wrote:
Just tested with D2009:
TStdcallMethod = procedure(Sender: TObject; Something: LongInt) of object;
stdcall;
If it is stdcall then methods must be listed in the rtti right-to-left b
Hello FPC Developers.
With the recent discussion of "what new fpc feature students can
implement" (at lazarus mailling list), I've followed the given link:
http://edn.embarcadero.com/article/34324
Do understand things right? Delphi (.net?) class helpers are very
close to objective-C categories,
In our previous episode, dmitry boyarintsev said:
>
> Do understand things right? Delphi (.net?) class helpers are very
> close to objective-C categories, for the expection, that helpers can
> also add additional members and properties. While categories are
> allowed to add new methods only?
As
On 12 Sep 2009, at 18:00, dmitry boyarintsev wrote:
Do understand things right? Delphi (.net?) class helpers are very
close to objective-C categories, for the expection, that helpers can
also add additional members and properties.
Can they really add new fields? (I guess that's what you mean
What's the current situation with armel? I've got the armel-generating
2.3.1 (I think from Florian) but I can't complete a "make all"- it barfs
during cycle 2.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
__
On 12 Sep 2009, at 18:58, Mark Morgan Lloyd wrote:
What's the current situation with armel?
I think the latest svn should work fine (both trunk and fixes_2_4).
I've got the armel-generating 2.3.1 (I think from Florian) but I
can't complete a "make all"- it barfs during cycle 2.
If that's
Martin Schreiber schrieb:
> On Saturday 12 September 2009 12:14:07 Jonas Maebe wrote:
>
>> Or do you use this information only for display or code completion
>> purposes (so you always want the parameters in left-to-right order)?
>> In that case, I don't think that's possible with rtti.
>>
> :-(
>
Florian Klaempfl wrote:
Fill a bug report so we can implement a D2010 compatible solution
http://bugs.freepascal.org/view.php?id=14573
Best regards,
Paul Ishenin.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/ma
Jonas Maebe wrote:
On 12 Sep 2009, at 18:58, Mark Morgan Lloyd wrote:
What's the current situation with armel?
I think the latest svn should work fine (both trunk and fixes_2_4).
I've got the armel-generating 2.3.1 (I think from Florian) but I can't
complete a "make all"- it barfs during cy
26 matches
Mail list logo
