Are you sure this would make things easier? Code in the handler needs
to be thread safe. Starting a thread is very easy, with TThread?
If you use common resources of course you do need to take create to do
it in a thread save way.
But if you want to off-load some kind of work to one or more
Michael Schnell wrote:
programmed like that using a thread it defines) but uses a thread the
program that sets the handler property defines ? Here the programmer
does not need to write code that passes the parameters to the thread:
the RTL does all this dirty stuff, helping less advanced progra
Hello, fpc-developer list.
As "Events" (i.e callbacks at the time being) are syntactically done as
properties, could it be possible that property attributes on the long
run could help implementing "thread Events" (i.e. a class "fires" an
event not as a callback (usually using a the main thread
Florian Klaempfl wrote:
Mattias Gaertner schrieb:
On Sun, 21 Oct 2007 08:36:24 +0200 (CEST)
Daniël Mantione <[EMAIL PROTECTED]> wrote:
Op Sun, 21 Oct 2007, schreef Michael Van Canneyt:
.ppu file format is something so general and
commonly used by (Free) Pascal programmers that
it should bec
Mattias Gaertner wrote:
On Sun, 21 Oct 2007 21:55:45 +0800
Paul Ishenin <[EMAIL PROTECTED]> wrote:
Florian Klaempfl wrote:
Only that the codetools can not use a ppureader.ppu from the RTL or
FCL. It can use the ppureader.pas, but not the .ppu.
Or use the XML approach as Florian
On Sun, 21 Oct 2007 21:55:45 +0800
Paul Ishenin <[EMAIL PROTECTED]> wrote:
> Florian Klaempfl wrote:
> >> Only that the codetools can not use a ppureader.ppu from the RTL or
> >> FCL. It can use the ppureader.pas, but not the .ppu.
> >> Or use the XML approach as Florian
> >>
> >
> > I sugges
Florian Klaempfl wrote:
Only that the codetools can not use a ppureader.ppu from the RTL or
FCL. It can use the ppureader.pas, but not the .ppu.
Or use the XML approach as Florian
I suggested :) Paul didn't like it that much
He started also a wiki page: http://wiki.freepascal.org/Property
One way to read .ppu files from multiple compiler versions would be a "ppu
meta file", which describes the fields written for each sym and def. The
will be one meta file per ppu version. An IDE or tool that wants to read
a ppu then processes the meta file for the ppu version to know how to find
Mattias Gaertner schrieb:
> On Sun, 21 Oct 2007 14:22:30 +0200 (CEST)
> Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
>> [...]
Well, the ppu file is divided in blocks; Each block has a type
and a size. If you don't "know" a block, you can 'skip' it.
(If memory serves me right, of
On Sun, 21 Oct 2007 14:22:30 +0200 (CEST)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>[...]
> > > Well, the ppu file is divided in blocks; Each block has a type
> > > and a size. If you don't "know" a block, you can 'skip' it.
> > > (If memory serves me right, of course)
> >
> > If the codeto
On Sun, 21 Oct 2007, Florian Klaempfl wrote:
> >>
> >> If the arrayoptions for example becomes a large set (>32 elements), an
> >> old version that will try to read a new version will read too little
> >> data. We will of course bump the ppu version, so the compile refuses
> >> old ppus.
> >
On Sun, 21 Oct 2007, Mattias Gaertner wrote:
> On Sun, 21 Oct 2007 01:43:51 +0200 (CEST)
> Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Sun, 21 Oct 2007, Mattias Gaertner wrote:
> >
> > > On Sun, 21 Oct 2007 00:46:19 +0200 (CEST)
> > > Michael Van Canneyt <[EMAIL PROTECTED
Op Sun, 21 Oct 2007, schreef Mattias Gaertner:
> On Sun, 21 Oct 2007 08:36:24 +0200 (CEST)
>
> Is the newer ppureader be able to read older ppu?
> In other words: Does a current ppureader contains the code to read the
> old format too?
No, the read code is similar to the write code, no version
Mattias Gaertner schrieb:
> On Sun, 21 Oct 2007 08:36:24 +0200 (CEST)
> Daniël Mantione <[EMAIL PROTECTED]> wrote:
>
>>
>> Op Sun, 21 Oct 2007, schreef Michael Van Canneyt:
>>
> .ppu file format is something so general and
> commonly used by (Free) Pascal programmers that
> it should
On Sun, 21 Oct 2007 08:36:24 +0200 (CEST)
Daniël Mantione <[EMAIL PROTECTED]> wrote:
>
>
> Op Sun, 21 Oct 2007, schreef Michael Van Canneyt:
>
> > > > .ppu file format is something so general and
> > > > commonly used by (Free) Pascal programmers that
> > > > it should become part of our RTL.
On Sun, 21 Oct 2007 01:43:51 +0200 (CEST)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
>
> On Sun, 21 Oct 2007, Mattias Gaertner wrote:
>
> > On Sun, 21 Oct 2007 00:46:19 +0200 (CEST)
> > Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > > On Sat, 20 Oct 2007, Mattias Ga
Op Sun, 21 Oct 2007, schreef Mattias Gaertner:
> Coming back to the real problem:
> Searching and reading the ppu is as expensive as reading the sources or
> reading the fpdoc xml files. So, there is no need to put the property
> information into the ppu - except for closed sources.
ppu's are
Op Sun, 21 Oct 2007, schreef Michael Van Canneyt:
> > > .ppu file format is something so general and
> > > commonly used by (Free) Pascal programmers that
> > > it should become part of our RTL.
> >
> > And another:
> > A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x.
>
On Sun, 21 Oct 2007, Mattias Gaertner wrote:
> On Sun, 21 Oct 2007 00:46:19 +0200 (CEST)
> Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > On Sat, 20 Oct 2007, Mattias Gaertner wrote:
> >
> > > On Sat, 20 Oct 2007 16:29:40 +0200
> > > "Tomas Hajny" <[EMAIL PROTECTED]> wrote:
> >
On Sun, 21 Oct 2007 00:46:19 +0200 (CEST)
Michael Van Canneyt <[EMAIL PROTECTED]> wrote:
>
>
> On Sat, 20 Oct 2007, Mattias Gaertner wrote:
>
> > On Sat, 20 Oct 2007 16:29:40 +0200
> > "Tomas Hajny" <[EMAIL PROTECTED]> wrote:
> >
> > > On 19 Oct 07, at 13:14, Micha Nelissen wrote:
> > > > Jona
On Sat, 20 Oct 2007, Mattias Gaertner wrote:
> On Sat, 20 Oct 2007 16:29:40 +0200
> "Tomas Hajny" <[EMAIL PROTECTED]> wrote:
>
> > On 19 Oct 07, at 13:14, Micha Nelissen wrote:
> > > Jonas Maebe wrote:
> > > > This is not true. You can perfectly compile a compiler using the
> > > > previous' r
On Sat, 20 Oct 2007 23:55:31 +0200 (CEST)
Daniël Mantione <[EMAIL PROTECTED]> wrote:
>
>
> Op Sat, 20 Oct 2007, schreef Mattias Gaertner:
>
> > And another:
> > A lazarus built with fpc 2.0.4 should be able to read the ppu of
> > 2.3.x. Even though the ppu format is very stable, it is not carve
Op Sat, 20 Oct 2007, schreef Mattias Gaertner:
> And another:
> A lazarus built with fpc 2.0.4 should be able to read the ppu of 2.3.x.
> Even though the ppu format is very stable, it is not carved in stone.
> So, maybe it would be best to keep a working copy of the ppu reader
> unit in the laza
On Sat, 20 Oct 2007 16:29:40 +0200
"Tomas Hajny" <[EMAIL PROTECTED]> wrote:
> On 19 Oct 07, at 13:14, Micha Nelissen wrote:
> > Jonas Maebe wrote:
> > > This is not true. You can perfectly compile a compiler using the
> > > previous' release rtl.
> >
> > Sure this is not the question.
> >
> >
On 19 Oct 07, at 13:14, Micha Nelissen wrote:
> Jonas Maebe wrote:
> > This is not true. You can perfectly compile a compiler using the
> > previous' release rtl.
>
> Sure this is not the question.
>
> > E.g. the people developing using the fp IDE often
> > do this (because they have a project
On 19 Oct 2007, at 13:14, Micha Nelissen wrote:
Jonas Maebe wrote:
This is not true. You can perfectly compile a compiler using the
previous' release rtl.
Sure this is not the question.
It is the question because this is actually done by several people.
E.g. the people developing using t
Jonas Maebe wrote:
This is not true. You can perfectly compile a compiler using the
previous' release rtl.
Sure this is not the question.
E.g. the people developing using the fp IDE often
do this (because they have a project for the compiler, but that one does
not automatically compile the
> Is there anything to be compatible with?
Yes, that is syntax used by Delphi.Net
>Does Delphi/win32 use this in any way?
No, but if someday Delphi/win32 has to support attributes it will
certainly use the same syntax
and FPC will be ready.
--
Inoussa O.
___
On 19 Oct 2007, at 11:21, Micha Nelissen wrote:
Jonas Maebe wrote:
On 19 Oct 2007, at 11:00, Micha Nelissen wrote:
Elaborate please ? You mean debugging of the compiler, but don't
you always work on new compilers ? When debugging, you could copy
the ppu to the "old" RTL if you're using an
Jonas Maebe wrote:
On 19 Oct 2007, at 11:00, Micha Nelissen wrote:
Elaborate please ? You mean debugging of the compiler, but don't you
always work on new compilers ? When debugging, you could copy the ppu
to the "old" RTL if you're using an old RTL with a new compiler ?
My global install of
On 19 Oct 2007, at 11:00, Micha Nelissen wrote:
Jonas Maebe wrote:
It's not a good idea to make the compiler dependent on features
not available in the RTL of the previous release, as this can
complicate debugging quite a bit.
Elaborate please ? You mean debugging of the compiler, but don
Jonas Maebe wrote:
It's not a good idea to make the compiler dependent on features not
available in the RTL of the previous release, as this can complicate
debugging quite a bit.
Elaborate please ? You mean debugging of the compiler, but don't you
always work on new compilers ? When debugging
On Fri, 19 Oct 2007, Jonas Maebe wrote:
>
> On 19 Oct 2007, at 10:28, Micha Nelissen wrote:
>
> >Michael Van Canneyt wrote:
> > >Well, the unit is in the compiler directory, and is not meant for
> > >distribution.
> > >It can only be in the compiler directory, otherwise it's impossible to
> >
On 19 Oct 2007, at 10:28, Micha Nelissen wrote:
Michael Van Canneyt wrote:
Well, the unit is in the compiler directory, and is not meant for
distribution.
It can only be in the compiler directory, otherwise it's
impossible to bootstrap the compiler (i.e. compile the compiler
the first tim
Michael Van Canneyt wrote:
Well, the unit is in the compiler directory, and is not meant for distribution.
It can only be in the compiler directory, otherwise it's impossible to bootstrap
the compiler (i.e. compile the compiler the first time).
The RTL is always compiled before the compiler is
> > But IMHO, if a new langage feature have to be introduced,
> > a feature already implemented in Delphi, it will be good
> > to make it compatible. Mainly for code sharing.
> >
> There already is a Delphi compatibility compiler switch. There could be
> a Delphi.NET (and maybe a Chrome) comp
But IMHO, if a new langage feature have to be introduced,
a feature already implemented in Delphi, it will be good
to make it compatible. Mainly for code sharing.
There already is a Delphi compatibility compiler switch. There could be
a Delphi.NET (and maybe a Chrome) compatibility compile
On Fri, 19 Oct 2007, Paul Ishenin wrote:
> Michael Van Canneyt wrote:
>
>
> > > Ok, no problem - lets it be ppu. We only need some way of accessing that
> > > data.
> > > Is ppu reading methods already exists in RTL or another fpc package?
> > >
> >
> > The ppu unit does what you need. I
Marco van de Voort wrote:
function func:integer; cdecl;
Most of the time yes, sometime no like the following :
procedure proc( CONST AParametter : integer );
IMHO this time, Delphi compatibility is a very strong point.
Is there anything to be compatible with? Does Delphi/win32 us
> > function func:integer; cdecl;
> Most of the time yes, sometime no like the following :
>
> procedure proc( CONST AParametter : integer );
>
> IMHO this time, Delphi compatibility is a very strong point.
Is there anything to be compatible with? Does Delphi/win32 use this in any
way?
_
On 10/18/07, Inoussa OUEDRAOGO <[EMAIL PROTECTED]> wrote:
>
> > It is a strong point.
> >
> > On the other hard keeping the language clean is an important responsible
> > task we have. We never planned to be compatible with Delphi.NET. (I have
> > never considered Delphi.NET a real Pascal implement
> It is a strong point.
>
> On the other hard keeping the language clean is an important responsible
> task we have. We never planned to be compatible with Delphi.NET. (I have
> never considered Delphi.NET a real Pascal implementation; it departs
> rather far from what Wirth designed). While .NET f
Michael Van Canneyt wrote:
Ok, no problem - lets it be ppu. We only need some way of accessing that data.
Is ppu reading methods already exists in RTL or another fpc package?
The ppu unit does what you need. It is used by the compiler and dumppu program
provided by FPC. Maybe we should
Marco van de Voort wrote:
These idiots had to do it totally against the Pascal Language specs.
This is not Pascal language anymore. This is Delphi language.
Delphi or Delphi.NET? Does native Delphi do more with it than ignore it?
Delphi.net in this case.
(like the dotted unit names introdu
Op Thu, 18 Oct 2007, schreef Inoussa OUEDRAOGO:
> > function func:integer; cdecl;
> Most of the time yes, sometime no like the following :
>
> procedure proc( CONST AParametter : integer );
>
> IMHO this time, Delphi compatibility is a very strong point.
It is a strong point.
On the other ha
> function func:integer; cdecl;
Most of the time yes, sometime no like the following :
procedure proc( CONST AParametter : integer );
IMHO this time, Delphi compatibility is a very strong point.
--
Inoussa O.
___
fpc-devel maillist - fpc-devel@lists
> > property TransactionModel: TTransactionModel read FtransactionModel
> > write SetTransactionModel attribute Engines: List =
> > 'firebird,oracle,sybase-asa';
> >
> > much more logical ?
>
> As attributes is meant to be used with allmost any construct( class,
> field, property, method
> o
> Michael Van Canneyt wrote:
> >
> > On Thu, 18 Oct 2007, Inoussa OUEDRAOGO wrote:
> >
> >>> how is [...] coupled to TransactionModel ?
> >>> Just because it happens to be declared the line in front of it ?
> >> Yes, the attribute declaration is placed imediately prior to the
> >> element it app
> property TransactionModel: TTransactionModel read FtransactionModel
> write SetTransactionModel attribute Engines: List =
> 'firebird,oracle,sybase-asa';
>
> much more logical ?
As attributes is meant to be used with allmost any construct( class,
field, property, method
orprocedure paramet
Micha Nelissen wrote:
Inoussa OUEDRAOGO wrote:
so the sample code becomes ( using Delphi's attribute syntax )
TxxxDatabase = class(...)
...
[Engines(List='firebird,oracle,sybase-asa')]
property TransactionModel: TTransactionModel read FtransactionModel
On Thu, 18 Oct 2007, Micha Nelissen wrote:
> Inoussa OUEDRAOGO wrote:
> > so the sample code becomes ( using Delphi's attribute syntax )
> >
> > TxxxDatabase = class(...)
> > ...
> > [Engines(List='firebird,oracle,sybase-asa')]
> > property TransactionModel: TTransactionModel read FtransactionM
Inoussa OUEDRAOGO wrote:
> so the sample code becomes ( using Delphi's attribute syntax )
>
> TxxxDatabase = class(...)
> ...
> [Engines(List='firebird,oracle,sybase-asa')]
> property TransactionModel: TTransactionModel read FtransactionModel
> write Set
Michael Van Canneyt wrote:
On Thu, 18 Oct 2007, Inoussa OUEDRAOGO wrote:
how is [...] coupled to TransactionModel ?
Just because it happens to be declared the line in front of it ?
Yes, the attribute declaration is placed imediately prior to the
element it applies to.
Example at
http://hall
On Thu, 18 Oct 2007, Inoussa OUEDRAOGO wrote:
> > how is [...] coupled to TransactionModel ?
> > Just because it happens to be declared the line in front of it ?
>
> Yes, the attribute declaration is placed imediately prior to the
> element it applies to.
> Example at
> http://hallvards.blogs
Another usage sample at http://dn.codegear.com/article/36962
In the document, the "[ServiceContract]" is used by the .Net runtime
to define service
interface( see bellow ).
type
[ServiceContract]
ISimpleCalc = interface
[OperationContract]
function Add(a, b: integer): integer;
[
> how is [...] coupled to TransactionModel ?
> Just because it happens to be declared the line in front of it ?
Yes, the attribute declaration is placed imediately prior to the
element it applies to.
Example at
http://hallvards.blogspot.com/2007/09/dn4dp14-net-only-attributes-support.html
--
I
Inoussa OUEDRAOGO wrote:
so the sample code becomes ( using Delphi's attribute syntax )
TxxxDatabase = class(...)
...
[Engines(List='firebird,oracle,sybase-asa')]
property TransactionModel: TTransactionModel read FtransactionModel
write SetTransactionM
so the sample code becomes ( using Delphi's attribute syntax )
TxxxDatabase = class(...)
...
[Engines(List='firebird,oracle,sybase-asa')]
property TransactionModel: TTransactionModel read FtransactionModel
write SetTransactionModel;
...
end;
--
Inoussa
On 10/18/07, Flávio Etrusco <[EMAIL PROTECTED]> wrote:
> The only downside to is that it'll probably be necessary to keep some
> duplicated parser code...
Actually code tools should already have all parsing capability necessary
--
Felipe Monteiro de Carvalho
Getting these informations at runtime is definitely a _powerful_
_feature_, it's no more than
.Net's attributes or java's annotations.
Their generation could be activated by a compiler switch like the RTTI
{$M+} and {$M-} so in debug mode it will be activated for the LCL code
and deactivated in re
Felipe Monteiro de Carvalho wrote:
Maybe:
procedure MethodX; {%widgetsets win32 wince}
This should be quicker and easier to implement then extending the ppu files.
yeah, and then we compile the source and poof, gone.
lazarus doesn't want to parse the sourcefiles forever, eventually we
will u
(...)
>
> Maybe:
>
> procedure MethodX; {%widgetsets win32 wince}
>
> This should be quicker and easier to implement then extending the ppu
> files.
>
> thanks,
> --
> Felipe Monteiro de Carvalho
>
Amen, brother Felipe ;-)
The only downside to is that it'll probably be necessary to keep some
dupl
Felipe Monteiro de Carvalho wrote:
On 10/18/07, Paul Ishenin <[EMAIL PROTECTED]> wrote:
The bad thing that this will not work. I am developer Felipe, not
technical writer. I dont know how to write helps and moreover I will not
write them.
I actually consider that what you wish to achie
On 10/18/07, Paul Ishenin <[EMAIL PROTECTED]> wrote:
> The bad thing that this will not work. I am developer Felipe, not
> technical writer. I dont know how to write helps and moreover I will not
> write them.
I actually consider that what you wish to achieve *is* documentation.
You desire to pass
Felipe Monteiro de Carvalho wrote:
One simple idea I just had is that this could be added to the
documentation. The IDE can look at the docs and show whatever is
needed for each different property on each class. The downside is that
the component would require docs in the same format as the lcl/r
On Thu, 18 Oct 2007, Paul Ishenin wrote:
> Michael Van Canneyt wrote:
> > On Thu, 18 Oct 2007, Paul Ishenin wrote:
> >
> >
> > > Hello, fpc-developer list.
> > >
> > > Some time ago I posted here proposal to extend platform keyword. You gave
> > > a
> > > hostile reception to that proposal.
>
One simple idea I just had is that this could be added to the
documentation. The IDE can look at the docs and show whatever is
needed for each different property on each class. The downside is that
the component would require docs in the same format as the lcl/rtc/fcl
ones, althougth that shouldn't
Michael Van Canneyt wrote:
On Thu, 18 Oct 2007, Paul Ishenin wrote:
Hello, fpc-developer list.
Some time ago I posted here proposal to extend platform keyword. You gave a
hostile reception to that proposal.
Later Florian in private conversation with me suggested better idea of
property att
On Thu, 18 Oct 2007, Paul Ishenin wrote:
> Hello, fpc-developer list.
>
> Some time ago I posted here proposal to extend platform keyword. You gave a
> hostile reception to that proposal.
>
> Later Florian in private conversation with me suggested better idea of
> property attributes. Indeed,
On Thursday 18 October 2007 12:55, Michael Schnell wrote:
> > I think it is better to send a RTF document than a ODT document:
> > * it is smaller
> > * more programs can read it
> > * no need to download and install plug-ins for a seizable minority
> > of people without open office or ODT-plug-in
On Thu, 18 Oct 2007, Vincent Snijders wrote:
> Michael Schnell schreef:
> >
> > > I bet you those two are MS Office users [..ducking and hiding..]
> > >
> > Should be no problem at all.
> > AFAIK (I'm not an MS-Office user :-) ), there is a free plugin that enables
> > even M$-Office to rea
Michael Schnell schreef:
I think it is better to send a RTF document than a ODT document:
* it is smaller
* more programs can read it
* no need to download and install plug-ins for a seizable minority of
people without open office or ODT-plug-in installed.
Valid considerations, but regarding t
I think it is better to send a RTF document than a ODT document:
* it is smaller
* more programs can read it
* no need to download and install plug-ins for a seizable minority of
people without open office or ODT-plug-in installed.
Valid considerations, but regarding this, PDF is a much better
Michael Schnell schreef:
I bet you those two are MS Office users [..ducking and hiding..]
Should be no problem at all.
AFAIK (I'm not an MS-Office user :-) ), there is a free plugin that
enables even M$-Office to read and write standard conform files (i.e.
Open Document ODT).
I think i
I bet you those two are MS Office users [..ducking and hiding..]
Should be no problem at all.
AFAIK (I'm not an MS-Office user :-) ), there is a free plugin that
enables even M$-Office to read and write standard conform files (i.e.
Open Document ODT).
-Michael
__
On 18/10/2007, Paul Ishenin <[EMAIL PROTECTED]> wrote:
> Michael Schnell пишет:
> > > odt is not well known format
> >
> > Open Document format is an ISO standard.
>
> yes, I know, but at least two developers complained about it, so rtf for
> those who have no OpenOffice.
To those two developers
Michael Schnell пишет:
> odt is not well known format
Open Document format is an ISO standard.
yes, I know, but at least two developers complained about it, so rtf for
those who have no OpenOffice.
Best regards,
Paul Ishenin.
___
fpc-devel mail
> odt is not well known format
Open Document format is an ISO standard. (That is why Microsoft's "Open
XML" hopefully will not be accepted as a concurrent "standard" for the
same purpose.)
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepasc
Marc Weustink пишет:
Micha Nelissen wrote:
Graeme Geldenhuys wrote:
VB) it showed a description of that property. As far as I remember
that description was part of the class definition - Delphi never
supported something like that.
I don't think you want to carry around complete property descr
Micha Nelissen wrote:
Graeme Geldenhuys wrote:
VB) it showed a description of that property. As far as I remember
that description was part of the class definition - Delphi never
supported something like that.
I don't think you want to carry around complete property descriptions in
your final
Micha Nelissen пишет:
Graeme Geldenhuys wrote:
VB) it showed a description of that property. As far as I remember
that description was part of the class definition - Delphi never
supported something like that.
I don't think you want to carry around complete property descriptions in
your final
Graeme Geldenhuys wrote:
VB) it showed a description of that property. As far as I remember
that description was part of the class definition - Delphi never
supported something like that.
I don't think you want to carry around complete property descriptions in
your final executables ;-).
Mic
On 18/10/2007, Paul Ishenin <[EMAIL PROTECTED]> wrote:
>
> Later Florian in private conversation with me suggested better idea of
> property attributes. Indeed, attributes are more general solution than
> platform keyword.
That's a very interesting idea. I can see many uses for it,
especially if
Paul Ishenin wrote:
Attached file (open document format can be opened by OpenOffice)
contains proposed syntax diagrams and declaration examples.
Sorry, seems odt is not well known format but hope rtf is :(
In attach same file in rtf.
Best regards,
Paul Ishenin.
property_attributes.rtf
Descr
Hello, fpc-developer list.
Some time ago I posted here proposal to extend platform keyword. You
gave a hostile reception to that proposal.
Later Florian in private conversation with me suggested better idea of
property attributes. Indeed, attributes are more general solution than
platform ke
85 matches
Mail list logo