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 the
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
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. Wh
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
> http:
On Tue, Nov 23, 2010 at 11:32 PM, Andrew Brunner
mailto:andrew.t.brun...@gmail.com>> wrote:
On Tue, Nov 23, 2010 at 1:59 PM, Max Vlasov mailto:max.vla...@gmail.com>> wrote:
Andrew,
Creating TList as a field for storing extra structures and
objects and supporting
On Tue, Nov 23, 2010 at 11:32 PM, Andrew Brunner wrote:
> On Tue, Nov 23, 2010 at 1:59 PM, Max Vlasov 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
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 th
On Tue, Nov 23, 2010 at 1:59 PM, Max Vlasov 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 by
> yourself? M
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 10:28 PM, Andrew Brunner 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 this type.
>>
>> I
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 workin
On Tue, Nov 23, 2010 at 1:20 PM, Michael Van Canneyt 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 most companies,
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 d
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 (improving/maintaining/fixing/apply
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 puz
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 it
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
func
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 sugges
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.
H
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
a
On Nov 23, 2010, at 8:43 AM, Hans-Peter Diettrich
> 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 targets.
No. The siz
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 t
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, si
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 ta
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:
http://freepascal.ru/forum/viewtopic.php
On Tue, 23 Nov 2010, Andrew Brunner wrote:
On Nov 23, 2010, at 2:27 AM, Max Vlasov wrote:
On Mon, Nov 22, 2010 at 5:13 PM, 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 design tim
On Nov 23, 2010, at 2:27 AM, Max Vlasov wrote:
>
>
> On Mon, Nov 22, 2010 at 5:13 PM, 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 design time? I mean, non-RAD
> compile
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
28 matches
Mail list logo
