On 02/14/2013 03:57 AM, Mike Salish wrote:
At the moment the 68K versions still in production are all for control
applications in embedded systems. These chips use the CPU32 and more
recently the MCF5 Coldfire architecture. For MCF there are some
sources of small and cheap demo boards (netg
On 02/15/2013 11:45 AM, Sven Barth wrote:
Nevertheless I'm currently mostly working on Coldfire support.
While this obviously is viable, I (understanding that the Coldfire ISA
is a subset of CPU32), do hope that the final version is able to
optionally work for both flavors (plus the "big" 68 K
On 02/17/2013 03:11 PM, Michel Catudal wrote:
the PIC32 is high on my list.
GREAT !
fpc really is a model of a vivid community project.
Thanks,
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/li
Can I help?
Info about good implementation of TValue -
http://www.cromis.net/blog/2013/02/tanyvalue-an-attempt-to-make-the-best-variable-data-container/
Has FPC some equivalent of invoke from rtti.pas (dynamically invoking
a methods and procedures/functions)? If not - I have my own basic
implement
Hi All,
We have developed an advanced RTTI API that replaces the Embarcadero RTTI
API and provides much more powerful and easy to use when accessing the RTTI.
We developed it as we ware running into huge number of issues and bugs when
trying to use the Embarcadero implementation, and we need
On 18.02.2013 20:30, Boian Mitov wrote:
Hi All,
We have developed an advanced RTTI API that replaces the Embarcadero
RTTI API and provides much more powerful and easy to use when accessing
the RTTI.
We developed it as we ware running into huge number of issues and bugs
when trying to use the
>
> From: Boian Mitov
>To: FPC developers' list
>Sent: Monday, February 18, 2013 4:30 PM
>Subject: Re: [fpc-devel] State of extended RTTI
>
> Hi All,
>
>We have developed an advanced RTTI API that replaces the Embarcadero RTTI API
>and provides much more power
On 18.02.2013 18:04, Maciej Izak wrote:
Can I help?
The generation of the extended RTTI data is currently missing which
needs corresponding knowledge in the compiler. And I'm also waiting for
the finishing of the attributes implementation which will pave some way
for the extended RTTI data.
Hi Sven,
It is an abstraction API that on the low side is 100% compatible with the
Delphi API, as it uses it to access the information, but on the user side
presents extremely easy to use API. It is probably better than anything
available in the world at the moment, and light years ahead of
Hi Leonardo,
At the moment we are only replacing some of the buggy parts of the catching
in the Emb. RTTI. We are also working to get it to perform faster than the
Delphi RTTI by implementing our own caching mechanisms.
With best regards,
Boian Mitov
--
On 18.02.2013 20:49, Boian Mitov wrote:
Hi Sven,
It is an abstraction API that on the low side is 100% compatible with
the Delphi API, as it uses it to access the information, but on the user
side presents extremely easy to use API. It is probably better than
anything available in the world
As example this enumerates all attributes of certain type for any public or
published member (function, field, or property) for a component:
for LMember in TRTRtti.GetType( Component.ClassType() ).GetMembers(
[mvPublic, mvPublished] ) do
for LAtrribute in LMember.GetAttributes( TMyCustomAttr
12 matches
Mail list logo
