On 22 Nov 2010, at 21:58, Den Jean wrote:
http://bugs.freepascal.org/view.php?id=17384
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
can a C-ABI expert enlight us on this ABI mess.
Does this also effect calling in general of C-functions from Free
Pascal.
Afaik, the Linux/i386 abi only
On Nov 23, 2010, at 2:27 AM, Max Vlasov max.vla...@gmail.com wrote:
On Mon, Nov 22, 2010 at 5:13 PM, michael.vancann...@wisa.be wrote:
We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - forces us
to follow suit.
Will it also create an additional confusion in
On Tue, 23 Nov 2010, Andrew Brunner wrote:
On Nov 23, 2010, at 2:27 AM, Max Vlasov max.vla...@gmail.com wrote:
On Mon, Nov 22, 2010 at 5:13 PM, michael.vancann...@wisa.be wrote:
We'll fix the issue as the upcoming Delphi 64-bit - unfortunately - forces us
to follow suit.
Will it
Hello, FPC developers' list
What can be a reason for the next error:
ld: in /usr/local/lib/fpc/2.4.2/units/i386-darwin/rtl/macpas.o,
indirect symbol index out of range ?
One user from the russian fpc board has a problem with building lazarus
on osx:
On 23 Nov 2010, at 07:29, Paul Ishenin wrote:
What can be a reason for the next error:
ld: in /usr/local/lib/fpc/2.4.2/units/i386-darwin/rtl/macpas.o,
indirect symbol index out of range ?
It's a problem with an older preview of an Apple tool chain that is
still under NDA, so I cannot
michael.vancann...@wisa.be schrieb:
The task itself is easy. The consequences of this may not be so easy:
TComponent is a basic class. Many many instances are created during the
lifetime of an application. Adding a field that adds 4/8 bytes to such a
class is something we're not eager to do,
Andrew Brunner schrieb:
That would not be an issue as Int64 is available under all flavors of FPC.
I don't see the hold up in adding a patch for Data field. There is just
one unit to change. What makes this so complicated that it hasn't be
accomplished yet???
First we have to agreee about
On Nov 23, 2010, at 8:43 AM, Hans-Peter Diettrich drdiettri...@aol.com
Components consume much space already, so what's the percentage that a 64 bit
type would add to every component, and to the app? And when the Tag type/sice
depends on the target, nothing will change unless for 64 bit
On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote:
Andrew Brunner schrieb:
That would not be an issue as Int64 is available under all flavors of FPC.
I don't see the hold up in adding a patch for Data field. There is just one
unit to change. What makes this so complicated that it hasn't be
Ok.
First off tag should be revised to match Delphi.
Second. I need data property on Tcomponent
I propose having an additional directive for this mechanism kind of like the
option for using large strings. Components have data property. This way I can
just get it into the Laz dialog.
On 23-11-2010 17:19, michael.vancann...@wisa.be wrote:
For Delphi compatibility reasons, the Tag type will be changed to PtrInt.
Michael.
As I understand it, Andrew wants just the existing tag to be changed to
64 bit, Not an additional field.
But PtrInt will do the job.
The Data field
Hello,
I am converting a couple of X11 extensions headers and I see that
xrender.pas already exists in Free Pascal, but it links the XRender
functions to libX11.so
In the systems which I tested, this is wrong and will never link.
Basically I am curious if in some kind of exotic Linux XRender
Andrew Brunner пишет:
Ok.
First off tag should be revised to match Delphi.
Second. I need data property on Tcomponent
I propose having an additional directive for this mechanism kind of like the
option for using large strings. Components have data property. This way I can
just get
Does this also effect calling in general of C-functions from Free Pascal.
Afaik, the Linux/i386 abi only mandates 4 byte stack alignment. That
means that any function requiring a higher stack alignment has to
realign the stack. That's what the new -mstackrealign gcc option does.
I am
Hi!
I've attached several patches regarding generics some time ago
(http://bugs.freepascal.org/view.php?id=15875,
http://bugs.freepascal.org/view.php?id=11777), but there was no
response regarding them. Is anyone from fpc developers working on
generics currently
On Tue, 23 Nov 2010, Sergei Gorelkin wrote:
Andrew Brunner пишет:
Ok.
First off tag should be revised to match Delphi.
Second. I need data property on Tcomponent
I propose having an additional directive for this mechanism kind of like
the option for using large strings. Components have
On Tue, Nov 23, 2010 at 1:20 PM, Michael Van Canneyt mich...@freepascal.org
wrote:
They do the same as we:
They introduced something like PtrInt (using of course a different name)
and made tag equal to this type.
Instead of biting the bullet and telling people to code properly.
But like
Am 23.11.2010 20:18, schrieb Aleksa Todorovic:
Hi!
I've attached several patches regarding generics some time ago
(http://bugs.freepascal.org/view.php?id=15875,
http://bugs.freepascal.org/view.php?id=11777), but there was no
response regarding them. Is anyone from fpc developers working on
On Tue, Nov 23, 2010 at 10:28 PM, Andrew Brunner andrew.t.brun...@gmail.com
wrote:
On Tue, Nov 23, 2010 at 1:20 PM, Michael Van Canneyt
mich...@freepascal.org wrote:
They do the same as we:
They introduced something like PtrInt (using of course a different name)
and made tag equal to
Hi,
To remain compatible with the upcoming Delphi 64-bit release, I've changed
the 'Tag' property type from Integer - PtrInt.
The practical upshot from this is that you can store a pointer in it on all
platforms.
(a widespread abuse of the Tag property).
This potentially breaks some existing
On Tue, Nov 23, 2010 at 1:59 PM, Max Vlasov max.vla...@gmail.com wrote:
Andrew,
Creating TList as a field for storing extra structures and objects and
supporting extra data reference using Tag as an index never was a problem
for me. Can you tell a single reason not to implement this approach
michael.vancann...@wisa.be escreveu:
On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote:
Andrew Brunner schrieb:
That would not be an issue as Int64 is available under all flavors
of FPC. I don't see the hold up in adding a patch for Data field.
There is just one unit to change. What makes
On Tue, Nov 23, 2010 at 11:32 PM, Andrew Brunner andrew.t.brun...@gmail.com
wrote:
On Tue, Nov 23, 2010 at 1:59 PM, Max Vlasov max.vla...@gmail.com wrote:
Andrew,
Creating TList as a field for storing extra structures and objects and
supporting extra data reference using Tag as an index
On Tue, Nov 23, 2010 at 11:32 PM, Andrew Brunner
andrew.t.brun...@gmail.com mailto:andrew.t.brun...@gmail.com wrote:
On Tue, Nov 23, 2010 at 1:59 PM, Max Vlasov max.vla...@gmail.com
mailto:max.vla...@gmail.com wrote:
Andrew,
Creating TList as a field for storing
If you create the menuItem at runtime, you can always use a sub-class,
create your own class TMyMenuItem, with a property and field to store the
data..
That is what OO is for
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Hello.
I'm trying to understand fpc's assembler's internals.
In fpcsrc/compiler/i386/cpubase.inc the enumertaion topsize is defined.
The elements S_B, S_W, S_L and S_Q correspond to byte, word, longword
and quadword. The elements S_IB, S_IW, S_IL and S_IQ also seem to
correspond to those sizes.
On Tue, 23 Nov 2010, Luiz Americo Pereira Camara wrote:
michael.vancann...@wisa.be escreveu:
On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote:
Andrew Brunner schrieb:
That would not be an issue as Int64 is available under all flavors of
FPC. I don't see the hold up in adding a patch for
Michael Van Canneyt escreveu:
On Tue, 23 Nov 2010, Luiz Americo Pereira Camara wrote:
michael.vancann...@wisa.be escreveu:
On Tue, 23 Nov 2010, Hans-Peter Diettrich wrote:
Andrew Brunner schrieb:
That would not be an issue as Int64 is available under all flavors
of FPC. I don't see
28 matches
Mail list logo
