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
> Therefore, an exceptionless "strtoint" is not a drop in replacement, you =
>
> need to recode your error handling. If you do so you can just as well =
>
> replace it by val.
If you first start off using compactsysutils, the error checking will still work
if you upgrade to using sysutils. Therefo
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
On 18 Oct 2007, at 16:17, mm wrote:
The inlined code shouldn't be much bigger than the calls to "Odd
()". So,
why aren't they inlined? Is there a reason you did so?
It's because the Odd function is an assembler function, and the
compiler can't yet inline assembler functions. I guess this s
Hello,
Contrary to Delphi, FPC doesn't inline the "Odd()" functions. I agree
this is not very important for most programs but this is annoying for
'math' programs. A few months ago, I re-started to work on my NX library
and currently, just because FPC doesn't inline "Odd()", its code is
stuffed w
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
"The Thumb code requires 70 % of space of the ARM code.
The Thumb code uses 40 % more instructions than the ARM code.
With 32-bit memory, the ARM code is 40 % faster than the Thumb code.
With 16-bit memory, the Thumb code is 45 % faster than the ARM code.
Thumb code uses 30 % less external m
Even worse. Thumb is completely different instruction set with
different number of registers. Completely new code generator is needed
for thumb.
That is why no Linux Kernel for thumb code exists and thus the new "pure
Thumb" Cortex M processors can't run Linux yet.
-Michael
___
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,
Felipe Monteiro de Carvalho wrote:
Acording to the nokia wiki using thumb would be produce smaller and
faster code on the majority of mobiles, so it may be useful to see of
just for more information:
"The Thumb code requires 70 % of space of the ARM code.
The Thumb code uses 40 % more instru
From: "Daniël Mantione" <[EMAIL PROTECTED]>
Op Wed, 17 Oct 2007, schreef Felipe Monteiro de Carvalho:
> so it may be useful to see of
> we can easely support thumb. Since we always use an external
> assembler
> for arm, I wounder: Wouldn't be supporting arm4/thumb just a
> question
> of switch
On 18 Oct 2007, at 11:45, Joost van der Sluis wrote:
But there is also a fpc-bug
(https://bugzilla.redhat.com/show_bug.cgi?id=337051)
They updated the rpm-package, so that it doesn't crach on it anymore
(https://bugzilla.redhat.com/show_bug.cgi?id=337011) but I like to
have
this fixed in fp
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
Op donderdag 18-10-2007 om 12:02 uur [tijdzone +0200], schreef Marc
Weustink:
> Joost van der Sluis wrote:
> > Op woensdag 17-10-2007 om 13:22 uur [tijdzone +0200], schreef Joost van
> > der Sluis:
> >> On recent (development) Fedora-systems the debug-information is
> >> extracted form executables
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
Joost van der Sluis wrote:
Op woensdag 17-10-2007 om 13:22 uur [tijdzone +0200], schreef Joost van
der Sluis:
On recent (development) Fedora-systems the debug-information is
extracted form executables in a different manner.
That could be a problem when building RPM's on a Fedora system.
I got
Op woensdag 17-10-2007 om 13:22 uur [tijdzone +0200], schreef Joost van
der Sluis:
> On recent (development) Fedora-systems the debug-information is
> extracted form executables in a different manner.
>
> That could be a problem when building RPM's on a Fedora system.
>
> I got this output, does
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
Could the warning not simply be switched off and on (or set to some kind of
level) by a {$... line ?
It is on the to-do list already. However, I don't think it'll be the end
of the discussions; there will always be tension between the compiler
being helpfull to signal dubious code, and
Op Thu, 18 Oct 2007, schreef Adriaan van Os:
> Daniël Mantione wrote:
> >
> > Op Mon, 15 Oct 2007, schreef Michael Schnell:
> >
> > > > So I guess the warning stays. We can discuss some extensions
> > > > which makes
> > > > it easier to code such restrictions like merging parts of the tue
> >
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
So I guess the warning stays. We can discuss some extensions which makes
it easier to code such restrictions like merging parts of the tue branch.
>>> Could the warning not simply be switched off and on (or set to some kind of
>>> level) by a {$... line ?
>>
>> It is on the to-do lis
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
Daniël Mantione wrote:
Op Mon, 15 Oct 2007, schreef Michael Schnell:
So I guess the warning stays. We can discuss some extensions which makes
it easier to code such restrictions like merging parts of the tue branch.
Could the warning not simply be switched off and on (or set to some kind of
58 matches
Mail list logo
